We are constantly looking for ways to improve the reliability, usability, and efficiency of the script, as per our goal of creating the best Windows activator out there. As such, we'd like to announce some changes that we want to make sometime in the future.

Future Plans​

The vast majority of MAS has been written in batch since its inception. As the project grew, however, it became increasingly harder to maintain, read, and debug the code. In many parts of MAS, we have to invoke PowerShell as a new process whenever batch can't accommodate what we want to do. The batch script has really started showing its age, and it's about time we move on to something better.

We have finally decided to begin work on a complete port of the script to PowerShell. This will allow us to achieve things that were previously impossible or infeasible:

• Better Performance: MAS is currently severely bottlenecked by the frequent need to start separate PowerShell processes. PowerShell takes a while to fully initialize; when you have to invoke it frequently, it wastes a lot of time.
• Feature Set: It will allow us to add new features that would have been difficult to implement using batch.
• Readable Codebase: Porting the script to PowerShell will allow us to adhere to modern standards for code organization, allowing more of our users to explore or audit the code much more comfortably.

Changes to Operating System Support​

The current version of MAS is to be considered "feature-complete." It has full support for Windows Vista onwards, and at this point, the only updates it receives are related to maintenance or minor improvements.

As such, we have decided that it's best for the PowerShell port to not include support for Windows 8.1 and older. By focusing on modern Windows versions, we can cut down on the bloat of the current script considerably and reduce the time needed to complete the port's development.

We do understand that this script is very important to some of you for activating older versions of Windows, which is why the legacy batch version will still be available for download on our GitHub. This does not mean that we will continue to support it after the PowerShell port comes to fruition. However, by the time the PowerShell port is completed, support from Microsoft for these old versions will be completely gone. This means that the legacy script should continue to work on these old versions without requiring future updates from us, as no new system changes will be introduced that could break it.

When?​

We don't have a concrete date for when the PowerShell port will be released to the public. We are all people who work on the project for free in our spare time, and many factors can drastically affect development time. Until the new version is ready, the batch version of the script will continue to be fully supported.

It is likely that we will have a brief public beta-testing period before deprecating the batch version for good, so the switch won't be too swift.

We really appreciate your patience while we work towards our goal of making the script even better than it already is. Take care.

A recent Windows update killed our new activation exploit, TSforge... or so we thought. I will break down what went wrong, how we worked around the problem, and in the process, make a point about the apparent decline in Microsoft's code quality control.

When we released TSforge back in February, it served as an entrypoint for multiple activation methods. Many news websites wrote articles about it on release, giving it a ton of publicity.

One of the main goals of TSforge was to enable the free activation of the Windows 10 Extended Security Updates program, giving thousands a simple way to keep using their Windows 10 system safely for a few more years without additional fees.

It was also the first permanent activation method for Windows versions earlier than Windows 10 that didn't require installing a bootkit into your system to inject an SLIC table into ACPI, a process known to sometimes cause issues with booting the system.

Initially, MAS integrated only one TSforge-based activation method: ZeroCID. ZeroCID was chosen because, due to how it works, it could activate basically everything permanently and it was tested by us rigorously before release to ensure reliability.

Everything was seemingly going fine with the release... until it wasn't.

The Incident​

Merely a month later, ZeroCID was confirmed patched on the then-latest Windows 11 Insider build, 27802:

To put this into perspective, Microsoft going out of its way to patch (or even care about) activation exploits was unheard of since the release of Windows 10 back in 2015.

Whenever Microsoft "patched" an activation method, it was almost always an unintentional side effect of an unrelated change. The first version of HWID (our most used activation method to date), for example, was patched by Microsoft unintentionally due to them finally remembering to cut off the free Windows 7 to Windows 10 upgrade that was supposed to end 7 years prior. The first version of HWID just so happened to rely on this free upgrade path to grant activation. Fortunately we managed to promptly update it 2 days later to un-patch it. Thanks Bill Gates.

But this time, we weren't so sure. Our immediate conclusion to this was simple: the party was finally over. Microsoft had caught on and patched the exploit intentionally for once. This theory seemed even more likely because the news articles written about TSforge had put us directly in the spotlight, directly in Microsoft's line of sight. It would make sense if Microsoft finally got someone to do something about the new developments in the Windows piracy department, as an attempt to protect their reputation.

But that theory quickly fell apart.

As explained previously, TSforge is simply an entrypoint. We made multiple activation methods that used said entrypoint to function. ZeroCID was now broken, but there also existed KMS4k, which KMS activates Windows for a staggering ~4000 years. We proceeded to test KMS4k on the new, problematic build and it ended up working flawlessly.

This didn't make a lot of sense. Why would Microsoft make such an incomplete, effectively duct taped attempt to patch an exploit of this magnitude? This was nowhere near a comprehensive fix; it was a targeted hit on only one of the activation methods made possible by TSforge. It didn't feel like a deliberate patch; it felt like an accident. We had to know what really happened.

Context​

The legitimate phone activation process, which ZeroCID exploits, works like this:

Windows provides you with an "Installation ID" (IID), which you're expected to provide to Microsoft by calling them. They give you back a "Confirmation ID" (CID) which you can use to activate Windows. The CID is cryptographically checked by Windows against a public key stored in the license file of the license you're trying to activate.

Under the hood, SPP stores "cache" entries containing a hash of the IID and CID pair in the "trusted store" (an AES encrypted file containing activation data) upon an attempt to phone activate. This is done to save CPU cycles in the future by avoiding repeated cryptographic checks. Instead, SPP refers to the cache every time it needs to quickly determine whether activation should be granted or not.

This performance optimization is what ZeroCID abuses to activate Windows since, if there's valid cache entries in the trusted store, SPP will no longer try to validate the input CID and will blindly trust the cache, assuming that everything is, indeed, valid. When you use ZeroCID, it manually adds its own cache entries into the trusted store (where it calculates the hash as if the CID were all 0s, hence the name).

Here's one of the cache entries opened in a hex editor, with the relevant section of the entry selected:

The first 4 bytes store the length of the hash, and the rest of the highlighted bytes are the hash itself. The hash is created by concatenating the IID and the CID, then SHA256 hashing the final string.

This known, predictable behavior was our baseline when developing the activation methods that used TSforge. Now, it was time to see what was changed.

Investigation​

On the next day, WitherOrNot began looking into what happened, mostly by trying to figure out what code was changed in SPP in 27802 compared to the previous build. Around the same time, asdcorp also started looking into the incident and began inspecting the trusted store on the new build, trying to see if data was being stored differently.

Eventually, it was noticed that the IID + CID pair hashes in the cache entries seemed to be calculated differently. At the time, we didn't know what exactly was being hashed, or if a workaround was even possible.

But then, yet another oddity was noticed. After some more time, we noticed that the hashes saved in the cache entries seemed to change every single time the user checked the activation status. SPP seemed to now be spamming Event Viewer logs with the following message as well:

This was very unusual, because the above Event Viewer log is only supposed to be sent if the IID and CID pair were re-validated cryptographically. This observation implied that they were essentially feeding garbage to the part of the code that generates the hash, which means that SPP would be forced to regenerate the hashes every single time the user performs an operation, therefore, succesfully hackpatching ZeroCID, which depended on SPP not checking the input CID if the cache was present. The cache would now always fail to validate due to the hashes never matching the IID + CID pair provided to SPP by the user.

This was deeply puzzling. It would be an extremely strange way to patch the exploit, to the point that it came across as a bit of an absurd conclusion based on the limited data we had. WitherOrNot doubted this theory and decided to confirm it himself by firing up a debugger (x64dbg), then starting to look for the function which was creating the hash. Surely we were mistaken and something else was going on.

Here's the debugger, with a breakpoint set on the BcryptHashData function which has been hit. You can see the arguments it's receiving on the right hand side. Even from this one screenshot, the issue is pretty clearly visible. For those unfamiliar with C-like languages, the ampersand (&) you see here before the second argument means we're passing a memory address to the data, not the data itself.

Yep, they're hashing the memory address of the data instead of the data itself. Which means the calculated hash will always be different every time SPP runs this check. This is effectively RNG-based hashing. They actually make this mistake twice, on both the IID and the CID.

To illustrate this more clearly, here's a simplified pseudocode representation of how you're supposed to do this correctly with BCrypt:

// Get the IID and the CID
LPWSTR iid_data = get_iid();
LPWSTR cid_data = get_cid();

// Create a handle for the SHA256 algorithm
hash_handle = BCryptCreateHash(...);

// 1. Hash the IID
BCryptHashData(hash_handle, iid_data, size_of_iid, 0);

// 2. Hash the CID
BCryptHashData(hash_handle, cid_data, size_of_cid, 0);

// 3. Get the resulting hash
BCryptFinishHash(hash_handle, final_hash_buffer, ...);

This is what Windows 11 does instead:

// Get the IID and the CID
LPWSTR iid_data = get_iid();
LPWSTR cid_data = get_cid();

// Create a handle for the SHA256 algorithm
hash_handle = BCryptCreateHash(...);

// 1. Hash the **address** of the IID data buffer
BCryptHashData(hash_handle, &iid_data, size_of_iid, 0);

// 2. Hash the **address** of the CID data buffer
BCryptHashData(hash_handle, &cid_data, size_of_cid, 0);

// The resulting hash is now useless due to the memory locations always being different
BCryptFinishHash(hash_handle, final_hash_buffer, ...);

Even if they made this mistake once, it still would have singlehandedly killed the phone activation cache, and by extension, ZeroCID. The cache would be generated with a completely random hash, and on the next check, it would fail validation because the memory locations of these inputs are very volatile and bound to change each time.

As mentioned previously, ZeroCID depends on SPP reading the cache, validating it successfully, then skipping cryptographic validation. If you legitimately phone activate Windows, you would be mostly unaffected by this bug. This is because, even though the cache would always fail to pass the hash checks, since the input IID and CID are actually valid, SPP can simply perform the cryptographic revalidations necessary every single time without issue.

Of course, this is inefficient. But, as we know from Windows 11, Microsoft doesn't care much about optimizing their OS anymore. If it isn't a massive problem, it's not important enough to be fixed.

Before the release of our workaround method (dubbed StaticCID), we attempted to report this bug to Microsoft and bring it to their attention using the Feedback Hub, where your filed issue will have a very slim chance to be seen by anyone who can fix the bug until your post gets a large amount of upvotes. We sought other possible avenues to get someone to remove the damn &'s from the code, with no luck.

Really?​

Now, you might ask a reasonable question: "Why?". To be perfectly candid, I am not really sure.

Compared to the Windows 10 version of sppobjs.dll (the SPP "plugin" that performs this crypto check and writes the cache), it seems like the changes made to the now-problematic function was part of an effort, possibly by a single engineer, to transition this part of the code from using SPP's internal hashing implementations to using the external, Microsoft-made library called Bcrypt instead:

It's not clear why this "refactoring" was done, considering that this code had otherwise been untouched for more than a decade. Maybe the goal was to "optimize" this hash check in some way? In the era of modern CPUs, this makes little sense. To simplify the code? Maybe. But, as I said, this code had been untouched for a decade. This seems like changing things just for the sake of changing things.

A change like this should have been carefully reviewed. Clearly, it wasn't.

The Windows Git repository has thousands of branches, and changes get reverse-integrated into different branches, slowly making their way down to whatever is the release branch. This bug got past the initial code review, made its way from the Windows Insider Canary channel, to the Dev channel, to the beta channel (already making the change very likely to reach stable builds), then it was finally shipped with the June cumulative updates.

This bug slipped past at least 4 branches, completely unacknowledged, leaving us hopeless that Microsoft would do anything to fix this slip up.

And yes, we kept checking if Microsoft used their chance to notice the bug or not after every major build.

Turning the Tables​

Many of you may have read our TSforge blog from a few months ago, where we explained the process of creating the exploit. What wasn't described there was how we became aware of yet another method during development (approximately November 2024), which ultimately didn't end up being shipped with the final product due to fears of potential instability. After we became aware of the patch, we quickly went back to take another look at this method and start testing it further.

The method is quite interesting. Effectively, it mimics real phone activation as closely as possible while still managing to activate Windows for free. How, exactly? Let's explain.

We can start by taking a look at the SppPkeyPhoneActivationData block in the trusted store for the currently installed license to see what it consists of:

The information located in this block is what SPP uses during phone activation, and it's always written when a product key is being installed. This block contains information about said product key, namely:

• The group ID.
• The serial number.
• The "security" value.

What these values represent isn't important, what is important is that, in theory, this is all the information we need to successfully phone activate Windows! We can simply rip these values out of a genuine, working key and manually insert this information into the trusted store.

After doing the above, SPP will generate an IID based on data ripped from a genuine product key, rather than data from the generic product key that Windows comes with by default. This means that Microsoft will allow us to use our newly obtained, activatable IID to get a CID, allowing us to phone activate Windows for free.

At first glance, the non-trivial part of this is getting the CID autonomously. Obviously, it is far from ideal to force our users to call Microsoft on the phone and provide them with the IID manually, so we needed a better way.

Luckily, a Microsoft tool already exists called the Volume Activation Management Tool (VAMT), which has functionality for "proxy activating" Windows systems.

Proxy activation essentially performs the equivalent of phone activation in a way which allows for activating many client computers isolated from the outer internet, while avoiding having to call any phone numbers. A master "VAMT Host" computer, which does have internet access, acquires the CID online from an online endpoint and applies it to the client computers to activate them.

Some people have reverse-engineered how VAMT does this, and there's a really nice tool called ActivationWs which uses the same endpoints that VAMT uses to acquire the CID. StaticCID uses this tool to get the CID, then it deposits the CID, successfully pulling off a weird, but effective mix of phone and online activation.

Quality is Job None​

The new StaticCID method is now introduced into MAS and is working flawlessly. Previously, MAS only offered ZeroCID, with no option to use anything else. This was initially done due to ZeroCID being powerful enough to overshadow everything else made possible by the discovery of TSforge. Now, we are being more cautious due to Microsoft seemingly messing up even the oldest parts of the codebase without reason and have made 3 methods accessible instead of only one: StaticCID, ZeroCID and the previously-mentioned KMS4k.

The script automatically chooses which method is best for the current OS, while also allowing the user to manually specify which one they prefer. The script automatically chooses StaticCID as the default option on Windows 10 as well, due to concerns about the bug being backported to older Windows versions. We've observed Microsoft do this a few times before, even though Windows 10 isn't supposed to get new feature updates anymore, so it feels like a worthwhile precaution.

This incident suggests a troubling trend in Microsoft's development and code quality assurance pipeline. Only time will tell what else they'll inadvertently break and fail to fix. However, we will continue to adapt to these changes and deliver the best experience possible to our users, regardless of what Microsoft does next.

Introduction​

2025 marks nearly 20 years since the introduction of Windows' current DRM system, the Software Protection Platform (SPP). With it serving as the primary gateway to activation since early in Windows Vista's development, many have come up with clever ways of tricking it, from resetting grace period timers to emulating KMS servers to hooking bootloaders. While all of these systems abuse various activation methods, there has never been an exploit that directly attacked SPP itself... until now.

In this blogpost, we introduce TSforge, one of our most powerful activation exploits ever. Capable of activating every edition of every version of Windows since Windows 7, as well as every Windows addon and Office version since Office 2013, TSforge is both the most complex and most wide-reaching exploit we've implemented in MAS to date, rivaled only by our ill-fated Keyhole exploit. Aside from discussing how TSforge works, I'll also be discussing the wild path we took to discover and understand it, as well as some of the fun things we did with it along the way.

SPP​

SPP is a very complex system with several moving parts involved. To keep things simple, we'll only focus on the parts relevant to this exploit:

• sppsvc.exe/slsvc.exe - The primary usermode service for SPP, responsible for managing licenses and activation statuses
• spsys.sys - (Windows Vista/7 only) Responsible for storing sensitive activation information, merged into sppsvc since Windows 8
• sppobjs.dll - A plugin library containing most of the logic for product key and confirmation ID validation

CID Trick​

Our first hint of a universal SPP exploit was in 2023, with the discovery of a method we called the "CID trick", which allowed us to deposit fake confirmation IDs.

Confirmation IDs (CIDs) are numeric values used for activating Windows by phone, either through a dialog or with the slmgr /atp command. Because phone activation can be done without being connected to any network, all Windows editions and addons have at least one licensing channel that can be phone-activated, including otherwise uncrackable products like KMS servers and ESU addons.

Recognizing this, asdcorp decided to investigate how CID validation worked internally. After doing a simple in-memory patch to make any provided CID valid, they noticed it had some odd effects:

As shown in the video, patching the CID validation code in sppobjs.dll allowed us to use a CID made of all zeroes for activation. Crucially though, this activation remained even after clearing the patch by restarting sppsvc. To us, this suggested something very important: whatever data SPP saves to remember that it's activated is never validated after being written.

This was a very exciting discovery for us, as it meant that if we could write this same data, we could easily activate any copy of Windows without needing to use debuggers or exploit kernel drivers. More importantly for me, it also meant that this method could possibly be extended to work on older versions like Windows 7 and 8, where patching SPP code at runtime is much more difficult.

In order make this a viable method, though, we needed to answer these questions:

• Where is activation data being written?
• What data is written during the CID trick that causes activation?
• How is this data encoded?

Initial Work​

From prior investigations, we had a partial answer to the first question. Observing sppsvc using Process Monitor, we could see exactly where it was storing activation data:

On Windows 8.1 and 10, we observed that data is mainly stored in the following locations:

• C:\Windows\System32\spp\store\2.0\data.dat
• C:\Windows\System32\spp\store\2.0\tokens.dat
• HKEY_LOCAL_MACHINE\SYSTEM\WPA

Windows 8 is almost identical, except that the .dat files are stored under C:\Windows\System32\spp\store.

Windows 7, however, is a very different story:

Here, I saw references to the following locations:

• C:\Windows\System32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-0.C7483456-A289-439d-8115-601632D005A0
• C:\Windows\System32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-1.C7483456-A289-439d-8115-601632D005A0
• C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat
• HKEY_LOCAL_MACHINE\SYSTEM\WPA

More strangely, though, I found that sppsvc wouldn't write to either of the "7B296..." files or WPA registry keys directly. Instead, it would use the DeviceIoControl method to call a driver known as spsys.sys. This driver would then handle writing to "7B296..." files and WPA registry keys.

In comparing these files and registry keys, I saw quite a few similarities. The tokens.dat files were mostly uninteresting at first, since across all versions, these files seemed to just hold the contents of the XML licenses in a similarly named folder: C:\Windows\System32\spp\tokens.

The "7B296..." and data.dat files seemed to serve similar roles, as these files were not only encrypted, but they seemed to have some kind of hash or signature included as well. Corrupting or deleting these files would uninstall all installed product keys and reset all other activation data (rearm counts, KMS client counts, etc.). On Windows 7, it would also show this lovely error message:

Setting aside the question of how I can't be authorized to make changes to my own computer, after installing a product key, I get a notification for "tampering with the trusted store" across several versions:

Putting all this together, it would seem like the "7B296..." files and data.dat both serve as storage for important activation data, and they seem to be referred to internally as the "trusted store".

A similar process of brute-force tampering with the WPA registry keys showed that they were somehow linked with the trusted store. New keys with seemingly encrypted data were added under HKEY_LOCAL_MACHINE\SYSTEM\WPA periodically, as well as after significant licensing changes. Additionally, thanks to the NtLockProductActivationKeys function, these keys were entirely read-only and unable to be deleted, unless you messed with them from a Windows PE environment. Tampering with or deleting these keys caused similar "license tampering" errors to appear, but if we copied these keys along with trusted store files from one installation to another, sppsvc didn't seem to complain about tampering anymore.

From all of this work, we learned the following things:

• Critical activation data like product keys and rearm counts are stored in something known as the "trusted store"
• The trusted store's data is held in encrypted files
• This data is somehow linked with seemingly encrypted registry keys under HKLM\SYSTEM\WPA

Unfortunately, we didn't know much more than this for quite a long time. My work on deobfuscating both older and newer versions of sppsvc helped us in confirming some of our theories, but without an understanding of spsys.sys, they didn't contribute much. In the meantime, we built an automated version of the CID trick, using a custom kernel driver to patch sppsvc without adjusting its protected process status, which helped greatly with testing CID trick.

Aside from this, though, we mostly shelved this work in favor of investigating CLiP, which seemed to have more promising avenues for exploitation.

When It Leaks, It Floods​

Although we focus heavily on Windows piracy, many of us MASSGRAVE members are also interested in its development history, or more specifically, its various pre-release beta builds. Studying and messing with these builds is not only fun as a novelty, but the artifacts that get left in during development can help us learn a lot about how Windows works.

While discussing activation mechanisms of recently leaked Windows 8 builds with some beta conoisseurs, I was casually blindsided with a couple major reveals:

Although build 7792 and build 7850 were on the path to Windows 8 development, their build numbers were close enough to Windows 7 (build 7600) that I was hopeful for some new information on spsys. Indeed, within a symbol archive for build 7850, I found symbols for spsys, along with the rest of the activation subsystem.

Build 7792 also had a version of spsys that was entirely unobfuscated, just as advertised, but with no symbols. Build 7850's spsys, on the other hand, had full symbols along with full obfuscation. While I wasn't able to have my cake and eat it too, this pairing was still an incredibly lucky finding, so I decided to use it to figure out how the trusted store works.

Spells and Curses​

As usual with lucky breaks, this one came with strings attached. The biggest one was that, unlike with any other normal Windows build, kernel debugging with WinDBG didn't work at all on build 7792, as this was one of the earliest ARM ports of Windows.

So, although I had a completely deobfuscated copy of spsys without any annoying anti-debug features, I had very few options to actually debug it. Since this build was being emulated in QEMU, I still had the option of using its built-in GDB debugging server, but this would be very difficult to use, as I would have to manually locate the kernel and drivers in memory to do anything useful. Luckily, I was able to get in touch with Rairii, who was more familiar with this debugging method thanks to his work on emulating early Windows on ARM.

Unfortunately, I knew little about QEMU OS debugging, or ARM, or very low-level Windows internals, so his advice was a bit difficult to follow at first...

Compounding the problem was my choice to write custom tooling for this project, using a GDB client library to control QEMU and automatically break whenever spsys loaded. Much like most of my attempts at custom tooling, this ended up being a gigantic waste of time that ultimately didn't even work in the end, not least due to my inexperience with GDB in general. After wasting even more time trying to add Windows support to GDB through its Python API, I ended up biting the bullet and choosing the devil I knew, the IDA Pro debugger.

Yes, it's the least "appropriate" choice for debugging a kernel or debugging QEMU (or really anything at all), but what was more important to me was that I'm familiar with it. Using the various kernel structs I grabbed and modified from build 7915's symbol set, I was able to crap out a script that would breakpoint on various kernel functions and grab important data, like the kernel base address and list of loaded kernel modules. By programmatically breaking on IopLoadDriver, I could even automatically update the module list as each driver was loaded.

However, even with this monitoring system, I still couldn't catch the moment that spsys.sys loaded. It was only after checking the code for its loader, spldr.sys, that I spotted an interesting call to ZwSetSystemInformation:

Referencing Geoff Chappell's table, I saw that this corresponded to SystemLoadGdiDriverInSystemSpace, which, of course, has it's own branch in the kernel code that can load drivers without invoking IopLoadDriver.

After breaking at this branch as well, I could finally catch spsys.sys as soon as it loaded!

All this work, mind you, ended up implementing what would've been just sxe ld spsys if WinDBG worked. Regardless, I was now able to catch and debug build 7792's spsys right as it loaded, without the annoying obfuscation and anti-debug in the way.

Speaking of obfuscation, I still needed to unpack build 7850's spsys to make any sense of it. Fortunately, this was much easier, since I could search for where calls to encrypted functions are made.

Then, I just had to break at these calls in the kernel debugger and dump the driver from memory, and I got all of the the code decrypted fairly easily. From here, it was just a long process of transferring symbols by eye, and I was finally at square one.

Progress At Last​

With all of the functions labeled, I noticed an interesting pattern in the code that generates the trusted store file, which seems to be called the "physical store". Rather than the typical approach of storing encrypted data in a separate buffer, Microsoft seemed to opt for doing their encryption in-place.

This probably prevents some kind of side-channel attack, but more importantly, it means that I can "decrypt" the physical store by simply skipping this call in the debugger and letting spsys write the un-encrypted contents to the disk. And so I did:

asdcorp and abbodi1406 immediately went to work, figuring out the data format and what kind of data is stored within. Meanwhile, I was focused on replicating this trick on Windows 10, where analysis would be far easier, not least due to having an actual debugger (x64dbg) available. Conveniently, the function HIDHash had some very unique constants in it:

Searching for these constants in Windows 10's sppsvc led me to the same function in sppsvc:

As I found out, most of spsys's code ended up being included in sppsvc on Windows 10. Comparing these codebases, I found all of the encryption, decryption, signature check, and hash check routines. Patching all of these routines out in the debugger, we could get sppsvc to not only decrypt its data.dat for us, but also to load and accept any modifications we made in it.

In the process of testing these patches, we ended up finding the long-lost product key for Redpill, a feature lockout system for beta releases of Windows 8.

With some experimentation and a bit of assistance from me, asdcorp managed to reproduce the CID trick, but this time without patching the CID verification routine.

From here, asdcorp and Lyssa figured out and tested even more exploits, including a method to KMS-activate offline for over 4000 years.

Although these results marked significant progress, we still needed to use a debugger to test these methods, since we had no way to decrypt and re-encrypt the physical store by ourselves. So, my next task was to figure out how to do just that.

Private Key Derivation​

I knew from looking at spsys that the only real key I needed to derive was an RSA key, which encrypts an AES key that encrypts the physical store data. I also knew from tests conducted with asdcorp that there were only two such keys: one for production/official beta versions and one for internal testing/Windows Insider versions. In the absence of raw key data, we found this out with a highly advanced method: copying physical store files, editing its version, and waiting for sppsvc to crash horrifically, signaling that it could decrypt but not parse the swapped file.

Examining the RSA decryption routine, called SpModExpPrv, I found a interpreter for a bytecode system known as ExecCodes. With a lot of drudgery and regexes, I was able to write a simulator of this system in Python.

Observing the output of this simulation, I realized that all of this obfuscation covered up a technique I had vaguely heard of before, known as addition-chain exponentiation. With a bit of thinking, I realized that I could just track and dump the inputs and outputs of each modular multiplication and use this to derive the private key. All it took was x64dbg logging and a few more lines of python:

And at last, I had the complete production key for all of SPP, from Windows Vista to Windows 11.

Deriving the test key took a little while longer, due to some weird differences in how the modular multiplications were implemented, but eventually, we had every SPP private key we needed.

Nailing The Coffin​

With the private key in hand, we were able to activate almost any edition we wanted with ease. There was still one bit of trouble, though, and that was in obtaining generic keys to enable activation.

On Windows 8 and up, it's rather trivial to generate generic keys for any channel of any edition you wanted. However, Windows 7 and CSVLKs (KMS host keys) up to Server 2022 used PKEY2005, a much more complicated encoding system that needed private keys to generate even generic keys. Since I didn't have any cryptographic tricks left up my sleeve, we decided the best way through this problem was around.

Within the physical store are large blobs for each product key, containing various pre-computed information, such as the product IDs and phone activation data. Additionally, we found that the token store (tokens.dat) also contains metadata tying product keys to the current edition of Windows. Therefore, we figured that simply replicating this data was enough to trick Windows into thinking a key was installed, and for once, we were right.

In the meantime, while developing a programmatic method for the new CID trick, which we now called ZeroCID, we were having trouble with the HWID data we needed to write into the physical store. Originally, we tried using a C# port of GatherOsState's HWID derivation, but this ended up failing to validate in some rare cases. Since we had few options to debug or fix this port, asdcorp decided to create an HWID value that would apply to all hardware, and yet again, it worked perfectly, even allowing transfer of activation between machines.

With the HWID validation and PKEY2005 defeated, we had now almost entirely defeated SPP's offline protections.

Closing Thoughts​

Even with the amount of damage we were able to do to SPP with a debugger and a hex editor, I still think it's a rather advanced and well-built DRM system. Its internals certainly improve upon those of Windows XP's DRM, which, despite whatever some might tell you, was rather poorly designed. It also manages to defend itself fairly well against the most common attacks, such as resetting evaluation timers by swapping physical store files. Additionally, there are still parts of SPP that we haven't managed to crack, like the signed XML licenses used to define its behavior. After all, it's not like there's another trivial patch that can bypass their signature checks...

Credits​

Core Research and Development​

• WitherOrNot - Lead tool development, reverse engineering, testing
• asdcorp - Initial demonstrations, reverse engineering, tool development, testing
• abbodi1406 - Reverse engineering, development, testing
• Lyssa - Reverse engineering, tool development, testing

Other Contributions​

• May - Code formatting, build setup

Special Thanks​

• BetaWiki - Documenting leaked beta builds used for reverse engineering
• Rairii - Assistance with initial reverse engineering efforts
• Microsoft - A fun challenge

Introduction​

In our ongoing work to bypass Windows licensing checks, we occasionally stumble upon bugs that we choose to keep secret. This decision allows us to preserve potential future activation methods by avoiding bug fixes, while also giving us valuable tools for testing or developing new methods.

One such discovery, which we've named "Keyhole", turned out to be a highly effective DRM bypass. It gave users the ability to license any Microsoft Store app or any modern Windows edition with ease.

Following the disclosure of CVE-2024-38184 by Cisco TALOS, we have decided to share our findings on Keyhole, which we independently uncovered around the same time it was reported to Microsoft.

CLiP​

To understand this exploit, we must first understand CLiP, the Client Licensing Platform. This system was introduced with Windows 10, primarily as a way to implement DRM for Microsoft Store apps, and integrated with Windows activation, allowing users to buy digital licenses for Windows on the Microsoft Store.

CLiP is comprised of a few different main binaries within Windows:

• clipup.exe - Migrates (converts) Windows 8 store licenses, genuine tickets, and product keys to digital licenses
• clipsvc.dll - User-mode service responsible for managing app licenses
• clipc.dll - API used by applications to interact with CLiP
• clipwinrt.dll - Similar to clipc.dll but for UWP applications utilizing Windows Runtime.
• clipsp.sys - Kernel-mode driver responsible for verifying licenses

Whenever a CLiP-licensed app is installed, a signed XML file containing the license information is sent to clipsvc.dll; once the XML signature is verified, the XML data is stored in ClipSVC's "token store" at %PROGRAMDATA%\Microsoft\Windows\ClipSVC\tokens.dat.

The signed license block is then extracted from the SPLicenseBlock tag and sent to clipsp.sys for verification. After verification, the license block is deposited in the CLiP license store at HKLM\SYSTEM\CurrentControlSet\Control\{7746D80F-97E0-4E26-9543-26B41FC22F79}. From there, clipsp.sys can then re-validate the license in the future if an app requests it using the CLiP API.

As designed, this system forms a rather strong chain-of-trust that transmits only signed data from usermode applications all the way to the kernel, making it seemingly difficult to tamper with. As we will see soon, however, this is not at all the case.

A Little Trolling​

So far, one binary failed to receive any mention: clipup.exe. This is because it isn't notable when talking about Keyhole itself. However, it holds the key to messing with CLiP:

Yes, literally. A valid ECDSA key to sign XML licenses is stored in unobfuscated form, allowing anyone to very easily sign or resign XML licenses. This key is normally meant to sign temporary licenses sent to the Microsoft store to get digital licenses, but ClipSvc will happily accept it for app licenses as well.

This allows us to bypass ClipSvc's gatekeeping and effectively send any license blocks we want straight to ClipSp. With this, we entirely bypass the usermode level of the chain-of-trust, and now all that's left is to try and trick ClipSp.

Unpacking ClipSp​

ClipSp, from our analysis, is not a very well-written driver. It's full of copy-pasted code (from where will be shown soon), and seems to be rife with odd choices and compromises. In other words, it's a perfect environment for someone looking for a bypass. There's only one big issue: most of the interesting driver code is hidden using Microsoft's proprietary obfuscator, known as Warbird. In order to find and understand it, we need to "unpack" it, a.k.a. undoing the obfuscation. Luckily, this is rather straightforward thanks to some symbols for clipsp.sys that were available on Microsoft's servers.

Similar to how Warbird works in user-mode programs, ClipSp wraps any calls to obfuscated code with an decryption and encryption function, as shown below:

So, if we can manually run these decryption functions, we could access all of the hidden code. Luckily, this is quite simple to do based on a method by KiFilterFiberContext, and with it, we are now able to finally find some bugs.

License Blocks​

License blocks, mentioned previously, are what actually hold the important license information in CLiP. Their format is well-documented and can store many kinds of data, so we figured they were a good place to start looking for bugs.

License blocks hold their data in a tag-length-value (TLV) format, where several smaller blocks are stored together with each holding values for their data type, the length of their data, and the data itself. For example, the TLV block highlighted below has a type of 0xC9 (License Information), a length of 0xA (10 bytes), and 10 bytes of data.

At the very end of a license block, there will always be a signature block, with a type of 0xCC. This block holds the signature of all the data before it, as well as indicating which key it was signed with. And of course, since it sits after all the data being signed, there's no way to alter any of it... right?

A Lot of Trolling​

In the middle of experimenting with this data format, one of our members, May, had a very simple question. If the signature block signs all the data before it, what happens to the data put after it?

Above, you can see a license block for Minecraft Bedrock edition with some new data placed after it (highlighted), containing blocks copied from a Windows license. What happens if we try to install such a license?

As it turns out, data after the signature block isnt checked at all... and it can even override data that came before it. Whenever two blocks of the same type are stored together, the last one overrides all the others before it. So, if we want to change any license data, we can just make a block for it and put it after the signature block!

This method lets us make licenses for anything sold on the Microsoft Store, including Windows, from any other Microsoft Store license. And since there are so many free apps with licenses, we now had the ability to make as many as we wanted for whatever we wanted. This bug essentially punched a hole straight through CLiP's DRM, so we decided to name it "Keyhole".

There is only one catch: licenses that are bound to a specific device, known as "device-locked" licenses, cannot be made from device-unlocked licenses. Since Windows digital licenses are device-locked, this meant that we needed to make them from device-locked app licenses. Luckily, many apps, including games like Roblox fit this criteria.

Trolling Tutorial​

The steps to make any Windows license you want were now dead simple. First, install an app with a device-locked license, like Roblox.

Then, using a HTTPS traffic capture tool like Fiddler, intercept the license that comes from https://licensing.mp.microsoft.com/v7.0/licenses/content.

Decode the license, then extract its license block.

Now, add whatever new data you need to make a new license.

Then, we just package our license block into a new XML file, sign the XML, and copy it into the folder C:\ProgramData\Microsoft\Windows\ClipSVC\Install\Migration.

Finally, we get ClipSvc to install our license, either by restarting it, or with the command clipup -p.

When we check our activation status, Windows is now permanently activated.

With this, we were able to do things that were previously impossible, like activating Enterprise LTSC with a digital license, or even activating a legitimate KMS server with a generic key:

From here, it's pretty easy to see that this simple bug completely annihilates CLiP's DRM system.

Buzzkill​

Having found this bug, we were quite happy that CLiP was now effectively dead. This happiness didn't last very long, though, as we recently found a vulnerability report from Cisco TALOS that reported this exact bug. It was reported to Microsoft on April 8, right around when we first found it.

This raises a question though: why was a DRM bug reported as a security vulnerability? At first, CLiP licenses don't seem to have anything to do with exploitation, which caused us to think the bug had been reported for no reason other than to fix Microsoft's DRM. However, Keyhole can be used as an entry point for more serious bugs in ClipSp, which prompted TALOS to make it part of their disclosure.

As for the fix itself, it's rather straightforward. As shown below, the current license block parser code immediately exits after encountering a signature block. This prevents it from processing blocks after the signature, completely patching Keyhole.

Giving Season​

After mourning the loss of our beloved exploit, we decided that it would only be fair to publicize our own discoveries on CLiP. So, we've released the code to generate Keyhole licenses and our collection of CLiP binaries with symbols for easier analysis. We invite you to go forth and discover more funny things in CLiP! (and report them to us instead of MS)

And now, for something different​

I mentioned that ClipSp's buggy code was copy-pasted, but from where? Well, the "SP" part just happens to reference a certain Microsoft game console: the Xbox One!

The Xbox One contains a chip known as the SP, or "secure processor", based on the TPMs in modern PCs. The main job of the SP is to enforce code signing, but it also handles license verification. During our research on Keyhole, we found many associations between CLiP and the Xbox One, and began wondering how they were actually related. While looking through some leaked source code, we stumbled upon this:

Well, this looks oddly familiar...

And there's the same bug that's in CLiP, but in Xbox code. In fact, we weren't too surprised to find this, as we found that almost all of CLiP, from the XML format of the licenses to the TLV-based license blocks, is mostly copy-pasted straight from the Xbox One's DRM system.

So, to those with a console that's been collaterally damaged, I wonder what happens if you mess with those funny-looking XML files in S:\clip ;)

Credits​

The research covered in this blogpost was made possible by the following people/groups:

• May - Initial discovery, testing, reverse engineering
• asdcorp - Testing, reverse engineering
• WitherOrNot - Tool development, testing, reverse engineering, bugfix analysis
• emoose, LukeFZ - License Block format documentation
• KiFilterFiberContext - ClipSp unpacking
• Phillippe Laulheret, Cisco TALOS - Inspiring this publication, clearing up misconceptions
• Rairii - Additional info