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
Ach ja und was bedutet LPM und SPM überhaupt? Und was ist eigentlich der Bootloader?
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.
ratlos wrote: [...] > Ich habe im Anhang den Screenshots unserer Settings. [...] > ratlos wo ist der Screenshot?
Angehängte Dateien:
-
settings1.JPG
140 KB
hier ist es, anscheinend gibt es eine Grössenbeschränkung für attachements.
@ratlos: Könntest du mir mal deine Mailadresse geben?
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.
Angehängte Dateien:
-
Erase_Device.png
6,8 KB
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.
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_-_6084_-_en_-_saal_6_-_201412281130_-_uncaging_microchips_-_peter_laackmann_-_marcus_janke.html#video Wie hat Wau Holland schon mal gesagt, "Es gibt keinen Kopierschutz nur einen Kapierschutz".
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.