mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Auslesen des *.hex-Files trotz setzen der Lockbits möglich


Autor: ratlos (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Wir haben eine Steuerung für ein Schweisgerät mit einem ATmega32 
realisiert. Bevor wir die Vorserie ausliefern, möchten wir 
sicherstellen, dass sich neimand die Software aus dem uC rauslesen kann.
Wir haben alo den Application Protection Mode 3 (LPM and SPM probhited) 
aktiviert (Lockbits). Das hatte aber keinen Effekt. Mit read konnte das 
Programm problemlos ausgelesen werden. Es gibt in diesem Forum Beiträge, 
die sagen man lese dann nur ein Speicherzuordnungsfile raus. Das stimmt 
aber nicht. Wenn wir das ausgelesene *.hex-File wieder in den Speicher 
brennen läuft das Gerät einwandfrei.

Was also müssen iwr tun, um unsere Anwendung vor den Chinesen zu 
schützen?

P.S. Wir verwenden ISP und ein STK500 zur Programmierung. Als 
Enticklungsumgebung verwenden wir AVR-Studio und den Compiler von 
WinAVR.

vielen Dank für eure Beiträge.

Gruss

ratlos

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr habt vermutlich die Boot-Lockbits mit den Lock-Bits verwechselt. Die 
Boot-Lockbits regeln lediglich den Zugriff per lpm und spm vom 
Bootloader aus. Die dafür zuständigen Lockbits heißen BLB01, BLB02, 
BLB11 und BLB12. Was Ihr ändern müsst sind die Lockbits LB1 und LB2. 
Wenn die beide "0", also programmert sind, dann dürfte kein Lesen mehr 
möglich sein.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ratlos wrote:

> Wir haben alo den Application Protection Mode 3 (LPM and SPM probhited)
> aktiviert (Lockbits). Das hatte aber keinen Effekt. Mit read konnte das
> Programm problemlos ausgelesen werden.

Das ist richtig.
Wie der Name ja schon sagt, ist dieser Mode nur dafür zuständig, wenn 
die Applikation sich selbst modifizieren will.


Du hast insgesamt 3 Lockmöglichkeiten.
Und für optimalen Schutz mußt Du auch alle 3 sperren.

Zusätzlich sollte noch SPI und JTAG gesperrt werden.

Erst dann ist die Software gesichert.


Peter

Autor: ratlos (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hm,
wir wollen aber nur zwei der drei Lockmöglichkeiten sperren. "Further 
Programming" sollte schon möglich sein. Das JTAG haben wir immer 
deaktiviert, aber auch ISP möchten wir zwecks späterer Updates nicht 
deaktivieren.

Ich habe im Anhang den Screenshots unserer Settings.

Könnte sich das jemand anschauen und mir sagen welche Kästchen ich 
anklicken muss, damit das Auslesen der Software verhindert wird. Ein 
weiteres Programmieren sollte aber möglich sein.

herzlichen Dank

ratlos

Autor: ratlos (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja und was bedutet LPM und SPM überhaupt?
Und was ist eigentlich der Bootloader?

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Load Program Memory: lädt ein Byte aus dem Programmspeicher (flash)
Store Program Memory: speichert ein Byte in dnm Programmspeicher

Da der AVR eine Harvard-Architektur ist,also Programm- und Datenspeicher 
getrennt sind und keinen gemeinsamen Bus besitzen,braucht es extra 
Befehle um Daten mit dem Programspeicher auszutauschen.

Autor: Manfred B. (vorbeigeschlendert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ratlos wrote:
[...]
> Ich habe im Anhang den Screenshots unserer Settings.
[...]
> ratlos

wo ist der Screenshot?

Autor: ratlos (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier ist es,
anscheinend gibt es eine Grössenbeschränkung für attachements.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ratlos: Könntest du mir mal deine Mailadresse geben?

Autor: unsichtbarer WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rechtes Fenster, oberste Zeile: "No Memory lock feature enabled" sollte 
gerade nicht ausgewählt werden.

Der Chip ist / sollte nach dem Setzen des Lock-Modes natürlich noch 
programmierbar, allerdings nur indem er komplett gelöscht wird.

>Ach ja und was bedutet LPM und SPM überhaupt?
>Und was ist eigentlich der Bootloader?

Ein Bootloader stellt die Möglichkeit dar, die eigentliche Anwendung zu 
verändern. Dazu wird der Programmspeicher (Flash) in verschiede 
Sektionen unterteilt. Der Bootloader befindet sich dann dort im 
Programmspeicher, wo der Controller nach einem Reset startet. Meist 
wartet der Bootloader dann auf ein spezielles Signal, um die Anwendung 
neu zu schreiben. Wenn dieses Signal innerhalb einer bestimmten Zeit 
nicht auftritt, wird die vorhandene Anwendung gestartet.
LPM und SPM wurden oben schon erklärt...

Autor: Hauke Sattler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hi Ratlos

So wie ich deine Anfrage verstanden habe, wollt  ihr folgendes.
- Das Programm soll nicht ausgelesen werden können
- Ihr habt keinen Bootloader
- das System soll wenn über ISP geupdatet werden

liege ich da richtig?

falls ja, dann wäre die richtige Einstellung
1. Lock bit Protection Mode 1 oder 2
2. Application Protection Mode 2
3. Boot Loader Protection Mode 2
und am Schluss nochmal
4. Lock bit Protection Mode 3

Warum?
"Lock bit Protection Mode 1&2" läßt eurer Brennsoftware noch die 
Möglichkeit euren Code zu verifizieren (zum Prüfen auf Brennfehler).

"Application Protection Mode 2" und "Boot Loader Protection Mode 2" 
untersagt Änderungen an eurer Software durch die Software.
Mode 3 oder Mode 4 sollte man nicht nehmen.
Wenn man Datentabellen (z.B. Kennfelder, Texte, Zeichensätze u.a.) aus 
dem Flash lesen will, wird dies üblicherweise über den Assemblerbefehl 
LPM realisiert. Dieses würde dann bei Mode 3&4 nicht mehr funktionieren.

Ganz zum Schluss sperrt man den AVR dann mit
"Lock bit Protection Mode 3"
Dadurch kann Nichts mehr verändert oder ausgelesen werden.

Zum Umprogrammieren muß dann zuerst ein Chip erase (geht aus über ISP) 
durchgeführt werden. Dieses löscht den Flash und die Lockbits, der Chip 
ist danach wieder programmierfähig (nur halt leer).

bis dann
Hauke

Autor: D a v i d K. (oekel)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Zum Umprogrammieren muß dann zuerst ein Chip erase (geht aus über ISP)

Entschuldigt dass ich den Thread wiederbeleben muss, aber er fasst so 
schön kurz und knapp das zusammen, was ich gebraucht habe, bis auf einen 
Zweizeiler, wie ich das besagte Chip-erase durchführe.

Autor: Thomas O. (kosmos)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
mit der passenden Software z.B. AVR-Studio klickst du einfach auf Erase 
Device nachdem du erst die Signatur ausgelesen hast damit es sich auch 
um den richten µC handelt.

Autor: NerviegerNachfrager (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Hallo,

bin mir jetzt nicht sicher, weil ich kein ATMEL Spezialist bin, aber ist 
es nicht total unsicher, den Pfad über den Programmer offenzulassen?

Gedankenspiel:

Wenn ich jetzt den µC aber programmieren kann, was hindert mich daran, 
ein Programm zu erstellen, das z.B. die UART aufmacht, das in das RAM 
des Controllers zu programmieren und von dort das Flash auszulesen und 
das über die UART wegzuschicken?
Der ATMEGA32 kann doch vom internen RAM exekutieren, oder?

Ich müsste dazu lediglich den Resetvector überschreiben, der Rest des 
Programms bliebe erhalten. Der Resetvector wäre aber leicht zu 
rekonstruieren...

Oder übersehe ich was? Geht das nicht?

Autor: Georg (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
NerviegerNachfrager schrieb:
> Oder übersehe ich was? Geht das nicht?

Wenn man es richtig macht, kann man nur neu programmieren, wenn man 
vorher gelöscht hat. Dann kannst du zwar den Flashinhalt lesen, aber es 
steht halt nichts mehr drin.

Georg

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
NerviegerNachfrager schrieb:
> bin mir jetzt nicht sicher, weil ich kein ATMEL Spezialist bin

So weit, so offensichtlich

> Gedankenspiel:
>
> Wenn ich jetzt den µC aber programmieren kann, was hindert mich daran,
> ein Programm zu erstellen, das z.B. die UART aufmacht, das in das RAM
> des Controllers zu programmieren und von dort das Flash auszulesen und
> das über die UART wegzuschicken?
> Der ATMEGA32 kann doch vom internen RAM exekutieren, oder?

Harvard-Architektur

> Ich müsste dazu lediglich den Resetvector überschreiben, der Rest des
> Programms bliebe erhalten. Der Resetvector wäre aber leicht zu
> rekonstruieren...
>
> Oder übersehe ich was? Geht das nicht?

Du kannst bei gesetzten Lockbits nichts überschreiben. Die einzige 
Möglichkeit, die Lockbits zurückzusetzen, ist ein device erase.

Autor: DerDaniel (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Es ist (bei bekannten Interrupt-Vektoren) möglich diese so zu verändern, 
dass sie auf eine u.u. ungenützte oder unwichtige Seite im Flash spring.
Mit dem richtigen Code verliert man nur bisschen Code der im Kontext des 
Programms meistens erschlossen werden kann.
Mit Glück kann man auch an jede beliebige stelle Springen und verliert 
mit noch einer Portion Glück nur paar Interrupt-Vektoren.

Da Atmel keinen "Zwangs-Erase" vor jedem Flash-Schreiben eingebaut hat, 
ist das leider ein fieses kleines Einfallstor.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
DerDaniel schrieb:
> Da Atmel keinen "Zwangs-Erase" vor jedem Flash-Schreiben eingebaut hat,
> ist das leider ein fieses kleines Einfallstor.

Das ist Quatsch.
Die Lockbits blockieren den Schreibbefehl, so einfach ist das und 
überhaupt nicht wirkungslos.

Ich hab mal ne Schaltung gebaut, die den Erase-Befehl senden konnte und 
nach einer einstellbaren Zeit die VCC auf 0V gesetzt hat.
Bis zu einer bestimmten Zeit passierte garnichts.
Aber einer Zeit wurde zwar der Flash gelöscht (Programm funktionierte 
nicht mehr), aber nicht die Lockbits.
Erst ab einer wesentlich längeren Zeit waren auch die Lockbits gelöscht.
Atmel hat da also einfach einen Sequenzer eingebaut, der die Reihenfolge 
vorgibt.

Autor: DerDaniel (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Die Lockbits blockieren den Schreibbefehl, so einfach ist das und
> überhaupt nicht wirkungslos.

Ich bezog mich auf die von NerviegerNachfrager angesprochene 
Unsicherheit dadurch das schreiben des Flashs weiterhin zuzulassen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
DerDaniel schrieb:
> Ich bezog mich auf die von NerviegerNachfrager angesprochene
> Unsicherheit dadurch das schreiben des Flashs weiterhin zuzulassen.

Das Schreiben kann nur 1-Bits löschen, d.h. bestehenden Code wirst Du 
bestenfalls mit Unsinn beschreiben.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
So oder so werden die Chinesen da nur müde drüber lachen. Wenn die 
wirklich an den Code wollen, können die einfach den Chip "köpfen", den 
Programmflash mit schwarzer Tinte bemalen und die Fuses löschen. 
Kostenpunkt ein paar hundert Euro wenn man schon die Anlagen hat.

Chips macht man wie hier auf:
http://media.ccc.de/browse/congress/2014/31c3_-_60...


Wie hat Wau Holland schon mal gesagt, "Es gibt keinen Kopierschutz nur 
einen Kapierschutz".

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
DerDaniel schrieb:
> Peter Dannegger schrieb:
>> Die Lockbits blockieren den Schreibbefehl, so einfach ist das und
>> überhaupt nicht wirkungslos.
>
> Ich bezog mich auf die von NerviegerNachfrager angesprochene
> Unsicherheit dadurch das schreiben des Flashs weiterhin zuzulassen.

Man kann nicht das Schreiben des Flashs zulassen, aber gleichzeitig das 
Lesen verbieten. Die 3 Eskalationsstufen sind:

1. kein Schutz
2. Schreiben verboten
3. Lesen und Schreiben verboten

und von 2. kommt man zwar noch zu 3. von da aber nur noch per
device erase zu 1.

Autor: DerDaniel (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Oops, mein Fehler, hatte gerade die LPM Sperre im Bootloader im Kopf.
Da geht es aber auf.

Peter Dannegger schrieb:
> Das Schreiben kann nur 1-Bits löschen, d.h. bestehenden Code wirst Du
> bestenfalls mit Unsinn beschreiben.

Z.B. bei unsauberen Interrupt-Vektoren die Statt RJMP/RETI mit 0xFFFF 
belassen werden, kann ich die vorherigen programmierten I-Vs zu NOPs 
machen und dann bei dem einen einen beliebigen Befehl rein schreiben. 
Schlauerweise ein JUMP nach sehr weit hinten, wo ich wieder freien Flash 
vermute.
Man müsste sich jetzt eingehender mit dem genauen Bitmuster der 
verschiedenen Befehle befassen und was man daraus machen kann. Die Idee 
ist aber nach weit hinten zu springen und dort aus leeren Zellen was 
zaubern...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.