Open anonfantom opened 6 years ago
Yeah, I can confirm it does boot loop you.
Thanks for the exploit; but did you actually test this before releasing? You might say it’s a PoC, but you branded it as a simple jailbreak.
@MTJailed: that’s a stupid way of saying a file got corrupted.
iPhones don’t even have hard drives.
I hate people who talk shit about terminology misuse, I meant to say that the filesystem got corrupted Ugh you get the fucking point.
@MTJailed: No, I don’t “get the fucking point” because the filesystem isn’t corrupted. You just wanted to chain together some fancy words to make it sound all big and fancy.
@nullpixel if your question was directed at me, then as stated in the description this is tested on iPhone X 11.3.1. Currently it achieves kernel RWX, escalates privileges to root and escapes the sandbox successfully for that platform on my test device.
This is an open source project with only few lines of code, of which none deal with APFS or even write anything to the filesystem from the repository's creation until now. If you have any doubt about that, take a look yourself.
Did you run any other code that does that by any chance? Note that if you do manage to find a bootloop issue within this project then that would itself be a major discovery.
@potmdehex I have a X on 11.3.1 — I saw you saying it was tested on that device in the README.
I know the project does not touch the filesystem. I have read the code.
The project logged a line to my console saying “Failed to find the corrupt port” — okay, the exploit failed; I can run it again, right. Nope. My phone rebooted and failed to boot again.
I fixed this by restoring back to 11.3.1, and tried reproducing the same issue — it happened again; the phone rebooted, and just would not finish booting after a force restart.
This was before the QiLin stuff, leading me to believe it was an issue with the RWX stuff — I never had this issue with the commits prior to the RWX commit.
Two other people were able to reproduce this in the jailbreak discord, along with the person who created this issue, and the other commenter.
@nullpixel Well, the code is there for you to scrutinize and make any changes you want to, all I can say is that I don't have that issue.
Did any of you run any code that attempts file system remount or writes files in some way? Because getting a bootloop is an achievement in itself, it's not something easily doable by mistake, especially not without touching the filesystem.
The other theory apart from you running something else causing it is that the heap manipulation, which is unrefined, randomly wrecked something so badly that it sent your device into oblivion, perhaps due to the new APFS changes starting from 11.3. The solution then would be to tweak it to something less violent, which certainly is possible with the primitives provided in multipath_kfree.h
I haven’t modified the code at all — running it out of the box resulted in a bootloop, upon failed attempts.
It leaves me to believe that the OS panicked whilst writing something important to disk, that obviously got corrupted.
I’m not sure if this is entirely your PoCs issue, but it definitely only happens upon running the code off master.
I’m able to reproduce it every time it fails on stock iOS, no modifications whatsoever. I setup as new just to ensure that this was not as a result of any modifications I did.
Didn't mean to say you must have made any changes - just that 1. you are welcome to make any changes to as well as point out anything you think can be improved and 2. if you have run any other code (AKA other app) that e.g attempts file system remount, such as the other private jailbreaks floating around then that could be the cause.
If you'd like to dig deeper, you could try setting breakpoints to see where it happens. Just keep in mind that setting a breakpoint at any location that does a refill after a free, effectively delaying it since you are pausing execution, will lead to the exploit certainly failing.
I’d love to help you investigate more, but it’s hard to debug. Not to mention I don’t want to risk losing my 11.3.1 version, as I’m confident that it’ll stop signing in the near future.
it has yet to bootloop me but does not find corrupt port on my iX, tried maybe 10 times now. gonna keep trying to get a diff result but egh, idk if it will or not. Did anyone convert the project appdelegate to swift or NO?
It seems on iPhone 6S the prealloc size of the ports will never make it end up in k.alloc 4096, maybe I should change the 0x660 to something else?
@nullpixel No worries. Just out of curiosity, did you run any FS remount/similar apps or not though (including before the first time it bootlooped)?
@pwned4ever and @MTJailed the main thing is where the multipath socket structs end up. You can try removing the sim card, rebooting and running the exploit without sim card inserted. I didn't do any testing on sim inserted or not, but just a wild guess is that if you have a sim card inserted, some app on the phone might detect that and open and keep a multipath socket. In that case there would already be a page allocated for the multipath socket structs, which the current super basic heap layout prediction doesn't account for (can be improved).
@potmdehex: I didn’t run anything at all, but the PoC.
@nullpixel made a tweet which suggests it could indeed be related to Siri.
So @anonfantom, @MTJailed, @pwned4ever, if any of you want to assist further then please re-test with Siri completely disabled.
@pwned4ever reported success after disabling Siri: https://twitter.com/pwned4ever/status/1003384911443550208
Testing it with Siri disabled worked for me on my iPhone 6S. I got as far as leaking the kernel slide but I think it panics there due to me having an invalid offset for AGXCommandQueue vtable.
(Kernel instruction fetch abort: pc=0xffffffe0242bf7e0 iss=0x6 far=0xffffffe0242bf7e0. Note: the faulting frame may be missing in the backtrace)
Anyway thank you for this great work, I think it may be better to align the port spray a bit more precise in the zone but I have no idea how I can do that.
I fixed it, the offset I had for AGXCommandQueue vtable was incorrect. Now running with root and shell access. Thanks for all.
The reboot loop occurs due to apfs write events corrupting your harddrive during the kernel panic. This is dangerous and you will need to perform an erase restore to fix it, better wait until someone adds logic for cleaning up the exploit on failure.