AVR: Lock-Bits - wie sicher?

OP #4412682
Lesenswert?

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!
#4412685
Lesenswert?

@ 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 #4412708
Lesenswert?

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 #4412744
Lesenswert?

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...
#4412747
Lesenswert?

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 #4412961
Lesenswert?

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 #4412981
Lesenswert?

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.
Moderator (Firma: Titel) Persönliche Seite #4413160
Lesenswert?

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...  :-/
OP #4414564
Lesenswert?

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 #4414740
Lesenswert?

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)
OP #4414834
Lesenswert?

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.
#4414854
Lesenswert?

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.
#4414924
Lesenswert?

@  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

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren