Gast
#4037826
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?
Gast
#4037886
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
Gast
#4037943
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..
Gast
#4038279
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??
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.
Gast
#4038318
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.
Gast
#4038322
>Ich möchte das Verfahren ja irgendwie testen.
Zu was?
Dein Vorhanden klingt irgendwie anders.
Hat denn das Transferprogramm kein "Verify", welches den tatsächlichen Speicherinhalt mit dem von dir geladenen Hex-File vergleicht?
Gast
#4038340
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?
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
Angehängte Dateien:
-
Tool.PNG
(1,9 KB)
Gast
#4038630
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 ;-)
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?
Gast
#4038643
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...
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.
Gast
#4038678
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?
Gast
#4038689
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.
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 :-)
Gast
#4038984
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..
Gast
#4039001
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!
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
#4039109
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. ;)
Gast
#4039145
Schreiber schrieb: > stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen: Wie geht das?
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.
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.
Gast
#4039792
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?
Angehängte Dateien:
-
c.PNG
(8,6 KB)
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
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
und dann das setzen
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
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
Gast
#4045799
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.
Angehängte Dateien:
-
d.PNG
(4,6 KB)
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.
Gast
#4046045
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
Gast
#4046136
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!
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.
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.
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.
Angehängte Dateien:
-
STM32_ST-LINK_Utility.jpg
(190 KB)
Gast
#7426241
Readout Protection
Überlege mal welchen Sinn diese Funktion hätte, wenn man sie einfach so umgehen könnte.
keinen
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/
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.
Gast
#7426268
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.
Hallo Alexander,
wie hast du das hin bekommen? Ich will einen STM32 mit aktivieren RDP Level 2 lediglich neu flashen, daher ist es OK, wenn der Flash bei der Aktion gelöscht wird. Hintergrund ist ein Verdrahtungsfehler am Boot0, welcher sich zwar mit Readout-Protection Level 2 umgehen lässt mit den entsprechenden Nachteilen.
Beste Grüße
Uwe
Gast
#7544842
Überlege mal welchen Sinn diese Funktion hätte, wenn man sie einfach so umgehen könnte.
Angeblich ist das gaz einfach:
eigentlich ganz einfach ... 2. betreffendes Bit suchen 3. den rest vom Chip vorsichtig mit schwarzer Farbe bemalen kann in einem besser ausgestatteten Bastelkeller/Hobbylabor durchgeführt werden
Dem hatte noch niemand widersprochen, was ich hiermit nachhole:
Das das so einfach geht, bezweifle ich. Wie malt man denn schwarze Farbe auf einzelne Bits? Mit einem Schweineborsten-Pinsel?
Das ganze gibts als Komplettangebot von einigen Dienstleistern für viele µCs zu erträglichen Konditionen (ab 500€)
Aktuell ab $2900 für STM32. Ich fürchte allerdings, dass die das Geld nehmen und sich dann nie wieder melden.
Da SWD bei mir deaktiviert war, klappte es nur mittels Bootloader. D.h. ich habe solange probiert bis es geklappt hat. STM32 stromlos, 3V3 mit ST Link v2 (Klon) verbunden, in den USB-Port eingesteckt und fast gleichzeitig im ST-Link Utility auf 'Verbinden' geklickt. Mit dem richtigen Timing klappt das. Als es irgendwann verbunden war habe ich dann einfach in den Option Bytes die Readout-Protection deaktiviert, das ging problemlos. Welches Level das war kann ich Dir nicht sagen. Einen Reset-Pin habe ich dazu nicht verlötet.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.