[Linux] Ethonmem - A C++ memoryhacking library

[flo8464]

Hey!

I am writing a Linux memoryhacking library for some time now and it finally
reached a state where I consider it to be usefull for other people.
(It's still under heavy development though).
I tried to keep the code as fast & generic as possible, with a modern C++ style.

Features:
- Enumerate processes and threads and extract information from abstract objects
representing them. There are also utilities to find processes running on the
system.
- Enumerate memory regions a process mapped into it's memory space.
- A debugger class which offers a lot of debug utilities.
- A memoryeditor to read and write a process' memory.
- A scanner to find addresses of POD values and byte patterns in the remote
process with an efficent approach.

Compiling:
- I use advanced C++0x features, so you need gcc 4.5 or later to compile the
library.
But this shouldn't be an issue as many distros already ship gcc 4.6 .
- The Boost library has to be installed. I compiled with version 1.40 and 1.46,
but older/newer versions should work as well.
- cmake/Code:Blocks is used as build system, please get one of them.
- Kernel 2.6 or higher is required so everything behaves like it should.
- Linux blocks writing to /proc/[PID]/mem per default, as it's considered a
security hazard. There are patches out there which enable writing to it without any
security issues. This is the fastest way to write memory, but it is only enabled
by Ethonmem if you define 'I_PATCHED_MY_KERNEL_TO_SUPPORT_WRITING_TO_MEM' when
compiling the library.

Download:
Checkout the source at https://github.com/Ethon/Ethonmem .

git clone git://github.com/Ethon/Ethonmem.git

Create the docs yourself with 'doxygen Doxyfile' or get these slightly outdated docs:
http://ethon.cc/blog/wp-content/uploads/2011/07/doc.zip

Some example code:
[C++] Ethonmem example code - Pastebin.com




I am releasing this because I want criticism and suggestions how to improve my library.
So, if you consider using it, please tell me what you'd like to change or why you don't want to use it.

Just a note, I am using the nickname "Ethon" for more than 4 years, neither the design nor the name ('insert greek mythology' + mem)
are 'stolen' from Cypher's HadesMem.

Have fun!
Greets,
Ethon

[rolingo]

Nice work! I will definitely try this one out

[Cypher]

Hey, cool to see somebody working on the Linux side of things.

One thing I noticed though is that you're using a singleton for your Debugger class. Is this strictly necessary? I don't know anything about the Linux debugging APIs, but under Windows it's possible to debug multiple processes at the same time...

EDIT:

Once again I don't know much about Linux, but it seems on recent kernels the restriction on mem_write has been removed (I compared the sources of an old 2.4 version and the latest 2.6 version to confirm, and the #ifndef is gone).

http://article.gmane.org/gmane.linux.kernel.mm/59775

[flo8464]

One thing I noticed though is that you're using a singleton for your Debugger class. Is this strictly necessary? I don't know anything about the Linux debugging APIs, but under Windows it's possible to debug multiple processes at the same time...

Yes, you are right. Didn't know that I am not limited to one process at a time, thanks.

Once again I don't know much about Linux, but it seems on recent kernels the restriction on mem_write has been removed (I compared the sources of an old 2.4 version and the latest 2.6 version to confirm, and the #ifndef is gone).

Gmane -- Mail To News And Back Again

Uhm, I always received an EINVAL error when I tried to write to the mem file. (Kernel 2.6.38-
Seems like I have to investigate why it fails. oO

[Cypher]

Yes, you are right. Didn't know that I am not limited to one process at a time, thanks.



Uhm, I always received an EINVAL error when I tried to write to the mem file. (Kernel 2.6.38-
Seems like I have to investigate why it fails. oO

It seems your kernel version is too old.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=blob_plain;f=fs/proc/base.c;hb=HEAD

I think you need 2.6.39.x. (I only checked 2.6.39.3, not sure about earlier builds. The fix is probably in for all of 2.6.39, but you'd have to confirm that yourself...)

By the way, any plans for supporting Clang?

[flo8464]

It seems your kernel version is too old.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=blob_plain;f=fs/proc/base.c;hb=HEAD

I think you need 2.6.39.x. (I only checked 2.6.39.3, not sure about earlier builds. The fix is probably in for all of 2.6.39, but you'd have to confirm that yourself...)

Uh, so it's a very recent change.
Well, I guess I ll leave it optional. Memory writing is a far less frequent task than reading, so compatibility matters more than the tiny bit of performance gained by being able to write more than 4/8 bytes a time.
At the least for the next 1-2 years until everyone runs an adequate kernel.

By the way, any plans for supporting Clang?

To be honest, I didn't know about Clang before.
But from what I saw it looks like a very interesting project, especially because many Unix systems are going to drop GCC.
It has a gcc compatibility layer so supporting it shouldn't be much work to do (well, maybe the less mature C++0x support may cause problems), so I will surely go for it.

[Cypher]

To be honest, I didn't know about Clang before.
But from what I saw it looks like a very interesting project, especially because many Unix systems are going to drop GCC.
It has a gcc compatibility layer so supporting it shouldn't be much work to do (well, maybe the less mature C++0x support may cause problems), so I will surely go for it.

It's a really awesome project. Yeah it's less 'mature' than GCC, but its standards compliance is way better, it's faster, etc. They're lagging behind in C++0x a bit, but afaik most of the major missing features should be added shortly (the biggest one that comes to mind is lambdas, I believe they're being worked on atm in the trunk). The primary thing stopping me adopting it atm is the lack of proper Windows support. Though Ruben from the MinGW-w64 project has started work porting it (test builds are available in his 'personal build' folder on the MinGW-w64 sourceforge page).

[Iksf]

PathScale compiler went open source recently too, might be good for this

[flo8464]

So ... I really forgot about this forum, sorry for all the feedback via PM I ignored.

I am gonna rewrite this library completly, step-by-step as my skills are more mature now and I really dislike what I made up in the past. Recently I wasted some time and tried to write a portable memory hacking library to be able to compile hacks for Linux and Windows ... until I realized that this is a complete waste of time, simply use a subset of Cypher's Library via libwine if you are gonna hack Windows applications, I want to focus on 'real' Linux processes.

So this new thing is gonna be non-portable as **** and I use it as playground for some cool features ... I am up for suggestions and especially for problems you had using/compiling the library, there are obviously many worms in the wood.

Regards,
flo

[Cypher]

My suggestion is still Clang support.

[flo8464]

My suggestion is still Clang support.

I really want to do that, but at the moment Clang 3.0 fails to compile Boost on my system, idk why.

[Cypher]

I really want to do that, but at the moment Clang 3.0 fails to compile Boost on my system, idk why.

Clang ToT is usually pretty stable, but if you don't want to compile it yourself then 3.1 is out now afaik.

Also, you might try posting your errors on the Boost mailing list, as Clang is afaik supposed to be compiling clean and passing tests on Linux.

[Torpedoes]

At first I thought I'd create a GitHub issue but I think I'll post it here instead. I may have found a minor buffer overflow in your code. sscanf automatically null-terminates strings after the specified length. So when you're reading the maps file here you need to make sure m_perms and pathBuffer are large enough to accommodate the null-terminator. I suggest reading 1023 bytes for the name and increasing m_perms to 5. The only reason I found this is because I'm using your code as a reference for my own library and I watched sscanf dirty my stack. Also I can't thank you enough for this library, it's been incredibly useful to my research.