Hallo zusammen, Die ATmega Chips haben ja alle eine Seriennummer, die avrdude beim Programmieren anzeigt. Gibt es die Möglichkeit, diese Seriennummer mit einem Programm auf dem Chip selber auszulesen? Lässt sich die Seriennummer verändern? Grüße Florian
Die haben eine Seriennummer? Ich dachte immer, die haben nur eine ID, an denen das Programmiergerät erkennen kann, wieviel von jeder Speicherart vorhanden ist. D.h., gleich für alle Chips eines Typs. Diese ID kann man m.E. nicht per Software auslesen.
Man koennte bestimmt mit einem kleinen Script diese ID ins eeprom schreiben, aber das ist wie gesagt keine fortlaufende Nummerierung.
Wie könnte man das forlaufend machen? kann man irgendwie übersmakfe file irgendeine Zahl aus einer Dateiauslesen und die ins eeprom brennen und die Zahl in der Datei um meins erhöhen?
Prinzipiell kannst Du die Nummer auch in´s Flash schreiben und Deine .hex-Datei jedesmal ändern. Es gibt da einige Möglichkeiten. Das EEPROM ist aufgrund eines möglichen Programmfehlers nicht sicher genug, das Flash kann man duch Lock-Bits sichern, so daß die Seriennummer in einem geschützten Bereich untergebracht werden kann.
>Diese ID kann man m.E. nicht per Software auslesen.
Geht glaub' ich schon. Hab's aber noch nicht probiert.
Signature Bytes All Atmel microcontrollers have a 3-byte signature code
which identifies the device. This code can be read in both Serial and
Parallel mode, also when the device is locked. The three bytes reside in
a separate address space.
For the ATmega8515 the signature bytes are:
1. $000: $1E (indicates manufactured by Atmel).
2. $001: $93 (indicates 8KB Flash memory).
3. $002: $06 (indicates ATmega8515 device when $001 is $93).
> This code can be read in both Serial and > Parallel mode Gemeint ist: Von einem Programmer aus. Klar kann der das Auslesen. Wie soll er denn sonst feststellen, welcher µC da drann hängt. Worums hier aber geht: Kann dein eigenes Programm auf dem µC diese Kennung auslesen. Und das kann es nicht. Das ist wie mit den Fuse Bits.
Ich kenne den Speicherbereich nicht, in dem die Teile stehen, normalerweise hat man auch vom Proramm aus Zugriff auf alle Speicherbereiche, auch auf die Fusebits.
FuseBits KÖNNEN vom internen Programm gelesen werden. Sie können allerdings nicht verändert werden. Auch die LockBits können intern gelesen werden. Einige von ihnen sind auch intern änderbar. Siehe Bootloader-Support in den verschidenen AVR-Datenblättern.
> normalerweise hat man auch vom Proramm aus Zugriff auf alle > Speicherbereiche, auch auf die Fusebits Hast du da nähere Informationen dazu? Wäre zwar neu, dass man vom Pgm aus auf die Fusebits rankommt, aber ich lass mich gerne überraschen.
Das Datenblatt - Dein Freund und Helfer. Zumindest bei allen Megas, außerdem bei den neuen Tinys, die "SPM" können.
> kann man irgendwie übersmakfe file irgendeine Zahl aus einer > Dateiauslesen und die ins eeprom brennen und die Zahl in der Datei um > meins erhöhen? Ich würde der Einfachheit halber Datum/Uhrzeit verwenden, wenn die Nummer nicht unbedingt fortlaufend, sondern nur für alle Controller verschieden sein muss. Unter Linux kann man sich z.B. mit 'date +%s' einen 32bit-Integer ausgeben lassen, der die Zahl der Sekunden seit 1.1.1970 00:00:00 angibt.
Hab gerade mal im Tiny13 Datenblatt nachgeschaut, geht tatsächlich: "It is possible to read both the Fuse and Lock bits from software. To read the Lock bits, load the Z-pointer with 0x0001 and set the RFLB and SELFPRGEN bits in SPMCSR. When an LPM instruction is executed within three CPU cycles after the RFLB and SELFPRGEN bits are set in SPMCSR, the value of the Lock bits will be loaded in the destination register." (S.98 Tiny 13) In Sachen Seriennummer: Man könnte einfach in dem Hexcode, den der Assembler oder Compiler erzeugt hat, an einer bestimmten Speicheradresse eine Seriennummer reinschreiben. Dafür reicht ein kleines Perl/Python/Rubyskript. Im AVR-Programm muss man natürlich den Speicherbereich genau festlegen, wo er sich die Seriennummer herholt.
Hi, Danke für eure Antworten, aber mir ging es mehr um eine feste, nicht veränderliche Seriennummer. Hintergrund: Diese Seriennummer wird ins Programm eingebaut und abgefragt. Dadurch weiss das Programm, dass es nicht auf einen anderen Chip kopiert wurde. Da es für wenige, teure Produkte ist, lohnt sich der Aufwand, das jedes Mal im Programm zu ändern. Da man die Lockbits bei den Atmels cracken kann, würde man mit dem Programm auch die eine Seriennummer im Flash oder EEProm mitkopieren. Eine feste, die vielleicht in einem anderen Bereich steht aber nicht.
Florian wrote:
> Da man die Lockbits bei den Atmels cracken kann....
Wie denn?
Es gibt verschiedene Firmen, die das anbieten und dabei unterschiedliche Bugs bei den Atmel-Chips nutzen. Es gibt dazu auch schon einige Diskussionen hier und in anderen Foren. Aber so etwas gehört eigentlich nicht hierher. Wirklich sicher sind wohl nur Secure-Atmels, aber die kriegt ein normal Sterblicher nicht ohne erheblichen Aufwand.
Wenn du Deine SW gegen billiges kopieren schützen willst, dann lass sie etwas Bistiges machen. z.B einen Randomcode erzeugen, diesen über eine Gal jagen mit möglichst schwer nachvollziebaer hw-Chiffriersystem das Prog. macht eine ähnliche Prozedur intern und schickt auch sein Ergebnis auf die Gal diese vergleicht beide Ergebnisse und gibt die Differenz zurück. Damite geht deine SW in eine Tabelle und dort steht ob der Wert zulässig ist. wiederhole diese Prozedur wann immer der Prozessor unausgelastet ist. Wer das entschlüsseln und kopieren kann, kann mehr als Du und bedarf deiner SW nicht mehr.
> Wenn du Deine SW gegen billiges kopieren schützen willst, dann lass > sie etwas Bistiges machen. > z.B einen Randomcode erzeugen, diesen über eine Gal jagen mit möglichst > schwer nachvollziebaer hw-Chiffriersystem das Prog. macht eine ähnliche > Prozedur intern und schickt auch sein Ergebnis auf die Gal diese > vergleicht beide Ergebnisse und gibt die Differenz zurück. Damite geht Wozu der Aufwand? Mit einfachen bis mittelschweren Geschützen sind die Lockbits nicht zu knacken. Und wenn einer den IC aufschleift und per Elektronenmikroskop ausliest, hat er sowieso soviel Geld und KnowHow, dass auch die GAL-Bistiges Methode schnell fällt. > Wer das entschlüsseln und kopieren kann, kann mehr als Du und bedarf > deiner SW nicht mehr. Eben. MfG Falk
Nunja, den Aufbau der Seriennummer kannst / musst du ja selber festlegen. Wenn du die Nummer als Konstante definierst wird sie im Flash abgelegt. So mache ich das. Die Seriennummer wird in meinem Fall als Kennung des Gerätes für die Kommunikation benutzt (es gibt bis zu 256 Slaves und 1 Master). Wenn die Firmware kopiert wird ist immer ein und dieselbe Seriennummer drin und das System funktioniert nicht. ganz einfacher kopierschutz.
@Sonic > Nunja, den Aufbau der Seriennummer kannst / musst du ja selber > festlegen. Wenn du die Nummer als Konstante definierst wird sie im Flash > abgelegt. So mache ich das. Die Seriennummer wird in meinem Fall als > Kennung des Gerätes für die Kommunikation benutzt (es gibt bis zu 256 > Slaves und 1 Master). Wenn die Firmware kopiert wird ist immer ein und > dieselbe Seriennummer drin und das System funktioniert nicht. ganz > einfacher kopierschutz. Ja klar. Und die bösen Kopierer sind auch so dämlich, nachdem sie die Lockbits geknackt haben, nicht einfach mal zwei HEX-Files zu vergleichen. ;-) Leute, ihr seid naiv. MfG Falk
Angeblich soll es möglich sein die Chip ID zu modden, wenn dem so ist progamm rein Chip ID runter modden. Das Prog fragt die modifizierte ID ab.Ist sie nicht richtig modifiziert ist schon im Powerup, Ritze. Am besten schließt der Chip gleich die Portpins der ISP kurz und verbrennt sich mal selbst die Füße. Jedenfalls etwas möglichst gemeines. Der erste chock wäre das kein Programmer weis was wirklich vor ihm liegt. Der zweite das auch das nicht mehr hilft weil das programm einfach wenn es denn gelungen ist es doch zu kopiern es den chip verbruzelt.
...nur mal so als Gedanke, gibt es nicht von diversen Herstellern
S/N-Chips die per I2C am µC hängen können? Soweit ich weiß gibts sogar
RTC's mit einmaliger S/N... Die werden beim Herstellungsprozess mit ner
Laser-ID versehen und sind einmalig... -I think-
Trozdem steht in deinem µC irgendwo "if(mySer = ChipSer){}" ... und das
zur neuen Ser.-Nr. umzumoddeln ist auch kein Akt...
Gruß Micha,
wenn man es so offensichtlich macht dan ists leicht! Aber gemeiner ist auf jedes Lockbit zu verzichten und statt dessen was gemeines auszuhecken, was die Kopie wertlos macht. Das stiftet zum ersten Verwirrung und erfordert im Anschluß eie Analyse welche jeden Rahmen sprengt.
Leute, auf wechem top-secret Militär-Forum sind wir denn hier? Es ist schließlich einfacher einen µC selbst zu programmieren als den riesen Aufwand zu treiben und den Speicher auszulesen. Die Funktion des Teiles zu kopieren geht allemal. Und ich glaube nicht dass hier einer Programme schreibt, die weltweit millionenfach vermarktet werden sollen, oder?
@winne > wenn man es so offensichtlich macht dan ists leicht! > Aber gemeiner ist auf jedes Lockbit zu verzichten und statt dessen was > gemeines auszuhecken, was die Kopie wertlos macht. Das stiftet zum > ersten Verwirrung und erfordert im Anschluß eie Analyse welche jeden > Rahmen sprengt. Ihr seid immer noch naiv. ;-) Ihr habt noch nie Software, geschweig denn Hardware gecrackt. Die Jungs die sowas machen, leben nicht hinterm Mond. Die hier vorgeschlagenen, selbstgestrickten "Methoden" sind alle hundertmal angreifbarer als die Lockbits. MfG Falk
geh mal zu den Hardcore-Freaks für SIM-Karten, Premeriekarten, usw die Arbeiten normaler weise immer Elektronenrastermikroscope.
@Marco: Schon klar dass es die Hardcore-Cracker gibt. Wenn einer meint, meine AVRs aus Freude am Knacken zu analysieren, dann soll er ruhig, habe ich nix gegen. Eine Firma, die es aus Profitgründen als lukrativ ansieht wird's nicht machen, da der Aufwand für illegale Aktionen wie diese gleich dem Aufwand der Entwicklung eines eigenen Systems ist. Außerdem riskiert diese Firma evtl. Klagen.
Es gibt Firmen, die offen Werbung damit machen. Das sind auch nicht irgendwelche Bastler sondern professionell ausgerüstete Labors in Osteuropa und Asien. Links will ich hier nicht nennen, weil ich für solche Leute keine Werbung mache.
Haste Recht, würd' ich auch nicht! Wenn die ihre Energie statt auf's Abkupfern in die Entwicklung stecken würden, wären sie nicht mehr abhängig vom Entwickler. Aber irgendwie ist bei denen die kriminelle Energie größer.
@Marco > geh mal zu den Hardcore-Freaks für SIM-Karten, Premeriekarten, usw > die Arbeiten normaler weise immer Elektronenrastermikroscope. Aber sicher! Ist ja auch sehr lohnend, ne popelige SIM-Karte oder Premierekarte mit so nem Aufwand zzu knacken. MfG Falk P.S. ;-) P.P.S. Der Naivitätspegel bricht hier alle Rekorde.
@Sonic > Wenn die ihre Energie statt auf's Abkupfern in die Entwicklung stecken > würden, wären sie nicht mehr abhängig vom Entwickler. Aber irgendwie ist ???? Das Abwägen zwischen Abkupfern und selber machen ist rein witrschaftlich. Das was einfacher und schneller (= billiger) geht, wird gemacht. Fertig. MfG Falk
Bei dem oben mehrfach genannten Aufwand fürs Abkupfern kann ich auch selbst entwicken. Ist auch nicht aufwändiger oder unwirtschaftlicher.
Florian wrote: > Da es für wenige, teure Produkte ist, lohnt sich der Aufwand, das jedes > Mal im Programm zu ändern. > Da man die Lockbits bei den Atmels cracken kann, würde man mit dem > Programm auch die eine Seriennummer im Flash oder EEProm mitkopieren. > Eine feste, die vielleicht in einem anderen Bereich steht aber nicht. Wenn es nur für wenige, teure Produkte ist: Lohnt es sich da wirklich für einen Konkurrenten das abzukupfern? Das Gerät besteht sicher nicht nur aus einem Atmel und seiner Software. Für mich klingt das nicht gerade nach einem Massenmarkt, der die entsprechende Investition wieder einspielt. Zudem kennt man in so einem begrenzten Markt seine Konkurrenz und kann und muss denen dann eben auch auf die Finger gucken.
Der Wirtschaftszweig der sowas macht nennt sich übrigens "Reverse Engineering" Netter Artikel den ich auf die schnelle gefunden habe: http://www.heise.de/tr/artikel/67856 Allerdings wird sowas bestimmt nicht für Produkte gemacht die hier im Forum entwickelt werden ;) Aber der Angriffspunkt bei der Lösung mit der Seriennummer ist, wie oben schon erwähnt, diese Zeile: "if(mySer = ChipSer){}" Im Assembler-Code schreibt der Cracker einfach statt dem jnz-Befehl ein jmp-Befehl und fertig... Also, setzt lieber die Lockbits und gut ist :) Bis denn
Vor ein paar Jahren habe ich selber Reverse Engineering als Hobby betrieben. Da ging es um Softwaremodding von Nokia Handys (bsw.3310,8210,...). Die ganzen Checksummen und Seriennummern wurden da schon relativ schnell geknackt und das von meist Jugendlichen ohne Bezahlung. Und das alles nur um ein eigenes Menü, andere Textmeldungen und ein Passwort geschützten Posteingang zu bekommen. Mein Tipp: Lockbits setzen. Wer die knackt, der braucht für eine Seriennummer Abfrage eh nur ein paar Stunden. (wenn überhaupt)
gieß' das board doch einfach ein. zusätzlich kannst du noch lockbits setzen und deine seriennummer einbringen. die ehefrau
@ falk Es ist doch so, dass sich cracken nur dort lohnt, wo ich dadurch einen fremden Markt erobern kann. Zum plagiatieren ist ne funktionale Nachempfindung einfacher. Wenn ich jedoch eine Anlage betreibe, welche ein Servicegerät erforder so hängt an jenem Servicegerät ein viel größerer Wartungsmarkt und hier liegt das eigentliche Potential für "reverse Engeniring" denn erst der Wissenklau ermöglicht mir in den fremden Markt einzubrechen. Zur Erklärung ich baue Aufzüge und dort ist das sehr wohl ein Thema, da nicht der Neubau sondern die Wartung der eigentliche Markt ist. Der Neubau wird zu Dumpingpreisen vollzogen um den Wartungsmarkt zu erschließen. Um diesen zu schützen schotten sich die Hersteller im Neubau technologisch ab. Wer da in fremde Reviere einbrechen will muss Industriespionage betreiben und tut es auch. Davon unnabhängig ist es mir immer ein Vergnügen zu testen ob ich hinter das komme, was man vor mir verbergen will. Aber wenn der Aufwand den Nutzen sprengt lohnt es halt nicht und für den genannten Zweck meine ich halt ist das so. Und die lockbits zu knacken, das geht. Wenn aber einer kopieren kann ohne diese Mühe erwartet er nicht mehr viel an Schutz und dann wird er es tun ohne arges zu erwarten. Er wird erst stolpern wenn die Kopie nicht taugt. Hier liegt das Potential eines kreativen Kopierschutzes, welcher gegebenfalls erst nach länger Benutzung zuschlägt. Dann nämlich wenn sich der Kopierer am Ziel wähnt. Ich bin keinesfalls naiv und ich weiß sehr wohl das gegen Häcken kein Kraut gewachsen ist, schon rein technologisch nicht. Der Trick besteht darin den Plagiator zu diskrediteren ohne dass er es bemerkt. Nur das hilft, alles andere ist nur ein schönes Unterhaltunstraining, eine Herausforderung welcher er sich mit Vergnügen stellt. ;-) Ich habe schon vor 20 Jahren meinen Atari zum hacken benutzt um Tapeprogramme auf 5,25 Zolldisks zu bringen oder ins Eprom. Auf ihm kenne ich die Funkton jeder Leitung und sein OS kenne ich heute noch fast auswendig, da ich es zum grössten Teil selbst disassembliert habe um interne Einsprungpunkte zu finden, welche gegen über dem Databecker allesamt um 0x0E verschoben waren, weil ich ne neuere OS Version besaß. Ich brauchte das Wissen um eigene Assemblercode zu erzeugen, welche die OS_Routinen und HW direkt ansprechen können. Andere Sachen lasse ich aus rechtlichen Gründen mal außen vor. Nur soviel, wie es geht ist kein Geheimnis für mich, welchen Aufwand ich betreiben will ist, nicht nur für mich, dabei die entscheidende Frage. MfG Winne
@Winfried Jaeckel > Neubau technologisch ab. Wer da in fremde Reviere einbrechen will muss > Industriespionage betreiben und tut es auch. Echelon sein Dank. Oder man schmeisst es der Konkurrenz von Morgen noch hinterher, so wie im Moment in China. :-( > halt ist das so. Und die lockbits zu knacken, das geht. Wenn aber einer Wie? Und mit welchem Aufwand? > Ich bin keinesfalls naiv und ich weiß sehr wohl das gegen Häcken kein > Kraut gewachsen ist, schon rein technologisch nicht. Naja, Vorsicht. Ist immer eine Frage der Aufwandsabwägung. > um interne Einsprungpunkte zu finden, welche gegen über dem Databecker > allesamt um 0x0E verschoben waren, weil ich ne neuere OS Version besaß. > Ich brauchte das Wissen um eigene Assemblercode zu erzeugen, welche die > OS_Routinen und HW direkt ansprechen können. Andere Sachen lasse ich aus Jaja, die gute alte Zeit. Solche handgestrickten Dinger sind aber nur bei kleinen, überschaubaren Projekten/Programmen gangbar. Lockbits setzten ist 1000mal einfacher und effektiver. > Geheimnis für mich, welchen Aufwand ich betreiben will ist, nicht nur > für mich, dabei die entscheidende Frage. Genau. MFG Falk
Bisher wurden bei fast jedem verbreiteten Chip irgendwelche Schwächen gefunden, die dann doch ein Auslesen des Programms ermöglichen, und zwar OHNE das Gehäuse wegzuätzen und mit Nadeln unterm Mikroskop den Speicher direkt abzufragen. Es gab Chips, die man trotz gesetzter Lockbits auslesen konnte, wenn die Betriebsspannung einen bestimmten Wert unterschreitet (außerhalb der Specs natürlich). Aufwand gegen null. Genauso gab es schon trickreiche Manipulationen mit dem Prozessortakt, das Auswerten von Reaktionszeiten, das Auswerten nicht nur von "low" oder "high" sondern "3.1V" und "3.15V" - mit genügend Zeit und Aufwand findet man wahrscheinlich bei jedem Chip einen kleinen Bug, der das Auslesen oder Löschen der Fuses ohne Löschen des Flash dann doch ermöglicht. Diese Lücken zu finden, ist vielleicht ein großer Aufwand. Sie dann anzuwenden, ein kleiner. Es gibt Experten dafür und einen Markt. Wenn ich 100.000 $ investiere, um eine Lücke zu finden und dann meinen Kunden einen Controller für 1000$ auslesen kann, mache ich ab 100 Anfragen einen Gewinn. Und es geht das Gerücht, daß es inoffizielle Anbieter gibt, die Dir einen AVR für 1000$ auslesen. Chip hin, CD zurück. Ihr seid doch alle naiv ;)
Jetzt wurden ja hier schon ´ne ganze Menge große Töne gespuckt, von denen 80% nur auf Gerüchten beruhen. Wenn es hier jemanden gibt, der einen AVR mit gesetzten Lockbits geknackt hat, ohne ihn aufzuschleifen, sondern nur mit den erwähnten Tricks von wegen Spannung und Takt, dann soll er/sie "hier" schreien und sagen, wie er/sie es gemacht hat. Dann kann man an ATMEL schreiben und einen ordentlichen Report abliefern. Von wegen:"...es soll Leute geben... und ich habe gehört, daß...." ist mir nicht genug, als daß ich die Funktion der Lockbits in Frage stelle. Was meint ihr, was mir mein Nachbar schon alles erzählt hat. Na wenn ich das alles glauben würde...
Das Problem ist halt, daß diese Leute damit gut Geld verdienen können und überhaupt kein Interesse haben, an Atmel zu schreiben. Übrigens gibt es dennoch ausführliche Reports über solche Angriffe, die auch in Forschungslabors von Universitäten schon durchgeführt wurden. Siehe google. Daß Mikrokontroller tatsächlich geknackt werden, steht doch wohl außer Frage.
Atmels Statement dazu ist, dass es nicht möglich ist. Und sie meinen, es sei einfacher und mit weniger Geldaufwand möglich, den Programmierer zu schmieren, als die Lockbits zu knacken. An sich eine gute Einstellung von Atmel auch wenn sie vielleicht etwas vertuschen. Aber würden sie zugeben, dass ihre Produkte unsicher sind, würde jeder Idiot so lange suchen, bis er die Schwachstelle findet. Ich werde auf die Lockbits vertrauen. Sollten dann wieder Klones meiner Produkte auftauchen weiß ich, dass die Lockbits nicht sicher sind.
>Übrigens gibt es dennoch ausführliche Reports über solche Angriffe, die >auch in Forschungslabors von Universitäten schon durchgeführt wurden. Zeigen! Nicht nur drüber reden! >Daß Mikrokontroller tatsächlich geknackt werden, steht doch wohl außer >Frage. Nur über Spannungs und Takt-Tricks? Beweisen!
Sorry es zu wissen genügt mir in diesem Fall. Brauche meine Chips für besseres als sie zu verbruzeln. Aber wenn ich mal in ein paar zig Jahren Rentner bin werde ich vielleicht aus Langer weile auch mal damit anfangen, oder bei nem lohnenden Objekt. Bis dahin schaue ich mir an was sich außerhalb der BB tut und entscheide wie ich die BB am besten simuliere ohne hineinzuschauen. Jede Leitung hat zwei Enden kenne ich die eine Seite, so kenne ich auch die Andere. und jeder Datenburst hat eine Struktur, das liegt in der natur der Sache, welche viel verrät. Nen guter sniffer bringt auch genug zu Tage ;-) Wer weis was er (mit Sucht) sucht findet selbst im rosa Rauschen das Gesuchte. bis dahin winki winki Tinki Winki
@ Winfried Jaeckel > >Wie? Und mit welchem Aufwand? > http://www.progforum.com/showpost.php?p=65659&;... Nix weiter als Gelaber. Ein Fall für die X-Files. MfG Falk
Beitrag #7343494 wurde von einem Moderator gelöscht.
Beitrag #7343514 wurde von einem Moderator gelöscht.
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.