(06.02.2011, 21:40)Acubra schrieb: [ -> ]Einfache Packer dienen, wie da Name ja schon sagt, nur dazu die Größe der .exe zu verringern bzw. zu "packen". Das der gesamte Code dann zur Runtime wieder entpackt werden muss, sollte klar sein. Somit steht der Code wieder völlig normal im Speicher und kann nach wie vor leicht verändert werden.
Aber bei einem Code Virtualizer sieht das schon wieder ganz anders aus. Diese arbeiten nach einem anderen Prinzip.
(06.02.2011, 21:40)Acubra schrieb: [ -> ]Wenn man jedoch die .exe patchen möchte, finde ich es um einiges leichter eine nichtgepackte .exe zu patchen, da man sich nicht mit der Entpackungsroutine des Packers beschäftigen muss.
Falsch. Um eine gepackte EXE patchen zu wollen müsstest Du diese erstmal entpacken. Ist diese insofern verändert worden das Du diese nur manuell entpacken kannst musst Du dich zwangsläufig damit auseinandersetzen.
Ich wiederrum finde es besser und eleganter eine EXE im gepackten Zustand zu patchen. Funktioniert allerdings nicht bei jedem Packer/Encrypter.
Beispiel...
Du hast eine gepackte EXE mit einer Größe von 10 MB. Entpackt hätte diese Datei eine Größe von, sagen wir mal 150 MB. Was wäre jetzt wohl sinnvoller? Im gepackten, oder entpackten Zustand patchen? Ich denke das sollte jetzt klar sein das ein Inline Patch schon sehr wohl nützlich ist. Mal abgesehen davon... Ein Inline Patch ist im Grunde auch nichts anderes als eine Code Injection, nicht mehr und nicht weniger. Vielleicht mach ich mal nen Tutorial mit einer "Crackme" dazu.
(06.02.2011, 23:53)sILeNt heLLsCrEAm schrieb: [ -> ]Aber bei einem Code Virtualizer sieht das schon wieder ganz anders aus. Diese arbeiten nach einem anderen Prinzip.
Hey,
ich dachte wir reden lediglich von einem
Packer und nicht einem Obfuscator/Protector?
(06.02.2011, 23:53)sILeNt heLLsCrEAm schrieb: [ -> ] (06.02.2011, 21:40)Acubra schrieb: [ -> ]Wenn man jedoch die .exe patchen möchte, finde ich es um einiges leichter eine nichtgepackte .exe zu patchen, da man sich nicht mit der Entpackungsroutine des Packers beschäftigen muss.
Falsch. Um eine gepackte EXE patchen zu wollen müsstest Du diese erstmal entpacken. Ist diese insofern verändert worden das Du diese nur manuell entpacken kannst musst Du dich zwangsläufig damit auseinandersetzen.
Ich muss eine gepackte EXE nicht entpacken um sie zu patchen. Lediglich muss ich wissen, wann ich wo welche bytes hinzuschreiben habe. Wenn du bei UPX z.B patchst, bevor alle Entpackungsroutinen abgelaufen sind, hast du zur Runtime wieder den Originalcode. Leitest du den Jump zum OEP jedoch zu deiner CodeCave um und schreibst dann die erforderlichen Bytes bevor du wieder zum OEP springst, hast du zur Runtime eine modifizierte exe. Und dafür brauchte man noch nicht einmal den Packer entfernen. Du hast ja selber schon das Stichwort Inline Patch gebracht.
(06.02.2011, 23:53)sILeNt heLLsCrEAm schrieb: [ -> ]Ich wiederrum finde es besser und eleganter eine EXE im gepackten Zustand zu patchen. Funktioniert allerdings nicht bei jedem Packer/Encrypter.
Beispiel...
Du hast eine gepackte EXE mit einer Größe von 10 MB. Entpackt hätte diese Datei eine Größe von, sagen wir mal 150 MB. Was wäre jetzt wohl sinnvoller? Im gepackten, oder entpackten Zustand patchen? Ich denke das sollte jetzt klar sein das ein Inline Patch schon sehr wohl nützlich ist. Mal abgesehen davon... Ein Inline Patch ist im Grunde auch nichts anderes als eine Code Injection, nicht mehr und nicht weniger. Vielleicht mach ich mal nen Tutorial mit einer "Crackme" dazu.
Das man nicht jeden Packer/Encryptor "inlinen" kann war mir nicht bewusst. Kannst du da ein spezielles Beispiel bringen?
PS: Sorry für Offtopic ;P
(07.02.2011, 00:17)Acubra schrieb: [ -> ]Hey,
ich dachte wir reden lediglich von einem Packer und nicht einem Obfuscator/Protector?
Reden wir auch. Das war mehr so als kleine Randinfo zu sehen.
(06.02.2011, 21:40)Acubra schrieb: [ -> ]Ich muss eine gepackte EXE nicht entpacken um sie zu patchen. Lediglich muss ich wissen, wann ich wo welche bytes hinzuschreiben habe. Wenn du bei UPX z.B patchst, bevor alle Entpackungsroutinen abgelaufen sind, hast du zur Runtime wieder den Originalcode. Leitest du den Jump zum OEP jedoch zu deiner CodeCave um und schreibst dann die erforderlichen Bytes bevor du wieder zum OEP springst, hast du zur Runtime eine modifizierte exe. Und dafür brauchte man noch nicht einmal den Packer entfernen. Du hast ja selber schon das Stichwort Inline Patch gebracht.
Okay... Halten wir eins mal fest. Der Inline Patch sollte natürlich dann aufgerufen werden wenn der Loader Stub abgearbeitet wurde. In der Regel bietet sich an, den Jump zum OEP umzubiegen. Halten wir weiter fest... Den Packer kannste auch nicht entfernen, denn der ist in der EXE nicht drin. Sondern nur der Loader bzw. der Algo der die EXE in den Arbeitsspeicher entpackt.
(06.02.2011, 21:40)Acubra schrieb: [ -> ]Das man nicht jeden Packer/Encryptor "inlinen" kann war mir nicht bewusst. Kannst du da ein spezielles Beispiel bringen?
Im Prinzip fallen hierunter alle Encryptoren. Reine Packer fallen nicht hierein. Da aber heutzutage viele, als Packer benannte Anwendungen, ebenfalls mit immer mehr Schutzmechanismen ausgestattet werden, wären da zu nennen... PECompact, Mew, RLPack, nPack, eXPressor...
Hallo Leute,
Wie installiere ich cheat engine 6.1 ohne das es auf EXPIRED geht und Geld will?
Gruß Warstel
Ich glaube du hast alles richtig gemacht ... DarkByte, der Entwickler von CE,
hat sich nur ein Spaß erlaubt ... darum sagt dir Cheat Engine am 1. April,
dass es bald abläuft und du Geld bezahlen musst
Richtig. Entweder die Systemzeit umstellen oder warten... Oder patchen...