tag:blogger.com,1999:blog-5498266518143777458.post526803773888041513..comments2009-11-08T11:34:54.526+01:00Piotr Baniahttp://www.blogger.com/profile/16139783712412229709noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5498266518143777458.post-66520704281670273472009-08-11T14:56:07.794+01:002009-08-11T14:56:07.794+01:00I 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.<br /><br />- pbPiotr Baniahttp://www.blogger.com/profile/16139783712412229709noreply@blogger.comtag:blogger.com,1999:blog-5498266518143777458.post-82008941491596448862009-08-05T16:10:08.242+01:002009-08-05T16:10:08.242+01:00&#39;Urm do you mean here something like original code stealing (exchanging with stub code)?&#39;<br /><br />so basicly Write a Debug Packer..<br />something that creates a process suspened, gathers thread start addresses and then runs a &#39;unencrypt&#39; routine on &#39;non&#39; 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..<br /><br />the idea or way of this bypassing the DBI is not just non main thread<br />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 &#39;encryption&#39; stub that was called on a per thread basis?BanMenoreply@blogger.comtag:blogger.com,1999:blog-5498266518143777458.post-3369119468632311772009-08-05T15:14:34.349+01:002009-08-05T15:14:34.349+01:00MmmBop 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.<br /><br />&gt;also say we where able to take code and run a decryption routine on the<br />&gt;threads code/data sections and then during runtime run the encyption<br />&gt;routine on it to restore the code back to what it was.. would your DBI<br />&gt;be able to detect this?<br /><br />Urm do you mean here something like original code stealing (exchanging with stub code)?<br /><br />Thanks for the kind words i appreciate it:-)Piotr Baniahttp://www.blogger.com/profile/16139783712412229709noreply@blogger.comtag:blogger.com,1999:blog-5498266518143777458.post-25135867200727934382009-08-01T00:53:09.683+01:002009-08-01T00:53:09.683+01:00So 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 &#39;worker threads&#39; 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&#39;s not..<br /><br />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?<br /><br />the Non Main thread decryption thing would definitly render this attack of a &quot;aggressive binary&quot; 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..<br /><br />excellent paper!! and great work piotr as always :)!!:D<br /><br />regards BanMeBanMenoreply@blogger.com