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

@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?

Exakt das was Du erwähntest. Bestimmte Sachen wie NOPs etc. werden ignoriert.

@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 .)

Hast Du daran gedacht das generisches Unpacking bei NOD32 nur mit der AH funktioniert? Ansonsten:

NOD32 nutzt oft "Single Point Signatures". Das bedeutet das sie während der Emulation bei bestimmten Ereignissen anhalten und diesen Punkt als Referenz für für Scans an fixen Offsets nutzen. Sollten also einige Signaturen relativ zum EIP erstellt worden sein, werden diese nicht mehr erkannt nach dem Ändern des EIP.

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?

Siehe OpCode Filter *g*.

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

Das hat mehrere Gründe. Einmal wären die Signaturen gar nicht so ohne weiteres kompatibel. Dann gibt es Engine Probleme. Die Engines sind einfach zu intelligent. Wieder andere lehnen es aus "Prinzip" ab. Weil es eine Erkennung wäre, "wenns bereits zu spät ist".

[Gast_Gladiator_*]

Das hat mehrere Gründe. Einmal wären die Signaturen gar nicht so ohne weiteres kompatibel. Dann gibt es Engine Probleme. Die Engines sind einfach zu intelligent. Wieder andere lehnen es aus "Prinzip" ab. Weil es eine Erkennung wäre, "wenns bereits zu spät ist".

Nicht zu vergessen die anschliessenden Performance "Probleme".
Die meisten AV Scanner haben schliesslich noch eine Reihe weiterer Dinge nebenher zu tun, als "nur" einen Memory Scan wie zum Beispiel andere Tasks/Services fuer POP3/SMTP, Webfilter, Scriptfilter und und und.
Und wenn eine AV einen Memoryscan hat dann muss man einiges mehr beachten als nei einem statischen Trojaner Scanner. Es geht schon los mit Viren. Dort kann man anschliessend nicht zwangslaeufig wie bei einem TrojanerScanner einfach den Prozess terminieren - das ist zumindest bei den Viren fatal, welche Dateien verschluesseln und den Schluessel aktiv im Speicher aufbewahren. Bestes Beispiel hierfuer ist der DOS OneHalf, unter Windows gibt es auch einige wenige Exemplare, aber auch die muessten beachtet werden.

[Gast_blablabla_*]

was soll eigentlich ein opcode filter bringen? ich meine irgendwelche opcodes müssen ja untersucht werden, wenn nop gefiltert wird baut man eben einen opcode ein der nicht gefiltert wird.....

Der Beitrag wurde von blablabla bearbeitet: 08.09.2003, 12:28

[Gast_Gladiator_*]

Das war eigentlich jetzt sinnloses "blablabla"

Wer sagt dass ein OpCode Filter nur und wirklich nur ausschliesslich NOP's filtert ?
Ein OpCode Filter kann sogar Jump's und Call's richtig abwickeln. Sprich Du bringst dann die Detection Routine auch nicht mehr durcheinander, wenn Du nach dem EntryPoint paar "sinnlose" Jump's hin und her machst.
So ein OpCodeFilter ist schliesslich kein Emulator der bei einem Befehl den er nicht kennt abbricht.

[Gast_blablabla_*]

immer diese geistreichen überaus intelligenten wortspiele mit meinem nick ;-)

meine aussage is vollkommen logisch: du MUSST irgendeine art opcodes nicht filtern, weil wenn du das nicht tust, dann kannst du auch nix erkennen .....den rest kann man sich selber denken

[Gast_Andreas Haak_*]

was soll eigentlich ein opcode filter bringen? ich meine irgendwelche opcodes müssen ja untersucht werden, wenn nop gefiltert wird baut man eben einen opcode ein der nicht gefiltert wird.....

Meine Ansicht nach nicht sonderlich viel *g*. Defacto wäre es einfacher das Teil durch den Emulator zu jagen und nach bestimmten Flags Konstellationen zu suchen.

Aber jeder wie er mag. OpCode Filter is ja CopyRight by Gladiator. Genau wie "Half Emulation".

[Gast_Gladiator_*]

Ist denn das wirklich so schwer zu verstehen ?
Packer erkennt man an gewissen OpCodes die nach Vorschaltung eines OpCode Filters im Prinzip stehen koennen wo sie wollen. Mit diesem OpCode Filter sammelt man Informationen und fuehrt dann nicht wie bisher von fast allen praktiziert 1:1 Abfragen in Form von CRC ueber den Unpack Stub oder Signaturen durch. Weil die Signatur Methode hat den Nachteil, dass man SEHR SEHR KURZE Signaturen verwenden muesste, welche dann zu gepackten Programmen fuehren obwohl sie ueberhaupt nicht gepackt sind (Sprich Packerfehlalarme) um solche Patchereinen zu beruecksichtigen.

Meist sind es irgendwelche MOV's oder JMP's die zur Identifizierung beitragen.
Sprich man macht die Packerdetection einfach frei ausbaubar ala

void Rulez_4_Packer_XYZ( void )
{
AddOpCode( 0x66, 0x81, 0xe3, 0xff, 0xff) // equ to CMP WORD PTR [ESI],FFFF
...blablabla...
...more opcodes...
...blablabla...
return;
}

So, damit traegt man das dann von mir aus in eine Packer OpCode Hashliste ein.
Werden alle (ausschlaggebenden) Opcodes des Packers XYZ gefunden (von mir aus auch *egal in welcher Reihenfolge* und egal wieviele tausende andere OpCodes dazwischen stehen) wird das Packerflag aktiv gesetzt.

[Gast_blablabla_*]

Ist denn das wirklich so schwer zu verstehen ?

ja, das frage ich mich auch...ich hatte mein beispiel ja eigentlich rauseditiert...aber was solls....

bsp.

mov reg, imm32


mach ich nen

xor reg, reg
add reg, imm32

draus und die erkennung geht wieder in die hose weil ich die opcodes immer irgendwie anders stellen kann! solche umstellungen kriegst du IMMER hin.

ohne emulation geht da gar nix!

[SkeeveDCD]

Was ist eigentlich wenn man über den eigentlich Packer-Stub noch einen Fake-Stub drüber macht, der einen bekannten Packer (z.B. UPX) so stark ähnelt das der Virenscanner das Programm als mit UPX gepackt erkennt - und nur so entpacken will?

[Gast_Gladiator_*]

Und wo fuehrt dann der Call oder der Jump in den FakeStub ?
Es geht auch nicht daraum dass man das *hundert* Prozent sicher machen kann - das geht nicht mal mit einer Emu.
Es sollte aber nicht soooooooooooo einfach sein, dass man nur schnell paar nop's einfuegt und es wird nichts mehr erkannt.

Aber ich nehme mal an das werden wir alles in a² sehen
Ich haette uebrigens schon mal gerne eine Version per email - steht ja in allen Foren man muss sich nur melden, dann bekommt man es per email - habe ich hiermit jetzt getan

[Gast_Gladiator_*]

ohne emulation geht da gar nix!

ROFL!

Ja denkst Du ich bin doof oder was ?

case 0x80: // ---===[ ADD ]===---
switch (OpCodeBuffer[ip+1])
{
case 0xC0: // add al, imm
if (r.al+OpCodeBuffer[ip+2]>255)
{
r.al = r.al+OpCodeBuffer[ip+2] - 0x100;
r.flags = r.flags | 2;
}
else {
r.al = r.al+OpCodeBuffer[ip+2];
r.flags = r.flags & 0xFFFD;
}
ip++; ip++; ip++;
break;

case 0xC2: // add dl, imm
if (r.dl+OpCodeBuffer[ip+2]>255)
{
r.dl = r.dl+OpCodeBuffer[ip+2] - 0x100;
r.flags = r.flags | 2;
}
else {
r.dl = r.dl+OpCodeBuffer[ip+2];
r.flags = r.flags & 0xFFFD;
}
ip++; ip++; ip++;
break;

case 0xC3: // add bl, imm
if (r.bl+OpCodeBuffer[ip+2]>255)
{
r.bl = r.bl+OpCodeBuffer[ip+2] - 0x100;
r.flags = r.flags | 2;
}
else {
r.bl = r.bl+OpCodeBuffer[ip+2];
r.flags = r.flags & 0xFFFD;
}
ip++; ip++; ip++;
break;

...

Ein Ausschnitt aus dem 16 Bit PackerOpCode Filter - den gibts genauso fuer 32 Bit Register.

Sowas nenne ich aber noch lange nicht EMULATION.

[Gast_Andreas Haak_*]

Aber ich nehme mal an das werden wir alles in a² sehen 
Ich haette uebrigens schon mal gerne eine Version per email - steht ja in allen Foren man muss sich nur melden, dann bekommt man es per email - habe ich hiermit jetzt getan 

*lol* ... bist auf der Liste. Allerdings muss ich darauf bestehen, das es a² free ist - keine der kommerziellen Versionen und folglich ohne unpacking. Aber wenigstens verbreitet a² beim Scannen dann keine Viren wie ein anderes Programm von einem gewissen Gladiator *g* - kennst Du den? *g*
Wie isses eigentlich in Seattle?

Der Beitrag wurde von Andreas Haak bearbeitet: 08.09.2003, 14:13

[Magnus]

Packer-Erkennung ist kein Problem. TrojanHunter macht das schon Problemfrei, auch bei modifizierte stubs. Das wirkliche Problem ist die Entpackung. Jeder Viren-Scanner den ich kenne der Unpacking-Fähigkeit hat benutzt Statische Entpackung. Das heist, der Packer-Algo wurde für jeden Packer Reverse-Engineered. Dynamische Entpackung/"Emulation Entpackung" ist alles Quatsch. Wenn jemand was anderes sagen Will, dann bitte dafür Beweise auch liefern. (Und nicht nur "Ich habe gehört scanner XYZ entpackt per Emulation.") So weit ich das untersucht habe (und ich habe da Tests gemacht) ist Emu-Entpacking viel, viel zu langsam um Praktisch nutzbar zu sein.

[Gast_Andreas Haak_*]

Hast Du auch NOD32 mal untersucht, Magnus?

[Gast_Gladiator_*]

Packer-Erkennung ist kein Problem. TrojanHunter macht das schon Problemfrei, auch bei modifizierte stubs. Das wirkliche Problem ist die Entpackung. Jeder Viren-Scanner den ich kenne der Unpacking-Fähigkeit hat benutzt Statische Entpackung. Das heist, der Packer-Algo wurde für jeden Packer Reverse-Engineered. Dynamische Entpackung/"Emulation Entpackung" ist alles Quatsch. Wenn jemand was anderes sagen Will, dann bitte dafür Beweise auch liefern. (Und nicht nur "Ich habe gehört scanner XYZ entpackt per Emulation.") So weit ich das untersucht habe (und ich habe da Tests gemacht) ist Emu-Entpacking viel, viel zu langsam um Praktisch nutzbar zu sein.

HURRA

Genau so sieht das aus.
Oder besser SO SOLLTE ES AUSSEHEN

Alles das was wichtig ist (sprich UPX, ASPack, tElock usw.) wird als frei compilierbarer ANSI-C Source (Damit es dann auch anschliessend unter Unix oder auch auf nem Apple funktioniert) compiliert.

Immer noch verdaechtige Files mit typischen Packer Flags (bsw. LoadLibary & GetProcAdress etc) kann man dann immer noch notfalls durch eine Emu jagen.

Eine Emu fuer alle Files ist VIEL ZU ZEITAUFWENDIG im Realtime Scan.

Schon mal darueber nachgedacht wenn ein Exchange Server 500 Mails pro Minute bekommt und alles emuliert wird ? Gute Nacht Herr Gesangsverein.

[Magnus]

Nein, habe ich nicht. Beim letzten Rokop-test haben die ja aber in sache Packers nicht Gut abgesnitten: http://www.rokop-security.de/main/article.php?sid=473

[Gast_Andreas Haak_*]

Schon mal darueber nachgedacht wenn ein Exchange Server 500 Mails pro Minute bekommt und alles emuliert wird ? Gute Nacht Herr Gesangsverein.

Schon mal darüber nachgedacht, das die Emu ja nicht strohdoof sein muss und ALLES zu emulieren hat? Bereits am Dateiaufbau kannst Du erkennen ob eine Datei gepackt ist oder nicht. Sogar ohne Dir auch nur einen einzigen Opcode anzuschauen. Wenn sie gepackt ist, kannst Du die Emu anwerfen - ansonsten nicht. Im normalen Betrieb stört das kaum. Wieviele Runtime Packed/Crypted files werden wohl auf ner normalen Maschine (oder von mir aus auch auf nem Mailserver beim täglichen Maildurchlauf) zu finden sein? 10 - 20? Auf die paar Sekunden die zu emulieren kommts dann auch nimma an.

Der Beitrag wurde von Andreas Haak bearbeitet: 08.09.2003, 17:33

[Gast_Andreas Haak_*]

Nein, habe ich nicht. Beim letzten Rokop-test  haben die ja aber in sache Packers nicht Gut abgesnitten: http://www.rokop-security.de/main/article.php?sid=473

Da wurde NOD32 1 getestet - nicht die 2er Version mit generic unpacking etc. .

[Magnus]

Warum soll ich denn glauben das NOD Emu-Unpacking-Fähig ist? Hat jemand das getestet?