@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."
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
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:
Code:
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:
Code:
int myaddr=super_ultra_hash_mit_junkcode(hardwareid,key);
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).