just a prove of concept code, it should work.
As I wrote earlier, I switched to python so I don't have more C code. I might consider sharing some python code if someone find it interesting.
ptrace gives possibility to read/write program data, as well as code, read and manipulation of registers. One of possible scenarios is to stop program execution, store processor context (registers), inject some code into stack (reading esp we have stack pointer), redirecting program execution (eip - register) restore processor context and resume program execution
Donate to remove ads, get your "DONATOR title, and get access to the MMOwned community's elite Shoutbawx.
Thanks for contributing to this thread, corderoy! Python is an excellent choice for writing bots, I'm sure. It's one of my favorite languages because it's so elegant and kind to the eyes of the reader.
Back to the topic, memory reading:
What corderoy posted is the standard POSIX way for reading another process' memory. It works and is portable. On Linux, there's a faster way:
- Open the "virtual" file /proc/PID/mem that represents the process' virtual memory map
- Attach to the process (like in corderoy's example)
- wait() for the process (like in corderoy's example)
- Use the POSIX function "pread" (man 2 pread) to read an arbitrary memory area
- Detach (like in corderoy's example)
The difference is that ptrace(PTRACE_PEEKDATA,...) only reads one word at a time while pread allows you to read large chunks at once.
Sidenote:
ptrace(PTRACE_PEEKDATA) is also the reason why OllyDbg isn't very fast in WINE, because WINE uses exactly this function to "emulate" the Windows facilities for reading another process' memory. The WINE developers seem to have chosen portability over performance in this case. Reference: [Only registered and activated users can see links. ]
How would I edit it to return a string? I mean, what if the address is a string, how would I redo this to make it return a string?
EDIT: And does anyone have a WoW address which I could use to test if it works? Without offsets
I knew /proc/PID/mem approach as well but for some reason I've chosen ptrace way (maybe becouse it was quite easy to implement, and while botting most often program has to access certain words of memory than larger chunks). I can confirm that ptrace is kinda slow but it was fast enough for me.
@Molleren
You need to understand how things works first. Ptrace lets you read single word in memory at a time. Then you need to realize how this string which you want to read is represented in memory. Strings are a long story, could be UTF-8, UTF-16 or simple c string (ascii). Given a word on 32-bit machines are 32 bit long and in c string you have one char stored in one byte, you need to read as many words as needed looking for '\0' character in it (assuming its a null terminated string). So basicaly, you read one word (4 bytes) - this are your first 4 chars of string assuming no byte has value of 0x00, and repeat this procedure till you find 0x00 appending consecutive bytes to your string. Check out also BIG ENDIAN and LITTLE ENDIAN terms on the internet because you need to understand how bytes are ordered in memory.
Here is my high level python code for it:
Code:
while True:
data = readWord_(pid, address)
str = binToString(data)
result = result + str
if len(str)<4:
break
else:
address = address +4
Hopes this helps, I'm not good in explaining things.
@Sednogmah
I knew /proc/PID/mem approach as well but for some reason I've chosen ptrace way (maybe becouse it was quite easy to implement, and while botting most often program has to access certain words of memory than larger chunks). I can confirm that ptrace is kinda slow but it was fast enough for me.
Yeah, that's perfectly reasonable of course. I just thought I'd mention it before anyone tries to do complete memory dumps with PEEKDATA ,-)
@Molleren: Note that PTRACE_ATTACH suspends the process, so you want to DETACH as soon as possible after you're done with reading.
Using ptrace to read large blocks of memory is just too much of a performance hit. Easiest solution is to alter the kernel source to be able to read/write from/to /proc/pid/mem file.
I don't remember exactely what file it was but it was changing a function to always return 1 instead of returning 1 when you're root or the program itself.
Using ptrace to read large blocks of memory is just too much of a performance hit. Easiest solution is to alter the kernel source to be able to read/write from/to /proc/pid/mem file.
Yes, using ptrace to read is slow. However you can read large chunks quickly without modifying the kernel if you use ptrace just to attach to the target process but instead of using ptrace's "PEEK" to actually read something, you open /proc/pid/mem and read with the pread(2) function.
Quote:
I don't remember exactely what file it was but it was changing a function to always return 1 instead of returning 1 when you're root or the program itself.
If you use ptrace(PTRACE_ATTACH) on the target process that runs under the same UID as you are, the kernel opens /proc/PID/mem for reading.
It has been a while since i used ptrace etc but isn't it so that you need to detach after you're done reading to continue the program?
With the kernel mod you just open the device with open or fopen and read/write whenever you need to without any performance loss.
After the kernel mod dependend bot i switched to a much better solution.
Loading a shared lib with LD_PRELOAD, hooking the iat PeekMessage function effectively creating a loader to load and unload other libs on demand.
I'm derailing the thread a little i think, so i have to say it's very informational. It took me a good while learning everything about X11 to get my first bot running with mouse movement and key presses.
