Hallo, ich schriebe hier für einen Internetlosen Mitstudenten. Ich möchte meinen Code vor unerlaubten auslesen schützen, dennoch aber die Möglichkeit haben, ein Update zu machen. Jetzt heißt es aber: Fusebit gesetzt keinen Zugriff, Fusebit gelöscht, Code weg. Wie kann ich das umgehen, oder muß ich bei jeden Update den gesamten Code wieder neu schreiben, d.h. er muß in der Updatedatei enthalten sein? Was ratet Ihr mir? Soweit mein Kollege, ich hoffe, das ich es richtig wiedergegeben habe. Vielen Dank für Eure Mühen, Martin
Salve, wonach Dein Kommilitone sucht, sind Lock-Bits - nicht Fuse-Bits. Was genau meint er mit "Updatedatei"? Mark
sicher meint er das flashen per bootloader über rs232. ich habe auch schon versucht, mich da schlau zu machen. Habe es aber irgendwie nicht so ganz verstanden bzw. zum damaligen Zeitpunkt mich nicht gut genug darum gekümmer: kann ich bei peters bootloader oder per megaload auch "updaten" ohne das quellcode herrausgefischt werden kann?
Also bei der Arbeit mit einem Bootloader helfen die Lock-Bits nicht weiter, da diese ja nur mit einem ChipErase wieder zurückgesetzt werden können. Über SelfProgramming gibt es (meines Wissens nach) keine Möglichkeit, ein einmal gesetztes Lockbit wieder zurückzusetzen oder den Programmspeicher zu beschreiben, wenn der Chip per Lockbit gesperrt ist. Damit kann nach dem Setzen der Lockbist kein Update mehr erfolgen, der Bootloader hat sich ausgesperrt. Man kann zwar den Bootloader selbst vor dem Überschreiben und Auslesen schützenden Schutz der Applikation muss aber der Bootloader selbst übernehmen. Leider bieten alle Bootloaderlösungen, die ich mir bisher angesehen habe, dazu keine Möglichkeit. Wer weiß, wie er den Bootloader startet und das entspechende Programm dazu hat und dieses eine Möglichkeit bietet, den Prozessor auszulesen, der kann das auch tun und erhält den Hex-Code Deiner Applikation (ob er damit viel anfangen kann, steht auf einem anderen Blatt). Will man das verhindern, so muss man einen Bootloader/PC-Programm nehmen, welche kein Zurücklesen unterstützt oder den Bootloder um einen Ausleseschutz erweitern. Letzteres habe ich mit einem Bootloader für AVRProg/AVR910 gemacht. Den Befehl "Lockbit Mode3 setzen" habe ich umgeleitet und schreibe eine Kennung auf das letzte Wort im Flash. Die Befehle zum Zurücklesen funktionieren nur, wenn diese Kennung fehlt. Ist zugegebenermaßen nicht sonderlich orginell, sicherlich auch nicht besonders sicher(?), aber besser als nichts, es funktioniert und was praktikableres habe ich bisher noch nicht gefunden. Jörg
@Jörg "Will man das verhindern, so muss man einen Bootloader/PC-Programm nehmen, welche kein Zurücklesen unterstützt" Mein Bootloader hat keine Auslesefunktion, sondern nur Program und Verify. Allerdings ist das kein Schutz, man kann nämlich an einer vermutlich freien Stelle, eine Ausleseroutine einfügen, die einen Dump über den kompletten Flash sendet. Man müßte also über ein Magic auch das Schreiben blockieren und ein zusätzliches Erase-Kommado einbauen, welches das Magic als letztes löscht. Peter
Mal ne blöde Frage aber wie läuft das Verify ab? Ließt der den Programmcode nicht noch mal aus und schick ihn zurück zum Pc und der vergleicht des dann mit dem was er geschrieben hat? Denn dann hat der Bootloader ja eine Auslesen-Funktion. Und wenn der Bootloader das Verify macht und die Leitung so schlecht ist, dass einen Fehler zweimal verschickt dann wird der µC ja falsch programmiert oder irr ich mich?
Hallo, Also eine der besten Möglichkeiten so etwas sicher hinzubekommen ist die AN avr231 mit aes verschlüsselung. bzw die avr230 mit des Verschlüsselung. Dabei ist es sogar möglich, das Objectfile auszuliefern und den entgültigen Benutzern das Updaten zu erlauben. Wichtig ist ja nur 1. das obj nicht lesbar zu haben, 2. den avr nicht auslesbar zu machen & 3. nicht zu erlauben, dass Teile des flashes mit einem fremden Progrmm überschrieben werdne. Wie's exakt geht steht in der avr230/1. Wies mit dem gcc geht weiss ich leider auch nicht. Siehe mein anderes Post von eben. Schoene Gruesse, Scheintod
@Marc "Und wenn der Bootloader das Verify macht und die Leitung so schlecht ist, dass einen Fehler zweimal verschickt dann wird der µC ja falsch programmiert oder irr ich mich?" Stimmt, das kann passieren, wenn kein Baudratenquarz aber eine hohe Baudrate verwendet wird. Deshalb kann man noch die CRC-16 überprüfen, die über alle empfangenen Bytes berechnet wird. Das Verify ist mit dem Schreiben identisch, bloß daß bei Ungleichheit nicht geschrieben wird, sondern ein Fehler gemeldet wird. Im Prinzip ist damit ein Auslesen möglich, indem man erst nur das 1. Byte verified bis kein Fehler kommt, dann das 2. usw., dauert dann eben etwas. Auf Geheimhaltung habe ich keinen Wert gelegt, da ich den Bootloader nur für die Entwicklung verwende. Peter
Hallöle So, erstmal von meiner Seite Danke und der Seite meines Kommolitonen! Also: Das Projekt ist für die Uni, und ein Präzisionsmessgerät, was die Genauigkeit, nach seiner Aussage, von einer von Ihm entwickelten Differentialgleichung erreicht. Selbst verstanden habe ich das nicht, wir sind zwar im selben Semester, aber in Mathe war er schon immer besser. Nun scheint es so zu sein, daß er die DGL weiterentwickeln will, und somit die Updatefähigkeit erhalten möchte, andererseits natürlich keiner an sein geistiges Wissen dran soll. Und ich sag euch eins, eine Uni ist ein Wissenspool sondersgleichen... Die Updatedatei soll die vorhandene DGL erweitern und, falls nötig, komplett ersetzen können (das ist der Hauptwunsch). Weiterhin soll zweitrangig Anpassungen des Messverfahrens gemacht werden. Ja, das umschriebt die Aufgabe Schöne Grüße, Martin
Hi. Der aes/des bootloader ist genau das ding das er sucht. Bin zwar selber nicht begeistert von übermäßiger Geheimniskrämerei, muss mich gerade aber auch notgedrungen damit beschäftigen. Schau mal hier unter avr231/avr230: http://www.atmel.com/dyn/products/app_notes.asp?family_id=607 Schoene Gruesse, Scheintod
@Martin, "Das Projekt ist für die Uni, und ein Präzisionsmessgerät, was die Genauigkeit, nach seiner Aussage, von einer von Ihm entwickelten Differentialgleichung erreicht." Ein beliebter Anfängerfehler ist es, Genauigkeit mit Auflösung zu verwechseln. Als Praktiker merkt man aber schnell, daß die meisten "genialen" Ideen auch nur mit Wasser kochen. Die Hauptarbeit ist daher nicht die "geniale Idee", sondern der Nachweis, daß sie auch wirklich was taugt. Im Falle der Ermittlung der Genauigkeit gehört sich zu allererst eine fundierte Fehlerabschätzung, d.h. die Ermittlung sämtlicher Fehlerquellen (Temperatur usw.) und deren Einflußverhalten. Und dann der exakte rechnerische Nachweis, daß unter sämtlichen möglichen Worst-Case Bedingungen der maximale Fehler nicht über den Grenzen für die geforderte Genauigkeit liegt. Betrachtet man z.B. eine 10Bit-ADC, so ist ein Fehler von einem LSB nur 0,1% groß (1/1024). Durch nachfolgende Mathematik (z.B. Differentialgleichungen) kann sich bei ungünstigen Koeffizienten dieser Fehler aber bis auf 10% oder mehr aufschaukeln. Peter
Bitte 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.