![[HaBo]](/styles/default/logoklein.png){kind=small}
Sind dumped files ausführbar auf allen Systemen ?
- Themenstarter JP81
- Beginndatum
Kommt auf dem Dump, den Dumpzeitpunkt und den Dumper an 
Normalerweise ist der Dump ohne Nachbearbeitung noch nicht mal auf dem gleichen Rechner lauffähig (Stichworte: PE-Header, FileAlignment, SectionAlignment)
D.h, nur wenn man dumpt, bevor der PE-Loader irgenwas initialisieren konnte UND FileAlignment == SectionAlignment (was das genau ist: siehe PE-Dokumentationen wie https://code.google.com/p/corkami/wiki/PE, diverse Compendien https://www.google.de/search?q=arteam+pe+compendium oder pecoff Doumentation von MS), dann läuft es.
Nicht umsonst bieten viele Dumper diesbezüglich eine Korrektur und/oder eine Auswahl, ob man den PE-Header von der Platte oder aus dem Speicher nehmen sollte.
Dann ist da noch die Frage, ob man eine ungepackte, gepackte oder geschützte Exe vor sich hat.
Bei allen Variationen: wurde TLS durchgearbeitet bzw. wurden wichtige Variablen initialisiert und kann das Programm damit umgehen?
---------------------------
1. Ungepackt, bevor IAT "verunstaltet" wurde:
läuft ohne weiteres überall, sofern FileAlignment==SectionAlignment, sonst muss SectionHeader bearbeitet werden.
---------------------------
2. Gepackt, nachdem der Packer alles entpackt hat und den OEP(OriginalEntryPoint) anspringt:
IAT-Rebuild notwendig, SectionHeader Bearbeitung, EP auf OEP setzen.
Hier läuft besonders bei Anfängern einiges schief - sie stellen die Packer-IAT wieder her, die Programm-IAT (also die Tabelle, die vom PE-Loader bzw dem Packer ausgefüllt wurde), bleibt so bestehen und beinhaltet schon "feste Adressen" zu Funktionen der DLLs. Gemeinerweise verweist die ImportTabelle auf die IAT des Packers (die wiederhergestellt wurde), so dass der Win-PE-Loader auch nicht meckert. Die festen Adressen in der "Ex-IAT" stimmen auch meist (zumindest für die gleiche Session).
D.h es wird auf der eigenen Maschine beim unmittelbaren Testen wahrscheinlich klappen, auf einer anderen Maschine (oder nach einem Reboot ) nicht mehr. Oder man hat seltsamste Fehlermeldungsorgien
---------------------------
3. Geschützt:
kommt auf die Fantasie des Autors, den Zeitpunkt des Dumps an und Integration des Protectors an:
a) API Aufrufe schon auf Sourcelevel "verunstaltet" - werden vom Protector mittels eigener Routinen (PEB=>TIB => Modulliste, eigene Exportscanroutine, das ganze in einer "VM" (also eigenentlich einem integrierten Interpreter, der generierten Bytecode abarbeitet - und in diesem Bytecode steckt die eigentliche Importsuche oder gar die wichtige, geschützte Funktion) oder Polymorpher-bla <weiterer Marketingname hier> (es gibt keine VM, aber die Anweisungen werden verändert und stark aufgebläht - z.B aus einem PUSH EAX wird
)
b) API Aufrufe beim Protecten verunstaltet (das Gleiche in grün, vielleicht nur einen Tick schlechter),
OEP-"Stealing" war auch mal "IN" - da wurden die ersten X-Opcodes, die sonst ausgeführt werden würden, vom Protector durch eigene Routine ersetzt und irgendwo "versteckt" und umgeschrieben (siehe VM/"Polymorpher" Ansatz) - dabei ging es in erster Linie darum, dass der Code a) schwer zu finden sein wird (es gibt keinerlei Markierung: "ab hier der Originalcode" ) und b) ohne Protector nicht läuft
c) PE-Header verunstaltet (bis hin zu "dummies" die nur den Protector starten und dieser dann die Funktion des PE-Loaders übernimmt, ohne den PE-Header "as is" irgendwo im Speicher stehen zu lassen).
d) IAT-Call-Redirect: entweder die (ehemalige) IAT wird gepatcht und Programmaufrufe landen in protectorinternen Funktionen (die z.B beim ersten Aufruf die Adresse der DLL über PEB&Co suchen und dann die Adresse der Funktion über abgrasen der DLL-Exporttabelle, was bei weitem kein Hexenwerk ist, ermitteln und zwischenspeichern) oder es werden direkt die Caller umgepatcht (mit dem gleichen Effekt).
Dann hat man beim Dumpen auch das Problem, dass irgendwo fixe Adressen stehen - dump läuft auch nach den üblichen Rebuild-Schritten nur auf der gleichen Maschine.
Gerne auch alles zusammen - d.h nach dem Dumpen muss man es rückgängig machen - was viele viele spannende Abende verspricht (das ist auch der Grund, warum viele lieber mit Memorypatchern arbeiten )
Normalerweise ist der Dump ohne Nachbearbeitung noch nicht mal auf dem gleichen Rechner lauffähig (Stichworte: PE-Header, FileAlignment, SectionAlignment)
D.h, nur wenn man dumpt, bevor der PE-Loader irgenwas initialisieren konnte UND FileAlignment == SectionAlignment (was das genau ist: siehe PE-Dokumentationen wie https://code.google.com/p/corkami/wiki/PE, diverse Compendien https://www.google.de/search?q=arteam+pe+compendium oder pecoff Doumentation von MS), dann läuft es.
Nicht umsonst bieten viele Dumper diesbezüglich eine Korrektur und/oder eine Auswahl, ob man den PE-Header von der Platte oder aus dem Speicher nehmen sollte.
Dann ist da noch die Frage, ob man eine ungepackte, gepackte oder geschützte Exe vor sich hat.
Bei allen Variationen: wurde TLS durchgearbeitet bzw. wurden wichtige Variablen initialisiert und kann das Programm damit umgehen?
---------------------------
1. Ungepackt, bevor IAT "verunstaltet" wurde:
läuft ohne weiteres überall, sofern FileAlignment==SectionAlignment, sonst muss SectionHeader bearbeitet werden.
---------------------------
2. Gepackt, nachdem der Packer alles entpackt hat und den OEP(OriginalEntryPoint) anspringt:
IAT-Rebuild notwendig, SectionHeader Bearbeitung, EP auf OEP setzen.
Hier läuft besonders bei Anfängern einiges schief - sie stellen die Packer-IAT wieder her, die Programm-IAT (also die Tabelle, die vom PE-Loader bzw dem Packer ausgefüllt wurde), bleibt so bestehen und beinhaltet schon "feste Adressen" zu Funktionen der DLLs. Gemeinerweise verweist die ImportTabelle auf die IAT des Packers (die wiederhergestellt wurde), so dass der Win-PE-Loader auch nicht meckert. Die festen Adressen in der "Ex-IAT" stimmen auch meist (zumindest für die gleiche Session).
D.h es wird auf der eigenen Maschine beim unmittelbaren Testen wahrscheinlich klappen, auf einer anderen Maschine (oder nach einem Reboot
) nicht mehr. Oder man hat seltsamste Fehlermeldungsorgien ---------------------------
3. Geschützt:
kommt auf die Fantasie des Autors, den Zeitpunkt des Dumps an und Integration des Protectors an:
a) API Aufrufe schon auf Sourcelevel "verunstaltet" - werden vom Protector mittels eigener Routinen (PEB=>TIB => Modulliste, eigene Exportscanroutine, das ganze in einer "VM" (also eigenentlich einem integrierten Interpreter, der generierten Bytecode abarbeitet - und in diesem Bytecode steckt die eigentliche Importsuche oder gar die wichtige, geschützte Funktion) oder Polymorpher-bla <weiterer Marketingname hier> (es gibt keine VM, aber die Anweisungen werden verändert und stark aufgebläht - z.B aus einem PUSH EAX wird
Code:
push ebx
xor ebx, ebx
xor eax, ebx
pop ebx
mov [esp-4], eax
sub esp,4b) API Aufrufe beim Protecten verunstaltet (das Gleiche in grün, vielleicht nur einen Tick schlechter),
OEP-"Stealing" war auch mal "IN" - da wurden die ersten X-Opcodes, die sonst ausgeführt werden würden, vom Protector durch eigene Routine ersetzt und irgendwo "versteckt" und umgeschrieben (siehe VM/"Polymorpher" Ansatz) - dabei ging es in erster Linie darum, dass der Code a) schwer zu finden sein wird (es gibt keinerlei Markierung: "ab hier der Originalcode"
) und b) ohne Protector nicht läuftc) PE-Header verunstaltet (bis hin zu "dummies" die nur den Protector starten und dieser dann die Funktion des PE-Loaders übernimmt, ohne den PE-Header "as is" irgendwo im Speicher stehen zu lassen).
d) IAT-Call-Redirect: entweder die (ehemalige) IAT wird gepatcht und Programmaufrufe landen in protectorinternen Funktionen (die z.B beim ersten Aufruf die Adresse der DLL über PEB&Co suchen und dann die Adresse der Funktion über abgrasen der DLL-Exporttabelle, was bei weitem kein Hexenwerk ist
, ermitteln und zwischenspeichern) oder es werden direkt die Caller umgepatcht (mit dem gleichen Effekt).Dann hat man beim Dumpen auch das Problem, dass irgendwo fixe Adressen stehen - dump läuft auch nach den üblichen Rebuild-Schritten nur auf der gleichen Maschine.
Gerne auch alles zusammen - d.h nach dem Dumpen muss man es rückgängig machen - was viele viele spannende Abende verspricht (das ist auch der Grund, warum viele lieber mit Memorypatchern arbeiten
)