[Tiptoi-hw] SPAMALERT: Re: Frage bez. SPI/NAND Flash

[Sven A. Huerlimann]

Wenn ich einen Offset von 0x1C reinbastel im NAND controller, komm ich
durch den ANYKANB? test.

Message to Myself: Reverse-Engineering ist keine exakte Wissenschaft.

Grz Shue

On 20.12.20 21:21, Sven A. Huerlimann via tiptoi-hw wrote:
> Hier noch die Knacknuss:
>
> Nach dem Laden des Flash-Images (erste 256 bytes)
>
> - 0x00a68 -> nand_boot
>     - 0x020c4 -> nand_load
>         - 0x02758 -> magic offset calulation -> Result: 0x38
>     - 0x01b74 -> nand_copy_buffer (kopieren vom buffer an die
> Zieladdresse (0x08000000))
>     - Copy 8 bytes von Zieladdresse to stack
>     - Compare mit fixem String "ANYKANB2" (oder 1 oder 0, je nach BIOS
> version)
>
> sieht das Memory wie folgt aus:
>
> // Zieladdresse:
>
> (gdb) x/20w 0x08000000
> 0x8000000:    0xea000023    0xea000043    0xe1a0f00e    0xea00005a
> 0x8000010:    0xea000066    0xe1a00000    0xea00003f    0xea00003e
> 0x8000020:    0x4b594e41    0x32424e41    0x02021004    0x00300003
> 0x8000030:    0x000f5ad1    0x000f5c5c    0x00050005    0x9510dcad
> 0x8000040:    0x00400800    0x10001000    0x02400800    0x020b030f
>
> // Der Stack (Teile davon)
>
> (gdb) x/20w 0x0802eed0
> 0x802eed0:    0x00000000    0xea000043    0xe1a0f00e    0x00000000
> 0x802eee0:    0x08000004    0x00000000    0x00000002    0x00003200
> 0x802eef0:    0x00000000    0x0802ef00    0x0000008c    0x00000a74
> 0x802ef00:    0x00000000    0x00000000    0x00000000    0x00000000
> 0x802ef10:    0x00000000    0x00000000    0x00000000    0x00000000
>
> // Der NAND Buffer
>
> (gdb) x/20w 0x0802f800
> 0x802f800:    0xea000023    0xea000043    0xe1a0f00e    0xea00005a
> 0x802f810:    0xea000066    0xe1a00000    0xea00003f    0xea00003e
> 0x802f820:    0x4b594e41    0x32424e41    0x02021004    0x00300003
> 0x802f830:    0x000f5ad1    0x000f5c5c    0x00050005    0x9510dcad
> 0x802f840:    0x00400800    0x10001000    0x02400800    0x020b030f
>
> -------------
>
> Der magische String ANYKANB2 ist im Flash-Dump am Offset 0x20.
> Die Überprufung auf diesen String geht über ein strcmp an der
> Stack-Addresse 0x0802eed4 (wo offensichtlich eine Kopie des zweiten und
> dritten Words aus dem Image liegen, null terminiert siehe 0x0802eedC ->
> im code: 0x00b64)
>
> Die einzige Mathe die mich bisher von Offset: 0x38 zu 0x20 bringt ist:
>
> - 0x38 ist ein 16bit Word offset. -> ergibt 0x1C als 32bit Offset
> - 0x1C ist 4 bytes Unterhalb von 0x20 -> Die Kopie auf dem Stack ist um
> 4 bytes vom Bufferanfang verschoben.
>
> Aber damit macht wiedermal alles keinen Sinn und ich geh jetzt in die
> Küche um mich da auf den Boden zu werfen und zu heulen :)
>
> Vielleicht hat ja noch jemand eine Idee..
>
> Gruss Sven
>
> On 20.12.20 20:36, Sven A. Huerlimann via tiptoi-hw wrote:
>> Salü allerseits
>>
>> Ich hab den aktuellen Stand der Flash-Emulation auf Github gepushed:
>> https://github.com/rhesus-ltd/qemu-chomptech
>>
>> - Der Code ist ein Massaker und funktioniert nicht
>> - Der emulierte Controller liefert immer die ersten 256 bytes des
>> Flash-Images
>> - EDC/ECC ist komplett taub (sagt eifach immer "Yes")
>>
>> Die positiven Punkte:
>>
>> - Grundgerüst für die Flash-Emulation steht
>> - Ich komme bis zum "ANYKANB2" test (der fehlschlägt, weil String am
>> falschen Ort)
>> - Das Ding kommt durch die Github CI und müsste also auf einem standard
>> Ubuntu bauen. (Bei mir bauts unter OSX)
>>
>> Sobald ich die Flash-Knacknuss gelöst habe, werde ich mal rigoros
>> aufräumen und wohl die ganze History wegpushen. Im Moment ist es halt
>> Hacky-Mode.
>>
>> Grüsse Sven
>>
>> P.S: Falls jemand mutig genug ist das ganze mal auszuprobieren:
>> ./arm-softmmu/qemu-system-arm -device
>> loader,file=roms/chomptech/BIOS.bin -drive
>> if=none,format=raw,file=<nandflash.img> -machine chomptech -d unimp -S
>> -gdb tcp::1234 --serial stdio
>>
>> On 13.12.20 18:32, Sven A. Huerlimann via tiptoi-hw wrote:
>>> Hallo zusammen
>>>
>>> Ich arbeite an der Flash Emulation. Da sind ein paar Fragen aufgetaucht
>>> wo ihr mir vielleicht weiterhelfen könnt.
>>>
>>> - Wenn die CPU nicht mittels GPIO-Pins in einen bestimmten Bootmode
>>> (USB-Massstorage, UART, USB-Boot) geschickt wird kippt sie in folgenden
>>> Pfad:
>>>     - Zuerst SPI Flash!! Boot (0x006c) unconditional
>>>     - Dann NAND Boot (0x0088) unconditional
>>>
>>> Meines Wissens hat das Produkt kein SPI-Flash? Überseh ich da wiedermal
>>> was?
>>>
>>> @matthias: du hast doch das NAND mal ausgelesen. Gibt es da einen Dump
>>> den ich als für Tests nutzen kann?
>>>
>>> Grüsse Sven
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> tiptoi-hw mailing list
>>> tiptoi-hw at lists.nomeata.de
>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>
>> _______________________________________________
>> tiptoi-hw mailing list
>> tiptoi-hw at lists.nomeata.de
>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>
>
> _______________________________________________
> tiptoi-hw mailing list
> tiptoi-hw at lists.nomeata.de
> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw