libmem: process memory, hooking and code injection as a portable C library

A primitives library, with the cheat examples as documentation

The repository describes itself as an advanced game hacking library for C, modern C++, Rust and Python, and the feature list is a list of operating system primitives: internal and external modes, finding and enumerating processes, modules, symbols, threads and segments, reading and writing memory, allocating and protecting memory, scanning memory by pattern or signature, resolving pointer scans and pointer maps, hooking and unhooking functions, assembling and disassembling code for JIT use, hooking and unhooking virtual method tables, and loading and unloading modules.

None of those are cheats. They are the operations that any low-level reverse engineering tool needs, and the README's examples are the author showing the shortest path from each primitive to a working result.

The C example is the clearest. It finds a module by name, resolves a symbol inside it, and installs a hook:

#include <libmem/libmem.h>

void hk_take_damage(int amount)
{
  printf("hooked take_damage! no damage will be taken\n");
  return;
}

int main()
{
	lm_module_t game_mod;
	lm_address_t fn_take_damage;

	LM_FindModule("game.dll", &game_mod);
	LM_FindSymbolAddress(&game_mod, "take_damage");
	LM_HookCode(fn_take_damage, hk_take_damage, LM_NULLPTR);

	return 0;
}

The Rust and Python examples push further. The Rust one does a signature scan for a byte pattern with wildcards, assembles shellcode with an architecture argument, and writes it over the original function. The Python one resolves a Cheat Engine style pointer scan and then writes a value to it in a loop.

So the library is a toolkit, and the examples are the tutorial. Whether that combination is useful to you, and whether it is lawful and within the rules of whatever you point it at, are two separate questions.

The platform matrix decides whether you can use it at all

The README publishes a support matrix with three operating systems and four architectures, and the legend distinguishes 100% working, mostly working and untested.

For Windows, x86 and x64 are both marked as 100% working. For Linux, x86 and x64 are also 100% working. For FreeBSD, both x86 and x64 are marked as mostly working rather than fully working. The ARM and Aarch64 columns are marked untested for all three operating systems.

That is the single most important line in the README for an adopter, and it is the kind of thing that gets missed. The library is a low-level one, working directly with process memory, page protection and instruction bytes, and the places where an instruction set differs are exactly the places where a library like this has the most work to do. A Raspberry Pi or an ARM server is not a supported target in practice, whatever the table's shape suggests.

The FreeBSD row is a smaller caveat and a more interesting one. Mostly working on both architectures means the code paths exist and are believed to function, and it also means the author does not claim the same confidence there as on the two systems where the marks are complete. For an operating system where the memory model and the system calls differ from Linux, a partly tested port is worth knowing about before you depend on it.

The package is otherwise self-contained in the sense that it works across all three systems behind one API, which is the whole point of it. The cost of that abstraction is the matrix, and you should read the matrix before the features.

The documentation is the header, and the examples are the other half

The documentation section is unusual and worth describing exactly, because it changes what you have to do to learn the library.

The main documentation for libmem can be found in include/libmem.h, and all APIs are documented with very descriptive information about each function, their parameters and return value, located in nearby comments so you should be able to see them by hovering on your text editor or IDE. The bindings documentation is embedded with their packages in the same way.

So the reference manual is a header file. That is a real pattern in systems programming, where the header is the interface and the implementation is an implementation detail, and it has a practical consequence: you learn the library by opening one file and reading it, rather than by browsing a documentation site. The cost is that there is no task-oriented guide, no narrative introduction and no examples of how to compose the primitives, which is why the README's code samples carry more of the teaching load than they appear to.

The examples themselves are the answer to that. The C++ one is a self-contained disassembler loop that decodes the main function until it finds a ret instruction, printing each instruction and its bytes, and it includes the expected output in the comment. The Python one resolves a pointer and writes to it on a timer. The Rust one combines a signature scan with assembled shellcode.

Between a documented header and four worked examples, the learning material is complete but entirely local. There is no hosted documentation site, no tutorial series and no API explorer, which is a reasonable trade for a library of this kind and a real cost in time for a newcomer.

Four official bindings and three that are not

The library ships bindings for C, modern C++, Rust and Python, and the four examples in the README are written in four different languages against the same core.

The C binding is the native interface, the C++ one is a header with a namespace and a modern interface, and the Rust and Python ones are idiomatic wrappers, with the Rust example using Option for fallible calls and the Python one using bytearray for the write. The C++ example requires C++20 or higher, which the comment in the code states.

The unofficial bindings section lists three more, and it is careful about the wording. These bindings are done by the community or third parties and are not affiliated with the libmem project or its author, and their code can have their own licenses as well, diverging from libmem's. The three listed are Nim_Libmem, Crazymem for NodeJS and Go Libmem.

That disclaimer is more than boilerplate. A binding is code that touches process memory through your call, and a third-party binding is code you did not write, in a language the project does not test, that will run with the same privileges as whatever you are hooking. For a library whose use is inherently about modifying another process, the trust boundary around the bindings is not a formality.

The same caution applies to the note in the licence section, which says that submodules and external dependencies might have their own licenses and that you should check for their licenses as well. The repository does carry a .gitmodules file and an external/ directory, and a dependency with its own terms is a dependency.

Two installation routes, and a CMake fetch that downloads binaries

There are three documented ways to get libmem onto a project, and one of them does something you should know about before running it.

The first is CMake without installing, using FetchContent. The README gives the commands to add to your CMakeLists.txt: they fetch libmem-config.cmake from the root of the repository, which will download libmem binaries for your system and include libmem in your CMake project.

include(FetchContent)

# Download and set up libmem
FetchContent_Declare(libmem-config URL "https://raw.githubusercontent.com/rdbo/libmem/config-v1/libmem-config.cmake" DOWNLOAD_NO_EXTRACT TRUE)
FetchContent_MakeAvailable(libmem-config)
set(CMAKE_PREFIX_PATH "${libmem-config_SOURCE_DIR}" "${CMAKE_PREFIX_PATH}")
set(LIBMEM_DOWNLOAD_VERSION "5.1.4")

# Find libmem package
find_package(libmem CONFIG REQUIRED)

Then linking is a single line, target_link_libraries against libmem::libmem, with a note that it might be necessary to link against other dependencies, pointing at the Dependencies section of the documentation.

The second route is vcpkg, with the package published there and a single command, vcpkg install libmem, with a link to Microsoft's own instructions for installing specific versions.

The third is the Windows path, and it is the one to read carefully. The README notes that if you download a binary version of libmem in the GitHub releases, you only need to install the Windows SDK, that building is not necessary, and that you just add libmem/include to your project's include directories and link it against the binary you downloaded. The listed prerequisites are the Windows SDK, Python 3 with the note to use 3.8.9 for Windows 7, Visual Studio 2022 or newer with C++ support and CMake, and Git Bash.

A project that fetches a prebuilt binary at configure time is convenient and it is a supply chain decision, so it belongs on the review checklist rather than in a README skim. The repository does have a Dockerfile, an alpine base with gcc, g++, gdb, git, cmake, make, python3 and the kernel headers, which is a reasonable environment for building it yourself.

AGPL-3.0, and the question of what you point it at

The licence is the GNU AGPLv3.0 with no later versions, and the README points at the LICENSE file. The AGPL is the strong copyleft licence, and for a library that links into other software it is a meaningful constraint, particularly for anything that is offered over a network. The explicit no later versions wording means the choice is deliberate rather than a default.

The platform table is followed by a features list and a note that this project is licensed under the AGPLv3.0, no later versions, and a separate note that submodules and external dependencies might have their own licenses.

Now the part that no technical document can resolve for you. These primitives exist to modify the behaviour of a running process, and the examples show them used to patch a function in a game so that damage is never taken and a health value is set to a fixed number. That is the intended demonstration. Pointing any of it at software you do not own, or at an online game whose terms of service prohibit modification, is a breach of those terms whatever the licence of the library says, and in the case of an online game it is also a route to a ban. A library being permissively licensed, or even aggressively copyleft, says nothing about whether the use is allowed.

So the honest framing is that libmem is a systems-level reverse engineering and instrumentation library, in the same family as a disassembler or a debugger, with the same dual-use properties and a much lower barrier to the interesting operations. It is the right tool for instrumenting software you own, for research, and for understanding how a binary behaves. It is the wrong tool for anything where the answer is that you should not be modifying that process, and no licence makes that answer different.

Editorial conclusion

libmem fits a systems programmer who needs the same low-level primitives across Windows, Linux and FreeBSD, in one API with bindings in the language their tooling is written in, and who is willing to read a header file to learn it. It does not fit a project that needs working ARM support, since the README marks those columns untested, and it does not fit a team that cannot accept AGPL terms or a native dependency with submodules of its own. Before you build on it, confirm the architecture you target is in the working column, and decide deliberately whether your use is instrumenting software you own, because pointing it at a third-party game is a terms of service problem before it is a technical one.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. rdbo/libmem on GitHub
4. README
5. Releases