HWID System sicherer machen

Page 1 of 2

12/05/2011 06:59 .Infinite#1

Ich habe bis jetzt ein einfaches HWID System: Beim Start des Programms wird die HWID an ein PHP-Skript �bergeben, dass dann �berpr�ft, ob die HWID in der Datenbank eingetragen ist.

Jetzt ist es aber m�glich, die Anfrage des Programms auf ein lokales Skript und eine lokale Datenbank umzuleiten... Wie k�nnte man das verhindern?

Ich hatte daran gedacht, dass ich vom Programm zus�tzlich noch eine Zufallszahlenfolge generieren lasse, die dann vom Skript mit einem statischen Passwort verschl�sselt wird. Die vreschl�sselten Zeichen werden zur�ckgegeben und das Programm �berpr�ft diese. W�rde das funktionieren? Wie sicher w�re es?

Au�erdem w�rde mich interessieren, ob es bei einem solchen System noch weitere Sicherheitsl�cken gibt.

Vielen Dank im Vorraus f�r jede gute Idee ;)

12/05/2011 12:45 Dr. Coxxy#2

kommt drauf an...

wenn das programm sowieso schon alles hat, also nur eine �berpr�fung auf registered auf deinem server macht w�rde ich mich eher auf einen packer/crypter und anti debugging ma�nahmen konzentrieren.
ich als reverser w�rde zumindest da ansetzen, anstatt zu versuchen eine mir unbekannte datenbank, eventuell mit timestamps etc. nachzubauen.
(wie diese aussieht, kann ich evtl. nat�rlich aus den packets entnehmen, die sollten also zumindest simpel verschl�sselt sein...)
wenn du merkst, dass du debuggt wirst, oder �hnliche seltsame sachen in deinem speicher sind, gibst du keine fehlermeldung aus "hey, ich werde debuggt!!!111", sondern setzt nen flag und l�sst dein programm noch ein wenig weiterlaufen.
nach ner weile springst du dann ein wenig ins leere (__asm jmp rand(); ), oder �berschreibst die adresse einer funktion o.�... alles halt, was zu einem 'unerkl�rlichem' programmabsturz f�hrt...
das sollte reichen um einen 0815-reverser zu bremsen...

wenn du das programm/funktionen aber von deinem server in eine art "interpreter"/"clienten" reinstreamst, reicht idr. die hwid �berpr�fung/login.
solltest nat�rlich auch wieder verschl�sseln, und in den gestreamten code dann ein paar zeitstempel �berpr�fen und eine 2. login sequenz durchf�hren, damit nicht einmal die gestreamten daten mitgeloggt werden, und dann einfach ins programm reingestreamt werden^^
das wieder auseinanderzunehmen ist dann eine sache f�r leute wie dbs, die eh nix zu tuen haben...

12/05/2011 14:14 .Infinite#3

Quote:

wenn das programm sowieso schon alles hat, also nur eine �berpr�fung auf registered auf deinem server macht w�rde ich mich eher auf einen packer/crypter und anti debugging ma�nahmen konzentrieren.

Ja, alle Funktionen sind schon im Programm drin. Wie kriege ich es denn hin, die zur Laufzeit zu streamen? Ist das nicht ziemlich langsam? Und liegt der Code nicht so oder so im Speicher?

Quote:

wie diese aussieht, kann ich evtl. nat�rlich aus den packets entnehmen

Wie willst du das denn machen? Das Programm sendet ein Packet (HTTP Get mit HWID als Parameter) und bekommt als Antwort auch nur ein Packet, in dem steht ob die HWID g�ltig ist oder nicht. Ich sehe nicht, warum man da was verschl�sseln sollte...

Quote:

wenn du merkst, dass du debuggt wirst

Woran merke ich das denn? Meine Kenntnisse im Bereich reverse engineering sind eher d�rftig.

Ich gucke gerade nochmal, was es f�r M�glichkeiten per SQL-Injection geben w�rde...

Auf jeden Fall Danke schonmal bis hier :handsdown:

12/05/2011 14:21 Dr. Coxxy#4

kommt drauf an, wie du das realisierst, wird im zweifelsfalle aber wirklich langsamer sein, und ist recht kompliziert.

packets mit wireshark o.�. abfangen, aus dem not registered ein registered machen...

gibt diverse methoden um zu sehen ob man debuggt wird, ich hab hier i-wo ne pdf mit anti debugging methoden liegen, such ich gleich mal raus und lads hoch.

EDIT: da ist es
sowas wie IsDebuggerPresent und nach window/processnamen suchen ist sehr weit verbreitet, da hat jeder schon nen fertiges plugin in z.b. ollydbug mit dem die umgangen werden, die anderen methoden sind aber interessanter :D

12/05/2011 14:32 .Infinite#5

Quote:

kommt drauf an, wie du das realisierst, wird im zweifelsfalle aber wirklich langsamer sein, und ist recht kompliziert.

Das guck ich mir auf jeden Fall mal an. H�rt sich interessant an :)

Quote:

packets mit wireshark o.�. abfangen, aus dem not registered ein registered machen...

Dann verschick ich halt statt einer flag einfach nen hash mit Checksumme oder so

Quote:

�gibt diverse methoden um zu sehen ob man debuggt wird, ich hab hier i-wo ne pdf mit anti debugging methoden liegen, such ich gleich mal raus und lads hoch. (ca 40 min...)

Danke :)

12/05/2011 16:16 MrSm!th#6

Quote:

Jetzt ist es aber m�glich, die Anfrage des Programms auf ein lokales Skript und eine lokale Datenbank umzuleiten... Wie k�nnte man das verhindern?

Gar nicht. Bau halt ne Verschl�sselung ein, sodass der Cracker nicht einfach auf ne Seite wie "success" umleitet und dann klappts.

�brigens ist der ganze Kram total sinnlos und auch eine Verschl�sselung macht es nur bedingt sicherer (gleiches gilt f�r Checkvalues, die kann man alle reversen).
Die sicherste Variante ist es, das Programm ohne Server nicht lauff�hig zu machen.
Das hei�t, du kannst bestimmte Code-Teile vom Server beziehen oder du l�dst wichtige Dlls nach oder das Executable ist verschl�sselt und der Server sendet den Decryption Key.

Alles andere ist nur eine geringe Verz�gerung f�r den Cracker.

Quote:

Ich sehe nicht, warum man da was verschl�sseln sollte...

Damit man eben nicht einfach mit nem kleinen recv Hook oder eigenen Seite + Umleitung nen Crack fertig hat :rolleyes:
Brauchst ja nur die empfangenen Daten modifizieren und peng, l�uft alles.

Quote:

Woran merke ich das denn? Meine Kenntnisse im Bereich reverse engineering sind eher d�rftig.

Ich gucke gerade nochmal, was es f�r M�glichkeiten per SQL-Injection geben w�rde...

Auf jeden Fall Danke schonmal bis hier

Gibt hunderte Methoden und auch hunderte, um die Detections zu bypassen.

Quote:

Dann verschick ich halt statt einer flag einfach nen hash mit Checksumme oder so

Dann baut man den entweder nach oder breakt einfach mal auf recv und sieht sich deinen Check an, das wird ja sicherlich nur so ein simples if(registered && valid_hash) sein, das sind 2 kleine Conditional Jumps, die man da patchen muss.

Code Streaming ist nicht langsam, wenn man es richtig macht und es kann ziemlich effektiv sein.

12/05/2011 19:31 .Infinite#7

Hmm... Ich verstehe ehrlich gesagt nicht, wie das funktionieren soll, den Programmcode zu streamen. Muss ich nen eigenen Interpreter schreiben, der den Code zur Laufzeit ausf�hrt oder wie funktioniert das?

Zudem m�sste ich ja dann wieder den kompletten Stream verschl�sseln... Verdammte Reverser! So toll sind meine Programme nun auch wieder nicht, dass ich einen gr��eren Aufwand zum Sch�tzen betreibe als f�r das eigentliche Programm -.-

12/05/2011 19:45 MrSm!th#8

Du musst nicht zwingend verschl�sseln, da der Reverser ja nicht sofort wei�, was Daten und was Code Instruktionen sind.
Er wei� vermutlich nichtmal, dass �berhaupt Code ausgef�hrt wird und sucht gar nicht danach.

Du musst nichts interpretieren, du schreibst doch schon in C++, das ist doch so sch�n hardwarenahe, sei doch etwas kreativ :P

Code:

//grundlegendes prinzip:

char buffer[xxx];

//empfangen

__asm call buffer;

//oder:

FunktionsPtr = (FunktionsPtrTyp)buffer;
FunktionsPtr(arg1,arg2,...);

Eventuell musst du vorher den Buffer noch als PAGE_EXECUTE_READWRITE markieren, damit es keine Access Violation produziert.

12/05/2011 21:30 .Infinite#9

Quote:

Code:

//grundlegendes prinzip:

char buffer[xxx];

//empfangen

__asm call buffer;

//oder:

FunktionsPtr = (FunktionsPtrTyp)buffer;
FunktionsPtr(arg1,arg2,...);

Das ist ja genial :P Mal gucken ob es funktioniert.

12/06/2011 01:13 Saedelaere*#10

Es gibt noch eine einfachere Methode, die auch ohne Server auskommt. Und zwar generierst du f�r jeden Kunden eine individuelle EXE. Danach verschl�sselst du wichtige Teile des Codes mit einem sicheren Algorithmus, wie z.b. RC5 oder AES. Als Encryption Key benutzt du die HWID des Kunden.

Beim Start des Programms, wird jetzt die aktuelle HWID ausgelesen und die vorher verschl�sselten Codestellen im Speicher wieder decrypted.
Stimmte die HWID �berein, ist das Programm nun lauff�hig. War die HWID falsch, so wurden die Codeteile falsch entschl�sselt und das Programm crasht.
Den Crash kann man noch verhindern, indem man die decrypteten Codestellen mit einer vorher in der EXE gespeicherten Pr�fsumme vergleicht.

Wie bei allen Schutzmechanismen, die auf diesem Prinzip basieren, also sowohl meine Methode, als auch das Code Streaming, kann die Anwendung aber sehr einfach von einem legitimen Kunden geleaked werden, da dieser ja logischerweise vollen Zugriff auf alle Codeteile besitzt.

12/06/2011 13:21 MrSm!th#11

Dein System ist aber nicht besonders praktikabel, man kann nicht f�r jeden eine EXE generieren. Sinnvoller ist es, das Programm mit einem Key zu verschl�sseln, welcher aus einer validen Serial berechnet werden kann, die wiederum abh�ngig von der HWID ist.

12/06/2011 15:52 Saedelaere*#12

Hatte mir mal ein Script geschrieben, mit dem man individuelle EXEn generieren konnte. Das konnte man dann ganz komfortabel auf nem Webserver laufen lassen.

Aber da der Aufwand zum Protecten bekanntlich nicht h�her sein soll, als der Programmieraufwand f�r das Tool selbst, nimmt man am besten eh fertige L�sungen, wie Themida oder VMProtect.
Sowas kombiniert mit dem von dir vorgeschlagenen Code Streaming sollte schon ziemlich sicher sein.

12/06/2011 16:23 Dr. Coxxy#13

Quote:

Originally Posted by MrSm!th

Code:

//grundlegendes prinzip:

char buffer[xxx];

//empfangen

__asm call buffer;

//oder:

FunktionsPtr = (FunktionsPtrTyp)buffer;
FunktionsPtr(arg1,arg2,...);

das war was ich mit meiner ersten methode meinte, gegen die meisten 'reverser' reichen einige der antidebugging methoden aus meiner pdf und damit sich leute daf�r richtig interessieren, musst du schon was gr��eres machen^^

12/06/2011 17:12 .Infinite#14

Hmm, was mache ich falsch?

Code:

        typedef void (*pointer_to_function)();

	char* buffer= new char[255];
	VirtualAlloc(buffer, sizeof(buffer), MEM_RESERVE, PAGE_EXECUTE_READWRITE);
	sprintf(buffer, "std::cout << \"test\";");
	
	pointer_to_function fptr;
	fptr = (pointer_to_function)buffer;
	fptr();

12/06/2011 19:49 MrSm!th#15

Quote:

Originally Posted by .Infinite

Hmm, was mache ich falsch?

Code:

        typedef void (*pointer_to_function)();

	char* buffer= new char[255];
	VirtualAlloc(buffer, sizeof(buffer), MEM_RESERVE, PAGE_EXECUTE_READWRITE);
	sprintf(buffer, "std::cout << \"test\";");
	
	pointer_to_function fptr;
	fptr = (pointer_to_function)buffer;
	fptr();

Wtf? Verarschst du mich? Du wei�t doch, dass C++ eine native Sprache ist.
Du kannst doch keinen Quelltext direkt ausf�hren o.O
Du musst kompilierten Code senden.
Und Funktionsaufrufe klappen selbstverst�ndlich nicht, da die Adressen der Funktionen ja im lokalen RAM v�llig anders sind.

Testweise k�nntest du folgendes kompilieren und streamen:

Code:

int func(int a, int b)
{
return a+b;
}

Solltest du die Funktion komplett senden (samt Stackframe etc. nat�rlich; f�r den Anfang kannst du ja einfach die Bytes des kompilierten Codes aus Olly kopieren und in ein Byte Array einf�gen) dann solltest du in deinem lokalen Programm bei

Code:

//reihenfolge h�ngt nat�rlich von der calling convention ab;
//ich denke mal es ist hier __cdecl
__asm push a; // a=1
__asm push b; // b=2
__asm call buffer;
//jetzt mal ohne die funcptr variante

3 herausbekommen.
Musst nat�rlich im Falle von inline ASM den return Wert manuell aus eax auslesen.

Quote:

Originally Posted by Saedelaere*

Hatte mir mal ein Script geschrieben, mit dem man individuelle EXEn generieren konnte. Das konnte man dann ganz komfortabel auf nem Webserver laufen lassen.

Aber da der Aufwand zum Protecten bekanntlich nicht h�her sein soll, als der Programmieraufwand f�r das Tool selbst, nimmt man am besten eh fertige L�sungen, wie Themida oder VMProtect.
Sowas kombiniert mit dem von dir vorgeschlagenen Code Streaming sollte schon ziemlich sicher sein.

Naja, ich halte es trotzdem f�r sinnvoll, wenn nicht jeder Kunde eine individuelle Exe anfragen muss, vor allem bei gr��eren Projekten, aber das ist wohl teilweise auch Geschmackssache.
Es auch nicht besonders schwer, zu implementieren, dass sich eine Exe f�r alle mit allen validen HWIDs entschl�sseln l�sst.
Am besten ist nat�rlich noch, wenn man regelm��ig die Abh�ngigkeit von HWID zu Key �ndert und die neue dann vom Server empf�ngt (nur bei korrekter Registration) und so die Leaking-Gefahr verringert.
Aber zumindest eine Serial w�rdest du auch ohne das regelm��ige �ndern verkaufen :D

Page 1 of 2