DEV Community: Pastukhov Aleksey

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

Pastukhov Aleksey — Sun, 10 May 2026 17:22:52 +0000

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

Reverse Engineering rpcss.dll: Hunting for the ROT's Hidden Structure

Pastukhov Aleksey — Wed, 06 May 2026 13:51:47 +0000

Part IV(?) of the "Inside the Running Object Table" series

When I started this research, I assumed finding the internal layout of the Running Object Table would be straightforward. Microsoft documents IRunningObjectTable at the API level, surely the implementation couldn't be far behind. I was wrong. What followed was a Ghidra session that turned up something far more interesting than I expected.

Where does the ROT actually live?
First surprise: there is no rpcss.exe on disk.
What Windows Task Manager shows as rpcss.exe is actually svchost.exe hosting rpcss.dll, classic service host pattern. The DLL lives at C:\Windows\System32\rpcss.dll and gets mapped into a dedicated svchost instance at boot. Every ROT operation your process makes through ole32.dll crosses an ALPC channel and lands in that DLL's code.
So that's our target.

Loading rpcss.dll into Ghidra
Standard procedure -drag, drop, let the auto-analyzer run. The interesting part comes when you load the PDB. Microsoft publishes symbol files for most system DLLs through their public symbol server, and rpcss.dll is no exception.
Grab symchk.exe from your Windows SDK Debuggers folder and run:

symchk C:\Windows\System32\rpcss.dll ^
    /s srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Point Ghidra at the downloaded PDB and suddenly FUN_18006XXXX becomes something readable. This is where it gets interesting.

First hit: CScmRotEntry
Searching the Symbol Table for ROT turns up the string u"ROTFlags" at address 180136070. Xref later, going inside a large function. But the real find is in the Symbol Table itself:
CScmRotEntry::GetAllowAnyClient
Not CROTEntry. Not CRunningObjectTableEntry. CScmRotEntry - SCM stands for Service Control Manager. This tells us something immediately, the ROT isn't just a COM subsystem. It's wired into the service infrastructure at a deeper level than the documentation suggests.
The decompilation of GetAllowAnyClient reveals the first concrete field offset:

return *(uint *)(this + 0x68) >> 1;  // bit 1 = AllowAnyClient flag

The real structure: LookupObjectInROT
Searching for CScmRot surfaces LookupObjectInROT - a function that takes ACTIVATION_PARAMS and walks the table looking for a matching object. From here we follow the call into CScmRot::GetObject, which is where the actual traversal happens.
The decompilation reveals the first architectural surprise:

cplVar13 = *(longlong **)(*(longlong *)(lpCriticalSection + 0x48) + uVar9 * 8);

The ROT is not a linked list. It's a hash table with 251 buckets (0xFB).
Each bucket is a pointer to a chain of CScmRotEntry objects. The hash function is a simple rolling hash over the moniker bytes:
chash = ((hash * 3) ^ byte) % 0xFB;
Aint cryptographic n complex. Fast and collision-tolerant for the expected workload of a few dozen registered objects.

Digging deeper: the class hierarchy
Listing all symbols with the CScmRot prefix turns up the full method table:

CScmRot::EnumRunning
CScmRot::GetEntryFromScmReg
CScmRot::GetTimeOfLastChange
CScmRot::IsRunning
CScmRot::Register
CScmRot::Revoke
CScmRotEntry::CScmRotEntry
CScmRotEntry::GetProcessID
CScmRotEntry::IsValid

Two things stand out. First, CScmRotEntry::CScmRotEntry it's a constructor, meaning this is a proper class with its own lifecycle. Second, CScmRotEntry::GetProcessID -every ROT entry stores the PID of the registering process. That field doesn't appear anywhere in the public API documentation.
Opening the constructor reveals something else entirely: CScmRotEntry is not a flat structure. It inherits from a base class:

CScmRotEntry
    └── CScmRotMgotEntryBase

"Mgot" itsa likely Marshaled Global Object Table. The base class constructor initializes most of the core fields:

CScmRotMgotEntryBase::CScmRotMgotEntryBase(
    CScmRotMgotEntryBase *this,
    ulong param_1, ulong param_2,
    _MnkEqBuf *param_3,
    CToken *param_4,
    ushort *param_5,
    tagInterfaceData *param_6,
    bool param_7,
    ulong param_8)
{
    *(undefined8 *)(this + 0x08) = 0;       // pNext = NULL
    *(undefined4 *)(this + 0x10) = 1;       // ref count = 1
    *(tagInterfaceData **)(this + 0x18) = param_6;
    *(ushort **)(this + 0x30) = param_5;    // display name
    this[0x40] = ... | param_7;             // flags
    *(_MnkEqBuf **)(this + 0x20) = param_3; // moniker eq buffer
    *(CToken **)(this + 0x28) = param_4;    // integrity token
    if (param_4 != NULL) {
        LOCK();
        *(int *)(param_4 + 8) += 1;         // manual AddRef
        UNLOCK();
    }
}

And CScmRotEntry adds its own fields on top:

*(ulong *)(this + 0x50) = 0x746f7263;   // magic: "crot"
*(ulong *)(this + 0x54) = param_5;
*(_FILETIME *)(this + 0x58) = *param_4; // last change time
*(tagInterfaceData **)(this + 0x60) = param_12;
*(ulong *)(this + 0x68) = param_7;      // ROTFlags

The complete structure map is being combining both constructors gives us the full layout:

struct CScmRotMgotEntryBase {
    void            *vtable;       // +0x00
    longlong         pNext;        // +0x08  next in bucket chain
    DWORD            dwRefCount;   // +0x10  starts at 1
    tagInterfaceData *pIFaceData;  // +0x18  marshaled interface
    _MnkEqBuf       *pMnkEqBuf;   // +0x20  moniker comparison buffer
    CToken          *pToken;       // +0x28  integrity level token
    ushort          *pwszName;     // +0x30  display name (wide string)
    longlong         unk_0x38;     // +0x38
    BYTE             bFlags;       // +0x40  bit 0 = various flags
    DWORD            dwField_44;   // +0x44
    DWORD            dwField_48;   // +0x48
    DWORD            dwField_4c;   // +0x4c
};
// Derived class
struct CScmRotEntry : CScmRotMgotEntryBase {
    DWORD            dwMagic;      // +0x50  0x746F7263 = "crot"
    DWORD            dwField_54;   // +0x54
    _FILETIME        ftLastChange; // +0x58  registration timestamp
    tagInterfaceData *pIFaceData2; // +0x60  second interface data
    DWORD            dwROTFlags;   // +0x68  bit 1 = AllowAnyClient
};

Three findings worth highlighting
The "crot" magic signature at +0x50. Every valid CScmRotEntry in memory carries the ASCII bytes c, r, o, t at this offset. This is almost certainly what CScmRotEntry::IsValid checks. For a memory scanner, this is a gift: you can locate entries by signature without knowing the head of the hash table.
CToken uses manual reference counting. The increment at param_4 + 8 is wrapped in LOCK/UNLOCK - interlocked, not COM AddRef. This means tokens are shared across multiple ROT entries from the same process using a private refcount mechanism entirely separate from COM lifetime management.
pwszName at +0x30 is the display name. This is the wide string you'd normally get from IMoniker::GetDisplayName. Reading it directly means a memory scanner doesn't need to deserialize tagInterfaceData or call any COM API to get human-readable moniker names — the string is right there in the entry.

The security picture
Walking CScmRot::GetObject surfaces three distinct access control mechanisms operating in sequence:

cRotEntryIsTrusted(plVar11, token)
RotMgotEntryIsAccessible(plVar11, token, ...)
CToken::IsTokenILLower(plVar11[5], plVar13[5], ...)

Trust check, accessibility check, integrity level comparison in that order. When multiple entries match the same moniker, the one with the higher integrity level wins. A sandboxed process cannot shadow a medium-integrity registration. AppContainer entries get discarded entirely for out-of-container clients — we even found the log string in the code:
"Disregarding ROT entry registered by AppContainer"
The ROT has a real access control model. It's just not documented anywhere near as clearly as the public API suggests.

Code and tooling: github.com/ssteelfactor-oss

[to be continued...]

NetEnum: legitimate API scanning tool

Pastukhov Aleksey — Sun, 19 Apr 2026 12:47:39 +0000

NetEnum is a compact, purpose-built network and service enumeration tool, written in plain C, focused on one core idea: collecting intelligence through “legitimate” APIs and standard system interfaces rather than noisy, signature-heavy probing. That design choice makes it especially useful in environments where you need reliable discovery while keeping activity indistinguishable from normal administrative telemetry—a practical advantage when EDR, IDS, and other detection layers are tuned to flag aggressive scanners.

What NetEnum is (and what it is not)

Unlike classic scanners that spray packets, brute-force banners, or rely on exploit-style fingerprinting, NetEnum is intended to enumerate using the same mechanisms that real enterprise tooling uses: vendor-supported endpoints, OS-provided management interfaces, and other approved channels. In other words, it aims to behave like routine operations—inventory, auditing, compliance checks—rather than “attack-like” reconnaissance.

This makes NetEnum a good fit for:

internal asset inventory and continuous discovery,
lab validation of monitoring baselines,
security assessments where you want realistic operator behavior,
blue team exercises that measure what can be learned from sanctioned interfaces alone.

Why “legitimate API scanning” matters

Modern corporate networks are full of valuable signals exposed through APIs: identity systems, management planes, cloud services, directory services, configuration endpoints, and monitoring stacks. Those systems exist specifically so administrators and automation can query them safely.

NetEnum’s philosophy is simple:

Prefer official read paths (documented endpoints, authenticated queries, normal tooling behaviors).
Minimize noisy traffic patterns (avoid broad port blasting when high-confidence information is already available via an API).
Reduce anomalous fingerprints (keep requests close to typical management and inventory workflows).

Lower visibility to EDR / IDS (in the practical sense)

EDR and IDS commonly trigger on patterns associated with classic scanning:

high-rate connection attempts across many ports/hosts,
unusual protocols or malformed probes,
repeated banner grabs,
tool-specific packet signatures.

When enumeration is performed through standard API calls and normal management interfaces, the observable footprint is often closer to:

legitimate admin scripts,
IT automation,
health checks and inventory tasks.

That doesn’t mean “undetectable”—good monitoring can still catch unusual authentication patterns, abnormal query volumes, or access outside an expected role. But it does mean NetEnum is designed to avoid the obvious scanner-shaped telemetry that many detection stacks prioritize.

Built for controlled, responsible use

NetEnum is best used where you have permission and clear scope: your own infrastructure, sanctioned assessments, or test environments. The “legitimate API” approach is powerful precisely because it leverages trusted interfaces—so it should be paired with proper governance, logging, and access control. Used correctly, it becomes a high-signal inventory and visibility tool that complements (rather than replaces) traditional network scanning.

Summary

If your goal is to understand an environment with less noise and fewer detection spikes, NetEnum is built around a modern enumeration strategy: learn as much as possible from the same APIs and management planes that enterprises already rely on. That yields actionable discovery while keeping collection closer to normal operational behavior—an advantage in networks where EDR/IDS is sensitive to classic recon patterns.

If you want, paste your README (or tell me the key features/modules you want highlighted), and I’ll tailor the post to match NetEnum’s exact capabilities and include a short “How it works” section without revealing anything unsafe.

Link to: https://github.com/ssteelfactor-oss/NetEnum

Part 3: putting it al l together

Pastukhov Aleksey — Mon, 13 Apr 2026 17:24:59 +0000

#include <windows.h>
#include <objbase.h>
#include <stdio.h>

int main(int argc, char * argv[]) {
    CoInitializeEx(0, COINIT_APARTMENTTHREADED);

    IRunningObjectTable *pROT  = 0;
    IEnumMoniker        *pEnum = 0;
    IBindCtx            *pCtx  = 0;
    IMoniker *pMon   = 0;
    ULONG     fetched = 0;

    GetRunningObjectTable(0, &pROT);
    pROT->lpVtbl->EnumRunning(pROT, &pEnum);
    CreateBindCtx(0, &pCtx);

    while (pEnum->lpVtbl->Next(pEnum, 1, &pMon, &fetched) == S_OK) {
        LPOLESTR name = NULL;
        if (SUCCEEDED(pMon->lpVtbl->GetDisplayName(pMon, pCtx, 0, &name))) {
            wprintf(L"%s\n", name);
            CoTaskMemFree(name);
        }
        pMon->lpVtbl->Release(pMon);
    }

    pCtx->lpVtbl->Release(pCtx);
    pEnum->lpVtbl->Release(pEnum);
    pROT->lpVtbl->Release(pROT);
    CoUninitialize();
    return 0;
}

Compile with:

cl rot_enum.c ole32.lib

What you'll actually see - on my comp the output looks like:

Part 2: How It Works Under the Hood

Pastukhov Aleksey — Sun, 12 Apr 2026 12:16:14 +0000

Before diggin into, it's useful to consider a question that most COM tutorials never address: where does the Running Object Table actually reside?
The ROT isnt a data structure inside the calling process, nor is it a kernel object.

It exists as a global, session-scoped table inside rpcss.exe, the RPC Subsystem process, and is shared by all processes running in the same Windows session.
When code calls GetRunningObjectTable() func, it does not receive a direct pointer to the table. Instead, it receives a proxy object that implements the IRunningObjectTable interface. Every method invoked on this proxy is marshaled across a local RPC channel (ALPC) to rpcss.exe. The actual mapping of monikers to live objects never leaves that system process.

As a result, every ROT operation: Register, Revoke, IsRunning, GetObject, etc is an inter-process call. The overhead is insignificant for occasional use, but it must be taken into account when these functions are invoked inside tight loops or performance-critical code.

The API chain
The full enumeration path will be looks like this:

GetRunningObjectTable()
    └── IRunningObjectTable::EnumRunning()
            └── IEnumMoniker::Next()
                    └── IMoniker::GetDisplayName()

Step 1: Get a handle to the ROT

HRESULT hr = 0;
IRunningObjectTable *pROT = 0;
hr = GetRunningObjectTable(0, &pROT);

Entry point - GetRunningObjectTable(). 1-argument is reserved and must be zero. On success it gives you IRunningObjectTable, proxy to rpcss.exe. Always check SUCCEEDED(hr) before proceeding; if the RPC channel to rpcss is broken, it fails.

Step 2: Get an enumerator

IEnumMoniker *pEnum = 0;
hr = pROT->lpVtbl->EnumRunning(pROT, &pEnum);

EnumRunning() returns IEnumMoniker, a standard COM enumerator over the monikers currently registered in the table.
This is a snapshot: entries registered after this call won't appear, entries revoked before you iterate won't be missing from the snapshot either - enumerator captures state at the moment of the call.

Step 3: Iterate

IMoniker *pMon = 0;
ULONG fetched = 0;

while (pEnum->lpVtbl->Next(pEnum, 1, &pMon, &fetched) == S_OK) {
    // process pMon
    pMon->lpVtbl->Release(pMon);
}

Next() func follows the standard COM enumerator contract: request items, get back how many were actually returned.
Ask for one at a time it's simpler error handlingn.

Step 4: Decode the moniker

IBindCtx *pCtx = 0;
CreateBindCtx(0, &pCtx);

LPOLESTR displayName = 0;
pMon->lpVtbl->GetDisplayName(pMon, pCtx, NULL, &displayName);

wprintf(L"%s\n", displayName);
CoTaskMemFree(displayName);

GetDisplayName() requires a bind context. IBindCtx- even though we're only reading a name, not actually binding. The bind context carries parameters that affect how monikers resolve; for display purposes we pass a default one via CreateBindCtx(0, ...).
Don't forget to free memory with callong CoTaskMemFree().

To be continued

Inside the Running Object Table: COM's Hidden Registry of Live Objects

Pastukhov Aleksey — Sun, 12 Apr 2026 11:20:02 +0000

Inside the Running Object Table: COM's Hidden Registry of Live Objects

*Introduction: Running Object Table, part I *

"...almost no developer ever looks at directly", by me.

COM is a technology that many developers believe they understand until they encounter its less-documented internals. Most are familiar with the core concepts — interfaces, CoCreateInstance, and reference counting — yet the Component Object Model contains considerably more supporting infrastructure than its public API reveals. One of the least examined parts of this infrastructure is the Running Object Table, commonly abbreviated as ROT.

The ROT is a system-wide registry that holds references to live COM objects. It does not store class information or factory objects; it contains only instantiated objects that have been explicitly registered as running and available for external access. In essence, it serves as the mechanism by which a COM server can declare that a particular object is active and can be located by name. A client that needs to connect to an already-running instance checks the ROT before creating a new object.

This component plays a more important role than is commonly recognized. The ROT is the underlying mechanism used by GetObject() in VBScript, it enables Visual Studio to expose its automation model to external scripts, and it supports certain inter-process communication patterns in Windows without the need for explicit sockets or named pipes. At the same time, the ROT is an area that is frequently misunderstood and can be misused.
Currently registered on a live Windows system, decoding of the monikers they expose, and analysis of what these findings indicate about the runtime behavior of COM.
In C, without ATL, without MFC, without training wheels. Just enumerate what's actually registered on a live Windows system, decode the monikers i find, and talk about what the results reveal about COM's runtime model.

To be continued