[S] Tutorial - TR/Dropper.Gen wegmodden

[EBFE]

Der "Dropper.Gen" wird eher an "EOF" erkannt. Also Anhängsel an die letze Section. Die meisten Crypter korrigieren (wenn überhaupt) die letze Section nicht vollständig, was dann zu der Heuristikmeldung führt.
Crypt.XPACK.Gen sollte afaik dagegen an den benutzen APIs liegen.

[marcel187]

Kannst du das bitte mit der EOF mal genauer erklären und wie man das mit dem PRoblem mit dem Dropper.Gen lösen kann, wäre sehr nett danke.

[EBFE]

Naja, die Theorie zum Fixen von EOF habe ich schon mehrmals erläutert
http://free-hack.com/showpost.php?p=331534&postcount=17
http://free-hack.com/showpost.php?p=347650&postcount=6
oder den pefixer nutzen (erweiterte Suche: pefix, Benutzername: EBFE)
was der macht:

Kleine Erklärung dazu: die VirtualSize, ImageSize und RawSize Größen werden von fast allen Linkern auf bestimmte Werte getrimmt. Heißt - sie sind ein Vielfaches von bestimmten Angaben (gleich mehr dazu). Wenn man die letzte Seciton fixt, muss man sich zwar nicht daran halten, aber dann "fällt" halt die Exe auf, weil sie z.B wie VB-Exe ausschaut, aber "komische" Werte hat.

Zu den Trimmwerten:
das sind SectionAlignment und FileAlignment.

Schau mal bei dir die Definition des IMAGE_OPTIONAL_HEADERS an:

Private Type IMAGE_OPTIONAL_HEADER
    ..
    ImageBase As Long
    SectionAlignment As Long
    FileAlignment As Long

Zitat aus MS Doku:

SizeOfImage The size (in bytes) of the image, including all headers, as the image is loaded in memory. It must be a multiple of SectionAlignment.

SectionAlignment The alignment (in bytes) of sections when they are loaded into memory. It must be greater than or equal to FileAlignment. The default is the page size for the architecture.
FileAlignment The alignment factor (in bytes) that is used to align the raw data of sections in the image file. The value should be a power of 2 between 512 and 64 K, inclusive. The default is 512. If the SectionAlignment is less than the architecture’s page size, then FileAlignment must match SectionAlignment.

Das heißt im Klartext soviel:
SectionAlignment ist für alle "Virtual" Werte verantwortlich. Sagen wir mal, es ist meistens = 1000h oder dezimal 4096. Dann sollten alle VirtualSize Angaben ein Vielfaches davon sein oder eben auf das Vielfache aufgerundet werden (auf, nicht ab!).
Vielfaches: heißt einfach "restlos durch die Zahl teilbar"
Bsp: alte VirtualSize+EOFSize=4300
der Wert ist nicht restlos durch 4096 teilbar,
dann musst du halt auf die nächste passende Größe aufrunden: 8196
Oder: EOF+VirtualSize=12030
muss man auf 12288 (hex: 3000) aufrunden.

wie man Aufrundet: angenommen, du hast EOF größe und VirtualSize der letzen Section ermittelt. Nun brauchst du noch den SectionAlignment.
Jetzt kann man mit Modulo erstmal berechnen, wieviel einem bis zum "runden" Wert fehlt:
AktVSize=EOF+VirtualSize
Rest=AktVSize MOD SectionAlignment
D.h Rest ist gleich den "überflüssigen" Bytes, also wieviele Bytes man "drüber" ist.
jetzt berechnet man noch die differenz:
Differenz=SectionAlignment-Rest.
AlignedVSize=AktVSize+Differenz

AlignedSize ist damit die endgültige, aufgerundete Größe.
Bsprechnung:
AktVSize=10000+2030=12030
Rest=12030 MOD 4096=3838
Differenz=4096-3838=258
AlignedVSize=12030+258=12288

So, dasselbe muss man nun auch mit RawSize durchführen, nur dass man hier FileAlignment nimmt:
AktRawSize=EOF+RawSize
Rest=AktRawSize MOD FileAlignment
Differenz=fileAlignment-Rest.
AlignedRawSize=AktRawSize+Differenz

allerdings gibt RawSize ja die Dateigröße an. D.h da man diesen Wert jetzt noch vergörßert, sollte man auch ans Ende der Datei genausoviele Bytes anhängen (da können 00 stehen oder auch Zufallsbytes).

Als letztes machst du noch die Anpassung des SizeOfImage:
ImageSize=ImageSize+Differenz (aus der ersten Rechnung, also Differenz, die für AlginedVSize Rechnung benutzt wurde)
oder:
ImageSize=lastSectionVirtualAdress+AlignedVSize.

So sollte es das machen, was der PEfixer macht.

Alle im Zitat erwähnten Werte lassen sich mit LordPE oder CFF Explorer auslesen und ändern.

[Devo]

der Dropper.Gen ensteht meistens durch eine verbindung zweier seiten das heißt z.B. du hast irgendwas gebunden oder gecryptet (so ist es meistens nach meinen infos)

dies bezüglich beklommt man sehr schwer nur weg , da man eine verbindung undetectet wird. dies hat vorteile so wie auch nachteile^^

es kann deine exe unstabel machen oder direkt kaputt...

av devil und viele andere methoden funzen schon lange nicht mehr ^^

wie man das problem löst weiß ich nicht ^^ ich hab es nur so beim crypten erlebt und bin dann endlich auf einen FUD crypter gestoßen (privat version) der den Dropper.Gen undetected machte

hoffe das ist so richtig... wenn nicht dann bitte korrigieren. (muss ja auch lernen )

[Diso]

Puh das heißt allso wenn ich nach dem Fixxen des PE Headers den Crypt.XPACK.Gen jetzt als neuen Fund habe, müsste ich die Scr dahingehend verändern, das er andere APIs benutzt... Man merkts mir vll an das ich Neuling auf dem gebiet bin... Aber um realistisch zu bleiben. Um da was zu verändern müsste ich meine VB Kenntnisse ausweiten richtig? Oder würde es vll einfach schon reichen den Offset der gefunden wird zu verschlüsseln?
Das ist die Stelle die detected ist...

Jemand ne Idee? Danke schon mal in vorraus^^

[EBFE]

Das ist exakt der Eintrag für eine DLL- Und so wie ich das sehe, auch die einzige DLL
http://sandsprite.com/CodeStuff/Unde...g_imports.html
D.h der erste Eintrag ist wichtig und kaum zu ändern (jedenfalls ohne PE Kenntnisse).
Der nachfolgende (FF FF FF FF) ist Timedatestamp und kann z.B auf 00 00 00 00 oder einen beliebigen Wert gesetzt werden. Du kannst natürlich auch "richtigen" Wert einsetzen (z.B aktuelles Datum hier umrechnen: http://www.aritso.net/index.php )
der nächste Eintrag (FF FF FF FF) ist ein forwarder chain und kann auf 00 bzw beliebigen Wert gesetzt werden.
der Wert 154F4 ist ein Verweis auf den DLL Namen. Den findest du auf der Adresse: ImageBase+154F4 -> ich tippe also stark auf 4154F4

Den kann man auch ändern:
such dir irgendwo freien Speicher, trägst den DLL Namen samt der abschließenden 00 ein (das letze Byte muss ein "Terminator" ==00 sein). Nun nimmst du die Adresse, an der du den Wert eingetragen hast (z.B 4154D4) und subtrahierst die ImageBase (in dem Fall 400000). Den Wert trägst du nun in 415300 statt 154f4 ein (siehe eigenes Screenshot). Alle Rechnungen natürlich im Hexformat .

Damit hast du die Stelle so ziemlich verändert. Allerdings sagt der Fund der Stelle (ich vermute mal mit irgendeinem Tool) noch nicht aus, dass wirklich auch diese für XPACK.Gen Meldung verantwortlich ist - hier ließt nur Antivir die Import Infos aus und kann dann halt die einzelnen Funktionen und API Strings ermitteln. Wenn man nun diese 20 Bytes irgendwie überschreibt, kann Antivir auch nicht zu den ImportStrings gelangen (nur läuft die Exe dann auch erstmal nicht ).

PS: Groß/Kleinschreibung ist bei DLL Namen egal (kann also MsVbVM60.DlL heißen) - ob das was bringt ist eine andere Frage.

[G0dLik3]

komisch wenn ich einen dll-name groß/klein schreibe ,ist zwar die antivir meldung weg, aber dannach kommt ....dll konnte nicht gefunden werden