Identifikation von Packern, OPCode Filter, etc. Einstellungen

[Gast_Nautilus_*]

In der Regel benutzen die Unpacking Engines diverser AV Scanner offenbar statische Unpack-Routinen.

Gemeint ist Folgendes: Für jeden erkannten (!) Packer wird eine spezielle Dekompressionsroutine (und nicht etwa eine generische Emulation) verwendet. Ein Packer wird nur dann erkannt, wenn er durch eine Analyse des "decompression stub" (des Dekompressions-Abschnittes) eindeutig identifiziert werden kann.

Die Identifikation erfolgt normalerweise durch einen Vergleich des zu scannenden Files mit verschiedenen decompression stub-Signaturen.

Wird der decompression stub nur ein wenig verändert (etwa durch Hinzufügen von NOPs oder per OEP redirection), erkennt der AV Scanner den Packer nicht mehr, da die Signatur nicht mehr "passt". In Konsequenz wird die statische Dekompressionsroutine nicht verwendet, die zu scannende Datei wird nicht entpackt, der Trojaner/Wurm/Virus bleibt unerkannt.

Die genaue Vorgehensweise betr. Hïnzufügen von NOPs bzw. OEP redirection ist inzwischen vielen VXern bekannt. Ich zoegere aber noch, dies auf unserer Webseite zu veröffentlichen, solange keine Abhilfe in Sicht ist.

Daher die Frage, was man dagegen tun kann:

@Gladi Du hast von OPCode Filtern gesprochen. Kannst Du das im Detail erklären? Wie funktioniert ein OPCode Filter genau? Welche Probleme existieren bei der Implementierung?

@All Wie sieht es mit einer generischen Unpacking-Engine (Emulation) aus? Warum versagt bspw. die NOD32 Emulation bei Trojanern, die mit PKLite gepackt wurden und bei denen der OEP umgelenkt wurde? (Immerhin werden - zumindest einige - mit UPX gepackte Trojaner erkannt, bei denen NOPs hinzugefügt wurden .)

Könnte man keine "intelligente" Unpack-Routine coden, die NOPs generell ignoriert und den Signaturvergleich (zum Erkennen des Packers) nicht nur direkt am OEP vornimmt, sondern zusätzlich prüft, ob kurz darauf (d.h. nach der Umleitung) ein "match" möglich ist?

Gruss,

Nautilus

P.S.: Warum verfügen "normale" AV Scanner eigentlich nicht auch über einen Mem Scanner wie TDS oder TH?

[Gast_Andreas Haak_*]

>Abgesehen davon, wer Malware mit Delphi oder VB schreibt verdient sowieso keine
>Beachtung. ;-)

Defacto sind die meisten RATs und Würmer aber in einer der beiden Sprachen entwickelt ;o).

Abgesehen davon:
ASPack verdient keinerlei Beachtung ... ist Delphi *g*. Morphine übrigens auch. Und dafür das Delphi ja so primitiv ist, macht Morphine RAV aber mächtig Probleme *g*.

>Es kann ja nicht jeder Allwissend sein. ICH BIN SO UNWÜRDIG!

Schwachsinn ... obwohls schon dumm aussieht wenn du ein Verfahren kritisierst, daß Du weder kennst noch verstanden hast. "Audi is doof. Hab noch nie einen Gefahren, aber es ist doof."

>Deine Argumentation ist echt beispielhaft. Erst sagst du, das Generic Unpacking
>wurde aus der Codeemu fuer Poly Viren entwickelt und danach das man das die so
>erweiterte Emu nicht auch fuer Poly-Viren einsetzen sollte.

Hach ja - ich werde meine Beiträge wohl besser strukturieren müssen (oder meinen Tipp Ex Rausch ausschlafen *g*).

>Genau, wenn der Virus NOD32 oder das sonstige eingesetzte AV-Programm im
>Speicher patched und auf HDD unbrachbar macht weil der Dropper nicht erkannt
>wurde - das ist total unwichtig.

Dropper --> Trojaner. Wir reden von nem Virus.
Angenommen ne Notepad.exe ist infiziert und wird danach gepackt. Die Notepad EXE würde evtl. wohl als Infektionsherd nicht ausgemacht werden können. Wohl aber sobald der Virus versucht eine Datei auf deinem Rechner zu infizieren. Klassenziel erfüllt ... Rechner vor Infektion bewahrt. Daher ist ein Unpacking für einen reinen Virenscanner nicht wirklich notwendig.