Simple VMProtect Loader (C++)
 

Here is a simple VMProtect loader to avoid "The file has been modified or cracked" error you get if you modify vmprotect binaries.

I know that people has been using sleep to avoid both checks but this is really unstable as it will be "computer-speed" dependent.
This solution is much more sufficent.

As I'm quite new here i thought it might be the time to contribute a little :)

Reliable inline, if the correct code is not under VM :)

Hi,

Nice stuff, but could you also explain where you got the constants 0x447E2A and 0x00A89010 ?

Greetings

0x00447E2A is the place where i patched(the crack itself), change it to where you wish to patch.
0x00A89010 is taken from the dump window, anywhere near your previous patch(explained above).
The loader will now know exactly when to patch, not a second before and not a second later(to avoid being caught by the VMP self checks)

In other words when 0x00A89010 is being read by the loader it will read the first bytes in the buffer 0xE4 and then second buffer 0xA6.
If this equals, it will know that "now is the time to insert patch".

Might also explain this:
buffer[0] = 0x90;
buffer[1] = 0x90;
buffer[2] = 0x90;
buffer[3] = 0x90;
buffer[4] = 0x90;

0x90 = nop as we all know,
It will now nop 5 times at 0x00447E2A, -> 90 90 90 90 90

compile this source please

sent you compiled version.

Works fine for Safengine Shielden as well.

you have made the permissions of the section where the patch if there is only writetable
I have this error
or code can not fully unpacked before patched?


---------------------------
Adrenalin.exe
---------------------------
File corrupted!. This program has been manipulated and maybe
it's infected by a Virus or cracked. This file won't work anymore.
---------------------------
ОК
---------------------------

You misunderstood how this loader works. read my reply further up.
You need to tell the loader when the file is unpacked and ready to patch, i explained this very detailed in post number 3 in this thread.

This is unreliable method . Readprocessmemory passes through kernel calls and has no exact cycle count to estimate each loop time . I am not criticizing what you did, its a decent method of course . rather i will advice you to use proxy dll methods to detect it, its much faster and less chance to miss the spot as the dll can read the memory space directly.(i personally use proxy dll to trick themida bypassing the vmware checks .)

@Conquest: Maybe share your DLL source code with us then ;)

Well as long as it works every time and on any OS I wouldnt call it unrelieable, but ofcourse it isnt a "search and replace loader" so if addresses change it wont work ofcourse.

I don't like the snippet. You didn't give a real explanation.

0x00A89010 -> This memory is dynamically allocated. This can change with every process start. Using this as hardcoded address doesn't seem smart.

Why do you read and write 12 bytes? You need only 2 (5) bytes.

It even looks like you don't need a 2nd ReadProcessMemory. If it is unpacked, it is unpacked. Why check it 2 times?

0x00A89010 <- in the program i used this last time was a particular case where this did not change.
I do agree that memory addresses change which wouldnt work properly.

However you dont need to use memory addresses.


You can also do it like this, this is entirely up to you.
If you don't like the way i did it, then make it better and post it here so that people can benefit from your inputs.

I agree on that you should dynamically set the bytes.
I do two ReadProcessMemory to make sure I'm at the correct place.

It's just something slapped together fast, and it works which is the most important thing for me.

I'm not a good coder so, I do thank you for your constructive feedback and i'm sorry if it doesnt appeal to your coding ideology
Please do your thing and post a better one, im sure both me and the community would be pleased.

Have a good day :)

my bad for using wrong words. i didnt mean to offend you . what i meant was that its not always 100% working because in some cases the execution flow may pass the patch point already before the patching fries up (not going to explain why . its obvious that thread timings and thread priority is the biggest issue here. not to mention without a sleep delay the process will consume 100% of a single cpu thread ).
Its same with even if you do proxy dll methods as well .

@mr. exodia . i will try to find it out today. i used it for that "mushroom game" long ago when i couldnt make a working unpack out of themida

Thanks for your input, im not a good coder, so maybe i will do it better next time :)

Yes, it shouldn't work for other Packed file.

Your Loader need add code loop(for/while) to detect WMProtect have been decrypted your app code(Real code you need patch), verify it then byte is exist, you will be suspend process and patch code before resume process.
That's all

BR,
quygia128

It works as long as you insert the correct offsets. It works on all VMProtect with self-checks as well as Safengine's selfcheck, tested on multiple protected files and i have cracks released with this loader for weeks without complains.

It still depends on the hardware (CPU power) of the machine. I have done a VMP loader myself in the past and I had to use Sleep() with a certain amount of time. The good thing is that you can automatically bruteforce the correct Sleep time more or less for a specific machine.

Real release groups don't allow "loader" cracks for obvious reasons.

For VMProtect and Themida/WinLicense,
Here is my method for loader.

1. Hook the API near OEP or near your patch point.
2. Check the return address from stack.

Then, you know when your target is unpacked.

Are you talking about my loader?
I'm not sure if i understood you correctly, because the source i posted here does not depend on hardware/CPU becuase it does not use sleep.
Sleep is a method i would never use at all, its shit, cuz yes as you said CPU.

I accept your critizism but i released my source to be nice, so that people that may not be "that" expericed with this, might solve it with my working method as well as giving people an idea to work on, and on how it could done.

To be honest i couldnt give two shits about what real release groups allow or not.
In my eyes, a working method is a working method, as long as the program opens, I'm happy and the users that use it will remain happy.

Good day.

0x22:

Easy tiger. I know your good intention of bringing the loader source here (although imho it doesn't help much). But honestly I think you should improve your code, and make it more universal, make it available on more machines.

It works on your computer, well ok. It fits your needs, ok.

The people just state here that they think you need to do more than that. Slapping a little bit on your ego isn't comfortable for you, but do accept it as a challenge. Don't be a kid or you will forever stay at your "level".

You can listen to my advice or not, it depends on you. However, satisifying yourself with little achievement won't take you far.

My two cents.

I am not a good coder, too.
So, if I share my source codes, they will surely be ugly.

But I think we share source codes, methods. And with help from more friends here, we work out new and better solutions together.

I love to learn, i have no issues with learning, i learn every day and i enjoy it.
One of the cracks i used this loader on has 8291 unique logins in my php panel as we speak, and not a single complaint.
So i dont see the reason to rip on something that work.

Yeah, It is very useful especially for patching child process created by father process; such as Armadillo, SDProtect, etc.

I always use hook method when loaders like dUP2 fails to patch on time.

So if the VMProtect does not check for API hooking, this method is the best.

Problem is ,like themida, vmp uses emulated api as well . so normally its hard to predict which api is "universally free" from api emulation and thus hooking doesnt work in all cases

This has worked bulletproof on VMProtect, Themida and Safengine for several dozen of loaders for me, never had any problems with using this method tbh.

As title says "SIMPLE" so thst is what this is.... simple loader. But as I can see after so many suggestions and criticism maybe some of you could show user 0x22 how to "ADVANCE" it...
;)

i dont see any link between your message and my statement . it doesnt apply to your method at all .

I'm sorry i must've misunderstood, my apologies :o

how to load a sys vmprotected sys PC tied? Any ideas to make HW customised virtual machine ? Gratias!

Has anyone tested this can load common?

Nice topic 0x22, I will have a look at this and comment later....need to read the past 3 pages of discussion!

Glad to see you are welcomed here....I knew you were the right person to get invited!