[HaBo]

HolyWater · 11.08.11, 09:27

hallo

hätte da nochma allgemeine fragen zum pe format...
ich bastel mir grad nen xtea crypter, ich hab meine xtea_decipher funktion + entrypoint sauber überschrieben! d.h. ich hab den entrypoint schon auf meinen stub umgeleitet, der dann in einer loop die xtea_decipher func callen soll. wäre an sich kein problem, nur glaube ich nicht dass es ausreicht wenn ich ne loop von 0x11000 (VirtualAddress der .code section) bis +VirtualSize durchlaufen lasse! wenn ich da noch die ImageBase drauf rechne bin ich aber immernoch nicht bei der richtigen adresse. genau so siehts auch am ende mit dem jump zurück aus, da bin ich auch an einer merkwürdigen adresse.

Code:

DWORD dwEP=0-((pSection->VirtualAddress+pSection->Misc.VirtualSize+39)-dwEP)-5;
[...]
memcpy((void*)(((DWORD)pBase)+pSection->PointerToRawData+pSection->Misc.VirtualSize+35),&dwEP,4);

an +34 steht ein 0xE9, danach steht nochmal 0xC3 (für einen debugger check)

thx schonmal

**CDW** · 11.08.11, 13:02

Und was wäre nun die Frage? Oder soll man darauf aus den 2 Zeilen Code schließen?

Was ist der Startwert für dwEP? Soll dwEP die absolute Adresse darstellen oder die Distanz für einen JMP? Im ersten Fall fehlt defentiv noch die ImageBase in den Berechnungen.

VirtualAddress ist (obwohl der Name etwas anderes vermuten lässt) eine RVA. Also Angabe bezüglich der ImageBase. ImageBase+RVA = Speicheradresse.
Bei relocatable Executablen müsste man stattdessen noch die "echte" Imagebase feststellen (z.B call zum GetModuleHandle(0) oder

Code:

call delta
delta:
pop eax
sub eax, rva_von_delta

sowas in der Art (bei relocatable Exen bekommt man noch ganz andere Probleme, da man die Relocations-Tabelle selber auswerten muss, aber das ist hier eher nicht das Thema

).

Bei "section1.VirtualAddress + section1.VirtualSize + 39" ist man definitiv im 00-initialisierten Speicherbereich (sofert dwEP mit 0 initialisiert wurde). Oder liegt da der Stubcode? Dir ist aber klar, dass, solange man die VirtualSize UND RawSize nicht entsprechend anpasst, nix davon vom Win-PE-Loader in den Speicher gemappt wird? (bin jetzt zu faul im MS-PECOFF nachzuschlagen, ob das nur bei RawSize < VirtualSize der Fall ist oder auch bei RawSize > VirtualSize). Also alle Daten, die nach RawSize noch in der Section liegen oder nach VirtualSize, "schaffen" es nicht in den Speicher.

Zu der zweiten Zeile: wenn man "RawDaten" kopiert, sollte man auch RawSize nutzen

. Ich sehe aber ehrlich gesagt keinen Sinn in der Anweisung, da

Code:

pSection->PointerToRawData+pSection->Misc.VirtualSize+35

garantiert außerhalb des VirtualSize Bereichs landet und damit hat man wieder das Problem, dass es vom PE-Loader "ignoriert" wird.

PS: lass Dir einfach alle Zwischenschritte/Werte ausgeben. So findet man am schnellsten den Fehler. Besonders bei C vertut man sich schnell (falsche Klammerung beim casten/Pointern führt zu falschen Berechnungen).

Anzeige

- Anzeige -

HolyWater · 11.08.11, 17:31

also was dwEP angeht soll das nen relative jump zum originalen entrypoint sein nur da finde ich (auch mit imagebase) nichts :|

wird auch alles sauber in den speicher gemappt

nur wie ich die relocations auswerten soll kp

Anzeige

- Anzeige -

11.08.11, 09:27	#1 (permalink)
HolyWater Registriert seit: 17.10.09 Likes: 0	allgemeine PE fragen Anzeige hallo hätte da nochma allgemeine fragen zum pe format... ich bastel mir grad nen xtea crypter, ich hab meine xtea_decipher funktion + entrypoint sauber überschrieben! d.h. ich hab den entrypoint schon auf meinen stub umgeleitet, der dann in einer loop die xtea_decipher func callen soll. wäre an sich kein problem, nur glaube ich nicht dass es ausreicht wenn ich ne loop von 0x11000 (VirtualAddress der .code section) bis +VirtualSize durchlaufen lasse! wenn ich da noch die ImageBase drauf rechne bin ich aber immernoch nicht bei der richtigen adresse. genau so siehts auch am ende mit dem jump zurück aus, da bin ich auch an einer merkwürdigen adresse. Code: DWORD dwEP=0-((pSection->VirtualAddress+pSection->Misc.VirtualSize+39)-dwEP)-5; [...] memcpy((void*)(((DWORD)pBase)+pSection->PointerToRawData+pSection->Misc.VirtualSize+35),&dwEP,4); an +34 steht ein 0xE9, danach steht nochmal 0xC3 (für einen debugger check) thx schonmal

11.08.11, 13:02	#2 (permalink)
CDW Moderator Registriert seit: 20.07.05 Likes: 202	Und was wäre nun die Frage? Oder soll man darauf aus den 2 Zeilen Code schließen? Was ist der Startwert für dwEP? Soll dwEP die absolute Adresse darstellen oder die Distanz für einen JMP? Im ersten Fall fehlt defentiv noch die ImageBase in den Berechnungen. VirtualAddress ist (obwohl der Name etwas anderes vermuten lässt) eine RVA. Also Angabe bezüglich der ImageBase. ImageBase+RVA = Speicheradresse. Bei relocatable Executablen müsste man stattdessen noch die "echte" Imagebase feststellen (z.B call zum GetModuleHandle(0) oder Code: call delta delta: pop eax sub eax, rva_von_delta sowas in der Art (bei relocatable Exen bekommt man noch ganz andere Probleme, da man die Relocations-Tabelle selber auswerten muss, aber das ist hier eher nicht das Thema ). Bei "section1.VirtualAddress + section1.VirtualSize + 39" ist man definitiv im 00-initialisierten Speicherbereich (sofert dwEP mit 0 initialisiert wurde). Oder liegt da der Stubcode? Dir ist aber klar, dass, solange man die VirtualSize UND RawSize nicht entsprechend anpasst, nix davon vom Win-PE-Loader in den Speicher gemappt wird? (bin jetzt zu faul im MS-PECOFF nachzuschlagen, ob das nur bei RawSize < VirtualSize der Fall ist oder auch bei RawSize > VirtualSize). Also alle Daten, die nach RawSize noch in der Section liegen oder nach VirtualSize, "schaffen" es nicht in den Speicher. Zu der zweiten Zeile: wenn man "RawDaten" kopiert, sollte man auch RawSize nutzen . Ich sehe aber ehrlich gesagt keinen Sinn in der Anweisung, da Code: pSection->PointerToRawData+pSection->Misc.VirtualSize+35 garantiert außerhalb des VirtualSize Bereichs landet und damit hat man wieder das Problem, dass es vom PE-Loader "ignoriert" wird. PS: lass Dir einfach alle Zwischenschritte/Werte ausgeben. So findet man am schnellsten den Fehler. Besonders bei C vertut man sich schnell (falsche Klammerung beim casten/Pointern führt zu falschen Berechnungen). __________________ Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf! Selig, wer nichts zu sagen hat und trotzdem schweigt.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

11.08.11, 17:31	#3 (permalink)
HolyWater Themenstarter Registriert seit: 17.10.09 Likes: 0	also was dwEP angeht soll das nen relative jump zum originalen entrypoint sein nur da finde ich (auch mit imagebase) nichts :\| wird auch alles sauber in den speicher gemappt nur wie ich die relocations auswerten soll kp

[HaBo]

allgemeine PE fragen