The magic word

I was running strings on a set of signed kernel drivers I had pulled from vendor installers when a literal stopped me mid-scroll. Sitting in the middle of a binary that had no business containing it was the string The Magic Word!, complete with the exclamation point.

I knew that string. It is the hardcoded credential in a popular open-source kernel driver, the one that user-mode processes send to prove they belong before the driver will talk to them. The source code is public. The string is public. And here it was, compiled into someone else's signed binary.

I went looking for more. Found two others. Three signed kernel drivers, three separate vendors, all forks of the same open-source driver. All three shipped the original authentication protocol unchanged. All three accept the same static string from any process that knows to send it. None of them show up in LOLDrivers or the HVCI blocklist as of September 2026.

Why the magic word exists

The original open-source driver sits at the bottom of an architecture that splits work between a user-mode service and a kernel component. The kernel side is where the real power lives: physical memory allocation, unsigned code loading into ring 0, direct MSR access. These are not bugs. The software needs these capabilities to function, and the driver provides them by design.

To keep random processes from issuing those IOCTLs, the driver uses a session authentication protocol. A cookie exchange. The process sends a request with a known initial cookie, a version identifier, and a passphrase. The driver checks all three and hands back session cookies for every subsequent call.

The passphrase is The Magic Word!. It has been the same string for years. It is defined as a constant in public source code that anyone can read.

In context, this is fine. The driver was never meant to be a security boundary. It loads on demand, it talks to its own service, and the admin chose to install it. The static credential is a sanity check, not access control. Security depends on who can load the driver and who can open the device handle, not on the passphrase being secret.

The problem is what happens when someone forks this driver, ships it inside their own product, gets it signed, and never changes the string.

The cookie exchange

Every IOCTL uses a common 24-byte request header:

typedef struct {
    uint32_t u32Cookie;         // 0x00: must match after auth
    uint32_t u32SessionCookie;  // 0x04: must match after auth
    uint32_t cbIn;              // 0x08: input buffer size
    uint32_t cbOut;             // 0x0C: output buffer size
    uint32_t fFlags;            // 0x10: always 0x42000042
    int32_t  rc;                // 0x14: return code
};                              // 0x18: payload starts here

The first IOCTL a process sends is the authentication request. Initial cookie is 0x69726F74, ASCII tori. Session cookie starts at zero. The payload carries the magic string at offset 0x18 and a version identifier at 0x28.

COOKIE request:
  u32Cookie        = 0x69726F74  ('tori')
  u32SessionCookie = 0x00000000
  cbIn             = 0x00000030
  cbOut            = 0x00000038
  fFlags           = 0x42000042
  rc               = 0x00000000
  +0x18: "The Magic Word!"      // 16 bytes, null-terminated
  +0x28: uReqVersion            // protocol version identifier
  +0x2C: uMinVersion            // minimum version accepted

COOKIE response:
  u32Cookie        = 0x64726962  ('bird')
  u32SessionCookie = 0x62697264  ('drib')
  rc               = 0x00000000  (success)

Once the driver hands back the bird/drib cookies, every subsequent IOCTL has to carry them. That is the entire auth mechanism. No process ID check. No handle validation beyond the device open. No per-session token. Cookie, string, version. Pass all three and you own the session.

The original driver creates a symbolic link so the device is accessible to the user who installed it. These forks skip that entirely. No symlink. You open the device through the NT namespace with a \\.\GLOBALROOT\Device\... path, which means you need to know the device name. But the device name is a static string baked into the binary. One more run of strings.

Three forks, three eras

All three drivers ship inside consumer software installers. Each vendor forked the same open-source driver at a different point in its history, bolted on their own modifications, and got it signed.

The version identifier in the cookie exchange is what told me when each fork split off.

Driver A is the newest. It carries a WHQL signature from Microsoft, meaning it went through the full Windows Hardware Quality Labs certification process. Microsoft's own infrastructure signed this binary. That one still gets me.

Driver B is mid-era. DigiCert code signing certificate.

Driver C is the oldest by protocol version, but here is the weird part: it has source paths from a newer release embedded in the binary. The vendor froze the protocol version early and kept pulling in runtime code from later releases. Also DigiCert-signed.

The version matters because the cookie exchange rejects the wrong one. My first PoC hardcoded the newest version. Worked against Driver A immediately. Drivers B and C returned version mismatch errors. I had to probe each fork to find what it would accept.

Not guesswork, though. The accepted version ranges are defined in the open source. Once you know roughly when a fork split off, the range is public.

The buffer size problem

After I got authentication working against Driver A, I figured B and C would fall quickly. Same protocol, different version number. They refused to authenticate for two days.

The original driver calculates the DeviceIoControl buffer size as max(cbIn, cbOut). One buffer, big enough for both input and output. You can send a buffer larger than what the input needs, and the driver does not care. Standard practice for METHOD_BUFFERED IOCTLs.

Drivers B and C changed this. Their IOCTL wrapper enforces exact sizes. InputBufferLength must equal cbIn. OutputBufferLength must equal cbOut. Not greater-than-or-equal. Equal.

I did not find this in a disassembler. I found it by staring at STATUS_INVALID_PARAMETER for two evenings, wondering why the exact same protocol that worked against Driver A was failing against two other forks of the same codebase. My PoC was passing max(cbIn, cbOut) for every request. These two forks rejected it every time.

// Original: one buffer, sized to max of input and output
DWORD bufSize = max(req.cbIn, req.cbOut);
DeviceIoControl(hDevice, IOCTL_CODE, buf, bufSize, buf, bufSize, ...);

// Forks B and C: strict match required
DeviceIoControl(hDevice, IOCTL_CODE, buf, req.cbIn, buf, req.cbOut, ...);

Split the buffer sizes. Both drivers authenticated instantly. The cookie exchange is identical across all three forks. The only differences are the version number and whether the IOCTL wrapper is strict about buffer sizes. Someone modified the Windows driver wrapper but left the authentication string untouched. And then a different vendor did the same thing.

What opens up

After authentication, the full IOCTL table is available. What each fork exposes depends on which features survived from the original, but all three kept the ones that matter.

All three have the module loading interface. One IOCTL allocates a slot and reserves kernel memory. The next copies a binary image into that memory and calls its init function. No signature check. Any authenticated caller can load arbitrary unsigned code into the kernel.

Drivers B and C also expose physical memory allocation primitives. One allocates physically contiguous pages and returns three things: a kernel virtual address, a user-mode mapping in the calling process, and the physical address.

Contiguous allocation response (Driver B):
  +0x18: kernel VA   = 0xFFFF????'????????
  +0x20: user VA     = 0x000001??'????????
  +0x28: phys addr   = 0x00000000'????????

Verified: wrote 0xDEADBEEF via user VA, read back via user VA. Match.
Verified: wrote 0xCAFEBABE via user VA, read back via user VA. Match.
Verified: 4096-byte pattern fill and readback. All bytes correct.

A second primitive does the same thing but constrains the allocation below 4GB for 32-bit DMA compatibility. Return layout is slightly different: user VA at 0x18, kernel VA at 0x20, physical address at 0x28. Reversed from the contiguous allocator.

Both give you a user-mode mapping of kernel memory with a known physical address. I wrote test values through the user VA and read them back on all three drivers. The allocations are real, the mappings work, the physical addresses are accurate.

One other memory primitive, the most commonly used one in the original project, failed across all three forks. Probably requires an active session context that does not exist when talking to the driver from a standalone process. The contiguous and low-memory allocators do not need that. They worked cold.

The extraction

I never installed any of the vendor software. The drivers ship inside installers packed in standard archive formats. 7-Zip opens most of them. I extracted the .sys files, verified signatures with signtool, and loaded them on a test machine with DSE fully enabled. All three loaded clean. The signatures are valid. Windows trusts them.

Standard BYOVD from there. Admin to load the driver, then any process that can open the device handle can authenticate and issue IOCTLs. The driver does not care who is calling. It checks the cookie.

An open secret

The authentication bypass is not a bypass. It is the intended protocol, implemented exactly as designed, using a credential that has been sitting in a public repository for over a decade. The Magic Word! is not hidden. It is not obfuscated. It is a string constant that anyone can read.

The original project does not treat it as a secret because it was never meant to be one. Security depends on who loads the driver and who opens the device, not on the cookie exchange being opaque. The cookie proves the caller is the right component, not some confused application that wandered onto the device path.

When a vendor forks this driver, signs it with their own certificate, and ships it in their installer, that security model stops working. The driver is standalone now. Anyone with admin can load it, open the device, and send the magic word. The only thing between an unauthenticated caller and kernel memory primitives is a string that has been public since the original project went open source.

Three vendors did this. Three signing authorities approved it. None of them changed the string.

What's next

These are live findings. I have not included driver names, vendor names, file hashes, or device paths. The details here describe a vulnerability class, not a recipe for a specific binary. Disclosure is in progress.

Good few evenings of work. I will update this post with a timeline once the vendors have had a chance to respond.