fix(dotnet): Resolve JIT vtable slot issues and add comprehensive V2-V5 ABI translation support (1.1 to 10.0)

[doomedraven]

Will be testing this fixes tomorrow

The crash in SafeGetMethodName during detonation (especially on samples like Formbook that hook, inject, or tamper with .NET runtimes) typically happens due to three core issues in x86 CLR interaction:

---

1. Calling Convention Mismatch (__thiscall vs __stdcall) on x86

In 32-bit MSVC, methods in ICorJitInfo / ICorMethodInfo use the __thiscall convention (where this is passed in register ECX), unless explicitly declared as COM STDMETHODCALLTYPE.

When defined as:

typedef const char* (__stdcall *fnGetMethodName)(PVOID _this, PVOID ftn, const char** moduleName);

• What happens: compHnd is pushed onto the stack as the first argument instead of being loaded into ECX.
• Inside clr.dll: The method reads whatever garbage was in ECX as its this pointer (CEEJitInfo*), and reads compHnd from the stack thinking it is ftn (CORINFO_METHOD_HANDLE).
• Stack imbalance: The callee cleans 8 bytes (ret 8), but your caller pushed 12 bytes. This corrupts ESP, leading to an immediate crash or an uncatchable stack corruption.

Fix for x86 MSVC: Use __thiscall with compHnd passed as the this argument:

typedef const char* (__thiscall *fnGetMethodName)(PVOID _this, PVOID ftn, const char** moduleName);

---

2. CLR FailFast Bypasses __try / __except

SEH (__try / __except) cannot catch Windows Fast Fail exceptions (STATUS_FAIL_FAST_EXCEPTION / __fastfail).

Inside clr.dll, CEEJitInfo::getMethodName performs sanity checks on the ftn pointer (casting it internally to MethodDesc*). Formbook frequently performs process hollowing, runtime injection, or dynamic method invoke with synthetic/obfuscated tokens:

• If ftn is not a valid MethodDesc or points to a dynamic stub without metadata, CLR's internal runtime contracts/assertions trigger an immediate **EEPolicy::HandleFatalError / FailFast**.
• The OS immediately terminates the process without unwinding the stack to your __except handler.

---

3. Vtable Index Instability Across CLR Versions

vtable[0] is not guaranteed to be getMethodName across every .NET CLR release:

• In ICorMethodInfo (defined in corinfo.h), getMethodName is preceded by getMethodDescFromMethod or debugging methods depending on the CLR build and architecture.
• In some .NET 4.x clr.dll builds, index 0 is getMethodDescFromMethod (virtual MethodDesc* getMethodDescFromMethod(CORINFO_METHOD_HANDLE ftn)), which expects 1 parameter, not 2.

---

Recommended Defensive Implementation

To prevent detonation termination, verify compHnd memory readability, ensure __thiscall on x86, and validate that ftn resides in valid readable memory before invoking:

#if defined(_M_IX86)
typedef const char* (__thiscall *fnGetMethodName)(PVOID _this, PVOID ftn, const char** moduleName);
#else
typedef const char* (__fastcall *fnGetMethodName)(PVOID _this, PVOID ftn, const char** moduleName);
#endif

static const char* SafeGetMethodName(PVOID compHnd, PVOID ftn, const char** moduleName) {
    const char* name = NULL;
    if (moduleName)
        *moduleName = NULL;

    if (!compHnd || !ftn)
        return NULL;

    __try {
        // 1. Verify compHnd and vtable pointers are readable
        PVOID* vtable = *(PVOID**)compHnd;
        if (!vtable || !vtable[0])
            return NULL;

        // 2. Ensure ftn points to readable memory before passing to CLR
        if (IsBadReadPtr(ftn, sizeof(PVOID)))
            return NULL;

        fnGetMethodName getMethodName = (fnGetMethodName)vtable[0];
        name = getMethodName(compHnd, ftn, moduleName);

        // 3. Validate string pointers
        if (name && IsBadStringPtrA(name, 256))
            name = NULL;

        if (moduleName && *moduleName && IsBadStringPtrA(*moduleName, 256))
            *moduleName = NULL;
    }
    __except (EXCEPTION_EXECUTE_HANDLER) {
        name = NULL;
        if (moduleName)
            *moduleName = NULL;
    }

    return name;
}

[doomedraven]

note for myself to get the slot id

The only missing piece is one integer: the vtable slot of CEEJitInfo::getMethodName in clr.dll. Fill it into GetMethodNameSlot's Framework case and it works, x86 and x64.

Getting the number (pick one)

Static, reproducible, no malware needed — load clr.dll in IDA/Ghidra with the Microsoft PDB (.symfix equivalent / symbol server), find CEEJitInfo::getMethodName, find the xref from the vtable ??_7CEEJitInfo@@6B@, slot = (entry − vtable_base) / ptr_size.

Live, WinDbg:

0:000> .symfix ; .reload
0:000> sxe ld:clrjit ; g
0:000> bp clr!CEEJitInfo::compileMethodHelper   ; (or bm clr!*compileMethod*)
0:000> g
;  x64: comp (ICorJitInfo*) is in rdx    ->  dps poi(@rdx) L140
;  x86: comp is at poi(@esp+8)           ->  dps poi(poi(@esp+8)) L140
;  find the row that resolves to clr!CEEJitInfo::getMethodName
;  slot = (row_addr - vtable_base) / @$ptrsize

Do it on the clr.dll builds that actually matter — realistically just 4.8.x (Win10/11) covers ~all modern samples; add 4.7.2 / 4.6.x only if you analyse older images. If 4.8 servicing turns out to shift it, we add file-version keying then (that's ~40 lines to read clr.dll's RT_VERSION resource without touching hooked APIs — I'll do it if/when needed).

Once you have the slot(s), it's:

case DOTNET_RT_FRAMEWORK:
    *abi = METHOD_NAME_ABI_FRAMEWORK_V2;
    return <slot>;   // clr.dll 4.8.x, verified via dps <date>

[doomedraven]

@kevoreilly the docs structure is fine for you? is for future versions handling semi-automatically