Exploring Legacy UWP Titles: Hooking Undocumented WinRT Store APIs, COD Points Ingestion & UWP Dumper Injection
Reverse engineering legacy Windows 10 UWP games (Call of Duty: Infinite Warfare): weaponizing UWP Dumper suspended process lifecycle for AppContainer DLL injection, VMT hooking undocumented IStoreContextServer COM interface, intercepting COD Points package requests, and analyzing why client-side Server-to-Server DLC spoofing fails.
An engineering case study on reverse engineering legacy Windows 10 UWP games (Call of Duty: Infinite Warfare), weaponizing UWP Dumper's suspended process lifecycle for AppContainer DLL injection, VMT hooking the undocumented IStoreContextServer COM interface, and analyzing the cryptographic limits of client-side Server-to-Server entitlement spoofing.
1. Architectural Divergence: Legacy UWP (AppContainer) vs. Modern GDK
Modern PC releases on the Xbox App / Microsoft Store employ the Game Development Kit (GDK). In GDK games, the executable is essentially a standard Win32 binary (.exe) augmented with Microsoft Gaming Runtime services (XStore, XUser, XGameSave). Packaging itself is flexible—modern GDK titles can be delivered in .appx, .msixvc, or loose virtual disks—but they execute with standard Win32 process integrity and communicate through documented APIs like XStoreQueryGameLicenseAsync and XStoreQueryAssociatedProductsAsync.
In contrast, Legacy Windows 10 UWP titles (spanning from 2016 to 2019, including Call of Duty: Infinite Warfare, Modern Warfare Remastered UWP, Gears of War 4, and Halo 5: Forge) were built on pure Windows Runtime (WinRT) AppContainer sandboxes. Infinite Warfare, for instance, is packaged as a monolithic .appxbundle containing encrypted EFS virtual filesystems and enforcing strict capability manifests:
| Subsystem | Legacy UWP (Infinite Warfare) | Modern GDK (BOCW / MWIII) |
|---|---|---|
| Sandbox Model | AppContainer Isolation (S-1-15-2-1) |
Win32 Medium Integrity + Gaming Services |
| Packaging Target | Monolithic .appxbundle / Encrypted VFS |
.msixvc / .appx / Virtual Disk Mounting |
| Store Interface | Undocumented IStoreContextServer (COM) |
Documented XStore C/C++ SDK |
| Memory Isolation | Strict DACL, blocked Win32 IPC | Standard process security descriptors |
| Debugger Hooking | Denied PROCESS_ALL_ACCESS without SID |
Standard CreateRemoteThread / Detours |
Because Legacy UWP runs under an isolated AppContainer, traditional dynamic analysis tools fail outright: standard injection mechanisms are rejected by the Windows kernel security model, and loaded DLLs are blocked unless explicitly granted ALL APPLICATION PACKAGES access rights.
2. The Injection Vector: Repurposing UWP Dumper
To inject our research module (ZPGDK / client-iw7-store) into the live game, standard injection (OpenProcess + VirtualAllocEx + CreateRemoteThread) was insufficient because of access restrictions enforced on AppContainer processes.
Instead of writing a complex kernel driver or token impersonation service, we repurposed the suspended process lifecycle vector popularized by UWP Dumper (Woomer/UWP Dumper by Wunkolo and emoose):
[UWP Launcher]
│
▼
IPackageDebugSettings::EnableDebugging()
│ (Launches AppX package suspended with DebugToken)
▼
Target Game Process Spawned (SUSPENDED in AppContainer)
│
├── Original UWP Dumper Action: Dump decrypted memory to disk
│
└── Our Weaponized ZPGDK Action:
1. Adjust Security Descriptor (Add 'ALL APPLICATION PACKAGES' ACE)
2. QueueUserAPC / Remote Thread Injection of ZPGDK.dll
3. ResumeProcess() -> DllMain() executes before Game DRM activates
By intercepting the target process at the point of suspension, our DLL is injected directly into the game's virtual address space before any in-game anti-tamper or WinRT runtime initialization runs. Once mapped, DllMain delegates execution to a detached worker thread, ensuring the game's loader thread finishes without deadlocks:
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
if (ul_reason_for_call == DLL_PROCESS_ATTACH) {
client_module = hModule;
DisableThreadLibraryCalls(hModule);
HANDLE hThread = CreateThread(nullptr, 0, [](LPVOID) -> DWORD {
init(); // ZPGDK initialization routine
return 0;
}, nullptr, 0, nullptr);
if (hThread) CloseHandle(hThread);
}
return TRUE;
}
3. Dissecting the Undocumented IStoreContextServer
In WinRT, developers access in-app purchases and license checks using the high-level Windows.Services.Store.StoreContext class. However, windows.services.store.dll is merely a thin client wrapper. The actual license validation and catalog synchronization are delegated via local RPC/COM to an internal, undocumented system service interface: IStoreContextServer (managed by Windows.Services.Store.Internal.StoreContextServer).

To intercept this interface before the game executes its initial entitlement handshake, we hook RoGetActivationFactory and RoActivateInstance from api-ms-win-core-winrt-l1-1-0.dll:
// Hooking WinRT Core Activation
typedef HRESULT(__stdcall* RoGetActivationFactory_t)(HSTRING, REFIID, void**);
typedef HRESULT(__stdcall* RoActivateInstance_t)(HSTRING, IInspectable**);
utils::hook::detour ro_activate_instance_hook;
utils::hook::detour ro_get_activation_factory_hook;
When the game requests an activation factory for Windows.Services.Store.StoreContext, our detour intercepts the instance, creates a shadow Virtual Method Table (VMT), and redirects all internal COM method slots to custom analysis stubs.
4. VMT Hooking & Logging In-Game Purchases (COD Points)
With the shadow VTable in place, we mapped the virtual method dispatch offsets of IStoreContextServer:
Method[6]—GetCustomerCollectionsId: Requests signed authorization tokens representing the user's content entitlements.Method[7]—GetCustomerPurchaseId: Requests tokens authorizing consumable or digital purchases.Method[11]—GetAssociatedStoreProducts: Enumerates available catalog items (DLCs, add-ons, and consumable bundles).Method[14]—GetUserCollection: Checks user inventory for specific SKU identifiers.Method[20]—GetAppLicense: Queries the base game license parameters.
Real-Time Ingestion of COD Points Package IDs
When Call of Duty: Infinite Warfare loads the Quartermaster / Store menu, our logging pipeline intercepted consecutive calls to Method[11] querying store package IDs:
[WinRT] IStoreContextServer::Method[11] called! a2=00007FF7B4C02840, a3=0000000000000000
[WinRT] Enumerating Store Products for Parent: 9NBLGGH52PH9 (Base IW7)
[WinRT] Query Filter: "Consumable"
[WinRT] Found Target Product: COD Points (200 CP Bundle) -> SKU: 9NBLGGH52PD2
[WinRT] Found Target Product: COD Points (1100 CP Bundle) -> SKU: 9NBLGGH5393R
[WinRT] Found Target Product: COD Points (2400 CP Bundle) -> SKU: 9NBLGGH52PH9
Each parameter passed to these COM methods utilizes Windows HSTRING handles allocated on the caller's stack frame. We engineered dynamic stack-scanning logic to locate and inspect output pointers:
inline bool try_spoof_hstring_param(void* param, const std::wstring& json_val, const std::string& name, bool force = false) {
if (!param) return false;
HSTRING* out_hstr = (HSTRING*)param;
if (IsBadWritePtr(out_hstr, sizeof(HSTRING))) return false;
if (!is_stack_pointer(out_hstr)) return false;
if (force || *out_hstr == nullptr) {
HRESULT create_hr = WindowsCreateString(json_val.c_str(), (UINT32)json_val.length(), out_hstr);
LOG("WinRT", INFO, "Captured & Injected HSTRING parameter {}, hr: 0x{:08X}", name, (unsigned int)create_hr);
return true;
}
return false;
}
5. Client Spoofing vs. Server-to-Server Verification: Why Local Emulation Hits a Wall
To understand why local license spoofing behaves differently across Windows Store titles, we must differentiate between Client-Side (Local OS) checks and Server-to-Server cryptographic validation.
How ZPGDK Spoofs Modern GDK Titles (Call of Duty: WWII)
In modern GDK environments, ZPGDK has already demonstrated successful client-side DLC unlocking (as implemented in src/s2-store-dlc-unlocker-standalone for Call of Duty: WWII). In those titles:
- The game downloads all DLC assets (
.ffand.pakfiles in thezone/andvideo/directories) directly within the monolithic 100GB+ base package from the Microsoft Store. - The game calls
XPackageEnumeratePackagesfollowed byXPackageMountWithUiAsyncto mount small "activator" packages. - If the user lacks an official license, the OS service (
appxsvc/GamingServices) aborts mounting with error0x803F8001. - ZPGDK's Spoof Solution: We detour
XPackageMountWithUiAsyncandXPackageMountWithUiResult. Instead of dispatching the request to the OS, we immediately trigger the game's asynchronous completion callback with a synthetic mount handle and hookXPackageGetMountPathto return the root executable path. Because the game engine evaluates mount success locally, it reads the pre-installed archives without any external server validation.
The Server-to-Server Brick Wall in Infinite Warfare (IW7)
In Call of Duty: Infinite Warfare, however, attempting local memory spoofing for online entitlements (such as COD Points or server-authenticated DLC playlists) hits an insurmountable barrier: Server-to-Server Cryptographic Verification.

Unlike purely client-evaluated checks where patching a local boolean or redirecting a filesystem handle suffices, remote Server-to-Server validation offloads the decision completely:
- Signed Token Request: The game client calls
Method[6](GetCustomerCollectionsId) on theIStoreContextServerWinRT COM interface. The Windows Store service contacts Microsoft authentication servers and receives a cryptographically signed JSON Web Token (JWT). - Off-Client Forwarding: The game does not inspect or validate this token locally. Instead, it serializes the raw JWT into an encrypted RPC payload and transmits it over TLS to Activision / Demonware backend servers.
- Server-to-Server Validation: The Demonware server contacts Microsoft's Azure Store endpoint directly to fetch Microsoft's public RSA signing keys and cryptographically verify the token's digital signature and claims.
- Entitlement Decision: Only if Microsoft's digital signature is valid and the authenticated Xbox Live identity holds legitimate purchase records does the server authorize the client's DLC playlists or allocate COD Points.
Because the JWT is signed with Microsoft's private key, local memory modifications (such as injecting {"isActive": true} or crafting a synthetic HSTRING payload) are rejected upstream:
[Demonware] Ingested JWT payload from client
[Demonware] Verifying signature against MS Store Public Key via Server-to-Server...
[Demonware] ERROR: Signature verification failed (Invalid RSA PKCS#1 v1.5 padding)
[Demonware] Entitlement rejected. Client DLC flags set to 0.
Breaking the Barrier: Online-Fix, ReUWP & ZPGDK's Open-Source Objective
However, the store entitlement layer is not uniform across all titles, and breaking this barrier remains an active, evolving research frontier:
- Closed-Source Precedents (Online-Fix): Teams like Online-Fix have successfully bypassed store license barriers in legacy UWP titles such as Gears of War 4. However, these solutions remain strictly proprietary and closed-source, obscuring the internal WinRT mechanics behind compiled binaries and configuration hashes.
- Specialized Open-Source Emulation (ReUWP): Recently, OptiJuegos developed ReUWP for Minecraft Bedrock (during its pre-GDK UWP lifecycle). ReUWP proved that full store license emulation is feasible by stubbing store methods in memory. However, its implementation relies on game-specific hardcoded offsets tailored solely to Minecraft's binary layout.
- ZPGDK's Architectural Mission: The barrier we are actively working to dismantle with ZPGDK is decoupling store emulation from game-specific hacks. By reverse engineering and documenting the undocumented
IStoreContextServerCOM interfaces, VMT layouts, andRoGetActivationFactoryhooks directly, ZPGDK aims to provide a clean, open-source, and generic API documentation layer for legacy Windows Store titles—bringing full transparency to an architecture that closed-source loaders have hidden for years.
6. Summary & Technical Takeaways
- UWP Dumper as an Injection Tool: Repurposing
IPackageDebugSettingsallows arbitrary C++ instrumentation inside Windows 10 AppContainer sandboxes without triggering security violations. IStoreContextServerInterface: The core of Windows 10 UWP store communication is an unexported COM interface whose VTable can be dynamically detoured viaRoGetActivationFactoryinterception.- Server-to-Server vs. Client/GDK Mount Spoofing: While modern GDK titles (such as WWII / S2) can have their DLC mounted locally by short-circuiting
XPackageMountWithUiAsyncand redirecting mount paths, titles governed by Server-to-Server token validation (Demonware backend verifying Microsoft Store JWTs) reject forged client payloads upstream. - Democratizing UWP Research: Complete research source code, VMT hooks, and analysis tools are open-sourced in the ZPGDK research repository under
src/client-iw7-store.