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_*]

>Wie wir anhand der kurzen Tests bereits feststellen konnten, ist das "generic"
>Unpacking von NOD32 2.0 mangelhaft - wie das bei Trojanern wesentlich
>weiterhelfen soll ist mir schleierhaft.

Die AH besteht NICHT NUR aus dem Generic Unpacking, sondern auch aus Decompilern für Delphi und visual Basic und Heuristiken für Backdoors, Würmer etc. .

>Und warum sollte ein Generic Unpacking fuer Viren nicht wichtig sein? Damit
>koennte man polymorphe Viren decrypten.

Autsch ... offensichtlich GAR nix gecheckt. Also:

NOD32 hat eine normale Emulation für Verschlüsselungen (egal ob statisch, polymorph oder metamorph). Solch eine Emulation besitzt derzeit wohl JEDER Scanner.

Das was NOD32 seit Version 2 jetzt macht ist folgendes:
Die Emulation wurde erweitert um nicht nur Verschlüsselungen zu durchbrechen, sondern auch um EXE Packer und Crypter zu entpacken - und das OHNE zu wissen wie das Entpacken genau funktioniert. Daher lässt sich die AH nicht so leicht durch EPO oder NOP Spielchen verwirren - die statischen Unpacker aber schon.

Daher ist deine Aussage totaler Blödsinn. Denn man hat Quasi das Verfahren, das erfolgreich bei polymorphen Viren eingesetzt hat, jetzt auf Packer übertragen. Daher ist dein Vorschlag das mal umgekehrt zu machen recht widersprüchlich.

Einen Virus kannst Du zwar verstecken mit UPX, aber spätestens in der nächsten "Generation" ist er wieder ungepackt. Also ... who cares?

>Interessant ist eigentlich auch, das NOD32 damit sein eigenes Konzept (MaxSpeed)
>verletzt.

Nö. Die Advanced Heuristik ist beim OnDemand und OnAccess Scan nicht ohne weiteres verfügbar. Also kein Widerspruch und beim Mailscan kommt es auf ein paar Millisekunden nicht drauf an.

>Und um den "gewissen" Zeitvorteil geht es doch bei Heuristik, oder?

Den NOD32 eindeutig hat. Siehe auch Kommentar von forge77. NOD32 hat z.B. auch BugBear per AH gefunden - ohne irgend ein Signaturupdate.

>Ja, ich wage zu behaupten das RAV eine gute Unpacking Engine hat. Zumindest
>kenne ich Costin und Maddy und traue ihnen zu da was gescheites zu machen.

So schlecht ist die RAV Unpacking Engine auch nicht.

>Es soll ja auch Programme geben die man ueberhaupt nicht benutzen kann wegen

Eine unsichere Software ist genauso schlim (evtl. sogar noch schlimmer da eine falsche Sicherheit vermittelt wird) wie eine nicht vorhandene Software. Man sieht wozu man solche unfertigen Sachen missbrauchen kann (siehe GAV's Unpacking).

Der Beitrag wurde von Andreas Haak bearbeitet: 09.09.2003, 14:43