Binder und Entbinder?

[rat]

Mir ist gerade ein gedanke zu einem Tool gekommen bei dem ich nicht weiß ob es ein solches verfahren in der Security Welt überhaupt gibt.

Jedem sollte ein Binder bekannt sein,ein Programm das zwei Files meist Malware und Zielprogramm mit einander verbindet.

Beispiel ist zwar Uralt aber sollte einleuchten
Binders and Malware (Part 2) :: Viruses, trojans and other malware :: Articles & Tutorials :: WindowSecurity.com

Und gerade frage ich mich ob man diese zwei Files auch wider von einander trennen könnte,bekannt ist mir kein Programm,aber Programmiertechnisch müsste es möglich sein oder schieße ich damit zuweit über das Ziel hinaus ???

Gesehen habe ich ein solches Tool jedenfalls noch nie und ein wirklicher Name wie sowas heißen könnte wüste ich auch nicht und auf diversen Reverse Engineering seiten hab ich nichts passendes gefunden.

 

[CDW]

Z.B EBFE's universal decrypter - CoderZ.cc (k.A warum sowohl coderz.cc wie auch b2h im Moment nicht gehen, vor allem deshalb ärgerlich, weil auf einer der Seiten auch die Funktionsdetails beschrieben wurden - deshalb erstmal ein Cache-Link). Link zur "Software" : http://files.mail.ru/S46EN9S46EN9S46EN9S46EN9S46EN9XX

PS: Ich habe auch noch keinen Malware-Packer/Binder gesehen, der auch nur im Entferntesten an die Komplexität eines Softwareprotectores heran kommt

Das Problem sind wohl eher die kleinen Variationen in der Umsetzung der Malware - meist wird man sich das Zeug trotzdem im Debugger anschauen müssen - und dann kann man es auch gleich dumpen. Insofern entfällt ein tatsächlicher Bedarf nach einem "Unpacker" für Malware.

 

[rat]

Ich wollte es eigentlich um eine infizierte Datei wider brauchbar zu machen wie z.b andere Securtiytools. gibt ja welche die wurden nur Infiziert verteilt oder sind nur noch in der Form zu finden meist im Gamehacking bereich ist dieses sehr oft vorzufinden.

 

[CDW]

Das verlinkte Tool würde "as is" natürlich heutzutage kaum noch gehen (man müsste auf Nativen-APIs umsteigen, z.B ZwResumeThread oder ZwWriteprocessMemory, was wiederum "Zusatzchecks" erfordert, da diese APIs auch intern im Prozess bzw. in den Win-APIs selbst häufiger verwendet werden). Es ist eher eine Art PoC.

Allerdings hatte man schon damals das Problem von "doppelt gemoppelter" Malware - ein Tool könnte durchaus mehrfach infiziert worden sein.
Und unterschiedliche Infektionsverfahren - "RupPE" (also im Speicher ausführen) sowie "Dropper"klassiker - schreiben auf die Platte und dann ShellExecute/CreateProcess drauf. Den "richtigen" Klassiker nicht zu vergessen - also Codeblock in den Programmablauf injizieren, so dass dieser komplett ohne CreateProcess und weiteren Tricks auskommt (mag natürlich sein, dass dieser kaum noch "in the wild" vorkommt).

Zudem bekommt man 2 oder mehr Dumps. Sehr häufig ist die entpackte Exe (also DumpX) die eigentliche Malware - muss allerdings nicht immer stimmen.
Das Problem ist eigentlich die Zuverlässigkeit -um auch nur halbwegs sicher zu sein, ein Programm wirklich desinfiziert zu haben, brauchts "ein bisschen mehr" an Codekomplexität. Ich kann mir ehrlich gesagt nicht vorstellen, dass ein Hobbyprojekt dieses Ausmaßes lange unbekannt verbleibt, weil es schon ziemlich in Richtung heuristischer Erkennung gehen würde - was auch den größeren, kommerziellen Projekten (aka AV-Software) immer noch Kopfzerbrechen bereitet.
Bleibt also nur Debugging - und da kommt man mit den Standard-RE-Tools wunderbar weiter (man muss sich in der Regel weder mit Codevirtualisierung noch "zerfetzten" Imports herumschlagen )

Was man eher machen könnte, wäre eine Art Sandbox, am besten auf Kernelhookebene, die Prozesstarts sowie Dateierstellung überwacht. Damit würde man relativ zuverlässig entpacken können - zumindest solange es unbekannt ist und keine "Anti"-Tricks (wie nun die Anti-AV/Anti-VM, Anti-Sandboxie) eingebaut werden. Aber da sind wir schon wieder bei gestiegener Codekomplexität und mangelnder Motivation seitens der Leuten, die sowas theoretisch auf die Beine stellen könnten