AppleSocHot: Hot Hot Hot
2023-03-05T19:38:17+00:00 • goncalomb • apple,ipad,hacking
I got hold of an iPad from a family member that was bootlooping and took the challenge to retrieve some files that were not backed up to iCloud. It was quite a ride for someone that is not an iOS/Apple user, developer or hacker.
I started with the obvious and only option, put the device into recovery mode and do an "Update" through iTunes (not "Restore", I want to keep the data)... Well, that failed. That's it. There is no other official option to fix the issue without losing the data. I could not accept that.
Even Apple would probably just replace the logic board and the data would be gone.
Going Underground
Searching for other tools quickly led me to idevicerestore, an open-source project to install iOS firmware files. That also failed, mainly because it is just an open-source re-implementation of the iTunes procedure.
Well, it's time to dig deeper. I ended up spending hours learning about jailbreaking, exploits, downgrades etc.
The iOS upgrade process is quite interesting, Apple issues "signed hashes" for a specific device/version and that prevents users from installing older software on the devices (or unsigned software, see shsh). The full firmware files are indexed online at ipsw.me (iPad 6).
The software stack for Apple devices is something like this:
Boot ROM (iBoot 1st stage) > Bootloader (iBoot 2nd stage) > Kernel (XNU) > OS
This is where checkm8 comes into play, a bootrom exploit for some Apple devices (processor A5 to A11, my 6th gen iPad has A10). The bootrom holds the first code that is executed by the processor, an exploit on this code means that Apple won't be able to fix it with a software update (read-only memory). This particular exploit allows code execution and the possibility of running unsigned software.
That's what some crazy people did with ipwndfu, sunst0rm, SSHRD_Script, checkra1n, palera1n, and others. These are some projects that use the checkm8 exploit to allow for downgrading, jailbreaking, SSH access etc.
Let's remember that what I'm trying to do is just recover some data, I don't need root access or jailbreaking. After many tests and research, I started using and modifying SSHRD_Script which allows for SSH access to the device even without booting iOS. I could not make it work. The device just went back to bootlooping.
Quite fortunately I was able to catch that image of the kernel panic: "AppleSocHot: Hot..."?! There are some references to that online, "AppleSocHot: Hot Hot Hot", but nothing that could help me.
I was about to let it go. But came back a few days later...
Inspecting The Kernel
Over the years I did some disassembly on a totally legit copy of IDA Pro. But it's not something that I'm very familiar with. I did know about Ghidra an open-source reverse engineering program with similar goals.
Apparently, there are some scripts/tools to help analyze the kernel with Ghidra (see google), but I just loaded the kernel directly (extracted from the firmware files).
Armed with the best tool in reverse engineering, search for strings, I just searched for "AppleSocHot: Hot Hot Hot" and after some simple analysis and related searches, I found something promising.
Two boot arguments for disabling the sochot, whatever that is. With almost no references on the open web except for some iPhone diagrams and some stuff on GitHub, I can only speculate that it is some kind of system to monitor the SOC temperature sensors.
"sochot0=0 sochot1=0" could that be my salvation after so many hours?
It worked! Modifying SSHRD_Script to use "sochot0=0 sochot1=0" works and using palera1n to boot iOS also works. An extra argument "wdt=-1" is required to disable to watchdog timer, without it the device reboots after a few minutes ("wdt" is a known argument).
I ended up not using SSH, I'm not even sure I would be able to extract the data, because it is restricted by the SEP and I don't think there are any tools to input the pin code from the terminal to unlock it.
The Solution
The easy way, with a single command, is using the palera1n-c binary:
./palera1n -e "sochot0=0 sochot1=0 wdt=-1"
That runs the palera1n rootless jailbreak and boots back to iOS.
Or without running the jailbreak payload, by using PongoOS's pongoterm script (compiled from PongoOS/scripts) to adjust the boot arguments:
# use palera1n-c to boot the PongoOS shell
./palera1n -p
# connect to it
./PongoOS/scripts/pongoterm
# on the PongoOS shell
sep auto
xargs sochot0=0 sochot1=0 wdt=-1
bootx
It's important to note that this only works because we have that checkm8 exploit, normally it is not possible to run the kernel with arbitrary boot arguments. All these tools are built upon that exploit.
Back on iOS I was able to access and backup the data.
Conclusion
I was successful with the main goal, recovering the data.
Thanks to all the people that developed these tools and exploits, they are the real MVP. I'm just someone that found some boot arguments.
The iPad itself is not fixed, it probably has some kind of hardware issue. I was able to do a factory reset from iOS, but OTA and iTunes updates fail. It can run with those boot arguments indefinitely. But I don't know the consequences, the UI is also very slow, I suspect the CPU is throttling as a result of disabling those temperature sensors or whatever they are.
There are a lot of other boot arguments that I have not analyzed, "sochot_tolerance" is one of them, and there are many others not documented anywhere. So maybe there is some potential for other cool stuff, and maybe even to "fix" other boot issues.
My job is done for now, maybe someday I'll return to explore some other stuff.
Back to my Linux machine... I never left.
Discord (/r/jailbreak)
At the time, I also joined the /r/jailbreak Discord server to ask for some help, but it did not gather a lot of interest, here is the post where I shared my progress as it was happening (join the server to access). One of the reasons I'm posting this here is because Discord of not searchable from the outside, and I feel like this might help someone else.
Other References
The iPhone Wiki was a very good resource for this project.
If you want to know how these exploits work, check this document from checkra1n: "magic hax".
The kernel (XNU) is open-source apple-oss-distributions/xnu and apple/darwin-xnu, but that is not the whole picture, the kernel that ships the devices includes some other proprietary parts. That's why it needs to be reverse-engineered to find these options.
See also all the other links on this post.