OffensiveGC [MSVC targets]
Offensive GC is an advanced feature in RemoteNET designed to allow objects freezing within unmanaged C++ applications (referred to as Unmanaged Remote Apps). While traditional garbage collection mechanisms are absent in MSVC-based C++ applications, Offensive GC introduces a custom approach to selectively retain objects in memory, preventing some of the target app's deallocation.
In Unmanaged targets (MSVC-compiled C++ apps), holding objects in memory from our injected code can be challenging, as typical memory pointers (void*, not "smart pointers") do not inherently prevent deallocation. Offensive GC addresses this by selectively intercepting and controlling destructor calls and free operations on specified objects, preventing their deallocation if we "froze" them.
The Offensive GC operates by:
- Hooking into destructors,
free, anddeletemethods within the target Unmanaged Remote App. - Maintaining an internal list of pointers to objects being "watched."
- Determining, on a case-by-case basis, whether to bypass deallocation for each "watched" object.
The approach is intentionally selective; only objects designated for retention are protected. This minimizes memory overhead and performance impact on the target application, which otherwise could encounter excessive memory consumption.
Note that hooking is done per module, as to not cause too much of a mess.
Hooking is done on the imports of free, and not the free method inself in the runtime's dll.
The "Offensive" in Offensive GC reflects its role in overriding the target app's expected memory behavior. The app assumes that it manages its own deallocation schedule. Offensive GC introduces a new layer of control, preventing premature (in our eyes) deallocation and thus altering the app's intended memory management practices.
Also, it sounds cool.
Currently, Offensive GC operates exclusively on heap-based objects, where free is used to deallocate.
A future iteration may expand to cover stack-based objects, but those are much harder to "hold", such as the lack of explicit free calls on the stack and reusing of the same bytes without an explicit "allocation" (e.g., getting the address from a malloc call).