Themida with crack

VMProtect's virtual machine is almost an exact replica of the Themida CISC VM featuring stronger obfuscation, and as such it works in the exact same way, which makes it almost equally weak.

If you want to compare the complexity of the newer Themida VMs e. EAGLE vs. VMProtect's VM, you're probably looking at a complexity scale saying or something like that.

TL;DR Don't listen to the guys above, as they are completely clueless on the topic. Pick Themida if you have to choose between the two of them. I think you're either trolling or extremely retarded because you're clearly uninformed.

If you're talking about protection, as JohnWho stated, everything can be unpacked, and easily even. The real dealbreaker is the virtualization. Well we are talking about protection , as OP requested " I would like to protect a small Win32 file and deciding which protection software to use" not virtualization.

If we're talking about the best virtualization, agile. Sorry, I am new to this. I want to protect my file from being reverse engineered, so it seems that virtualization is what I want. First you claim virtualization is not "protection"..?

If he OP wants protection, and asks which protection software to go with, it includes all features of the protection software, such as virtualization. Themida offers exceptional protection in real situations, when you don't want people to understand certain functions.

Next you pick a. NET virtualizer and tell us that, if we're to deduce the best virtualization protection software while the choice stands between VMProtect and Themida we should pick Agile. In case that point flew over your head, here's another stupid point to this:. Don't put words in my mouth. Never claimed virtualization isn't protection.

OP didn't ask for a native packer , stop assuming because it makes you look extremely uninformed and stupid. It ISN'T protection at all. Clearly you're the latter. OP is looking for constructive feedback , not some edgy 14 year olds opinion on freeware. Sprux thank you very much for your detailed response. Do not listen to that idiot. Themida is NOT an obfuscator , here's literally the developer of themida saying it himself.

You make me cry a little everytime I see your replies. I will before-hand declare that this is my last response to your impeccable rant of stupidity, but I feel the need to put out these points.

Well guessing from the first post of the topic creator, he wants to use virtualization as protection otherwise he wouldn't think about VMProtect or?

I didn't invest time in reversing Themida protected targets yet, neither code virtualized targets but soon. Currently I'm working on VMProtect a lot in my free time, and what I can say that the VMs have a pretty straightforward pattern when it comes to the handlers.

For me the biggest problem was actually the mutation of the assembly, but with compiler optimization techniques you can clean up the code pretty good and continue your analysis on the demutated code which is one half the devirtualization process.

The other half is pretty much identifying how the handlers work, analyzing them and translating them back but even this is dynamically possible with coding and I would think it's less effort than reversing the different themida vms. Themida's newer VMs furthermore utilizes combined handlers, so that one handler can be responsible for multiple operations, while also being mutable across processes, meaning that one handler can be responsible for e.

But since I don't have a lot of knowledge about Oreans Virtualizer I'm wondering how strongly the different VMs are from each other. Like is there strong polymorphism which makes it really difficult to automate the process of devirtualization?

Also those hybrid VMs seem to have a more serious impact on performance I believe? And my last question would be: I saw that there are not only those animal names for the VMs but also colors? Yes, that is correct. Let's take FISH for example: The fact that it combines handlers makes room for huge polymorphism, as it can make different handler-combinations for the different files. Also, it has tons of "protection templates", which is basically annoying little "if" checks that it uses for internal cryptographic registers, such as:.

This also means that you have to deduce the execution-path branching , which makes the process much harder, and this is just one of many tricks you'll come across in this ocean of cancer. FISH is the most distinctive, as it has those operation-combination handlers, which makes for really big handlers. It's a type of protection template, I guess one could say. Yes, the hybrid VMs takes a really hard toll on performance. Imagine every instruction in the application must be interpreted by the "guest" VM plus there's the extra anti-dump instructions parsed.

Next imagine that for every instruction that is going to be executed to actually parse the code-flow for this, another VM the "host" VM is used to parse that again, tons of anti-dump shit. It's very confusing and deeply nested. Performance basically dies. Simply having done one of them e. FISH won't suffice. BLACK is the heaviest in complexity, but also the slowest in performance. In addition to what Sprux already perfectly described colors means the VM handlers will contain garbage.

Also they add fake conditional jumps and as far as I remember also mutation of the handler instructions. Rearranging a block from unconditional branches is no problem, as long as you know the destination e. But even garbage code shouldn't be a problem with compiler optimization. Conditional jumps shouldn't be a huge problem if you have an anchor point somewhere to hold on to calculate if the jump is ever going to be taken or not. And if those conditional jumps are only decoration and won't actually ever be taken you can simply remove them.

This is just what I suppose could work to clean that part up. Since branch-prediction is very error-prone, you can imagine the problems you could have tracing through Also, the branches aren't deduced by neither a register or immediate values.

They use internal state registers which has internal cryptographic behaviour across different handlers to carry encoded data to be decoded by the exact pattern in the given handler.

Here's an example:. However, when you're emulating the VM behaviour to devirtualize, the registers won't be set, so you have to keep track of all the context operations and emulate performance of them on a local structure of your own, to keep track of the cryptographic datas. Vmprotect is way better in few words. I don't really get your argument here. Well you could obviously add custom made protection, but if you pay for a good protector you shouldn't have to because it's the job of the protector to do so.

I took a look on their VM the sample that HellSpider uploaded. It is very simple VM with very simple "obfuscation" or you can say almost no existing obfuscation. I worked on that a little bit more than one weekend and I think that I need one more weekend to finish devirtualizing his sample, but not so interested in it right now.

All the reasons were already listed in this thread. For every item loaded in Themida, the encryption keys andalgorithms differ, while debuggers are also rendered ineffective.

To fool the cracking tools and other similar devices, theapplication will add some junk code among the real instructions inyour code. This makes it virtually impossible for disassemblers todiscern and interpret correctly the real bits.

Setting the protection options for a loaded file is really simplebecause all one has to do is check the corresponding boxes andchoose the desired options from the few drop-down menus. Aninteresting feature is the ability to block file and registrymonitors, so when the protected application is installed, itscomponents cannot be tracked by specialized tools.

Themida supportsvirtualization, so developers can choose the functions, entry pointand processor specs. To sum it all up,Themida manages to supply a decent array of functions that offerreally good protection for applications and libraries.