Was sind Packer und Obfuskation, und wie erkennt man sie in einem Binary?
Kurzantwort
Packen komprimiert oder verschlüsselt die eigentliche Payload und stellt ihr einen Stub voran, der sie zur Laufzeit in den Speicher entpackt; Obfuskation transformiert Code oder Daten, um dem Lesen und Signaturen zu widerstehen. Packen erkennt man an hoher Sektionsentropie nahe 8,0, einer winzigen oder nur aus dem Stub bestehenden Importtabelle, ungewöhnlichen oder schreib-ausführbaren Sektionsnamen wie UPX0, einem Einsprungpunkt außerhalb von .text, einer großen virtuellen Größe gegenüber einer kleinen Rohgröße sowie Detektoren wie Detect It Easy oder PEiD. Keines davon ist allein schlüssig, daher wägen Analysten mehrere Signale zusammen ab und bestätigen, indem sie das Entpacken zur Laufzeit beobachten.
Die meiste Massen- und gezielte Malware ist gepackt, um ihren Fußabdruck zu verkleinern und vor allem statische Signaturen auszuhebeln und Analysten zu bremsen. Interviewer fragen das, um zu prüfen, ob Sie ein gepacktes Sample schnell erkennen, statt Stunden mit dem Disassemblieren eines Stubs zu vergeuden.
Packen versus Obfuskation
Ein Packer nimmt die eigentliche Payload, komprimiert oder verschlüsselt sie und hüllt sie in einen kleinen Entpack-Stub. Zur Laufzeit reserviert der Stub Speicher, stellt den Originalcode wieder her und übergibt ihm die Ausführung — auf der Festplatte sehen Sie also nur den Stub plus einen undurchsichtigen Blob. Obfuskation ist weiter gefasst: Control-Flow-Flattening, Junk-Instruktionen, undurchsichtige Prädikate, String-Verschlüsselung und API-Hashing erschweren alle das Lesen und Fingerprinten des Codes, ob die Datei gepackt ist oder nicht. Packen verbirgt die Payload; Obfuskation verbirgt die Logik.
Erkennungssignale
Kein einzelnes Signal ist ein Beweis — man stapelt sie:
- Hohe Entropie. Sektionen, die nahe 8,0 Bit pro Byte messen, deuten auf Kompression oder Verschlüsselung hin. Einschränkung: legitime komprimierte Medien und Installer punkten ebenfalls hoch, daher ist Entropie ein Hinweis, kein Urteil.
- Winzige Importtabelle. Ein echtes Programm importiert Dutzende APIs; ein gepacktes importiert oft nur
LoadLibraryundGetProcAddress, weil es nach dem Entpacken alles dynamisch auflöst. - Seltsame Sektionen. Namen wie
UPX0/UPX1, als schreibbar und ausführbar markierte Sektionen oder eine kleine Rohgröße bei großer virtueller Größe. - Lage des Einsprungpunkts. Ein Einsprungpunkt außerhalb von
.text, in einer schreibbaren Sektion, ist verdächtig. - Detektoren. Detect It Easy (DIE), PEiD-Signaturen und Entropiegrafen identifizieren viele bekannte Packer namentlich.
Es bestätigen
Die entscheidende Bestätigung ist dynamisch: das Sample ausführen und beobachten, wie es ausführbaren Speicher reserviert und hineinschreibt (das Entpacken). Eine gute Antwort sagt, dass die Erkennung statisch probabilistisch und dynamisch sicher ist.
Wahrscheinliche Anschlussfragen
- Warum hat ein gepacktes Binary in seinen Imports oft nur LoadLibrary und GetProcAddress?
- Ist hohe Entropie ein Beweis für Packen? Was erzeugt Fehlalarme?
- Wie unterscheidet sich Obfuskation vom Packen in dem, was sie schützt?