Exetools

Exetools (https://forum.exetools.com/index.php)
-   Source Code (https://forum.exetools.com/forumdisplay.php?f=46)
-   -   Simple VMProtect Loader (C++) (https://forum.exetools.com/showthread.php?t=16276)

0x22 10-18-2014 23:08

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 :)


Code:

// ConsoleApplication.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{

        #define ADDRESS (LPVOID)0x447E2A

        unsigned char buffer[1024] = { 0 };
        SIZE_T nSize;
        int fooo = 0;

        PROCESS_INFORMATION procInfo = { 0 };

        STARTUPINFO startupInfo = { 0 };
        startupInfo.cb = sizeof(startupInfo);

        fooo = CreateProcess(L"FILENAME.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, &startupInfo, &procInfo);

        printf("%d\n", fooo);

        while (1)
        {
                //00A89010  E4 A6 42 00
                ReadProcessMemory(procInfo.hProcess, (LPVOID)0x00A89010, buffer, 12, &nSize);
                if ((buffer[0] == 0xE4) && (buffer[1] == 0xA6))
                {
                        printf("Unpacked.\n");
                        ReadProcessMemory(procInfo.hProcess, ADDRESS, buffer, 12, &nSize);
                        if ((buffer[0] == 0xE8) && (buffer[1] == 0x79))
                        {
                                buffer[0] = 0x90;
                                buffer[1] = 0x90;
                                buffer[2] = 0x90;
                                buffer[3] = 0x90;
                                buffer[4] = 0x90;
                                //Sleep(570);
                                printf("Address FOUND!\n");
                                WriteProcessMemory(procInfo.hProcess, ADDRESS, buffer, 12, &nSize);
                                exit(1);
                        }
                }
        }


        return 0;
}


Kla$ 10-19-2014 02:08

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

mr.exodia 10-19-2014 03:41

Hi,

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

Greetings

0x22 10-19-2014 04:11

Quote:

Originally Posted by mr.exodia (Post 95256)
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

Kla$ 10-19-2014 04:14

compile this source please

0x22 10-19-2014 04:58

sent you compiled version.

0x22 10-19-2014 05:19

Works fine for Safengine Shielden as well.

Kla$ 10-19-2014 06:01

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.
---------------------------
ОК
---------------------------

0x22 10-19-2014 06:21

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.

Conquest 10-19-2014 12:50

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 .)

mr.exodia 10-19-2014 23:24

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

0x22 10-19-2014 23:43

Quote:

Originally Posted by Conquest (Post 95265)
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 .)

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.

Carbon 10-19-2014 23:46

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?

0x22 10-19-2014 23:56

Quote:

Originally Posted by Carbon (Post 95273)
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.


Code:

ReadProcessMemory(procInfo.hProcess, (LPVOID)0x00409605, buffer, 12, &nSize);
                if ((buffer[0] == 0xF6) && (buffer[1] == 0xC1))
                {
                        ReadProcessMemory(procInfo.hProcess, 0x409615, buffer2, 12, &nSize);
                        if ((buffer2[0] == 0x74) && (buffer2[1] == 0x0C))
                        {
                                buffer2[0] = 0x90;
                                buffer2[1] = 0x90;
                                //buffer2[2] = 0x01;
                                //buffer2[3] = 0xEB;
                                //buffer2[4] = 0x0B;
                                //buffer2[5] = 0x90;
                                //buffer2[6] = 0x90;
                                //buffer2[7] = 0x50;
                                //Sleep(570);
                                printf("Address FOUND and patched!\n");
                                WriteProcessMemory(procInfo.hProcess, ADDRESS2, buffer2, 12, &nSize);

                        }

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 :)

Conquest 10-20-2014 00:18

Quote:

Originally Posted by 0x22 (Post 95272)
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.

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


All times are GMT +8. The time now is 19:13.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX