rdbo / libmem Goto Github PK

I just noticed there's a problem in mem_string_replace and I'm working on it. Just opening this issue to let you know.

Problem 1: Slow scan if the scanned memory length is too big
Problem 2: Returns the wrong value on Windows when scanning big chunks of memory
Thanks to @karliky for pointing the issues

Title says it all

The build scripts are made for bash and it might not be installed or it might not be at /bin. Run the following commands as root:
pkg install bash
ln -s /usr/local/bin/bash /bin/bash
The build scripts should work fine now.

The file internal.h was useful when there were helpers; now they're gone so the file seems useless. I will keep it until I manage to solve most of the other issues just to make sure I really won't use it. If I can manage to solve the other issues and the file remains useless, it will be deleted.

If the current commit of libmem is not working, use the latest release.
If you're already using the latest release, try the latest commit.
If neither of them work, open a new issue.
Releases: https://github.com/rdbo/libmem/releases

Working on it.

LIEF is a C++ library that can parse multiple types of binaries and among other features, dump their debug symbols.
As mentioned in the issue #26, libmem has to become more modular. Maintaining all of these features by myself is not a good idea, especially since there are libraries out there that will do a better job.
I have been trying to use LIEF on libmem, but because it is a C++ library, I've had a few problems integrating it. Nonetheless, I still think it's important to use it.

Some things in libmem are not properly named. For example, LM_GetProcessIdEx. It should be something like LM_FindProcessId, since it has no guarantee that it will be got or not - on the other side LM_GetProcessId is always going to succeed by returning the current process ID.

The tests cover a lot of libmem's surface area, but they still don't test everything, like LM_HookCodeEx. That should change.

How do you go about doing subroutine hooks, like how zeex/subhook does it?

I almost figured out how all of libmem's API works, which is awesome 😁

I wish to document it sometime in the future, to better hope those who may need it. libmem is definitely a fantastic replacement to doing this stuff other ways.

That might be due to your procfs not being mounted. You'd have to manually do so by running the following command:
mount -t procfs proc /proc
To automatically mount the procfs on boot, you'd have to add the following line to /etc/fstab:
proc /proc procfs rw 0 0
If your problem is not solved, open another issue.

Source: https://stackoverflow.com/questions/5486317/could-not-find-proc-self-maps

process_vm_readv & process_vm_writev methods not found in android

Android NDK: APP_PLATFORM not set. Defaulting to minimum supported version android-16.
Android NDK:
[armeabi-v7a] Compile thumb  : mem <= libmem.c
jni/libmem.c:3020:24: warning: implicit declaration of function 'process_vm_readv' is invalid in C99 [-Wimplicit-function-declaration]
                rdsize = (lm_size_t) process_vm_readv(proc.pid, &iodst, 1,
                                     ^
jni/libmem.c:3086:23: warning: implicit declaration of function 'process_vm_writev' is invalid in C99 [-Wimplicit-function-declaration]
                wrsize = (lm_size_t)process_vm_writev(proc.pid, &iosrc, 1,
                                    ^
2 warnings generated.
[armeabi-v7a] SharedLibrary  : libmem.so
ld: error: undefined symbol: process_vm_writev
>>> referenced by libmem.c:3086 (jni\libmem.c:3086)
>>>               ./obj/local/armeabi-v7a/objs/mem/libmem.o:(LM_WriteMemoryEx)

ld: error: undefined symbol: process_vm_readv
>>> referenced by libmem.c:3020 (jni\libmem.c:3020)
>>>               ./obj/local/armeabi-v7a/objs/mem/libmem.o:(LM_ReadMemoryEx)
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [C:/Users/Unknow/AppData/Local/Android/Sdk/ndk/23.0.7123448/build//../build/core/build-binary.mk:718: obj/local/armeabi-v7a/libmem.so] Error 1```

Windows has an API that will fetch page information of a given address, so there no need to enumerate all pages until it finds that address on Windows.

So, I'm working on adding Node.js bindings to this library to use it with JavaScript. 🚀

While working on this I found something weird, looks like mem_ex_get_module doesn't work:

    PID:                8020
    Process Name:       explorer.exe
    Process ID:         8020
    Module Name:
    Module Path:
    Module Base:        0000000000000000
    Module Size:        0000000000000000
    Module End:         0000000000000000

The first 3 lines are from mem_ex_get_pid and mem_ex_get_process and they do work fine 👍 . Then comes process_mod_ex and they look empty or filled with 0000000000000000. The process name I'm using it's explorer.exe

Here is the source code, which I copied from https://github.com/rdbo/libmem/blob/master/example/example.cpp:

	mem_pid_t pid_ex = mem_ex_get_pid(mem_string_new(PROCESS_NAME));
	tprint("PID:                %i", pid_ex);

	//-- Get Process Information
	mem_process_t process_ex = mem_ex_get_process(pid_ex);
	tprint("Process Name:       %s", mem_string_c_str(&process_ex.name));
	tprint("Process ID:         %i", process_ex.pid);

	//-- Get Process Module
	mem_module_t process_mod_ex = mem_ex_get_module(process_ex, mem_string_new(PROCESS_NAME));
	tprint("Module Name:        %s", mem_string_c_str(&process_mod_ex.name));
	tprint("Module Path:        %s", mem_string_c_str(&process_mod_ex.path));
	tprint("Module Base:        %p", process_mod_ex.base);
	tprint("Module Size:        %p", (mem_voidptr_t)process_mod_ex.size);
	tprint("Module End:         %p", process_mod_ex.end);

Am I doing something wrong? 🧑‍💻

Here is the whole source code just in case it helps:
bindings.txt

Hi!

Do you plan to add them? Very much it would be useful

Hi,

I would like to use mem.read for reading android memory simple functions like
so it will be basically
long addressreturn=Read(address);
string stringreturn=ReadString(address,ize,bytesToRead);

#if defined (arm)
//arm read syscall for process_vm_writev 377
int syscallWrite = 377;
//arm read syscall for process_vm_readv 376
int syscallRead = 376;

Problem with me is i get read data error because entity might be removed and i try to read it it cause the memory stack crouption. and i get detected.

if you build that class for me i can pay you
i know its quick work for you but it will support your time.
please do let me know my discord is Hammad2224#9851

Thanks
Regards,
Hammad

Functions like LM_GetModule have the flag parameter in the start of the function, which does not look very nice.

It gets a bit hard to find useful information from the compiler when it's generating hundreds of lines of warnings. They have to either be fixed or disabled.

Title says it all

I have learned Rust a while ago, and I want to (at some point) port libmem to Rust. I can't promise anything though, since I've never ported any C APIs to Rust and since I have to solve all of the other issues first.

libmem is a project I have work on and off for a very long time. It has had many different versions, one completely different than the other, because the more I got better at programming, the more ideas I had to make it better.
Unfortunately, libmem has become practically unmaintainable, mainly for the following reasons:

• It is not modular: everything is on libmem.h and libmem.c, including the code for all different platforms and architectures, making it a mess with all the preprocessor directives.
• It has too many features: libmem should have followed the KISS process (Keep It Simple Stupid), instead of adding too many features, such as multiple different hooking methods, debugger functions, overly-complicated code injection (such as the LM_FunctionCallEx).

So how to fix it?
My plan is to do the following:

• Modulate libmem: I could do that by separating the OS-specific and Arch-specific code, and rely on better written third-party libraries, such as the addition of the capstone and keystone libraries instead of writing my own assembler/disassembler. I'm not sure yet how am I going to modulate it in practice because everything is so entangled together, but I'm sure there is a way.
• Remove overkill features: offer only one hooking method per architecture, no debugging functions as they're not the main focus of libmem, etc.
• Follow a Unix-like directory structure for the project: instead of putting everything under the libmem folder, there should be a include and source folders (like in capstone and keystone, similar to the Unix /usr directory), since the library should be compiled first and then included into your project, and not compiled along with your project.
• Make it 'installable': At least on Unix-like systems, there should be a way to install the libmem shared library into /usr/local/lib to make it easier for linking the library.
• Add better documentation: there used to be a documentation, but since the project started changing very often, I deleted the old one. After all of other points are fixed, there should be a very detailed documentation about all libmem APIs to make developer's lives easier.

These are only the stuff I could remember right now, and I hope I can close this issue in the future.
If you want to contribute, make a pull request.
There's a lot of work ahead of libmem.

Working on it. It's taking a long time to read the /proc/<pid>/map file. I'll try different approaches.

Some functions call mem_*_protect to change the page protection and do not restore the original protection back. A fix might be out soon.

I have a project where this library was needed for taskmanager(thank you!) and while working on it, I found something rather strange with mem::in::detour_trampoline (or I am using it incorrectly) as the trampoline executes but the returning gateway fails to return.
this is how the detour was created:
o_function= (function_t) mem::in::detour_trampoline(IsServer, (void *)IsServerHook, mem::in::detour_size(MEM_ASM_x86_JMP64), MEM_ASM_x86_JMP64);
and here is the respective hook:

typedef bool(* function_t)(void *ret);
bool __fastcall IsServerHook(void *ret)
{
    GlobalSettings = ret;
    std::cout << "exe" << std::endl;
    return o_function(ret);
}

it prints out the exe string and then upon return, process crashes.
before jumping(executes):

returning back(crashes on 'ret' instruction):

The old one was a mess. The current one uses the POSIX regex.h header, which is better. But it has not been implemented yet.

The LM_Assemble and LM_Disassemble functions can only do operations with one instruction at a time right now, but the Capstone and Keystone libraries offer support for doing things with multiple instructions.
The idea is to find a way of adding an API that can take/write multiple instructions, but avoiding memory allocations and memory leaks somehow. If avoiding those things isn't possible, then the developer will be responsible for freeing the memory later.

Title says it all

Instead of having LM_MakeTrampoline, LM_DestroyTrampoline, etc, what could be done is have a single LM_Detour function that has a parameter which would be the pointer to a trampoline. If that pointer is not null, generate the trampoline. If it is null, don't do anything.
Prototype:

LM_API lm_size_t
LM_Detour(lm_address_t src, lm_address_t dst, lm_address_t *ptrampoline);

LM_API lm_bool_t
LM_RestoreDetour(lm_address_t ptrampoline, lm_size_t size);

Find a way to force CMake to compile libmem and all of its dependencies in 32 bits.

It would be more optimized to read a section of the /proc/<pid>/maps file at a time and parse it; if the results were found, free the buffer and return; else, just read once again. This might be applicable to other files, such as /proc/<pid>/status, but since they're not so big, it might not be necessary for performance increase. Instead, it might be a good idea to read until the end of life and pass the read line to a function.

Unlike on Linux, where the pages are acquired through /proc/<pid>/maps, the Windows function tries to get all valid pages starting from address 0, which would be extremely slow when compared to only looping through the allocated pages.

Hi, I really enjoyed your guide back then. But I can't seem to find it again. What happened to it?

Title says it all

Since the library is being modulated, there's no need to include every single required header on libmem.h and import all of that stuff into the other programmer's source code; instead, move them to headers or source files in src/.

Link: https://discord.com/invite/Qw8jsPD99X

There's no need to keep the old v3 API on the code, it just adds more mess and trouble to maintain.

This function alone is ~400 lines long, which clearly indicates that it must be broken down somehow.

After most of the current issues (mainly #26) have been solved, there should be a full code review to find flaws in the code before proceeding.

The current version of LM_LoadModuleEx is using the overly complicated LM_FunctionCallEx API, which is not good, specially since that API will most likely not be present anymore.

The "object" that will be freed/destroyed should be passed in as a pointer, and its value should become NULL.
For example, LM_UnhookCode does not take the trampoline as a pointer, but it should, because the trampoline will be freed.

I found out that external functions related to code injection on Linux might cause the target program to crash.
The functions doing code injection are:

mem_ex_protect
mem_ex_allocate
mem_ex_deallocate
mem_ex_load_library

Currently unsupported architectures, let's say for example RISC-V, should not be build on the Capstone and Keystone libraries. This would generate a smaller binary, and also save compilation time.

Somewhere in the code, an invalid address is being free'd. I'm still looking for this problem and it might take some time to even identify where is this occurring

Hi, by referencing your AssaultCube-Multihack of this line:

Data::oSwapBuffers = (SwapBuffers_t)mem::in::detour_trampoline(Data::pSwapBuffers, (mem::voidptr_t)Hooks::SwapBuffers, Data::szSwapBuffers, mem::MEM_DT_M1);

see here

What should it looks like in current version of libmem?

This is the code what I've made:

lm_module_t opengl32;
namespace gl
{
  void* SwapBuffers;
}
using SwapBuffers_t = BOOL(__stdcall*)(_In_ HDC hDC);
namespace hook
{
  namespace gl
  {
    SwapBuffers_t SwapBuffers;
  }
}

// idk why crashed...
void Init(HMODULE hModule)
{
  LM_GetModule(LM_MOD_BY_STR, (void*)LM_STR("OPENGL32.dll"), &opengl32);

  gl::SwapBuffers = LM_GetSymbol(opengl32, (lm_cstring_t)"wglSwapBuffers");
  hook::gl::SwapBuffers=(SwapBuffers_t)LM_MakeTrampoline(gl::SwapBuffers, 5);
  LM_DetourCode(gl::SwapBuffers, &hook::gl::SwapBuffers, LM_DETOUR_JMP32);
}

I wanted to suggest the ability to:

• Unprotect memory
• Install a NOP patch
• Install a JMP patch
• Install a CALL patch

I would be more than happy to assist, if need be?

Statically compiling all the dependencies is making the final binary way bigger than it has to be.
To fix this, CMake could search first for the shared libraries before compiling the dependencies statically.

There's no need to keep calling LM_GetProcessBitsEx all the time you want to do a bits-dependent operation. It should be stored when the process handle is opened with LM_OpenProcessEx.

This function has some similarities between Linux and BSD, but it should be broken down in smaller functions and commented to make the code more readable and understandable.

Functions such as LM_GetProcessPathEx, LM_GetProcessNameEx, etc, should have a pointer passed to them instead of a copy of the lm_process_t structure. This would go slightly easier on memory usage.