[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] OEM Windows in Qemu

From: Michael Tokarev
Subject: Re: [Qemu-devel] OEM Windows in Qemu
Date: Wed, 21 Dec 2011 11:53:51 +0400
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110805 Icedove/5.0

On 20.12.2011 22:23, address@hidden wrote:
> Sorry, I don't normally use this email and didn't realize it was set to
> html.
> I've been trying for several days now to get my OEM copy of Windows XP
> to pre-activate properly in Qemu-kvm.  I saw the instructions for
> patching the seabios here:
> http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html

Note that for winXP, the only thing needed from the bios is to _mention_ -
anywhere in its memory - name of your manufacturer.  That is, you can
add any table with just a string - say - "ASUS_Notebook" in it, winXP
does an equivalent of memmem() function on the bios content to find if
it is supposed to be right OEM.

> That seems to have worked as expected.  When I boot, it shows the newly
> compiled BIOS, but Windows fails to detect the SLIC codes which I copied
> from my working Dell system as per the instructions.  My research so far
> has turned up the existence of multiple versions of SLP/SLIC which I
> think may account for this.

WinXP requires "SLIC version 1.0", which is reduced to just having a string
with the name of your OEM in the bios (one possible place is the SLIC table).
More recent version of SLIC (2.1 I think) is needed to activate windows7.

> Can anyone confirm what version of SLP the patch posted to this list is
> effective at emulating?  Is there an easy way to modify the patch to
> support a different version of SLP?

While I'm the author of the howto you mentioned, so my "opinion" here is
biased, but still I can say that several other people used this way to
run oem versions of windows7 and windowsVista in their VMs, and sent me
their thanks.  I also found this way mentioned in vmware-related forums.

> I've installed several low level BIOS scanning tools in the VM to
> troubleshoot and gather information.  None of the tools I've used
> (OEMSCAN, Oembios) show a valid SLP 1.0 OEM data in the BIOS/RAM.  But
> another tool (ReadWrite) shows a valid Dell SLP 2.0 signature.  This
> leads me to believe that either I didn't copy the right SLIC information
> from my Dell PC or the patch is set up to create SLP 2.0 and not 1.0.

I've no idea what does these tools do.  For testing I just boot linux
and check if it can see the tables with the content I've used (somewhere
in /sys/firmware/acpi/tables).  For further testing I boot my OEM-preinstalled
copy of windows to verify it still thinks it is OEM-activated.  I also
tried to actually activate win7 in a VM, using slic+certificate from
a "random" OEM (these are available on the 'net despite being M$ high-secret),
and it worked just fine too.

This is about win7, not winXP, for which I used real bios modification
way in the past to just put a single string into BIOS of my machine for
it to recognize the "OEM-ness".

Besides all this, you obviously should have the right OEM version of
windows, wich "knows" this very OEM you're pretending to be (if you're
installing new VM and not using a pre-installed copy).  For win7 this
means valid certificate belonging to this OEM is installed in the system.

I wont provide any further details about it, because someone thinks it
is hackish and "blackish" territory.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]