mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega Bootloader Lock Bits


Autor: hahgeh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ist es eigentlich möglich die Lock Bits so einzustellen, dass ein 
erneutes Programmieren und Verifizierung über den Bootloader möglich 
ist, ohne dass der Code nachher ausgelesen werden kann?

Die normalen Lockbits müssen ja sowieso beide gesetzt sein, damit ein 
Auslesen über SPI verhindert wird.

Zu den BootLockBits:
Wenn ich alles sperre, außer das Schreiben in die Application Section 
von der Bootloader Section aus, dann kann ich zwar das Auslesen 
verhindern und das Programmieren ermöglichen, ich kann aber nicht mehr 
verifizieren, ob der Code richtig aufgespielt wurde. (höchstens noch 
beim ersten Mal, wenn ich die BootLockBits nach dem verifizieren setze)
Theoretisch müßte man die BootLockBits zusammen mit dem Code löschen 
können, um sie nach dem verifizieren wieder zu setzen.

Aber so viel ich weiß, kann das dazu erforderliche ChipErase Kommando 
nur über SPI ausgeführt werden.

Gibt es überhaupt eine Lösung für mein Problem?

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Solange Du das LPM in der Applikationssektion nicht sperrst, kann Dein 
Bootloader diese lesen und ausgeben. Der Chip ansich ist über SPI dann 
nicht auslesbar. Deinen Bootloader kannst Du mittels Passwort zum 
Auslesen bewegen. Bootlockbits umschreiben geht immer nur im 
Zusammenhang mit ChipErase.

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe bei einer ähnlichen Aufgabe das Problem per "Verschlüsselung" 
gelöst:
- SPM/LPM Bootsection gesperrt
- SPM/LPM Applicationsection freigegeben
- "further" Programming gesperrt
- Hex-Datei wird mit einem PC-Programm verschlüsselt (hat aber weiterhin 
Hex-Format)
- Bootloader nutzt AVR109-Protokoll
- Daten aus verschlüsselter Hex-Datei werden per AVRProg oder AVRDude 
zum Bootloader übertragen
- Bootloader entschlüsselt und schreibt Inhalt ins Flash
- beim Verify verschlüsselt der Bootloader die Daten aus dem Flash 
wieder bevor sie gesendet werden
- Programmiersoftware vergleicht die verschlüsselten Daten vom 
Bootloader  mit den Daten im verschlüsselten Hex-File

Vorteile:
- Standard-Programmiersoftware nutzbar - man muss nichts extra schreiben 
(z.B. für Passwort), Kunde kann gewohntes Tool nutzen
- Bereits vorhanden Bootloadercode genutzt, nur Verschlüsselungs- und 
Entschlüsselungsfunktion ergänzt - hat Arbeit gespart
- Programmcode ist nie in Klarschrift sichtbar (Datei per e-mail zum 
Kunden, Kopierschutz)
- Verify mit der verschlüsselten hex-Datei jederzeit möglich
- erneutes Programmieren jederzeit möglich
- "Fremde" unverschlüsselte Software kann zwar auf den Controller 
übertragen werden, funktioniert aber nicht, da sie nicht zu "sinnvollem" 
Maschinencode entschlüsselt wird.

Nachteil:
- Bootloadercode wird größer
- Unterschied "verschlüsselt-unverschlüsselt" nicht direkt 
offensichtlich (beides hex-Dateien, Vorgehensweise auf Kundenseite wie 
bei unverschlüsselten Dateien)

Atmel hat auch einige AppNotes betr. Verschlüsselung und Bootloader, 
grade aber nicht erinnerlich, wie die das "Verify-Problem" gelöst haben

Nun denn, viel Prosa. Vielleicht dennoch als Hinweis nützlich.
Martin Thomas

Autor: hahgeh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit der Verschlüsselung hört sich sicher an. Da wird dann aber wohl 
nicht mehr 1 kByte für den Bootloader reichen. Aber es ist wohl die 
einzige Möglichkeit.
Wirklich schade, dass man nicht so ein "Application-Section-Chip-Erase" 
hat.

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

welche Lock-Bits genau muss ich denn setzen, damit das Auslesen des 
Programmes  verhindert wird?

Beim Atmega 2561 würd ich jetzt nach Datenblatt LB-Mode 3 setzen.
"Further programming and verification is disabled...."

Bei den Bits des BLB Modes bin ich mir unsicher, was die Auswirkungen 
auf Interrupts betrifft.

mfg

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.