Skip to content

Track and expose Module Overloading evasion techniques - #199

Open
doomedraven wants to merge 3 commits into
kevoreilly:capemonfrom
doomedraven:opt/module-overloading-detection
Open

Track and expose Module Overloading evasion techniques#199
doomedraven wants to merge 3 commits into
kevoreilly:capemonfrom
doomedraven:opt/module-overloading-detection

Conversation

@doomedraven

Copy link
Copy Markdown
Contributor

No description provided.

doomedraven and others added 3 commits September 8, 2026 21:14
…erloading detection

## Issues Fixed

1. **Use-After-Free in Dynamic Module Name Resolution**
   - Fixed memory management bug where `dynamic_module_name.Buffer` pointed
     directly into freed `absolutepath` memory in:
     - NtMapViewOfSection
     - NtMapViewOfSectionEx
     - NtProtectVirtualMemory
     - VirtualProtectEx
   - Solution: Use stack-allocated basename_buffer instead of pointing into
     freed heap memory. Buffer now stays valid through logging calls.

2. **Missing NULL Check for get_dll_basename()**
   - Added NULL check before using basename to prevent potential crashes
     or invalid logging in all four functions.

3. **Format String Mismatch in NtCreateSection**
   - Fixed format string from "PhopiipF" (8 characters) to "PhopipF" (7 characters)
   - Was causing logging macro to misinterpret parameters when accessing
     FileHandle and FileName fields.

4. **Improved Memory Safety**
   - basename_buffer properly null-terminated with bounds checking
   - Prevents buffer overruns and use-after-free scenarios

The fixes ensure module names are captured safely during module overloading
detection without risk of memory corruption or crashes.
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.

1 participant