[rootw0rm]

Starting work on a patcher for VBox source which will Anonymize All The Things, including SMBIOS and the DSDT + SSDT ACPI tables, and also be open source.

For anti-VM detection is it better to attempt to look like a real system according to SMBIOS/ACPI, or to strip it down to nothing so that no info can be gathered?

I'm leaning towards the stripped down approach...

Current VBox DSDT is super obvious and can be easily targeted, even without the "VBOX " string.
There's also an inactive Pentium 3 CPU entry in SMBIOS...no good, we can still read it

DSDT red flags:

It's ~8.2KiB binary, my laptop one is ~76.3KiB
strings: VBOX, Windows 2006 SP2, VAIN, all the DBG strings, 0xDEC0AD0B, many many others

this:

Code: Select all

Method (_PRT, 0, NotSerialized)
            {
                if (LEqual (LAnd (PICM, UIOA), Zero)) {
                    DBG ("RETURNING PIC\n")
                    Store (0x00, \_SB.PCI0.SBRG.APDE)
                    Store (0x00, \_SB.PCI0.SBRG.APAD)
                    Return (PR00)
                }
                else {
                    DBG ("RETURNING APIC\n")
                    Store (0xbe, \_SB.PCI0.SBRG.APDE)
                    Store (0xef, \_SB.PCI0.SBRG.APAD)
                    Return (PR01)
                }
            }

and this:

Code: Select all

Field (PCIC, ByteAcc, NoLock, Preserve)
                {
                    Offset (0xad),
                    APAD,   8,
                    Offset (0xde),
                    APDE,   8,
                }

plus code structure, field names, method names, etc. I think it needs a serious overhaul.

[newcomer]

For sure it will better to make Vbox looks like real machine. And also change some hardware that can't be change with VboxHardened as sound card, video card, processorid.

[rootw0rm]

For sure it will better to make Vbox looks like real machine. And also change some hardware that can't be change with VboxHardened as sound card, video card, processorid.

After looking at the problem a lot more I agree. I've added support to VBox for multiple SSDT tables and moved the VBox DSDT code to SSDT. Later I might consider obfuscating it, I don't think anybody's ever really obfuscated ACPI code before. My main concern is Windows, and getting SSDT tables past the first one isn't explicitly supported by Windows API, so it might be okay for now to hide the code there. It's possible of course to get to those tables, but it will at least take a little bit more effort.

I'm now looking at DSDT code for lots of different hardware and considering a few things:

1.) which ones I will be able to add with the least amount of changes so they're as close to originals as possible
2.) i'd like to have at least a couple DSDT templates based on different, popular brands and models
3.) full OS compatibility (including XP) is desirable
4.) i'm still not sure yet how feasible all this is because this is the first time i've messed with ACPI stuff and i'm testing ideas as i go

truly undetectable VM environment is looking more and more difficult, hopefully something decent can be created.

[newcomer]

For sure it is great if can choose different profiles, but obvious thing to detect almost any virtual environment is checking motherboard chipset. For instance, in virtualbox,vmware it will be Intel Natoma 82440FX.Outage motherboard.And even more if you are running AMD it will be same. The good this is to find somehow to emulate different newer models.Also same problem persists with GPU.
Maybe you have some ideas of this too.

P.S.
Find the way how to emulate any CPU at virtualbox, when finish testing results will be posted.

[rootw0rm]

All the hardware are my priorities. Bringing up AMD is a good point, my focus so far has been on Intel hardware. Matching host CPU capabilities with a compatible guest CPU that makes sense for the guest chipset is probably something I'll tackle last. My focus for now is extending VirtualBox to be able to emulate realistic mainboards. Without a proper dev environment however it's becoming tedious to do serious work. PowerGREP + notepad++ is only really suited for minor updates =)

I might temporarily switch my focus to migrating the windows build system to Visual Studio projects so that I can have a nice IDE to be productive with. The Kbuild system can produce very nice logs which should be decent enough for me to generate some project files for an x64 release only build. Adding the custom build steps (nasm, iasl, etc.) after that shouldn't be too tedious.

Also last night I hit the maximum ACPI size limit of 64KiB that's hardcoded into VBox, so I'll have to patch that.