Generierung einer eindeutigen MachineID (Diskussion)

[neuronet]

Hier nun die endgültige Fassung, ich der die Units hwid und md5 getrennt wurden.

Viel Spaß damit!!!

[omata]

Moin,

also bei mir klappt das überhaupt nicht. Ich bekomme nur Fehler.
Ich habe mir das mal genauer angesehen und festgestellt, dass ich kein BiosDatum in der Registry habe. Eigentlich wird das ja durch einen try ... except Block abgefangen, knallt aber trotzdem und so heftig das keine ID berechnet wird.

Ausserdem habe ich festgestellt, dass die Generierung ziemlich viele Speicherlecks hat. Als ich das sah, hatte ich keine Lust mehr mich weiter damit zu beschäftigen.

MfG
Thorsten

[negaH]

Zitat:

Wenn Du meine Software installiert hast, dann weisst Du nicht genau, welche Informationen ich zum Generieren des Hash-Wertes verwende.

Wie kommst du zu dieser Aussage ?
Sorry aber manchmal verstehe ich die Welt nicht mehr. DU bist ein Programmierer also müsstes ausgerechnet DU sehr genau wissen wie DEINE Sourcen durch den Compiler in einem Maschniencode übersetzt werden und wie DU diesen Code wieder durch einen Disassembler quasi lesbar machen kannst. Es entsteht zwar dann nicht 1 zu 1 der originale Source, aber das juckt einen erfahrenen Reverse Engineer überhaupt nicht.
Ergo, in dem Moment wo du deine Software auf einem unsicheren System kopierst musst du davon ausgehen das man sehr wohl weis aus welchen Werten sich deine Serial Nummer zusammensetzt.

Jetzt, unter Deiner falschen Annahme, hast du ein Sicherheistsystem deren wahre Sicherheit garnicht existiert. Du GLAUBST also es wäre sicher defacto muß es unsicher sein. Und exakt solche Systeme sind es die heutzutage noch permanent geknackt werden. Denn der Angreifer kann nur Systeme knacken in denen der Entwickler grobe Designfehler eingebaut hat.

Du kannst jetzt die "Kriegs-Spirale" weiter drehen lassen und wiederum nach dem Konzept "Security by Obscurity" mit allen möglichen Programmiertricks dein Verfahren komplizierter und schwerer verständlich machen. Aber bedenke bitte eines: diese Arroganz ist tödlich da du in diesem Falle immer nur davon ausgehst das DU schlauer als eine Gruppe von vielen Hackern bist die es sportlich sehen so schnell wie möglich zu verstehen was du da programmiert hast.

Reale Sicherheit ist aber vom analytischen Konzept her gesehen absolut wasserdicht, dem Abgreifer darf nicht die geringste Chance für einen Angriff gegeben werden. Der einzigste Angriff der zum Schluß übrig bleibt ist die Brute Force Attacke, und deren Komplexität wird einfach durch große Passwörter soweit in die Höhe gechraubt das man Millionen Jahre an dem Problem zu knacken hat.

Wenn du dir also vorstellst das du jedem deinen Source 1 zu 1 geben kannst und dann in der Lage bist analytisch nachzuweisen das unter diesen Voraussetzung keiner in der Lage ist dein System zu knacken, erst dann ist es sicher.

Gruß Hagen

[alzaimar]

Wenn man aber mit einem solchen System Programme sicher macht, die sowieso kaum Einer haben bzw. kopieren will, dann ist das Verfahren auch wieder sicher. Aber dann kann man es auch ganz sein lassen.

Ich würde mal so sagen, das Du in deine SW eine kleine Hürde eingebaut hast, die es dem Frickelkopierer und Kazaasauger von Nebenan etwas schwerer macht, deine SW zu klauen. Das kann ausreichen, weil es den Prozentsatz der schwarzkopierten SW leicht verringert. Ob das dann zu Umsatzsteigerungen führt, sei mal dahingestellt.

Entweder, man setzt auf die Ehrlichkeit der Kunden oder man sichert eine SW richtig. Wir branden jede SW, erzählen es dem Kunden aber nicht. Das ist zwar überhaupt nicht sicher, aber wir sind wenigstens in der Lage, eine unzulässigerweise kopierte Version zuverlässig der Quelle zuzuordnen bzw. eindeutig zu belegen, das das Branding gefaked ist (einfach, weil wir gar nicht so viele Versionen im Umlauf haben. Das reicht schon, um diesem 'Kunden' mal ins Gewissen zu reden. Man muss dazu sagen, das es sich hier nicht um Massenware handelt, sondern um Software, die einfach nicht an andere Abteilungen weitergegeben werden soll.

Nebenbei kann uns nichts Besseres passieren, als das ein blöder Kunde unsere SW massenhaft verbreitet. Dann schnappt die 'Falle' zu, wir verklagen ihn auf X mal Wert der Software und müssen dann nie wieder arbeiten. Wir haben aber keine blöden Kunden.

Ich persönlich bin übrigens kein Verfechter von Dongleware oder anderen Schutzmechanismen, ausgenommen einer passwortgestützten Installation. Damit sind die Fronten nämlich geklärt: Der pöse Purche, der die Software verbotenerweise installiert, gesteht mit Eingabe des geklauten Passwortes und Annahme der Eula, das er sich seiner 'Tat' bewusst ist.

Wir unterstellen unseren Kunden gnadenlose Ehrlichkeit, was man ruhig machen kann, wenn man ein gutes Produkt zu einem vernünftigen Preis anbietet. Wichtiger als die Kohle ist uns auch unser Ruf: Da ist es kontraproduktiv, mit irgendwelchen Seriennummern und Warnungen zu kommen, das die SW nicht läuft, wenn man die HD wechselt.

Merke: Ein Schutzmechanismus macht aus einer SW noch keine Killerapplikation. Das muss die SW alleine können.

In diesem Sinne,

viel Spass beim hacken und knacken.

Der Alz

[mschaefer]

Zitat von neuronet:

Wenn Du meine Software installiert hast, dann weisst Du nicht genau, welche Informationen ich zum Generieren des Hash-Wertes verwende.
Dann werden diese Informationen bei jedem Programmstart mit der Online-Datenbank abgeglichen.
Ist so eigentlich sicher genug...

Da ist als Vorraussetzung, die Onlineverbindung. Das ist sicher nicht selbverständlich. Letzlich sicher wird Software ehedem nicht zu machen sein, deshalb ist die Lösung zumindest besser als nicht. Bin sogar der Auffassung, das Microsoft ohne die unsichere Software nie diesen Erfolg gehabt hätte.

Eigentlich wäre ich schon froh, wenn man Software so herrichten ´könnte, dass Sie nur von einem bestimmten Installationsmedium (USB-Stick mit Ident) installiert werden kann. Sonst sehe ich das eher wie Borland. Eine läuffähige Notsicherung gewährt den reibungslosen Weiterlauf der Arbeit und das kann man als Entwickler tolerieren.

Grüße // Martin

[neuronet]

@mschaefer:

Zitat:

Da ist als Vorraussetzung, die Onlineverbindung. Das ist sicher nicht selbverständlich.

Da es sich bei meiner Software um eine Lösung für Internet- und Telecafés handelt kann man wohl von einer vorhandenen Onlineverbindung ausgehen...

[alzaimar]

Neuronet: Deine Lösung ist ganz nett, aber sie ist eben nicht *sicher* im Sinne einer "Unhackbarkeit". Natürlich, nur sicher ist der Tod, aber ein anständiges Kryptoverfahren ist, praktisch gesehen, als sicher anzusehen.
Dein Verfahren ist unter diesem Gesichtspunkt nicht sicher. Punkt. Dessen musst Du Dir einfach bewusst sein. Solange Du mit deiner Lösung leben kannst, ist doch alles ok, aber hör doch auf die Spezialisten, die Dir einfach mal erzählen, das Du auf dem Holzweg bist, wenn Du meinst, Du hättest das tollste Verfahren. Hast Du nicht. Unknackbar ist es nicht, sicher ist es nicht und Spezialisten lachen Dich aus, wenn Du was anderes behauptest.

Aber eins muss man eben auch sagen: Es funktioniert und ist imho völlig ausreichend. Aber sichere damit keine Massenware. Denn dann kriegst Du sofort Cracks um die Ohren geballert, das dir Hören und Sehen vergeht.

Kann man eigentlich immer die Serien# einer HD auslesen? Geht das mit jedem Modell? Lustig. Kann man das nicht faken? Mit einem kleinen Service? Ich frag nur so, aus Interesse.

[negaH]

Sorry das ich mich nochmal melde:

Delphi-Quellcode:

procedure AntiProcDump;assembler;
procedure antidebug;assembler;

Sind echt alte Hüte und jeder Hacker wird diese Codestückchen sofort rausfischen. Besonders AntiDebug mit seinem "verstecketen" INT 3 OpCode ist sehr leicht für moderne Dissassembler auszumachen. Dies disassemblieren nämlich gleich mehrere möglich Programmpfade man muß es diesen nur sagen. Naja, bisher hast du sie ja auch noch nciht benutzt.

function GetHDSerialNumber: LongInt; Benutzt GetVolumeInformation() und bekommt die LOGISCHE Serialnummer zurückgeben, NICHT die physikalische Serialnummer. Die Logische Serialnummer lässt sich auf DOS Ebene sehr leicht verändert, oder eine Formatierung reicht schon aus.

Ok dafür hast du ja gleich anschließend

function GetIdeSerialNumber ():string; Diese benutzt den S.M.A.R.T Treiber, und wer aber weis das dieser Treiber nur statistische Aufgaben in einem System erledigt wird diese so wie ich löschen. Dieser Treiber erledigt keine für das OS wichtigen Aufgaben, sondern wird immer wieder gerne nur für den Softwareschutz benutzt.

function gethardwareid: string; Nur ganz wenige Intel CPUs kennen eine CPU-ID. Mit speziellen Tools kann man diese extern deaktivieren und beim Ausführen des CPU-ID Befehles kommt es dann zu einer Hardwareexception. Desweiteren kann der CPU-ID Befehl komplett für Ring 3 Anwendungen gesperrt werden, auch dafür wird es wohl Tools geben. Dies führt zu einer Hardware Exception. Wo ist dein TRY EXCEPT Block eigentlich ? Naja und den Rest machst du über die Registry die ja jeder selber abändern kann.

Du solltest mal den MD5 so erzeugen das er auf Basis der Annahme das KEINE deiner Funktionen mit dem Datensammeln Erfolg gehabt haben, und dir diesen MD5 Digest dann wirklich merken. Es könnte durchaus sein das mit der Zeit immer mehr Registrationen reinflattern mit solchen MD5 Digest.

Erfreulich ist aber die Anwendung des MD5 Hashs da diese bei einer bekannten Serial verhindert das man die nötigen Werte für die Registry ermitteln kann. Man muß also schon Zugriff auf den Rechner haben den man kompromittieren möchte um dann alle Infos auslesen zu können und somit einen zweiten Rechner mit den Werten für die gleiche Serial versehen zu können. Das IST eine Notwendigket die ein Hacker in einem solchen Falle NICHT umgehen kann, das ist also sicher, und liegt am MD5. Bekommt also ein Hacker eine Serial in die Hände so nützt diese ihm wenig wenn er nicht weis von welchem Rechner sie stammt und er keinen Zugriff auf diesen Rechner bekommt.

Du hast also eine echte kryptographische Funktion an einer Stelle eingesetzt wo sie kryptographisch sehr sinnvoll ist und dies führte dann auch tatsächlich zu einer Erhöhung der Sicherheit indem bestimmte Angriffe definitiv ausgeschlossen werden. Dies zeigt sehr schön den Unterschied zu den anderen Funktionen.

Gruß Hagen

[negaH]

Um die MD5 noch sicherer zu machen schlage ich vor das du in der Registry zb. in hKey_Classes_Root\CLSID eine Zufalls CLSID anlegst und diese in die MD5 Berechnung mit einfließen lässt.Dein Setup erzeugt also einen dir bekannten CLSID Schlüssel und legt dadrunter einen Zufallswert mit 128 Bit Länge ab.
In deiner Serial Routine berechnest du diesen Wert dann ein.

Warum?
Weil es nur eine sehr begrenzte Anzahl von verschiednenen CPUs und Betriebssystemen gibt. Gehen wir davon aus das einige deiner Funktionen scheitern, eben VolumeID und SMARTVSD dann stützt sich deine Serial Berechnung nur noch auf die CPUID und den Werten in der Registry. Sagen wir mal das es nur ca. 10000 verschiedene Kombinationsmöglichkeiten gibt und ein Angreifer diese alle berchnen kann. Somit kann ein Angreifer bei deiner Methode anhand der MD5 Serial per Dictionary Angriff ermitteln was für ein Rechner zur Serial gehört. Im Endeffekt also unsicher da es nicht soviele verschiedene CPUs und Betriebssysteme auf dem Markt gibt.

Der Zufallswert in der Registry randomisiert nun dieses Verfahren und er werden garantiert zu unterschiedliche Serials erzeugt. Ein Angreifer müsste also wiederum Zugriff auf den jeweiligen Rechner haben um diesen ZUfallswert auslesen zu können.

Denken wir mal weiter: Du installiert in \WinNT\SYSTEM32\ eine eigene DLL an die du hintenan an die Datei dran während des Setups einen Zufallswert speicherst. Diesen kannst du sogar mit der gleichen DLL wieder auslesen wenn du möchtest (was keine verdächtige Aktion darstellt, da es normal ist das in diesem Ordner Haufen von DLLs liegen, das diese natürlich auch geladen werden und das innerhalb der DLL es durchaus üblich ist Resourcen aus der DLL am Ende der Datei zu laden).
Naja, auf alle Fälle fließt dieser Zufallswert ebenfalls in deine MD5 mit ein.

Gruß Hagen

[neuronet]

Vielleicht sollte ich mir doch mal 'ne Kiste Dongles oder SmartCards bestellen...