For you testers: Here’s how to spoof a Kaby Lake processor inside a VirtualBox Win7 VM

[woodyDa Boss]

Details coming shortly from MrBrian….
[See the full post at: For you testers: Here’s how to spoof a Kaby Lake processor inside a VirtualBox Win7 VM]

[MrBrianAskWoody_MVP]

Note: My text got mangled. In step 3, before each cpuidset there should be two minus signs. Also, before cpuid-portability-level there should be two minus signs.

[woodyDa Boss]

OOOPS. Change made.

(The editor changed double-hyphens into em-dashes.)

[MrBrianAskWoody_MVP]

Thanks, but I’m still seeing a solid dash instead of two minus signs.

[abbodi86AskWoody_MVP]

pastebin (and similar sites) are good place to post programatic code

2 users thanked author for this post.

woody,

MrBrian

[woodyDa Boss]

Blech. The editor took them away again.

I’ll take Abbodi’s advice….

Did that work?

[MrBrianAskWoody_MVP]

For you testers: Here’s how to spoof a Kaby Lake processor inside a VirtualBox Win7 VM

[MrBrianAskWoody_MVP]

For reference: CPUID.

[MrBrianAskWoody_MVP]

Some Windows 7 tests involving spoofed Kaby Lake CPU:

1. Installed KB4015546 (April 2017 security-only update) and rebooted. Then tried to install an older standalone Windows Update (.msu file) KB3021917. Result:

View post on imgur.com

2. Then, with Windows Update configured to never check for updates, manually checked for Windows updates. Result:

View post on imgur.com

View post on imgur.com

3. Then uninstalled KB4015546 (April 2017 security-only update) and rebooted. Then tried to install an older standalone Windows Update (.msu file) KB3021917. Result:

View post on imgur.com

4. Then, with Windows Update configured to never check for updates, manually checked for Windows updates. Result:

View post on imgur.com

5. Then installed a few updates through Windows Update. Result:

View post on imgur.com

6 users thanked author for this post.

Elly,

FakeNinja,

radosuaf,

James Bond 007,

abbodi86,

PKCano

[MrBrianAskWoody_MVP]

My last post demonstrated:

1. When the April 2017 security-only update was installed, you can’t install Windows updates either through Windows Update or .msu files.

2. After the April 2017 security-only update was uninstalled, Windows updates can be installed through either Windows Update or .msu files.

[abbodi86AskWoody_MVP]

Can you test to see if dism /add-package with cab file works on blocked system?

thanks

[MrBrianAskWoody_MVP]

Result: package successfully added 🙂

[woodyDa Boss]

Amazing!

So that’s the solution for folks who manually installed the Security-only patch.

What about those who installed the Monthly Rollup?

Thanks!

[MrBrianAskWoody_MVP]

See a few posts below.

[abbodi86AskWoody_MVP]

It works for either of them

[MrBrianAskWoody_MVP]

Step 3: see https://pastebin.com/s5krwbMc.

[anonymous]

@ MrBrian

If I am using a Win 7/8.1 computer with the Intel Kabylake or AMD Ryzen chip, how do I spoof a 5th-gen chip, so that I won’t be blocked by MS from getting security updates until 2020/2023.?

[MrBrianAskWoody_MVP]

Do you mean for a virtual machine or a real computer?

[anonymous]

@mrbrian

Both?

[MrBrianAskWoody_MVP]

For a virtual machine, see https://www.askwoody.com/forums/topic/for-you-testers-heres-how-to-spoof-a-kaby-lake-processor-inside-a-virtualbox-win7-vm/#post-108402.

For a real machine, I briefly searched for a CPU spoofing method, and did not find anything.

[MrBrianAskWoody_MVP]

I did the same tests as https://www.askwoody.com/forums/topic/for-you-testers-heres-how-to-spoof-a-kaby-lake-processor-inside-a-virtualbox-win7-vm/#post-107993, but this time testing KB4015549 (April 2017 monthly rollup) instead of KB4015546 (April 2017 security-only update).

Results: Same as before!

Recap:

1. When the April 2017 monthly rollup was installed, you can’t install Windows updates either through Windows Update or .msu files.

2. After the April 2017 monthly rollup was uninstalled, Windows updates can be installed through either Windows Update or .msu files.

[AscarisAskWoody_MVP]

MrBrian wrote:

I did the same tests as https://www.askwoody.com/forums/topic/for-you-testers-heres-how-to-spoof-a-kaby-lake-processor-inside-a-virtualbox-win7-vm/#post-107993, but this time testing KB4015549 (April 2017 monthly rollup) instead of KB4015546 (April 2017 security-only update). Results: Same as before! 

This is the same method Radosuaf suggested, if I am correct.

So what you’d have to do is uninstall the most recent rollup already installed on the PC (which should normally be the one from the prior month), then allow Windows Update to find and install the new one.  Since the rollups are cumulative, you’d have reinstalled all of the fixes that were in last month’s rollup that you just deepsixed when you installed the new patch.  Next month, do the same, and the month after, and the month after…

I have little doubt that the people who brought us cracks for the Windows theme signature enforcement and other such things will find a way around this pretty quickly.  This is a tacked-on little change, and it should be relatively easy for someone to get rid of.  Perhaps someone will even create a “disable CPU checking” service that works like the “disable theme signature enforcement” one.

In Microsoft’s zeal to assert complete control of people’s systems, they’re training a whole new generation of Windows users to do things like disable the Windows Update service and otherwise hack the system to get back the control that MS took away.   Apparently, people choosing to have automatic updates OFF was intolerable for Microsoft, so they’ve set it up so that now the few people who ever changed the update settings will just disable the service, which makes it even less likely they’ll get future updates than if they’d just turned them off (particularly if they would have chosen the “notify but don’t install” option).

 

Group "L" (KDE Neon User Edition 5.16.3).

3 users thanked author for this post.

HiFlyer,

Elly,

FakeNinja

[MrBrianAskWoody_MVP]

Yes indeed. I made a topic for radosuaf’s method.

[MrBrianAskWoody_MVP]

Another test involving spoofed Kaby Lake CPU: the behavior of Windows Update when set to update automatically.

1. Installed KB4015546 (April 2017 security-only update) and rebooted.

2. Set Windows Update to update automatically and rebooted.

3. After a few minutes, I got the “Unsupported hardware” message.

4. Rebooted. After few minutes, I got the “Unsupported hardware” message again.

2 users thanked author for this post.

woody,

radosuaf

[anonymous]

Lol, 

imgur.com/a/Qws1t

yep, that’s the message.

“unsupported hardware” that’s such a joke. I wonder if taking the new cpu driver and hal.dll from windows 10, when released, will make any difference.

[radosuafAskWoody Lounger]

That is disgusting. GWX2 for me. They don’t only block updates but will harass people with this stupid notification. Are you patient enough to see if it happens just once after reboot or every X minutes? 🙂

MSI H110 PC MATE * Intel Core i5-6402P * 2 x 8 GB Corsair Vengeance LPX DDR4 2133 MHz * Aorus Radeon RX 570 4GB * Samsung 840 EVO 250GB SSD * Western Digital Blue 1TB HDD * Seagate Barracuda 1TB HDD * DVD RW Lite-ON iHAS 124 * Creative X-Fi XtremeGamer PCI * Windows 10 Pro 1809 64-bit

[abbodi86AskWoody_MVP]

“Windows Update when set to update automatically”

of course he will get the messege, since WU trying to search for updates in the background

[radosuafAskWoody Lounger]

I cannot recall any other WU error popping up on my screen when it was impossible to search for updates.

MSI H110 PC MATE * Intel Core i5-6402P * 2 x 8 GB Corsair Vengeance LPX DDR4 2133 MHz * Aorus Radeon RX 570 4GB * Samsung 840 EVO 250GB SSD * Western Digital Blue 1TB HDD * Seagate Barracuda 1TB HDD * DVD RW Lite-ON iHAS 124 * Creative X-Fi XtremeGamer PCI * Windows 10 Pro 1809 64-bit

[abbodi86AskWoody_MVP]

Yeah, but that’s not an actual error in this case

it’s a designated lock

[radosuafAskWoody Lounger]

abbodi86 wrote:

Yeah, but that’s not an actual error in this case it’s a designated lock

Yes, that’s why I’m saying it’s harassment :). Block updates and stop nagging people.

MSI H110 PC MATE * Intel Core i5-6402P * 2 x 8 GB Corsair Vengeance LPX DDR4 2133 MHz * Aorus Radeon RX 570 4GB * Samsung 840 EVO 250GB SSD * Western Digital Blue 1TB HDD * Seagate Barracuda 1TB HDD * DVD RW Lite-ON iHAS 124 * Creative X-Fi XtremeGamer PCI * Windows 10 Pro 1809 64-bit

[MrBrianAskWoody_MVP]

It also would be bad if a user stopped getting Windows updates through automatic updates and wasn’t notified of this fact.

[James Bond 007AskWoody Lounger]

Thanks MrBrian for the tests.

So I think I can assume that Windows 7 and Windows 8.1 virtual machines running on a REAL Kaby Lake or Ryzen system (which shows the CPU id inside the virtual machine) will also be blocked from future Windows updates once the April security quality rollup (or subsequent rollups) are installed.

I would like to try this test myself but I am using VMware Workstation, not Virtualbox. I wonder if there is a way to do this with VMware.

Hope for the best. Prepare for the worst.

[James Bond 007AskWoody Lounger]

James Bond 007 wrote:

I would like to try this test myself but I am using VMware Workstation, not Virtualbox. I wonder if there is a way to do this with VMware.

I think I know how to spoof a Kaby Lake CPU in a VMware virtual machine. But I need a ProcessorID from a Kaby Lake CPU as I don’t have a Kaby Lake system myself.

So I would like to ask for help in obtaining the ProcessorID. If there is anyone here who is using a Kaby Lake system to run Windows, could you please do the following:
(1) Open Windows Powershell
(2) Type the command Get-WmiObject Win32_Processor (there is a space between) and press enter
(3) From the data displayed, record the ProcessorID and post it here

That is all. Thank you for your help in advance.

MrBrian, is it possible for you to post the ProcessorID inside your spoofed Kaby Lake virtual machine?

Hope for the best. Prepare for the worst.

[MrBrianAskWoody_MVP]

ProcessorID field was blank.

[James Bond 007AskWoody Lounger]

MrBrian wrote:

ProcessorID field was blank.

So apparently Virtualbox does not list the ProcessorID inside the virtual machines.

Thanks for your help, MrBrian. I have found the necessary information from the CPU-World website. I shall try the test myself using VMware Workstation later and report back the results.

Hope for the best. Prepare for the worst.

[aarvAskWoody Lounger]

I found something interesting, i just tested with virtualbox spoofed cpuid, win8.1 enterprise, after April 2017 update

http://imgur.com/a/A30ZK

is that mean it can work with enterprise version windows???

[abbodi86AskWoody_MVP]

Did you try Windows 8.1 Pro edition? maybe the spoofing did not get set correctly

[aarvAskWoody Lounger]

sorry, i’m not…

also one thing i not set is cpuid-portability-level=1 because after set this i can’t install win8.1 in virtualbox

so it may not be correctly…

[abbodi86AskWoody_MVP]

Nonetheless, the only way to confirm is you use same spoofing setting on both editions

if both passed, then the spoofing is not complete
if Pro get blocked, then you finding is indeed true and interesting

thanks

[MrBrianAskWoody_MVP]

Try setting cpuid-portability-level to either 2 or 3.

[aarvAskWoody Lounger]

I found the reason, it because i was tune on  hyper-v that win8.1 can detect i’m using virtual machine, after i turn it off the warning will show on

sorry everyone…

[MrBrianAskWoody_MVP]

If anybody has an actual Kaby Lake or other blocked processor, and has a VirtualBox Windows 7 or 8.1 virtual machine, and wants to spoof a different processor that might not be blocked from getting Windows updates in the virtual machine, please try substituting this for step 3, and post your results. If it works, I will make a separate topic for it.

[MrBrianAskWoody_MVP]

Good news: a user has purportedly successfully used this method :).

1 user thanked author for this post.

abbodi86

[MrBrianAskWoody_MVP]

In step 3, the number following cpuid-portability-level needs to be an integer from 0 to 3. The lower the number, the more faithfully VirtualBox tries to spoof the processor, but also the greater chance of the virtual machine not working.

[aarvAskWoody Lounger]

ok, i tried another method, i just replace wuaueng.dll to old version, windows update is working, no problem with checking and install update

 

View post on imgur.com

(更新已安裝=install complete, sorry i have no time to change the language to english)

4 users thanked author for this post.

Elly,

James Bond 007,

MrBrian,

radosuaf

[aarvAskWoody Lounger]

it’s also work in win7

View post on imgur.com

View post on imgur.com

but sometime warning is show on but it still can install update

View post on imgur.com

1 user thanked author for this post.

[anonymous]

hello aarv, thanks for the info of changing the dll. I test the same way but also change the other files depending on Windows Update. I change six files and now Update works again fine.

replaced files:

wu.upgrade.ps.dll
wuapi.dll
wuapp.exe
wuauclt.exe
wuaueng.dll
wucltux.dll

I have to use a live linux to replace the files. So somebody knows a way to do this in working Windows, because of the wrong owbership for that system files. sorry for that english.

Edited to remove HTML code. Please convert your reply to text before posting

[aarvAskWoody Lounger]

you can use takeown command to change file owner

takeown /a /f “C:\Windows\System32\wuaueng.dll”

after do this, you should change the Administrators group have fully control this file

icacls “C:\Windows\System32\wuaueng.dll” /grant Administrators:f

now you can change this file in windows

[James Bond 007AskWoody Lounger]

Interesting, so by replacing the wuaueng.dll file with an older version dated 14 May 2016, Windows Update will resume working even though the April updates are installed.

This may be useful in the future.

Hope for the best. Prepare for the worst.

[MrJimPhelpsAskWoody_MVP]

aarv wrote:

sorry i have no time to change the language to english

Your English is good. Thank you for the helpful information that you post.

Group "L" (Linux Mint)
with Windows 8.1 running in a VM

1 user thanked author for this post.

[James Bond 007AskWoody Lounger]

I am pleased to report that I have successfully recreated (part of) the results of the test.

I took the CPU data supplied by MrBrian (which is in fact the CPUID of a Kaby Lake mobile CPU) and converted them for use in VMware Workstation.

I use VMware Workstation 10.0.5 and a Windows 7 virtual machine (patched to September 2016) created before. My host CPU is Core i7 6800K.

For interested parties, here is what I have done so far:

(1) Add the following lines to the vmx file of the virtual machine
cpuid.1.eax = “0000:0000:0000:1000:0000:0110:1110:1001”
cpuid.1.ebx = “0000:0000:0001:0000:0000:0100:0000:0000”
cpuid.1.ecx = “0111:1111:1111:1010:1111:1011:1011:1111”
cpuid.1.edx = “1011:1111:1110:1011:1111:1011:1111:1111”
featureCompat.enable = “FALSE”

The data was obtained from MrBrian’s supplied data, specifically the line “–cpuidset 00000001 000806e9 00100800 7ffafbbf bfebfbff”. VMware required that the data be converted to binary from hexadecimal.

The last line is needed in case the virtual machine fails to start.

(2) After the virtual machine started and with Windows Update set to Never Check for Updates, I installed KB4015546 (April Security-only update) and rebooted the virtual machine.

(3) After the reboot, I ran Windows Update and attempted to check for updates. The message “Unsupported Hardware” immediately appeared and Windows Update displayed the error “Code 80240037”.

(4) I then attempted to install KB4015549 (April Security Quality Rollup) and the install failed with the error “Installer encountered an error 0x80240037”.

(5) I tried to install KB4014661 (IE11 Cumulative Security Update) or KB4014573 (.NET 3.5 security update, part of the .NET security update KB4014985), same as (4).

So far the results are consistent with MrBrian’s. After installing the April Security only update KB4015546, no more updates can be installed via Windows Update or .msu files.

Hope for the best. Prepare for the worst.

3 users thanked author for this post.

Elly,

abbodi86,

MrBrian

[MrBrianAskWoody_MVP]

It’s great to have another person testing this. Thanks :).

[James Bond 007AskWoody Lounger]

I did another test by installing the IE11 update KB4014661 first and then reboot. This time Windows Update when asked to check for updates successfully displayed the list of updates. This shows clearly that the IE11 update does not contain the CPU checking code.

I also tested by installing the April Security Quality rollup KB4015549 first and then reboot. After this the same problems occurred. Windows Update showed “Unsupported Hardware” when asked to check updates, and .msu update files downloaded from the Update Catalog refused to install.

After installing KB4015549, I attempted to install KB4014566 (the .NET 4.5.2 security update which is a part of the .NET security update KB4014985) and the install was allowed to proceed. The install file is an .exe file and not a .msu file when downloaded from the Update Catalog.

Hope for the best. Prepare for the worst.

1 user thanked author for this post.

MrBrian

[James Bond 007AskWoody Lounger]

Here is a picture of “Unsupported Hardware” in VMware :

Hope for the best. Prepare for the worst.

Attachments:

You must be logged in to access attached files.

1 user thanked author for this post.

MrBrian

[James Bond 007AskWoody Lounger]

There is a slight error in (1). The text that should be added to the vmx file should be:

cpuid.1.eax = “0000:0000:0000:1000:0000:0110:1110:1001”
cpuid.1.ebx = “0000:0000:0001:0000:0000:1000:0000:0000”
cpuid.1.ecx = “0111:1111:1111:1010:1111:1011:1011:1111”
cpuid.1.edx = “1011:1111:1110:1011:1111:1011:1111:1111”
featureCompat.enable = “FALSE”

The error is in the second line. Sorry for the mistake.

Hope for the best. Prepare for the worst.

[James Bond 007AskWoody Lounger]

Further testing.

(1) I cloned a new Windows 7 virtual machine with the following lines added to the vmx file:

cpuid.1.eax = “0000:0000:0000:0100:0000:0110:1110:0011”
cpuid.1.ebx = “0000:0000:0001:0000:0000:1000:0000:0000”
cpuid.1.ecx = “0111:1111:1111:1010:1111:1011:1111:1111”
cpuid.1.edx = “1011:1111:1110:1011:1111:1011:1111:1111”
featureCompat.enable = “FALSE”

These lines should spoof a Skylake CPU inside the VM. CPUID data was obtained from a VMware log posted on this link.

(2) I then moved the vmdk disk file used in the Kaby Lake VM (with KB4015546 installed, which generates the “Unsupported hardware” message when asked to check for updates in Windows Update) to the Skylake VM.

(3) Then I launched the Skylake VM, ran Windows Update and asked it to check for updates. While in the Kaby Lake VM Windows Update gave me “Unsupported hardware”, the same copy of Windows 7 inside the Skylake VM successfully gave me a list of updates in Windows Update.

(4) I chose to install KB4015549 (April Security Quality Rollup). The update was downloaded and successfully installed. Then I rebooted the virtual machine.

(5) I then attempted to install KB4014573 (the .NET 3.5 security which is a part of the .NET security update KB4014985), in .msu format. The install was successfully completed. The same install was blocked under the Kaby Lake VM.

My conclusion is that the current CPU blocking code contained in KB4015546 / KB4015549 blocks Kaby Lake systems from installing any further updates either via Windows Update or .msu update files from the Update Catalog. But the code does not block Skylake systems at this time.

Hope for the best. Prepare for the worst.

1 user thanked author for this post.

MrBrian

[James Bond 007AskWoody Lounger]

This is the result shown when running CPU-Z on the spoofed Kaby Lake VM :

This is the result shown when running CPU-Z on the spoofed Skylake VM :

So I can say that this method of spoofing is successful and can be used for other types of CPU.

In the future I believe Microsoft may change the CPU blocking code when it thinks it is necessary to do so. Therefore I will keep these virtual machines and use them for testing future update rollups and security-only updates when necessary.

So far, my test results corresponds with MrBrian’s. In a nutshell, KB4015546 or KB4015549 when installed will prevent Kaby Lake (and probably also Ryzen) systems from installing further updates either via Windows Update or .msu updates from the Update Catalog. Other CPU types such as Skylake are not blocked at this time.

Hope for the best. Prepare for the worst.

Attachments:

You must be logged in to access attached files.

2 users thanked author for this post.

abbodi86,

MrBrian

[MrBrianAskWoody_MVP]

Some Skylake systems might be blocked though: Skylake systems supported on Windows 7 and Windows 8.1.

[James Bond 007AskWoody Lounger]

MrBrian wrote:

Some Skylake systems might be blocked though: Skylake systems supported on Windows 7 and Windows 8.1.

Yes, I am aware of that. That’s why I am keeping the altered virtual machines for testing later. I am going to see if Skylake systems other than those on that list will be blocked later. At present, as far as I can tell, there is no indication that Skylake systems have been blocked after installing the April rollup or April security-only update.

Hope for the best. Prepare for the worst.

[James Bond 007AskWoody Lounger]

One more thing. This may not be very relevant for people here. But I thought I should mention it anyway.

I also tested a Windows Server 2008 R2 virtual machine altered to spoof a Kaby Lake CPU. The result is the same as with Windows 7. For example, after installing KB4015549 and rebooting, then asking Windows Update to check for updates, will generate an “Unsupported hardware” message.

Hope for the best. Prepare for the worst.

1 user thanked author for this post.

MrBrian

[James Bond 007AskWoody Lounger]

I also tested a Windows 8.1 virtual machine altered to spoof a Kaby Lake CPU. The result is just as expected, the same as with Windows 7. For example, after installing KB4015550 and rebooting, then asking Windows Update to check for updates, will generate an “Unsupported hardware” message.

Hope for the best. Prepare for the worst.

2 users thanked author for this post.

MrBrian

[anonymous]

I’ve said this elsewhere, not all hope is lost, all it takes is patching the updater (wuaueng.dll) IsCPUSupported(void) check to always pass true to IsDeviceServiceable(void), works both in win7 and 8.1 for now, hoping for a wider bit of public uptake and support to make a proper tool for everyone. Be it a tool that patches the dll or a tool that patches the routine in memory.

Edited to remove HTML content

[anonymous]

This is most likely something you would want to do in memory, and I hope someone is working on it. I’d be concerned that patching the dll would cause integrity issues with system files, and Windows would automatically restore the original dll when either sfc or dism is run.

[anonymous]

It seems that editing the correct things within wuaueng.dll seems to do the trick. I just tried it now and I’m able to once again access Windows Update. I’m going to keep my patch running for a few days to see if anything changes, but for now it works.

[anonymous]

would it be possible to just replace “wuaueng.dll” with a older version without the cpu detention?

[MrBrianAskWoody_MVP]

A poster in this thread tried this. Note though that the lowest level of servicing since Windows Vista has been the component level and not the file level.

[Author]

Posts