Exetools

Exetools (https://forum.exetools.com/index.php)
-   General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)
-   -   Anti-debugging techniques for a hypervisor debugger (https://forum.exetools.com/showthread.php?t=18881)

HarrySpoofer 08-03-2018 00:42

Anti-debugging techniques for a hypervisor debugger
 
What anti-debugging techniques would a hypervisor debugger be vulnerable to ?

IMO a debugger that is a hypervisor can intercept the rdtsc instruction and most timing based anti-debugging techniques.

Am I missing anything?

DavidXanatos 08-03-2018 00:57

You mean like to debug an entire operating system?
Or to debug an app inside an operating system (kinda like edge now runs in win 10)?

How about trying some convoluted means of time measurement, for example,
lock a Mutex and than try to lock it again with a call that times out after 1sec or so.
And than always compare the result to what you get from the rdtsc.

i.e. try to compare different timing sources, unless you would debug the entire os and modify all timing sources to keep them in sync that would be a way to detect something is wrong.

Of cause comparing against a server time would also be an option but well that needs a network connection.

HarrySpoofer 08-03-2018 01:03

The hypervisor would have to envelop the entire OS to be tight and effective, wouldn't it? Like the famous Blue Pill...
Then, using OS structures, a single process could be singled out for debugging, so the experience is not too slow.

Indeed, with a network connection a timing based anti-debugging technique could be made.

What about, non-timing based techniques?
Could IO MMU and hardware be exploited?

DavidXanatos 08-03-2018 01:22

> Could IO MMU and hardware be exploited?

Hmm...
I think that would strongly depend on how your anti-debugging technique ties into the operating system. Without ring 0 access you are limited to no hardware access and only a limited set of opcodes.

So assuming that your protected application is just that, a user space application, other that a Hardware dongle or Server I don't think there is any way.

If your application however comes with a driver than possibly there is a way, although I wouldn't know of hand how this way looks.

But, if you are virtualizing an entire OS with your victim application, why use hardware virtualization and risk the application having a shot at detecting something?

There were virtual machines long before there was Intel VT and AMD Pacifica, I remember Connectix virtual PC later M$ virtual PC, although this was before 64bit became mainstream.
Anyhow I don't see a reason why one couldn't make a new virtual machine software which runs a 64bit OS but does not require hardware support that is runs on the host as a boring user mode process. That is of cause except that fact that its performance would be worse may be much worse of cause. But for debugging that wouldn't matter much I guess.


So ultimately the only way to go would be to try to detect being run in a VM at all and than denying to run.

However if said VM software would be intended to be a Debuging host I think there would be no reliable way to detect being run in it which couldn't be bypassed by some minor update to the VM software.

user1 08-03-2018 05:31

google it, you find open source projects. some code is in ASM x86 so will need rewrite for x64.


All times are GMT +8. The time now is 07:35.

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