DEV Community: lupingQAQ

red-team-skill-tree: a full-stack offensive security reference

lupingQAQ — Tue, 29 Sep 2026 13:49:46 +0000

red-team-skill-tree: a full-stack offensive security reference

A comprehensive red team skill reference covering the full offensive-security stack - from anti-attribution and reconnaissance to post-exploitation, malware evasion, cloud-native attacks, and AI-powered offense. Based on a real training curriculum, updated with 2025-2026 APT techniques.

Coverage (24 sections)

#	Topic	Coverage
1	Anti-Attribution and Anonymization	OPSEC, encrypted VMs, anonymous network chains, crypto laundering
2	Reconnaissance	OSINT, SGK, asset platforms, supply-chain mapping, CDN bypass
3	Penetration Testing	Web app attacks (SQLi/RCE/upload), framework exploits, container escape
4	Code Audit	Java (MyBatis/deserialization/SSTI), PHP (ThinkPHP RCE chains), .NET, memory shells
5	Post-Exploitation and Lateral Movement	AD attacks (Kerberos/delegation/CVEs), credential harvesting, privilege escalation
6	Host Credential Extraction	Browser/SSH/RDP/VPN password decryption tools
7	Social Engineering	Phishing pretexts, waterholing, malicious payload crafting
8	C2 Development	Cobalt Strike customization, Godzilla modification, traffic forwarding
9	Malware Evasion	EDR blinding (driver-level), static/dynamic/traffic evasion, injection techniques
10	Forensic Image Recovery	Linux disk image restoration for evidence analysis
12	AI-Powered Attacks	Deepfake phishing, LLM-assisted malware, AI infrastructure CVEs, OWASP LLM Top 10
13	Cloud-Native Attacks	Kubernetes escape (runc/eBPF), serverless, CI/CD supply chain
14-24	Advanced Techniques	Modern C2, sleep obfuscation, ADCS (ESC1-16), MFA bypass, zero-trust evasion, OT/ICS, mobile, living-off-the-land

Files

File	Description
`red-team-skill-tree.md`	Main content - refined skill tree, 24 sections (English)
`red-team-skill-tree.zh-CN.md`	Main content - 24-section reference (Chinese)
`red-team-skill-tree-outline.md`	Original XMind export, raw outline (English)
`red-team-skill-tree-outline.zh-CN.md`	Original XMind export (Chinese)
`red-team-skill-tree.xmind`	XMind source file
`red-team-skill-tree.png`	Full-resolution mind map

Repo: https://github.com/lupingQAQ/red-team-skill-tree

SqlStealthRogue: a zero-probe SQL and NoSQL data dumper

lupingQAQ — Tue, 29 Sep 2026 13:49:25 +0000

SqlStealthRogue: a zero-probe SQL and NoSQL injection data dumper

A minimalist, zero-probe SQL/NoSQL injection data dumper. Single entry file, pure Python standard library, no dependencies.

Concept

SqlStealthRogue is a scalpel, not a swiss-army knife: given a known injection point and a known database, table, and columns, it extracts data at high speed with zero negotiation and zero reconnaissance traffic. sqlmap - even with -D/-T/-C pinned - still fires requests for DBMS fingerprinting, version detection, privilege/table enumeration, WAF detection and technique polling. SqlStealthRogue does the opposite: every single request it sends is a data-extraction request.

Zero extra requests

Behavior	SqlStealthRogue
DBMS fingerprint / version probing	none
Privilege / schema enumeration	none (you already know the target)
WAF detection / technique polling	none (`--dbms` + `--technique`, specify and go)
True-mark calibration requests	none (row termination rides on extraction requests)
Every request sent	is a data-extraction request

High-speed extraction (measured on real engines)

Optimization	Measured effect
Bit-parallel blind engine (`char & mask`, 8 concurrent bits)	5.35x faster, request count identical to serial binary search
HTTP keep-alive, thread-local connections	5.6x faster (auto-downgrades on HTTP/1.0 targets, zero penalty)
Error-mode adaptive chunk prefetch	long values fetched in one batch
PG/MSSQL large chunks (error messages carry >=800 chars, measured)	600-char value: 22 -> 6 requests
UNION mode	whole table in 1 request

Custom WAF-bypass plugins (tamper chains)

# 13 sqlmap-compatible tampers built in; compose in order; zero extra traffic
python SqlStealthRogue.py --tamper "randomcase,between,space2comment" ...

# Custom plugin: one .py file with one tamper() function
python SqlStealthRogue.py --tamper mybypass --tamper-dir /path/to/tampers ...

Built-in tampers: space2comment space2plus space2randomblank between equaltolike randomcase charencode chardoubleencode halfversionedmorekeywords apostrophemask percentage unionalltounion xforwardedfor.

Minimal-blast-radius abort on misconfiguration

A wrong parameter never floods the target - the cost of a mistake is capped at "first row, first value":

Misconfiguration	Packets actually sent
Statically invalid args / unknown tamper / dbms x technique mismatch	0
Injection point unreachable	<= 2
Template or true-mark syntax error	8-16
Always-true true-mark / always-matching regex (sentinel guards abort)	~128 (would be 16,384+ without guards)
Bad UNION template	1

12-engine real-machine verification matrix

Engine	error	bool	time	prefix	union
MySQL 8	yes	yes	yes	-	yes
PostgreSQL 14	yes	yes	yes	-	yes
MSSQL 2022	yes	yes	yes	-	yes
SQLite	-	yes	yes	-	yes
Redis	-	yes	partial	-	yes
MongoDB 7	-	yes	yes	yes	-
openGauss 5	yes	yes	yes	-	yes
OceanBase CE	-	yes	yes	-	yes
Oracle 23ai	-	yes	yes	-	yes
Elasticsearch 8	-	yes	partial	-	yes
Milvus 2.4	-	-	-	-	yes
pgvector	yes	yes	yes	-	yes

Repo: https://github.com/lupingQAQ/SqlStealthRogue

impacket-programming-manual: writing your own domain-penetration scripts

lupingQAQ — Tue, 29 Sep 2026 13:43:19 +0000

impacket-programming-manual: writing your own domain-penetration scripts

A book-length, source-code-driven guide to developing your own domain-penetration scripts on top of impacket - not another walkthrough of secretsdump.py / psexec.py flags.

Why this manual exists

Almost every public exploit for recent Active Directory vulnerabilities was built directly on impacket modules: sam-the-admin, CVE-2022-33679, noPac, Zerologon tooling, PetitPotam-style relay chains. Yet nearly all existing articles only explain how to run the example scripts. This manual fills the gap the other way around: it walks module by module through the impacket source tree, so when the next domain vulnerability drops you can grab impacket and write your own PoC fast.

Author: Lu Ping
Length: ~5,400 lines, 9 chapters, 6 parts
Covers: LDAP, Kerberos (krb5), GSS-API/SPNEGO, DCE/RPC (NDR, EPM, transport), 20+ MS protocol modules, DCOM and WMI, the support libraries, and the impacket 0.12-0.14 additions

What's inside

Part	Chapter	Content
I. Preliminaries	Ch.1 impacket overview and directory layout	Where every module lives in the source tree
	Ch.2 `structure.py` - universal serialization base	The base class behind every protocol packet structure
II. Authentication and Directory	Ch.3 LDAP (`ldap`)	Directory queries, ACL structures, Global Catalog
	Ch.4 Kerberos (`krb5`)	Tickets, ccache/keytab, PAC, GSS-API and SPNEGO
III. DCE/RPC	Ch.5 `dcerpc`	RPC basics (NDR, rpcrt, EPM, transport) + 20+ interface modules in 5 functional groups (SAMR, NRPC, LSAD, RRP, SRVS, RPRN/PAR, TSCH, BKRP, DRSUAPI...)
IV. DCOM and WMI	Ch.6 MS-DCOM	COM/DCOM programming, dcomrt, oaut/comev/scmp/vds/wmi submodules
V. Support libraries	Ch.7 `common`	SMB2/3, DPAPI, NTDS (ese), TDS
VI. New interfaces and case studies	Ch.8 interfaces added in 0.12-0.14	ICPR (AD CS certificate enrollment), GKDI (group key distribution), NEGOEX, RAA (remote authorization), SCMR, plus `acl.py` and `dpapi_ng.py`
	Ch.9 case studies	BadSuccessor (CVE-2025-53779) and CVE-2025-33073 - PoC walk-throughs

Case studies woven through the chapters

Zerologon (CVE-2020-1472) in nrpc; PrinterBug / PrintNightmare in rprn/par; CVE-2019-1040 NTLM MIC bypass in gssapi; Exchange RPC-over-HTTP relay (rpcmap / ProxyRelay); Akamai's "Cold Hard Cache" RPC security-callback bypass; WMI persistence (wmipersist); golden PAC forging. In Part VI: BadSuccessor (CVE-2025-53779), which abuses the Windows Server 2025 dMSA account type, and CVE-2025-33073, the reflective relay that yields SYSTEM on any host without SMB signing.

Highlights

Source-level, not example-level. Every chapter reads the actual impacket source: getKerberosTGT/getKerberosTGS internals, ccache/keytab binary layouts, DCERPCTransportFactory dispatch, DCOMConnection/INTERFACE/IRemUnknown object model, IWbemServices method tables.
Annotated code excerpts. Long listings are compressed to key code paths with step-numbered annotations, so you see the flow at a glance instead of scrolling through hundreds of lines of boilerplate.
Upstream-verified quotes. All cited code was checked against the current fortra/impacket master; known upstream quirks (the par.py opnum 39 tuple, hept_map spelling, MimiUnbind vs MiniUnbind) are preserved and annotated instead of silently "fixed".

Formats

English edition (impacket_programming_manual_EN.pdf) and Chinese edition (impacketç¼–ç¨‹æ‰‹å†Œ.pdf), both included, plus the source-first chapters.

Repo and docs: https://github.com/lupingQAQ/impacket-programming-manual

dotnet-memshell: three .NET memory shells at three insertion positions

lupingQAQ — Tue, 29 Sep 2026 13:42:56 +0000

dotnet-memshell: three .NET memory shells at three distinct insertion positions

Three .NET memory shells at three different insertion positions - single-file payloads, armed by one deserialization, invisible to unmarked traffic.

Why these are different

Most public .NET memory shells (module, handler, route, VirtualPathProvider) live inside the HTTP request pipeline at already-known positions. dotnet-memshell spreads across three different layers instead: the pipeline event layer (with pool broadcast), the HTTP-to-WebSocket upgrade point (connection takeover - the .NET port of the WebSocket memory-shell idea), and an already-registered Remoting channel (container-style endpoint registration).

All three ride the target's existing endpoints: no new port, no web.config change, no file on disk.

The three shells

#	Shell	Insertion position	Trigger	Minimum privilege
1	HttpModuleShell	`HttpApplication` module-event pipeline	any request with an `MSH-Cmd: <cmd>` header	default app-pool identity
2	WsTakeoverShell	HTTP-to-WebSocket upgrade transition	handshake with subprotocol `msh`	app-pool identity + integrated pipeline + WS feature
3	RemotingUriShell	AppDomain-global URI table of an existing Remoting channel	remoting call to `<channel>/msh`	app-pool identity + business hosts Remoting

HTTP.sys / IIS
 +- ASP.NET request pipeline
     +- module events (BeginRequest...)      <- #1 HttpModuleShell
     +- routing / VPP / handler / endpoint    (known families)
     +- upgrade point (HTTP->WS handshake)   <- #2 WsTakeoverShell

in-process protocol stacks
 +- existing Remoting server channel          <- #3 RemotingUriShell

What makes them different

Property	dotnet-memshell
New listening port	none - #1/#2 ride the site's 80/443, #3 rides the business channel
`web.config` / registry / URLACL changes	none (contrast: HttpListener shells need `netsh urlacl`, an admin action)
Files dropped	none - payloads are single `.cs` files compiled into the deserialization, assembly loaded from bytes (`Location` empty)
Effect on unmarked traffic	none - every trigger checks a magic marker first and returns immediately
Pool coverage	`HttpApplicationFactory._freeList` broadcast - arming only the serving instance misses most requests
Graceful degradation	#2 on non-integrated pools catches and passes through (the handshake request still returns 200)

Call chains

#1 HttpModuleShell

delivery deserialization -> E()
 +- HttpContext.Current.ApplicationInstance                 (serving instance)
 +- HttpApplicationFactory._theApplicationFactory._freeList  (pool broadcast)
      per instance:
      +- integrated: GetModuleContainer(<module>)
      |    -> new SyncEventExecutionStep(app, OnRequest)     [reflection]
      |    -> ModuleContainer.AddEvent(BeginRequest, false, step)
      +- classic:    ApplicationStepManager._execSteps append  [append-only]
trigger: request -> BeginRequest -> step -> OnRequest
      +- no MSH-Cmd header -> return (business continues untouched)
      +- header -> cmd.exe /c -> Response.Write -> End

#2 WsTakeoverShell

same anchor; handler is a strict no-op unless handshake + msh
GET + Upgrade: websocket + Sec-WebSocket-Protocol: msh
 -> IsWebSocketRequest check -> AcceptWebSocketRequest(Duplex)
 -> connection upgraded, request pipeline terminates, duplex stream owned by the loop
 -> Receive(cmd) -> exec -> Send(output) ... until Close frame

#3 RemotingUriShell

E()
 +- AppDomain.AssemblyResolve  <- bridges byte-loaded assembly (formatter resolves
 |                                well-known types by assembly NAME)
 +- guard: an IChannelReceiver already exists (business hosts remoting)
 +- RegisterWellKnownServiceType(E.Svc, "msh", Singleton)
trigger: remoting client -> tcp://host:<business-port>/msh -> Svc.Exec(cmd)

Notes

Payloads are delivered as single .cs source files, compiled into the deserialization payload; the assembly is loaded from bytes, so Assembly.Location is empty.
Each trigger checks a magic marker before doing anything, so unmarked business traffic is untouched.
For .NET Framework 4.5+.

Repo: https://github.com/lupingQAQ/dotnet-memshell

JGD: an autonomous agent for Java deserialization gadget chains

lupingQAQ — Tue, 29 Sep 2026 13:35:12 +0000

JGD (JavaGadgetDigger): an autonomous agent for Java deserialization gadget chains

JavaGadgetDigger is an autonomous agent for Java deserialization research. Point it at a JAR directory and it produces gadget chains and weaponized proof-of-concept payloads, with no intermediate user input.

Why the last mile matters

For most Java deserialization work, the hard part is the last mile: you have the classpath in front of you, and you need a working chain from an entry point to a dangerous sink. JGD automates that step end to end.

What it produces

Known public chains with a four-state determination: PRESENT / VERSION / ASSEMBLE / FIRE.
Novel, unpublished chains discovered through static + dynamic analysis with adversarial LLM auditing.
Weaponized PoCs - serialized payloads with an RCE-closure demo (benign marker file).

All decisions are internalized: JARs in, chains out.

Pipeline

Input: any JAR directory          Output: chains + PoCs

  Known    -->  Bridge    -->  Chain   -->   PoC
  Chains        Discovery      Pairing       Weapon
    |               |               |           |
 signature       bytecode        dynamic     benign
 + version       + CHA graph     contract    payload
 gates           + dispatch      synthesis   + fire
                 edges           + 5 carriers test

Discovered chains

T1 - novel entry

Chain	Bridge class	Carrier	JDK
`objlongpair-hashmap`	`org.apache.activemq.artemis.api.core.ObjLongPair`	HashMap rehash	17+

T2 - new bridge classes

Vavr family (7 chains):

Chain	Bridge class	Carrier	JDK
`tuple1-8-hashmap`	`io.vavr.Tuple1` ... `Tuple8`	HashMap rehash	11
`either$left-hashmap`	`io.vavr.control.Either$Left`	HashMap rehash	11
`either$right-hashmap`	`io.vavr.control.Either$Right`	HashMap rehash	11
`option$some-hashmap`	`io.vavr.control.Option$Some`	HashMap rehash	11
`validation$valid-hashmap`	`io.vavr.control.Validation$Valid`	HashMap rehash	11
`validation$invalid-hashmap`	`io.vavr.control.Validation$Invalid`	HashMap rehash	11
`hasharraymappedtrie$leafsingleton`	`io.vavr.HashArrayMappedTrie$LeafSingleton`	HashMap rehash	11

Spring AOP family (6 chains): composablepointcut-hashmap, methodmatchers$unionmethodmatcher, methodmatchers$intersectionmethodmatcher, singletontargetsource-bave, hotswappabletargetsource-bave, defaultintroductionadvisor-bave.

Guava family (3 chains): functions$formapwithdefault, predicates$isequaltopredicate, present.

Other libraries: mutableobj-bave (hutool-core), antlr4-pair-bave (antlr4-runtime), clojure-proxy-hashmap (clojure), jacksoninject$value-bave (jackson-annotations), objectidgenerator$idkey-bave (jackson-databind), tolerantmap-hashmap (snakeyaml), scala-objectref-bave (scala-library).

T3 - variants

ewah-hashmap (JavaEWAH, used by Lucene/Elasticsearch) and the federation*-hashmap family (4 chains, Artemis).

Example dispatch stack (ObjLongPair, T1, JDK 17)

HashMap.put -> HashMap.hash
  -> ObjLongPair.hashCode(ObjLongPair.java:55)
    -> Objects.hash -> Arrays.hashCode
      -> EqualsBean.hashCode -> EqualsBean.beanHashCode
        -> ObjectBean.toString -> ToStringBean.toString -> Method.invoke
          -> TemplatesImpl.defineClass -> payload static block

Quick start

CLI mode (batch audit)

# Install deps (Python 3.10+, JDK 11 and 17, ECJ compiler)
pip install chromadb  # optional, for RAG persistence

# Point at any JAR directory, get chains + PoCs
python3 audit_target.py --target /path/to/jars --name "your-product"

TUI mode (interactive)

python3 tui.py                 # English
python3 tui.py --lang zh       # Chinese

Key bindings: arrow keys or j/k to navigate chains, Enter to toggle detail, t to switch language, q to quit.

Project structure

jgd/
  audit_target.py        # Product CLI entry point
  tui.py                 # Interactive TUI
  jgd/                   # Core agent modules (25)
    verify_agent.py      # Bridge discovery + ds adversarial audit (incremental checkpoint)
    chain_complete.py    # Chain pairing + exhaustion proof (per-item evidence)
    poc_gen.py           # Weaponized PoC generation (heq/jackson/map-dispatch tails)
    known_chains.py      # Public chain four-state determination (155-chain SQLite)
    build_chain_db.py    # Chain DB builder (155 chains, 168 version gates)
    novel_chains.py      # Novel chain auto-tiering (GLM propose + DS verify)
    matrix_agent.py      # Multi-JDK probe orchestration
    bcdisasm.py          # Pure-Python bytecode disassembler
    bridge_fix.py        # Operand-stack symbolic execution
    chroma_store.py      # RAG with corpus-scoped collections
    llm.py               # Dual-model (GLM + DeepSeek)
    scope.py             # Corpus fingerprint isolation
    conductor.py         # Acceptance-gated terminal verdict
    ...
  examples/chains.json   # All discovered chains (machine-readable)
  examples/chains.md     # Human-readable chain catalog
  tests/test_smoke.py    # Third-party reproducible test suite
  ARCHITECTURE.md        # 25-module graph + design decisions
  CHANGELOG.md           # Design decision history (R6-R52)

How it works

1. Public chain determination. A 155-chain SQLite database with per-chain family, source, CVE, trigger method, sink type, JDK range, conditions, and jar version gates. Class signature matching (jar-scoped) plus JDK internal class detection, with per-jar multi-version verdicts (APPLICABLE / BLOCKED / UNVERIFIED) and dynamic assembly + fire verification using the target's own JARs.

2. Novel chain discovery. Static operand-stack symbolic execution detects receiver-bridges, argument-bridges, and Map-dispatch bridges. A real-time corpus-fingerprinted call graph plus CHA dispatch edges and JDK builtin sink seeds. Dynamic batch-parallel JVM probes across 5 carriers, with field-contract synthesis and multi-JDK coverage. Observability via marker reachability, exception stack frames, marker caller-stack, and MAPDISPATCH signals.

3. Adversarial auditing. Dual-model proposal/verification (GLM proposes, DeepSeek verifies) with incremental checkpointing, so verify / chain / poc all resume on the same fingerprint.

Repo: https://github.com/lupingQAQ/JGD

Introducing ntobjmanager-mcp: stateful Windows RPC research for AI agents

lupingQAQ — Tue, 29 Sep 2026 13:34:48 +0000

ntobjmanager-mcp: a stateful MCP server for Windows RPC research

A Model Context Protocol (MCP) server that gives an AI agent live, stateful access to Windows RPC attack-surface research, built on James Forshaw's NtObjectManager (NtCoreLib).

Why it exists

Most "let an LLM drive PowerShell" setups are stateless: every tool call spawns a fresh shell, so the RpcServer object you just parsed, the client you just connected, and any session variables are gone when the call returns. That breaks the workflows RPC research depends on: auth handshakes, context-handle chains, anything where step two needs the object from step one.

ntobjmanager-mcp keeps a single PowerShell engine alive for the whole session and exposes it as 22 fixed tools.

Two things a generic PowerShell MCP cannot do

1. Stateful RPC connections. A persistent powershell.exe keeps parsed RpcServer objects and connected RPC clients alive across tool calls: rpc_connect once, rpc_call many times. Auth handshakes, context-handle chains, and session variables survive.

2. CVE methodology as fixed tools. The standard hunting workflows from 2024-2026 public research ship as one-click tools instead of prompt-engineering.

Architecture

AI Agent (Claude Code / OpenCode / any MCP client)
     |  MCP (stdio, 22 tools)
     v
server.py -- snippets.py (PS templates, @@TOKEN@@ + ps_str escape)
     |
     v
ps_engine.py -- persistent powershell.exe (base64 + __MCP_DONE__)
     |            state: $RPCMCP = @{ Servers; Clients; vars }
     v
NtObjectManager / NtCoreLib  -->  RPC runtime (ALPC / pipe / TCP)

Tool matrix (22)

Core stateful pipeline

Tool	Purpose
`rpc_parse(file, symbol_path?)`	Parse a PE for RPC servers, cache (keys `file_N`)
`rpc_state()`	Cached servers + live sessions
`rpc_get_interface(key)`	Procedures, NDR params, context handles, strictness
`rpc_query_endpoints(ifid?, search_binding?, find_alpc_port?)`	Endpoint-mapper query (local or remote)
`rpc_running_servers(pid?/service?)`	Live process/service enumeration
`rpc_connect(session, key, binding?, auth?)`	Generate + connect a client (stateful)
`rpc_methods(session)`	Signatures with opnum mapping
`rpc_call(session, method, args_json, store_as?)`	Reflection invoke; `{"__var__"}` passes stored objects
`rpc_disconnect(session)`	Drop session

2024-2026 CVE methodology tools

Tool	Methodology source
`rpc_scan_context_handles(paths)`	Context-handle type confusion - CVE-2025-48815 pattern (whereisk0shl 2026)
`rpc_inventory(paths?, limit?)`	Attack-surface inventory + EPM cross-check - MS-RPC-Fuzzer phase 1 (CVE-2025-26651)
`rpc_fuzz(session, dry_run=True)`	Primitive-only default-value fuzzing with ok/denied/error classification - dry-run by default
`rpc_find_hijackable()`	Unregistered interfaces of stopped services - EPM poisoning / RPC-Racer (CVE-2025-49760 / 59200 / 59230)
`rpc_etw_unreachable(duration, trigger_script?)`	Clients calling dead servers - PhantomRPC (Kaspersky 2026), admin required
`rpc_interface_security(key)`	ALPC security descriptor / anonymous-ACE audit - MS-NRPC null session (SafeBreach / Securelist 2025)
`rpc_decode_flags(flags)`	`RpcServerRegisterIf3` flag bitmask decoding
`rpc_format_client(key)`	Export the generated C# client source (offline grep workflow)
`rpc_new_struct(session, type, store_as)`	Build NDR complex types as session vars
`rpc_alpc_squat(name, duration)`	ALPC port squat + connection capture (race validation primitive)
`rpc_accessible_tasks()`	User-startable tasks (Dark-Elevator chain material, CVE-2026-66804 pattern)
`rpc_vars` / `rpc_clear_cache`	Session-variable and cache management (eviction cap 150)

Every tool call is appended to output/mcp_audit.log, so at the end you have a full trace of what the agent actually did.

Quick start

# 1) Prerequisites (one-time)
Install-Module NtObjectManager -Scope CurrentUser -Force
pip install -r requirements.txt            # mcp>=1.2.0 (1.x / 2.x compatible)

# 2) Verify - three suites
python tests\smoke_test.py                 # 17 checks (live MCP stdio round-trip)
python tests\var_test.py                   # 10 checks (store_as / __var__ mechanics)
python tests\audit.py                      # 43 checks (edge cases, hostile paths, concurrency)

# 3) Run the server
python server.py                           # stdio MCP

Add it to an MCP client

Claude Code:

claude mcp add ntobjectmanager-rpc -- python C:\path\to\ntobjmanager-mcp\server.py

Any MCP client (OpenCode opencode.json):

{
  "mcp": {
    "ntobjectmanager-rpc": {
      "type": "local",
      "command": ["python", "C:\\path\\to\\ntobjmanager-mcp\\server.py"],
      "enabled": true
    }
  }
}

How it works

The agent speaks MCP over stdio to server.py, which compiles PowerShell snippets and hands them to a persistent powershell.exe (base64-encoded, with a completion sentinel). All state lives in one PowerShell variable, $RPCMCP = @{ Servers; Clients; vars }. NtObjectManager and NtCoreLib do the actual RPC work underneath, over ALPC, named pipe, or TCP.

Repo and docs: https://github.com/lupingQAQ/ntobjmanager-mcp