Wie herausfinden ob eine Ausführbare gepackt ist?

[Metal_Snake2]

hi,

hat einer einen blassen schimmer wie ich herausfinden kann ob eine ausführbare binärdatei mit PE Packern wie z.B. UPX komprimiert wurde? Villeicht in der PE Header durchstöbern?

danke für antworten.

[Olli]

Also die beste Indikation ist meiner Meinung nach die Entropie, aber das ist auch nicht hunderprozentig sicher. Einfach ein Histogramm der Verteilung der einzelnen Bytewerte anzeigen lassen und schon siehst anhand der Gleichmäßigkeit, ob die Datei wahrscheinlich gepackt ist.

Mit Sicherheit kann man das ja sowieso nur für bekannte Packer herausbekommen und "Crypter" sind in diesem Sinne auch als Packer zu verstehen. Ansonsten kann ja jeder seinen eigenen Packer schreiben ...

[himitsu]

Eigentlich bräuchte man doch nur die Anwendung ausführen, sich im Prozessspeicher das FileImage suchen und mit der EXE zu vergleichen? :gruebel:

[Metal_Snake2]

@himitsu: Wie meinst du das? Welche werte sol ich miteinander vergleichen.
@Olli: Ist das nicht ein bischen zu aufwendig? Das benötigt sicherlich auch einiges an rechenzeit. Der Process Explorer erkennt eine gepackte exe wie ein flitzebogen:-)

[himitsu]

Im Normalfall gibt es sozusagen eine Kopie der "EXE" im RAM, welche ausgeführt wird.

Wenn die Datei aber gepackt wurde, dann ist doch am Anfang der EXE ein winziges Programm (der Entpacker), welches stattdessen die entpackte Version der EXE im RAM ablegt und diese dann ausführt.

Denn der Computer kann ja nur mit der entpackten Version arbeiten.

Also wenn das Abblid im RAM anders ist, als die Daten in der EXE, dann wurde es verändert und demnach könnte die EXE also gepackt sein.
Am einfachsten bräuchte man wohl nur die Größe des Abbildes mit der der EXE vergleichen ... es müßte ja größer sein.

[Olli]

Zitat:

Zitat von Metal_Snake2

@Olli: Ist das nicht ein bischen zu aufwendig? Das benötigt sicherlich auch einiges an rechenzeit. Der Process Explorer erkennt eine gepackte exe wie ein flitzebogen:-)

Und du bist dir sicher, daß der *alle* Packer erkennt?! Die Standardpacker kann man mit Signaturen erkennen, keine Frage. Deine Frage war aber generisch gestellt und so habe ich sie beantwortet.

Zitat:

Zitat von himitsu

Wenn die Datei aber gepackt wurde, dann ist doch am Anfang der EXE ein winziges Programm (der Entpacker), welches stattdessen die entpackte Version der EXE im RAM ablegt und diese dann ausführt.

Denn der Computer kann ja nur mit der entpackten Version arbeiten.

Also wenn das Abblid im RAM anders ist, als die Daten in der EXE, dann wurde es verändert und demnach könnte die EXE also gepackt sein.
Am einfachsten bräuchte man wohl nur die Größe des Abbildes mit der der EXE vergleichen ... es müßte ja größer sein.

Das ist etwas naiv:
1.) kann sich das Datensegment auch so ändern
2.) ist die Ausrichtung im Speicher anders als auf Platte, die Daten unterscheiden sich also schon per-se!

Außerdem kommt es dann noch darauf an, welche Form der Entpacker wählt:
1.) reserviert er eine Section in der PE-Datei, die in der Datei 0 Byte, im Speicher aber x (x>0) ist?
2.) benutzt er VirtuallAlloc & Co. um Speicher für die entpackten Daten zu allozieren?
3.) benutzt er eine völlig unbekannte Form?

Ja, die von mir beschriebene Methode ist nicht schön, sie kostet Rechenaufwand, sie ist nicht perfekt - aber besser geht es meines Erachtens nach aktuell noch nicht.

[Garfield]

Vielleicht bringt es etwas, sich die aPLib anzusehen. Die Library wird zum Beispiel von PEspin benutzt.

UPX verwendet zum Beispiel UCL.

UPX wird - wie es auf der Homepage aussieht - von einigen seriösen Softwareherstellern verwendet, während PESpin öfter im Zusammenhang mit Trojanern auftaucht.

Oder Du siehst Dir an, was ein PE Explorer ausgibt:
ZB - http://www.pe-explorer.com/ 129 $, 30 Tage Trial

Beziehungsweise siehst Du Dir die Strukture des Headers an:
http://www.delorie.com/djgpp/doc/exe/
http://www.wotsit.org/search.asp?s=EXE

oder das noch:
http://www.itee.uq.edu.au/~cristina/...is96/table.htm

Dummerweise alles in Englisch. Eine Seite in Deutsch, welche interessant war, war vermutlich nicht legal und bei ein paar txt-Dateien sprang der Virenwächter an.

[Metal_Snake2]

Danke für die links.

Ich habe jedoch eine sehr einfache Methode herausgefunden(die nicht so ganz sicher ist). Ich untersuche einfach die ausführbare nach allen möglichen namen von Exe-Packern. Den mit ist aufgefallen das Exe packer in die binary den namen des packers hinzufügen.

Hier ist auch schon eine liste aller packer: http://en.wikipedia.org/wiki/Executable_compression

[Olli]

Zitat:

Zitat von Metal_Snake2

Hier ist auch schon eine liste aller packer

:wall: ... soll ich heute mal einen Packer schreiben, mit dem ich alle meine Programme ab jetzt packe? Der hat dann keinen String für die Erkennung drin usw. - wie erkennst du ihn? Es gibt Myriaden von Packern!

[Metal_Snake2]

Naja war nur mal ein anhaltspunkt. Hab leider mom. noch keinen anderen brauchbaren entdeckt.

[Lillebrohr]

Hi,

also ich hätte da einen Lösungsansatz. Man sucht sich die Raw Size und die Virtual Size der einzelnen Sections raus und vergleicht diese. Wenn sich R.Size und V.Size deutlich unterscheiden kann man davon ausgehen das diese .exe, .dll gepackt ist.
Aber aufgepasst, das die V.Size der .DATA Section sich stark gegenüber der R.Size unterscheiden kann liegt wohl daran das der Programmierer schonmal viel Memory pre-allocated also reserviert hat für irgendwelche Variablen oder Arrays.

Hier mal ein Beispiel einer gepackten Exe mit Aspack :

Zitat:

CODE-Section
-> VSIZE = 1B2000
-> RSIZE = 99E00
DATA-Section
-> VSIZE = D000
-> RSIZE = 6800

Und jetzt noch ein Beispiel einer nicht-gepackten Exe:

Zitat:

text-Section
-> VSIZE = 3344A
-> RSIZE = 34000
DATA-Section
-> VSIZE = 9FA8
-> RSIZE = 5000

Die Unterschiede bei der "normalen" Exe sind recht gering.
Das ist mir bei vielen Packern aufgefallen. Es wäre halt ein Weg um ne grobe Analyse zu zeigen.

Bye

[himitsu]

Zitat:

Zitat von Lillebrohr

Das ist mir bei vielen Packern aufgefallen.

Na ja, verwunderlich ist was wohl nicht ... oder was sollte denn sonst der Sinn von 'nem Packer sein :mrgreen:

[Olli]

Zitat:

Zitat von Lillebrohr

Die Unterschiede bei der "normalen" Exe sind recht gering.

Aha, und wer definiert "normal"?

Ich habe schon mehrere Anwendungen geschrieben, wo ich absichtlich und unter Vollbesitz meiner geistigen Kräfte die Sektionsparameter angepaßt habe. Daß dir das bei einer Delphi-EXE selten passieren wird, ist mir klar. Andere Sprachen/Compiler lassen solche Modifikationen aber zu ... (und diese Modifikationen können gute Gründe haben, wie zB Speicher, welcher vom Loader alloziert wird und direkt ohne Umwege von der EXE benutzt werden kann).


Und nochmal für Metal_Snake2: es gibt keinen Unterschied zwischen gepackten und sog. verschlüsselten PE-Dateien. Wenn du generisch etwas rausbekommen willst, ist die Verteilung (Stichwort: Histogramm) noch die beste Chance, allerdings auch nur unter der Annahme, daß es sich nicht um eine "Verschlüsselung" ala ROT13 handelt.

[Metal_Snake2]

@Lillebrohr:

Danke für den ansatz, jedoch funzt das bei mir nicht. Ich Öffne mit dem PE-Explorer einmal die mit UPX Komprimierte datei und die nicht Gepackte Datei, jedoch merke ich keinen unterschied zwichen den einzelnen größen der PE Section Headers.
Die Ausführbaren dateien waren klein, gepackt 20KB und undgepackt 31KB, villeicht kann es auch daran liegen?? Jedoch waren die werte absolut identisch.

@Olli:
Ja deine idee ist wohl eher die "Vollständig" Funktionierendere Methode, jedoch würd ich lieber eine einfachere lösung vorziehen, wie z.B. unterschiedliche werte zu vergleichen den an irgendweiner stelle muss sich ja eine gepackte und nichtgepackte ausführbare unterscheiden.

Nachtrag: mir ist aufgefallen das gepackte exe datein keine Relocation Table beinhalten, villeicht kann man ja dort ansetzen.

[Olli]

Zitat:

Zitat von Metal_Snake2

jedoch merke ich keinen unterschied zwichen den einzelnen größen der PE Section Headers.

Er meinte die Sektionen, nicht die Section Headers.

Zitat:

Zitat von Metal_Snake2

Ja deine idee ist wohl eher die "Vollständig" Funktionierendere Methode, jedoch würd ich lieber eine einfachere lösung vorziehen, wie z.B. unterschiedliche werte zu vergleichen den an irgendweiner stelle muss sich ja eine gepackte und nichtgepackte ausführbare unterscheiden.

Das ist schon klar, aber eine triviale Lösung gibt es für dieses Problem nicht. Es gibt zuviele verschiedene Methoden um eine EXE zu packen, so daß es mindestens ebensoviele Indikatoren gibt ...

Eine Heuristik ist da eben die beste Methode. Alternativ: Emulator ...

[himitsu]

20/31KB, wer kommt denn aus diese Idee so'ne Datei nohmals zu packen?
ich meine ... irgendwo kann man es auch übertreiben.

[Olli]

Zitat:

Zitat von himitsu

20/31KB, wer kommt denn aus diese Idee so'ne Datei nohmals zu packen?
ich meine ... irgendwo kann man es auch übertreiben.

Vielleicht Leute aus der Demo-Szene?

[himitsu]

hmmm, aber selbst auf 'ne Diskette würden dann immernoch tausende dieser "Demos" draufpassen ... Platzmangel sollte doch bei diesen Kleinen (Größen) wohl keiner herschen :stupid:

[brechi]

Hier mal ein paar Ansätze die man geschickt kombinieren muss um ein möglichst gutes Ergebnis zu erzielen. Dabei wird dann aber auch ein Crypter etc. als Packer erkannt.

Es dürfen nur gängige Sektionnamen benutzt werden (.text .data)
Ist bei einer Sektion die Rawdatengröße 0 dann ist es (wahrscheinlich) gepackt
Welche Daten stehem am Entrypoint? siehe z.b. Programm PeID
Wo liegt der Entrypoint? Nur in der Codesection und 1. Section erlaubt. (OllyDbg erkennt die unter anderem so)

[Lillebrohr]

Hey brechi,

Bei Delphi liegt der EP oft auch in der DATA-Section also wars das mit CODE-Section.

@Olli:

Zitat:

Es wäre halt ein Weg um ne grobe Analyse zu zeigen.

!!! ;)

@himitsu:

Zitat:

Na ja, verwunderlich ist was wohl nicht ... oder was sollte denn sonst der Sinn von 'nem Packer sein

Genau und ebend das machen wir uns zu Nutze ! ;)

[brechi]

Zitat:

Zitat von Lillebrohr

Bei Delphi liegt der EP oft auch in der DATA-Section also wars das mit CODE-Section.

Das bezweifel ich. Zeigst mir nen Sourcode der beim kompilieren den EP in die Datasection legt?

[Olli]

Zitat:

Zitat von Lillebrohr

Bei Delphi liegt der EP oft auch in der DATA-Section also wars das mit CODE-Section.

Wenn du auf die Namen der Sektionen anspielst, die haben keine, aber absolut keine, Bedeutung für den PE-Loader!!!

Sie sagen also nicht, wie häufig fälschlich angenommen, etwas über den Inhalt aus. Die Attribute einer Sektion geben mehr Aufschluß als der Name, da kann man sich nämlich gewaltig irren. Übrigens: Sektionsnamen können jegliche 8bit-Zeichen enthalten, nicht nur anzeigbare.

[brechi]

Ich denk mal er meint

TImageNtHeaders.OptionalHeader.BaseOfData sowie
TImageNtHeaders.OptionalHeader.BaseOfCode

Diese setzt Delphi aber (von D2-D7) immer auf die DATA sowie CODE section (da mein ich jetzt den Namen) und die DATA section hat nicht das Executableflag gesetzt. Somit kann der Entrypoint nicht in BaseOfData/Datasection zeigen. Und eben für diese Behauptung hätte ich gerne nen Source + Delphi Version, wo das möglich sein soll.

[mirage228]

Hi,

Vielleicht kann man sich ja anschauen, wie PEID arbeitet: http://peid.has.it/ ...

mfG
mirage228

[brechi]

Hab ich doch schon geschriebn, des schaut sich die Daten am EP an.

[Metal_Snake2]

Peid selbst arbeit mit mehreren ansätzen um herauszufinden ob eine ausführbare gepackt ist.


Man kann nun folgende ansetze geschickt kombinieren um eine gute Chance zu haben ob eine exe gepackt ist.

1. Entropie. Diese methode scheint wohl die best geeignetste zu sein. Leider habe ich keine ahnung wie ich das jetzt in Delphi umsetzen könnte. Ich hab das internet durchsucht und folgendes gefunden(Leider kein Code).

Link
Benötigte Entopie- Formel

Wie kann man jetzt z.B. ca 10000 bytes einer PE mit hilfe der Entropie untersuchen?



2. Man untersucht den EP Eintrit. Ist er in der ersten Sektion(Code-Sektion)?
3. Geängige Sektionsnamen wie Code,Data usw. upx z.B. erstellt 2 Sektionen namens upx0 und upx1.
4. Ist die RawData Größe = 0 einer Sektion?
5. Naja ansonsten nach bestimmten strings durchsuchen.

[negaH]

Metal_Snake2 fragte mich per PN:

Zitat:

hi,

falls ich störe einfach ignorieren.

Meine Frage: Hast du villeicht eine idee wie ich die Entropie einer Datei(exe datei) berechnen kann.
Mein ziel ist es damit herauszufinden ob eien exe gepackt/komprimiert wurde.
Da ja die zeichen in einer Komprimierten datei wesentlich Chaotischer(mehr nach dem zufall) geordnet sind
als bei einer unkomprimierten(eher mit mehr ordnung) kann man da ja eigentlich die Entropie anwenden.

Wie müßte ich deinen Code aus der libary umändern??


danke für eine antwort.

Ich stelle mal hier meine Antwort rein, hoffe Metal_Sbake2 hat nichts dagegen.

Hi

Fragende stören nie

Also erstmal: welcher Code aus welcher Library ?

Ich habe den Thread der DP mit Spannung mitgelesen.

Technisch gesehen gibt es nur eine Möglichkeit mit 100% Sicherheit eine ausführbare Datei zu klassifizieren. Dazu benötigt man eine SandBox und einen teil-softwarebasierten Emulator. Das ist eine Machine die quasi jeden Befehl der gestarteten EXE emuliert und somit die absolute Kontrolle darüber hat was der Code der EXE macht. Dies funktioniert deshalb weil ja das Ziel der EXE es ist ausgeführt zu werden. Dagegen gibt es auf Hackerseite keinen "Schutz" Der Emulator kann nun erkennen wie die EXE geladen wird und die notwenigen Codesegment Manipulationen, eg. das Entpacken/Entschlüsseln in das Codesegment im Speicher, erkennen.

Leider ist dies sehr aufwendig

Bleiben noch zwei Wege übrig:

1.) Klassifikation über selektierte Merkmale. Man versucht also das was zb. Himitsu im Thread vorschlug, nämlich die Eigenheiten aller bekannten Packer/Crypter zu ermitteln und quasi wie bei einem Virenscanner auf bekannte Signaturen in einer Datenbank zurückzugreifen. Das funktioniert im Falle von Viren sehr gut, benötigt aber eine ständig auf aktuellem Stand gehaltene Datenbank.

2.) der mathematische Weg wie Olli ihn vorschlug. Entropie bzw. mal größer gefasst Mustererkennung ist das Stichwort. Es gibt dabei mehrere Möglichkeiten:

a.) packe die EXE mit einem ZIPer. Eine gepackte EXE lässt sich logischerweise weit weniger packen als eine ungepackte EXE. Durch ein Preprozessing, sprich Zerlegung des EXE Images in seine Sektionen und Resourcen, kannst du jeden relevanten Teil einer EXE separat packen. Als Indiz ergibt sich das Bild das das CODE und RESOURCE Segment meistens gepackt wurden und die Relocationtable entfernt wurde.

b.) neben dem Zippen die einfache Entropie ermitteln. Man geht dabei davon aus das eine EXE auf Grund der Opcodes/Jump etc. eine Struktur aufweist die sich deutlich von anderen Daten unterscheidet. Tja, leider muß dies nicht so sein. Zb. die Entropie (Verteilung/Anzahl von Symbolen) von Text ist deutlich unterschiedlich von ausführbarem Code. Aber in jeder heutigen EXE werden Stringkonstanten, ja ganze Texte ebenfalls im Codesegment gespeichert. Oder die Entropie von gepacktem zu verschlüsseltem Code im Vergleich: beide haben die gleiche Entropie, diejenige die Zufall entspricht. Und beide sollte nicht weiter komprimierbar sein.

c.) höhere Mathematik und reale Mustererkennungen. Auf diesem Gebiet habe ich selber längere Zeit ge-hobby-forscht Ich kann hier aber nur über das reden was ich selber als Idee verfolgt hatte.
Als erstes wird die Datei in ein 2D Frequenzspektrum umgewandelt, quasi einer zeitlicher Spektralanalyse unterzogen und die Bytedaten der Datei dient als sequentieller Datenstrom als Input.

Warum macht man diesen Schritt ?
1.) Quantisierung der Datenmenge. Jede Datei ist unterschiedlich groß, hat unterschieldiche Anordnungen der Segmente und Dateninhalte. Man muß nun einen Weg finden der diese unterschiedlichen Datenmenge auf eine Zischendatenmenge reduziert die immer gleiche Größe und Struktur besitzt. D.h. aus einem komplexen Fingerabdruck wird mithilfe eines komplexen Verfahrens nur wenige wichtige Vergleichspunkte errechnet die dann für alle Fingerabdrücke immer die gleiche Größe/Anzahl an Punkten und Strukur besitzt. Durch die Quantisierung werden also unterschiedliche Dateien in einen immer gleichgroßen "Fingerabdruck" umgewandelt.
2.) Spektralanalyse. Dabei geht es darum quasi die Art und Weise des Vorkommenes aller 256 möglichen Symbole in der Datei zu ermitteln. Man ermittelt also wie oft und wie periodisch (Amplitude und Frequenz) die einzelnen Symbole auftauchen. Bei Texten wird man feststellen das ganze Symbole fast niemals auftreten, bei EXEs wird man feststellen das 0 sehr oft vorkommt.
3.) 2D Spektralanalyse. Man macht nun sequientiell für zb. von Daten-scheiben a 256b-16Kb an Daten nacheinander eine Spektralanalyse. Das hast du schon öfters in Filmen gesehen, bei Sprachanalysen von Agentenfilmchens. Meistens ist das ein sich von Links nach Rechts bewegendes farbiges Band das von rot nach gelb über grün nach blau geht. Darin kann man zb. die Basstakte einer Musik erkennen.
In unserem Falle ist das von Vorteil da wir davon ausgehen können das eine EXE einen sequientiellen Aufbau haben wird der ja nach Segment unterschiedliche Dateninhalte speichert und somit auch unterschiedliche Spektren erzeugen wird. Eine 2D Spektralanalyse mancht nun auch eine Spektralanalyse über den kompletten Zeitraum.

Was heist das immer "Spektralanalyse" ?
Wichtiger ist das WIE, und das ist ganz einfach machbar über Fourier Transformationen, genauer gesagt die FFTs Fast Fourier Transformationen. Wenn wir uns eine Musik anhöheren dann wird eine FFT diese komplexe Schallwelle der Musik in all ihre Sinusfrequenzen die dieses komplexe Schallmuster ergeben, zerlegen. Je nach Stärke = Amplitude der einzelnen Frequenzen wird die FFT in ihrem Resultat einen stärkeren "Ausschlag" erzeugen. Die FFT liefert uns also ein Bild darüber wie sich eine komplexe Schallwelle aus den verschiedenen Frequenzen zusammensetzt und zeigt auch noch deren Stärke an. Nun, simple Bytes aus einer EXE kann man auch als "Schallwelle" ansehen, man kann sogar mit einer FFT zwei Zahlen multplizieren (sogar höchst effizient wenn diese Zahlen enorm groß sind, aber das ist ein anderes Hobby von mir )
Eine 2D FFT macht nun viele Einzel-FFT sequientiell über die Datenblöcke einer EXE. Wie in einem Musikstück werden wir dann den zeitlichen Verlauf der Schallwellenänderungen analysieren, wir sehen dann den Beat, den Bass, das Einsetzen des Sängers und zusätzlich natürlich immer auch all die Frequenzen der Schallwellen. Wir sehen also wann und mit welchem Bass der Beat komponiert wurde, mit welcher Stimmlage der Sänger singt etc. pp.
All das ist 1 zu 1 übertragbar auf jeden beliebigen Datenstrom ja sogar Chemischer Substanzen und Stoffe.

Nun, aber wie erkennen wir jetzt an Hand dieser Daten eine EXE ?
In meinem Projekt benutzte ich dazu Neuronale Netzwerke. Das sind quasi lernfähige Computer"hirne" (ein sehr naiver Vergleich allerdings). Wichtig ist nur: die NN's können von uns trainiert werden und sie können auf Mustererkennungen trainiert werden (Spracherkennungen, Bilderkennungssysteme, Gesichtserkennungen usw. usw.) Aber am wichtigsten ist es zu wissen das ein NN Muster erlernt indem es autom. und selbständig diese klassifizieren lernt OHNE das wir als Menschen wissen welche markanten Merkmale das NN für diese Klassifizierung real heranzieht. D.h. wir sagem dem NN was es klssifizieren lernen soll und es lernt Merkmale zu finden ohne das wir wissen wollen welche Merkmale es gefunden hat. Wir sind also nur am Ziel interessiert.

Einem NN müssen wir aber erstmal die Datenmengen vorverdauen, zurechtbiegen so das es die Aufgabe überhaupt lösen kann. Und dazu müssen die Daten quantisiert werden, quasi auf einen Einheitsvektor abgebildet werden. Denn ein NN hat nur eine feste und begrenzte Anzahl von Eingabeneuronen (quasi der Input in das Netz).

Wir führen also zb. eine 256 Punkte FFT durch, ermitteln also die Amplitudenwerte von maximal 128 Frequenzen/Symbolen. Diese 128 Punkte der FFT dienen dem NN als Input. Bei der Trainigsphase lassen wir einfach alle Dateien einer großen Festplatte per FFT umrechnen. Wir ordnen dann diese Dateien in eine Datenbank ein, zb. sortiert nach Textdateien,binären Dateien,komprimierten Dateien etc.pp. Nun haben wir eine Trainingsdatenbank und trainieren unser NN. Das NN wird nun autom. aus einem 2D Spektrum einer Datei die Antwort liefern ob sie eher eine Textdatei, binäre Datei etc. pp. ist.

Nungut, exakt damit habe ich rumgespielt und doch sehr gute Erfolge erzielen können. EXE Dateien hat er zuverlässig erkannt und auch ob sie komprimiert und oder verschlüsselt waren. Allerdings konnte mein NN eben nicht zwischen gepackten EXE und verschlüsselten EXEen unterscheiden lernen. Einfach weil es da meistens keinen Unterschied gibt in den Daten. Leider war diese Unterscheidung, bzw. das Erkennen kryptographisch geschützter Daten mein eigentliches Ziel.


Fazit: Ich stimme grundsätzlich Ollis Ansatz über die Entropie zu gehen zu, allerdings im weiterem Sinne gefasst. Ich würde Mustererkennungssysteme benutzen da die einfache Entropie zu wenig aussagekräftig sein wird, ja sogar wenn man die EXE vorher in ihre einzelne Segmente zerlegt und diese separat analysiert. Das liegt einfach daran das Code heut auch viel an Daten enthalten wird.

Als technisch leichter und denoch relativ effizienter Weg wäre noch wie oben angedeutet die Test-Komprimierung der Daten möglich. Zufallsdaten, verschlüsselte Daten und komprimierte Daten lassen sich weit weniger nochmals komprimieren als andere Daten. Aber Vorsicht auch hier gilt das in einer unkomprimierten EXE große Portionen an zb. Bildern wie JPPEGs, PNGs, GIFs sogar Bitmaps enthalten sein können und diese sind meistens alle komprimiert. ALso auch hier keine wirkliche Sicherheit in der Erkennung.

So, mal wieder ein langer Beitrag, sorry

Gruß Hagen

[Olli]

Zitat:

Zitat von negaH

Dagegen gibt es auf Hackerseite keinen "Schutz"

Leider doch. Das Timing ist der Hinkefuß des Emulators, kann aber über eine Art Profiling an echtem Code wieder behoben werden ...

Leider sind sogar die Emulatoren der AV-Firmen relativ langsam (trotz dynamischer Emulation) und meist auf bestimmte Befehle beschränkt.

[Garfield]

Ein Packer Detector:
http://www.rdgsoft.8k.com/RDG%20Packer%20Detector.htm


PE Compact, unten ist ein Schema vor und nach der Kompression.
http://www.bitsum.com/pec2.asp