Skip to content

Implement high-level .NET API Translation and JIT Metadata Tracing (PR-2) - #174

Merged
kevoreilly merged 2 commits into
kevoreilly:capemonfrom
doomedraven:opt/dotnet-api-translation
Aug 21, 2026
Merged

Implement high-level .NET API Translation and JIT Metadata Tracing (PR-2)#174
kevoreilly merged 2 commits into
kevoreilly:capemonfrom
doomedraven:opt/dotnet-api-translation

Conversation

@doomedraven

Copy link
Copy Markdown
Contributor

Overview of .NET API Translation inside opt/dotnet-api-translation:

Currently, capemon JIT monitoring operates strictly at the binary bytecode level, logging only generic messages like "Dumped decrypted .NET JIT MSIL bytecode at 0x%p". While valuable for payload recovery, it
provides the analyst with zero context regarding the meaning of the executing code.

To elevate this to High-Level .NET API Translation, we engineered a highly sophisticated, crash-safe metadata resolution engine directly inside hook_clr.c:

  1. Interface Interrogation (ICorJitInfo):
    During JIT compilation, the Common Language Runtime (CLR) passes a pointer compHnd (an ICorJitInfo C++ class) to compileMethod.
  • Because ICorJitInfo uses multiple virtual inheritance, its virtual method layout can be complex.
  • However, getMethodName is defined as the first method of the base interface ICorMethodInfo. In MSVC, this maps directly to index 0 inside the main virtual method table (vtable).
  1. Safe, SEH-Protected Resolution (SafeGetMethodName):
    To execute this safely from pure C without risking crashes due to version-dependent VTable shifts between different .NET Framework and .NET Core runtimes, we implemented SafeGetMethodName:
  • Wrapped completely in a Structured Exception Handling (SEH) block (__try / __except) to safely trap any access violations.
  • Resolves getMethodName dynamically and executes it by passing the opaque method handle info->ftn.
  • Incorporates strict pointer probe validation checks (verifying that the returned method name and class/module name pointers are indeed valid, readable ASCII strings in memory) before using them.
  1. Behavioral Log Integration:
    When a method is compiled, we now extract its fully qualified name (e.g., System.Net.WebClient.DownloadData) and write it directly to the behavioral log under the unifed "dotnet" category using LOQ_string:

1 LOQ_string("dotnet", "ss", "Class", className ? className : "UnknownClass", "Method", methodName);

Impact:
Analysts now get a high-fidelity, readable execution trace of the .NET binary's inner workings on the CAPE timeline, showing exactly which classes and APIs are being compiled and executed in real-time!


doomedraven and others added 2 commits August 18, 2026 12:39
…R-2)

Surgically implements the second PR of our .NET modernization roadmap inside hook_clr.c:
1. Implements a crash-safe, SEH-protected SafeGetMethodName helper function that accesses the getMethodName virtual method (index 0) from the ICorJitInfo/ICorMethodInfo vtable.
2. Incorporates robust pointer-read validation probe checks to guarantee absolute crash-protection across all .NET Framework and .NET Core versions.
3. Automatically translates and logs the exact fully qualified Class and Method names (e.g. System.Net.WebClient.DownloadData) being JITcompiled inside compileMethod to the behavioral log under the "dotnet" category, providing a powerful, high-level API execution trace.
@kevoreilly
kevoreilly merged commit 4fa7bd1 into kevoreilly:capemon Aug 21, 2026
@doomedraven
doomedraven deleted the opt/dotnet-api-translation branch August 21, 2026 15:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants