vmprotect v3 debugger detected
 

Greetings,

i have been away for a couple of years and i can see that a lot of things have been changed, I have been playing around with vmprotect v3 but unfortunately no matter what plugins/options i use my debugger gets detected, anyone know how to successfully hide olly from vmprotect please advise.


Regards

show your target if possible :)

Some vmp antidebug is realized by syscall instructions directly in the VM code instead of calling Nt functions
You can also use TitanHide

I would say try titanhide, as well. But it would also be good to list the options/plugins you have already tried so that people don't have to guess when they suggest alternatives for you.

:)

Use a Windows XP VM instead of a newer version of Windows.

i tried windows xp windows 7/8 titanhide scllayhide and no matter what option i use it gets detected,

target can be found here: https://mrt-dongle.org/pages/download

anyone can tell me how to hide olly successfully please let me know plugins used and options.


Regards

Okay, so you're trying the right options...

Did you run the titanhidetest app to verify that everything is installed correctly and not being detected? I would also suggest trying x64DBG. I too prefer Olly, but maybe would make the difference.

yes i have verified that titanhide is running correctly.

change windows build number to a random number and you should be good to go. VMP detects debugger based upon hardcoded syscall numbers according to windows build number. If build number is not supported then VMP goes back to old detection methods.

Edit:

Because I see good people is interested in how to bypass this, here its the procedure more or less:

it goes like this: load your target in ollydbg, press G fs:[30] in command bar. At that memory location + 2 bytes you should read 0x01 if debugger is attached or 0x00 if debugger isn't attached (or you have installed any kind of anti-debugging plugin). This is BeingDebugged flag. It tells you are in the right track. At that base address, pointed by fs:[30]) add 0xA4 and you should read OSMajorVersion, and at 0xAC you should read OSBuildNumber. Change these last two parameters to any random number and you should be good to go. _PEB is a per-process structure so it won't affect anything else. I would tell you also to try ollydbg stolystruct plugin to quickly find all of this but its outdated and you could end up modifying a different member of the _PEB struct, although it is worth trying too if you are using win7. Remember _PEB has evolved slightly throughout the years. In any case, such changes have been fully described in this handy reference which is always good to have: http://blog.rewolf.pl/blog/wp-conten..._Evolution.pdf.

:eek:

Nice little tidbit!

More here:

https://lifeinhex.com/tag/vmprotect/

[QUOTE=bolo2002;112161]+Aesculapius,old school and still alive,respect. ;)

Have been revisiting and compiling info on VMP 3.x as trying to automate execution tracing while devirtualizing only key important parts of code on the code on the fly sort of tool. I had wondered why different machines had different behavior.

This explains clearly why I have not seen this behavior while staying in the Windows 10 insider fast ring. Suppose its the one benefit of it :D.

Respect to the old school reversers who have posted some real knowledge and true info in this thread.

Call IsDebuggerPresent to determine that the return value eax==1 is debugged, and eax==0 is not debugged.

CheckRemoteDebuggerPresent, determine whether the buffer return value is 0 or 1, 1 is debugged, 0 is not debugged.

NtQueryInformationProcess, ProcessInfoClass=0x1E to get the debug handle, to determine whether it is debugged, the debug handle returns 0 and the return value of eax is 0xC0000353

NtSetInformationThread, ThreadInfoClass=0x11, this is not to detect debugging, but to set the debugging information to the debugger, you can directly change 0x11 to 0x3 or other values.

ZwQuerySystemInformation, SystemInfoClass=0x23 (MACRO: SystemKernelDebuggerInformation), the return value is a 2-byte bool value, set to 0.

ZwQuerySystemInformation, SystemInfoClass=0xB (MACRO: SystemModuleInformation), will go through the kernel module, and then judge, the first time is to obtain the buffer length that needs to be stored, the second time is to actually get the information, as long as the buffer is set to 0, Debugging is not detected. As for the location of the buffer, the LocalAlloc application space is used for storage after the first call.

CloseHandle anti-debugging, if it is debugged, then the KiRaiseUserExceptionDispatcher function will be called, go the exception handling process; if it is not debugged, it will not go to the exception process.

Detecting hardware breakpoints is handled by SEH exceptions
First, in the SEH chain, the next software breakpoint for the SEH header of the current module.

Then modify the Dr0, Dr1, Dr2, Dr3, Dr6, Dr7 debug registers to 0.

If it is the GetpRrocessAffinityMask function call when it comes to CALL eax, the anti-debug has passed.

information can be tracked here at VmCall ‘’CALL eax‘’

In addition, after ZwQuerySystemInformation[SystemInformationClass::SystemModuleInformation] gets the list of system modules, the module name and the decrypted strings "sice.sys", "siwvid.sys", "ntice.sys", "iceext.sys", and "syser" .sys" for comparison to complete the test.
The above is the debugger detection bypass of VMP3.0.0-3.2.0

Now, The best solution! ! !

I have these x64 targets https://passcovery.com/download/passcoverysuite64.exe and
http://anonym.to/?http://passwordrecoverytools.com/store/accentrpr64_setup.exe
and tried to debug its with x64dbg plus hidding plugin set for vmprotect
but got message of debuger detected in memory

some special help ?