[DevirtualizeMe] Themida 2.3.5.0 Full

[HellSpider]

Hi.

My DevirtualizeMe series continue with this entry.

I have protected a simple file containing 18 keyboard initiated functions with different virtual machines using a full version of Themida 2.3.5.0 .

The file does not have any extra protection as the idea of this challenge is to understand the virtual machines. Also non-virtual machine protection settings are kept to a minimum, meaning no antidebug, no API redirection etc. Basically only antidump is enabled on top of the virtual machines.

All of the virtual machine code blocks are identical in sense of instructions.

List of function initiators:

q = FISH32 White
w = FISH32 Red
e = FISH32 Black
r = TIGER32 White
t = TIGER32 Red
y = TIGER32 Black
u = PUMA32 White
i = PUMA32 Red
o = PUMA32 Black
a = SHARK32 White
s = SHARK32 Red
d = SHARK32 Black
f = DOLPHIN32 White
g = DOLPHIN32 Red
h = DOLPHIN32 Black
j = EAGLE32 White
k = EAGLE32 Red
l = EAGLE32 Black

 

As said earlier, the idea is just to understand the differences between the virtual machines. Thus the identical code blocks.

~ HellSpider

devirtualizeme_themida_2.3.5.0_hellspider.rar

 

Edited August 18, 2016 by HellSpider

[koolk]

Something interesting is going on with this exe, seems to be a bug in themida.

 

But before I will talk about that, I will talk about the new dolphin vm. After this post I finally finished adding support for this vm. 

So dolphin is basically (not surprisingly) more of the same, with a little new concept that is different from fish and tiger (splitting basic operations handlers to more handlers)

 

Eagle is just fish virtualized by dolphin (in the same way that puma is tiger virtualized by fish, and shark is fish virtualized by tiger).

 

Now about the wierd bug. In nested vms, usually all the handlers are virtualized by the same vm engine. But this time things were different.

Eagle used two engines vritualize the fish handlers - one of them is dolphin that was generated for that, and the other one was the regular dolphin that was generated for the dolphin only (with the corresponding color) 

Puma used three engines - the fish engine generated for puma, the regular fish handler, and a fish engine virtualized by dolphin (= eagle, it used the same eagle engine instance). So puma in your exe was tiger virtualized by fish/eagle.

Shark was even weirder. Shark should be fish virtualized by tiger engine, but again, in addition to the tiger engine, it used the puma engine too (tiger virtualized by fish) And it was the same broken puma engine! Which mean that some of the handlers were fish virtualized by tiger virtualized by fish virtualized by dolphin!

 

This is why the eagle vms in your exe are fast (as expected from about ~20 virtualized opcodes), but puma is slower (3 levels of vms instead 2), and shark is extremely slow - about few minutes for shark black (~20 opcodes virtualized by 4 levels of vms!)

 

I don't know why it happened. Themida generated the right amount of engine, but it seems that it got confused when choosing the engines for the nested vms.

 

Anyway, the fixed exe is attached with all the unneeded sections removed (took my script half an hour to devirtualize all those 18 engines ><) (EDIT: After running it with pypy instead python it took less than 8 minutes)

unpackme.unpacked.fixed.exe.zip

Edited September 11, 2015 by koolk

[HellSpider]

 

Something interesting is going on with this exe, seems to be a bug in themida.

 

But before I will talk about that, I will talk about the new dolphin vm. After this post I finally finished adding support for this vm. 

So dolphin is basically (not surprisingly) more of the same, with a little new concept that is different from fish and tiger (splitting basic operations handlers to more handlers)

 

Eagle is just fish virtualized by dolphin (in the same way that puma is tiger virtualized by fish, and shark is fish virtualized by tiger).

 

Now about the wierd bug. In nested vms, usually all the handlers are virtualized by the same vm engine. But this time things were different.

Eagle used two engines vritualize the fish handlers - one of them is dolphin that was generated for that, and the other one was the regular dolphin that was generated for the dolphin only (with the corresponding color) 

Puma used three engines - the fish engine generated for puma, the regular fish handler, and a fish engine virtualized by dolphin (= eagle, it used the same eagle engine instance). So puma in your exe was tiger virtualized by fish/eagle.

Shark was even weirder. Shark should be fish virtualized by tiger engine, but again, in addition to the tiger engine, it used the puma engine too (tiger virtualized by fish) And it was the same broken puma engine! Which mean that some of the handlers were fish virtualized by tiger virtualized by fish virtualized by dolphin!

 

This is why the eagle vms in your exe are fast (as expected from about ~20 virtualized opcodes), but puma is slower (3 levels of vms instead 2), and shark is extremely slow - about few minutes for shark black (~20 opcodes virtualized by 4 levels of vms!)

 

I don't know why it happened. Themida generated the right amount of engine, but it seems that it got confused when choosing the engines for the nested vms.

 

Anyway, the fixed exe is attached with all the unneeded sections removed (took my script half an hour to devirtualize all those 18 engines ><) (EDIT: After running it with pypy instead python it took less than 8 minutes)

 

 

Extremely impressive.

 

This answered a lot of questions, especially why the shark red and black variants were so slow.

[GIV]

Hi.

Is interesting that in your file the imports are not allocated outside the main file virtual space.

A simple OEP dump will unpack the file.

So if any sensitive data is out of the VM borders all can be changed.

 

 

http://www15.zippyshare.com/v/K5bVuQNl/file.html

 

Folder nou.rar

Edited October 13, 2015 by GIV

[HellSpider]

Hi.

Is interesting that in your file the imports are not allocated outside the main file virtual space.

A simple OEP dump will unpack the file.

So if any sensitive data is out of the VM borders all can be changed.

 

I don't really understand what you mean. The import scheme corresponds to the normal MASM style, which means creating one block of "JMP DWORD PTR [iATPOS]" entries and just calling these jumps from different parts of the code.

 

So when Themida handles the imports without redirection (as specified by the used protection settings), it will just alter the block of jumps making each entry a direct jump to the imported module. If you dump the file without creating a new import table, the dump will work as long as the imported modules are mapped into the same base addresses as on your system.

 

So for example, as you did not rebuild the import table, it will look like this when I load it:

 

 

Obviously, this file wont run in this condition, because my modules are loaded at different base addresses.

 

And yes, any sensitive data outside the VM blocks can be changed. That's why all of the "sensitive" data is inside the VM blocks and the purpose of the task was to devirtualize these blocks. As this dump has cut the Themida sections, these VM entries jump to an undefined memory region making it crash even if the imports would be fixed correctly.

Edited October 3, 2015 by HellSpider

[GIV]

Yep.

Yhis dump have the TM sections removed.

Could have them on the right place but makes no difference to me.

As i know Themida allocate al API's to VM'ed portions of memory outside the main exe.

That is why i was so puzzled. Because i see that the redirection was into main exe virtual space and not in upper addresses.

The IAT table can be restored via 4 patch points like in LCF-AT script or just bp on acces on a API and them memory bp on write on code section to see where is written.

You can with a little patience to restore the IAT table or write a small Odbg script to automate.

It remains to add the VM'ed antidumps and i think all is done.

In you case.

As you can see a dedicated person will UV the VM'ed code so i guess that Oreans cannot sleep well.

Edited October 4, 2015 by GIV

[Deathway]

As you can see a dedicated person will UV the VM'ed code so i guess that Oreans cannot sleep well.

 

Indeed, they need to change their schemas, like CISC and Risc on its moment 

Edited October 4, 2015 by Deathway

[kao]

Well, there are few dedicated persons in the world who can do that. Noobs can't. And there are no up-to-date public tools (Deathway's tools are not working for most VMs already).

So, after doing simple cost-benefit analysis, Themida guys will sleep really well.

[GIV]

VMProtect VM was unvirtualized like Themida was?

[Conquest]

Well, there are few dedicated persons in the world who can do that. Noobs can't. And there are no up-to-date public tools (Deathway's tools are not working for most VMs already).

So, after doing simple cost-benefit analysis, Themida guys will sleep really well.

The problem lies with time available to one person. Its not hard to make one but its rather time consuming to reverse all the patterns one by one. A public repo would been much better but i guess some people are really making money out of it (Its like paying the thugs to keep other thugs out of your business)

[koolk]

I think that the new VMs of Oreans are the best VMs out there.

Until then all the VMs were with simple handlers, and the complexity were in other areas (in the obfuscation of the handlers or the obfuscation of the "vm code").

Oreans made vms with auto-generated complex handlers. (and now it isn't even necessary to obfuscate the handlers or the vm code)

(As a side note: They protect their newer products with improved version of tiger, which does obfuscate the vm code with their regular obfuscation and using internal vm registers, but beside being annoying it doesn't add much to the protection..)

I started working on VMProtect (just had one day to work on it), it looks similar to CISC, but they implement many operations with a small set of simple handlers, which make this vm more complex (than CISC, not the new vms, but I don't have the right to say that until I fully devirtaulize it)

 

And about time consuming - it is enough to just devirtualize one of those new vms, if you do it good.

I work on this project as a side project for fun (mostly on weekends), and it took me about two months to fully devirtualize fish. But after that it took me just a week to add support for tiger, and even less to add support for dolphin.

 

I don't make money from this, but I don't share this project because then there won't be a point in this protection

[GautamGreat]

Brother

koolk

can you give me your script

[GIV]

Brother

koolk

can you give me your script

Yep. I thougth will raise some asker soon.

Look good no?

[cachito]

Yeah, scripts for everyone!!

[Sound]

Extremely impressive., saw a lot of discussion.

 

Br.

Sound