Loader/Agent Memory Allocation

The what

Both the agent and loader use an internal contract for memory allocations in the form of a function definition called allocate_memory:

LPVOID allocate_memory ( size_t size, DWORD protection );

This is a simple contract where the caller is asking for a region of memory of the specified size and protection. It doesn't care how it's allocated (or freed). The default implementation just calls VirtualAlloc:

DECLSPEC_IMPORT LPVOID WINAPI KERNEL32$VirtualAlloc ( LPVOID, SIZE_T, DWORD, DWORD );

LPVOID allocate_memory ( size_t size, DWORD protection ) {
    return KERNEL32$VirtualAlloc ( NULL, size, MEM_RESERVE | MEM_COMMIT | MEM_TOP_DOWN, protection );
}

There's a corresponding contract for freeing memory, called free_memory, where the default implementation naturally calls VirtualFree.

DECLSPEC_IMPORT BOOL WINAPI KERNEL32$VirtualFree ( LPVOID, SIZE_T, DWORD );

void free_memory ( LPVOID address ) {
    KERNEL32$VirtualFree ( address, 0, MEM_RELEASE );
}

You obviously need to treat these as related pairs. The freeing function has to be compatible with the allocation function.

The why

This approach allows users to bring their own custom implementation for these two functions, overriding the defaults. This gives much more flexibility than the framework providing pre-made options for you to choose from.

The how

When you extract the client release, you'll see a resources directory that contains the default agent and loader COFF files.

❯ ls resources/
.rw-r--r--  529 daniel 26 Mar 17:32  agent.spec
.rw-r--r--  14k daniel 26 Mar 17:32  agent.x64.o
.rw-r--r-- 4.1k daniel 26 Mar 17:32  libtcg.x64.zip
.rw-r--r-- 1.8k daniel 26 Mar 17:32  loader.x64.o
.rw-r--r--   90 daniel 26 Mar 17:32  socks.spec
.rw-r--r-- 4.6k daniel 26 Mar 17:32  socks.x64.o

To implement custom memory allocation, just write your custom functions in C:

LPVOID allocate_memory_with_foo ( size_t size, DWORD protection ) {
    ...
}

void free_memory_with_bar ( LPVOID address ) {
    ...
}

And build as a COFF file.

x64: bin
    $(CC_64) -DWIN_X64 $(CFLAGS) -c src/memory.c -o bin/memory.x64.o

Copy that COFF into the resources directory and modify agent.spec. You need to load the target COFF, merge it, and then redirect the old call sites to the new ones.

load "agent.x64.o"
    make object +optimize

    load "memory.x64.o" # load my custom memory code
        merge           # merge it with the agent
        
    # redirect calls
    redirect "allocate_memory" "allocate_memory_with_foo"
    redirect "free_memory"     "free_memory_with_bar"

    ...

The same can be applied to the loader if you want your custom memory code to be used in both places. You can, of course, have different COFFs implementing different techniques; merge one into the loader and a different one into the agent. The flexibility is yours.

The +optimize option will ensure that the old [allocate/free]_memory functions will get stripped out of the final PIC. So you don't have to worry about dead code being left behind.