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?

[SkeeveDCD]

Ahja - daher auch der Vorschlag Generic Unpacking für poly Engines zu nutz, gell?

Da hat einer das Prinzip der Code Emulation nicht ganz verstanden, was? ;-)

Sorry, ich hatte eine glückliche Kindheit. 92 hab ich lieber mit Freunden gespielt als am PC zu hocken *g*.

Jo, kann mich noch an deinen VHM-Meeting Auftritt erinnern. ;-)

Wo ist deine Leistung, das Du kritisierst? Ich setz mir gerne den Hut auf, wenn Du es auch machst. Zeig deine Leistung und zeig das Du somit das Recht hast zu kritisieren.

Tja so einfach mache ich es dir nicht, wenn du noch immer nicht gemerkt hast wer ich bin dann grueble mal fleissig weiter.

Was bringts? Wird die Infektion wieder verhindert - bei jedem Systemstart. Nervig zwar, aber ändert nichts daran das die Infektion verhindert wurde.

Wie willst du die Infektion verhindern wenn der Virus erst einmal gestartet ist? Die Moeglichkeiten des Virenscanners dann noch was zu machen sind eher gering - wenn der Virenprogrammierer was drauf hat.

Agree. Aber nicht in der Form wie dein Statement zuerst formuliert wurde: "Schwachsinn".

Hmm, da hat der Herr Haak aber wieder Erinnerungsluecken wer da zuerst von Schwachsinn geredet hat. Wie Nautilus sagt, vielleicht solltest du die Leute mit ein bisschen mehr Respekt behandeln?

Widersprüchlich, da eine Emulation für ein generic unpacking ist anders aufgebaut als eine normale CodeEmu für Viren etc. . Es gibt zwangsläufig andere "Trigger" um die Emulation abzubrechen etc. Ein Generic Unpacking dann für Viren einzusetzen hätte wenig Sinn, da evtl. Viren verpasst werden.

So wuerdest du das Problem angehen - und jetzt behauptest du, dein Ansatz ist die einzige moegliche Loesung? Stell dir vor, es gibt auch noch Programmierer ausser dir die was drauf haben.

Defacto benutzt NOD32 eh ein un die selbe Emulation für beides - nur halt andere Module die die Emulation steuern

Und wieder widersprichst du dir selber. Erst sagen der doppelte Einsatz macht keinen Sinn und dann "ach ja, NOD32 macht das eigentlich auch so".

Ich hatte nur nicht mehr wirklich Lust das noch großartig weiter breitzutreten.

Tja, andere arbeiten ernsthaft und du nach dem Lustprinzip.



@Nautilus:

Ausserdem habe ich nach einer kurzen Internetrecherche beschlossen, dass SkeeveDCD wohl ein Halbtroll sein muss, der zwar an heissen Forumsdiskussionen und Kontrageben interessiert ist, die Sache aber nicht wirklich voranbringen will. Daher ignoriere ich seine Postings jetzt erstmal so lange, bis er sich ernsthaft Mühe gibt, verständlich, respektvoll und konstruktiv zu schreiben.)

Nein, Aahz war der Troll, err, Demon. Noch so einer mit Gedaechtnisluecke. ;-)
Ignorierst du Andreas jetzt auch? Der ist weder verständlich, respektvoll noch konstruktiv.