Hallo, ist es möglich beim ATMega ( z.B. AT1284P ) den Startcode, sprich die main nicht auszuführen, wenn der Code nicht per Bootloader in den Controller eingespielt wurde. Wenn sich kein Bootloader auf dem Controller befindet oder der Code per ISP / JTAG aufgespielt wurde, wird die Anwendung nicht ausgeführt. Wenn es soetwas gibt: wie und wo wird soetwas programmiert??? Gruß Hardy63
Klar gibt es sowas. Wurde dir doch im Mikrokopter Forum bereits gesagt..
Genau das ist ja mein Problem: statt mir vorher das kleingedruckte durchzulesen habe ich einfach drauf losgebastelt und einen eigenen Controller ohne Bootloader verbaut. Nun suche ich eine Möglichkeit für mich, doch noch einen lauffähigen Code auf das Teil zu bekommen ... eben ohne Loader.
Deine Frage macht keinen Sinn. Wenn ein Programm frisch in den µC eingespielt wird, egal ob man dazu den Bootloader benutzt oder ob das über ISP geschieht, wird nach dem C-system-eigenen Startup Code immer main() ausgeführt. Ob Bootloader oder ISP macht keinen Unterschied. Das sind nur unterschiedliche Transportmechanismen (zumindest bei einem der üblichen Bootloader) wie ein Programm in den µC kommt. Was anderes ist es, wenn der Bootloader kein Bootloader im eigentlichen Sinne ist, sondern mehr eine komplette Laufzeitumgebung die schon mehr in Richtung Betriebssystem geht. Dann muss man eben in einen nagelneuen µC erst mal den Bootloader per ISP einspielen und die Fusebits entsprechend richtig stellen, damit er auch ausgeführt wird.
Hallo, danke für die schnellen Antworten. @chavotronic hab ich gemacht ... und vorhin auch eine positve Antwort bekommen. Ich soll das Board mal einschicken und die werden sehen, was sie machen können. Ich dachte schon, ich kann das Teil in die Tonne treten... hoffentlich klappt es. Um es auch klar zu stellen: mir liegt es fern, irgendwie an ihrem code umherzupfuschen oder irgendwelche anderen Sachen zu machen. Hatte nur Panik, alles umsonst zusammengepappt zu haben. @kbuchegg das mit dem ISP und Bootloader ist mir schon irgendwie klar ... einschalten - ein paar Sekunden warten ob Daten gesendet werden, wenn ja empfangen und speichern, wenn nein, startup zur main() Hab mich nun rein interessenhalber auch ein bischen mit dieser Materie auseinander gesetzt. Das mit dem als Bootloader getarnten "Mini-Betriebssystem" leuchtet mir ein, dass soetwas klappen könnte. Was ich nicht raffe ist, wie der nachfolgende Code an seiner Ausführung gehindert werden kann - vor allem wenn kein weiterer Code in der bootloader section vorhanden ist. ist chon merkwürdig. Gruß Hardy
Ich erkläre das Problem mal genauer: Es soll eine Art Kopierschutz sein. Die Firmware eines Mikrocontrollers soll nur auf bestimmten Platinen laufen (Hex Files sind frei verfügbar), und das Hauptprogramm sucht scheinbar nach einem bestimmten Bootloader bzw. sucht nach einem bestimmten Wert in einem bestimmten Adressbereich des Flash Speichers. Der Bootloader (nicht frei verfügbar)ist also sozusagen ein Dongle.
Was heißt hier "die Hex-Files sind frei verfügbar"? Ich vermute einmal, es geht um Updates, die man irgendwo herunterlädt. Ich sehe da nur die Möglichkeit, dass man die HEX-Files verschlüsselt und diese dann nur vom Bootloader entschlüsselt werden können. Das Flash muss man dann natürlich per Fuse gegen auslesen schützen. Ein Hex-File im "Klartext" kann man eigentlich immer disassemblieren und patchen und so eine Dongle-Abfrage umgehen.
> Ich sehe da nur die Möglichkeit, dass man die HEX-Files verschlüsselt > und diese dann nur vom Bootloader entschlüsselt werden können. Das wirds wohl sein.
Detlev T. schrieb: > Ich sehe da nur die Möglichkeit, dass man die HEX-Files verschlüsselt > und diese dann nur vom Bootloader entschlüsselt werden können. Das Flash > muss man dann natürlich per Fuse gegen auslesen schützen. > > Ein Hex-File im "Klartext" kann man eigentlich immer disassemblieren und > patchen und so eine Dongle-Abfrage umgehen. Das ist so nicht ganz korrekt. Auf der einen Seite kann eine Datei zwar verschlüsselt, aber dennoch veränderlich sein. Unter gewissen Voraussetzungen kann man dadurch durch Ausprobieren bestimmter Änderungen an einer Datei eine gewünschte Reaktion auslösen. Im Gegensatz hierzu steht die kryptografische Signatur. Hierbei kann das Programm unverschlüsselt bleiben. Sogar der Bootloader, der die Prüfung der Signatur durchführt, kann jedem Dritten im Quelltext oder in kompilierter Form vorgelegt werden. Dennoch ist es Dritten nicht, veränderte Programme in das Gerät bzw. den Microcontroller einzubringen. Der Trick besteht nämlich darin, ein kryptografisches Schlüsselpaar (z.B. RSA) zu erzeugen. Man berechnet einen starken Hashwert (z.B. SHA-x) über den Update-Inhalt und verschlüsselt diesen mit Hilfe des geheimen Schlüssels des o.a. Schlüsselpaares. Im Bootloader selbst hinterlegt man den öffentlichen Schlüssel. Der Bootloader berechnet dann selbst den Hashwert über den angebotenen Update-Inhalt und vergleicht diesen mit dem mit Hilfe des öffentlichen Schlüssels entschlüsselten Hashwertes, der sich im Header oder Anhang des Update-Inhalt befindet. Stimmen beide Hashwerte überein, gilt der Update-Inhalt als zulässig. Ansonsten wird er abgelehnt. Solch ein Verfahren ist sehr einfach zu implementieren und genügt auch sehr hohen Sicherheitsanforderungen. Die meisten AVRs sind jedoch zu schwach auf der Brust, um die erforderliche Zwischenspeicherung des Update-Inhaltes durchführen zu können. Die SHA- und RSA-Routinen benötigen auch noch etwas Platz und Rechenleistung.
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.