ABSTRACT
Nowadays most of the malware applications are either packed or protected. This techniques are applied especially to evade signature based detectors and also to complicate the job of reverse engineers or security analysts. The time one must spend on unpacking or decrypting malware layers is often very long and in fact remains the most complicated task in the overall process of malware analysis. In this report author proposes MmmBop as a relatively new concept of using dynamic binary instrumentation techniques for unpacking and bypassing detection by self-modifying and highly aggressive packed binary code. MmmBop is able to deal with most of the known and unknown packing algorithms and it is also suitable to successfully bypass most of currently used anti-reversing tricks. [...]
Paper can be found at:
http://piotrbania.com/all/articles/pbania-dbi-unpacking2009.pdf
PAPER: Generic Unpacking of Self-modifying, Aggressive, Packed Binary Programs
Posted On //
4 comments
4 komentarze:
So basiclly it can be bypassed by not having a stub like most classical packers..by simply using a per thread decryption routine to restore original code to 'worker threads' and not as the first order of business in the main thread...this may bypass the decryption detection in the DBI, but not if it was done on a per thread basis.Which it's not..
also say we where able to take code and run a decryption routine on the threads code/data sections and then during runtime run the encyption routine on it to restore the code back to what it was.. would your DBI be able to detect this?
the Non Main thread decryption thing would definitly render this attack of a "aggressive binary" useless, but we all have more work to do..im guessing the protection artists that have packers based on the use of stubs are shaking in there boots, right now..
excellent paper!! and great work piotr as always :)!!:D
regards BanMe
MmmBop currently does not support multithreading :-( but i believe it is something that still can be done. I would need to build some memory manager and separate the structures like CPU context from each other.
>also say we where able to take code and run a decryption routine on the
>threads code/data sections and then during runtime run the encyption
>routine on it to restore the code back to what it was.. would your DBI
>be able to detect this?
Urm do you mean here something like original code stealing (exchanging with stub code)?
Thanks for the kind words i appreciate it:-)
'Urm do you mean here something like original code stealing (exchanging with stub code)?'
so basicly Write a Debug Packer..
something that creates a process suspened, gathers thread start addresses and then runs a 'unencrypt' routine on 'non' encypted code..essentially encrypting it..then flushs the sections back to the file..during runtime the Main thread would create worker threads that calls a encryption routine, that would restore the original code..reverse encryption..
the idea or way of this bypassing the DBI is not just non main thread
as gone over above,cause adding multithreaded support is easy and I expect that to be quite easily implemented, but the idea here is that your DBI recognizes decryption routines and stops just after them to dump the image..so if MmmBop was multithreaded, would the DBI be able to pick up a 'encryption' stub that was called on a per thread basis?
I see well yes for current time being it is not supported my MmmBop. However i think the situation u mentioned should be possible to handle, however i would need to see such packer first :-) Generally the DBI is able to collect entire execution trace of each thread in a very reasonable time so you can even do some further manual work to guess whats going on with the decryption routines.
- pb
Post a Comment