Hacker News new | ask | show | jobs
by nneonneo 836 days ago
I 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?
3 comments

My 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.
That 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

Thank you guys for your explanation.

From what I understand on this thread, the header of the firmware is 0x400 long. A page can be up to 0x800:

``` int size_to_write = Size > 0x800 ? 0x800 : Size; ```

So it would appear the firmware has a header of 0x400 which is buffered during upload but discarded if the firmware fails the checksum at the end of the upload.

I'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!
I 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.