Question Custom CRT & HeapAlloc Detection — Safe Allocation Methods

[byte_corvus]

Anyone currently digging into CRT-less builds has probably hit this wall. When you're trying to strip dependencies like ucrt.lib or vcruntime.lib to keep your import table clean, you realize that standard

malloc

and

new

implementations are essentially just thin wrappers around

HeapAlloc

The problem isn't just the import itself; it's how anti-cheats handle heap scanning. If a proactive AC decides to walk the heap and finds a chunk of memory that doesn't correspond to a signed module or looks orphaned, you're looking at a flagged account or a manual ban.

The Technical Dilemma
If you're building a custom CRT, you need a way to manage memory that won't scream "I'm a cheat" to a kernel-level driver. Standard

HeapAlloc

is convenient, but it leaves traces that are easily audited by stack walking and heap metadata analysis.

1. Heap Walking: ACs can verify if the memory block belongs to a legitimate heap created by the process or if it's some suspicious standalone allocation.
2. Signed Memory: If the memory doesn't map to signed space or legitimate segments, it's a massive red flag during routine scans.
3. Traceability: Syscall hooking or APC-based scanning can catch

   NtAllocateVirtualMemory

   calls if you try to bypass the heap entirely without proper spoofing.

Spoiler: Potential Workarounds

1. Manual Implementation of dlmalloc: You can implement something like dlmalloc on top of a single large hijacked region within a legitimate module to blend in.
2. Direct Syscalls: Use direct syscalls for

   NtAllocateVirtualMemory

   to avoid user-mode hooks, though this won't help against kernel-level heap walking if your VADs look suspicious.
3. Proxying Game Allocs: Hunt for the game's internal operator new or its private heap handle. Blending into the game's own memory footprint is significantly safer than spawning your own heap.

Risks and Considerations
Building a safe CRT isn't just about hiding imports; it's about staying consistent with the target process's architecture. If you're running an internal and the game uses a specific allocator, your "stealthy" custom allocation might stick out because it fails standard consistency checks used by modern AC integrity modules.

While others are catching bans from broken free injectors and messy

malloc

pastes, mastering memory management and stripping dependencies is the only way to maintain a long-term UD status.

who's run a custom heap setup successfully against EAC lately?