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.
Me just reverse-engineered the full structure from constructors alone. Constructors are better than documentation - every field gets initialized with its exact offset. Two hours of reading decompiled C later, discovered:
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.
We also found gpscmrot - the global pointer to the CScmRot object, at Ghidra address 0x180161270. RVA: 0x161270.
Now had a map. Time to read the territory.
## Phase 2. The RVA that lied
With SeDebugPrivilege and ReadProcessMemory, opened the svchost hosting rpcss.dll and read the gpscmrot slot:
First hit: u"ROTFlags" at 0x180136070. One xref. Inside a very large function. But the Symbol Table itself gave us the real prize:
rpcssBase + 0x161270 → 0x0000000000000000
NULL. Every time. On a live system with 15 ROT entries visible via ole32.
Dumped 64 bytes around the address. The slot was genuinely zero. gpProcessList - also zero. gScmMgot - zero.
Spent time scanning every memory region in rpcss for the "crot" magic. MEM_PRIVATE. MEM_MAPPED. All regions. Zero results. We searched for L"Personal-Monikers" across every svchost process. Nothing.
At this point the honest assessment was: we don't know where the data is.
## Phase 3. The LOAD/STORE revelation
Then came the constructor analysis of CScmRot::Register. In Ghidra's
write-site xref listing:
1800ffe77: MOV qword ptr [gpscmrot], RSI ← STORE
The instruction that writes gpscmrot is a STORE: mov [mem], reg.
Our behavioral scorer was built to find LOAD instructions: mov reg, [rip+disp].
We had been hunting in the right neighborhood but looking at the wrong side of the street. The constructor writes to gpscmrot. The functions that use it read from it. The scorer finds readers, not writers.
So when the scorer found a candidate at 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.
The fix: check whether gpscmrot is non-null before committing to a process.
DWORD_PTR slotAddr = rpcssBase + RVA_GPSCMROT;
DWORD_PTR pScmRot = 0;
if (ReadPtr(hProc, slotAddr, &pScmRot) && pScmRot != 0) {
return pid; // this is the active instance
}
// null → wrong svchost, keep looking
One loop change. Suddenly everything was non-null.
Phase 5 The behavioral scorer
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 renamegpscmrot. 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
ole32 had shown 15. We found 22. The 7 extra entries are what the public API silently discards.
## 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
With a valid CScmRot*, the rest was mechanical:
uses_[+0x48] = true`
The write-site calculation confirmed 0x161270: