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..
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..?
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:
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.
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.
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"
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.
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
voidprint_val(char*msg,uint8_tval)
4
{
5
Serial.print(msg);
6
Serial.println(val,HEX);
7
}
8
9
voidsetup(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_ti=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_ti=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.
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
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:> 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:
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
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.
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...
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.
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.
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
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.
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?"
Thread beobachten
Seitenaufteilung abschalten