Kopierschutz

[Peter666]

Hallo allerseits Sicherlich werden einige Leute hier ein ähnliches Problem haben, wie ich hier beschreibe: Wer gute Software produziert muss auch damit rechnen dass diese raubkopiert und/oder gecracked wird. Als Entwickler nimmt man das selbstverständlich ziemlich persönlich und es ist denke ich ein Ammenmärchen, dass alle die eine Raubkopie nutzen sich niemals die Software legal erwerben würden.
Wie dem auch seih, in der Regel sollte man nicht zu viel Arbeit in das Entwickeln eines Kopierschutzes stecken, da professionelle Teams nahezu jeden Kopierschutz auf Kurz oder Lang aushebeln.
Aber niemand hat behauptet man sollte es ihnen leicht machen
Was waren also meine Schritte bis zu meiner jetzigen Lösung (sieht man von der Webrecherche ab)? Zu allererst kauft man sich einen Exepacker für den es keinen One-Click Unpacker gibt. Gute Beispiele finden sich im Netz, deswegen gehe ich nicht darauf ein.
Der zweite Ansatz ist eine dezentrale Schlüssellogik die nicht auf eine einfache: "If Key=GenerateKey(Nutzerkennung)" hinausläuft. Auch sollte man sowas wie: If Keyeingabe=False then Showmessage('Falscher Schlüssel') tunlichst vermeiden..
Aber dennoch gibt es diverse Codestellen die man gerne unleserlich machen möchte. Mein Ansatz schaut hierfür wie folgt aus:
Man packt einen Marker an den Beginn der zu verschlüsselnden Codezeile und einen an das Ende.

Delphi-Quellcode:

 lblBlockStart:
    asm  
     db $EB, $0B; // Jmp +10 -> die Position hinter dem MarkerStart- Text
     db "MarkerStart"
    end;

 lblBlockEnd:
    asm 
     db $EB, $09
     db "MarkerEnd"
    end;

Die Adressen der beiden Labels kann man via mov eax, offset lblBlockStart bzw. lblBlockEnd ja auslesen.
Zum Verschlüsseln reicht ein einfaches:

Delphi-Quellcode:

 data:=  pointer(StartPosition);
 VirtualProtect(data, EndPosition-StartPosition, PAGE_EXECUTE_READWRITE, @OldProtect);
 // verschlüssele den Data Pointer mit einem Algorithmus
 VirtualProtect(Data, EndPosition-StartPosition, OldProtect, @oldProtect);

vollkommen aus.
Jetzt braucht man nur noch ein Patchtool zu schreiben, dass nach $EB, $0B, "MarkerStart" bzw. dem Endmarker sucht und verschlüsselt das ganze mit dem gleichen Passwort.

Das ganze kann man sicherlich verfeinern, dass bleibt ja jedem selber überlassen..

Hat jemand eventuell noch irgendwelche Ideen, die das Debuggen vermiesen? Ich denke da an Funktionen die in einem separaten Thread aufgerufen werden und nach Debuggern ausschau halten bzw. im Zweifel die Anwendung beenden.
Alles was sich so im Internet befindet ist irgendwie Stand <=2005

Peter

[Luckie]

Wesentlich besser: Deaktiviere bestimmte Features oder schränke sie per Compilerschalter ein. Was nicht da ist, kann man auch nicht cracken.

[Peter666]

Ja, das trifft aber nur bei ner Demoversion bzw. Shareware zu.

[Phoenix]

Das Problem mit dem Exepacker ist, dass ich den in nicht ganz 10 Minuten ausgehebelt habe - das brauchst Du also schon gar nicht zu probieren (sich selbst in Memory entpacken lassen und dann den Prozess-Memory dumpen (da ist das komplette entpackte Programm drin), den richtigen Einsprungspunkt suchen und that's it). Exepacker haben nur einen einzigen Zweck: Speicherplatz auf der Platte oder beim Übertragen durchs Internet zu sparen auf Kosten des RAM bei der Ausführung. Security ist da njiente.

@Verschlüsselung: Nicht ganz falscher Ansatz, das Problem ist, dass man bei der Ausführung solcher Blöcke diese auch während der Ausführung im entschlüsselten Zustand wegdumpen und dann in das binary-Image wieder einfügen kann. Zudem: Ist das Passwort bekannt hat es sich auch ausverschlüsselt.

Holger (von IBExpert) hat auch *lange* sowas versucht und ist jedes mal recht schnell umgangen worden.
Er setzt nun auf Kommerzielle Tools die tatsächlich (bis jetzt) das halten, was sie versprechen.

[Die Muhkuh]

Eventuell wäre es interessant zu wissen, welche Tools das sind. Dem einen oder anderen kann das sicherlich helfen.

[mkinzler]

Richtig sicher gibt es aber nicht
http://www.heise.de/newsticker/meldu...t-1161876.html
http://www.youtube.com/watch?v=4loZG...layer_embedded
Wobei es witzig ist, was Sony hier für ein komplexes System aufbaut und dieses dann durch eine "schludrige" Wahl eines Parameters ( feste/gleiche Zufallszahl) ihre System ad-absurdum führt

[Aphton]

Zitat von Phoenix:

Das Problem mit dem Exepacker ist, dass ich den in nicht ganz 10 Minuten ausgehebelt habe - das brauchst Du also schon gar nicht zu probieren (sich selbst in Memory entpacken lassen und dann den Prozess-Memory dumpen (da ist das komplette entpackte Programm drin), den richtigen Einsprungspunkt suchen und that's it). Exepacker haben nur einen einzigen Zweck: Speicherplatz auf der Platte oder beim Übertragen durchs Internet zu sparen auf Kosten des RAM bei der Ausführung. Security ist da njiente.

@Verschlüsselung: Nicht ganz falscher Ansatz, das Problem ist, dass man bei der Ausführung solcher Blöcke diese auch während der Ausführung im entschlüsselten Zustand wegdumpen und dann in das binary-Image wieder einfügen kann. Zudem: Ist das Passwort bekannt hat es sich auch ausverschlüsselt.

Holger (von IBExpert) hat auch *lange* sowas versucht und ist jedes mal recht schnell umgangen worden.
Er setzt nun auf Kommerzielle Tools die tatsächlich (bis jetzt) das halten, was sie versprechen.

Man könnte doch einen Filecrypter basierend auf den RC4-Algorithmus bauen, der ne Keyabfrage hat. Das einzige Problem hierbei wäre eben, dass man jedesmal beim Ausführen der Executable das Passwort eingeben muss, damit es im RAM/bei der Codeausführung richtig entschlüsselt (und evt. entpackt) wird.
Natürlich sollte man da keine Exceptionbehandlung einabeun. Dies würde es umso schwerer machen, da man dann wirklich das Passwort kennen muss.
Übrigens - vielleicht geht das nicht direkt aus dem obrigen Text hervor, aber die Keyabfrage wird in die Executable "reingepflanzt" (Section erstellen, Code einfügen, Einsprungspunkt umbiegen)

Edit: Vor einem Memory dump nach einem erfolgreichen Entschlüsseln hilft das natürlich auch nicht weiter. Aber dem Kunden sollte man glaube ich vertrauen können - in der Annahme, dass sich Cracker nicht die Mühe machen, das Produkt zu kaufen um es dann der breiteren Masse verfügbar machen zu können.

MfG

[Assarbad]

Zitat von Aphton:

Aber dem Kunden sollte man glaube ich vertrauen können - in der Annahme, dass sich Cracker nicht die Mühe machen, das Produkt zu kaufen um es dann der breiteren Masse verfügbar machen zu können.

Das ist leider eine Fehleinschätzung. Oftmals werden gestohlene Kreditkarten eingesetzt um ein Produkt zu kaufen und es wird danach geleakt. So bspw. schon geschehen bei IDA. Dagegen kann man sich wohl nur schützen indem man nur andere Zahlungsmethoden erlaubt.