search

axi0mX / ipwndfu

open-source jailbreaking tool for many iOS devices
GNU General Public License v3.0
7.09k stars 1.69k forks source link

t8012 #226

Closed rickmark closed 2 years ago

MCMrARM commented 4 years ago

For some reason AES keys can not be dumped with this as-is.

tl;dr of the issue is malloc. SEP functions now make a rather large allocations (0xf0), which makes the code allocate a chunk from bin 0xb. The chunk spans all the remaining RAM. The issue is that when validating the chunk hash, it crashes. For some reason the processor cannot access the 0x0x1801ffff8 address when loading a 64-bit access value (the heap ends at exactly 0x180200000). I have no idea why is this a problem, it sounds like a mix of a caching issue and some other processor state/bugs?

The heap allocation code always leaves an empty chunk (0x40 sized) at the end of the heap. A dumb workaround is to move it 0x40 bytes before (one allocation unit) and fix the previous chunk's size to point to it. The code implementing this workaround can be found here: https://mrarm.io/u/Paste%202020-03-09%2016-32-00.html

This still leaves us with the issue of why this bug is happening in the first place. With high certainty it can be said that it is somehow inflicted by the exploit, because otherwise the heap management code would crash in the first place.

One of my theories involves the SCTLR register, we don't know the default value of it. Maybe it matters.

mwoolweaver commented 4 years ago

Does this fork provide the proper fixes?

h0m3us3r/ipwndfu/commits/master

MCMrARM commented 4 years ago

it looks like it integrated my workaround patch, so i guess

rickmark commented 4 years ago

Bump - @axi0mX - looks like there is approval on the changes, so if you bless this...