Guide [Source] DiscordHook64 — Hijacking Shared Section for Traceless Overlay

[byte_corvus]

If you're looking for a stealthier way to render visuals without creating top-level windows or messing with hijackable overlays that every AC already flags, this is the move. We're talking about hijacking the shared memory section DiscordHook64 uses for its framebuffer.

The Concept
Discord's overlay maps a shared file into memory to handle the frame buffer. By finding where DiscordHook64.dll maps this section, you can write your own frame data directly into it. Since the internal module handles the actual swap to the game window, your overlay becomes essentially "traceless" from a window-enumeration perspective.

Data Structure
First, you need the header structure for the shared section. This is what Discord expects to see:

typedef struct _Header
{
    UINT Magic;
    UINT FrameCount;
    UINT NoClue;
    UINT Width;
    UINT Height;
    BYTE Buffer[1];
} Header;

Implementation Logic
The trick is finding the base module of DiscordHook64.dll and reading the pointer to the mapped file. In recent builds, the offset is 0x130E58.

1. Grab the module base for DiscordHook64.dll.
2. Read the mapped file address from the offset.
3. Write your Width and Height to the header.
4. Copy your pixel data (BGRA format) into the buffer.
5. Increment FrameCount. This is the trigger—it tells the internal module to copy the framebuffer over to the screen.

Technical Implementation (External/Kernel Style)

uintptr_t DiscordHook64 = get_module_base(process_id, L"DiscordHook64.dll");
if (DiscordHook64) 
{
    uintptr_t mapped_file = Read<uintptr_t>(DiscordHook64 + 0x130E58);
    if (mapped_file) 
    {
        SendFrame(mapped_file, frame.Width, frame.Height, frame.Buffer, frame.Size);
    }
}

inline void SendFrame(uintptr_t mapped_address, UINT width, UINT height, void* frame, UINT size)
{
    Write(mapped_address + offsetof(Header, Width), &width, sizeof(UINT));
    Write(mapped_address + offsetof(Header, Height), &height, sizeof(UINT));
    Write(mapped_address + offsetof(Header, Buffer), frame, size);

    UINT currentFrameCount = Read<UINT>(mapped_address + offsetof(Header, FrameCount));
    currentFrameCount++;
    Write(mapped_address + offsetof(Header, FrameCount), &currentFrameCount, sizeof(UINT));
}

Critical Troubleshooting

Spoiler: The 2MB Page Trap

If you find that your rendering works for the first 4KB page (you might see a single white line or flickering) but fails after that, check your virtual address translation logic. If you're working at a low level (kernel/manual translation), make sure you aren't strictly checking the read/write bit in 2MB pages incorrectly. Ensure your translation handles large pages properly to avoid failing on the mapping boundaries.

This method is extremely clean for external projects that need a high-performance overlay without the usual detection vectors. Just keep an eye on the offsets when Discord updates their DLL.

anyone else tweaked this for different overlay modules?