AVR: Lock-Bits - wie sicher?

OP #4412682
Hallo Leute,

wie sicher sind die Lock-Bits um das auslesen des Flashs zu verhindern. 
Können diese nur durch Öffnen des Chip-Gehäuses und neusetzen 
(Elektronstrahlschreiber, ...?) des Lock-Bits zurückgesetzt werden?

- Ich habe von mehreren möglichkeiten gelesen Power-Glitches etc. die es 
ermöglichen den Flash trotz Lock-Bits auszulesen!

Micht interessiert wie sicher grundsätzlich die umsetzung in den Atmel's 
ist und welche möglichen Angriffvektoren es gibt!
@ Patrick L. (crashdemon)

>wie sicher sind die Lock-Bits um das auslesen des Flashs zu verhindern.

Sichder genug, um 90% aller Möchtegernkopierer abzuhalten.

>Können diese nur durch Öffnen des Chip-Gehäuses und neusetzen
>(Elektronstrahlschreiber, ...?) des Lock-Bits zurückgesetzt werden?

So in etwa.

>- Ich habe von mehreren möglichkeiten gelesen Power-Glitches etc. die es
>ermöglichen den Flash trotz Lock-Bits auszulesen!

Kann sein, das geht aber nicht bei allen ICs.

>Micht interessiert wie sicher grundsätzlich die umsetzung in den Atmel's
>ist und welche möglichen Angriffvektoren es gibt!

Warum? Allgemein aus Wissensdurst oder weil du meinst, daß deine 
Firmware besonders schutzwürdig ist?
OP
Falk B. schrieb:
> Warum? Allgemein aus Wissensdurst oder weil du meinst, daß deine
> Firmware besonders schutzwürdig ist?

Mich intereesiert allgemein welche möglichkeiten es gibt seine 
Programmier-Werke zu schützen. Dazu gehört dann auch, wie der Schutz 
umgangen werden kann.

Interessant wäre auch noch. Wenn man den Chip aufmacht, wie würde man 
die Stelle auf dem Chip-Layout finden an der sich die Lock-Bits 
befinden. Wir gehen jetzt mal davon aus so sachen wie REM, tc... sind 
vorhanden (Universitäres Umfeld).

Wie ist das wenn ich einen Bootloader auf einem mit Lock-Bits vor 
auslesen geschützten Chip habe? Kann ich dann trotzdem über den 
Bootloader neue SW in den µC schreiben?
Moderator (Firma: Titel) Persönliche Seite
Patrick L. schrieb:
> welche möglichkeiten es gibt seine Programmier-Werke zu schützen.
Mache in jede Version einen nervigen Fehler. Dann möchte der Kunde bald 
wieder ein Update. Und irgendwann ist es dem Knacker zu blöd. Und er 
programmiert die Software einfach funktionsgleich ohne Fehler nach.

Letztlich wird nämlich meist nicht der Controllerinhalt kopiert, sondern 
die Funktion...
Wie bei allen Schutzmaßnahmen gilt auch hier: Es ist "nur" eine Frage 
des Aufwandes.

Chip abschleifen und direkt auslesen oder Schutzbit zurücksetzen.
Angeblich soll auch eine genaue Analyse der Stromaufnahme hilfreich 
sein.
(Konstruktions-)Fehler ausnutzen.

Also Vorsicht bei der Verwendung von Algorithmen die viele Millionen 
Wert sind.
Gast
Lothar M. schrieb:
> Mache in jede Version einen nervigen Fehler. Dann möchte der Kunde bald
> wieder ein Update. Und irgendwann ist es dem Knacker zu blöd.

Das erklärt Einiges!

Ich dachte immer, das sind Bugs, wenn die SBR-Steuerung das Datum 
verwürfelt, oder die Heizungssteuerung den Drehencoder springen läßt. 
Dabei ist das ein Kopierschutz!

Jetzt fällt es mir wie Schuppen aus den Haaren...
Gast
Lothar M. schrieb:
> Patrick L. schrieb:
>> welche möglichkeiten es gibt seine Programmier-Werke zu schützen.
> Mache in jede Version einen nervigen Fehler. Dann möchte der Kunde bald
> wieder ein Update. Und irgendwann ist es dem Knacker zu blöd. Und er
> programmiert die Software einfach funktionsgleich ohne Fehler nach.

Also zumindest bei den Kunden meines Brötchengebers baut man freiwillig 
keinen Fehler ein. Besonders keinen "nervigen" :-)

@Topic:
Zum Auslesen gibts Spezialisten. Wie den hier:
http://www.ic-cracker.com/
Ob das seriös ist weiß ich nicht. Der Name klingt etwas halbseiden, 
finde ich.

Aber es gibt mehrere solcher Services. Irgenwo wird man wohl fündig 
werden. Ob sich das lohnt steht auf einem anderen Blatt. Man hat dann 
immer noch nur ein Binary, das sich nicht leicht modifizieren lässt.
OP
Das es verschiedene Anbieter gibt die das auslesen des Flash auch bei 
gesetzten Lock-Bits durchführen ist mir klar. Nür mich hätte gerade 
interessiert wie man die stellen in µC-Layout selber findet, wenn man 
ansonsten alle Geräte zur Verfügung habt.
Moderator (Firma: Titel) Persönliche Seite
WehOhWeh schrieb:
> Also zumindest bei den Kunden meines Brötchengebers baut man freiwillig
> keinen Fehler ein. Besonders keinen "nervigen" :-)
Ich bin ziemlich sicher, dass trotzdem einer drin ist. Vielleicht sogar 
ein nerviger... ;-)

Ich habe da z.B. ein Auto, das pingt mich freundlich an, wenn die 
Temperatur von 5 nach 4°C oder gar von 1 nach 0°C fällt. Und das gerne 
auch 20 Mal pro Stunde, wenn die Temperaturschwankungen (z.B. 
abwechselnd Wald und Sonne) es zulassen.
Zum Glück kann man diese "Komforttöne" auch ausschalten. Blöd nur, dass 
dann auch der  Komfortton "Lichtwarnung" ausgeschaltet wird...  :-/
Gast
Patrick L. schrieb:
> Micht interessiert wie sicher grundsätzlich die umsetzung in den Atmel's
> ist und welche möglichen Angriffvektoren es gibt!

Patrick L. schrieb:
> Nür mich hätte gerade
> interessiert wie man die stellen in µC-Layout selber findet, wenn man
> ansonsten alle Geräte zur Verfügung habt.

Du willst es mal ausprobieren - oder?
OP
Dieter F. schrieb:
> Du willst es mal ausprobieren - oder?

Naja ich denke schon. Einen Defekten Chip habe ich hier noch liegen. Ich 
bin mir allerdings noch nicht sicher, wie ich den Layout-Teil finde wo 
die Lock-Bits sind.

Hier hat zumindest schon mal jemand die Die freigelegt:

https://www.youtube.com/watch?v=mT1FStxAVz4

Ansonsten auch gerne wissenschaftlicher:

http://repository.tudelft.nl/assets/uuid:f257d2d7-06b3-41e4-a6ba-51262e187059/Tang_2012.pdf
Gast
Frank M. schrieb:
> Quatsch, aber es wird da keine signifikanten Unterschiede zu den anderen
> Fuse-Bits geben.

War da nicht was, daß die beim AVR extra abgedeckt sind, so daß man 
nicht zerstörungsfrei rankommt? (Wobei zerstörungsfrei jetzt nicht das 
Abfräsen oder Ätzen des Chipgehäuses meint)
Timm T. schrieb:
> War da nicht was, daß die beim AVR extra abgedeckt sind, so daß man
> nicht zerstörungsfrei rankommt?

Bei µCs für sicherheitsrelevante Anwendungen geht man noch weiter. Da 
sind über Fuses und ggf. auch EEPROM oder Flash besondere Strukturen 
drübergelegt, deren Verletzung zur Löschung führt.
OP
Timm T. schrieb:
> War da nicht was, daß die beim AVR extra abgedeckt sind, so daß man
> nicht zerstörungsfrei rankommt? (Wobei zerstörungsfrei jetzt nicht das
> Abfräsen oder Ätzen des Chipgehäuses meint)

Sowas könnte ich mir auch ganz gut vorstellen. Evtl. ist es auch 
irgendwelchen Zwischenlagen? Möglicherweise aber auch noch nicht, weil 
das Prozessmäßig zu aufwendig wäre bei einem nicht Sicherheits-Chip.

Frank M. schrieb:
> Sie leuchten blau.

Naja gar nicht so abwegig. Ich hab mal davon gehört, dass schnell 
schaltende Fet's mitunter Photonen emmitieren. Warscheinlich werden dass 
aber so wenig sein, dass man die nicht so einfach messen kann.
90% der Leute die glauben ihre "Werke" schützen zu müssen haben de facto 
schon den Schutz, weil das neu schreiben einfacher ist als per JTAG den 
Code auszulesen... und man dabei auch meistens besseren Code erhält.

Die Lock-Bits umgeht man in aller Regel so:
Man ätzt ein Loch in das Gehäuse (macht ein Chemielabor so für 100 Euro 
oder so). Dann nimmt man etwas Lack und bepinselt damit die Bereiche in 
denen der Flash ist. Man legt dass dann so lange unter UV-Licht, bis die 
"Lock Bits" gelöscht sind.

Dann kann man das normal auslesen.

Ja, es gibt bessere Techniken... das Problem dabei ist, dass die dann 
wahrscheinlich mehr pro Stück kosten als Deine Programmierarbeit wert 
ist. Grob gesagt speicherst Du dann Deinen Code nur noch im RAM. Du hast 
daran eine Batterie sowie ein undurchsichtiges Kunstharz durch das sehr 
feine Drähte gehen. Werden die Drähte unterbrochen oder kurzgeschlossen 
wird das RAM gelöscht. Zusätzlich hast Du dann noch einen 
Temperatursensor drin, der ungewöhnliche Temperaturen misst und dann 
auch das RAM löscht.
Idealerweise hat man dann die Batterien außen und innen drin noch einen 
Spannungsregler um Angriffe über die Stromversorgung zu vermeiden.
@  A. K. (prx)


>> Das muss man nicht machen. Man muss nur den normalen Flash lokalisieren,
>> den dann abdecken und den Rest löschen.

>Wenn der Hersteller nicht völlig deppert ist, dann ist mindestens eine
>Lage Metall über den Fuses. Oder auch 3 davon (AT91SAM7S).

Eben. Nur weil der Trick vor Jahren mal bei einem uralten PIC 
funktionierte, heißt das noch lange nicht, daß das bei allen (neuen) ICs 
auch so ist.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 10 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.