STM8S Speicher auslesen bei LOC Bit

Berny schrieb:
> Netzteil versucht die Daten aus dem STM32S005 zu lesen mit einem ST-Link
War da nicht von STM8 die Rede?

> V2, das Read Bit war gesetzt und nach zurück setzen war ohne Warnung das
Das war wohl eher ROP (Read Out Protection). Die Warnung bzw. der 
Hinweis auf die Funktionsweise steht halt im RM0016 - das muss man halt 
lesen, bevor man am offenen Herzen operiert.

> Flasch leer.
Genau so ist das gedacht ...

> Ist es möglich das Flash zu lesen mit anderer Hardware oder so? Ich
Jein. "Offiziell" ist es unmöglich, so ist es jedenfalls von ST gedacht. 
Es gibt aber durchaus erfolgreiche Angriffe auf diesen Ausleseschutz. 
Geht aber nicht mal so im Vorbeigehen.

A. B. schrieb:
>> Ist es möglich das Flash zu lesen mit anderer Hardware oder so? Ich
> Jein. "Offiziell" ist es unmöglich, so ist es jedenfalls von ST gedacht.
> Es gibt aber durchaus erfolgreiche Angriffe auf diesen Ausleseschutz.
> Geht aber nicht mal so im Vorbeigehen.

Hallo A. B. du hast natürlich recht, ist ein STM8S005. Kannst du mich in 
das Verfahren einweihen?

Gruß Berny

Peter D. schrieb:
> Der Entwickler wird ja das Programm nicht so nebenbei in der Kaffeepause
> entwickelt haben und daher es nicht für umme nachbauen lassen wollen.
> Daher hat er eben die Lockbits gesetzt, um einen Diebstahl zu vereiteln.

Hallo Peter, du hast natürlich recht, ich will ja auch nicht den 
Quellcode mit allem drum und dran, sondern nur ein HEX File und das wird 
auch für andere Geräte als Update angeboten.

@ alle: Mit welchem Tool habt ihr bei der Programmierung in C gerne 
gearbeitet?

Gruß  Berny

Berny schrieb:
>
> Hallo A. B. du hast natürlich recht, ist ein STM8S005. Kannst du mich in
> das Verfahren einweihen?

Mit z.B. "Voltage Glitching" kann man eventuell den Leseschutz umgehen.

"STM8 Glitch" als Suchbegriff liefert einige Treffer.

Berny schrieb:
> Hallo A. B. du hast natürlich recht, ist ein STM8S005. Kannst du mich in
> das Verfahren einweihen?

Abgesehen vom dem Hinweis oben auf "STM8 glitch": Die nichtflüchtige 
Konfiguration (u. A. Ausleseschutz) wird bei vielen Controller-Familien 
in einem Teil des normalen Flash gespeichert (teilw. allerdings nicht 
direkt auslesbar/beschreibbar) und unmittelbar nach power-up reset durch 
eine einfache state machine (nicht etwa durch die CPU) in die 
zugehörigen Register kopiert.
Erst diese Registerinhalte sind dann für die Konfiguration maßgebend.
Wenn zu dem passenden Zeitpunkt die Versorgung einbricht, wird die Info 
beim Kopieren verfälscht, mit "Glück" kippt da gerade ein Bit, das den 
Ausleseschutz betrifft ...

Den richtigen Zeitpunkt zu erwischen bedeutet natürlich, dass man lange 
herumprobieren muss, und selbst dann klappt's u. U. nur beim jedem 
tausendsten Versuch.

Die Hersteller könnten das natürlich absichern, indem z. B. das 
Verfälschen eines einzigen Bits nicht reicht sondern z. B. mehrere Bits, 
die nacheinander kopiert werden, nötig wären, aber das bedeutet Aufwand 
...

Z. B. bei den STM32 wird das RDP-Byte zweimal gespeichert, einmal im 
Original, einmal komplementiert, aber dann ist natürlich die Frage, wie 
man bei Nicht-Übereinstimmung verfährt ... Rauchzeichen geben?

Hallo A.B.

Cool und danke für den Tip. Ich versuch es mal auf einem Evalution 
Board.

Bis dann Bernhard