[PE] Problem bei einfachem Crypter

[Cardano]

Guten Abend allerseits.

Ich habe mal versucht mein bisheriges Wissen über das PE Dateiformat an einem kleinen Crypter umzusetzen. Es wird alles genau so durch mein Programm erstellt wie ich es will. In CFF Explorer sieht alles 1a aus. Aber wenn ich das ganze dann starten will.... nichts. Windows 7 x86 weigert sich komplett. Ich habe es in Ollydbg versucht zu untersuchen. Nachdem ich es in Olly geladen hatte sah noch alles in Ordnung aus. Olly sprang zu dem von mir gewählten EP und es stand auch der richtige Code dort. Ich drückte F7 aber nichts. F8 und F9 lieferten auch keinen Erfolg. Im Hintergrund sah ich wie Windows bereits eine Fehlermeldung erzeugte. Danach hatte ich mein Programm so umgebaut, dass gerade einmal der minimalste Part erledigt wird und verwendete statt einer eigens implementierten RC4 Encryption eine XOR Encryption.

Nun wurde NURNOCH folgendes gemacht:

1. Es wird eine Section hinzugefügt (Header usw werden entsprechend angepasst)
2. Der OEP wird auf die erste Instruktion der neuen Section gesetzt
3. Die checksum wird auf 0 gesetzt, BaseOfCode wird auf die neue Section gesetzt
4. Die Characteristics der .text Section wird auf C0000040 geändert.
5. In die neue Section wird eine XOR Encryption eingebaut in welcher alle wichtigen Daten wie Anfang und Größe der .text Section automatisch eingetragen werden.
6. Es wird ein Relocationeintrag für die neue Section angelegt indem alle in der XOR Encryption vorkommenden RVA's an denen VA's addressiert werden eingetragen werden. (Somit ist das ganze unabhängig von der Imagebase)

Wie man sieht eine sehr einfache Implementierung des Crypters, vorher wurden zb Checksum ermittelt, eventuelle Codecaves genutzt usw.

Nun probiere ich die fertig 'gecryptete' Datei erneut aus. DASSELBE Risultat!
Der reinen Neugier halber, probiere ich es unter XP... ES FUNKTIONIERT. Ich testete meine vorherige eigentliche Version... SIE FUNKTIONIERTE. Beide Version funktionierten 1a unter XP und Ollydbg funktionierte ebenfalls gut mit den Datein.

Nun frage ich mich natürlich weswegen es nicht unter 7 funktioniert, wohlmöglich auch nicht unter Vista??

Ich habe euch hier eine .rar gemacht in der ihr eine hallowelt App findet und eine Datei mit dem Namen hallowelt_mod, welche die mit der XOR-Version gecryptete Datei ist. Solltet ihr sie unter XP starten, werdet ihr merken dass alles funktioniert. Unter Windows 7 sieht das Ganze aber anders aus.
RapidShare: 1-CLICK Web hosting - Easy Filehosting


Hat einer von euch eine Idee was hier angepasst werden muss damit Windows 7 die Datei ebenfalls starten kann ?

Vielen Dank für eure Hilfe, Cardano

[ocz]

lol, fuck this.

[Cardano]

Oh danke
Ich seh aber gerade dadurch, dass du mich darauf hinweist, weswegen die RelocTable alles zerstört. Ich habe diese XOR-Version auf die schnell implementiert und wie es aussieht eben den XOR Key selber mit auf die RelocTable gesetzt :lol (dieser kleiner Patzer ist mir bei der eigentlichen Version nicht passiert )
Jetzt ist dieser runter von der RelocTable und in Olly siehts auch richtig aus:


Hier die aktulle Datei(wieder selbes Problem unter Win 7):
RapidShare: 1-CLICK Web hosting - Easy Filehosting

Danke schonmal für deine Antwort

[ocz]

lol, fuck this.

[DizzY_D]

Dein Problem ist nicht, wie fälschlicherweise von OpCodez (<3) behauptet, der reloc table, sondern das allseits gemochte DEP.
MSVC exen haben im OptionalHeader -> DllCharacteristics den Wert "Image is NX compatible" gesetzt. Das bedeutet eben, dass DEP hier "verschärft zugreift".
Nimm diesen Wert einfach mal raus, dann kann dein Code auch ohne Probleme ausgeführt werden.
Ein zweiter Feheler ist, dass du im reloc Table an der RVA 1009 einen Eintrag hinzugefügt hast für die Schleifendurchläufe.
Siehe:

01296008    B9 5408E900     MOV ECX,0E90854
0129600D    807431 FF 3F    XOR BYTE PTR DS:[ESI+ECX-1],3F
01296012    E2 E2           LOOP SHORT 01295FF6

Das ist ein einfacher Brainerror, wie wir ihn sicherlich alle kennen.
Denn die Size der Codesection hat ja wenig mit relocation/imagebase issues zu tun.

Nach diesen änderungen hat alles fehlerfrei bei mir auf W7 funktioniert.

BTW: Sehr nettes Projekt, weiter so!

[Cardano]

Danke DizzY_D, von der DEP hatte ich bisher noch nichts gehört (werde mich gleich mal drüber schlau lesen ). Aber leider muss ich sagen, dass es bei mir immernoch nicht funktioniert. Dank deines Tipps läuft es auch inzwischen unter Windows 7 in Olly. Ich kann erstmal die Stub durchlaufen lassen und am Ende ist die .text Section wieder richtig encryptet und es wird dorthin gesprungen. Nur wird gleich der erste Call in der .text Section, der nach hallowelt.__security_init_cookie dem Ganzen zum Verhängnis. Genauergesagt ist es dort die 5. Instruktion (makiert im Screenshot[rechts: hallowelt_mod, links: hallowelt]):

012E1791     A1 0030527F         MOV EAX,DWORD PTR DS:[7F523000]

wobei an der Addresse 0x00000000 steht
Sobald diese ausgeführt wird in *_mod passiert eine Accessviolation. Anders hingegen in der hallowelt, dort wird folgendes gemacht:

00141791   |.  A1 00301400       MOV EAX,DWORD PTR DS:[__security_cookie]

und hier bei der Addresse: DS:[00143000]=BB40E64E steht.

Hier die Version (ich hoffe alles berücksichtigt zu haben, was euch aufgefallen ist): RapidShare: 1-CLICK Web hosting - Easy Filehosting

BTW: Es ist schonwieder nur mein Win 7 , Windows XP schluckt alles ohne zu meckern

Danke schonmal an OpCodez und DissY_D
MfG Cardano

[ocz]

lol, fuck this.

[DizzY_D]

Nach etwas Nachdenken kam mir gerade der Geistesblitz:
Ist doch klar, dass das nicht funktioniert (für OpCodez(<3) anscheinend nicht):
Die Relocations werden vom Loader ja BEVOR der EP ausgeführt wird, angewandt.
Wenn du da dann natürlich "drüberxorst", stimmen die Adressen natürlich nicht mehr.

Das heißt, du musst die Relocs nach deiner Cryptroutine "per Hand" fixen.

Und nochmal an OpCodez(<3):
Probleme schafft man nicht aus der Welt, indem man sie ignoriert!!

[Cardano]

DANKE Dizzy =)
Aber nicht nur das
Eigentlich muss ich doch folgendes machen:
Ich muss die eigentlichen Relocs irgendwo zwischenspeichern, löschen und erst nach dem XOR'ren wiederherstellen und selber fixen.
Denn würden die Relocs zur Zeit des Loaders existieren, würde ein an einer RVA innerhalb der .text Sektion stehender und zum Relocieren bestimmter Pointer doch zur Zeit des Loaders um += des Deltas, von dem Aktuellen zur bevorzugten ImageBase verändert werden.
Also sagen wir an 1000h wäre ein Pointer welcher innerhalb der RelocTable steht und der Bereich von 1000h bis 2000h bildet die .text Section:
So würde an 1000h ein verxor'xter Pointer stehen, welcher sagen wir den Wert 30000h hat, also in reverse Byteorder: 00 00 03 00. Nach dem xor'xen hat er bei einem Key von 3F den Wert: 3F 3F 3C 3F. Wenn die Imagebase sich um 40h unterscheidet, dann sieht der Relocierte Pointer wie folgt aus:
3F3C3EFF = FF 3E 3C 3F. Wenn dann meine XOR Routine dadrüber wandert siehts so aus:
C0 01 03 00 = 000301C0, also liegt die Addresse nun um 180h = 384 Bytes daneben.

Will heißen: Ich müsste alle relocs (bis auf die der neuen Section) zwischenspeichern und später eigenhändig ablaufen, oder ?

Vielen Dank für alle Antworten bisher =)

BTW: Ich benutze wie gesagt statt der XOR Encryption eigentlich eine RC4 Encryption. Ich hab die (mit meinen spärlichen ASM Künsten) soweit optimiert wie ich nur konnte, sind 103 Byte für eine RC4 Encryptionstub angemessen?

MfG Cardano

[jojoomgasd]

Nimm lieber XOR und mach das so: (Dann ist es auch FUD)

for(int i = 0; i < size; i++)
{
if(byte[i] == xorKey || byte[i] == 0x00)
 continue;
byte[i] = byte[i] ^ xorKey;
}