Ein neuer Kopierschutz

[Blue-Fox]

Hmm
Warum schreibst du das in VisualBasic?

[Alex]

Weil es geht?

[niwax]

gandro schrieb:  Was macht eigentlich GetHash()? Ist ist ja wohl kaum Hashtable.GetHash Method (System.Collections) ?

Nein, das erzeugt einen 2048-Bit Hash der Systemkomponenten.
VB war eig die erste Sprache die ich gelernt hab: erst VBScript, dann C++, dann kam VB Classic, Java, VB.Net, VB für DOS, Delphi, HTML+CSS, Javascript, PHP und Perl (so etwa in der Reihenfolge, es sind noch ein paar mehr und ich hab auch schon selbst Skriptsprachen entworfen, aber das sind die wichtigsten). An sich finde ich VB übersichtlicher, wenn es auch darum geht, möglichst wartungsfreien Code zu erstellen, der immer mal wieder leicht verändert wird. Zum Errorhandling: der erste Try-Block fängt Errors ab, falls die Keylänge nicht ausreicht, um alles zu verschlüsseln, der zweite falls noch gar kein Hash existiert (Also noch nicht freigeschaltet wurde)
Visual Basic ist heute genau so schnell wie alle anderen wichtigen Sprachen, weil VB.Net, C#, C++.Net und J++ alle zu MS-IL kompiliert werden und sogar in ner anderen Sprache wieder dekompiliert.

[gandro]

niwax schrieb:  

gandro schrieb:  Was macht eigentlich GetHash()? Ist ist ja wohl kaum Hashtable.GetHash Method (System.Collections) ?

Nein, das erzeugt einen 2048-Bit Hash der Systemkomponenten. Ich wollte das nicht gleich offenlegen.

Wie du meinst. Nur Sicherheit bringt dir die Nicht-Offenlegung definitiv nicht, weil das hindert niemanden mit genügend Interesse daran, herauszufinden was du tust und wie man es umgehen kann.

[niwax]

War eigentlich mehr deswegen, weil der Code nicht grad clean ist (Ziemlich viele Stringfunktionen etc.)

[oreissig]

niwax schrieb:  An sich finde ich VB übersichtlicher, wenn es auch darum geht, möglichst wartungsfreien Code zu erstellen, der immer mal wieder leicht verändert wird.

ist das nicht ein Widerspruch? kleine Veränderungen sind doch das, was typischerweise unter Wartung fällt

niwax schrieb:  Zum Errorhandling: der erste Try-Block fängt Errors ab, falls die Keylänge nicht ausreicht, um alles zu verschlüsseln, der zweite falls noch gar kein Hash existiert (Also noch nicht freigeschaltet wurde)

Jaja das ist schon klar, dass es angedacht ist, dass da nur bestimmte Exceptions auftreten.
Nur wie heißen die exceptions denn genau? bei dem catch-statement sollte nicht einfach die Klasse aller Exceptions stehen, weil die Fehlerbehandlung (die bei dir nicht vorhanden ist) i.a.R. auf einen bestimmten Fehlertyp zugeschnitten ist. ein fehler ob die Keylänge ausreicht ist was anderes, als wenn er z.B. die datei nicht öffnen kann, in letzterem Falle wäre es nämlich NICHT sinnvoll einfach den Fehler zu fangen und weiterzumachen, weils nix gibt, um weiterzumachen

[niwax]

Der Code kann gar keinen Fehler erzeugen, außer dass der Key zu kurz ist, deshalb wollte ich nicht testen, was bei zu kurzem Key passiert sondern habs einfach verallgemeinert. Ich habe ja zwei Try-Blöcke, einen um die Dateiroutinen, die lesen ist ein Try-Block drum, weil sichs bei Lesefehlern um ne fehlerhafte Datei, also ein nicht akjtiviertes Programm handelt. Die Funktion Generate() hat absichtlich keinen Try-Block um den Plattenzugriff, damit der Aufrufer den Fehler weitergereicht bekommt und so darauf reagieren kann, wie er will zB mit ner Demoversion etc.

[gandro]

Also, ich hab mir die Sache mal ein bisschen kryptografisch angeschaut.

Etwas stutzig macht mich dabei sofort, dass du in der GUI irgendwo MD5 erwähnst, du aber nirgendwo MD5 verwendest..? Egal.

Was du ja prinzipiell machst, ist einen Hashwert aus den Systemeigenschaften generieren und den abspeichern. Kopiert jemand die Dateien auf einen anderen Rechner, oder bastelt an der EXE rum, dann fällt das natürlich dann auf, das ist ja die Idee hinter dem Schutz.

Die "Verschlüsselung" die du machst, ist nichts weiter als ein XOR aus den Daten der EXE und dem Hash. Du schüttest da noch ein paar Zufallszahlen in die anticop.y rein, aber das ist ja nur Datenmüll zur Verschleierung.

Das heisst, wir haben hier eine synchrone XOR-Verschlüsselung mit ein bisschen Obfuscation. Mit Blowfish hat das herzlich wenig zu tun

Synchrone "Verschlüsselung" heisst: Jeder kann die Datei entschlüsseln (im Zweifelsfall .NET dekompilieren und den Code anschauen), den Hash rauslesen und einen eigenen Hash reinschreiben (den Hash-Generator getHash() lieferst du ja auch mit, da kommt man auch an den Code ran).

Als potentieller Cracker muss ich also nur ein winziges Programm schreiben, was die anticop.y für den Rechner neu schreibt und fertig.

Von daher schützt dein Code zwar vor einfachem Copy-Paste, aber der Schutz lässt sich problemlos aushebeln, weil du synchrone Verschlüsselung verwendest.

Ein richtiger Kopierschutz müsste mit asynchroner Verschlüsselung arbeiten, wo das Setup oder dein Download-Server den rechnerspezifischen Hash verschlüsselt, wo du beim Überprüfen nur noch entschlüsseln musst und ein Angreifer keine Verschlüsselung basteln kann, weil du den Code zum verschlüsseln nicht mitlieferst.

Solange du aber die Verschlüsselungsroutine inkl. Key im Programm behälst, kann jeder deinen Kopierschutz aushebeln.

[niwax]

GetHash() ist ne Funktion von mir, in der wiederum Object.GetHashCode() verwendet wird, die auf MD5 basiert.

[gandro]

Hm... nö.. das ist definitiv kein MD5.

Default implementation for Object.GetHashCode() - Stack Overflow

Wobei du ja GetHashCode() von Objekten aufrufst, die von Microsoft stammen. Die werden da nicht überall die Standard-GetHashCode verwenden, aber MD5 halte ich (ohne es überprüft zu haben) für sehr unwahrscheinlich. Viel zu zeitaufwendig, weil der Hash idR auch nicht kryptografisch sicher sein muss.

Am meisten (oder immer?) verwendest du in GetHash() ja eh Strings, also String.GetHashCode(). Und das ist definitiv nicht MD5, nur schon von der Bitlänge her viel zu kurz.

String.GetHashCode Method (System)