Wie Seriennummer erzeugen?

[nobody0]

Ich möchte Seriennummern erzeugen, die nicht einfach erraten oder leicht berechnet werden können. Etwas einfaches wie nur Primzahlen verwenden scheidet also aus.
Welche Möglichkeiten gibt es zu so einer Zahlenerzeugung und wo gibt's Quellcode dazu? :confused:

[locus vivendi]

Ich glaube "Seriennummer" ist das falsche Wort, für das was du suchst. (Pseudo-)Zufallszahlen triff es glaube ich besser. Und danach würde ich auch mal Googeln. Um etwas Vorwegzunehmen, auf GNU/Linux Systemen kannst du /dev/random und /dev/urandom auslesen. Dann gibt es z.B. noch eine Bibliothek namens Crypto++, die transparent /dev/[u]random auf GNU/Linux und etwas vergleichbares unter Windows benutzen kann.

[Jasper]

Ich möchte Seriennummern erzeugen, die nicht einfach erraten oder leicht berechnet werden können. Etwas einfaches wie nur Primzahlen verwenden scheidet also aus.



such dir irgendwas eindeutiges und verhashe es. meistens packt man die lizenzinformationen (welche version, wieviele user, laufzeit, etc.) zusammen mit einer laufenden nummer in einen string, verhasht das ganze und hat seine seriennummer. wenn man aus der seriennummer die lizenzinfos wieder auslesen will, statt verhashen einfach verschlüsseln (am besten asymetrisch).


-j

[nobody0]

Also ich suche sowas wie den Key-Genarator für MS-Win95 oder Quake 3.
Die benötigte (Hash-)Funktion soll also a) den verfügbaren Zahlenbereich halbwegs gleichmäßig benutzen und b) soll nur 1/n-tel genutzt werden, damit ein Erraten (Bruit-Force-Attak) im Mittel nur bei jedem n-ten Versuch erfolgreich ist.
Damit nur der bruit-force-Weg offen bleibt, soll die Funktion schwer zu erraten sein und auch nicht aus ein paar Seriennummern berechenbar sein.

Sowas wie Lizenzinformationen will ich nicht reinpacken, denn solche Sachen kann man ja, wenn man denn will, in Datenbanken packen, die die Seriennummer als Primärschlüssel verwenden.

Weil solche Keys häufig verwendet werden, habe ich gehofft sowas in Büchern wie "Crackproof your Software" zu finden, aber bisher war nichts zu finden.

[locus vivendi]

meistens packt man die lizenzinformationen (welche version, wieviele user, laufzeit, etc.) zusammen mit einer laufenden nummer in einen string, verhasht das ganze und hat seine seriennummer.
Das könnte ein Schwachpunkt sein, wenn man leicht zu erratende Daten wie Versionsnummer und ähnliches verwendet. Auch wenn man die Daten hashed, denn man sollte davon ausgehen das ein Angreifer die Hashfunktion kennt.

Die benötigte (Hash-)Funktion soll also a) den verfügbaren Zahlenbereich halbwegs gleichmäßig benutzen und b) soll nur 1/n-tel genutzt werden, damit ein Erraten (Bruit-Force-Attak) im Mittel nur bei jedem n-ten Versuch erfolgreich ist.
Was ist an /dev/urandom oder ähnlichem verkehrt?

[nobody0]

Das könnte ein Schwachpunkt sein, wenn man leicht zu erratende Daten wie Versionsnummer und ähnliches verwendet. Auch wenn man die Daten hashed, denn man sollte davon ausgehen das ein Angreifer die Hashfunktion kennt.
Was ist an /dev/urandom oder ähnlichem verkehrt?

Da gibt's keinen Konsistenz-Check.
Es soll nur 1/n-tel des Wertebereichs genutzt werden und eine Prüf-Funktion soll festestellen, ob eine Zahl eine Seriennummer ist oder nicht.
Die Funktion, die die Serien-Nummer berechnet, soll kollisionsfrei sein, damit z. B. die fortlaufende Nummer als Eingabe verwendet werden kann.
Schön wäre noch, wenn die es zu der Funktion eine einfach berechenbare inverse gibt, damit man aus der Seriennummer die Eingabe-Nummer (fortlaufende Nummer) berechnen kann.

Übrigens bekomme ich von hier keine Mails mehr, obwohl ich abonniert habe.
Anscheinend mailt das Forum nicht mehr.

[bischi]

Die benötigte (Hash-)Funktion soll also a) den verfügbaren Zahlenbereich halbwegs gleichmäßig benutzen und b) soll nur 1/n-tel genutzt werden, damit ein Erraten (Bruit-Force-Attak) im Mittel nur bei jedem n-ten Versuch erfolgreich ist.
Das Ding heisst "Brute-Force" und wenn du das ganze kombinierst mit einem Benutzernamen, so wird noch deutlich mehr als 1/n drinnenliegen...

MfG Bischi

[Joghurt]

Erzeuge einfach eine Zufallszahl, z.B. mit /dev/(u)random, denke dir eine Prüfbedingung aus (z.B. Quersumme = 7) und passe die Zahl so an, dass die Bedingung erfüllt ist.

Wenn dir zehnstellige Zahlen genügen, könntest du das ISBN-Prüfverfahren verwenden (Wikipedia unter ISBN) Das Verfahren fängt alle Zahlendreher und auch noch einige andere Fehler ab. Und wenn du einen guten Zufallszahlengenerator nimmst, wie z.B. einfach aus /dev/random zu lesen, ist die Wahrscheinlichkeit, dass du zwei gleiche Seriennummern herausgibst, auch wohl sehr gering.
Bei 1000 wären es z.B. (10^9)!/ ( (10^7)! * 10^(9*1000))

[Joghurt]

Mir war langweilig... Wenn du /urandom nimmst, kommen die Zahlen schneller, sind aber nicht mehr 100% Zufallsverteilt...

#include <stdio.h>
//Genau umgedrehte Gewichtung. ISBN nutzt Gewichte 1,2,3,4,5,6,7,8,9
//wir 9,8,7,6,5,4,3,2,1
int pruefziffer(long zahl)
{
int pos;
int res = 0;
for(pos=2;pos<11;pos++) {
res = (res+(zahl%10)*pos)%11;
zahl /= 10;
}
return (11-res)%11;
}

long serial()
{
FILE* rndfile;
rndfile = fopen("/dev/random", "rb");
long serial;
long pruef;

do {
fread(&serial, 1, 4, rndfile);
pruef = pruefziffer(serial);
} while (serial>=1e9 || pruef == 10);
fclose(rndfile);

return serial*10 + pruef;

}

int main()
{
int i;
for(i=0;i<100;i++) {
printf("%010u\n", serial());
}
}

[nobody0]

Naja, besser als keine Konsistenz-Prüfung, aber ich will keine Nummern (ohne Prüfziffer) haben, die unmittelbar benachbart sind. Ich mache die Seriennummern deshalb über Gray-Codierung und fester Hamming-Distanz zu einem zufälligen Seed-Wert.
Das gibt bei einem Definitionsbereich mit M Bit und Wertebereich mit N und der Hamming-Distanz n immerhin
a=N!/(n!*(N-n)!)
Zahlen und kann auch im Mikrocontroller schnell und mit wenig Code überprüft werden. Den ISBN-Check hänge ich an, aber mit Gewicht 0 für die 10. Ziffer, da ich N=32 nehme.

[Joghurt]

Den ISBN-Check hänge ich an, aber mit Gewicht 0 für die 10. Ziffer, da ich N=32 nehme.Wofür denn das noch? Der Hamming-Check sollte doch ausreichen.

[nobody0]

Ok, stimmt eigentlich. :rolleyes:

[SeeksTheMoon]

und wie prüft man diese Nummern?
Es können auch Zahlen wie 0021380888 rauskommen, die dann als oktal angenommen werden, die Prüfuing sollte dann wohl als Stringvergleich gemacht werden, oder?

Was gibt es eigentlich für Wege, um solche Funktionen zu "sichern"?
Wenn jemand dem Programm mit Debuggern wie Softice auf die Pelle rückt, war die Arbeit ziemlich umsonst, weil man so die Seriennummer rausbekommt oder gleich ganz mitbekommt wie die Seriennummern erzeugt werden.

[Joghurt]

Was gibt es eigentlich für Wege, um solche Funktionen zu "sichern"?
Wenn jemand dem Programm mit Debuggern wie Softice auf die Pelle rückt, war die Arbeit ziemlich umsonst, weil man so die Seriennummer rausbekommt oder gleich ganz mitbekommt wie die Seriennummern erzeugt werden.Genau! Es gibt keine! Du kannst es den Leuten erschweren, indem du z.B. versuchst, Debugger zu erkennen, und wilden, selbstmodifizierenden Code schreibst, der ausnutzt, das wenn ein Debugger läuft, die Cache anderen Code enthält; aber Leute, die es wirklich herausbekommen wollen, hälst du damit nicht auf.

Deswegen nutzen ja Online-Spiele auch immer zwei Seriennummernchecks, einen einfachen, den der Client macht, und einen komplizierten, den der Server macht. Oder Zwangsregistierung wie bei HL2.

Ich finde das ganze etwas lächerlich. Wenn jemand sich solche Mühen macht, um nichts für ein Programm ausgeben zu müssen, würde er es sowieso nicht kaufen! Einfache Serieunnummerntests dagegen können wohl dazu führen, dass jemand, der das Programm ganz gut gebrauchen könnte, es sich auch kauft, da er es ja nicht einfach umsonst haben kann.

[oracle2025]

Also ich würde das folgendermaßen machen:

Der User gibt Vorname, Nachname und Email Addresse an, dann hängt man das aneinander, und macht zusätzlich noch einen festgelegten geheimen String ans Ende dran, und verwendet dann auf das ganze eine x-beliebige Hash-Funktion, wie etwa md5. Das ergibt den Key.

Evtl. sollte man noch schauen, dass man den geheimen String so im Sourecode versteckt, dass er nicht mit einem einfachen Aufruf von "strings" herausgefunden werden kann.

[oracle2025]

Oder wenn du das mit dem Namen und Email vermeiden willst, dann erzeuge einfach eine ganz beliebige Zahl für den ersten Teil der Seriennummer, hänge dann deinen geheimen String dran, und verwende den ermittelten Hash-Wert als Teil 2 der Seriennummer.

[nobody0]

Was gibt es eigentlich für Wege, um solche Funktionen zu "sichern"?
Wenn jemand dem Programm mit Debuggern wie Softice auf die Pelle rückt, war die Arbeit ziemlich umsonst, weil man so die Seriennummer rausbekommt oder gleich ganz mitbekommt wie die Seriennummern erzeugt werden.

Deshalb wird beim Mikrocontroller die JTAG Fuse durchgebrannt und dann kann kein Debugger mehr connecten, selbst wenn die Vergußmasse aufgelöst würde. Weitere Maßnahmen gegen Debugger findet man in "Crackproof your Software", aber eine ganz einfache ist Multithreading und von mehreren Threads parallel Key-Erzeugung/-Check erledigen lassen, denn multithreaded Programme zu Debuggen ist nicht leicht, also eine Hürde.