Hacker News Reader

Comment by nicoboo | Hacker News Reader

Well 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.

View on HN

The 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.

Ouch! That's a fail on the same level of Microsoft forgetting the XBox decryption keys on the secret ROM.

The product itself was, at this stage, very rushed to market.

So 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.

its also worth noting, on balance, that apple quickly made it a relatively hardened platform.

The IFX team that produced the baseband firmware had never heard of Sicherheit. It was … riddled with trivially exploitable security issues.

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?

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.

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!

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.

Reply on news.ycombinator.com