Software Protection - Methoden

[nathex]

Nabend,

Also wie man der Ueberschrift schon entnehmen kann, suche ich nach Methoden um eine, in C++ geschriebene Software moeglichst gut vor Crackern schuetzen zu koennen.

Diese Methoden koennen in Form von Code Snippets oder auch Protection-Tools (wie z.b. rlpack oder armadillo) sein. Allerdings sollten sie halt so sicher wie moeglich sein.

Am besten waere natuerlich ein "Guide" wie man seine Tools effektiv schuetzt und es so den Crackern schwer macht. (Mir ist schon klar, dass man eine Software nicht "uncrackbar" machen kann. Man kann allerdings die Zeit bis die Software gecrackt wird verzoegern!)

Sooo... vielen Dank schonmal an die Leute die mir hier Ihre Methoden verraten werden.

#Edit: An die ganzen Klugscheisse und Spammer hier -> Ich hab sowohl google als auch die SuFu benutzt. Das einzige was ich bei Google finden konnte war ein Thread zum Schutz vor Crackern aus dem Jahr 1998.. Ich denke mal, dass die Methoden darin nichtmehr ganz so aktuell sein werden :D

greetZ, nathex

[snify]

Da gibt es 5 Möglichkeiten:

1. Du nimmst einen Crypter (private oder public).
Allerdings wird es bei public Crypter oft das Problem geben, dass die dann AVs detected werden. (z.B. Themida etc...)

2. Du cryptest deine Datei nur Scantime (also ein Dropper).
Du machst dein Programm also nur zugänglich, wenn es auch wirklich ausgeführt wird (oder schon im Arbeitsspeicher ist). Problem ist: Wenn du dein Programm z.B. auf TEMP droppst, kann man mit Tools herausfinden, welche Dateien dann auf deine Festplatte geschrieben wird.

3. Stichwort: Obusfactor

4. Du verschlüsselst deine Strings, Variablen, Funktionen etc...
Somit wird das cracken schwieriger.

5. Schreibe ein paar AntiDebugging Funktionen. Bzw. schau dir mal das PE Format an, da gibts es auch Tricks, wie du dein Programm vor OllyDbg schützst etc...

Ich hoffe, ich konnte dir helfen.
Eigentlich gibt es keine anderen Möglichkeiten....

[DizzY_D]

Zuerst gilt hier die Grundregel sich nicht auf einen guten Protector zu verlassen. Denn wenn du zwar eine starke Protection verwendest, aber eine unsichere Lizensüberprüfung, ist das cracken trotz Protection kein Problem mehr. Trotzdem würde ich dir zu einem guten Protector raten (EXECryptor/Themida).
Für welche Art von Lizensierungssystem hast du dich denn entschieden?
Hardware-ID? Lizensdateien? Registriercodes?

[fred777]

Also wie DizzY_D (http://free-hack.com/member.php?u=39579) schon sagte, EXECryptor z.B. ist ein ganz netter PRotector, macht dein Tool aber nicht uncrackbar.
Anti-Debugging-Methoden bringen es, zumindest die meisten, ebenso wenig, da die meisten Cracker "vollgestopfte Debugger" (mit Plugins) benutzen, welche kleine Mechanismen wieder automatisch außer Kraft setzen...
Das wichtigste ist wie schon gesagt die Prüfung der Lizens, so kannst du z.B. deinen Algorithmus möglichst kompliziert und über viele Umwege leiten..

[blackberry]

Ich hab mal kurz zwei Sachen zusammengeschrieben.

Der erste Code sollte die meißten User-Mode Debugger erkennen und versucht auch Debugger zu erkennen, die das BeingDebugged-Flag löschen. (danke an EBFE für die Idee)

Der zweite Code sollte die meißten Debugger aus der Bahn werfen, da dort versucht wird den Debugger Befehle vorzugaukeln, wo keine Befehle sind. Diese Befehle überlappen sich dann mit den eigentlichen Befehlen und verstrecken diese somit.

http://nopaste.free-hack.com/index.php?id=af1c1a9f64
http://nopaste.free-hack.com/index.php?id=19f4ff25c0

Interessant ist vielleicht noch diese Seite:
http://www.woodmann.com/crackz/Tutorials/Protect.htm


Zu beachten wäre hierbei, dass solche Methoden sehr leicht zu erkennen und auszulöschen sind.
Ein etwas besserer Schutz wäre vielleicht, dass im Programm die Hardware-ID benutzt wird und anschließend zur entschlüsselung des eigentlichen Programmcodes benutzt wird. (also: HardwareID = Schlüssel)
Das wäre zwar immernoch nicht der prefekte Schutzmechanismus, jedoch bräuchte der Reverser eine funktionierende HardwareID um das Programm überhaupt richtig ausführen zu können!


mfG. BlackBerry

[wacked]

wäre es nich bei ner hardware id möglich einfach das
if(GetHardwareID()==hashedID){ einfach zu ersetzen. Also auf lowlevel wäre das ja ein je den man nur nach jne umändern müsste?

[blackberry]

Deshalb sage ich ja:
Den Hauptprogrammcode mit der HardwareID verschlüsseln.
Dein kleines ASM Stub Programm berechnet dann diese HardwareID und versucht den Code zu entschlüsseln.
Danach wird einfach auf den Code gesprungen.

Stimmt die HardwareID nicht, wird das Programm einfach eine Fehlermeldung geben (wenn man Maschienencode falsch entschlüsselt kommen mit einer sehr hohen Wahrscheinlichkeit Befehle dabei raus, die das Programm crashen - aber das wollen wir ja: es soll nicht auf anderen Rechnern funktionieren)

Stimmt die HardwareID hingegen, werden die richtigen Maschienenbefehle dabei rauskommen und man kann das Programm ausführen.

Die "richtige" HardwareID wird im Programm also nicht gespeichert.

[EBFE]

@nathex: es geht um Grundlagen/Prinzipien und diese veralten nie ;)
http://www.s-a-ve.com/faq/Anti-Cracking-Tips-2.htm
http://www.hackerboard.de/thread.php?threadid=37963 (und nein, der großteil der Tipps ist sprachübergreifend bzw. lässt sich sogar besser in inc(C) realisieren, als in NET).

Ich erinnere mich immer noch gerne an eine mit EXECrypter geschützte Anwendung (zur Zeiten, als es noch keine "NoExeCrypterOllyDbgMod" gab und auch keine Tuts von Haggar, wie man EC umgeht ;) ), die >100 Zeichen langen Key gebraucht hat und eine ellendlange Generationsroutine. Dummerweise wurde der Schlüssel am Ende mit etwas "strcmp" artigem verglichen - ein Selfkeygen war dann auch trotz EC kein Problem :). Dasselbe lässt sich auch über Themida sagen. Sofern das Prinzip an sich simpel ist, hilft ein Protektor auch nur wenig. Ganz witzig waren noch selbtentwickelte, kommerzielle Protectoren von *hust* VBlern. Da waren auch Tipps mitdabei, wie man sich vor Crackern schützen kann:
Zitat: "schreiben sie ihre wichtigen Strings nie im Klartext, sondern maskieren sie diese über Chr(65)+Chr(70) usw." :D
Entsprechend war auch der Schutzlevel - der Key wurde letzlich im Klartext verglichen. Netterweise waren auch die ganzen Referenzen auf der Webseite. Die Proteciton wurde von über 50 Softwareautoren eingesetzt. Mit etwas Aufwand könnte man einen "Generic Selfleygen" machen, der dann Keys für alle diese 50 Anwendungen herausspuckt :rolleyes:


Grundsätzlich würde ich an deiner Stelle keine Zeit mit Antidebugmethoden und eigenem PE-Gewurschtel verschwenden. Es gilt wie immer: ein (normaler) Cracker beschäftigt sich schon Monate, wenn nicht Jahre damit und man kann einfach nicht nach 3 Tagen sich irgendwelche Tricks ausdenken, die ihn ernsthaft behindern ;). Man sollte sich darauf beschränken, was man kann - nämlich programmieren.


@snify: 90% der "private Crypter" kannst du knicken. Lassen sich leichter entpacken als UPX. Option 4 bringt nur bei NET etwas. In nativen Sprachen werden weder Variablennamen noch sonstiges übernommen (es gibt nur noch Adressen ;) ). Allerdings ist es nicht schlecht, darauf zu achten, auch nur Release-Versionen weiterzugeben. Denn die Debugversionen beinhalten netterweise (für den Cracker) nützliche Infos.


PS: hier ist noch ein Ansatz, welcher sich sowieso super mit C/C++ umsetzen lässt:


program proc_demo;

type tProc=PROCEDURE;

var zeiger:POINTER;
var proc:tProc;
var eingabe:string;

procedure demo; FAR;
begin
writeln('hello');
end;

procedure false;
begin
write('falsch');
end;

function super_hash(ein:string):pointer;
var toInt:longint;
var code:integer;
var temp:string;

begin
temp:=ein[1]+ein[2]+ein[3]+ein[4]+ein[5]+ein[6]+ein[7]+ein[8]+ein[9];
val(temp,toInt,code);
super_hash:=POINTER(toInt);
end;

begin
readln(eingabe);
zeiger:=super_hash(eingabe);
{hier sollte noch ein CRC/Try Catch rein}
proc:=tProc(zeiger);
proc;

writeln(LongInt(@demo)); { Adressermitltung }
readln;
end.
ist zwar eine Demo in Pascal - es geht aber im Prinzip um folgendes: man bildet aus dem Userkey und Hardwareid einen Hash, nimmt davon bestimmte Stellen (die Funktion darf so groß sein, wie man mag :) ) und setzt aus diesen Stellen letzendlich eine Funktionsadresse. Z.B einer wichtigen "vorinitialisierungsfunktion".

also in C:


int myaddr=super_ultra_hash_mit_junkcode(hardwareid,ke y);
void (*func) (parameter_die_man_braucht);
func=(void*) myaddr;
if (crc_check(myaddr)!=12345) show_msg("Registriere Dich!!!!");
else func(param1,param2...);

Es wird also eine Adresse gebildet. Man kann sie vor dem Aufruf noch prüfen und gegebenfalls eine nette Meldung ausgeben. Patchen bringt an dieser Stelle dem Cracker nur einen Programmabsturz.

Das ist im Prinzip wieder den Ansatz von BlackBerry ähnlich (man speichert keine HarwareID im Programm) - allerdings braucht man kein InlineAsm und kann HWID-"Get" Funktion in C++ mit Makros usw schreiben (und damit möglichst gut aufblähen).

[snify]

ooops.
sorry, hab die Frage falsch verstanden...
es ging um die Lizenzierung, bzw. Schutz von Shareware etc.
Ich dachte es ging hier hauptsächlich NUR um Anti-Reverse Methoden, die verhindern, den Source zu klauen etc. Tut mir Leid :/

[nathex]

So, danke erstmak fuer die ganzen Antworten :)

Für welche Art von Lizensierungssystem hast du dich denn entschieden?
Hardware-ID? Lizensdateien? Registriercodes?
Was waere denn da am sichersten, deiner Meinung nach? Ich glaube du hattest mit ein paar anderen Leuten den Trojka 3 gecrackt oder?
Wo waren da die Schwachstellen, welche den Trojka trotz hw-id "crackbar" machten? Und welcher Schutz macht es Crackern am schwersten?

[l0dsb]

Hardware-IDs sind so lange sinnvoll, wie sie richtig implementiert werden. Vergleiche lassen sich generell leicht umbiegen (Trojka), im Falle der Verschlüsselung mit der Hardware-ID müsste man bruteforcen oder - wie es üblicher ist, Beispiel: Prinzip der Secured Sections - die Daten mit einem richtigen Key entschlüsseln.

Im Trend liegt heutzutage (zu Recht) die Virtualisierung (RLP, EC, TM, WL, SD, SC, SF, ... die Liste lässt sich natürlich noch weiter führen). Was eine virtuelle Maschine im Bezug auf Softwareschutz ist, verrät Google. ;)

[EBFE]

Vor allem war bei Trojka die Umwandlung der HardwareIDs in Strings total unnötig. Denn arbeiten kann man auch mit Bytearrays - Strings sind dagegen im Speicher viel auffälliger. Und es lief letzendlich alles auf "if HardwareID=einprogammierter String then" hinaus. Da half auch nicht, den eigentlichen Stringcompare zu verschleiern. Btw: wie gesagt: die Tipps von Lazarus aus den 1998gern sind immer noch aktuell ;). Natürlich hat man inzwischen mehr technische möglichkeiten (siehe VMs - früher war die Performance einfach unzureichend). Aber imho sollte erstmal das Konzept gut sein und der technische Kram als netter Zusatz betrachtet werden ;)

[Qgel]

Gibt übrigens auch nen ziemlich guten Artikel zum Thema Anti-Debugging auf CodeProject (mit code-snippets und erklärungen).

Schau mal hier:
http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx