A forum for reverse engineering, OS internals and malware analysis 

Discussion on reverse-engineering and debugging.
 #25545  by Codehook
 Wed Apr 01, 2015 10:33 am

I was analyzing an old Qakbot sample recently, and noticed it contained the "long opcode" anti-VM technique. It is detailed in this report:


This ended up being executed without an exception in VirtualBox, resulting in VM detection. This doesn't happen if VirtualBox is running an OS with hardware virtualization turned on, as it will raise the correct exception.

Are there any settings I can use to change VBox's behavior for this when not using hardware virtualization? I have tried the latest version of VirtualBox, but it is still susceptible to this technique.

 #25547  by EP_X0FF
 Wed Apr 01, 2015 1:52 pm
You don't have VT in CPU? How old is it?
 #25550  by Codehook
 Thu Apr 02, 2015 11:08 am
EP_X0FF wrote:You don't have VT in CPU? How old it is?
Ha :D well yes I believe it does have VT but I don't have permissions to modify BIOS settings for various reasons, unfortunately. If this is the only feasible solution though then I will see if I can get it enabled.

I suppose I'm just wondering if it's a known VirtualBox issue, and/or whether there's a setting that can be changed to influence it. VMWare doesn't seem to be affected by the same technique.
 #25562  by EP_X0FF
 Thu Apr 02, 2015 4:53 pm
VirtualBox is known not to fix anything they do not consider as bugs affecting emulation.

http://www.kernelmode.info/forum/viewto ... 930#p18930

This detection method was abused few years in VmProtect before this was fixed as side-effect of VirtualBox further development. I guess since your described problem not appears with VT acceleration, they won't give this any attention. Most of computers now have VT-x and it is enabled by default in most cases, so malware is wasting their time implementing such detection.

Guess your topic is linked to this issue -> http://www.kernelmode.info/forum/viewto ... 6&start=20