[DevirtualizeMe] VMProtect 3.0.9

[Raham]

Hi Guys

 

and here is my solution for 32bit one.

 

devirtualizeme32_vmp_3.0.9_v1_deVM_Raham.zip

 

PS: my decompiler is in progress state, so tell me if you found mistake in X86 instructions.

Kind Regards

 

Edited September 21, 2017 by Raham

[HellSpider]

On 9/21/2017 at 7:24 PM, Raham said:

Hi Guys

 

and here is my solution for 32bit one.

 

devirtualizeme32_vmp_3.0.9_v1_deVM_Raham.zip

 

PS: my decompiler is in progress state, so tell me if you found mistake in X86 instructions.

Kind Regards

 

Well done.

I can't say if each instruction matches 100% since I lost my original compiled binaries due to a windows reinstall. The recompiled binary from the same source code is extremely close. All constants are the same in any case and the general code flow is in order.

I will accept this solution in the OP.

[Raham]

9 hours ago, HellSpider said:

Well done.

I can't say if each instruction matches 100% since I lost my original compiled binaries due to a windows reinstall. The recompiled binary from the same source code is extremely close. All constants are the same in any case and the general code flow is in order.

I will accept this solution in the OP.

Hi HellSpider.

Please post second challenge for VMP 32bit.

[HellSpider]

17 hours ago, Raham said:

Hi HellSpider.

Please post second challenge for VMP 32bit.

Challenge posted.

[xSRTsect]

Hello.

 

Who the heck designed the new security requirements as far as passwords for this forum? Its absolutely insane.

This time I submit a fully devirtualized version of the aforementioned crackme for the 64 bit version of VMP.

Of course, I didn't work on this entirely by myself, it was more like a joint project with other reversers that are no strangers to this forum.

 

Because we all had the same interests (code deobfuscation/VMs devirtualization/Unpacking) we decide to create our own group, where we essentially reverse some well known protectors for PE files.

Current group members:

 

@fvrmatteo

@SmilingWolf

@mrexodia

@xSRTsect

@Raham

@root

@Downpour

 

People involved in the coding of the 64 bit VMP devirtualization tool:

@fvrmatteo, @SmilingWolf, @mrexodia,  @xSRTsect.

 

The tools will never be released.

 

There is a tiny chance that an outsider can join our group IFF you have pwned an interesting protector and you are willing to share your insight with our group or you are willing to impress us with some mad unpacking / deobfuscation skills.

 

Best Regards,

 

The European Reversers Alliance.

 

Edit: Added gay @ symbols to the nicknames (some people really wanted that). And added a more gay version of the devirtualized binary which is essentially the same but with the devirtualized functions linked statically.

 

devirtualized.rar

inlined_version_ERA.7z

Edited May 23, 2018 by xSRTsect
Gay Reasons.

[HellSpider]

On 5/23/2018 at 3:47 AM, xSRTsect said:

Hello.

 

Who the heck designed the new security requirements as far as passwords for this forum? Its absolutely insane.

This time I submit a fully devirtualized version of the aforementioned crackme for the 64 bit version of VMP.

Of course, I didn't work on this entirely by myself, it was more like a joint project with other reversers that are no strangers to this forum.

 

Because we all had the same interests (code deobfuscation/VMs devirtualization/Unpacking) we decide to create our own group, where we essentially reverse some well known protectors for PE files.

Current group members:

 

@fvrmatteo

@SmilingWolf

@mrexodia

@xSRTsect

@Raham

@root

@Downpour

 

People involved in the coding of the 64 bit VMP devirtualization tool:

@fvrmatteo, @SmilingWolf, @mrexodia,  @xSRTsect.

 

The tools will never be released.

 

There is a tiny chance that an outsider can join our group IFF you have pwned an interesting protector and you are willing to share your insight with our group or you are willing to impress us with some mad unpacking / deobfuscation skills.

 

Best Regards,

 

The European Reversers Alliance.

 

Edit: Added gay @ symbols to the nicknames (some people really wanted that). And added a more gay version of the devirtualized binary which is essentially the same but with the devirtualized functions linked statically.

 

devirtualized.rar

inlined_version_ERA.7z

Results from quick value tests compared to my published file:

Devirtualized = Key#1 = different | Key#2 = different
Inlined version = Key#1 = ok | Key#2 = different

Did these work on your systems?

[xSRTsect]

1 hour ago, HellSpider said:

Results from quick value tests compared to my published file:

Devirtualized = Key#1 = different | Key#2 = different
Inlined version = Key#1 = ok | Key#2 = different

Did these work on your systems?

 

I think I know what the problem was. Would you try this again? If it doesn't work for proc2 then please supply your register state after executing CPUID.

devirtualizeme64_vmp_3.0.9.inlined_fx.exe

[HellSpider]

3 hours ago, xSRTsect said:

 

I think I know what the problem was. Would you try this again? If it doesn't work for proc2 then please supply your register state after executing CPUID.

devirtualizeme64_vmp_3.0.9.inlined_fx.exe

Still no. CPUID state:

RAX : 000000000000000B
RBX : 00000000756E6547
RCX : 000000006C65746E
RDX : 0000000049656E69
RBP : 000000014000F7F8
RSP : 000000000014F9E0
RSI : 0000000000000000
RDI : 0000000080006010
R8  : 0000000000000000
R9  : 0000000000030001
R10 : 000000000025042E
R11 : 0000000000000246
R12 : 000000000025042E
R13 : 0000000000000100
R14 : 0000000000000000
R15 : 0000000000000000

Hint:

Spoiler

Check the compare conditions for which branch is to be executed based on the CPUID result

 

[xSRTsect]

5 hours ago, HellSpider said:

Results from quick value tests compared to my published file:

Devirtualized = Key#1 = different | Key#2 = different
Inlined version = Key#1 = ok | Key#2 = different

Did these work on your systems?

 

Well I am very sorry about this. But let me tell you why we are having all these fails: It turns out that our tool produces correct code, however not pretty enough, so what we did was to 'reverse' this code a little and re-write its logic in a more compact/appealing asm program. Unfortunately we are only humans and so I happened to copy a few values incorrectly namely the second if is <0xa and not 0xd (I seriously have no clue on what this value was doing there). Hopefully this time for the win,

 

 

 

devirtualizeme64_vmp_3.0.9.inlined_fx_.exe

[deepzero]

Quote

 

The European Reversers Alliance.

 

Ah, I like it! Some fresh spirits!

 

If you dont mind, I would love to know what your general approach is in your tool. Is it a direct attack on VMP's VM implementation or a trace-and-deobfuscate approach?

[VirtualPuppet]

7 hours ago, deepzero said:

Ah, I like it! Some fresh spirits!

 

If you dont mind, I would love to know what your general approach is in your tool. Is it a direct attack on VMP's VM implementation or a trace-and-deobfuscate approach?

Since VMProtect is one of the easier protectors to devirtualize (since the VM is very simple) I assume they targetted Vmp specifically.

They probably use basic compiler theory to collapse instruction-expansions and then categorize vm handlers based on patterns. Thereafter the rest is easy, trace a functions P-code to determine handler chain, then again use compiler theory to determine x86 equivalent of stack machine code.

For my own devirtualizer, I went with a much different approach; i wrote an Intel/AMD x86(_64) cpu simulator and use it to interpret my data for a full trace that allows branch prediction in realtime. This significantly narrows down things and after that I just have to "reduce" the instructionset. When this is done, I can categorize handlers based on a specific method I came up with, that I won't disclose here, as it seems to work for all VMP versions and i don't want to damage VMP in any way. And once they're categorized I run them through my converter for the restored code.

The smart thing about the cpu simulator is that I can also unpack using this method, and it will make sure malware does not impact me

 

[HellSpider]

15 hours ago, xSRTsect said:

Well I am very sorry about this. But let me tell you why we are having all these fails: It turns out that our tool produces correct code, however not pretty enough, so what we did was to 'reverse' this code a little and re-write its logic in a more compact/appealing asm program. Unfortunately we are only humans and so I happened to copy a few values incorrectly namely the second if is <0xa and not 0xd (I seriously have no clue on what this value was doing there). Hopefully this time for the win,

devirtualizeme64_vmp_3.0.9.inlined_fx_.exe

This one is completely restored, the instruction order and used registers are fairly similar too. Good job!

[xSRTsect]

12 hours ago, deepzero said:

Ah, I like it! Some fresh spirits!

 

If you dont mind, I would love to know what your general approach is in your tool. Is it a direct attack on VMP's VM implementation or a trace-and-deobfuscate approach?

 

I would love to tell everyone everything, but its evident by now that the VMP developers read this forum and tailor their compiler/packer to break the tools produced here.

(See for instance how Raham's resource protection memory hack using traverse-then-decrypt of the resource tree tool was rendered useless within a very short period of time after release).

I am not trying to protect the vmp developers or anything, I don't really care about them.

[mrexodia]

On 5/27/2018 at 9:18 AM, VirtualPuppet said:

Since VMProtect is one of the easier protectors to devirtualize (since the VM is very simple) I assume they targetted Vmp specifically.

They probably use basic compiler theory to collapse instruction-expansions and then categorize vm handlers based on patterns. Thereafter the rest is easy, trace a functions P-code to determine handler chain, then again use compiler theory to determine x86 equivalent of stack machine code.

For my own devirtualizer, I went with a much different approach; i wrote an Intel/AMD x86(_64) cpu simulator and use it to interpret my data for a full trace that allows branch prediction in realtime. This significantly narrows down things and after that I just have to "reduce" the instructionset. When this is done, I can categorize handlers based on a specific method I came up with, that I won't disclose here, as it seems to work for all VMP versions and i don't want to damage VMP in any way. And once they're categorized I run them through my converter for the restored code.

The smart thing about the cpu simulator is that I can also unpack using this method, and it will make sure malware does not impact me

 

Maybe you could solve VMP32 (2) to show how awesome your undisclosed method is?

One idea I toyed with was to do simple input/output tainting on the handler level and do some black box tests to determine what operation a handler does. This should work at least on VMP because handlers perform very simple operations. Regardless it would be a waste of time because the difficult part is not to disassemble the VM opcodes, but rather restoring as perfect x86 as you can.

[Raham]

Hi.

its month after challenge v2, but i had free time just now, to work on target.

Result of both Key 1 & 2 are identical compared to Protected file.

 

 

Kind Regards

devirtualizeme32_vmp_3.0.9_v2_DeVM_Final_OK.exe

Edited November 12, 2018 by Raham

[deepzero]

Quote

they have connected each handler with the following handler like some sort of linked list and unique

It's called threading / threaded execution.

 

edit: disregard, putting downvoted posts at the end of the thread successfully confused me.

Edited November 12, 2018 by deepzero

[HellSpider]

On 11/12/2018 at 4:25 PM, Raham said:

Hi.

its month after challenge v2, but i had free time just now, to work on target.

Result of both Key 1 & 2 are identical compared to Protected file.

Kind Regards

devirtualizeme32_vmp_3.0.9_v2_DeVM_Final_OK.exe

Excellent. Instructions were fine. Good job!

[Mecanik]

Pretty sad though. This means that there is no protector someone can use to protect their products/ideas.

Everything can be unpacked, the only question remains which one is "stronger/harder" to unpack.

Since no such tools will be ever released, the "best" RE should make a list with pros/cons/recommendations for those people that have no such experience.