Thanks for confirmation. Obviously another "backdoor" that MS build into their systems. That makes mod for Hyper-V required only for Win7 (SLIC 2.1) sebus
@kibkalo Dell is one of the pickie sets, try using HP or any other set that has the string in one of these ranges: Code: f000,0000,ffff e000,0000,ffff
Can't understand, - I have to set the registry key (text 32bytes long) - that is a bit different to what is written in OEMBIOS, as I read the whitepaper.. Which string may I enter to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\BiosLockString to activate the B6F0EEFD ? And more interesting for me, how can I calculate this host REGISTRY STRING myself?
Code: f000,e076,0010,Dell System f000,e840,0010,Dell Computer f000,49a9,0010,Dell System f000,e05e,0010,Dell System f000,e838,0018,Dell Inc As i said, Dell is not easy to activate it needs it's SLP string(s) in a very specific location I make one example What means f000,e076,0010,Dell System ? - f000,e076 -> Start Address (0x000Fe076) of the SLP Address - 0010 -> Address range in bytes (in hex) - Dell System -> SLP 1.0 String which must be placed in the address range As you can see DELL uses very specific SLP address ranges/locations which are not mapped within the physical ram address 0x000F8B88 this trick by Inge001 uses... try using another OEMBIOS set / SLP combination preferably use a set that covers the whole bios, and not specific locations, like: Code: f000,0000,ffff e000,0000,ffff
OK, I understand, that DELL is not an easy sample. Here I see what you did - the sample: IBM (OEMBIOS CRC=F35DA4D2) 'e000','0000','ffff','IBM CORPORATION' 'f000','0000','ffff','IBM CORPORATION' NEC (OEMBIOS CRC=5B988ABF) 'f000','0000','fff0','NEC_Product' 'e000','0000','ffff','NEC_Product' How came that you combined both titles, addes spaces, got "NEC_ProductIBM CORPORATION ", that activates both NEC and IBM? Let me try the same with different HP from table: 'f000','ffea','0006','COMPAQ' 'e000','0000','ffff','Compaq' 'f000','0000','ffff','Compaq' 'e000','0000','ffff','compaq' 'f000','0000','ffff','compaq' 'e000','0000','ffff','ProLiant' 'f000','0000','ffff','ProLiant' 'e000','0000','ffff','Proliant' 'f000','0000','ffff','Proliant' 'e000','0000','ffff','Hewlett-Packard' 'f000','0000','ffff','Hewlett-Packard' 'e000','0000','ffff','hewlett-packard' 'f000','0000','ffff','hewlett-packard' As I read whitepaper, OEM IDs are case insensitive, So I think that putting to registry just something like "COMPAQProLiantHewlett-Packard " does the trick. I edit the registry, restart VMMS, boot VM, run SLP_Check_Tool and... I see F:Compaq OEMBIOS.CAT CRC=A5E32571 F:Hewlett-Packard OEMBIOS.CAT CRC=00A1EECB F:Hewlett-Packard OEMBIOS.CAT CRC=3BA155E1 F:HP & Compaq OEMBIOS.CAT CRC=CD4E1902 Meaning that I can autoactivate the above versions of OEM SLP 1.0 OS in VM. Now I seem to understand the trick with SLP 1.0 in Hyper-V and am happy with it. Is there a known method of setting another (to Microsoft) SLIC 2.0 to VMs in same way? Or do we have an OEM .xrm-ms certificate for the "VRTUAL" SLIC 2.0 in Hyper-V?
It works on 2008 or 2008 R2 host It activates whatever guest that can read the SLP 1.0 string from this location (XP or K) And of course you need the correct oembios.* set & SLP key in the guest! sebus
Dell is ALREADY included in original un-modded Hyper-V, no need to mod anything, just use the correct oembios.* set for W2K3 But as Freestyler said, use something easy in BiosLockString for XP (HP is as always good) sebus
sebus, your two post above are about SLP 1.0 guests, right? XP, 2003, SBS2003, Home Server, etc. In this topic, it was said, that one can activate WS2008 (SLP 2.0) in Hyper-V VM. And in my VMs I see the existance of SLIC 2.0 with Everest.. So, to activate SLP 2.0 OS (Vista, WS08, SBS08, EBS08) I need a sort of .xrm-ms certificate, corresponding to "VRTUAL" SLIC 2.0 in Hyper-V
Ok. Didn’t get it still. AFAIR, string '9b80ca0d5dd061ec9da4e494f4c3 fd1196270c22' was always in both Hyper-V & VMware BIOSes. (I’m not 100% sure about VMware, but rather 95%) And we use Dell OEM stuff to activate XP/2003 on both types of hosts… Now we discuss another method: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization] "BiosLockString"="NEC_ProductIBM CORPORATION " ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ string must be 32 chars long. If needed, pad with spaces This "BiosLockString" is mapped to the physical ram address 0x000F8B88 If I get everything right: It’ll work on Hyper-V host (2008+) only. Can activate XP/2003 only and still need some oem.* files… I thought if registry "BiosLockString" matches 0x000F8B88, that’s all we need… oem.* files are signed and that’s why we cannot “edit” them. It looks like the method above “lock” memory location and therefore doesn’t need oem.* files I’m lost…
You ALWAYS need matching oembios.* set for XP/2K3 to activate. BiosLockString ONLY provides the needed SLP 1.0 for such set Yes, we can only read the set to see what is needed, but not edit it Only Vmware Workstation 7 has this string build in And for XP guest (if the host runs on Intel processor this Genuine OEMBIOS.CAT CRC=8B2EBECB will of course activate with no problems) sebus
Ok… Let’s see if I got it right this time: OEMBIOS set has some string/ranges combos: 'f000','ffea','0006','COMPAQ' 'e000','0000','ffff','Compaq' 'f000','0000','ffff','Compaq' 'e000','0000','ffff','compaq' 'f000','0000','ffff','compaq' Suppose our BIOS doesn’t have any of the above. General case end here – no string – no activation! If we have Hyper-V, than we can still activate OEM distribution as thoroughly described by kibkalo: get CRC32 checksum of OEMBIOS.CAT and set BiosLockString registry key to required value. I.e there is no need to have this value in BIOS at address 0x000F8B88, right? I was extracting VMware server and ESX BIOSes myself for editing. I do remember, I saw it there… Although, I might be mistaken easily – but I definitely didn’t do anything with VMware workstation… >(if the host runs on Intel processor this Genuine OEMBIOS.CAT CRC=8B2EBECB Ops. That’s something new again! Where does it come from / what distribution and why it’s bound to Intel CPU only? Just drop a link, I’ll read myself. Bro, very nice explanation how to make it work! Yet no word why/how does it work… Hypotheses: Hyper-V BIOS doesn’t have required string at address 0x000F8B88. It simply cannot have different strings for different OEM sets. However, VMM service can return WHATEVER set in registry if [certain?] program tries to read 0x000F8B88 address. And therefore activation works. Any other way to make it work seamlessly? Q: Where 0x000F8B88 address come from? Does this address exist (as part of the range?) in every OEM set?
Correct Correct No idea. Usual harware systems do not have anything special at this address too. OEM systems, sold with OS that needs to be pre-activated have something there. Hyper-V has one BIOS for all VMs, it is in vmwp.exe and can't ba changed programaticly. For OEM vendors, there is an option to map somestring to the address 0x000F8B88 of VMs BIOS. If you put anything ib BiosLockString, all VMs get it in 0x000F8B88 of their BIOS. The specification of SLP 1,0 - the address where OS is looking for harware-manufaturer's marker, that this piece of hardware has been sold with OS. Address can't "exist", it is just an address. Any OEM manufacturer, who ships OEM OS with SLP 1,0 activation has to put something on this address and might have its own OEMBIOS.* set corresponding to own string.
Ah, i have been wondering why the GENUINE set could be used in quite a lot scenarios... the 'GENUINE INTEL' string makes sense... thx for clearing this up for me