Deep inside the COM: Reading Windows ROT Without Asking Permission. Detective story

Source: Dev.to

This is Part 4 of the “Inside the Running Object Table” series. Parts 1-3 covered the public COM API and rpcss internals. This one is about going further & getting it wrong several times before getting it right.

The goal

GetRunningObjectTable() returns 15 entries on my machine. We wanted to read the same table without calling that function at all, directly from rpcss memory. Without ole32 & ALPC. Raw ReadProcessMemory. The motivation: the public API filters. AppContainer entries disappear. Security policy silently drops others. We wanted the unfiltered view. Simple idea. But suddenly aint simple path.

Phase 1. Ghidra and the structure hunt

We opened rpcss.dll in Ghidra, loaded the PDB from Microsoft’s symbol server, and searched for ROT in the Symbol Table. CScmRotEntry::GetAllowAnyClient CScmRotEntry::GetProcessID CScmRotEntry::IsValid CScmRotMgotEntryBase::CScmRotMgotEntryBase

Aint CROTEntry. CScmRotEntry. SCM: Service Control Manager. The ROT is wired into the service layer at a level the documentation never mentions. struct CScmRotMgotEntryBase { void *vtable; // +0x00 longlong *pNext; // +0x08 linked list DWORD dwRefCount; // +0x10 tagInterfaceData *pIFaceData; // +0x18 _MnkEqBuf *pMnkEqBuf; // +0x20 moniker comparison buffer CToken *pToken; // +0x28 integrity level token ushort *pwszName; // +0x30 display name }; struct CScmRotEntry : CScmRotMgotEntryBase { DWORD dwMagic; // +0x50 = 0x746F7263 = “crot” DWORD dwROTFlags; // +0x68 bit 1 = AllowAnyClient };

The magic signature “crot” at +0x50 was a gift. The hash table: 251 buckets, rolling hash (hash * 3 ^ byte) % 0xFB. gpscmrot - the global pointer to the CScmRot object, at Ghidra address 0x180161270. RVA: 0x161270.

Phase 2. The RVA that lied

SeDebugPrivilege and ReadProcessMemory, opened the svchost hosting rpcss.dll and read the gpscmrot slot: u”ROTFlags” at 0x180136070. One xref. Inside a very large function. But the Symbol Table itself gave us the real prize: NULL. Every time. On a live system with 15 ROT entries visible via ole32. gpProcessList - also zero. gScmMgot - zero. “crot” magic. MEM_PRIVATE. MEM_MAPPED. All regions. Zero results. We searched for L”Personal-Monikers” across every svchost process. Nothing. we don’t know where the data is.

Phase 3. The LOAD/STORE revelation

CScmRot::Register. In Ghidra’s 1800ffe77: MOV qword ptr [gpscmrot], RSI ← STORE

The instruction that writes gpscmrot is a STORE: mov [mem], reg. LOAD instructions: mov reg, [rip+disp]. writes to gpscmrot. The functions that use it read from it. The scorer finds readers, not writers. 0x160DE8 instead of 0x161270, it was not wrong , it found a different global, one that functions read from with the same CScmRot usage pattern. Two different addresses. Both valid entry points into the same object graph. instruction VA: 0x1800ffe77 next RIP: 0x1800ffe7e displacement: 0x000613f2 gpscmrot slot: 0x1800ffe7e + 0x613f2 = 0x180161270 ✓

The math was right all along. The object just happened to be NULL in the svchost we were reading.

Phase 4, Two svchosts, one ROT

rpcss.dll was loaded in two different svchost processes. EnumProcesses returns processes in an unspecified order. We were consistently landing in the svchost where rpcss was loaded but the ROT was not yet initialized, a secondary instance handling a different service role. gpscmrot is non-null before committing to a process.

DWORD_PTR slotAddr = rpcssBase + RVA_GPSCMROT;

One loop change. Suddenly everything was non-null. We built a parallel approach: find gpscmrot dynamically from binary behavior, without trusting the hardcoded RVA. Any function managing CScmRot does all of these: Load a global pointer via mov reg, [rip+disp]

Call a mutex CMutexSem2::Request

Access [base + 0x30] registration counter Take address of [base + 0x38] CScmRotHintTable Take address of [base + 0x48] CScmHashTable Microsoft can rename gpscmrot. They can strip PDB symbols. They cannot remove the mutex, the counter, and the hash table without breaking COM entirely. We scored 2 points per pattern, +4 bonus for all four simultaneously.

[] Scoring 2048 functions… [] Candidates: 407 [*] Best score: 13 slot: 0x00007FFC15460DE8 uses_lock = true uses_[+0x30] = true uses_[+0x38] = true

Score 13. Maximum possible. Found without symbols, without hardcoded addresses, from behavior alone. CScmRot + 0x48 → CScmHashTable (CScmHashTable) → bucket array (251 entries) bucket[i] → CScmRotEntry +0x50 → “crot” magic (validate) +0x20 → _MnkEqBuf _MnkEqBuf + 0x14 → moniker name (uppercase wide string)

The _MnkEqBuf buffer has 4 bytes size header, 12 bytes COM metadata, then the name. Final output with Office open: [ROT][bucket 000] C:\USERS\USER\SOURCE\REPOS\IBULDOSER\IBULDOSER.SLN [ROT][bucket 011] !PERSONAL-MONIKERS::STORAGEPROVIDERSEARCHHANDLER [ROT][bucket 020] !VISUALSTUDIO.DTE.18.0:12600 [ROT][bucket 192] C:\USERS\USER\APPDATA…[redacted].XLAM

[+] Total ROT entries found: 22

What is the key

The LOAD/STORE distinction matters. Ghidra shows where a variable is written. Your scanner needs where it is read. These can be different globals. NULL is not evidence of absence. Two processes loaded rpcss.dll. Only one had an initialized ROT. Always validate the pointer before committing to a process. Behavior survives refactoring. Addresses don’t. The scorer found a valid CScmRot using four behavioral signals that cannot be removed without breaking Windows COM. Hardcoded RVAs last until the next update. Behavioral signatures last until the architecture changes. The buffer is always 16 bytes ahead of the string. A lesson in reading COM serialization formats the hard way.

Phase 6 — Reading the table

CScmRot*, the rest was mechanical: The write-site calculation confirmed 0x161270:

Code

github.com/ssteelfactor-oss/iBuldoser