Unpacking VB6 Packers With IDA Pro and API Hooks (Re-Upload)

[@dassumpfhuhn7225]

Just found you and instantly fall in love with those kinda videos! Just cool

[@Ivo--]

Love the classic music :D

[@SakiiR]

What is the track ? :p

[@Ivo--]

Darude - Sandstorm Nah j/k it's Push It To The Limit from the movie Scarface.

[@AndrewBoudreau]

Is there a link to the video you reference at the 2:00 minute point? About windows user/kernel layers?

[@OALABS]

For sure! We cover this in two videos kzbin.info/www/bejne/eZq9ZndsrNF8qNkm42s and kzbin.info/www/bejne/qHW0nptnrquKfbcm23s. The first link is probably the most in-depth and the second one describes how to relate this call chain to sandbox output.

[@purpler3m910]

Not sure if you have made a video already for what i am about to ask, but when the malware writes code into the injected process little bit at the time, do you dump the buffer on the Nvirtualwritememory API right before you get a ResumeThread is that right?

[@OALABS]

This is a great question. I think we have covered it in a few tutorials but we may not have been clear about the process. So this is pretty common to see the code written section by section instead of as one big blob. There are two ways to deal with this: 1) The easy way is to to out a bp on writeprocessmemory, ntwritevirtualmemory, etc. And then when you get the bp check the buffer where the data is being written _from_. This will often contain the full unpacked PE even though it is just being written into the process a little bit at a time. Then you can just dump that buffer to get the full PE. 2) The hard way is to use the same break points but if the _from_ buffer doesn't have the full PE you will just have to copy each section piece by piece and reconstruct it yourself. 2.5) You might also get lucky where you can just wait for all the sections to be written into the remote process and break on resumethread. Then attach a second debugger to the the remote process and dump it and reconstruct the imports with scylla... this won't always work though so the first two options are more reliable.

[@purpler3m910]

@@OALABS ahhh! i just had an enlightenment moment. Thanks a lot OALABS. I will give it a try.

[@HXMCPP]

I have just one question please , why reversing application compiled by VS is much harder than GCC compiler . (C/C++ Win) ?

[@OALABS]

I'm not sure if I understand the question correctly, if you are asking about reversing Linux binaries vs. Windows or VisualStudio compiler vs mingw-gcc? Either way it's a good question and the answer for both is sort of the same! So when you compile software directly with a compiler (ex. mingw-gcc) the compiler will basically compile the code that you pass it (with some optimization depending on the flags). However when you start a project in VisualStudio the IDE adds in a lot of boilerplate code that is not visible in the IDE but is compiled into the binary. This code includes things like exception handling, window setup/teardown, etc. You can strip this out by customizing your project settings but by default it will be added. This means that a VisualStudio compiled binary will have some extra code in it that you will have to ignore to get to the important functions, making it appear larger and harder to analyze at first glance.

[@HXMCPP]

@@OALABS thanks for the explanation ! and yes . i was talking about mingw vs VS compiler . Specialy when i don t change the default compilation settings i find a lot of weird assembly Instructions and some Undocumented stuffs .

[@DmytriE]

I like your videos a lot! They're very helpful and informative. I was curious about the other ways to tell that something is a VB6 file? Is it worth looking at the PE file? 2) Are there way to obfuscate the import files? If so and you can't see the files imported, what are the tricks and indications within the PE file affirm your suspicion that it's a VB6 file?

[@OALABS]

Hey glad to hear you are enjoying the videos! So identifying VB6 is actually quite easy as it will have to have that MSVBVM60 dll imported. The first thing the PE will do is jump into the DLL. I haven't seen any VB6 PEs where the import of that dll was obfuscated. It doesn't mean it can't be, I just haven't seen it. Another quick way to tell would be to look at the code ... when you disassemble the binary you will see a small amount of assembly and most of the rest of the file will be p-code. If you come across a sample that is VB6 but it has been obfuscated to look like a normal PE I would be very interested if you could share : )

[@thunt5777]

Hi, Firstly thanks to making this video. But I hv a question , the sample we analysed is VB (P-Code ) , by same way can we Unpack VB(Native) file. I tried but not happened. Can u look into this.

[@OALABS]

The same methodology should work for you... as you can see in the video we don't really care about the p-code at all just the API calls. Regardless of the code those API calls will be the same. Good luck!

[@thunt5777]

@@OALABS Thanks .

[@thunt5777]

@@OALABS I tried with with both Api Map and Unmap , And Virtual Write also, but not able to find Unpack file. Can u please help me out in this . md5,9DCE2B5CAA5EE7A572955BEDDC0709D1

[@thunt5777]

Hi kindly reply @OALabs

[@mohamedzakaria9124]

where i can find this program

[@SimoneAonzo1988]

FYI if you are trying to repeat this example in Windows 10 x64 set a breakpoint on kernel32_CreateProcessW, instead of kernel32_CreateProcessInternalW. @OALabs do you know the subtle difference? Google wasn't helpful

[@OALABS]

We actually cover this in detail in an older video ; ) kzbin.info/www/bejne/eZq9ZndsrNF8qNkm42s

[@2arx992]

what is the intro music?

[@far2ez539]

A remix of the old "WE'LL DO IT LIVE" meme by Bill O'Reilly

[@pratikmehta9580]

Love it