6 ms·
How the Devteam Conquered the iPhone
- nicoboo 3y agoWell written and highly detailed description, as always with Fabien's work. I remember seeing the investigation on this iPhone protection back at the time, what a journey it has been since this work. Also, I hope someone can provide more information about that minus 0x400 shift before data write so it would be completely explained.
- e1ghtSpace 3y agoThe minus 0x400 shift appears to work like this: Seek(fd, 0xA0020000 - 0x400); We seek to 0x400 before where we need to write the data SendWrite(fd, foo, 0x400, false); We set the first 0x400 bytes of what we want to write to 0 SendWrite(fd, fw, fwsize, true); We then set the rest of the bytes to our data. SendEndSecpack(fd); The iphone copies the data from 0x400 bytes onwards (which is all the data we wanted to write), then tries to verify the signature and fails. If the signature could be verified the first 0x400 bytes (which we left as all zeros) would then be copied.
- trashburger 3y agoOuch! That's a fail on the same level of Microsoft forgetting the XBox decryption keys on the secret ROM.
- ixtli 3y agoThe product itself was, at this stage, very rushed to market.
- bombcar 3y agoSo very many products are, but most people never see any of it, and most are boring enough that nobody cares to break them apart and see what's inside.
- ixtli 3y agoits also worth noting, on balance, that apple quickly made it a relatively hardened platform.
- 95014_refugee 3y agoThe IFX team that produced the baseband firmware had never heard of Sicherheit. It was … riddled with trivially exploitable security issues.
- nneonneo 3y agoI think Fabien is looking for an explanation as to why shifting by 0x400 bypasses the signature check. For example, is that shift somehow corrupting the signature check logic, or bypassing it by convincing the checker that no check needs to be performed?
- burnte 3y agoI think it was lack of imagination on the part of whoever programmed it. I wager they were more afraid of someone taking total control of the baseband so they figured everyone would start writing programs at 0, so they protected the beginning, which is their most important code. They didn't foresee someone just skipping that part and writing part of the firmware for such a small change.
- wonnage 3y agoI'm reading this as the iPhone holds the first 0x400 bytes in a buffer and doesn't write them until the signature has been verified. Everything else does get written. The assumption is that stripping off those initial bytes would render the firmware unusable, except in this case where they just padded the write by 0x400 bytes!
- garaetjjte 3y agoMy guess is that the chip doesn't have enough RAM to store firmware image, verify it, and only then write it to flash. So instead it needs to write it on the fly as it receives data in chunks of 0x400 byte pages. It starts by erasing first page, but instead of immediately writing it instead keeps buffer for that page for later. Then it transfers remaining pages normally, and at the end only when signature is correctly verified it goes back to write the first page.
- raphman 3y agoThat would also be my assumption. However, it seems the firmware was written as 0x800 byte pages: https://cdn.cs50.net/2014/fall/lectures/1/w/src1w/iUnlock.c https://cdn.cs50.net/2014/fall/lectures/1/w/src1w/iUnlock.c
- dmitrygr 3y ago> HELP WANTED: If you happen to know why -0x400 trick works, or can get in touch with Geohotz/MuscleNerd, please let me know. I have tried to ask around but have not found any explanation. I would be happy to update this article if someone knows. This is commonly done with fw updaters. first 0x400 bytes is a header that the earlier stage loader needs to see before it'll allow this stage to boot. So you RX the data, write it freely, just not the header. This is safe and will not allow any code exec since the header is missing. then at the end you sig check the whole thing you wrote, and if it is good, you write the header, making the whole image valid. the trick here is you write 0x400 bytes of garbage first, 0x400 bytes earlier than your desired write. this is buffered but not written (treated as the headers). The rest of what you sent IS written (writing what you wanted where you wanted). then sig is checked. you fail. the first 0x400 is not written (and you did not want it written). win
- ixtli 3y agoiZsh ( https://x.com/izsh1911 https://x.com/izsh1911 ) might also know but i lost track of that guy more than 10 years ago :(
- ixtli 3y agoAlso the part where you talk about “recovery mode” I think we referred to this as DFU mode back in the day. “Device firmware update” I’m not entirely sure it was called “recovery” at the time though I could be wrong as it’s been more than 15 years
- sneak 3y agoI think DFU mode and recovery mode are different. In recovery mode the screen is initialized and displays the “connect to iTunes” image. In DFU mode the screen is blank; I think this is implemented by the bootrom and can be used to restore even iBoot. https://www.theiphonewiki.com/wiki/DFU_Mode https://www.theiphonewiki.com/wiki/DFU_Mode
- ixtli 3y agoooo good point it’s been so long I might be misremembering. the reason I commented was because I thought you had to put the device in DFU to upload the image to the Media dir that was mounted rw. But again it’s been 15 years lol
- saagarjha 3y agoAh, the good old days. Back when iPhone hacking was easy…well not easy, but far easier.
- vmfunction 3y ago>These three fields would be concatenated into a token. The token would be sent to Apple server (albert.apple.com) where it would be signed with Apple's private key. The signed token would then be sent back to the device. A daemon lockdownd, listening over USB verified the token using Apple's public key. With the proof that the token came from Apple, and matching DeviceID, IMEI, and ICCID, lockdownd updated the device state to "Activated". The user then had access to the iPhone homescreen and the apps. Sounds like the pre-cursor to oAuth now days.
- ixtli 3y agoJust for history’s sake: I wrote iPHUC (and yes I was 19 and came up with that name lmao) and a guy with the nic “nightwatch” who I loved working with was responsible for the initial jailbreak and coining the term itself. I believe he was also responsible for pdf or tiff exploits that unlocked the PSP, too. He worked and lived in South America possibly at a university … but that’s all I know. It was a really fun time and I learned a lot. Also, George Hotz endangered the welfare of a few people who had kindly gotten us access to some documentation in Japanese despite repeated pleas not to do so. Very frustrating and why the dev team all eventually stopped working on the project.
- ixtli 3y agoOh, I just remembered one of the people who helped us understand the ARM architecture (it was somewhat new at the time) had the nic “pineapple” which is why many of the early UIs had pineapples on them. Again, great people and it’s a shame we never kept in touch
- epcoa 3y agoARM32 was nearly 15 years old by that point (the ARM700, the first 32 bit core dates to 1993). Maybe not exciting but the ARM32 had the bulk of its life before the iPhone, ARM64 came shortly after. Old and boring for the original iPhone ISA was also intentional.
- ixtli 3y agosorry i shouldn't have said "arm architecture" there obviously arm32 wasnt anything new: i figured that was implied. we wanted specifics on the S5L8900 and they were (and still are) quite hard to come by. this contributed to the discovery and instrumentation of DFU mode, iboot, etc that contributed to jailbreak
- 95014_refugee 3y agoLess “intentional” and more “unavoidable”. There was limited runway to fix the S5L8900 design, the Cortex A8 wasn’t ready at tapeout, and so the ARM1176 was it. If Broadcom hadn’t looked like they were fumbling the BCM2730 it would have been an ARM1132 instead, and history would have been a little different.
- deleted 3y ago[deleted]
- rewsiffer 3y agoAnyone know what tool they used to make the flow diagrams? They seem to be text based and might be superior to mermaid.
- dewey 3y agoLooks like monodraw, it was also on HN again a few days ago.
- FirmwareBurner 3y agomonodraw seems MacOS exclusive unfortunately :(
- unleaded 3y agohttps://asciiflow.com https://asciiflow.com will probably do
- FirmwareBurner 3y agothanks
- fabiensanglard 3y agoI use https://asciiflow.com https://asciiflow.com.
- xorl 3y agoThose were the days. :)
- xyst 3y agoThe “S” in original iPhone is for security. All in the name of shipping out that first product. Just like car manufacturers. Never buy the first few model years of a new product or platform.
- Night_Thastus 3y agoThere is no consensus on what the "S" stood for, and Apple never officially made any statement on the matter. "Successor" or "Second" or "Speed" all more or less fit, but there's no real answer. Generally, "S" just indicated a marginal upgrade over the base model.
- sroussey 3y agoHe is talking about the original iPhone. Not the 4S or whatever. Same kind of quote: the S in IoT stands for security! The S is missing, so security was missing too!
- adhambadr 3y agofuck this was a beautiful trip down memory lane thanks for the work putting and narrating this story so well. I remember following the progress half way across the globe and doing the hardware soldering hack on my 1st-gen, then good ol'd Cydia days. Can't process how young these people were and how they knew how to do such low-level investigative coding. I remember back then I was doing .NET c# and thought i'm the boss, humbling.
- deleted 3y ago[deleted]
- tgma 3y agoOne anecdote I remember was when the release of iPhone OS 1.1 broke jailbreak and I was on the IRC channel: one of the tricks found was to downgrade to 1.0.2, jailbreak the phone, symlink the `/root/Media` directory (reachable through iTunes) to `/` which was preserved during an upgrade, then do a firmware update and have access to rootfs then. (Yep, it was called iPhone OS back then not iOS.)