Beschreibe, wie du ein gepacktes Sample entpackst, um den ursprünglichen Code zu erreichen.
Kurzantwort
Entpacken stellt den ursprünglichen Code wieder her, den der Packer verborgen hat. Für bekannte Packer nutzt du den passenden Unpacker oder einen Emulator. Für eigene Packer entpackst du manuell: Führe das Sample in einem Debugger aus, lass den Stub die Payload in den Speicher dekomprimieren, finde den Moment, in dem er zum ursprünglichen Entry Point springt (oft durch Breakpoint auf Speicher, der ausführbar wird, oder auf den Tail-Jump), dumpe dann das Prozess-Image aus dem Speicher und baue die Import Address Table mit einem Werkzeug wie Scylla oder PE-sieve wieder auf. Das Ergebnis ist eine lauffähige oder analysierbare PE, die die echte Payload enthält.
Entpacken ist das Tor, das du vor der tiefen statischen Analyse der meisten Malware passieren musst: Der Disassembler sieht nur den Stub, bis du die echte Payload wiederherstellst. Interviewer nutzen das, um zu prüfen, ob du verstehst, was ein Packer zur Laufzeit mit dem Speicher macht, und nicht nur, dass Packing existiert.
Bekannte Packer — die Abkürzung nehmen
Wenn ein Detektor wie Detect It Easy einen gängigen Packer benennt (UPX, ASPack, ältere Themida-Builds), greife zuerst zum passenden Werkzeug: upx -d für UPX, dedizierte Unpacker oder ein emulationsbasierter Unpacker, der den Stub in einer gesandboxten CPU ausführt und das Ergebnis dumpt. Das ist schnell und einen Versuch wert, bevor du manuelle Arbeit beginnst.
Eigene Packer — manuelles Entpacken
Wenn es keinen fertigen Unpacker gibt, entpackst du von Hand:
- Führe den Stub unter einem Debugger aus (x64dbg). Der Stub wird Speicher allozieren und die Payload hinein dekomprimieren oder entschlüsseln.
- Finde den ursprünglichen Entry Point (OEP). Gängige Techniken: Setze einen Hardware-Breakpoint auf Ausführen auf den frisch allozierten/beschriebenen Speicher, sodass du die erste Instruktion des echten Codes erwischst; achte auf den Tail-Jump (ein
jmp/retin eine andere Sektion); oder breake auf eine verräterische API, die die Payload früh aufruft. Werkzeuge wie PE-sieve können die entpackte Region auch automatisch erkennen. - Dumpe das Prozess-Image aus dem Speicher, sobald die Ausführung den OEP erreicht.
Die Imports wiederaufbauen
Ein roher Speicher-Dump hat meist eine kaputte Import Address Table, weil der Packer die APIs zur Laufzeit aufgelöst hat und die On-Disk-IAT leer oder veraltet ist. Nutze Scylla (oft in x64dbg integriert) oder PE-sieve/pe_unmapper, um die IAT zu rekonstruieren und den Entry Point zu reparieren, was eine saubere, analysierbare PE ergibt.
Eine Senior-Antwort benennt die OEP-Findungsstrategie, den Speicher-Dump und den IAT-Wiederaufbau als die drei echten Hürden — und merkt an, dass du für eine Triage die entpackte Payload einfach aus einem Sandbox-Speicher-Dump lesen kannst, statt sie vollständig zu reparieren.
Wahrscheinliche Anschlussfragen
- Wie findest du den ursprünglichen Entry Point (OEP) für einen eigenen Packer?
- Warum hat ein Speicher-Dump meist eine kaputte Import-Tabelle, und wie reparierst du sie?
- Wann würde PE-sieve oder ein dynamischer Unpacker das manuelle Entpacken schlagen?