Hallo, ich habe einen ATtiny13A und wollte den Schutz vorm Auslesen aktivieren. Im AVR-Sudio finde ich bei den LockBits: - No memory lock feature enabled - Further programming disabled - Further programming and verification disabled Von Lesen steht da also nichts. Andererseits nehme ich mal an dass er Lesen muss um die 'Verification' auszuführen. Ausprobieren will ich das aber noch nicht, da ich mit dem Programm noch nicht fertig bin. Andererseits würde ich vlt. den Controller wechseln, fals ich hier keinen Schutz gegen das Auslesen habe. Also, die Frage lautet: Wird bei 'Further programming and verification disabled' auch das Auslesen verhindert? Gruß Peter
Ja. Keine Angst, ein Erase löscht auch die Lockbits, nachdem der Flash gelöscht wurde.
:
Bearbeitet durch User
Peter schrieb: > Also, die Frage lautet: Wird bei 'Further programming and verification > disabled' auch das Auslesen verhindert? Ja, kann man sehr leicht ausprobieren indem man versucht, den Flash auszulesen. Peter schrieb: > Ausprobieren will ich das aber noch nicht, da ich mit dem Programm noch > nicht fertig bin. Andererseits würde ich vlt. den Controller wechseln, > fals ich hier keinen Schutz gegen das Auslesen habe. Was hast du den so grossartiges in 1KB programmiert, dass du es schutzen musst ?
Peter D. schrieb: > Ja. > > Keine Angst, ein Erase löscht auch die Lockbits, nachdem der Flash > gelöscht wurde. Wunderbar, vielen Dank. Frank L. schrieb: > es einfach testen wäre unter deiner Würde? Ersten das und zweitens war ich mir nicht sicher, ob ich den dann wieder neu programmieren kann. Marc V. schrieb: > Peter schrieb: >> Ausprobieren will ich das aber noch nicht, da ich mit dem Programm noch >> nicht fertig bin. Andererseits würde ich vlt. den Controller wechseln, >> fals ich hier keinen Schutz gegen das Auslesen habe. > > Was hast du den so grossartiges in 1KB programmiert, dass du es > schutzen musst ? Die Frage zur Antwort '42'. Gruß Peter
Achsoo. Ich fürchtete schon es enthalte den tödlichsten Witz der Welt... https://de.wikipedia.org/wiki/Der_t%C3%B6dlichste_Witz_der_Welt
Peter schrieb: > - Further programming and verification disabled > > Von Lesen steht da also nichts. to verify, schau mal was das heißt ;)
M. K. schrieb: > Peter schrieb: >> - Further programming and verification disabled >> >> Von Lesen steht da also nichts. > > to verify, schau mal was das heißt ;) Verify steht da aber nicht, sondern verification. Und verification hat mit Lesen nix zu tun: http://dict.leo.org/dictQuery/m-vocab/ende/en.html?searchLoc=0&lp=ende&lang=en&directN=0&rmWords=off&search=verification&resultOrder=basic&multiwordShowSingle=on
>Was hast du den so grossartiges in 1KB programmiert, dass du es schutzen musst ?
Kopierschutz schützt hauptsächlich die eigene Marge, nicht das eigene
KnowHow.
Klaus schrieb: > M. K. schrieb: >> Peter schrieb: >>> - Further programming and verification disabled >>> >>> Von Lesen steht da also nichts. >> >> to verify, schau mal was das heißt ;) > > Verify steht da aber nicht, sondern verification. > > Und verification hat mit Lesen nix zu tun: > http://dict.leo.org/dictQuery/m-vocab/ende/en.html?searchLoc=0&lp=ende&lang=en&directN=0&rmWords=off&search=verification&resultOrder=basic&multiwordShowSingle=on Richtig, da steht verification, also das Nomen zum Verb. Und ja, to verify heißt nicht lesen sondern prüfen. Jetzt muss man aber mal den Grips einschalten: Wenn man den Flash-Speicher nicht prüfen kann könnte das ja u.a. bedeuten, dass man ihn nicht lesen kann denn zum Prüfen, das ist zwingend, muss man ihn lesen. ;)
M. K. schrieb: [...] > Grips einschalten: Wenn man den Flash-Speicher nicht prüfen kann könnte > das ja u.a. bedeuten, dass man ihn nicht lesen kann denn zum Prüfen, das > ist zwingend, muss man ihn lesen. ;) Jein. Man muß den Speicher mit einem Sollwert vergleichen können. Das kann man auch so implementieren, dass der Sollwert zum Chip geschickt wird und als Antwort dann nur PASS/FAIL zurückkommt. Damit ließe sich zwar durch Brute Force der Inhalt ermitteln, dies ist aber schon bei 1kByte unpraktikabel (2^8192 Möglichkeiten).
Einfach mal Atmels, ich glaub, AN910 lesen. Da steht auch extra drin, dass das Device nicht mehr zu lesen ist wenn beide Lockbits gesetzt sind.
Ralf D. schrieb: > Damit ließe sich > zwar durch Brute Force der Inhalt ermitteln, dies ist aber schon bei > 1kByte unpraktikabel (2^8192 Möglichkeiten). LOL. Wie kommst du darauf ? 1024 * 256 = 262,144 Versuche, wenn der Inhalt auf 0xFF steht. Da aber 0xFF gelöscht bedeutet, ist etwa die Hälfte davon viel wahrscheinlicher, also 131,072 Versuche. Selbst wenn man pro Anfrage 1ms braucht, wäre das Ganze in etwas mehr als 2 Minuten fertig.
:
Bearbeitet durch User
Marc V. schrieb: > 1024 * 256 = 262,144 Versuche Das willst du bestimmt noch einmal nachrechnen. In zwei Byte bekomme ich gut 65000 Zustände kodiert. In 1024 sind es dann... ???
Georg G. schrieb: > In zwei Byte bekomme ich > gut 65000 Zustände kodiert. In zwei Byte gibt es 2 mal 256 Zustände.
Route 6. schrieb: > In zwei Byte gibt es 2 mal 256 Zustände. Und wie schafft man es dann, in 2 Byte einen Integer von 65000 zu kodieren? In zwei Byte passen 2^16 Zustände (das sind 256 * 256).
Marc V. schrieb: > LOL. > Wie kommst du darauf ? > 1024 * 256 = 262,144 Versuche, wenn der Inhalt auf 0xFF steht. > Da aber 0xFF gelöscht bedeutet, ist etwa die Hälfte davon viel > wahrscheinlicher, also 131,072 Versuche. > Selbst wenn man pro Anfrage 1ms braucht, wäre das Ganze in etwas mehr > als 2 Minuten fertig. Wie kommst du den auf 256? in einem Byte sind doch NUR 8 Bit. 1 Bit hat 2 Zustände. 8 Bit haben dann 2 * 8 = 16 Zustände. Du brauchst also nur 2 8 1024 = 16384 Versuche, das ist also in unter 17 Sekunden durchprobiert!
Mathematiker schrieb: > Marc V. schrieb: >> LOL. >> Wie kommst du darauf ? >> 1024 * 256 = 262,144 Versuche, wenn der Inhalt auf 0xFF steht. >> Da aber 0xFF gelöscht bedeutet, ist etwa die Hälfte davon viel >> wahrscheinlicher, also 131,072 Versuche. >> Selbst wenn man pro Anfrage 1ms braucht, wäre das Ganze in etwas mehr >> als 2 Minuten fertig. > > Wie kommst du den auf 256? > in einem Byte sind doch NUR 8 Bit. > 1 Bit hat 2 Zustände. > 8 Bit haben dann 2 * 8 = 16 Zustände. > Du brauchst also nur 2 8 1024 = 16384 Versuche, das ist also in > unter 17 Sekunden durchprobiert! Das üben wir aber nochmal, ja?
Damit auch ein Mathematiker das Rechnen lernt: Mathematiker schrieb: > ... > in einem Byte sind doch NUR 8 Bit. Stimmt! > 1 Bit hat 2 Zustände. Auch richtig (solange wir von binärer Logig reden) > 8 Bit haben dann 2 * 8 = 16 Zustände. Und hier wird dann falsch. Die einzelnen Bits sind ja unabhängig. Ich versuche es jetzt mal mit weniger (3) Bits aufzuschreiben: 0 0 0 -> Möglichkeit 1 0 0 1 -> Möglichkeit 2 0 1 0 0 1 1 1 0 0 1 0 1 1 1 0 1 1 1 -> Möglichkeit 8 Wie unser alter Lehrer zu sagen pflegte: "Was lernt uns das?" Zahl der Möglichkeiten ist 2^3 = 8. Hochgerechnet auf ein Byte: 2^8 = 256 zwei Byte: 2^(2*8) = 2^16 = 65536 Die Weiterführung der Rechnung auf größere Speicherbereiche sollte jetzt auch dem "Mathematiker" möglich sein.
Georg G. schrieb: > Mathematiker schrieb: >> Wie kommst du den auf 256? > > Ironie Tags vergessen? Oder wirklich Nuhr? Muss man die wirklich dabei setzen? bei der Vorlage: Marc V. schrieb: >> 1kByte unpraktikabel (2^8192 Möglichkeiten). > > LOL. > Wie kommst du darauf ? > 1024 * 256 = 262,144 Versuche, </ironie>
Mathematiker schrieb: > Muss man die wirklich dabei setzen? In diesem Forum ist alles möglich. Seit ich hier mitlese, ist mein Verständnis für Physik erheblich größer geworden.
Hmmm, das Verify wird ja nicht über den gesamten Speicher gemacht, sondern über einen Bereich. Wenn ich den Bereich auf ein Byte dezimiere, - ... Wenn das geht habe ich nur noch 256 Möglichkeiten. Mal der Anzahl der Bytes. Das würde dann wirklich sehr schnell gehen.
Das hängt eben von der Implementierung ab. Ein sicheres Verify ohne Lesen vergleicht natürlich immer den gesamten Speicherinhalt, bevor man eine Antwort bekommt. Ist bei Passwörtern ja auch so: Antworten wie "Der zweite Buchstabe war falsch" bekommt man heutzutage nichtmal mehr über einen Seitenkanal.
Thomas W. schrieb: > Hmmm, das Verify wird ja nicht über den gesamten Speicher gemacht, > sondern über einen Bereich. > > Wenn ich den Bereich auf ein Byte dezimiere, - ... > > Wenn das geht habe ich nur noch 256 Möglichkeiten. > Mal der Anzahl der Bytes. > Das würde dann wirklich sehr schnell gehen. Geht aber nicht. Ich wollte ihn nur auf seinen Denkfehler hinweisen. Also konkret beim Tiny13: Selbst wenn Verify erlaubt wäre (ist es ja nicht, aber nur mal als Beispiel), kann man nur ganze Pages vergleichen und eine Page ist beim Tiny13 16 Words, also 32 Bytes gross. Das ergibt dann 2^256 Möglichkeiten = 1.1579208923731619542357098500869e+77 und das ist aber eine ziemlich grosse Zahl ;) Und selbst der kleine Tiny13 hat 32 davon.
:
Bearbeitet durch User
Marc V. schrieb: > Das ergibt dann 2^256 Möglichkeiten = > 1.1579208923731619542357098500869e+77 > und das ist aber eine ziemlich grosse Zahl ;) Ui, dass ist aber verdammt nah an der Schwingungsfrequenz eines Basisteilchens ;-)
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.