Kopierschutz

[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

[brechi]

If keyEingabe = false
ist sowieso schonmal falsch, es würde
If not KeyEingabe
heißen

Und zu deinem obigen Beispiel, es würde auch nichts bringen. Einen BreakPoint drauf und mann weiß was da eingetragen werden soll. Es bringt dir also 0 selbst wenns im anderen Thread läuft.

[cookie22]

schau mal hier, da hatte ich mal was gepostet.

http://www.delphipraxis.net/150049-l...ml#post1013000

wobei all diese dinge recht nutzlos sind. wenn jemand dein programm cracken will, wird er das auch früher oder später schaffen. eigentlich sollte man keine energie auf sowas verwenden. denn das ammenmärchen stimmt, jemand der gecrackte software benutzt zahlt eh nicht und die ehrlichen user benutzen keine cracks. wenn man deine software nicht cracken kan,n nutzen diese leute halt ein anderes produkt zu dem es cracks gibt.

[Assarbad]

Benutze ein Wasserzeichen in den Binärdateien und mache dies den Kunden bekannt. Kündige ebenfalls an, daß Versionen die irgendwo auftauchen identifiziert und die Urheber des Lecks (eben der jeweilige Kunde) nach Zivilrecht in Regress genommen wird - mache dies Teil des Vertrages.

Ist meiner Meinung nach die einzige effektive Maßnahme.

Alle technischen Maßnahmen scheitern schon an dem grundlegenden Widerspruch:

1. Dem Kunden wird nicht vertraut
2. Das Programm muß auf dem System laufen, weswegen Schlüssel oder ähnliches mitgegeben werden muß ...

Besonders absurd wird es wenn sichere kryptographische Maßnahmen benutzt werden, aber dieser Widerspruch dem Entwickler nicht bewußt ist - das ist wie der sprichwörtliche Hausschlüssel unter der Fußmatte. Jeglicher Aufwand auf technischer Ebene ist im besten Falle geeignet Anfänger vom Kopieren abzuhalten und im schlechtesten Falle zahlende Kunden zu verprellen wenn der Kopierschutz spinnt ...

[generic]

Kauf die dir lieber etwas z.B. THEMIDA.
http://www.oreans.com/themida.php
Das kompiliert ASM Code zu anderen CPU Typen.
Das macht das Debuggen schwieriger, da die meisten Programmierer nur einen CPU-Typ beherrschen aber nicht 10.
Und für 149€ bekommst du das nicht selbst nach programmiert.

[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