meine 328er werden per Atmel-ICE geflasht. Nun suche ich eine einfache Möglichkeit, beim Flashen einen Timestamp mit einzubringen (wird ins EEPROM geschrieben). Grund: Unverwechselbarkeit der Geräte. Zuerst hatte ich vor, über eine externe Datenbank eine Nummer zu vergeben, aber ein Timestamp erscheint mir einfacher. Er sollte über den ICE mit geflasht werden... Hat jemand damit schon Erfahrung gemacht oder einen Lösungsansatz? Ich bin fürs Erste recht ratlos, wie ich das ohne HW-Zusatz hinbringe..
:
Gesperrt durch Moderator
Du könntest den zeitstempel in eine Datei schreiben und dann avrdude aufrufen, um das File ins EEprom zu übertragen. Mit Linux/Cygwin geht das ganz einfach.
Wie ist es mit der eingebauten timestamp. Mit dem Makro eine Konstante belegen und ab in den Flash-Speicher. Du kannst auch u. A. die Zeit, das Datum oder den Dateinamen extrahieren. Dann nur neu Kompilieren und ab in den Flash-Speicher.
Hanno R. schrieb: > Hat jemand damit schon Erfahrung gemacht oder einen Lösungsansatz? Wie sind denn deine PC-Programmierfähigkeiten? Nicht vorhanden: Vergiss es. Vorhanden: Schreib dir einen Uploader, der mit den entsprechenden Avrdude-Aufrufen, das Flash.hex und das Eeprom.hex auf den Controller schreibt. Das Eeprom.hex muß dabei vor jedem Aufruf mit den aktuellen Zeitwerten neu erstellt werden. Alternativ könntest du den Zeitstempel oder auch jede andere Information in die z.B. letzten 16 Byte des Flash.hex schreiben. Ob das Programm nun mit einem Button bedient wird oder man einen halben Roman in die Tastatur hämmern muß, ist Geschmackssache. Ich bevorzuge für sowas den Button: Button klick Flash.hex flashen Eeprom.hex bearbeiten Eeprom.hex flashen fertig. So ein kleines Tool lässt sich auch ins Avr-Stúdio einbinden und ist dann über Tools verfügbar. Jedenfalls geht das beim alter 4er. Beim aktuellen wahrscheinlich auch. Nur hat wohl noch niemand rausgefunden, wie man das macht.
Hanno R. schrieb: > Nun suche ich eine einfache Möglichkeit, beim Flashen einen Timestamp > mit einzubringen (wird ins EEPROM geschrieben). > Zuerst hatte ich vor, über eine externe Datenbank eine Nummer zu > vergeben, aber ein Timestamp erscheint mir einfacher. Besser noch: eine GUID. Insbesondere dann, wenn der Grund ist: > Grund: Unverwechselbarkeit der Geräte > einen Lösungsansatz? Der Lösungsansatz ist ein "Hook", also eine Stelle im Prozess des Flashens, an der du ein eigenes Stück Code zum Laufen einhängen kannst. Es hängt also vor allem davon ab, mit welcher Software du flashst, nicht von der Hardware. Blöderweise hast du aber genau dazu nix gesagt...
c-hater schrieb: > Der Lösungsansatz ist ein "Hook", also eine Stelle im Prozess des > Flashens, an der du ein eigenes Stück Code zum Laufen einhängen kannst. > > Es hängt also vor allem davon ab, mit welcher Software du flashst, > nicht von der Hardware. Blöderweise hast du aber genau dazu nix > gesagt... Ist schon ein wenig chaotisch: die Libs schreibe ich mit DEV-C++, die Module erst mal mit Arduino (= schnelles testen), größere Sachen mit Atmel Studio 7, die kleineren lass ich meistens im Ardu.
Stefan U. schrieb: > zeitstempel in eine Datei schreiben und dann avrdude > aufrufen, um das File ins EEprom zu übertragen ist zu aufwendig für eine größere Stückzahl. Hier soll der Bestücker die ATmegas vor dem Bestücken programmieren, und der will schnell fertig sein...
Hanno Reimann schrieb: > Ist schon ein wenig chaotisch: die Libs schreibe ich mit DEV-C++, die > Module erst mal mit Arduino (= schnelles testen), größere Sachen mit > Atmel Studio 7, die kleineren lass ich meistens im Ardu. Und wir wissen nun immer noch nicht, wie genau nun dein Flashvorgang aussieht...
Thomas E. schrieb: > Vorhanden: Schreib dir einen Uploader, der mit den entsprechenden > Avrdude-Aufrufen, das Flash.hex und das Eeprom.hex auf den Controller > schreibt. .. leider am Thema vorbei. Der Bestücker will die Atmels vor dem Bestücken programmieren, es muss hier alles superschnell in einem Rutsch durchlaufen und fehlefrei sein. Der Junge hat mich bis jetzt schonb ganz schön getrieben...
c-hater schrieb: > Der Lösungsansatz ist ein "Hook", also eine Stelle im Prozess des > Flashens, an der du ein eigenes Stück Code zum Laufen einhängen kannst. Dieser Ansatz gefällt mir am besten. Möglicherweise kann ich auch den timestamp vom Atmel-ICE benutzen. Damit hab ich mich noch nicht wirklich befasst, bisher flashe ich nur die hexen damit (Kanonen > Spatzen)..
c-hater schrieb: > Und wir wissen nun immer noch nicht, wie genau nun dein Flashvorgang > aussieht... bis jetzt: hex erzeugen, dann mit Atmel Studio via ICE flashen, fertig. Was da drin passiert, hat mich bisher noch nicht interessiert - Hauptsache es funzt.. Also Atmel Studio analysieren..?
Als alternative gibt es einige UUID ICs die per i2c oder one-wire lesbar sind. Ist meistens einfacher und günstiger als Prozesse zu ändern.
Hanno Reimann schrieb: > Der Bestücker will die Atmels vor dem > Bestücken programmieren [...] > Also Atmel Studio analysieren..? Wenn der Bestücker das Atmel-Studio zum Flashen verwendet, könnte das tatsächlich zum Ziel führen. Allerdings halte ich das für sehr, sehr unwahrscheinlich. Weil: > und der will schnell fertig > sein... Dann wird er ganz sicher nicht das Atmel-Studio zu Flashen verwenden, oder er müsste völlig bescheuert sein... Also sollte dir das weitere Vorgehen klar sein: den Bestücker fragen, was er verwendet und am besten auch gleich nach seiner Schnittstelle zum Einbinden exemplar-abhängiger Änderungen im "Flashgut". Die Tools, die Bestücker verwenden, haben alle sowas. Entweder direkt eingebaut oder dadurch, dass das eigentlich Flash-Tool in ein Script eingebettet ist, aus dem sich auch andere Programme aufrufen lassen. Hat dein Bestücker sowas nicht: Such' dir besser einen anderen. Der ist nicht professionell.
Hanno Reimann schrieb: > bis jetzt: hex erzeugen, dann mit Atmel Studio via ICE flashen, fertig. > Was da drin passiert, hat mich bisher noch nicht interessiert - > Hauptsache es funzt.. Also Atmel Studio analysieren..? Nein. atprogram benutzen. Wenn es, wie du sagst über ICE geht:
1 | atprogram -t jtagicemkii -i jtag -d atmega328p write -ee -o 0x100 --values ABCD |
Damit schreibt dein Bestücker Timestamp (ABCD) ins Eeprom ab Adresse 0x100 (über JTAG) oder mit -i isp über ISP. Hoffentlich ist der imstande, etwas entsprechendes zu schreiben...
c-hater schrieb: > Dann wird er ganz sicher nicht das Atmel-Studio zu Flashen verwenden, > oder er müsste völlig bescheuert sein... Er nimmt es her. Weil der Atmel-ICE es verlangt. Er hatte vorher einige schlechte Erfahrungen mit verschiedenen Sticks gemacht. Bescheuert stimmt nicht ganz - er ist ein Nordlicht... c-hater schrieb: > Also sollte dir das weitere Vorgehen klar sein: den Bestücker fragen, > was er verwendet und am besten auch gleich nach seiner Schnittstelle zum > Einbinden exemplar-abhängiger Änderungen im "Flashgut". Wie gesagt: Atmel-Studio und ICE. Damit hat er bisher am wenigsten Ausschuss produziert. Obwohl das bestimmt nicht daran lag... c-hater schrieb: > Die Tools, die Bestücker verwenden, haben alle sowas. Entweder direkt > eingebaut oder dadurch, dass das eigentlich Flash-Tool in ein Script > eingebettet ist, aus dem sich auch andere Programme aufrufen lassen. sowas ähnliches hatte ich ihm auch zur Verfügung gestellt, aber er war nicht überzeugt. Zumal er (immer noch !) Probleme mit den Fuses hat. Was für Tools haben denn die Bestücker? Würde mich interessieren. c-hater schrieb: > Hat dein Bestücker sowas nicht: Such' dir besser einen anderen. Der ist > nicht professionell. Unprofessionell - das stimmt. Aber mein Kunde schwört auf ihn - er sitzt im Nachbardorf.... und das ist ein unschlagbares Argument.
Marc V. schrieb: > ... Damit schreibt dein Bestücker Timestamp (ABCD) ins Eeprom ab Adresse > 0x100 (über JTAG) oder mit -i isp über ISP. Geil. Werde ich nachher gleich mal checken, mal sehen, was es hier für Hürden gibt... Werde berichten.
Wer nimmt denn anschliessend die Geraete in Betrieb? Kannst Du evtl. beim ersten Einschalten eine Seriennummer in den EEPROM schreiben? wendelsberg
wendelsberg schrieb: > Kannst Du evtl. beim ersten Einschalten eine Seriennummer in den EEPROM > schreiben? Das wäre auch mein Vorschlag. Beispielsweise in den Sockel zum Flashen auch noch den UART an den PC durchverbinden. Der AVR wird beim Startup prüfen, ob bereits eine Zeit im EEPROM steht, wenn nein: - AVR sendet per UART kurzen Befehl an den PC, wo ein kleines Programm läuft - PC antwortet mit Uhrzeit - AVR schreibt diese Uhrzeit ins EEPROM - Beim nächsten Startup steht bereits ein Wert != 0 an der EEPROM-Speicherstelle -> PC-Kontaktierung wird übersprungen -> UART kann normal verwendet werden So ein Programm wäre in C beispielsweise mit wenigen Zeilen als Konsolenanwendung realisierbar. Als UART-Bridge könnte man die üblichen FT232RL-Platinchen vom Chinesen verwenden.
:
Bearbeitet durch User
wendelsberg schrieb: > Wer nimmt denn anschliessend die Geraete in Betrieb? Inbetriebnahme erfolgt durch meinen Kunden. Der Bestücker testet Stichproben aus der Produktion - habe Prüfpunkte auf der Platine - mittels Nadeladapter und 3 Spannungsmessungen. Ein umfassendes Prüfprogramm ist ihm zu aufwendig. > Kannst Du evtl. beim ersten Einschalten eine Seriennummer in den EEPROM > schreiben? Beim ersten Einschalten könnte man eine Seriennummer schreiben. Das setzt aber ein kleines Programm im PC voraus (Mini-Datenbank). Wurde schon bis zum Umfallen diskutiert, aber es wird zu aufwendig empfunden. Das war mein erster Vorschlag zu dem Thema. Aber die wollen letztendlich nur noch einen Stichprobentest machen... wenn die ersten 100 durchgelaufen sind.
Robin S. schrieb: > Das wäre auch mein Vorschlag. Beispielsweise in den Sockel zum Flashen > auch noch den UART an den PC durchverbinden. Der AVR wird beim Startup > prüfen, ob bereits eine Zeit im EEPROM steht, ... Ja, den Sockel zu erweitern, wäre gerade noch so machbar (mehr trau ich denen ohne Hilfestellung nicht zu), aber da möchte ich doch gerne (gezwungenermaßen) dabei sein. Hab ich schon öfters erlebt, dass woanders Mist gemacht wird, und Schuld ist immer die Software. Kennt das jemand noch? Leider ist mir das unangenehm weit - von Bayern nach NRW-Nordecke. Soweit möchte ich das nicht treiben... also so einfach wie möglich. Da ist der Grund für den timestamp.
Habe die ganze Geschichte nochmal weiter gedacht: Kommt ein Konkurrent meines Kunden zu diesem Bestücker und drückt ihm ein paar Scheinchen in die Hand für das Schreiben eines Wunsch-Timestamps. Was macht der? Stellt die PC-Uhr um. Super. Die Raubkopie erscheint damit echt. Also muss man hier die Zeit über TCPIP (vom Zeitserver) holen. Dann ist die Geschichte schon etwas erschwert. Außerdem muss vor der Verwendung des Timestamps noch eine Sicherheitskodierung über diesen laufen - man muss ja auch nicht gleich an der Seriennummer erkennen, dass das eine Zeitangabe ist. Somit wird hier doch noch etwas mehr Gehirnschmalz einfließen müssen, und der Aufwand wird auch nicht geringer. Nur gut, dass eine Dekodierung nicht erwünscht wird - die Seriennummer wird (wie seit Jahrzehnten) per Hand auf den Etikettendrucker übertragen, damit ist die Vebindung zum Endkunden bei der Auslieferung fixiert.
Hanno Reimann schrieb: > Also muss man hier die Zeit über TCPIP (vom Zeitserver) holen. Dann ist > die Geschichte schon etwas erschwert. > Außerdem muss vor der Verwendung des Timestamps noch eine > Sicherheitskodierung über diesen laufen - man muss ja auch nicht gleich > an der Seriennummer erkennen, dass das eine Zeitangabe ist. > > Somit wird hier doch noch etwas mehr Gehirnschmalz einfließen müssen, > und der Aufwand wird auch nicht geringer. Aus Erfahrung gesprochen: Je mehr Aufwand mit Schutz getrieben wird, desto weniger ist es das Programm überhaupt wert, geschützt zu werden. Und wenn beide Seiten (Entwickler und Bestücker) nicht einmal imstande sind, das Ganze anständig durchzuziehen, wird es echt tragikomisch...
... und dann hat der Bestücker einen Gang-Programmer und N Geräte haben die selbe Nummer ;-) Bei entsprechender Stückzahl würde ich mir Gedanken über eine Programmierhardware machen. Flash-Chip und RTC drauf. Aufstecken, Spannung dran, (Knopf drücken,) Warten auf grüne (oder rote) LED, Spannung ab, abstecken. Bei Bedarf kann er sich die vergebenen Nummern (und ob Erfolg oder nicht) auch merken. Und wenn am Ende die Anzahl von der gelieferten abweicht, darf der Bestücker ein wenig Zeit mit Dir verbringen und erklären, wie es dazu kommt. Gruß Jobst
Jobst M. schrieb: > Und wenn am Ende die Anzahl von der gelieferten abweicht, darf der > Bestücker ein wenig Zeit mit Dir verbringen und erklären, wie es dazu > kommt. Dann ist es zu spät.
Marc V. schrieb: > Aus Erfahrung gesprochen: > Je mehr Aufwand mit Schutz getrieben wird, desto weniger ist es das > Programm überhaupt wert, geschützt zu werden. Leider ist es in diesem Fall nicht so. Die Konkurrenz (sehr mächtig, Marktführer, weltweite Niederlassungen) hat ein Auge auf dieses Modul. Und sie arbeitet mit äußerst unlauteren Mitteln. Also ist ein gewisser Schutz unumgänglich.
Jobst M. schrieb: > Bei entsprechender Stückzahl würde ich mir Gedanken über eine > Programmierhardware machen. Flash-Chip und RTC drauf. > Aufstecken, Spannung dran, (Knopf drücken,) Warten auf grüne (oder rote) > LED, Spannung ab, abstecken. Dieses Thema wurde schon vor einem Jahr diskutiert und - verworfen. Allerdings hält sich die Stückzahl im Rahmen (1-2k/j) - ich sehe das als noch grenzwertig für einen erhöhten Aufwand. Und leider werden solche Entscheidungen a) aus dem Bauch und b) aus Kostengründen getroffen. "Wer zahlt, schafft an"
Falls möglich, den 328 zu einem 328PB "upgraden". Der enthält schon in der Hardware eine 10-Byte lange ID...
Dein ganzes Konzept ist mir noch sehr unklar. Verstanden habe ich bisher, dass dein Bestücker die Mikrocontroller mit individuellen zeitstempeln ausstatten soll, bevor sie eingelötet werden. Das Ganze soll "irgendwie" vor Raubkopien schützen. Wie werden denn später die Zeitstempel auf Gültigkeit geprüft?
Hanno Reimann schrieb: > Außerdem muss vor der Verwendung des Timestamps noch eine > Sicherheitskodierung über diesen laufen - man muss ja auch nicht gleich > an der Seriennummer erkennen, dass das eine Zeitangabe ist. > > Somit wird hier doch noch etwas mehr Gehirnschmalz einfließen müssen, > und der Aufwand wird auch nicht geringer. Jobst M. schrieb: > Bei entsprechender Stückzahl würde ich mir Gedanken über eine > Programmierhardware machen. Flash-Chip und RTC drauf. Genau. Es ist ein einmaliger Aufwand für die Hardware und entsprechende Software. Mit ESP anstatt RTC hätte man sogar die Kontrolle in Echtzeit und kann z.B. 100 Timestamps vergeben, danach ist (bis auf weiteres) Schluss.
Für das Compile Datum kann man folgendes in den Code einfügen:
1 | #define MCSOFTBUFSIZE 128
|
2 | |
3 | char McSoftVersionBuffer[MCSOFTBUFSIZE]; |
4 | char * position_pointer=m_strcpy(McSoftVersionBuffer,VersionInfo,&McSoftVersionBuffer[MCSOFTBUFSIZE]); |
5 | |
6 | // if compile with the GCC we have data and time information
|
7 | #ifdef __GNUC__
|
8 | |
9 | position_pointer=strcpy(position_pointer,(char *) "compile date: ", &McSoftVersionBuffer[MCSOFTBUFSIZE]); |
10 | position_pointer=strcpy(position_pointer,(char *) __DATE__, &McSoftVersionBuffer[MCSOFTBUFSIZE]); |
11 | position_pointer=strcpy(position_pointer,(char *) " compile time", &McSoftVersionBuffer[MCSOFTBUFSIZE]); |
12 | position_pointer=strcpy(position_pointer,(char *) __TIME__, &McSoftVersionBuffer[MCSOFTBUFSIZE]); |
13 | #endif
|
und zusätzlich ein 1W Seriennummer bestücken ist keine Lösung? https://www.maximintegrated.com/en/products/digital/memory-products/DS2401.html
Marc V. schrieb: > Es ist ein einmaliger Aufwand für die Hardware und entsprechende > Software. Richtig. Ist auch mein Favorit. Allerdings muss ich das Ganze nochmal in einer Diskussion aufwärmen. > Mit ESP anstatt RTC hätte man sogar die Kontrolle in Echtzeit und > kann z.B. 100 Timestamps vergeben, danach ist (bis auf weiteres) > Schluss. Das ist nett, aber die Stückzahl ist um einiges höher. Nehme RTC.
Joachim B. schrieb: > und zusätzlich ein 1W Seriennummer bestücken ist keine Lösung? Nein. Platine wird schon produziert, es ist nur im Rahmen der Programmierung noch was möglich...
chris_ schrieb: > Für das Compile Datum kann man folgendes in den Code einfügen: > #define MCSOFTBUFSIZE 128 > .... Das muss ich mir in einer ruhigen Minute beschnüffeln, gute Idee das..
Hanno Reimann schrieb: >> Mit ESP anstatt RTC hätte man sogar die Kontrolle in Echtzeit und >> kann z.B. 100 Timestamps vergeben, danach ist (bis auf weiteres) >> Schluss. > > Das ist nett, aber die Stückzahl ist um einiges höher. Nehme RTC. LOL. Heute werden 100 Timestamps beantragt und genehmigt. Danach ist Schluss. In einer Woche werden dann wieder 50 Timestamps beantragt und genehmigt. Nach weiteren 4 Wochen werden...
Marc V. schrieb: > Heute werden 100 Timestamps beantragt und genehmigt. > Danach ist Schluss. > > In einer Woche werden dann wieder 50 Timestamps beantragt und > genehmigt. > > Nach weiteren 4 Wochen werden... Hab das schon diskutiert. Naja, der Aufwand... Eigentlich - um den Aufwand auf der Bestückerseite niedrig zu halten - müßte ich für jede Platine eine eigene HEX liefern. Könnte bei mir in der DaBa geführt werden, aber eine Garantie für eine Doppelnummer gibt es hier auch nicht (Bestücker könnte die gleiche HEX mehrfach verwenden..)
Hanno Reimann schrieb: > Hab das schon diskutiert. Naja, der Aufwand... > Eigentlich - um den Aufwand auf der Bestückerseite niedrig zu halten - > müßte ich für jede Platine eine eigene HEX liefern. Könnte bei mir in > der DaBa geführt werden, aber eine Garantie für eine Doppelnummer gibt > es hier auch nicht (Bestücker könnte die gleiche HEX mehrfach > verwenden..) Nein, kann der nicht. 100 Stück sind 100 Stück und nicht 105 oder 110. Und wenn die zu flashende Hexdatei in deinem Programmiergerät steht, noch dazu schön verschlüsselt, kann der gar nichts mehr machen. Updates und ev. ein neues Schlüssel geht wieder über ESP, die täglichen Flashquoten werden zurückgesendet. Kann alles mit verhältnismässig wenig Aufwand realisiert werden.
Marc V. schrieb: > Und wenn die zu flashende Hexdatei in deinem Programmiergerät steht, > noch dazu schön verschlüsselt, kann der gar nichts mehr machen. > Updates und ev. ein neues Schlüssel geht wieder über ESP, die > täglichen Flashquoten werden zurückgesendet. Habe das nochmal diskutiert - es ist inzwischen schon wieder ein anderes Konzept fixiert: die ersten paar hundert macht der Bestücker über Nadeladapter und Atmel-ICE. Geht zu langsam. Dann soll der Chiplieferant das übernehmen (er ist billiger). Wenn ich den erst mal kenne, kann ich die Geschichte mit ihm aushandeln. Aber er steht noch nicht fest... Zum Schluss: recht vielen Dank für die reichlichen Anregungen. Damit möchte ich den Thread schließen.
Nachtrag: habe eine undokumentierte Möglichkeit gefunden, die Seriennummer des Chips vom ATMega328P (nicht PB!) auszulesen, damit ist alles andere plötzlich nicht mehr aktuell. Hier haben wir die unverwechselbare, einmalige SN, die ich eigentlich über "timestamp" erzeugen wollte. Und an dieser Nummer kann keiner mehr rütteln, weil sie werksseitig vergeben und gebrannt wird.. 4 Beispiele (gerade erzeugt): ATMEL328P(1): Signature : 0x1E 0x95 0xF Serial Number : 0x55 0x35 0x35 0x30 0x34 0x33 0xFF 0x14 0x23 0x28 ATMEL328P(2): Signature : 0x1E 0x95 0xF Serial Number : 0x55 0x35 0x35 0x30 0x34 0x33 0xFF 0x14 0x19 0x23 ATMEL328P(3): Signature : 0x1E 0x95 0xF Serial Number : 0x55 0x35 0x35 0x30 0x34 0x33 0xFF 0xF 0x2C 0x16 ATMEL328P(4): Signature : 0x1E 0x95 0xF Serial Number : 0x55 0x35 0x35 0x30 0x34 0x33 0xFF 0x14 0x25 0x27
Hanno Reimann schrieb: > habe eine undokumentierte Möglichkeit gefunden, die Seriennummer des > Chips vom ATMega328P (nicht PB!) auszulesen Nun könntest du uns ja zumindest nicht dumm sterben lassen und verraten, woher du sie liest. ;-) „Undokumentiert“ heißt allerdings auch, dass Atm^H^H^HMicrochip das Verhalten von heute auf morgen ändern kann, ohne dich per PCN oder dergleichen darüber zu informieren.
Jörg W. schrieb: > Nun könntest du uns ja zumindest nicht dumm sterben lassen und > verraten, woher du sie liest. ;-) Schnell im Arduino:
1 | #include <avr/boot.h> |
2 | |
3 | void print_val(char *msg, uint8_t val) |
4 | {
|
5 | Serial.print(msg); |
6 | Serial.println(val, HEX); |
7 | }
|
8 | |
9 | void setup(void) |
10 | {
|
11 | |
12 | Serial.begin(9600); |
13 | while (!Serial) ; |
14 | #define SIGRD 5
|
15 | #if defined(SIGRD) || defined(RSIG)
|
16 | Serial.print("Signature : "); |
17 | for (uint8_t i = 0; i < 5; i += 2) { |
18 | Serial.print(" 0x"); |
19 | Serial.print(boot_signature_byte_get(i), HEX); |
20 | }
|
21 | Serial.println(); |
22 | |
23 | Serial.print("Serial Number : "); |
24 | for (uint8_t i = 14; i < 24; i += 1) { |
25 | Serial.print(" 0x"); |
26 | Serial.print(boot_signature_byte_get(i), HEX); |
27 | }
|
28 | Serial.println(); |
29 | #endif
|
30 | }
|
> „Undokumentiert“ heißt allerdings auch, dass Atm^H^H^HMicrochip das > Verhalten von heute auf morgen ändern kann, ohne dich per PCN oder > dergleichen darüber zu informieren. Wenn das geschieht, setzen wir den 328PB ein. Dort ist es dokumentiert.
OK, also aus den weiteren Bytes der Signature Row.
Hanno Reimann schrieb: > 4 Beispiele (gerade erzeugt): Und sie geben bei jedem Zugriff auch die selben Werte? Sind also nicht Random? Und wenn das Hex-File nun auf einen weiteren Chip (mit weiterer SN) geschrieben wird - wie ist das dann geschützt? BTW: Wäre ich der große Konkurent, der mit allen Mitteln arbeitet, würde ich mir ein Gerät von Dir kaufen und den Chip knacken und auslesen. Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Und sie geben bei jedem Zugriff auch die selben Werte? > Sind also nicht Random? Jedesmal der gleiche Wert > Und wenn das Hex-File nun auf einen weiteren Chip (mit weiterer SN) > geschrieben wird - wie ist das dann geschützt? geschützt ist es nicht, aber beim Hersteller (meinem Kunden) in seiner Datenbank gespeichert. Wenn andere Seriennummern auftreten sollten, dann kann man dem nachgehen Das ist der momentane Stand. Aber noch nicht aller Tage Ende - mein Kunde will alles nochmal überschlafen... > BTW: Wäre ich der große Konkurent, der mit allen Mitteln arbeitet, würde > ich mir ein Gerät von Dir kaufen und den Chip knacken und auslesen. und was nützt das? Natürlich kann man die Hardware kopieren, die Software weniger gut (lockbit ist gesetzt). Selbst wenn, dann hat man nur das hexfile, kann also so ohne Weiteres auch kein reengineering betreiben. Hier geht es auch nicht vorrangig um ein Kopieren, sondern dass man verhindert, dass Fehlfunktionen eingebaut werden. Tritt eine solche auf, dann liefert die Auflistung in der DaBa den Beweis, dass hier kriminelle Kräfte am Werk waren und absichtlich rumgefummelt haben...
Hanno Reimann schrieb: > Wenn andere Seriennummern auftreten sollten, dann kann man dem nachgehen Als Konkurent würde ich das dann ja auch unter meinem Namen verkaufen. Hanno Reimann schrieb: > die Software weniger gut (lockbit ist gesetzt). Deshalb schrieb ich ja 'Chip knacken', das Lockbit ist kein wirkliches Hindernis, wenn man mit großen Mitteln dran geht. Hanno Reimann schrieb: > Hier geht es auch nicht vorrangig um ein Kopieren, sondern dass man > verhindert, dass Fehlfunktionen eingebaut werden. Aha. Oben war es noch die Angst vor einer Kopie. ...? > Tritt eine solche auf, > dann liefert die Auflistung in der DaBa den Beweis, dass hier kriminelle > Kräfte am Werk waren und absichtlich rumgefummelt haben... Nö. Wie denn? Ich habe den Eindruck, als wenn sich dort nicht die richtigen Gedanken gemacht werden oder man keine Ahnung hat. Wenn Ihr vor all dem Angst habt, dann lasst die Boards sockeln und steckt den Chip selber rein oder lasst Euch die unprogrammierten Boards liefern, welche dann per ISP programmiert werden. DAS ist die billigste Lösung vor all den Maßnahmen gegen einen unvertraulichen Bestücker. Gruß Jobst
Hanno Reimann schrieb: > Joachim B. schrieb: >> und zusätzlich ein 1W Seriennummer bestücken ist keine Lösung? > > Nein. Platine wird schon produziert, es ist nur im Rahmen der > Programmierung noch was möglich... das ist aber eine falsche Entwicklung, auch Platinen können ein re-design bekommen, für die erste Serie kann man in Handarbeit an freie Portpins vom Atmel https://www.maximintegrated.com/en/products/digital/memory-products/DS2401.html nachrüsten.
Jobst M. schrieb: > Als Konkurent würde ich das dann ja auch unter meinem Namen verkaufen. Ist zu umständlich. Der Konkurrent hat eigene Lösungen, die er gut beherrscht. Aber das heutige Meeting hat ergeben, dass eine böswillige Veränderung die größte Gefahr darstellt (-> Beseitigen der Konkurrenz). Fehlerhafte Geräte gehen ja an den Hersteller zurück. Dann kann man es abchecken, ob hier was geändert wurde oder ein wahrer Fehler vorliegt.. Jobst M. schrieb: > Aha. Oben war es noch die Angst vor einer Kopie. ...? ich schrieb: vorrangig Jobst M. schrieb: > Wenn Ihr vor all dem Angst habt, dann lasst die Boards sockeln und > steckt den Chip selber rein oder lasst Euch die unprogrammierten Boards > liefern, welche dann per ISP programmiert werden. zu teuer. Jobst M. schrieb: > Ich habe den Eindruck, als wenn sich dort nicht die richtigen Gedanken > gemacht werden oder man keine Ahnung hat. Ich darf weitere Gründe (echte Gründe) nicht anführen...
Joachim B. schrieb: > das ist aber eine falsche Entwicklung, auch Platinen können ein > re-design bekommen, für die erste Serie kann man in Handarbeit... Habe mich entschlossen, die Seriennummer des Chips zu benutzen. Aufwand einige Zeilen Code, sonst nichts. Schau in den Beitrag von 14:34 weiter oben..
Wenn du das Programm vor böswilligen Veränderungen schützen willst, dann bringt eine Prüfsumme und ein Check derselben sicher mehr, als der Zeitstempel.
Hanno Reimann schrieb: > zu teuer. Nein. Das was Du vor hast ist zu teuer und bringt vor allem nichts. Gruß Jobst
Hanno Reimann schrieb: > Habe mich entschlossen, die Seriennummer des Chips zu benutzen. ja ist klar aber nur wenn der immer so bleibt bei jeder Serie! Ich persönlich würde das mit dem Re-Design und extra SerienNr. Chip im Hinterkopf behalten, ist ja auch ein guter Verkaufsgrund, neues verbessertes Modell (scnr)
Joachim B. schrieb: > ja ist klar aber nur wenn der immer so bleibt bei jeder Serie! Bei jeder Serie? Das ist eine Unique ID pro Chip, also letztlich genau das, was oben schon mal als UUID vorgeschlagen worden war. Der Unterschied ist halt nur, dass sie hier von Atmel/Microchip bereits vor der Auslieferung des Bauelements vorgegeben worden ist.
Jörg W. schrieb: > Bei jeder Serie? das war dein Zitat Jörg W. schrieb: > „Undokumentiert“ heißt allerdings auch, dass Atm^H^H^HMicrochip das > Verhalten von heute auf morgen ändern kann, ohne dich per PCN oder > dergleichen darüber zu informieren. mir wäre dann ein echter DS2401 Chip extern lieber
Joachim B. schrieb: > das war dein Zitat Ach, darauf beziehst du dich. Ist doch aber recht einfach: er muss die Nummer ohnehin erfassen, damit wird es beim Auslesen offensichtlich, ob sie vorhanden ist (und unique) oder nicht. Das war ansonsten auch ein caveat emptor von mir: ich gehe nicht ernsthaft davon aus, dass daran irgendwer was ändern wird, insbesondere natürlich angesichts der Tatsache, dass die Nummer bei den neueren PB-Typen tatsächlich dokumentiert worden ist.
Jörg W. schrieb: > Das ist eine Unique ID pro Chip, also letztlich genau das, was oben > schon mal als UUID vorgeschlagen worden war. Der Unterschied ist > halt nur, dass sie hier von Atmel/Microchip bereits vor der > Auslieferung des Bauelements vorgegeben worden ist. Ergänzung zum Thema: Man verwendet UINs in erster Linie, um eine möglichst einfache Identifizierung zu gewährleisten, eine Alternative wäre die Verwendung von Attributen. Oft benutzt man eine Kombination von bedingt eindeutiger Kennung und Attribut, etwa mit Hilfe von Zeitstempeln. Jörg W. schrieb: > Ist doch aber recht einfach: er muss die Nummer ohnehin erfassen, > damit wird es beim Auslesen offensichtlich, ob sie vorhanden ist > (und unique) oder nicht. Eindeutig. > Das war ansonsten auch ein caveat emptor von mir: ich gehe nicht > ernsthaft davon aus, dass daran irgendwer was ändern wird, > insbesondere natürlich angesichts der Tatsache, dass die Nummer bei > den neueren PB-Typen tatsächlich dokumentiert worden ist. Geh ich auch nicht von aus. Ich denke, die UIN ist schon länger im Chip (und Vorgänger), ohne dass hier eine Veröffentlichung erfolgte. Mit Einführung der PB-Serie kann man nun - da dokumentiert - mehr Dollars verlangen. Hab mal Mouser gecheckt, es sind wirklich 35 cent Unterschied. Eine gute Strategie...
Hanno Reimann schrieb: > Mit Einführung der PB-Serie kann man nun - da dokumentiert - mehr > Dollars verlangen. Meiner Erinnerung nach hat die PB-Serie auch sonst noch paar Features mehr, irgendwas an den Timern oder dergleichen. Wobei ich natürlich nicht ausschließen würde, dass es der gleiche Die ist, der nur als „alter“ ATmega328P marketingwirksam für ein paar Cent billiger verkauft wird as der PB. Selbst das Abschalten der nicht mit verkauften Features ist hardwaremäßig kein Thema.
Jörg W. schrieb: > Wobei ich natürlich > nicht ausschließen würde, dass es der gleiche Die ist, der nur als > „alter“ ATmega328P marketingwirksam für ein paar Cent billiger > verkauft wird as der PB. Das soll nach Herstellerangeben nicht stimmen, ist ein neuer die: Compared to existing ATmega328 variants, the following enhancements or additional features are available in ATmega328PB: • PTC - Peripheral Touch Controller. • CFD - Clock Failure Detection mechanism. • OCM1C2 - Output Compare Modulator. • USART start frame detection is available in all sleep modes • Analog Comparator output is available on a pin. This pin is multiplexed with PE0. • Unique device ID to identify the device • Additional USART • Additional SPI • Additional TWI • Additional Timer/Counters Was mich stört, ist die unterschiedliche pin-Belegung:
1 | 32-pin TQFP/MLF package |
2 | Pin ATmega328 ATmega328PB |
3 | 3 GND PE0/ACO |
4 | 6 VCC PE1 |
5 | 19 ADC6 ADC6/PE2 |
6 | 22 ADC7 ADC7/PE3 |
:
Bearbeitet durch Moderator
Hanno R. schrieb: > Das soll nach Herstellerangeben nicht stimmen, ist ein neuer die: Schreibt er doch. Lies Dir seinen Satz nochmal genau durch. Hanno R. schrieb: > Was mich stört, ist die unterschiedliche pin-Belegung: Nutze sie einfach nicht! Lass die Pins eben auf GND und VCC liegen ... Gruß Jobst
:
Bearbeitet durch User
Jörg W. schrieb: > Das war ansonsten auch ein caveat emptor von mir: ich gehe nicht > ernsthaft davon aus, dass daran irgendwer was ändern wird, insbesondere > natürlich angesichts der Tatsache, dass die Nummer bei den neueren > PB-Typen tatsächlich dokumentiert worden ist. Eins fiel mir dazu noch ein: es könnte natürlich allemal passieren, dass dir irgendwann einfach mal jemand ältere ICs vorsetzt, die das Feature noch nicht haben.
Jörg W. schrieb: > Eins fiel mir dazu noch ein: es könnte natürlich allemal passieren, > dass dir irgendwann einfach mal jemand ältere ICs vorsetzt, die das > Feature noch nicht haben. es gibt ja second source Verkäufe für ICs und da bin ich wieder bei Joachim B. schrieb: > mir wäre dann ein echter DS2401 Chip extern lieber
Jörg W. schrieb: > es könnte natürlich allemal passieren, > dass dir irgendwann einfach mal jemand ältere ICs vorsetzt, die das > Feature noch nicht haben. ..das muss abgewartet werden. Jede Neubestellung muss halt darauf gecheckt werden. Ein kleiner Aufwand gegenüber der Einsparung durch die UID. Ich checke in der Software erstmal die UID, wenn das in die Hose geht, dann werden die Teile anderweitig eingesetzt. Oder gehen zurück. Sie sind ja noch nicht verlötet.
:
Bearbeitet durch User
Hanno R. schrieb: > Ich checke in der Software erstmal die UID, wenn das in die Hose geht, > dann werden die Teile anderweitig eingesetzt. Oder gehen zurück. Sie > sind ja noch nicht verlötet. Checken geht, aber selber flashen nicht ? Irgendwas stimmt da nicht...
Jörg W. schrieb: > Meiner Erinnerung nach hat die PB-Serie auch sonst noch paar Features > mehr, irgendwas an den Timern oder dergleichen. Siehe Anhang.
Uhu U. schrieb: > Siehe Anhang. Ich glaube, eine URL hätte genügt ;), zumal's hier ja nicht direkt um die PBs ging.
Marc V. schrieb: > Checken geht, aber selber flashen nicht ? checken über die firmware ja, aber warum flashen, wenn die UID nicht ausgelesen werden kann oder nicht exisitiert? Es gibt noch einige andere Projekt mit den 328er, die die UID nicht benötigen. Die können dann dafür zur Seite gelegt werden. Allerdings glaube ich nicht, dass die UID nicht auslesbar ist. Auch bei älteren Teilen. Die Zukunft wirds zeigen... Ausserdem soll der Lieferant der 328er die Teile flashen - der hat das richtige Equipment dafür und ist dazu noch recht preiswert.
:
Bearbeitet durch User
Hanno R. schrieb: > Ausserdem soll der Lieferant der 328er die Teile flashen - der hat das > richtige Equipment dafür und ist dazu noch recht preiswert. War das nicht der Bestücker ? Hanno Reimann schrieb: > .. leider am Thema vorbei. Der Bestücker will die Atmels vor dem > Bestücken programmieren, Wenn es jetzt plötzlich der Lieferant macht, dann ist alles hinfällig und man braucht die UID gar nicht. Irgendwie stimmt das immer noch nicht...
Marc V. schrieb: > Wenn es jetzt plötzlich der Lieferant macht, dann ist alles hinfällig > und man braucht die UID gar nicht. .. wir brauchen sie noch für einen ganz anderen Zweck, aber das würde hier zu weit führen.
Hanno Reimann schrieb: > Joachim B. schrieb: >> das ist aber eine falsche Entwicklung, auch Platinen können ein >> re-design bekommen, für die erste Serie kann man in Handarbeit... > > Habe mich entschlossen, die Seriennummer des Chips zu benutzen. Aufwand > einige Zeilen Code, sonst nichts. Schau in den Beitrag von 14:34 weiter > oben.. Das wird dir aber nicht viel bringen! Wenn ich dein Konkurrent wäre, kaufe ich deine Hardware, schreibe mir eine eigene Firmware dafür mit Bootcode. Ab einem voreingestellten Trigger lass ich das Ding abschmieren. Der Bootloader löscht mein Programm und um dich zu ärgern setze ich noch zusätzlich die Lockbits für den Ausleseschutz.
fasst vergessen: Die Seriennummer deines Chips ist dabei eindeutig von dir! Wer in der Produktionskette ist dann als Krimineller beschuldigt?
Alex W. schrieb: > Die Seriennummer deines Chips ist dabei eindeutig von dir! wie das?? Der Hersteller des Chips meißelt sie ein. Auch ich, und auch kein anderer, kann sie beeinflussen. Ich kann Deine Gedankengänge nicht verfolgen....
Hanno R. schrieb: > Alex W. schrieb: > Die Seriennummer deines Chips ist dabei eindeutig von dir! > > wie das?? Der Hersteller des Chips meißelt sie ein. Auch ich, und auch > kein anderer, kann sie beeinflussen. Ich kann Deine Gedankengänge nicht > verfolgen.... Eben genau der von dir verwendete IC hat eine Seriennummer die bei dir durch die Produktion gehen. somit ist eindeutig nachvollziehbar dass der Chip von dir stammt weil eben keine Veränderung der Seriennummer möglich ist. und das ist dein Problem. der Inhalt des Chips kann von deinem Konkurrenten geändert werden und spielt somit als wäre das System von dir! und somit hast du keine Möglichkeit herauszufinden ob das ein Fehler von dir ist oder ein böswilliger von deinem Konkurrenten, denn ihr habt die Möglichkeit nicht nachzuvollziehen auch nach dem Verkauf an den Chip irgendetwas verändert wurde
:
Bearbeitet durch User
Alex W. schrieb: > ...der Inhalt des Chips kann von deinem > Konkurrenten geändert werden und spielt somit als wäre das System von > dir! und somit hast du keine Möglichkeit herauszufinden ob das ein > Fehler von dir ist oder ein böswilliger von deinem Konkurrenten... das wäre wirklich kriminell, aber nicht unmöglich. >> Hast Du einen Vorschlag? << Ist sicherlich bei dieser Diskussion auch für etliche andere interessant. Ich meine, irgendwo sollte der Aufwand auch noch vertretbar sein. Wenn der Aufwand zum Schutz den Aufwand der Firmware übersteigt, läuft was schief. Der Firmwareaufwand lag bei ~250 h und hat 2270 endgültige Codezeilen erzeugt. In dieser Zeit sind Labortests, Feldtests und Zertifizierung eingeschlossen. Mein Bauch sagt mir, weitere 10% dieser Zeit sind für Sicherheit nicht zu viel, aber dann ist auch hier Ende der Fahnenstange...
Hanno R. schrieb: > Der Firmwareaufwand lag bei ~250 h und hat 2270 endgültige Codezeilen > erzeugt. In dieser Zeit sind Labortests, Feldtests und Zertifizierung > eingeschlossen. Das wird bestimmt nicht kopiert. Bei so wenig Gesammtaufwand kann ev. nur die Idee geklaut werden, die Firmware entwickelt man in ein paar Tagen oder Wochen selber. Die ganze Diskussion um Schutz war praktisch umsonst.
Marc V. schrieb: > Hanno R. schrieb: >> 2270 endgültige Codezeilen Also ein trivialstes Kleinstprojekt. Erklär einem fähigen Entwicklerteam was das Gerät genau machen soll, gib ihnen ein paar Exemplare davon zum Rumspielen und die entwickeln einen Klon davon (vom gesamten Gerät!) from scratch binnen zwei Wochenenden. Und der kann dann im Gegensatz zum Orginal zusätzlich noch Kaffee kochen und Bier holen und ist 2€ billiger weil keine teuren Atmels verwendet werden sondern billige ARMs. 2270 Zeilen, das kann man ja fast noch in einem Rutsch durchscrollen ohne einmal am Scrollrad umgreifen zu müssen, an guten Tagen hab ich sowas an einem Tag runtergerissen.
:
Bearbeitet durch User
Marc V. schrieb: > Bei so wenig Gesammtaufwand kann ev. nur die Idee geklaut werden, > die Firmware entwickelt man in ein paar Tagen oder Wochen selber. Wer ist "man"? Ich denke, dass DU es bestimmt nicht sein kannst (hab mal einige Deiner threads gelesen..) Aber ich will ja sachlich bleiben. Hier geht es auch nicht um EINE Idee, sondern um einen Schwall von Ideen. Wie will ich Ideen klauen, wenn ich nur ein HEX habe? Aufwand zu hoch dafür. > Die ganze Diskussion um Schutz war praktisch umsonst. Wenn Du nicht weißt, was dahinter steckt, dann schweig bitte still. Auch wenn es für dieses eine Projekt vielleicht nur einen marginalen Nutzen bringt, ist der Nutzen dieser Diskussion doch für viele Teilnehmer und Nurleser nicht unter den Tisch zu kehren. Hier sind viele Ideen zu Tage gekommen, die sicher für andere Projekte die Weichen stellen konnten. Und damit meine ich sicher nicht nur meine Projekte, sondern die vieler anderer auch. Und schon alleine aus diesem Grund war diese Diskussion sehr nützlich und richtungsweisend. Also nochmal vielen Dank an alle Teilnehmer
Bernd K. schrieb: > Erklär einem fähigen Entwicklerteam > was das Gerät genau machen soll, gib ihnen ein paar Exemplare davon zum > Rumspielen und die entwickeln einen Klon davon (vom gesamten Gerät!) > from scratch binnen zwei Wochenenden. Nicht notwendig: Hanno Reimann schrieb: > Der Konkurrent hat eigene Lösungen, die er gut beherrscht. Wenn das Progamm ebenso stümperhaft aufgebaut ist, wie an dessen Schutz herangegangen wird, ist es das Programm gar nicht Wert. Die bisherigen Lösungen verhindern zumindest nicht, dass der Mitbewerber dazwischen hauen kann. Allerdings habe ich mittlerweile den Eindruck, dass Ihr Euch da etwas einbildet, was Ihr vielleicht gerne hättet. Die einzige, zuverlässige und kostengünstige, wenn auch arbeitsintensivere Lösung ist: Selber programmieren der fertigen Boards und Direktvertrieb. Gruß Jobst
Hanno R. schrieb: > Wer ist "man"? Ich denke, dass DU es bestimmt nicht sein kannst (hab mal > einige Deiner threads gelesen..) Aber ich will ja sachlich bleiben. Sagen wir es mal so: Ich habe mehr vergessen als du jemals lernen wirst... Und nein, ICH kann es bestimmt nicht sein. Normalerweise machen so etwas Lehrlinge im 2. Jahr. Dachdecker Lehrlinge. Abgesehen davon, zeigt sich, dass ich doch Recht hatte: Marc V. schrieb: > Aus Erfahrung gesprochen: > Je mehr Aufwand mit Schutz getrieben wird, desto weniger ist es das > Programm überhaupt wert, geschützt zu werden. > > Und wenn beide Seiten (Entwickler und Bestücker) nicht einmal imstande > sind, das Ganze anständig durchzuziehen, wird es echt tragikomisch... Und du bist ja nicht mehr als eine tragikomische Figur, die mit Gewalt etwas versucht was weder notwendig ist, noch selbst imstande ist, so etwas überhaupt zu machen. Jobst M. schrieb: > Hanno Reimann schrieb: >> Hier geht es auch nicht vorrangig um ein Kopieren, sondern dass man >> verhindert, dass Fehlfunktionen eingebaut werden. > > Aha. Oben war es noch die Angst vor einer Kopie. ...? Marc V. schrieb: > Hanno R. schrieb: >> Ausserdem soll der Lieferant der 328er die Teile flashen - der hat das >> richtige Equipment dafür und ist dazu noch recht preiswert. > > War das nicht der Bestücker ? Soviel zu deiner Glaubwürdigkeit überhaupt. Und jetzt träume mal weiter von grossem Marktdurchbruch...
> Der Firmwareaufwand lag bei ~250 h. In dieser Zeit sind Labortests, > Feldtests und Zertifizierung eingeschlossen. Und da machst du so einen Aufriss? Das ist ein winzig kleines Pillepalle Projekt. Dein bisheriger Aufwand, diverse Schutzmethoden zu überdenken, war schon unverhältnismäßig hoch.
Hanno R. schrieb: > Auch wenn es für dieses eine Projekt vielleicht nur einen marginalen > Nutzen bringt, ist der Nutzen dieser Diskussion doch für viele > Teilnehmer und Nurleser nicht unter den Tisch zu kehren. Hier sind viele > Ideen zu Tage gekommen, die sicher für andere Projekte die Weichen > stellen konnten. > > Und damit meine ich sicher nicht nur meine Projekte, sondern die vieler > anderer auch. > > Und schon alleine aus diesem Grund war diese Diskussion sehr nützlich > und richtungsweisend. > > Also nochmal vielen Dank an alle Teilnehmer Hiermit verabschiede ich mich aus dem inzwischen arg aus dem Ruder gelaufenen Thread. Ich denke, dass Beschimpfungen und Beleidigungen einen eigenen Thread erfordern. Vielleicht unter "Wer ist hier der Größte?"