Understand exactly what MSI changed in the X670E TOMAHAWK v1KB BIOS update
Decide whether to flash v1KB based on the risk analysis in the writeup
Learn how UEFI option ROM stripping blocks FPGA-based DMA cheat hardware
There is nothing to install; the repo is a markdown writeup so reading the README is the entire deliverable.
This repository is a writeup, not a tool. The author takes a recent BIOS update from MSI for the MAG X670E TOMAHAWK WIFI motherboard, called v1KB and dated March 2026, which MSI advertised in its release notes with the line about an anti-cheat mechanism. The README is the result of opening up the new BIOS file, comparing it against the previous version v1KA, and explaining exactly what changed. The short answer is that only two small things changed in the pre-boot code that runs before the operating system starts. MSI did not add a new driver, a new system management handler, or any new piece that the operating system can talk to. Both changes live in early UEFI firmware modules called Bds and DxeCore. The first change adds 52 bytes to the Bds module. During the part of boot where the firmware lists all the PCI devices on the board, the new code clears one specific attribute bit on each device, the EMBEDDED_ROM bit. PCI devices can advertise their own small option ROM, which is firmware code that the system runs during boot. By stripping that bit, MSI prevents any plugged-in PCI card from injecting its option ROM into the boot process. The author notes that some hardware cheating devices, particularly FPGA boards that perform direct memory access tricks, rely on this option ROM behaviour, so this is most likely the route MSI is closing, although MSI itself has not said so. The second change is a single tweaked number in DxeCore that controls the no-execute, or NX, policy for different categories of memory during boot. The bitmask goes from 0x4FD5 to 0x4F41. In practice this removes NX protection from three memory types: EfiLoaderData, EfiBootServicesData, and EfiConventionalMemory. That is the opposite of hardening, since it lets code run from memory regions that were previously marked as data only. The author guesses this is either a compatibility patch for a new pre-boot component or a workaround for a regression from the AMD AGESA firmware update. The writeup ends with a risk note. Both changes only run once during boot. There is no new code path that a driver running inside Windows or Linux can reach after the operating system starts. The author concludes the update is safe to flash.
Generated 2026-05-22 · Model: sonnet-4-6 · Verify against the repo before relying on details.