Vanguard Reversed.

One protector, seven binaries

The suite is a single protection scheme applied per target. Three binaries carry the full stack (vgk.sys, vgc.exe, vgm.exe), one ships as a packed shell (vgrl.dll), three are plain (vgtray.exe, log-uploader.exe, uninstall.exe). Version 1.18.5.x, (C) 2019-2026 Riot Games, source tree vanguard-client, Jenkins release builds, DigiCert G4 chain.

Interface facts: vgc never opens a handle to the driver. It locates the vgk base via ZwQuerySystemInformation(SystemModuleInformation) and calls the export thunks Egg_0 (0x1400dd554) and Egg2_0 (0x1400dd818) directly. vgk holds no device object: zero IoCreateDevice imports, zero IOCTL surface. The NalDeviceControl / MAPMEM / MsIo / WinIo strings are blacklist scanner signatures for third-party drivers, not vgk handlers (4.7).

1.1Boot chain, install to kernel

1.2Communication matrix

1.3Kernel enforcement flow

Seven binaries, measured

Section layout and import counts read straight off the PE headers. Raw sizes are on-disk bytes; vsize is the mapped size. The three .riot1 sections are near-identical copies of one shared runtime blob.

2.1Protection classes

• Full stack (vgk, vgc, vgm): clean .text reduced to thin thunks whose real bodies JUMPOUT into .grfn1; unpacker stage in .stub0; function directory in .riot0; shared runtime in .riot1.
• Packer-only vgrl.dll is the extreme case: on disk, every section except the stubs is zero-filled. The entire original image is reconstructed at load time.
• Unprotected (vgtray, log-uploader, uninstall) carry no detection logic of their own, so shipping them plain costs nothing.
• Config lives in .toir dwords: byte 2 is the per-binary variant (07 vgc, 0b vgm, 01 log-uploader); bytes 4-7 differ between protected (22 01 02 00) and lightly protected (02 01 00 00) builds.
• All three protected binaries enter the shared runtime at the same PE entry offset: vgk rva 0x3dea13c, vgc 0x513d13c, vgm 0x140713c, each resolving to .riot1+0x3313C.

2.2Observations worth keeping

• One runtime blob serves three binaries: .riot1 raw sizes vgk 0x660600 / vgc 0x666091 / vgm 0x666000, a common core plus a per-binary tail.
• Import counts are meaningless as a difficulty signal: the protector replicates import resolution across 30-90 call sites per API inside .grfn1, so caller counts carry no semantic signal.
• .fptable appears in every userland binary; in vgrl it is the plain function-pointer cache left by the packer.
• vgtray's .rdata (3.4 MB) is larger than its code: the Pre-Check strings and D3D11 shader cache dominate.
• An analysis-time marker was found embedded in one build: the string https://i.imgur.com/KOiWz9K.png inside vgc's .rdata, an image URL with no loader reference. Treated as a developer artifact, not a signal path.
• _ENTROPY in vgk holds packer entropy metadata; its raw size (0x200) is far below its mapped size (0x1000).

Four layers between you and the code

One protector, applied per target. The layers are independent: the packer hides the image, control-flow flattening destroys structure, mixed boolean arithmetic hides predicates, and the runtime holds the keys to all of it. All four are broken in this analysis.

; .stub1+0x1C40 · key schedule, one round per 4-byte block
mov     eax, [rsi]           ; ciphertext block
xor     eax, 0x3F15A7       ; seed constant
rol     eax, 7
imul    eax, 0x6F4D9B1
xor     eax, edx              ; rolling state
mov     [rdi], eax          ; plaintext block
add     edx, 0x10             ; offset advance

3.1Layer map per binary

The kernel driver, laid open

71 MB on disk, 127 imports, 2 exports. The driver boots through its own protector runtime before any logic runs, exposes exactly one interface (two export functions, no device, no IOCTL), and every verdict it produces travels through computed dispatch that static call-graph analysis cannot see. All of it decoded below.

4.1Section layout

4.2Boot chain and the arming gate

DriverEntry is not in .text: the PE entry 0x143dea13c sits in .riot1 at the shared offset +0x3313C. The entry computes a status and either returns quietly or tail-jumps into a hidden second entry whose target is stored in a runtime slot that is zero on disk.

; PE entry 0x143dea13c (.riot1+0x3313C) - exact decode
push rbx/rcx/rdx/r8/r9; sub rsp,0x20
lea  rbx,[rip-0x8e]           ; cb = 0x143dea0c0 (callback block)
call sub_143DE1E27                ; runtime init thunk
test eax,eax          je  plain_ret    ; eax == 0
cmp  eax,0xD4494E49    je  plain_ret    ; "VGNOINIT" (0xD4494E494F4E4756)
; else: hidden second entry
rax = movsxd dword[cb+0x28]     ; -0xAD0C0 -> .riot0 base
rax = qword[rax+0x10]           ; slot = *(.riot0+0x10), ZERO on disk
ebx = dword[cb+0x5C]           ; 0x52F90 (verified on disk)
jmp  rax                          ; target = slot + 0x52F90

• The mov ebx load zero-extends over cb before add rax,rbx, so the target is slot + 0x52F90, not slot + cb + 0x52F90. Emulation-proven: slot 0 yields rax = 0x52F90 exactly.
• The armed slot value is cb itself (0x143dea0c0): target = cb + 0x52F90 = 0x143E3D050, the CFF continuation.
• The registrar 0x143dea190 stores cb into the slot: lea r8,[rip-0xdd]; call 0x143de1faf; if (rax) *(qword*)rax = r8. Arming the slot means storing cb. The registrar has zero static xrefs; it is reached only through computed directory dispatch.
• The magic is computed, not immediate: VGNOINIT materializes through an MBA imul-chain (first materialization rva 0x4179d36, spilled to 24 stack sites, final load rva 0x3e864fb). Only 2 immediate sites exist image-wide: a never-executed .grfn1 stub and the DriverEntry compare.

Arming protocol (emulation-proven)

4.3.riot0: function directory and integrity manifest

The section opens with a header (magic 0x5647020b, directory offset 0x128, config qword 0x6a72aebc at +0x20) and then the protector's own index of every protected function: 30,521 twelve-byte triples, perfectly monotonic, running from rva 0x1310 to 0x43eeebf. The third dword is a pointer, not a hash: for all 30,521 entries it lands inside a mapped section, and consecutive entries map to consecutive variable-length descriptor records that open with a 01 00 xx 00 header and carry a token stream of small integers. The runtime walks these records, hashing them with FNV-1a-64 to drive the CFF dispatch.

These counts are the protector's authoritative view and differ from IDA framing (which counts 32,410 .grfn1 functions): the directory merges fragments that IDA frames separately. At +0x59e2c, directly after the directory, vgk alone carries an integrity manifest: 11 fixed 0x78-byte slots, absent from vgc and vgm. Slot layout: +0x00 tag 0x10, +0x08 24-byte digest, +0x20 region rva, +0x24 region size, +0x34 tag 0x2005, +0x38 16-byte aux blob.

• Total covered: 0x3c02800 bytes = everything except .text, .riot1 and INIT.
• The 24-byte digests are not on-disk content hashes: the two all-zero regions carry nonzero digests, and sha1/256/512, md5, blake2s/b, sha3, crc32, adler32, fnv, xor/sum batteries all miss. Expected values of runtime-initialized content or per-region key material.
• No plaintext reference to the manifest offset exists anywhere in the image; the reader is computed dispatch. The hub decompiles point at the family: FNV-1a-64 prime 0x100000001B3 appears 93-129 times per hub, with strength-reduced multiples (2x 0x20000000366, 3x 0x30000000519, 4x 0x400000006CC), so the digests and dispatch keys are FNV-family fingerprints.
• A 'vgk.sys' string sits at 0x143d967fc, table-driven with 30,803 xrefs into .riot1.

4.4The Egg interface: two exports, nothing else

• No device object exists. vgk imports no IoCreateDevice (only IoCreateFileEx), so there is no IOCTL surface at all. The two exports are the only entry.
• The export directory points into .riot1: AddressOfFunctions entries 0x1443eeed0 / 0x1443eeee0 sit 0x11 bytes past the end of the on-disk function directory. The exported entry points are runtime-resolved slots, not static code addresses.
• Egg_0: thunk 0x1400dd554 → body 0x140271833 → resolver pattern call sub_1401F818B; jmp rax. Egg2_0: thunk 0x1400dd818 → 0x140213c89 → call sub_140317F12; jmp rax. Both bodies JUMPOUT into .grfn1; the resolvers are themselves CFF.
• There is no static command table. The Egg_0 body is a CFF fragment web of 420 reachable fragments; dispatch lives in MBA dispatcher hubs that refuse decompilation (fragments over 9,000 chars). The resolver decodes as push rax; lea/lea; jmp through junk-obfuscated constants: the resolver is the dispatcher entry, continuation = f(registers, runtime state). Opcode encoding is recoverable only dynamically.
• Entry is unauthenticated in shape: any kernel-mode caller that finds the vgk base can invoke the exports. vgc locates the base via ZwQuerySystemInformation(SystemModuleInformation); notably vgc itself carries no plaintext Egg-RVA constants (a dword scan for 0xdd554/0xdd818 finds zero hits, the marshalling lives in its own CFF web, and its ZwQuerySystemInformation import has zero direct xrefs through XOR-indirection).

Primitive surface reachable from Egg_0 (fragment-BFS)

4.5Kill path: verdict encoding

The verdict channel is invisible to static call-graph analysis and there is no constants table to patch. Adjacent to the kill sites sit the tamper panics: KeBugCheckEx at 46 sites.

4.6Import census

125 of 127 imports referenced. Caller distribution is uniform, almost every import at 30-90 .grfn1 call sites: an artifact of the flattener replicating resolver stubs, so caller counts do not rank importance.

Only .stub0 imports ExAcquire/ReleasePushLockExclusiveEx: runtime locking during unpack. And the clean .text scanner wrapper sub_14000E6C8 obfuscates its own imports the same way .grfn1 does, through XOR-indexed indirection: fn = qword_140135C80 ^ qword_140135C88[(u8)byte_140135C78].

4.7Embedded cheat-driver blacklist

Three independent clusters in .rdata (A at 0x1400f8xxx, B at 0x1400f8fxx, C at 0x1400f9fxx), each a table of string-descriptor entries (ptr + flags) for known abusable kernel drivers. Three clusters = three scanner passes matching these literals inside loaded driver images: match on embedded strings of the offending driver, not file names.

Cluster reference map: 0x1400f92d0 is referenced from .grfn1 (0x1403096cd, 0x14044c0f6) and from the .stub0 unpacker region (0x14015118b, 0x140151ac7); 0x1400f9f50 from .stub0 (0x140151668); 0x1400fa300 from three .grfn1 sites (0x140216939, 0x140303ffe, 0x14039c475, 0x1403abaae). Descriptor entries in the control blocks at 0x1400f85d0+ are referenced from the WPP registration at 0x14014df6a in INIT. This is the kernel-side cheat-driver blacklist, not an IOCTL dispatch: vgk has no device object.

The in-kernel trust boundary

One clean .text function at 0x1400a3c78 owns the driver's cryptography: the only caller of BCryptVerifySignature in the binary. It authenticates modules and handshake blobs in-kernel without touching wintrust, against a table of pinned keys baked into .data.

5.1Accepted signature algorithms

All four OID literals are also referenced from .grfn1 code: the flattened payload checks algorithm ids itself, in parallel with the clean verifier.

5.2Digest path

Callers of the verifier: 0x140328a18 (.grfn1, call site 0x140328a95) and 0x143d3e40c (.riot0). BCryptImportKeyPair and BCryptVerifySignature each have exactly one .text caller: this function.

5.3The pinned key table

Stride 0x258 per entry, base 0x140105260 in .data, exponent hardcoded 65537. The table itself is under digest in manifest slot 8.

5.4Inline crypto in the runtime

The kernel does not only call BCrypt. .riot1 carries its own primitives, all recovered: an RSA key generator at sub_143DB70D7 (gcd coprimality loops of e against p-1 / q-1, 128-bit phi = (p-1)*(q-1)), two SHA-256 cores (initial state 0x6A09E667, at 0x143DCF277 and 0x143E2C9E5), and CRC32 (polynomial 0xEDB88320 at 0x143DDA3D4). Boot-time session keys come out of this machinery. The same cores serve the userland binaries: .riot1 is one blob, 95.7% byte-identical across vgk / vgc / vgm, common prefix 0x330C8 ending 0x74 bytes before the shared PE entry.

The launcher, unpacked and whole

On disk, vgrl.dll is a 3.2 MB shell: every section except the packer stubs is zero-filled. Fully unpacked (wine loader, ASLR cleared, dump at preferred base 0x180000000), it is the suite's launcher library in plain MSVC C++: service lifecycle, process spawning, an in-host anti-injection firewall, and a pre-flight probe battery. Ten ordinal exports, 1337 through 1346.

6.1Three tiers of code

Dynamic-import census (tier 2, all 31 APIs recovered)

Method: run the loader under wine 11.15, record the module bases the real loader chose, invert the arithmetic the stubs use to compute their continuation targets, and every site resolves to an exact named API. The 19 imports the stub declares openly were never hidden; the 31 computed ones were.

6.2DllMain: registering the anti-injection firewall

; two-phase hook engine, live-decoded under wine
; phase 1 - DllMain registers, does NOT patch:
heap  = call HeapCreate(0, 0, 0)   ; private heap, handle 0x180039DA8
for each (target, handler):
    blk  = RWX alloc 0x40            ; dual stub
    blk+0x00 = relocated prologue + jmp [target+stolen]
    blk+0x16 = jmp [handler]        ; entry thunk
    entry = {target, blk+0x16, blk, backup[5], flags}
; phase 2 - spawn wrappers arm, then disarm:
call ARM(0)                          ; = E9 rel32 into every entry
call CreateProcessW(...)                ; tier-2, 10 args
call DISARM(0)                        ; write the backups back

Live decode settled what static analysis could not: the registry the earlier pass read as a fixed-VA table is a private HeapCreate heap (the 0x7FFFFEFF0000 address was a wine loader artifact; the 0xffeeffee words around the entries are wine heap fill magic), and the E9 detour is written by a separate call, sub_18000BD40: VirtualProtect to RW, patch, restore the old protection, flush the icache. Two NT functions are registered in-host: NtAllocateVirtualMemory and NtWriteVirtualMemory. The replacements inspect the target process: if it is not on the internal whitelist (teamfighttactics, league_of_legends), the call does not fail, it fake-succeeds: STATUS_SUCCESS is returned, the requested buffer address is reported back, and nothing was written. Injection tooling that checks return codes sees a working injection.

The trampoline builder is a complete Detours-style rewriter, not a byte copier: it length-decodes every stolen instruction and relocates it — E8 calls become a 14-byte call-through-absolute, E9/EB jumps resolve their destination and jump through it, short conditional jumps and LOOP variants are re-encoded over an absolute jump, RIP-relative constants are recomputed. It also knows the hotpatch layout: if the five bytes before a function are uniform padding, the detour lands at −5 and a two-byte EB F9 bridges back into it, leaving the function bytes untouched. The consequence for detection is the point of the design: at rest, ntdll is unmodified — same bytes, same page protection, nothing in any IAT points at vgrl. The detour exists only inside the spawn window, written and removed around a single CreateProcess family call by exports 1337 through 1339. A scanner that hashes ntdll once per boot will never see it.

6.3The arm gate

Every spawn export enters through the same dispatcher (sub_18000BC20 behind the 0x18000C340 arm wrapper): an interlocked spinlock, then either one target or the whole entry array. Return codes 0, 2, 4, 5 and 6 are the operating states — 0 armed clean, 2 registry not initialized, 4 target not registered. Re-entering the spinlock is an int3 kill, not a wait.

6.4Exports 1337 - 1346

6.5Pre-flight probes

Ordinal 1343 runs a bitmask battery. The FourCCs 1094930505 and 1380011332 that appear in tier-2 code are 'ACPI' and 'DMAR': a GetSystemFirmwareTable query for the VT-d DMAR table.

Probe strings are XOR-hidden in tier 2, one constant per string; the battery is cheap, read-only, and answers before any spawn happens.

6.6Starter pipeline

• Spawn order: probes (1343) → gate check (1345) → service starter (1340) → bootstrap spawn (1337) → session spawn (1339) when a UI process is required.
• Import slots: the resolved IAT places loader-critical APIs at slots [0], [2], [4] and [6]-[17]; the remaining stub-declared imports fill the rest. .fptable is the plain function-pointer cache the packer leaves behind.
• Job objects pin every spawned process; affinity follows the parent set; working sets are trimmed after spawn.
• Whitelist for memory-write access: teamfighttactics and league_of_legends image names. Everything else gets the fake-success path.

vgc, vgm, vgtray, and the upload path

The service owns everything: full SCM rights, WTS session crossing, shutdown privilege. The worker is a job-object child. The tray app is plain code that talks to the service and runs the visible Pre-Check. RTTI names survive in the log-uploader and name the whole client-side class model.

The TPM probe, answered

vgrl's probe bit 0x2 loads tbs.dll and asks the machine's TPM for its posture. That DLL is now reversed end to end from the Windows 11 25H2 binaries, and it has no secrets left: there is no RPC layer, no ALPC, no COM anywhere. A TBS context is literally a file handle to \??\TPM, a device object tpm.sys creates, and every operation is one NtDeviceIoControlFile.

Ten IOCTL codes are whitelisted in tpm.sys, all FILE_DEVICE 0x22, all METHOD_BUFFERED. Before submission, tbs.dll overwrites byte 0 of its command copy with a size class of 1 to 4; after the response arrives it reads the TPM response code from bytes 6 to 9 big-endian and publishes TpmLockedOut / TpmInFailureMode through WNF state names.

The interesting word for the probe is the interface type dword in GetDeviceInfo: tpm.sys fills it through an 11-entry jump table with values 1 to 5, hardcoding 4 for firmware TPMs. That one dword is the real-TPM / fTPM / vTPM discriminator — the bit of the machine that says whether the measured boot chain is anchored in silicon. Identity surfaces complete the picture: Tbsi_GetDeviceID returns the WindowsAIKHash REG_BINARY under Services\TPM\WMI, and the TCG measurement logs (WBCL, WBCLDrtm, WBCLTrustPoint under IntegrityServices) are written by tpm.sys itself into \SystemRoot\Logs\MeasuredBoot.

The kernel side enforces its own boundary: every IOCTL passes a SeAccessCheck against the security descriptor D:(A;;GA;;;SY)(A;;GA;;;BA) — system and administrators only. tbs.sys is a kernel-mode clone of the same contract (ZwDeviceIoControlFile on a kernel handle, pool tag TBSK). And when there is no TPM at all, the open fails and every entry point funnels to one error: 0x8028400F, TBS_E_TPM_NOT_FOUND — which is exactly the signal the vgrl probe records in its posture word.

Everything the suite looks at

One view across all seven binaries: every surface the suite probes, what exactly it reads, which component does the reading, and what the answer costs you. Hardware posture questions dominate the usermode side, timing dominates the install gate, and the kernel does the killing.

What is not here matters as much: no TPM attestation is forwarded, no measured-boot log leaves the machine through vgk itself, and the posture word is a machine fingerprint, not a court verdict. The only responses the suite can execute are terminate, panic, degrade, and report.

The ring, not the IOCTL

Kernel detection events reach usermode through a shared ring buffer built over an MDL, not through per-event IOCTLs. The format strings name the machinery precisely.

10.1The ring, in its own words

ace[diag]: FlushActiveBuffers logger=%u FlushAll=%d Collected=%u
vgtrace[diag]: Worker logger=%u STARTED CollectionOn=%d FlushTimer=%u FlushThreshold=%u
ace[diag]: BuildConsumer logger=%u kva=%p uva=%p mdl=%p
vgtrace[diag]: FlushToRealtime logger=%u SKIPPED (ring not initialized) seq=%llu savedOffs=%llu

Worker threads fill, a flush timer and a threshold trigger collection, and BuildConsumer maps a kernel VA to a user VA over an MDL: the consumer is vgc, reading the ring through NtMapViewOfSection.

10.2Identity flow

10.3Exposure

• The ring is a one-way channel: no command enters the kernel through it. Command-shaped traffic uses the Egg exports (4.4).
• Event volume is invisible from outside: flushes are batched by timer and threshold, not by event count.
• The mapped user VA is per-consumer; the MDL pins the pages, so the ring survives service restarts without the driver reloading.