Hallo Forum, ich bin auf der Suche nach einer Möglichkeit, aus einem Cortex-M0 mit aktivierter Code-Protection die Firmware auszulesehen. Konkret handelt es sich im einen Nuvoton MINI54ZAN. Details gibt es im Thread: Beitrag "Hackbarer(?) 21 EUR Quadcopter" Bisher war es mir möglich per SWD auf der Controller zuzugreifen. Das SRAM und viele AHB-Bereiche lassen sich per SWD mit Keil auslesen. Der Codebereich besteht aber nur aus FF. Ebenso scheint es nicht möglich zu sein, die CPU nach dem Eintritt in den Debug-Modus wieder zu starten. Wenn es gelänge, ein Programm im SRAM auszuführen, müsste es über dieses möglich sein den Inhalt das Flash-Bereichs Stück für Stück in SRAM zu kopieren. Zum Ausführen des Codes wäre es ja prinzipiell denkbar, den Return-Stack zu manipulieren und auf den eigenen Code zu verbiegen. Diese Art des Angriffs ist natürlich so trivial, dass ARM wohl eine Gegenmaßnahme installiert hat. Eines der Probleme ist, wie oben gesagt, dass sich die CPU ohne Reset nicht wieder starten lässt. Hat jemand schon einmal Ähnliches probiert? Gibt es dazu noch Ideen? Ich bin auch noch auf der Suche noch eine aussagekräftigen Beschreibung des SWD-Protokolls. Momentan bin ich mir noch etwas im Unklaren über die Fähigkeiten des Ports.
:
Bearbeitet durch User
Hallo, Tim . schrieb: > . Zum Ausführen des Codes wäre es ja prinzipiell denkbar, den > Return-Stack zu manipulieren und auf den eigenen Code zu verbiegen. Hast du Zugriff auf die Register? Kannst du den PC ändern?
Sieht nicht so gut aus:
1 | Security Lock |
2 | 0 = Flash data locked. |
3 | 1 = Flash data unlocked. |
4 | When flash data is locked, only device ID, unique ID, Config0 and Config1 can be read by writer and ICP through serial debug interface. Other data is locked as 0xFFFFFFFF. ISP can read data anywhere regardless of the LOCK bit value. |
Also der ISP kann die Daten ganz normal lesen. Evtl. hat der ISP eine Schnittstelle nach draussen?!
Hi, ich denke, da hast du ohne ein detailiertes Datenblatt keine Chance. Ein paar Möglichkeiten um das Auslesen mit dem Debugger zu verhindern wären: Das Flash einfach abzuschalten sobald eine Debug-Session gestartet wird. Die MPU (falls vorhanden) so zu programmieren, dass im Debug-Mode kein Zugriff aufs Flash erlaubt wird. Aber es sollte doch kein Problem sein, ein kleines Progrämmchen zu schreiben, es für den RAM Bereich zu linken (vorrausgesetzt man kennt die RAM-Adressen), per Debugger zu laden und zu starten. Dann stellt sich schnell heraus ob man vom RAM aus auf den Flash kommt.
Christopher B. schrieb: > Hast du Zugriff auf die Register? Kannst du den PC ändern? Der PC hängt beharrlich bei 0xfffffffe. Screenshot anbei. Ohh schrieb: > When flash data is locked, only device ID, unique ID, Config0 and > Config1 can be read by writer and ICP through serial debug interface. > Other data is locked as 0xFFFFFFFF. ISP can read data anywhere > regardless of the LOCK bit value. Witzigerweise stimmt das nicht. Denn ich kann Config0 und Config1 nicht auslesen, dafür aber das SRAM und jede Menge AHB-Peripherie. >Also der ISP kann die Daten ganz normal lesen. Evtl. hat der ISP eine Schnittstelle nach draussen?! Beim ISP handelt es sich um einen Bootloader der die serielle Schnittstelle nutzt. Der Bootloader ist natürlich auch gesperrt.
:
Bearbeitet durch User
Wie kommt man eigentlich darauf das jeder dahergelaufene die Codeprotection eines ARMs durch irgendwelche einfachen Tricks aushebeln kann? Wenn das so einfach wäre würden die Dinger nicht mehr verkauft werden.
holger schrieb: > Wie kommt man eigentlich darauf das jeder dahergelaufene > die Codeprotection eines ARMs durch irgendwelche einfachen > Tricks aushebeln kann? > > Wenn das so einfach wäre würden die Dinger nicht mehr > verkauft werden. Zahlen, Daten, Fakten bitte.
Flash-Speicher und Code protection sind meiner Meinung nach Chip Hersteller Sache und nicht ARM Tim schrieb: > Zahlen, Daten, Fakten bitte. Warum hast Du denn an Deiner Wohnungstuer ein Schloss dran?
Tim schrieb: > Ohh schrieb: >> Funktioniert STEP ? > > leider nicht. Dann kannst du es vergessen. Kauf dir 2 Geräte und schreib dir eine eigene Firmware bis die Outputs identisch sind ;-).
Ohne den Kontroller zu kennnen. NVIC zugänglich? -> Kontrolle über PC Peripherie mit integriertem Speicher vorhanden? (z.B. USB Buffer?) Ist der ausführbar?
Folgende Vorgehensweise wäre unter gewissen Umständen erfolgreich: - NVIC table vector ins RAM legen - Exception-Vector auf deine Routine im RAM verbiegen - Thumb-Bit löschen (führt nach einem CPU-Takt zur Exception) - CPU Step ...
Hallo, ich habe die Firmware bei meinem Gerät (Mould King X6) einfach auslesen können und auch das Ausführen von Code im SRAM lief. Nach einigem Rumprobieren und dem Versuch das APROM neu zu beschreiben geht jetzt allerdings der SRAM Upload nicht mehr. Hat jemand eine Idee woran das liegen könnte? Die Register kann ich noch auslesen und auch schreiben nur ins SRAM und Flash schreiben funktioniert nicht mehr. Firmware, OpenOCD script (eine Version mit src/flash/nor/mini51.c wird benötigt) und Testcode habe ich mal hier hochgeladen: http://code.google.com/p/e-projects/source/browse/ Die MK-X6 Firmware verwendet übrigens sowohl für spi als auch für i2c bit-banging und nicht die Hardware (spi ist wohl auch falsch verkabelt).
Jog3k schrieb: > ich habe die Firmware bei meinem Gerät (Mould King X6) einfach auslesen > können und auch das Ausführen von Code im SRAM lief. Nach einigem Super Sache, vielen Dank! Was hast Du für einen SWD-Adapter genutzt? > Rumprobieren und dem Versuch das APROM neu zu beschreiben geht jetzt > allerdings der SRAM Upload nicht mehr. Hat jemand eine Idee woran das > liegen könnte? Die Register kann ich noch auslesen und auch schreiben > nur ins SRAM und Flash schreiben funktioniert nicht mehr. Hast Du evtl. die Config-Register verändert? > Firmware, OpenOCD script (eine Version mit src/flash/nor/mini51.c wird > benötigt) und Testcode habe ich mal hier hochgeladen: > http://code.google.com/p/e-projects/source/browse/ Ich habe die Firmware einmal disassembliert (anhang). Leider ist es beim Cortex M0 wirklich anstrenged etwas aus compiliertem Code zu lernen. > Die MK-X6 Firmware verwendet übrigens sowohl für spi als auch für i2c > bit-banging und nicht die Hardware (spi ist wohl auch falsch verkabelt). Interessant. Dann scheint es insgesamt ziemliche Unterschiede zum JXD385 zu geben. Da bestätigt sich wieder dass der X6 der Clone vom Clone ist :) Der Hauptthread ist übrigens hier: Beitrag "Hackbarer(?) 21 EUR Quadcopter"
Tim schrieb: > Super Sache, vielen Dank! Was hast Du für einen SWD-Adapter genutzt? Ich habe den stlink-v1 vom stvldiscovery benutzt. > Hast Du evtl. die Config-Register verändert? Das ich die Config-Register geändert habe kann gut sein, zumindest zeigt mit der ISPCON Register jetzt immer an das er vom LDROM bootet (nach einem POR). Allerdings sehe ich in den CONFIG Registern nichts was das Schreiben ins SRAM verbieten könnte ... mal gucken. > Ich habe die Firmware einmal disassembliert (anhang). Leider ist es beim > Cortex M0 wirklich anstrenged etwas aus compiliertem Code zu lernen. IDA (hex-rays.com/idapro) ist ein gutes Programm für solche Aufgaben. Der Bereich 0..0xbc besteht aus 32bit Worten (0: sp Wert, 4: Addresse des Reset-Handlers und dann die Adressen der anderen Exceptions). Ab Adresse 0xc0 kommt dann der ARM-thumb Code (in IDA Alt+G und "1" als Wert eingeben). Aber objdump geht natürlich auch. Demnach: initial sp = 0x20000680 reset_offs = 0x35fd ...
Die Frage ist vielmehr: Was genau wird unter "Firmware auslesen" verstanden? Wenn es nur darum geht, einen FW-Stand auszulesen -> const char's mit der Revision ablegen und 08/15 auslesen. Ansonsten wird bei aktivierter Code-Protection jeder Versuch den Code auszulesen scheitern. Sonst wärs ja keine Code-Protection.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.