Here is my little thread about yet another bug I found in A6 bootrom (and probably any other that boots from H2FMI PPN NAND)
As always, absolutely useless on its own
As always, absolutely useless on its own
Look at this picture. The bootrom has just read LLB from a bootpage and is now ready to create a Memz structure out of it. Address - 0x10000000, size - 0x24C00, flags - IMAGE_OPTION_LOCAL_STORAGE
Since the size was 0x24C00, we expect to see nothing on range of 0x10024C00 - 0x10060000 (the end of load area), right? Wrong!
As you can see, we have controllable custom data beyond the range nand_read_bootblock() reports to main()
The first question you ask now is can we write beyond load area on devices where [unlike A6] load area is shorter than NAND space for LLB (for example A5 - 0x2F400 vs 0x2C000)?
Nope. This works only because nand_read_bootblock() checks ECC of newly read page BEFORE adding its size to a counter, and when ECC is bad it returns, and under certain circumstances it even returns success
As result, we can have up to one page of data beyond the size nand_read_bootblock() reports to the caller (and it stays unaware), BUT only if it doesn’t overflow the limits of load area
(Remark - I’m a shit reverse engineer, so better verify the last bit yourself)
How to achieve this on practice and have something we want to see there? Well, the boot block consists of pages and pages consist of sectors. A sector is 0x200 bytes in size, and there’re 3 in one page (so a page is 0x600)
We can write just 2 sectors instead of 3 - this way first 2 sectors will contain our arbitrary data, and the third will have some nonsense and broken ECC. Lame way, and it limits size of the meaningful data to 0x400, but that's the best I could do
I’ve implemented this technique in my iBoot payload - StarInjector - and will push the updated branch a little bit later. Stay tuned (omg, who the hell cares)
https://twitter.com/nyan_satan/status/1358849392799801347
As stated in the top tweet, it’s absolutely useless without something else. But since Image3 routines won’t consider this data as part of an image, it will survive a lot of memset()s on the way, except for the one in main() which is only called when boot_image() returns
And upon successful load of an Image3, the data will persist to the very end. Here you can see the bootrom ready to boot an image (0x5F80 is prepare_and_jump()) and our data still there
Useful resources:
1) Stolen iBoot source code - still contains the code for booting from H2FMI NAND, even though it’s not used by SecureROM from that era
2) My thread about bugs I’ve found in Image3 stack of A4/A6 bootrom
1) Stolen iBoot source code - still contains the code for booting from H2FMI NAND, even though it’s not used by SecureROM from that era
2) My thread about bugs I’ve found in Image3 stack of A4/A6 bootrom
https://twitter.com/nyan_satan/status/1225106425531322370
3) StarInjector - mentioned above, the payload to write to boot block (and more!)
https://twitter.com/nyan_satan/status/1358849392799801347
One more thing. I initially thought that the ECC failures on the device I discovered the whole thing on were caused by the fact StarInjector violates standard procedure of writing to NAND boot block a little bit
The procedure is like this:
1) Save the page 0 - partition map
2) Erase the whole block (0)
3) Put the map back on pages 0 and 1
4) Write your LLB page by page
5) The rest of the pages must written as “full” (for whatever it means - look at the screenshot)
1) Save the page 0 - partition map
2) Erase the whole block (0)
3) Put the map back on pages 0 and 1
4) Write your LLB page by page
5) The rest of the pages must written as “full” (for whatever it means - look at the screenshot)
StarInjector skips the step 5
But apparently this bug happens even on fresh normal restores. Either they skip the step too, or that’s just not the cause
• • •
Missing some Tweet in this thread? You can try to
force a refresh
