[Guide] Intel/AMD CPU Microcode conversion and utilization without modding the BIOS

Although this is the BIOS Modding forum, I think this guide will be beneficial to some.

It explains how to utilize newer CPU microcode versions without having to mod your machine’s BIOS,
and provides (information about) two utilities to convert microcode binary to text format and vice versa,
as the latter is needed to utilize microcodes on OS level.

This is by no means new information. Microcode loading at boot time or OS startup has been a feature
in various Non-Windows OS’s for a long time (notably Linux), but in Windows it’s pretty uncommon,
although the OS supports it by default. Microsoft provides microcode updates through its own mechanism
only if they’re needed to fix actual issues with the respective CPU’s (see e.g. this update).

Fortunately, a separate, free driver provided by VMWare allows microcode loading during startup of the OS on the Windows platform.
It is available for download here.
The driver, however, requires the to-be-loaded microcode file in text format (.dat), not in binary format (.bin),
and this is where the following conversion utilities come into play:

1. bin2dat.py (Thanks to whoever posted the core code for this here)
A little Python script that converts a binary microcode file to its text counterpart, available for download here.
Can simply be started by double-clicking it, or from the command line, and obtains required information through several dialogs.
Requires Python v3.x.
Note:
The script writes a leading comment line into the target file, containing the CPU ID of the CPU the microcode is designed for
(see this site for an overview of the various components of CPU ID’s, and this site for a collection of CPU ID’s of various manufacturers).
This is optional, and can be skipped by clearing the input field in the respective dialog.

2. microdecode.exe (See this thread)
This command line utility does the opposite, it converts microcode in text format to its binary counterpart.
Starting the program without any parameter shows a usage message.
The source code is included.

So in order to enable microcode loading during Windows startup, you have to do the following:
- Obtain a microcode file in text or binary format (binary microcode files are for example included in UBU).
- If your file is in binary format, convert it with bin2dat (see above).
- Rename the microcode file in text format to “microcode.dat”.
- (One-time only) Install the aforementioned driver (see the instructions on the linked site).
- Move the renamed microcode file to %WINDIR%\System32\drivers (replacing an existing file of the same name, if required;
due to file system permissions in that directory you probably have to delete the existing one first).
- Reboot.
- Check Windows Event Log; in the ‘Information’ category, you should now see two entries from Source ‘cpumcupdate’ with Event ID 39 and 41, that provide information about the microcode loading process.

Notes:
- The driver checks the BIOS’s microcode version before attempting to load any microcode, i. e. in case your microcode file contains an outdated microcode version, it won’t be loaded. The aforementioned log entries will reflect this in this case. Also in case anything goes wrong during the process, you’ll see respective log entries (with different Event ID’s), Source is always ‘cpumcupdate’.
- This might work for AMD CPU’s, too, since the driver also supports loading of AMD microcode. Since I don’t have an AMD-based system, I’m unable to test it and hence can’t make a statement in this respect.

I can’t seem to get this to work? Unless the latest 20180108 microcode packages don’t contain anything for my two systems running Asus Rampage IV Extreme + Intel Core i7-3960X, and Asus P8B-E/4L + Intel Xeon E3-1275v2. Both CPU’s are listed on the download page so I suppose they should be getting a new microcode update with this release?

My 3960X has microcode 7C according to HWInfo64 and my E3-1275v2 has microcode 29. That was before I tried running VMWare Driver Update / cpumcupdate. But even after running it HWInfo64 reports the same, even after a reboot and all I can see in the Event Viewer is the following; “No CPUs needed an update. Your system might not need this driver.”.

Something is not working right. Both the Rampage IV Extreme and the P8B-E/4L hasn’t seen a BIOS/UEFI update in forever. The P8B-E/4L has barely gotten any whatsoever so I highly doubt they are on the latest microcode to begin with and I suppose this new 20180108 is supposed to contain newer ones trying to patch for Spectre?

no, only few CPU have updated microcode in 20180108 release, old CPU are not updated.

I figured as much after decoding the microcode.dat. Both my CPU’s are left with microcodes from 2012 and 2013. My 8700K was able to get a newer microcode using the VMWare method.



This is the message you get when the microcode in your BIOS is newer than the one the driver refused to load. If the driver successfully loads the provided microcode, its version should be displayed in HWInfo, too.

There is one problem with this method: recent Windows security mitigation for Spectre needs newest microcode to be loaded at kernel initialization stage because mitigation relies on certain HW support. So if CPU has no such HW support with old microcode but has it with newest microcode then mitigation will be turned off because kernel will see the lack of HW support.
Of course when you boot virtual machine then CPU microcode loaded through driver is in place and in virtual machine security mitigation will work.



Yeah I’m aware of that, it’s unfortunate esp for users with older hardware who supposedly won’t get any BIOS updates for their systems from their board vendors.
It’s probably advisable to follow the discussion in this thread, maybe someone finds a solution for the loading issue.

I doubt they will find a way because driver should be loaded at early stage of kernel initialization. I tried to play with the order of driver`s boot but without luck - too late for mitigation.

Thanks for your time really :slight_smile: but I think using my method is just little better and easy 1 click process :slight_smile:

Here is my method:-

http://forum.notebookreview.com/threads/…eltdown.806451/

Thanks again! :slight_smile:



You seem to have a wrong understanding of the purpose of this guide.
It’s not about the current security issues due to Meltdown/Spectre, and it’s also not about providing an "easy" solution for them.
This guide is meant for technically skilled and interested people who want to know what your options are if you want to (or have to) avoid modifying your BIOS in order to update CPU microcodes.
It also focuses on microcode format conversions, because those can be a hassle due to lack of conversion utilities.

Anyway, this method appears to be of little help for the current Meltdown/Spectre issues, since the driver doesn’t load the microcode early enough. Unless somebody finds a solution for that, you can’t fix any of those vulnerabilities using this method.

Back in the old day we use PXE to inject SLIC, not sure if we can use similar way for the microcode.



You seem to have a wrong understanding of the purpose of this guide.
It’s not about the current security issues due to Meltdown/Spectre, and it’s also not about providing an "easy" solution for them.
This guide is meant for technically skilled and interested people who want to know what your options are if you want to (or have to) avoid modifying your BIOS in order to update CPU microcodes.
It also focuses on microcode format conversions, because those can be a hassle due to lack of conversion utilities.

Anyway, this method appears to be of little help for the current Meltdown/Spectre issues, since the driver doesn’t load the microcode early enough. Unless somebody finds a solution for that, you can’t fix any of those vulnerabilities using this method.




True about it but it does help on security + performance side because it is all about toggling true/false or on/off

If the microcode loaded early then windows will see that and tells you that those vulnerabilities is fixed or protected from it by toggling it but… if it’s not loaded early then it doesn’t mean that you are not protected… you are still protected even if it is loaded late because windows will not see that so it will say you are not protected but actually it is vise versa :slight_smile:

It is all a matter of seconds even during the boot… you’re not connected to internet until your windows loads its drivers ,etc… so you are still safe :slight_smile:

like I said… it is all about toggling options if it’s true/false or on/off :slight_smile:

correct me if I’m wrong about it :slight_smile:



You seem to have a wrong understanding of the purpose of this guide.
It’s not about the current security issues due to Meltdown/Spectre, and it’s also not about providing an "easy" solution for them.
This guide is meant for technically skilled and interested people who want to know what your options are if you want to (or have to) avoid modifying your BIOS in order to update CPU microcodes.
It also focuses on microcode format conversions, because those can be a hassle due to lack of conversion utilities.

Anyway, this method appears to be of little help for the current Meltdown/Spectre issues, since the driver doesn’t load the microcode early enough. Unless somebody finds a solution for that, you can’t fix any of those vulnerabilities using this method.




True about it but it does help on security + performance side because it is all about toggling true/false or on/off

If the microcode loaded early then windows will see that and tells you that those vulnerabilities is fixed or protected from it by toggling it but… if it’s not loaded early then it doesn’t mean that you are not protected… you are still protected even if it is loaded late because windows will not see that so it will say you are not protected but actually it is vise versa :slight_smile:

It is all a matter of seconds even during the boot… you’re not connected to internet until your windows loads its drivers ,etc… so you are still safe :slight_smile:

like I said… it is all about toggling options if it’s true/false or on/off :slight_smile:

correct me if I’m wrong about it :slight_smile:


It just a temporary workaround for those who don’t have support from vendors because the devices are in their EOL list.
I reckon Windows just looks at ucode shipped with BIOS that’s the reason some features aren’t activated.
On linux those features are being used but there’s little slowdown.
I don’t think VMware driver can be made to run at boot.



You seem to have a wrong understanding of the purpose of this guide.
It’s not about the current security issues due to Meltdown/Spectre, and it’s also not about providing an "easy" solution for them.
This guide is meant for technically skilled and interested people who want to know what your options are if you want to (or have to) avoid modifying your BIOS in order to update CPU microcodes.
It also focuses on microcode format conversions, because those can be a hassle due to lack of conversion utilities.

Anyway, this method appears to be of little help for the current Meltdown/Spectre issues, since the driver doesn’t load the microcode early enough. Unless somebody finds a solution for that, you can’t fix any of those vulnerabilities using this method.




True about it but it does help on security + performance side because it is all about toggling true/false or on/off

If the microcode loaded early then windows will see that and tells you that those vulnerabilities is fixed or protected from it by toggling it but… if it’s not loaded early then it doesn’t mean that you are not protected… you are still protected even if it is loaded late because windows will not see that so it will say you are not protected but actually it is vise versa :slight_smile:

It is all a matter of seconds even during the boot… you’re not connected to internet until your windows loads its drivers ,etc… so you are still safe :slight_smile:

like I said… it is all about toggling options if it’s true/false or on/off :slight_smile:

correct me if I’m wrong about it :slight_smile:


It just a temporary workaround for those who don’t have support from vendors because the devices are in their EOL list.
I reckon Windows just looks at ucode shipped with BIOS that’s the reason some features aren’t activated.
On linux those features are being used but there’s little slowdown.
I don’t think VMware driver can be made to run at boot.



Well…I would like to add another thing is I tried to make it load as early as possible by doing this trick :slight_smile:

Open the registry and go to [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cpumcupdate] look at the [Start] key… usually you will find the value will be (2) [Which means Automatic] so… change it to (1) [Which means it will load with the system] :slight_smile:

I tried to put (0) [Which means it will load at boot] but it didn’t work and it failed to apply the new microcode

you can try also to make dat file smaller so driver will not have to load and process all that codes till it find your CPU :
- convert your CPU microcode from bin to dat file ( depend of CPU it will be between 30 - 300Kb compared with original dat 4.8Mb ) and replace the original dat file.

Microsoft update for microcodes (finally) for Skylake H/S and Skylake U/Y & Skylake U23e
https://support.microsoft.com/en-us/help…crocode-updates

Hmmm, maybe I’m stupider than I thought.
bin2dat.py says every Intel microcode .bin file I give it is invalid.
I’m running it on 64 bit ubuntu 17.10.

looks like cpumcupdate doesn’t work with windows 10 version 2004.

see two events:
- Initiating check of CPU microcode version.
- Failed to update microcode on one or more CPUs.

edit: actually, nevermind. It’s probably because of hyper-v (trying out wsl2)

NewEraCracker’s bin2dat v0.0.3.1 (dated 26 Dec 2018)
platomav’s microcode repositories
Intel/AMD uCode fix for Spectre, HT bug fix and Meltdown guide in NotebookReview forum (dated May 25 2019)
microcode_amd.bin

I’m adding cpumcupdate2.1 file which includes NewEraCracker’s bin2dat 0.0.3.1,VMware CPU Microcode Update Driver,necessary amd microcode file (vmware driver needs it to run but not included in it)
all you need to do is,download and unzip it in place,get your microcode bin from platomav’s repo,rename it to microcode.bin,place it into the folder,run the bin2dat (using cmd) and change your microcode bin to dat format then run the driver.

pretty much everything is the same as mentioned in the guide(s).i have just put them together to keep it simple and for safekeeping.
except phyton,you can get it from microsoft store

Edit: see here;
Microsoft is releasing regular microcode updates for Windows10
https://www.bleepingcomputer.com/news/mi…rocode-updates/