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
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.
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
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
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.
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...
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
> 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.
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.
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?
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
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.
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.
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.
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.
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.
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.
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...
