Seite 2 von 2

Verfasst: 22.10.2004 21:38
von slave
wow ihr seid spize
wirklich cool schneller als googel :wink:

vielen dank :allright:

Verfasst: 22.10.2004 22:35
von Deeem2031
Auch wenn im Duden steht, dass das Verb "googeln" heißt, heißt die Suchmaschine immernoch Google ;)

Verfasst: 22.10.2004 22:49
von Gerrit
LittleFurz hat geschrieben:wenn du es wirklich sicher machen willst dann mach es so: du forderst dein kunden beim erststart auf das passwort einzuegben. das Passwort wird dann mit MD5 verschlüsselt und ganz normal in eine Datei speichern. Danach, wenn das Programm startet, forderst du dein Kunden auf das passwort einugebebn. das eingegebene passwort wird dann auch mit MD5 verschlüsselt und dann mit dem Key aus der Datei verglichen. Wenn die Keys ungleich sind, ist das Passwort falsch.

MD5 ist eine einweg verschlüsselung und damit hoch sicher. damit sollte es auf jeden fall gehen und sicher ist es odendrein auch noch.
*lol* dieser Schutz schreckt ja wohl kaum jemanden ab. Die Variationen davon auch nicht wirklich. Man braucht nur ein beliebiges Passwort mit MD5 verschlüsseln und es in die Datei schreiben, schwupps habe ich Zugriff, so einfach wäre das. Lösen könnte man das indem du das Passwort mit einem eigenen Algorythmus verschlüsselst, das würde schonmal einen Großteil abschrecken (da sie das Passwort ja ohne den Schlüssel, der im Programm steckt nicht neu erstellen können). Problem an der Sache: Wenn ich die Datei (oder auch den Registerykey) mit dem Schlüssel lösche denkt das Programm es sei der erste Start. Zack, wieder umgangen ;)

Mein Lösungsansatz (auch wenn ich nicht weiß "wie" sicher das ganze sein soll):
Es ist möglich an alle Möglichen Dateien Daten "anzuhängen". So kannst du zbs. ein Bild oder Icon an eine Exe oder DLL binden. Genauso kannst du auch (im Nachhinein) das Passwort an die Exe anhängen. Schon wäre das ganze einen Tick sicherer. Da ich aber selbst erst mit PB anfange kann ich dir kein Beispiel für eine Implentation bieten, aber die Idee :)

Mfg, Gerrit

Verfasst: 22.10.2004 23:34
von MVXA
Meinst du sowas ?

Code: Alles auswählen

Debug PeekS(?Passwort)

Passwort:
!DB "Hallo"
Das Beispiel entstand in 10 Sekunden /:->. und stürzt daher nach einmaligem benutzen sofort ab. Aber ich lass mir das was einfallen.

edt. hab den bug gefunden -_- da fehlt n end, jetzt funzt des eigentlich schon ganz gut

edt2. gibt es n kleines Problem, FASM plaziert am Ende des Programms noch jede menge anderen Code. damit wird es quasi unmöglich genau an die Pos. Passwort ran zu kommen :(

Verfasst: 22.10.2004 23:48
von MVXA
Meinst du sowas ?

Code: Alles auswählen

Debug PeekS(?Passwort)

Passwort:
!DB "Hallo"
Das Beispiel entstand in 10 Sekunden /:->. und stürzt daher nach einmaligem benutzen sofort ab. Aber ich lass mir das was einfallen.

edt. hab den bug gefunden -_- da fehlt n end, jetzt funzt des eigentlich schon ganz gut

edt2. gibt es n kleines Problem, FASM plaziert am Ende des Programms noch jede menge anderen Code. damit wird es fast unmöglich genau an die Pos. Passwort ran zu kommen :(

Verfasst: 23.10.2004 01:38
von Ynnus
Ein Buffer ist in der Regel eine Variable, wo Daten gespeichert werden. In meinem Beispiel wird eine Variable erstellt, die Passwort heißt. In der Funktion übergebe ich mittels @ die Adresse der Variable. Länge heißt in dem Fall, wie lang der Text im Buffer oder in der Variable ist. Das Ergebniss wird dann in der Variable MD5Passwort gespeichert.
Ist ein Buffer nicht normalerweise ein Bereich im Speicher welchen man mit Allocatememory() reservieren könnte? Dann wäre zwar @Variable auch der Speicherbereich der Variable (Somit der Buffer in welchem der Wert der Variablen steht), aber das macht den Buffer noch nicht zu einer Variablen selbst.

*pointer = @variable wäre dann ein Buffer an der Stelle im Speicher wo der Wert der Variablen steht, mit der gleichen Größe, seh ich das so richtig? Ebenso könnte man auch *pointer = allocatememory(10) oder so nehmen, um 10 Byte im Speicher zu reservieren. Dies ist meines Wissens nach dann ein Buffer. Man korrigiere mich bitte wenn ich mich vertan habe, so viel hab ich mich mit Speicheradressen noch nicht beschäftigt.

Betreffend dem Thema der Verschlüsselung - Ich hab eben so ein kleines Testprogramm geschrieben mit MD5 Verschlüsselung, hatte mich vor diesem Beitrag hier auch noch nicht damit auseinandergesetzt.

Code: Alles auswählen

OpenFile(0, "Passcode.txt")
*buffer = AllocateMemory(10)
PokeS(*buffer, "123456789")
WriteString(MD5Fingerprint(*buffer, 10))
CloseFile(0)

OpenConsole()
OpenFile(0, "Passcode.txt")
String$ = Input()
*buffer = AllocateMemory(10)
PokeS(*buffer, String$)
If MD5Fingerprint(*buffer, 10) = ReadString()
  Print("Jo, korrekt!!")
Else
  Print("Ahh, NEIN!")
EndIf
Input()
Kleine Erklärung für alle denen es unklar ist, was genau hier passiert:

Es wird eine Datei passcode.txt erstellt, dann ein Buffer eingerichtet und dieser enthält den Wert "123456789", welches hier unser Passwort darstellt. Dann wird dieser String verschlüsselt und in der Datei gespeichert. Nun wird die Datei geschlossen und erneut geöffnet, ein Konsolenfenster wird geöffnet und man kann ein Passwort eingeben. Gibt man nun "123456789" ein, so erscheint die Nachricht, dass es das richtige Passwort ist. Bei jeder anderen Eingabe erscheint eine Fehlermeldung.


EDIT:
Mein Lösungsansatz (auch wenn ich nicht weiß "wie" sicher das ganze sein soll):
Es ist möglich an alle Möglichen Dateien Daten "anzuhängen". So kannst du zbs. ein Bild oder Icon an eine Exe oder DLL binden. Genauso kannst du auch (im Nachhinein) das Passwort an die Exe anhängen. Schon wäre das ganze einen Tick sicherer. Da ich aber selbst erst mit PB anfange kann ich dir kein Beispiel für eine Implentation bieten, aber die Idee
Im Nachhinein kannst du keine Daten mehr in die Exe schreiben. Zumindest hat Windows da einen Schutz welches es nicht erlaubt, in die eigene laufende Anwendung Daten zu schreiben. Somit wirst du einen weiteren Prozess brauchen der nach dem Schließen der Exe startet und in die Exe etwas hineinschreibt. Das könnte man dann eventuell wieder manipulieren. Außerdem könnte man auch diese Werte in der Exe mit einem Hexeditor ganz einfach ändern und sich somit einen neuen Schlüssel basteln.

Vielleicht sollte man sich daher eine eigene Verschlüsselungstechnik schreiben, dann ist es ja egal, ob der Anwender den verschlüsselten Text sieht, wenn er ihn nicht durch einen anderen ersetzen kann.
Also die Problematik ist ja die, dass man, wenn man den verschlüsselten MD5 Fingerprint in einer Textdatei hinterlässt, diesen einfach durch einen anderen ersetzen kann und schon hat man das Passwort geändert. (Wäre ganz einfach, in PB ein beliebiges Passwort in einen MD5 umwandeln lassen, die Textdatei damit ersetzen und schon hat man den String vor der Umwandlung als neues Passwort). Also ist es ratsam hier, einfach einen eigenen Algorithmus zu entwerfen, welcher einen Schlüssel erstellt und dann genauso handhabt, in einer Textdatei hinterlegt und mit dem eingegebenen Passwort vergleicht. Dann würde das Problem entfallen, dass man den Schlüssen ersetzen kann, weil es ja nicht mehr geht. Wer den Algorithmus nicht kennt, der kann dann zwar die Textdatei mit dem verschlüsselten Passwort beliebig verändern, aber dadurch kennt er dann noch nicht das neue Passwort für seine Änderung die er vorgenommenb hat. Ihm fehlt also der Weg, sich selbst aus einem Passwort-String diesen Schlüssel zu basteln und diesen zu ersetzen und nutzen zu können.
Somit bietet man dem Anwender dann keine Gelegeneheit mehr, sich selbst ein passwort zu bauen. Meiner Meinung nach recht sichere Sache dann. ;)

Dann könnte der Schlüssel vielleicht so aussehen, dass man den letzten Buchstaben des Passwortes mit dem ersten Buchstaben per XOR verknüpft und danach um 4 Bit nach rechts verschiebt. Dann den 1ten Buchstaben mit dem 2ten Buchstaben des Passwortes per XOR verknüpfen und wieder bitrotation durchführen. Dann diesmal den 2ten Buchstaben mit dem 3ten per XOR verknüpfen und rotieren lassen... Und immer so weiter, dann entsteht daraus auch ein netter Zahlensalat der sich nicht so leicht wieder herstellen lässt.
Nun solltest du aber natürlich nicht genau diese Methode nehmen, denn sonst kennt man sie ja nun. Lass dir was eigenes einfallen für den Schlüssel, einen eigenen Algorithmus zum verschlüsseln des Passwortes.
(Diese Verschlüsselungsmethode ist nicht von mir sondern hab ich aus einem Contest heraus behalten, an dem ich mal mitgemacht habe. Da war die Aufgabenstellung, einen String mit dieser Methode zu verschlüsseln)

EDIT2: Zuspät gesehen dass Gerrit ja bereits auch schone eine eigene Verschlüsselung angesprochen hat... /:->
Naja, jetzt hab ich den Text schon geschrieben, lassen wir es mal so. Vielleicht kannst du die Verschlüsselungstechnik die ich unten beschrieben habe ja als Denkanreiz nutzen und damit was anfangen, um dir dann deine eigene Verschlüsselungstechnik zu basteln. ;)
Problem an der Sache: Wenn ich die Datei (oder auch den Registerykey) mit dem Schlüssel lösche denkt das Programm es sei der erste Start. Zack, wieder umgange
Wie wäre es, wenn beim Erwerb des Programmes eine Art Seriennummer mitgeliefert wird, welche das Passwort des Programmes ist? Dann muss man dieses zwar gut aufheben, aber hat dann, ähnlich wie bei kommerziellen Programmen, einen Key mit welchem man das Programm dann starten oder installieren kann, oder was auch immer.
Dann müsste man natürlich für jedes rausgehende Produkt eine einmalige Seriennummer entwerfen welcher dann irgendwie beigelegt wird.

Verfasst: 23.10.2004 02:32
von MVXA
ich hätte dann eine weitere Idee. Man könnte doch die Compilerzeit mit in den MD5Print einwriken lassen. Also:

Code: Alles auswählen

Passwort.s = "Passwort" + Str(#PB_Compiler_Date)
NeuesPasswort.s = MD5Fingerprint(@Passwort, Len(Passwort))
Das wäre dann noch etwas sicherer, da die Compilerzeit wirklich statisch ist und man die nicht so genau herausfinden kann.

P.S. wieso steht mein Post da oben 2x :? ? Habs nicht 2x gepostet :freak:

Verfasst: 23.10.2004 05:02
von Gerrit
Sunny hat geschrieben:Wie wäre es, wenn beim Erwerb des Programmes eine Art Seriennummer mitgeliefert wird, welche das Passwort des Programmes ist? Dann muss man dieses zwar gut aufheben, aber hat dann, ähnlich wie bei kommerziellen Programmen, einen Key mit welchem man das Programm dann starten oder installieren kann, oder was auch immer.
Dann müsste man natürlich für jedes rausgehende Produkt eine einmalige Seriennummer entwerfen welcher dann irgendwie beigelegt wird.
Ja, ein Key ist schon eine Lösung. Eine 100% Lösung gibt es ja eh nicht, es ist immer nur die Frage ob sich der Aufwand lohnt eine solche Barriere zu knacken.

@Dateien an Exe hängen
Ok, lassen wir die Geschichte mit der Exe, das Programm wird ja wohl noch mehr Daten haben als die eine Datei oder :mrgreen: Oder folgendermassen: Bei der erstinstallation wird eine Schlüsseldatei erzeugt (mithilfe der Seriennummer/Masterpasswort, wie auch immer) und ein Passwort angelegt. Dieses wird in einen (selbstdefinierte) Datei geschrieben, in irgendeiner Verschlüsselung (zbs. erst ein paar Bit wirre Zahlen und Buchstaben, dann das verschlüsselte Passwort (welches ja auch wirre Buchstaben und Zahlen sind ;)) und dann nochmal ein paar Biti hinterher und niemand kann hier noch etwas ändern. Ist die Datei beim Start nicht vorhanden wird wieder nach dem Masterpasswort gefragt.

@Letzte Alternative
Du kannst auch einen Windowsserver mieten, nach dem Kauf des Programms ein Passwort abfragen, das Programm On-the-fly auf dem Server Kompilieren (mit dem gegebenen Passwort), es packen lassen und dann per Email verschicken oder einen Download Link dorthin. Das wäre etwas für paranoide. Das PW kann man im Quelltext auch verschlüsselt ablegen..je nach Wunsch :o

Mfg,Gerrit
(Bitte den letzten Absatz nicht alzzu Ernst nehmen, wobei es Theoretisch klappt..)