KernelMode.info

Patched dlls for Win64 VirtualBox-4.3.12-93733. Backup original Vbox files and replace with attached. Due to patch digital signature is broken, however it is not important and do not affect Vbox work.

Since 4.3.14 vbox developers being are under drugs added number of "security" "fixes" to protect their crappy and bugged code full of exploits. Yes, instead of code refactoring they added additional layer of bullshit.

From now, VirtualBox application and components "protected":
1) from binary modification - by number of integrity checks including self-implemented validation, digital signatures checking;
2) introduced whitelist of applications and dlls allowed to work;
3) system dlls from whitelist are all validated and checked their certificate to be OK;
4) hardened dll spoofing for critical integrity checking routines;
5) attached debugger banning;
6) protection from dll-injection by dll whitelist and allocated regions guard;
7) protection from remote-thread - checking the only 1 calling thread is running.

The current Virtual Box version is very bugged and not recommended to use, until they remove or improve all above shit they added. Because of "security" innovations (which are not security at all) given virtual machine is no longer can be used for malware research under WinNT. We can try to patch it like we did before to avoid malware detection, but currently this piece of Oracle shit is simple unworkable.

crappy and bugged code full of exploits

You talking about guest-side components, or about hypervisor kernel as well?

Cr4sh wrote:

crappy and bugged code full of exploits

You talking about guest-side components, or about hypervisor kernel as well?

I'm talking in retrospective of last known exploits they are aware, I've no doubts they have more of the same kind, thats why all resources now thrown not to fix bugs but to make exploitation harder.

u mean there is no anti-detect patches for vbox from now?

No. When they will release anything that actually *work* - not doing these from clean install,



we will look if vbox is still can be patched anyhow. If not, well then we have these workarounds:

1) do not use it at all
2) write hiding driver that will do patching on the fly inside vm
3) rebuild vbox and turn off this idiocy

Time will show, now there is nothing to "patch", because nothing works.

EP_X0FF wrote:No. When they will release anything that actually *work* - not doing these from clean install,



we will look if vbox is still can be patched anyhow. If not, well then we have these workarounds:

1) do not use it at all
2) write hiding driver that will do patching on the fly inside vm
3) rebuild vbox and turn off this idiocy

Time will show, now there is nothing to "patch", because nothing works.

4) Continue using version 4.3.12?

Maybe. However sometimes VBox updates really can help - like in case of this bug http://www.kernelmode.info/forum/viewto ... 930#p18930 long time used to detect VBox and fixed only in 4.3.4. What if something like this exists in 4.3.12?

One thing I can certainly say right now - old style vbox dlls patching is dead.

What exactly patching were doing - they removed VirtualBox, Innotek, Oracle, Virtual Machine signatures inside.

Some things can be replaced with DMI configuration - yes, this thread have examples. Do not install VM additions - yes, this is advice by default in case of malware RE on VBox.

But several detection methods does not rely on the above data and cannot be reconfigured anyhow by VirtualBox user. One of it - firmware data that is accessible from Windows or from kernel mode and can be used to reveal VBox easily. Starting with 4.3.14 in the pathetic attempt stop VBox exploitations Oracle made his virtual machine friendly to detection by malware. Success.

I vore for driver.

Hello,

TETYYSs wrote:I vore for driver.

Firmware data can be in region protected by PatchGuard (as we do not even consider x86-32 versions). Besides, hiding driver must rely on a lot of undocumented staff like OS dependent offsets, structures etc, not to mention driver will be unsigned so you will be forced to turn off DSE.

Latest build of Virtual Box fixed incompatibilities by switching restrictions model from "deny start with 3rd party code inside" to "deny 3rd party code inside".

Best Regards,
-rin