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

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:

1. Load a global pointer via mov reg, [rip+disp]
   


2. Call a mutex CMutexSem2::Request
   


3. Access [base + 0x30] registration counter


4. Take address of [base + 0x38] CScmRotHintTable


5. 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

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:

## Code

github.com/ssteelfactor-oss/iBuldoser