Hagens Methode eine Datei zu schützen

[jus]

Hi,
Ich bin beim Durchlesen von alten Artikeln auf eine für mich persönlich sehr interessante Methode von Hagen gestossen, ein Programm zu schützen - siehe hier
Als Programmieranfänger würde mich sehr sehr interessieren wie man so was hinbekommt. :-D
Den relevanten Teil markieren mit ASM Anweisung mit "CODESTART" und "STOPCODE" markieren und mit einem externen Programm die passende Stelle dazwischen verschlüsseln, das würde ich noch hinkriegen.

Nun meine Fragen:
-Doch wie kann ich während das Programm läuft, das Programm im Speicher entschlüsseln und die Funktionen darin aufrufen? :pale:
-wie kann man das von Hagen genannte "Structured Exception Handling = SEH" realisieren ?



jus

[jus]

*push* :)

jus

[jus]

Kann mir denn wirklich keiner helfen? :cry:

Da es anscheinend niemand interessiert, muß man sich selbst helfen. :???: Die letzten paar Tage habe ich versucht etwas brauchbares in die Richtung zu finden. Nun bin ich auf den Befehl "ReadProcessMemory" und "WriteProcessMemory" gestossen. Vielleicht kann mir diesesmal jemand sagen, ob ich mich auf den richtigen Weg befinde, oder es eine Sackgasse ist.

Nun meine Fragen dazu:

-Kann ich einfach ohne jegliche Vorbereitung einfach den entschlüsselten Programmteil zwischen "CODESTART" und "STOPCODE" mit WriteProcessMemory in meine markierte Programmstelle reinschreiben?
-und wie finde ich die markierte Stelle bei einem laufenden Programm im Speicher?

Vielen vielen Dank für die Antwort im voraus! :)

jus

[himitsu]

Ich würd mal sagen irgendwie so:

Delphi-Quellcode:

function StartCode: PChar; 
asm 
     MOV  EAX,OFFSET StartMarker 
     RET 
StartMarker: 
     DB   'CODESTART'#0 
end; 

procedure ProtectedCode; 
begin 
.... 
end; 

procedure StopMarker; 
asm 
      DB  'STOPCODE'#0 
end; 

function StopCode: PChar; 
asm 
      MOV  EAX,OFFSET StopMarker + 9 
      RET 
end;

procedure Encode(P: Pointer; Len: Integer);
begin
  //hier halt irgendwie enschlüsseln
end;

Delphi-Quellcode:

// speicher reservieren
P := GetMem(StopCode - StartCode);
// code von der Datei (diese wird ja in deinen RAM gemappt) kopieren
Move(StartCode, P, StopCode - StartCode);
// den code entschlüsseln
Encode(P, StopCode - StartCode);
// entschlüsselten code ausführen
P2 := P + (ProtectedCode - StartCode);
ASM
  CALL &P2
End;
// Speicher wieder freigeben
FreeMem(P);

!!! keine Garantie, daß mein BeispielCode funktioniert, ist halt nur ein grobes Beispiel

[jus]

@himitsu
Zunächst vielen vielen Dank! Leider funktioniert es nicht.
Ich versuche mit Readprocessmemory die CodeStart Stelle bis Stopcode auszulesen.

Delphi-Quellcode:

ReadProcessMemory(HandleWindow,ptr(SpeicherAdresse),buf,CodeGroesse,BytesRead);

Das Problem ist nur, dass ich überhaupt nicht weiß, wie ich die Codestart Stelle als SpeicherAdresse für Readprocessmemory finden/übergeben kann.
Ich habe sogar versucht mit folgendes Adresse zu finden. Leider ohne Erfolg. :(

Delphi-Quellcode:

function CodeGroesse: Integer;
asm
  mov eax,offset StopMarker
  sub eax,offset Startcode;
  ret
end;

function Startmarkierung:DWORD;
asm
  MOV  EAX,OFFSET Startcode
  RET
end;

procedure Speicherauslesen;
//..
begin
//..
  ReadProcessMemory(HandleWindow,ptr(Startmarkierung),buf,CodeGroesse, BytesRead);
//..
end;

jus

[Luckie]

Motzi hatte mal so etwas als Anticrackschutz implementiert. War aber etwas kompliziert. Schreib ihm mal eine PN und weis ihn auf diesen Thread hin. Kan aber sein, dass er nicht gleich antwortet, weil er zur Zeit ziemlich beschäftigt ist.

[jus]

@Luckie
Werde ich machen, vielen Dank für den Tipp!

Ich habe zumindest den ersten Schritt, die markierte Stelle im Speicher zu finden, nun hingekriegt. :dancer:

Delphi-Quellcode:

procedure StartMarker;
asm
  DB 'CODESTART',0
end;

procedure ProtectedCode;
begin
  showmessage('protected Code wird ausgeführt');
end;

procedure StopMarker;
asm
  DB  'STOPCODE',0
end;

function StopCode: PChar;
asm
  MOV  EAX,OFFSET StopMarker
  RET
end;

function StartCode: PChar;
asm
  MOV EAX,OFFSET StartMarker
  RET
end;

function CodeGroesse: Integer;
asm
  mov eax,offset StopMarker
  sub eax,offset StartMarker;
  sub eax,10
  ret
end;

function Startmarkierung:DWORD;
asm
  MOV  EAX,OFFSET StartMarker
  ADD  EAX,10
  RET
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  ProcessId : DWORD;
  ThreadId : DWORD;
  Dest: TStream;
  ProcessHandle: THandle;
  Buffer: Pointer;
  Size: DWORD;

begin
  ThreadId := GetWindowThreadProcessId(Handle,@ProcessId);
  ProcessHandle := OpenProcess(PROCESS_ALL_ACCESS,False,ProcessId);

  Buffer:=AllocMem(CodeGroesse);
  ReadProcessMemory(ProcessHandle, ptr(StartMarkierung), Buffer, CodeGroesse, DWORD(nil^));

  //Den Buffer in eine Datei speichern zu Testzwecken
  Dest := TFileStream.Create('testpart.bin', fmCreate);
  Dest.WriteBuffer(buffer^, CodeGroesse);
  Dest.Free;

  FreeMem(buffer);
  closehandle(ProcessHandle);
end;

[himitsu]

Wie gesagt, wenn du innnerhalb deines eigenen Programms daten auslesen willst, kannst du das direkt machen und mußt nicht über Read-/WriteProcessMemory gehen.

Delphi-Quellcode:

Var P: Pointer;

P := StartCode;

Du hast also sofort einen Pointer auf den StartCode, welchen man z.B. einfach kopieren könnte

Delphi-Quellcode:

Var P: Pointer;

P := GetMem(StopCode - StartCode + 1);
Move(StartCode, P, StopCode - StartCode + 1);

Und schon hast du eine Kopie des Codes in einen neuen Speicherbereich (P) kopiert und kannst damit machen, was du willst.

z.B. den ausgelesenen Teil wieder entschlüsseln und dann die enthaltene Prozedur aufrufen.
wobei im OriginalCode die Prozedur ProtectedCode ja eine bestimmte Anzahl an Bytes hinter der dem StartCode liegt, also liegt jetzt die entschlüsselte Prozedur die selbe Anzahl Bytes hinter dem StartCode im neuen Speicherbereich, wo du diese nun aufrufen könntest.

ProtectedCode - StartCode = Anzahl der Bytes (Abstand)

Delphi-Quellcode:

Var P, P2: Pointer;

P := GetMem(StopCode - StartCode + 1);
Move(StartCode, P, StopCode - StartCode + 1);
Encode(P, StopCode - StartCode + 1); {Pointer, Length}
P2 := P + (ProtectedCode - StartCode);
ASM
  CALL &P2
End; 
FreeMem(P);

Vergiß aber nicht die Hinweise von Hagen ... es darf nichts in der gesicherten Funktion/Prozedur drin sein, was mit relativen Sprüngen etwas außerhalb versucht anzuspringen, es sei denn du holst dir vorher die direkten adressen und springst diese an (wie hier z.B. die neue Adresse der Prozedure ProtectedCode ermittelt und angesprungen wurde).

[jus]

Zitat:

Zitat von himitsu

Wie gesagt, wenn du innnerhalb deines eigenen Programms daten auslesen willst, kannst du das direkt machen und mußt nicht über Read-/WriteProcessMemory gehen.

Delphi-Quellcode:

Var P: Pointer;

P := StartCode;

Du hast also sofort einen Pointer auf den StartCode, welchen man z.B. einfach kopieren könnte

Delphi-Quellcode:

Var P: Pointer;

P := GetMem(StopCode - StartCode + 1);
Move(StartCode, P, StopCode - StartCode + 1);

Und schon hast du eine Kopie des Codes in einen neuen Speicherbereich (P) kopiert und kannst damit machen, was du willst.

z.B. den ausgelesenen Teil wieder entschlüsseln und dann die enthaltene Prozedur aufrufen.
wobei im OriginalCode die Prozedur ProtectedCode ja eine bestimmte Anzahl an Bytes hinter der dem StartCode liegt, also liegt jetzt die entschlüsselte Prozedur die selbe Anzahl Bytes hinter dem StartCode im neuen Speicherbereich, wo du diese nun aufrufen könntest.

ProtectedCode - StartCode = Anzahl der Bytes (Abstand)

Delphi-Quellcode:

Var P, P2: Pointer;

P := GetMem(StopCode - StartCode + 1);
Move(StartCode, P, StopCode - StartCode + 1);
Encode(P, StopCode - StartCode + 1); {Pointer, Length}
P2 := P + (ProtectedCode - StartCode);
ASM
  CALL &P2
End; 
FreeMem(P);

@himitsu
Zunächst einmal vielen vielen Dank, dass du mich unterstützt bei meinem Vorhaben.
Ich bin eigentlich nur über ReadProcessMemory gegangen, weil "Move(StartCode, P, StopCode - StartCode + 1)" irgendwie Probleme (Exception wird ausgelöst) bereitet.

Zitat:

Zitat von himitsu

Vergiß aber nicht die Hinweise von Hagen ... es darf nichts in der gesicherten Funktion/Prozedur drin sein, was mit relativen Sprüngen etwas außerhalb versucht anzuspringen, es sei denn du holst dir vorher die direkten adressen und springst diese an (wie hier z.B. die neue Adresse der Prozedure ProtectedCode ermittelt und angesprungen wurde).

Das mit den relativen Sprüngen wird wohl noch eine Grosse Hürde sein. Aber derzeit suche ich noch eine Methode aus der project1.exe die relevante Stelle zwischen CODESTART und CODESTOP auszulesen.
Ein Problem, das ich auf mich zukommen sehe, ist, dass die Verschlüsselungslänge wahrscheinlich länger sein kann als die ursprüngliche Länge. Das muß ich auch noch irgendwie hinkriegen.
Also wenn jemand zu meinen Problem Lösungsvorschläge weiß, bin ich ganz Ohr. :cyclops:



jus

[negaH]

Zitat:

Ein Problem, das ich auf mich zukommen sehe, ist, dass die Verschlüsselungslänge wahrscheinlich länger sein kann als die ursprüngliche Länge.

Wieso ? Die meisten sicheren symmetrischen Algorithmen können Daten inplaced verschlüsseln. In meinem damaligem Anti-Cracking-Program habe ich direkt nach "CODESTART" noch 256 Bytes an Zufallsdaten eingebettet. Das "Registrationspasswort" ware ebenfalls per Zufall gewählt. Als Verschlüselungsalgo. hatte ich einen modifizierten RC4 benutzt. Suche mal hier in er CodeLib nach RCx.

Ich empfehle dir aber in meinem DEC den IDEA Cipher anzuschauen. Dieser Cipher hat asymmetrische Ver- und Entschlüsselungsfunktionen. Mit asymmetrisch sind nicht die bekannten Verfahren gemeint sondern in diesem Fall der fakt das die Verschlüsselungsfunktion nicht die gleiche ist wie die Entschlüsselungsfunktion, und das im matheamtischen Sinne eine inverse Funktion darstellt die das multiplikative Inverse benötigt. Erwähnen tue ich dies weil du nun zb. IDEA zerpflücken könntest und nur die Entschlüsselungsfunktion in deine EXE integrierst, mit leichten Abwandlungen. Nur wer die Ver-schlüsselungsfunktion dazu kennt kann also auch den Schutz deiner EXE reimplementieren und somit einen echten Keygen programmieren.

Gruß Hagen

[jus]

@negaH
Hallo Hagen, ich hatte gehofft, dass du zurückschreibst. :)

Zitat:

Zitat von negaH

Wieso ? Die meisten sicheren symmetrischen Algorithmen können Daten inplaced verschlüsseln. In meinem damaligem Anti-Cracking-Program habe ich direkt nach "CODESTART" noch 256 Bytes an Zufallsdaten eingebettet. Das "Registrationspasswort" ware ebenfalls per Zufall gewählt. Als Verschlüselungsalgo. hatte ich einen modifizierten RC4 benutzt. Suche mal hier in er CodeLib nach RCx.

Ups, ich hatte noch die verschlüsselten Dateien von einem anderen Beitrag im Kopf. Ich habe nicht berücksichtigt, dass die Dateien nur deswegen größer sind, weil noch Head Daten wie Größe und Salt enthalten. Sorry. :oops:
Da ergibt sich die Frage, ob ich hier den Salt verwenden und mitspeichern soll oder reichen hier wie in deinem Fall 256 Bytes an Zufallsdaten, die ich am Anfang des zu verschüsselnden Codes anhänge und es durch die DEC Verschlüsselung durchjage? Oder beides?

Zitat:

Zitat von negaH

Ich empfehle dir aber in meinem DEC den IDEA Cipher anzuschauen. Dieser Cipher hat asymmetrische Ver- und Entschlüsselungsfunktionen. Mit asymmetrisch sind nicht die bekannten Verfahren gemeint sondern in diesem Fall der fakt das die Verschlüsselungsfunktion nicht die gleiche ist wie die Entschlüsselungsfunktion, und das im matheamtischen Sinne eine inverse Funktion darstellt die das multiplikative Inverse benötigt. Erwähnen tue ich dies weil du nun zb. IDEA zerpflücken könntest und nur die Entschlüsselungsfunktion in deine EXE integrierst, mit leichten Abwandlungen. Nur wer die Ver-schlüsselungsfunktion dazu kennt kann also auch den Schutz deiner EXE reimplementieren und somit einen echten Keygen programmieren.

Gruß Hagen

Meinst du mit dem IDEA "zerpflücken", dass ich sozusagen mit Copy und Paste nur den Entschlüsselungsquelltext aus dem DEC rausnehmen soll und es in meinem Programm integrieren soll, weil sonst Delphi den TCipher_IDEA.DoEncode mitkompiliert? Oder meinst du etwas anderes?
Das mit dem leichten Abwandlungen ist eine Sache für sich, ich wüßte/traue mich nicht ganz wie man den IDEA Algorithmus(procedure IDEACipher) so abzuwandeln, dass es nachher noch funktioniert, weil beim DEC IDEA anscheinend die procedure IDEACipher in TCipher_IDEA.DoDecode und in TCipher_IDEA.DoDecode verwendet wird. :coder2: Vielleicht könntest mir ja helfen. :cyclops:

Danke, dass du Dir die Zeitgenommen hast für mich!

jus

[negaH]

Was ich meine ist das du dir zb. IDEA als Beispiel anschauen sollst für deine Entscheidung bei der Auswahl des passenden Ciphers. IDEA ist patentiert und dürfte somit erstmal ausfallen. Aber die Idee hinter IDEA solltest du dir mal genauer anschauen.

@Salt:

Ja, wenn du einen Cipher benutzt der einen Feedbackmodus wie CTS/CBC/CFB/OFB benutzt. Das ist wichtig damit die 256 bytes Zufall am Anfang der zu verschlüsselnden daten auch Einfluß auf die nachfolgenden bytes haben. Der richtig Feedbackmodus sorgt also dafür das die 256 Bytes Zufall während der Verschlüsselung auch Auswirkungen auf die Daten danach haben. Also selbst wenn ein Angreifer wüsste das dein Code mit bestimmten Sequenzen beginnt so würde er denoch beim Knacken erstmal die exakten 256 Bytes Zufall finden müssen. Das dürfte unmöglich sein und somit kann er auch nicht an deinen Code rankommen selbst wenn er ihn partiell kennt.

Gruß Hagen

[jus]

@negaH

Zitat:

Zitat von negaH

Was ich meine ist das du dir zb. IDEA als Beispiel anschauen sollst für deine Entscheidung bei der Auswahl des passenden Ciphers. IDEA ist patentiert und dürfte somit erstmal ausfallen. Aber die Idee hinter IDEA solltest du dir mal genauer anschauen.

Ok, werde ich beherzigen. Ich hoffe nur, dass mir das nicht zu Steil wird. :) Wo gibt es eigentlich gute Unterlagen darüber? Ich habe mal IDEA im im Google eingegeben, das Problem ist nur, dass sehr viele allgemeine Aussagen darüber findet, bisher haben ich das mit dem asymmetrische Ver- und Entschlüsselungsfunktionen noch nicht gefunden. Achja, gibt es gute Bücher über Verschlüsselungen zu empfehlen?

Zitat:

Zitat von negaH

@Salt:

Ja, wenn du einen Cipher benutzt der einen Feedbackmodus wie CTS/CBC/CFB/OFB benutzt. Das ist wichtig damit die 256 bytes Zufall am Anfang der zu verschlüsselnden daten auch Einfluß auf die nachfolgenden bytes haben. Der richtig Feedbackmodus sorgt also dafür das die 256 Bytes Zufall während der Verschlüsselung auch Auswirkungen auf die Daten danach haben. Also selbst wenn ein Angreifer wüsste das dein Code mit bestimmten Sequenzen beginnt so würde er denoch beim Knacken erstmal die exakten 256 Bytes Zufall finden müssen. Das dürfte unmöglich sein und somit kann er auch nicht an deinen Code rankommen selbst wenn er ihn partiell kennt.

Gruß Hagen

Du hast im vorherigen Beitrag mir den Tipp gegeben mit RCx. Wenn ich den RCx Beitrag richtig verstanden habe, so enthält RCx schon die "Lawineneffektfunktion", dass die anfänglichen Daten Auswirkungen auf den nachfolgenden Ausgabecode haben.

Grüsse,
jus

[negaH]

Hi

Zitat:

Ich habe mal IDEA im im Google eingegeben, das Problem ist nur, dass sehr viele allgemeine Aussagen darüber findet, bisher haben ich das mit dem asymmetrische Ver- und Entschlüsselungsfunktionen noch nicht gefunden. Achja, gibt es gute Bücher über Verschlüsselungen zu empfehlen?

Vorsicht! ich habe im Falle des IDEA Ciphers mit "asymmetrisch" dessen internen matheamtischen Operationen gemeint, nicht vergleichbar mit den Asymmetrischen Verfahren wir RSA oder Diffie Hellman.
IDEA nutzt intern eine "mathematische Einwegoperation" als Verschlüsselungsfunktion. Somit ergibt sich dazu eine "a-symmetrische" Entschlüselungsfunktion. Dieses Verhalten macht IDEA zu einem aussergewöhnlichen symmetrischen Verfahren, denn die wenigesten Cipher habe diese Eigenschaft. Man könnte es so ausdrücken: wenn man NICHT weis wie man eine solche Entschlüsselungsfunktion invertieren soll so kann man bei nicht bekannter Ver-schlüsselungsfunktion diese Funktion nicht reproduzieren und somit ach keinen Keygen programmieren. Dh. das nötige Wissen bei einem Angreifer ist viel höher als bei anderen sym. Verfahren. Und letzendlich ist Sicherheit immer ein Kampf um das beste und neueste Wissen !

Bücher ? Ich empfehle dir zum Einstieg "Bruce Schneier: Angewandte Kryptographie".

Zitat:

Du hast im vorherigen Beitrag mir den Tipp gegeben mit RCx. Wenn ich den RCx Beitrag richtig verstanden habe, so enthält RCx schon die "Lawineneffektfunktion", dass die anfänglichen Daten Auswirkungen auf den nachfolgenden Ausgabecode haben.

Korrekt. Beachte aber das diese Modifikation durch MICH erfolgte, und ICH eben beiweitem kein Maßstab für einen Kryptoexperten sein kann. Aus meinem Verständnis heraus habe ich nur verschiedene annerkannte Technologien im RCx kombiniert. Das sollte die Sicherheit natürlich erhöhen und ich vertrete auch die Auffassung das es so ist. Aber auch dieser Schritt der Kombination muß mathematisch als beweisbar korrekter Schritt durchgeführt werden. Und exakt diesen Beweis kann ich nicht antreten, dazu ist mein Wissen zu gering. Allerdings kann ich ohne Untertreibung behaupten das viele Cipher auf diese Weise konstruiert wurden, die heute noch sicher sind und ebenfalls keinen speziellen Beweis angetreten haben. Es ist also so das selbst heutzutage Verschlüsselungen quasi im Baukastenprinzip konstruiert werden und die Konstrukteure nicht jeden Baustein im Kontext des gesammten neuen Verfahrens als korrekt beweisen. Diese Erkenntinis führt uns dann auch direkt zu der Behauptung warum Merhfachverschlüsselungen nicht als gleichermaßen sicher eingestuft werden dürfen wie Einfachverschlüsselungen. Wir können die sich gegenseitig beeinflussenden Bausteine bei der Mehrfachverschlüsselungen nicht als sicher beweisen.

Naja, bin schon wieder mal ein Bischen vom Thema abgekommen ;)

Gruß Hagen

[jus]

@Hagen
Vielen vielen Dank für die vielen Infos und Tips!! Ich muß das ganze erst mal verdauen. :wall: Wahrscheinlich werde ich zunächst mal RCx verwenden und mich dann langsam an den IDEA Algorithmus versuchen zu modifizieren(experimentieren).

Eines was mich zu diesem Thema noch brennend interessieren würde ist das Structured Exception Handling(SEH), was einen verschlüsselten Codebereich vor Überraschung beim Ausführen schützen sollte. Doch wie könnte man sowas hier realisieren? :gruebel:

Grüsse
jus