Hallo zusammen,
letzte Woche habe ich eine x301t bekommen, einen Jtag angelötet und den bootloader gedumpt; gibt es eine Möglichkeit auch den xos (welcher den Bootloader anspringt) zu dumpen (entweder den seriellen Flash auslesen oder gibt es "Überreste" des XOS im RAM wenn der Bootloader angesprungen wird)?
Das BL-Image sieht im Hex-Editor zunächst genauso aus wie eine gewöhnliche NK.bin-Datei (die ROMHDR-ID an Adresse 0x40) und nicht wie ein Bootloader-Image; normalerweise steht doch bei einem EBOOT oder SBOOT an Adresse 0 ein relativer Sprung in den Code des bootloaders.
*EDIT*: Der Sprungbefehl liegt hier anscheinend an offset 4 :
ROM:00000004 li $k0, 0xB363392C
ROM:0000000C jr $k0
ROM:00000010 nop
* END EDIT*
Hat schonmal jemand versucht, das xos zu dumpen?
Das XOS läuft nicht auf der host-cpu sondern auf der XPU, es befindet sich zugriffsgeschützt in den letzten ~2MB von dram0. Das XOS springt also nicht den Bootloader an, sondern resettet die hostcpu und verbiegt vorher den Resetvektor so das er auf den vorher aus dem flash geladenen und entschlüsselten WinCE-Bootloader zeigt.
Das XOS läuft nicht auf der host-cpu sondern auf der XPU, es befindet sich zugriffsgeschützt in den letzten ~2MB von dram0.
Wie ist das mit dem "geschützt" gemeint; heißt das, daß ich den Speicher nicht mit dem JTAG auslesen kann?
Ich habe im Wiki gelesen, daß in dem smp8364 serieller Flash vorhanden ist (der wahrscheinlich dann den Bootstrap für die XPU beinhaltet). Ist dieser Speicher auch nur von der XPU erreichbar?
PS: Ich habe mit IDA den Bootloader disassembliert und bin diesen gerade am durchsehen; es ist übrigens sehr angenehm, daß nicht alle Debugmessages aus dem Code entfernt wurden :); vielleicht kann man diese ja wieder durch das ersetzen des "nullstub" durch den original Funktionsaufruf wieder reaktivieren...
Wie ist das mit dem "geschützt" gemeint; heißt das, daß ich den Speicher nicht mit dem JTAG auslesen kann?
Ja.
Ich habe im Wiki gelesen, daß in dem smp8364 serieller Flash vorhanden ist (der wahrscheinlich dann den Bootstrap für die XPU beinhaltet). Ist dieser Speicher auch nur von der XPU erreichbar?
Ja.
Ich gehe mal von aus das die originalen Funktionen die durch die Nullstubs ersetzt wurden nicht mehr existieren, idr. werden ja nicht benutzte Funktionen wegoptimiert.
Ich gehe mal von aus das die originalen Funktionen die durch die Nullstubs ersetzt wurden nicht mehr existieren, idr. werden ja nicht benutzte Funktionen wegoptimiert.
Ich meinte die rauscompilierte "DEBUGMSG"-Funktion:
ROM:93666F54 DebugMsg_CompiledOut: # CODE XREF: OEMLaunch+40p
ROM:93666F54 # PrintBanner+54p ...
ROM:93666F54 jr $ra
ROM:93666F58 nop
ROM:93666F58 # End of function DebugMsg_CompiledOut
so wie es aussieht, sind die Debug-Messages doch nicht ganz rauskompiliert, denn ich habe viele Stellen im Code wie die folgende gefunden:
ROM:93634E58 li $a1, 1
ROM:93634E5C addiu $a0, $v0, (aSmp863xWindows - 0x93600000) # "\nSMP863X Windows CE Bootloader Version "...
ROM:93634E60 jal DebugMsg_CompiledOut
ROM:93634E64 sw $t1, 0($t0)
ROM:93634E68 # ---------------------------------------------------------------------------
ROM:93634E68 lui $v0, 0x9360
ROM:93634E6C jal EdbgOutputDebugString
ROM:93634E70 addiu $a0, $v0, (aSignedBl - 0x93600000) # "SIGNED BL\r\n"
-> Die Meldung SIGNED_BL kommt ja immer noch raus; nur die meldung oben drüber nicht mehr; wenn man jetzt an die Stelle der Funktion DebugMsg_CompiledOut eine "richtige" Funktion oder einen Aufruf unterbringt; sollte man die anderen Meldungen auch alle noch ausgegeben bekommen
Ich vermute, daß hier ein Entwickler den Präprozessor nicht im Griff hatte :)
Naja, das könnte man wohl schon per jtag zurechtpatchen, die Frage ist nur ob sich der Aufwand lohnt, denn so spannend sind die BL-Ausgaben auch wieder nicht. Das Relevante kann man ja auch schon so aus den referenzierten Strings herauslesen.