Hello everyone! Almost three months went by and nothing seems to have happened here. Have we finally given up? I hope not.
Emmanuel, is there anything going on? If yes, please post a quick summary ;) tof wrote: > my hypothese about this , for the boot process : > > 1) the arm resets, mask rom is mapped at 0 (remap=0, BOOT_MODE=0) > 2) the rom program copies the flash to the internal ram (256kB?, so only > 1/4 of it, so up to 0004 0000) > 3) the decryption runs from the rom and deciphers the ram between > adresses 0000 8000 and 0004 0000 (this is why the encrypted code stops > abrupthly at this adress) > 4) the rom jumps to a ram adress, probably 2200 8000 where the code begins > 5) the ram program sets remap=0, dmap=1, so the ram is mapped at adress > 0 instead of the rom. > 6) Now the reset vector is valid, and useful. the ram program can now > also put valid interrupt jumps (the actuals are a loop at 2200 00xx !!) > ....... > > > it seems to me this is the only scenario where the vector table at 0 in > the flash can be useful... Sounds pretty straightforward, but I would guess that they don't use the whole SRAM for that, but only up to 0x28000, where the encrypted data stops, as the firmware may need to place some critical code in the SRAM (i.e. interrupt vectors requiring low latencies or the code to wake up from standby and re-enable the SDRAM). tof wrote: > a solution could be code injection in the flash: > it seems the soc can boot from the flash by putting the BOOT MODE pin to 1. > we need to find this pin, probably tied to 0, and put it to 1. > > then we need to wire a easily reprogrammable memory in the place of the > flash > then we just put a quick routine in this mem that will read out adresses > from 2000 0000 (rom) and to output it in some manner. > the easiest output i can imagine is the adresses of the flash (reading > an adress outputs this adress on the adress bus.) > > so we would need to emulate the flash with a fpga, and record the adress > access as an output. > > someone ready to experiment ? Olivier ? I think it's even easier: We don't need to change BOOT_MODE to do that. Remember that the IVT and all the memory up to 0x8000 are not encrypted and could be replaced by arbitrary data. We could just remap the reset vector that way and place some KB of code immediately after the IVT to do the dumping. On the first boot, the internal ROM will load our code into SRAM, then we give it another reset, and our code will be executed, right? If they did clean programming, they don't jump to 0x8000 on the first boot, but instead fire a software reset. So our code would be loaded instantly. Pretty cool, isn't it? So let's hope there is no checksum for the whole boot flash including the IVT. But we nevertheless need to wire an FPGA to that iPod to emulate that memory, but you SMD guys will somehow manage to do that... Good Luck :) serpilliere wrote: > I din't know if someone remarks this: > > the section located at 0007C3C0 and the other located at 000B5E40 > starts with same first bytes, > but a difference appears some 0x210 bytes after start: > The first one: > 0007C3C0: 2A 7E 38 EA 35 03 06 44 85 78 8E 8E 38 F9 32 88 > 0007C3D0: 9D B8 26 50 48 72 57 96 CA 3A 83 B6 F4 C8 FA 50 > ... > 0007C5C0: 54 60 84 5B E4 56 90 17 53 2B 8D 5E 84 CD A4 37 > 0007C5D0: 7F C6 4D 57 BC 27 DC 0A 27 89 F4 D1 AC 03 65 08 This is the weird overlapping section. > > The second one: > 000B5E40: 2A 7E 38 EA 35 03 06 44 85 78 8E 8E 38 F9 32 88 > 000B5E50: 9D B8 26 50 48 72 57 96 CA 3A 83 B6 F4 C8 FA 50 > ... > 000B6040: 54 60 84 5B E4 56 90 17 53 2B 8D 5E 84 CD A4 37 > 000B6050: 7E C3 5C FC 9B 69 13 B6 FB B1 8D CE 0D 1F 59 14 This is diagflsh. And for some weird reason this is also part of the section above. In fact it's the last part of it. > > So this could mean both section may be (if ciphered) ciphered with same > key and those 2 > sections start with same bytes, but differs at nearly 0x220 bytes from > start so their ciphered text. Yep, that seems to be true. I'll try to find out whether they are ciphered at all. At least this invalidates my theory where the key is stored. The fact that the weird section starts the same way as diagflash suggests that that weird section is also executable code. At least, if one assumes, that the entrypoint of the xxxxflsh executables is at their beginning. But if it is executable and the entrypoint is it's first word, then it must be either encrypted or there must be some code at a pretty weird offset, as it's first instruction would be a relative branch to +0xE1F8A0 bytes. The disassembly immediately afterwards is weird nonsense, so I guess it's encrypted, but with the same key. Weird coincidence that it's first instrunction is an unconditional branch, thats 1 out of 256. > > But maybe it doesn't really helps. Why do you think that way? Maybe it DOES help, that's important! One thing i'm pretty sure about is that the decryption key isn't stored in the header of the section, but either somewhere in the ROM or in the decrypted version of the flash somewhere in the code at 0x8000. But what are these section headers good for? They seem to be XOR crypted from 0x20 to 0x200 with the key stored at 0x18, but what do they contain? A checksum? Greets and good luck with your further invesigations The Seven _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
