Discover and read the best of Twitter Threads about #checkm8
Most recents (8)
Took us >1 year (way too long) but, @quaack723 and I got it working after I realized we were missing a oneliner 😎
A7-A8X.
Writeup son.
#Linux #AsahiLinux #checkm8
A7-A8X.
Writeup son.
#Linux #AsahiLinux #checkm8
Would be very helpful if you guys could help get a nice database of ADTs pulled from a running device (to get reserved memory map etc)
not only a7-a8x, every iDevice is welcome! (did I mention homepod runs on a8)
github.com/SoMainline/adt…
not only a7-a8x, every iDevice is welcome! (did I mention homepod runs on a8)
github.com/SoMainline/adt…
I agree with @chronic. There was no attempt to verify facts or claims with our team. There is no demo or proof of concept.
For example, the timeline in ironpeak post has many inaccurate or misleading claims, and it is not even in chronological order.
For example, the timeline in ironpeak post has many inaccurate or misleading claims, and it is not even in chronological order.
To be clear, the public @checkra1n jailbreak does not currently have any SEP exploit or mitigation bypass whatsoever for any device. Ironpeak claims that it does.
When we write things for public consumption, it is important that we are clear, accurate, and get basic facts right.
When we write things for public consumption, it is important that we are clear, accurate, and get basic facts right.
Good writing about deeply technical topics requires collaboration with subject-matter experts. It requires editing and peer review. There is no way around it.
I do not know what "vulnerability details" ironpeak emailed to Apple, but it was most likely a low quality bug report.
I do not know what "vulnerability details" ironpeak emailed to Apple, but it was most likely a low quality bug report.
IMPORTANT POINT 👇
Apple has the option of empowering users who #checkm8, while protecting users who do not #checkm8.
Instead, they decided that even users who want to #checkm8 cannot have a fully functioning iOS 14 jailbreak without a SEPROM exploit.
Apple has the option of empowering users who #checkm8, while protecting users who do not #checkm8.
Instead, they decided that even users who want to #checkm8 cannot have a fully functioning iOS 14 jailbreak without a SEPROM exploit.
Apple could allow jailbreaking to continue without SEPROM exploits, while protecting users who do not want to jailbreak. It would take slightly more engineering effort to make that happen, but it is not difficult to do.
Political barriers are more difficult to overcome.
Political barriers are more difficult to overcome.
It is the prisoner's dilemma: Two completely rational individuals might not cooperate, even if it appears that it is in their best interests to do so.
Unpatchable exploits cannot be stopped, but if they remove the incentive to release them publicly, they might just stay private.
Unpatchable exploits cannot be stopped, but if they remove the incentive to release them publicly, they might just stay private.
Security implications of this SEPROM vulnerability are not as bad as you might think:
(1) Browser-based (nation states) or app-based (community) jailbreaks cannot use it, because the value in TZ0 register is locked and cannot be changed after boot.
1/
(1) Browser-based (nation states) or app-based (community) jailbreaks cannot use it, because the value in TZ0 register is locked and cannot be changed after boot.
1/
(2) Apple's HW and SW uses many different mitigations, and they work together to limit the impact of a single vuln. This vuln cannot even be triggered without a vuln like #checkm8. Unless something like #checkm8 is found for A12/A13, we cannot even check if this issue exists.
2/
2/
(3) A #checkm8-based jailbreak can use this vuln to exploit SEPROM, patch SEP/OS in a meaningful way, and then protect SEP from further access after iOS boots. SEP could then still be secure against accesses from the AP, and apps and tweaks will not be able to exploit it.
3/
3/
1/ #CheckRa1n Hello from a bathroom inside Apple Headquarters! Some of us in the internal departments are happy to see the release of the upcoming CheckRa1n release! It's truly interesting to see a truly outstanding team come together to create and defeat one of our most secure
2/ aspects of the Apple devices! It made our job less boring here in the internal department! We just got out of a meeting where we just discussed how we plan to combat the upcoming jailbreak...I felt it's necessary to leak this information to give the community a heads-up on
3/ what security measures we are taking...In the upcoming weeks, the internal team is planning to patch the #CheckM8 bug and release the modified bootrom software across the Apple internal networks to the Foxconn factories where they will implement the new bootrom patch to
After the release of Checkm8, hundreds (maybe thousands) of researchers globally didn't sleep much and basically looked like this. Getting into DFU hundreds of times is quite tiring but soon the sandbox will be forever free for most iPhones/iPads!
#FreeTheSandbox #Checkm8
#FreeTheSandbox #Checkm8
Shamelessly copied from @AntonSquaredMe who did it for chess (but not Checkm8) :)
While we're at it, like/RT this tweet to help @Apple understand that #FreeTheSandbox would actually help iOS security:
There's a bug in A6 SecureROM in Image3 parser, that allows both tethered and untethered code execution. @iH8sn0w found it back in 2015. I tried to find it too, decompiled most of the Image3 stack in that ROM, but couldn't find anything useful, only memory leak and other nonsense
With release of #checkm8 by @axi0mX and forthcoming release of something else, I guess it's absolutely pointless to continue any research on this matter, so I'm publishing all the decompilations along with IDB and SecureROM/SRAM dumps
github.com/NyanSatan/Imag…
github.com/NyanSatan/Imag…
Freeing A6 devices was kind of a primary concern of my life, and now I don't even know what to do next
@axi0mX’s #checkm8 is out and let’s you debug your device (up to A11).
But how is this done?
Here is a little thread on dumping the bootrom (SecureROM) on demoted devices with Apple’s official tools.
1/ connect the cable using the correct lighting orientation and launch astris
But how is this done?
Here is a little thread on dumping the bootrom (SecureROM) on demoted devices with Apple’s official tools.
1/ connect the cable using the correct lighting orientation and launch astris
2/ select the CPU you want to work on (in this case, we’ll select CPU0) and halt it.
As result, astris will provide the output containing the selected CPU’s registers with their content.
We can now use the debugger to copy the content from the memory region
As result, astris will provide the output containing the selected CPU’s registers with their content.
We can now use the debugger to copy the content from the memory region
3/ use the command ‘save’ followed by the destination filename on the host, the address of the SecureROM and the size of the desired region to be copied (512kb are enough)
