Ticket #2784 (closed enhancement: obsolete) — at Version 9

Opened 11 years ago

Last modified 4 years ago

Windows Guests fail wpa on current SLP PCs

Reported by: lilian Owned by:
Component: other Version: VirtualBox 2.1.0
Keywords: Cc:
Guest type: Windows Host type: Linux

Description (last modified by frank) (diff)

Large manufactureres (e.g. Dell, HP) use Security Locked Preinstallation (SLP) OEM versions of Windows, employing codes embedded in the host BIOS to pre-activate the installation and thereby obviate the need for explicit product activation by the end user.

Section 9.13 of handbook provides information on setting certain strings in the VirtualBox bios; in some instances this may allow such activation to continue to work, even in the virtual environment. Such an approach has also been described in the user forums. However, setting the 13 available DMI strings to match the original BIOS DMI settings is *not* sufficient to allow Windows to achieve SLP activation, at least on newer machines (tested on Dell Precision T5400 workstation). It appears that more than this simple identification information is being used (possibly SLP 2.0?). Since the OEM version of Windows supplied with these machines is normally permitted to achieve activation *only* via SLP, this seems to rule out using VirtualBox to host Windows Guests on these machines, since only the appropriate OEM version of Windows will be available.

VMWare apparently has a setting:

SMBIOS.reflectHost = TRUE

which causes the BIOS of the virtual machine to reflect (some of) the strings in the host BIOS. Presumably current versions of VMWare reflect more than the basic ID strings, in order to allow SLP to continue to work when using the virtual machine.

Since the current situation seems to rule out using Windows Guests on newer corporate machines, it would appear to be a problem of some significance. Presumably it would be possible for the developers to instrument the virtual BIOS running on such a machine, in such a way that the 'reflection' needed could be determined and subsequently implemented (e.g. it might be necessary to read directly from the BIOS address space, at the original BIOS address, in addition to simply querying DMI strings).

Test environment: host = RHEL5, guest = Windows XP (64 bit), hardware = Dell Precision T5400; actual setup was vmdk of original installed raw disk (partition), although the problem should be equally applicable to a virtual disk installation. Tested on 2.0.6 and 2.1.0.

Change History

comment:1 Changed 11 years ago by darose

I believe I'm running into this problem as well on a Dell Precision M4400, using vbox 2.1.0 and WinXP Pro via a vmdk with a raw disk partition.

comment:2 Changed 11 years ago by frank

See paragraph 9.14 in the user manual. However, the information which can be changed there might be insufficient. People reported that Windows still complains. Any additional information is welcome.

comment:3 Changed 11 years ago by lilian

Comment (by frank):

See paragraph 9.14 in the user manual.

That was the manual section I was referring to in the description, although the section number seems to have changed from 9.13 to 9.14

However, the information which can be changed there might be insufficient. People reported that Windows still complains.

That is indeed what I (and others) have found, and what prompted me to make my submission.

Any additional information is welcome.

It appears to be the case that specific addresses in the BIOS address space are being queried, not merely the contents of some of the BIOS product strings (presumably in order to make it harder to counterfeit the validation). For this reason, I suggested that the VirtualBox development engineers could instrument their BIOS access code to see which addresses are being queried and via what access methods, in order to enable them to implement a 'pass through' or equivalent mechanism, which would allow WPA to read the correct validation details from the real BIOS ROM.

comment:4 Changed 10 years ago by cherinolero

I'm running into the same problem with a Dell XPS 1330, I've properly configured all the 13 parameters for the DMI but still windows XP is not activated. I guess,as lilian said, that Windows is looking somewhere else in the BIOS. Thanks for your efforts

comment:5 Changed 10 years ago by jss


I have an Asus A8Js which came with preinstalled WXP (it now runs Linux) not needing activation.

I have an application from work that needs MSSQL. So, I wanted to run this on a virtual machine on the Linux host.

The first battle was then to make Windows dual booting, meaning virtual and physical, just in case I had to go back to Windows. This was not easy but after I got it to work with both VB and VMPlayer, I discovered that Windows was asking for activation.

After some research, I concluded that the original OS has the SLP mechanism which, in the case of ASUS, requires the string "ASUS_FLASH" on a memory address near the top of the BIOS. It's not enough to place it somewhere, it has to be close to the top, I can't remember now the exact lower limit but a quick google should find this.

First thing I tried was the VB strings inclusion method cited above but it didn't work.

I then concluded that I had to use VMPlayer, against my will, because it allows you to use your own bios with the clause

bios440.filename= "myvmBIOS.ROM"

At the time I wasn't aware of the easier way provide by the clause above, reflectHost, neither did I try it yet.

So, following advice of some articles found on the net, I extracted the VMPlayer Bios with a resource hacker, edited it with Phoenix bios editor to include this string on an apparently unused area (0x00 or 0xFF, not sure) very close to the top, just before the date of the bios. I couldn't just use an hex editor because the bios is compressed or somehow coded until placed on memory.

It worked, Windows ceased to ask for activation and I have been using this setup since a few months without any problem, Linux host with a small virtual machine running Windows for my business application.

Nevertheless, for the reasons that all of you know, I would like to switch to VB and that's why I decided to share my experience to ease the task of solving this problem for our community.

If someone would like more details, I'll be monitoring this board.

Regards, jss

comment:6 Changed 10 years ago by jss

Hello again,

Couldn't wait, went back and tested

SMBIOS.reflectHost = TRUE

Doesn't work in my case.

rgds, jss

comment:7 Changed 10 years ago by darose

Some more info on my attempts to get this to work on my machine:

If anybody's got any suggestions on how I might be able to get this working, I'm all ears! Cause I've tried just about anything I can think of and am about to throw in the towel.

F*ing Microsoft. Yes, by all means they must do everything in their power to prevent me from running the legitimately installed, purchased, & registered version of Windows that I have already installed on my hard drive from being run (off of same hard drive) from inside of a VM. Yes, please - make me pay twice for the same product!!!




comment:8 Changed 10 years ago by jss

@darose Good news, I've just made it, read

Enjoy, jss

comment:9 Changed 4 years ago by frank

  • Status changed from new to closed
  • Resolution set to obsolete
  • Description modified (diff)
Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use