Mikrocontroller auslesen

[STM-Bastler (Gast)]

Hallo liebe Forumgemeinde,

kann mit dem ST-Link (SWD) und Coocox ein STM32 ausgelesen werden?

Es geht um den Flashspeicher..

Ich möchte ein Programm runterladen als .hex oder .bin


Kann mir jemand helfen?

[Pascal (Gast)]

Das kannst du mit der STM32 ST-LINK utility:
http://www.st.com/web/en/catalog/tools/PF258168

Einfach verbinden und dann View->Device Memory

anschliessend rechts klick auf den Device Memory Tab->Save to file

[STM-Bastler (Gast)]

Danke für deine Antwort Pascal.

Das Programm habe ich schon installiert und wird morgen
ausprobiert.

Ich denke das klappt. Danke.


BTW: Hast du Erfahrungen mit der "Read-out-protection" der 
STM32-Controller?

Im Kern geht es mir darum meinen Code zu schützen..

[STM-Bastler (Gast)]

Hallo,

das Programm "ST-LINK utility" habe ich installiert und kann nun
den "Device Memory" vom STM32F051 auslesen und speichern.

Ich habe ein sehr einfachen Testcode (Toggle LED) geschrieben den
ich auslese und wieder auf den gelöschten Mikrocontroller laden möchte.

Das klappt leider nicht, obwohl das Programm "ST-LINK utility" die
grüne Meldung "Memory programmed in 0s and 858ms" ausgibt.

Auch sonst gibt es keine Fehlermeldungen.

Nur mein Testcode "Toggle LED" läuft eben nicht -> LED aus.

Flashe ich es mit Coocox erneut blinkt die LED. Auch wenn ich das
Orginal hex. oder .bin File von Coocox nehme und es mit ST-LINK utility
flashe funktioniert es.

Wieso funktioniert der 1:1 ausgelesene Code nicht??

[Random .. (thorstendb)]

STM-Bastler schrieb:
> BTW: Hast du Erfahrungen mit der "Read-out-protection" der
> STM32-Controller?
>
> Im Kern geht es mir darum meinen Code zu schützen..

Flash Option Bytes

Beim Atmel SAM3X sperre ich den kompletten JTAG/SW Port, so dass 
überhaupt kein Zugriff per Debugger mehr möglich ist, ausser per Mass 
Erase Pin an der MCU.

[STM-Bastler (Gast)]

Hallo Random,

"Flash Option Bytes" habe ich gefunden in der Software. Damit
kann die "Read Out Protection" gesetzt werden..
Klingt erstmal vielversprechend.

Mein Problem ist zunächst jedoch, dass ich unter Laborbedingungen meinen
Code zwar irgendwie auslesen, aber nicht lauffähig wieder zurückspielen 
kann.
Gibt es hierzu Erfahrungen?

Ich möchte das Verfahren ja irgendwie testen.

[spontan (Gast)]

>Ich möchte das Verfahren ja irgendwie testen.

Zu was?

Dein Vorhanden klingt irgendwie anders.

[Karl H. (kbuchegg)]

Hat denn das Transferprogramm kein "Verify", welches den tatsächlichen 
Speicherinhalt mit dem von dir geladenen Hex-File vergleicht?

[STM-Bastler (Gast)]

spontan schrieb:
> Zu was?

Test1
1. Controller auslesen
2. Controller löschen
3. Gelöschten Controller mit ausgelesenem hex/bin File beschreiben

Test2
1. Controller beschreiben
2. read out setzen
3. Versuchen den Controller auszulesen

Dachte mir, das wäre ne logische Vorgehensweise..

Karl Heinz schrieb:
> Hat denn das Transferprogramm kein "Verify", welches den Speicherinhalt
> mit dem von dir geladenen Hex-File vergleicht?

Doch. Sagt mir auch immer "Verification...OK" nach dem Flashen.


Mit dem STM32 ST-LINK Utility können auch zwei Files miteinander 
vergleichen werden.
Und es sind tatsächlich Unterschiede da zwischen dem Orginal 
Coocox-Hex-File und dem Ausgelesenen Hex-File.

Wird der Controller vielleicht nicht zu 100% ausgelesen?

[Mike R. (thesealion)]

STM-Bastler schrieb:

> Wird der Controller vielleicht nicht zu 100% ausgelesen?

Das wird dein "Problem" sein. Beim ST-Link Tool kannst du einstellen,
wie viele Daten und von welcher Adresse er diese Lesen soll.
Wenn du hier nicht genug liest, ist dein Programm hinterher natürlich 
nicht lauffähig.

Das speichern speichert dann einfach nur den Bereich, den du ausgelesen 
hast.

Mike

[STM-Bastler (Gast)]

Hallo Mike,

du hast mich auf die Lösung des Problems gebracht:

Das "ST-LINK Utility" liest das lauffähige Programm von der Adresse
0x08000000 mit der Größe 0x0808 aus -> siehe Bild "a.png"
ST-LINK Utility hat diese Einstellungen von "Adress" und "Size" selber 
gesetzt.
Wenn dieses ausgelesene File nun wieder aufgespielt wird, fuktioniert es 
nicht!

Erweitert man die Größe manuell auf z.B. 0x0812 -> siehe Bild "b.png"
funktioniert das ausgelesene Programm beim erneuten Flashen!

Danke für die Hilfen!

Jetzt kann ich die "Read-Out-Protection" testen. Vielleicht muss
ich mich dann hier nochmal melden ;-)

[Route_66 H. (route_66)]

STM-Bastler schrieb:
> Jetzt kann ich die "Read-Out-Protection" testen.

Zeifelst Du an den Herstellerangaben oder willst Du nur wissen, ob Du 
die Entwicklungsumgebung  die Programmiersoftware  die Hardware 
richtig benutzt?

[Schreiber (Gast)]

STM-Bastler schrieb:
> Jetzt kann ich die "Read-Out-Protection" testen.

Ich dachte immer die Readout-Protection testet man mit etwas UV-Licht...

...bei geöffnetem Gehäuse...

...und mit einem guten Stereomikroskop und einer ruhigen Hand bei 
Malerarbeiten...

[Mike R. (thesealion)]

Route 66 schrieb:
> STM-Bastler schrieb:
>> Jetzt kann ich die "Read-Out-Protection" testen.
>
> Zeifelst Du an den Herstellerangaben oder willst Du nur wissen, ob Du
> die Entwicklungsumgebung  die Programmiersoftware  die Hardware
> richtig benutzt?

Das schöne bei den STM Controllern ist, das man die ReadOut Protection 
auch innerhalb der Firmware testen und setzen kann (löschen hab ich noch 
nicht probiert :)

Und zu mindestens zu diesem Zweck möchte man sicher schon testen, ob die 
eigenen Routinen funktionieren.

[STM-Bastler (Gast)]

Route 66 schrieb:
> Zeifelst Du an den Herstellerangaben oder willst Du nur wissen, ob Du
> die Entwicklungsumgebung  die Programmiersoftware  die Hardware
> richtig benutzt?

Na ja, bis heute habe ich gedacht das ich die Einstellungen
der Read-Out-Protection selber in meinem C-Code konfigurieren und
einschalten muss.
Es gibt hierzu ein Beispiel vom Hersteller -> stm32f0xx_flash.c
Nicht gerade übersichtlich. Da wollte ich wissen ob meine Befehle
im Programm funktionieren.

Offensichtlich sieht das "ST-LINK Utility" eine einfache Möglichkeit
diese Einstellungen vorzunehmen, ohne sich selber Code aus den Fingern
saugen zu müssen :-)

Oder bin ich wieder auf dem Holzweg?

[Schreiber (Gast)]

Mike R. schrieb:
> Das schöne bei den STM Controllern ist, das man die ReadOut Protection
> auch innerhalb der Firmware testen und setzen kann (löschen hab ich noch
> nicht probiert :)

allerdings ist die Readout-Protection erfahrungsgemäß bei den meisten 
µCs weitestgehend wirkungslos, da man das zuständige Bit problemlos 
löschen kann.

[Mike R. (thesealion)]

Das ST-Link Tool kann das Flags auch per Hand setzten. Aber im eigenen 
Quelltext ist das ganze in sofern sicherer, als das es nicht vergessen 
werden kann.


Schreiber schrieb:
> allerdings ist die Readout-Protection erfahrungsgemäß bei den meisten
> µCs weitestgehend wirkungslos, da man das zuständige Bit problemlos
> löschen kann.

Meiner Erfahrung nach ist das bei ST schon recht gut gelöst. Du kannst 
das Bit zwar problemlos löschen, der Controller löscht dann aber den 
Flash auch gleich mit :-)

[STM-Bastler (Gast)]

Mike R. schrieb:
> Meiner Erfahrung nach ist das bei ST schon recht gut gelöst. Du kannst
> das Bit zwar problemlos löschen, der Controller löscht dann aber den
> Flash auch gleich mit :-)

Jap.. Gerade getestet. Schon ab Level 1 geht nichts mehr mit auslesen. 
Es kann zwar der Schutz deaktivieren werden..aber wie Mike schon sagte 
ist der Code dann auch weg ;-)

Ich glaube bei Level 2 geht auch nichts mehr mit Schutz deaktivieren. 
Der
Controller ist dann zu. Das habe ich aber nicht getestet..

Ich werde mir trotzdem mal eine kleine lib für "Read-out-protection" 
schreiben..

[Schreiber (Gast)]

Mike R. schrieb:
> Schreiber schrieb:
>> allerdings ist die Readout-Protection erfahrungsgemäß bei den meisten
>> µCs weitestgehend wirkungslos, da man das zuständige Bit problemlos
>> löschen kann.
>
> Meiner Erfahrung nach ist das bei ST schon recht gut gelöst. Du kannst
> das Bit zwar problemlos löschen, der Controller löscht dann aber den
> Flash auch gleich mit :-)

stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen:

Schreiber schrieb:
> Ich dachte immer die Readout-Protection testet man mit etwas UV-Licht...
> ...bei geöffnetem Gehäuse...
> ...und mit einem guten Stereomikroskop und einer ruhigen Hand bei
> Malerarbeiten...

dass es nicht im Datenblatt steht heißt eben nicht, dass es nicht geht!

[Steffen R. (steffen_rose)]

Schreiber schrieb:
> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen:

Von außen ohne Zugriff auf das RAM zu haben, um von dort ein Programm 
einzuschleusen?

[;) (Gast)]

Route 66 schrieb:
> STM-Bastler schrieb:
>> Jetzt kann ich die "Read-Out-Protection" testen.
>
> Zeifelst Du an den Herstellerangaben oder willst Du nur wissen, ob Du
> die Entwicklungsumgebung  die Programmiersoftware  die Hardware
> richtig benutzt?

Vertrauen ist gut - Kontrolle ist einfach besser!
Das sehe ich genauso - wie STM-Bastler und würde auch erst alles 
durchtesten bevor die Firmware vermarktet wird.

;)

[Pascal (Gast)]

Schreiber schrieb:
> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen:

Wie geht das?

[Markus M. (mmvisual)]

STM-Bastler schrieb:
> Ich glaube bei Level 2 geht auch nichts mehr mit Schutz deaktivieren.
> Der Controller ist dann zu. Das habe ich aber nicht getestet..

Ich habe mal zufällig Mode 2 anstatt Mode 1 verwendet.
Ergebnis: Ich durfte den Chip runter löten und wegwerfen :-(

Mode 2 funktioniert somit auch zuverlässig.

[Mike R. (thesealion)]

Schreiber schrieb:

> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen:

Dann klär uns doch mal auf, wie das geht.

[STM-Bastler (Gast)]

Guten Morgen,

Mike R. schrieb:
> Das ST-Link Tool kann das Flags auch per Hand setzten. Aber im eigenen
> Quelltext ist das ganze in sofern sicherer, als das es nicht vergessen
> werden kann.

Ich möchte das auch gerne im Quelltext realisieren. Nun habe ich mich an
das Verfahren in der stm32f0xx_flash.c gehalten.

Klappt natürlich nicht. Ich habe den Verdacht, dass ich es mir wieder zu
einfach vorstelle.

Wenn ich das so programmiere ist mein "LED-Toggle-Programm" nicht
lauffähig..

Kann mir jemand mal einen Tipp geben? Mike?

[Mike R. (thesealion)]

Ich gehe mal davon aus, dass du die Library von ST benutzt, meine 
Routinen besieren allerdings noch auf der alten Version, von daher hier 
mal der komplette Quelltext, der bei mir funktioniert:

als erstes ein unlock

void FLASH_Unlock(void)
{
  /* Authorize the FPEC of Bank1 Access */
  FLASH->KEYR = FLASH_KEY1;
  FLASH->KEYR = FLASH_KEY2;

#ifdef STM32F10X_XL
  /* Authorize the FPEC of Bank2 Access */
  FLASH->KEYR2 = FLASH_KEY1;
  FLASH->KEYR2 = FLASH_KEY2;
#endif /* STM32F10X_XL */
}

und dann das setzen

/**
  * @brief  Enables or disables the read out protection.
  * @note   If the user has already programmed the other option bytes before calling 
  *   this function, he must re-program them since this function erases all option bytes.
  * @note   This function can be used for all STM32F10x devices.
  * @param  Newstate: new state of the ReadOut Protection.
  *   This parameter can be: ENABLE or DISABLE.
  * @retval FLASH Status: The returned value can be: FLASH_ERROR_PG,
  *   FLASH_ERROR_WRP, FLASH_COMPLETE or FLASH_TIMEOUT.
  */
FLASH_Status FLASH_ReadOutProtection(FunctionalState NewState)
{
  FLASH_Status status = FLASH_COMPLETE;
  /* Check the parameters */
  assert_param(IS_FUNCTIONAL_STATE(NewState));
  status = FLASH_WaitForLastOperation(EraseTimeout);
  if(status == FLASH_COMPLETE)
  {
    /* Authorizes the small information block programming */
    FLASH->OPTKEYR = FLASH_KEY1;
    FLASH->OPTKEYR = FLASH_KEY2;
    FLASH->CR |= CR_OPTER_Set;
    FLASH->CR |= CR_STRT_Set;
    /* Wait for last operation to be completed */
    status = FLASH_WaitForLastOperation(EraseTimeout);
    if(status == FLASH_COMPLETE)
    {
      /* if the erase operation is completed, disable the OPTER Bit */
      FLASH->CR &= CR_OPTER_Reset;
      /* Enable the Option Bytes Programming operation */
      FLASH->CR |= CR_OPTPG_Set; 
      if(NewState != DISABLE)
      {
        OB->RDP = 0x00;
      }
      else
      {
        OB->RDP = RDP_Key;  
      }
      /* Wait for last operation to be completed */
      status = FLASH_WaitForLastOperation(EraseTimeout); 
    
      if(status != FLASH_TIMEOUT)
      {
        /* if the program operation is completed, disable the OPTPG Bit */
        FLASH->CR &= CR_OPTPG_Reset;
      }
    }
    else 
    {
      if(status != FLASH_TIMEOUT)
      {
        /* Disable the OPTER Bit */
        FLASH->CR &= CR_OPTER_Reset;
      }
    }
  }
  /* Return the protection operation Status */
  return status;       
}

danach resete ich den Controller (weiß aber nicht, ob das unbedingt 
nötig ist)

Was du evtl. auch noch schauen mußt, sind die Clock Einstellungen. Ich 
weiß gerade nicht, ob man eine Clock aktivieren muss, damit man im 
Option Byte schreiben kann.



Mike

[STM-Bastler (Gast)]

Hallo,

danke für deine Routine Mike.

Ich habe jetzt meinen Fehler gefunden.. Denke ich.

Mein Programm hat die Read-Out-Protection schon richtig
gesetzt. JEDESMAL beim Starten des Controllers. Inklusive
eines System-reset. Das Programm ist also nie zum Mainloop
gekommen.

Mit einer Abfrage ob die Read-Out-Protection schon gesetzt ist,
setze ich jetzt nur EINMAL den Schutz. Ab nun überspringt er
das Setzen vom Schutz und vor allem den System-Reset.

Mike R. schrieb:
> danach resete ich den Controller (weiß aber nicht, ob das unbedingt
> nötig ist)

Das macht die Funktion FLASH_OB_Launch(); und ist wohl nötig.

Mike R. schrieb:
> Was du evtl. auch noch schauen mußt, sind die Clock Einstellungen. Ich
> weiß gerade nicht, ob man eine Clock aktivieren muss, damit man im
> Option Byte schreiben kann.

Nein. Läuft bei mir so. Das Datenblatt schreibt was von internem 
RC-Clock.
Ich denke solange da eine Clock aktiv ist, läuft das (...)

Mike R. schrieb:
> Schreiber schrieb:
>
>> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen:
>
> Dann klär uns doch mal auf, wie das geht.

Ich glaube da kommt nichts mehr.

Man findet schon einiges im Netz zum Hacken von Controllern.. Zum Teil 
auch Angebote von Firmen die sich drauf spezialisiert haben.

Ich stelle mal die These auf, dass mit viel Aufwand sowas möglich ist.
Genau wie man in ein Haus einbrechen kann, welches sehr gut geschützt 
ist. Wenn ich mein Haus aber garnicht erst abschließe, sondern alle 
Türen offen lasse, muss der Dieb sich nicht anstrengen was zu klauen.

Für "normale" Programmierer denke ich das es nicht möglich ist den
geschützen Controller auszulesen.

[Steffen R. (steffen_rose)]

STM-Bastler schrieb:
> Ich stelle mal die These auf, dass mit viel Aufwand sowas möglich ist.
> Genau wie man in ein Haus einbrechen kann, welches sehr gut geschützt
> ist. Wenn ich mein Haus aber garnicht erst abschließe, sondern alle
> Türen offen lasse, muss der Dieb sich nicht anstrengen was zu klauen.
>
> Für "normale" Programmierer denke ich das es nicht möglich ist den
> geschützen Controller auszulesen.

Die Frage ist eben, vor wem willst Du Dich schützen. Ist dein Code 
soviel Wert, dass jemand entsprechende Spezialisten beauftragt.

[Schreiber (Gast)]

Mike R. schrieb:
>> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen:
>
> Dann klär uns doch mal auf, wie das geht.

eigentlich ganz einfach:
1. Gehäuse vom Chip öffnen, üblicherweise mit etwas Salpetersäure und 
Aceton
2. betreffendes Bit suchen
3. den rest vom Chip vorsichtig mit schwarzer Farbe bemalen
4. Chip unter UV-Lampe legen, ggf. hierzu schräg stellen/legen
5. Programm mit handelsüblichem Programmiergerät auslsen
6. fertig

Das ganze gibts als Komplettangebot von einigen Dienstleistern für viele 
µCs zu erträglichen Konditionen (ab 500€), kann aber auch in einem 
besser ausgestatteten Bastelkeller/Hobbylabor durchgeführt werden

[STM-Bastler (Gast)]

Steffen Rose schrieb:
> Die Frage ist eben, vor wem willst Du Dich schützen. Ist dein Code
> soviel Wert, dass jemand entsprechende Spezialisten beauftragt.

Nein, der ist nicht so viel Wert. Es wird niemand deswegen einen 
Spezialisten beauftragen. Aber das "Schloß zum Abschließen der Tür" 
kostet mich ja nichts ;-) und somit bleiben die "Gelegenheitsdiebe" 
erfolglos.

Jetzt steht der Code und es funktioniert. Das ist was ich erreichen 
wollte.
Danke euch!

[Bernd K. (prof7bit)]

Mike R. schrieb:
> Schreiber schrieb:
>
>> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen:
>
> Dann klär uns doch mal auf, wie das geht.

Indem Du ein paar Scheine locker machst und dich mit der Firma da: 
http://russiansemiresearch.com/en/service/ in Verbindung setzt.

[Bernd K. (prof7bit)]

STM-Bastler schrieb:
> Für "normale" Programmierer denke ich das es nicht möglich ist den
> geschützen Controller auszulesen.

Es wird ja auch nicht gemacht wenn man Programmierer hat oder gar von 
Programmierern selbst (Programmierer würden sowas nie tun, die nehmen ja 
oft nichtmal fertigen Code selbst wenn er verfügbar ist weil er immer 
schlechter wäre als das was man selber machen könnte) sondern wenn man 
gerade eben KEINE Programmierer hat weil man keine bezahlen will und 
stattdessen lieber kurzerhand das teure Konkurrenzprodukt 1:1 klont.

[Alexander (alecxs)]

Hallo, ich möchte einen STM32 auslesen, bekomme aber nur FFFF heißt das 
ich habe versehentlich das Programm gelöscht? Ich habe lediglich in den 
Option Bytes die Readout Protection auf disabled gestellt, wusste nicht 
dass ich damit den STM32 lösche? wie muss ich die Adresse und Länge 
angeben zum auslesen des Programms? Hab heut zum ersten Mal sowas in der 
Mangel.

[Stefan F. (stefanus)]

Alexander schrieb:
> Readout Protection

Überlege mal welchen Sinn diese Funktion hätte, wenn man sie einfach so 
umgehen könnte.

keinen

[Bauform B. (bauformb)]

Stefan F. schrieb:
> Alexander schrieb:
>> Readout Protection
>
> Überlege mal welchen Sinn diese Funktion hätte, wenn man sie einfach so
> umgehen könnte.

einfach ist relativ, oben wurden ja ein paar einschlägige Firmen und 
Preise erwähnt. Seit 2015 ist auch das billiger geworden, z.B.:

https://blog.kraken.com/post/3662/kraken-identifies-critical-flaw-in-trezor-hardware-wallets/

[Alexander (alecxs)]

verdammmt, ich wollte nur ein Backup machen bevor ich was flashe. egal. 
an welche Adresse muss man das hexfile flashen, oder steht das in der 
Datei selbst? hab es aus diesem Internet heruntergeladen, also irgendwer 
hat das irgendwie schon mal ausgelesen.

[Stefan F. (stefanus)]

Alexander schrieb:
> oder steht das in der Datei selbst?

Die Adressen stehen in der Datei.