Protection for Native Driver / Applicaition

[KoMaR1911]

Hello

What do you think about TheMida / VMProtect / Obsidium?

i need to protect my driver and application - i need good performance and virtualization i saw some opinions about VMProtect and Themida some people said VMProtect is not good (is not hard to devirtualize) and themida is better in virtualization than vmprotect

now i want to pick Obsidium but i need some informations about their virtualization

Obsidium vs TheMida vs VMProtect?

 

Thanks

[HostageOfCode]

Haven't seen so far unpacked or devirtualized driver of any protector above. So far as far as i know exist only dynamic devirtualizers which don't see how will work in kernel mode. Only static devirtualizer for kernel mode would work  but not sure any of this exists.

Edited November 3, 2018 by HostageOfCode

[Mattiwatti]

Obsidium cannot do kernel mode protection as far as I'm aware.

You can run Themida on a .sys file, and it will do some impressive stuff and make it a few MB bigger, but after it's finished the output driver will import from kernel32.dll and user32.dll. Good luck with that.

VMProtect is the only option that has actual first class support for kernel mode drivers. Beware that its anti-debug (meaning anti-kernel debugger) is a bit of a joke IMO, definitely when compared to its user mode counterpart. But VMProtect is absolutely not easy to devirtualize, contrary to what people may have told you, so in the end you might be able to bypass the anti-debug protection in about an hour but it won't really help you in any way at all because that's not where the difficulty lies.

[VirtualPuppet]

14 hours ago, Mattiwatti said:

Obsidium cannot do kernel mode protection as far as I'm aware.

You can run Themida on a .sys file, and it will do some impressive stuff and make it a few MB bigger, but after it's finished the output driver will import from kernel32.dll and user32.dll. Good luck with that.

VMProtect is the only option that has actual first class support for kernel mode drivers. Beware that its anti-debug (meaning anti-kernel debugger) is a bit of a joke IMO, definitely when compared to its user mode counterpart. But VMProtect is absolutely not easy to devirtualize, contrary to what people may have told you, so in the end you might be able to bypass the anti-debug protection in about an hour but it won't really help you in any way at all because that's not where the difficulty lies.

I don't agree with this.

VMProtect's obfuscation is a joke. Dead-code elimination will give you semi-original code. Minor stack optimization tweaks and a few constant foldings will get you the original. The handlers are super small and easily pattern-scannable. Very easy VM to devirtualize - took me less than a week to write a devirtualizer for VMProtect (working on it only in my spare time).

Themida's obfuscation is pretty rough. Also, Themida has 3 different engines for their newest generation of VMs. To fully devirtualize the newer Themida (and to support all executables), you must do the following:

• Make a deobfuscator
• Make a parser for the generic newer VM engine
• Make a parser for FISH's combined arithmetic handlers and relocation handlers
• Make a parser for TIGER's singular handlers
• Make a parser for DOLPHIN's crypto handlers
• Figure out how hybrid virtualization works (PUMA, SHARK, EAGLE)
  • Apply this nested devirtualization

 

It's way more advanced than VMProtect, and took me roughly 2-3 months to have my own fully working (working on it only in my spare time).

[SkyProud]

Thanks for clarifying this. There's some rumor that Themida is pretty weak in China, I thought I'm the only one who regard Themida stronger than VMProtect.

For instance of MaxtoCode, it adopted Themida in early version, but switch to VMProtect to pack its runtime lately.

[Mattiwatti]

2 hours ago, VirtualPuppet said:

I don't agree with this.

VMProtect's obfuscation is a joke. Dead-code elimination will give you semi-original code. Minor stack optimization tweaks and a few constant foldings will get you the original. The handlers are super small and easily pattern-scannable. Very easy VM to devirtualize - took me less than a week to write a devirtualizer for VMProtect (working on it only in my spare time).

Themida's obfuscation is pretty rough. Also, Themida has 3 different engines for their newest generation of VMs. To fully devirtualize the newer Themida (and to support all executables), you must do the following:

• Make a deobfuscator
• Make a parser for the generic newer VM engine
• Make a parser for FISH's combined arithmetic handlers and relocation handlers
• Make a parser for TIGER's singular handlers
• Make a parser for DOLPHIN's crypto handlers
• Figure out how hybrid virtualization works (PUMA, SHARK, EAGLE)
  • Apply this nested devirtualization

 

It's way more advanced than VMProtect, and took me roughly 2-3 months to have my own fully working (working on it only in my spare time).

Yes, I'm aware of your opinion on this, as the horse has been beaten to death and further in the "Themida vs VMProtect" topic where it was hard to miss your posts.

While this all sounds very impressive, since the topic was about drivers, I'm going to stick with the protector that generates .sys files that do not import from user mode DLLs. Are you serious?

[HostageOfCode]

Have someone even tried to unpack vmp, oreans or safengine packed driver .sys? Not sure it is even possible though.

[VirtualPuppet]

52 minutes ago, Mattiwatti said:

Yes, I'm aware of your opinion on this, as the horse has been beaten to death and further in the "Themida vs VMProtect" topic where it was hard to miss your posts.

While this all sounds very impressive, since the topic was about drivers, I'm going to stick with the protector that generates .sys files that do not import from user mode DLLs. Are you serious?

It was mostly in response to the "But VMProtect is absolutely not easy to devirtualize, contrary to what people may have told you, so in the end you might be able to bypass the anti-debug protection in about an hour but it won't really help you in any way at all because that's not where the difficulty lies."

However, I have never attempted (de)virtualization of drivers, nor even protection of drivers in general, so I wouldn't know too much about the subject. However, I do agree that importing usermode system files into kernelmode space seems way too exploitable.

[Mattiwatti]

4 hours ago, VirtualPuppet said:

It was mostly in response to the "But VMProtect is absolutely not easy to devirtualize, contrary to what people may have told you, so in the end you might be able to bypass the anti-debug protection in about an hour but it won't really help you in any way at all because that's not where the difficulty lies."

However, I have never attempted (de)virtualization of drivers, nor even protection of drivers in general, so I wouldn't know too much about the subject. However, I do agree that importing usermode system files into kernelmode space seems way too exploitable.

I'm not really interested in the whole "Themida vs VMProtect" debate. There's already a topic on that with more than enough posts arguing for either side, and if I had a strong opinion either way I'm sure I would have posted in it.

Importing user mode DLLs in a driver will in fact make the driver extremely secure, because it will never run I don't feel particularly inclined to try this out, but since the kernel loader component is a lot less complex than the ntdll user mode loader because of space constraints, my educated guess would be that the user mode DLLs would in fact be mapped into kernel space, and a BSOD will then occur almost instantly after since one of the first things that happens in process initialization is a call to RtlSetUnhandledExceptionFilter, which queries the process cookie via a syscall instruction since it is assumed to be running in user mode. In the very best case the kernel mode loader will refuse to load such DLLs because of something like the subsystem not being native. In that case you merely have a driver file that will never start.

So my argument against Themida is not really based on its virtualization strengths, more on the fact that it simply cannot do what OP is requesting.

[VirtualPuppet]

1 hour ago, Mattiwatti said:

I'm not really interested in the whole "Themida vs VMProtect" debate. There's already a topic on that with more than enough posts arguing for either side, and if I had a strong opinion either way I'm sure I would have posted in it.

Importing user mode DLLs in a driver will in fact make the driver extremely secure, because it will never run I don't feel particularly inclined to try this out, but since the kernel loader component is a lot less complex than the ntdll user mode loader because of space constraints, my educated guess would be that the user mode DLLs would in fact be mapped into kernel space, and a BSOD will then occur almost instantly after since one of the first things that happens in process initialization is a call to RtlSetUnhandledExceptionFilter, which queries the process cookie via a syscall instruction since it is assumed to be running in user mode. In the very best case the kernel mode loader will refuse to load such DLLs because of something like the subsystem not being native. In that case you merely have a driver file that will never start.

So my argument against Themida is not really based on its virtualization strengths, more on the fact that it simply cannot do what OP is requesting.

I'm pretty sure I've seen a driver which was packed (and virtualized) with Themida. However, I do not know if Themida handles driver protection in a specific scheme - in fact, I don't know how Themida works with drivers at all. But I've seen it for some game protection software I messed with a long time ago - forgot the name of the software.

[JazzyBecker]

My driver can't be loaded when i protect using Themida. On their web, is not written can protect Driver.
So, i using VMProtect to protect driver. They write on their web, that VMP can protect Driver.