Accessing proc/memory

[Anonymous Monk]

Hey folks,

I want to cheat in Linux, that is changing the memory of programs at runtime. Kcheat doesn't build anymore, and I didn't find anything comparable, so I thought of throwing together my own little tool.

I learnt that in order to access /proc/PID/mem, I have to attach first with ptrace. But I'm stumped already at the very beginning. I run the following program under sudo:

#!/usr/bin/perl
use strict;
use diagnostics;
use Sys::Ptrace qw(ptrace PTRACE_ATTACH);

ptrace PTRACE_ATTACH, 9701;

open my $fh, '<', '/proc/9701/mem' or die "could not open mem for read
+ing: $!";
my $buf;
while (1) {
    my $res = read $fh, $buf, 8*1024;
    die "could not read 8KB from mem: $!" unless defined $res;
    exit if 0 == $res;
    print $buf;
};

This bombs out with "Input/output error at ptrace.pl line 12.". I don't understand why.

[betterworld]

I haven't used /proc/*/mem yet and don't know anything about it, but my guess would be that it contains the virtual memory of each process, so that the first byte that you read would be *NULL, which is impossible to read. If my assumption is right, you should probably seek() to some mapped regions before you read.

[Anonymous Monk]

That helped immensely! My understanding was that each mem file is what each process occupies in memory. But that's wrong. Instead, it's the image of my whole memory, and I can only read the sections which the specific process occupies.

As per your suggestion, I added:

use Fcntl qw(SEEK_SET);
seek $fh, 134512640, SEEK_SET or die "could not seek in mem: $!";

I got that number from converting from the hex address the maps file in /proc.

[shmem]

It seems that the kernel doesn't let you access a processes memory in that way. That's arguably A Good Thing.

Why do you want to "cheat"? Why do you think "changing memory of programs at runtime" is a good idea? This sounds much like an XY Problem.

--shmem

[Anonymous Monk]

It's only an XY problem if I do not explain the greater goal, but which I did.

Have you never cheated in computer games? It's either hexediting savefiles or messing with the memory in a debugger. That's what brought me to Turbo Pascal and programming in general in the first place!

I don't believe that the kernel doesn't let me do anything I want to do. I have su privileges and am not afraid to use them. If accessing memory is possible in DOS, Win98 and Win2k, so it bleeding well be in Linux. These mem files aren't just lying around /proc because they look pretty, you see.

[shmem]

It's only an XY problem if I do not explain the greater goal, but which I did.

Didnt see it.

Have you never cheated in computer games?

Erm... no. I don't do computer games.

I don't believe that the kernel doesn't let me do anything I want to do.

Well, if you haven't selinux turned on, that is. Then there are fences which UID 0 cannot pass either. Ah, and beliefs.. talking of them - confronted with facts, your belief is as good as mine ;-)

--shmem

[hv]

For the initial analysis, and maybe also for the resulting program, I'd suggest playing with gdb, the debugger. This has the ability to attach to a running process, to inspect and modify memory, and much more besides; and because it freezes the process while attached you aren't trying to hit a moving target.

Some scattered clues to this approach may be found in how to write a program to control gdb and Re: Is there any way of determining the current line number of a child process while it is running?.

Hugo