Forum: Mikrocontroller und Digitale Elektronik Flash im Cortex-M0 durch Codeinjektion ins SRAM auslesen


von Tim  . (cpldcpu)


Lesenswert?

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
von Christopher B. (chrimbo) Benutzerseite


Lesenswert?

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?

von Ohh (Gast)


Lesenswert?

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?!

von user (Gast)


Lesenswert?

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.

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

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
von Ohh (Gast)


Lesenswert?

Funktioniert STEP ?

von Tim  . (cpldcpu)


Lesenswert?

Ohh schrieb:
> Funktioniert STEP ?

leider nicht.

von holger (Gast)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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.

von Juergen G. (jup)


Lesenswert?

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?

von Ohh (Gast)


Lesenswert?

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 ;-).

von Maxx (Gast)


Lesenswert?

Ohne den Kontroller zu kennnen.

NVIC zugänglich? -> Kontrolle über PC
Peripherie mit integriertem Speicher vorhanden? (z.B. USB Buffer?) Ist 
der ausführbar?

von Ohh (Gast)


Lesenswert?

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 ...

von Jog3k (Gast)


Lesenswert?

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).

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

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"

von Jog3k (Gast)


Lesenswert?

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
...

von Roland E. (roland0815)


Lesenswert?

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
Noch kein Account? Hier anmelden.