accessing memory used by another program

I was hoping that this

Code:

---

printf("%s\n", &argv[1]);

---

would make a simple one line program that would print the string pointed to by a pointer from another program if argv[1] was the address of the pointer (eg, bfde768f), but it seems not to work.

Now I notice that if I ask gdb (running without an input program) "x/s 0xbfde768f", it can't access this memory (it's "out of bounds"). I had thought memory was "protected" by simple assigned (ie. the same address won't be handed out twice) and not by actual restriction, as appears to be the case.

Is there a way around this?

Each program will have it's own memory space, and gdb will access the stack (and other accesses to the debuggee application) via some debug interface that the OS supports.

You can use this interface yourself. In Linux that would be the ptrace system call:
http://linux.die.net/man/2/ptrace

--
Mats

thanks matsp...this implies unless the other program is a forked child, it's memory space is permanently out-of-bounds.

Which means there is not much purpose in trying to do the following, but given that char address[9] is a string containing a memory address, how can I actually get the content of that address if it's "in bounds" (as it turns out, &address doesn't do that)?

The next sentence

Quote:

---

Alternatively, the parent may commence trace of an existing process using PTRACE_ATTACH.

---

You can check if the address is valid in the child process:

Quote:

---

On success, PTRACE_PEEK* requests return the requested data, while other requests return zero. On error, all requests return -1, and errno is set appropriately. Since the value returned by a successful PTRACE_PEEK* request may be -1, the caller must check errno after such requests to determine whether or not an error occurred.

---

--
Mats

ptrace seems to work but any ideas about how to pass that address (other than in a string, which seems to be a dead end)?

For example: This is program1, which gives up its pid and a char pointer address, then waits around using getc...

Code:

---

#include <stdio.h>

int main () {
        short int pid=getpid();
        char this[]="that";
        printf("%d\t%x\n", pid, this);
        getc(stdin);
}

---

This is program2, which accepts a pid and a "memory address":

Code:

---

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/ptrace.h>

int main (int argc, char *argv[]) {
        int pid=atoi(argv[1]), word;
        if ((ptrace(PTRACE_ATTACH,pid,NULL,NULL)) != 0) {perror("ptrace fail");return -1;}
        if ((word=ptrace(PTRACE_PEEKTEXT,pid,(void*)argv[2],NULL)) == -1) perror("peektext fail");
        else printf("%d\n", word);
        ptrace(PTRACE_DETACH,pid,NULL,NULL);
}

---

peektext always fails with an Input/output error

What are you ACTUALLY trying to do? [not the "I want to undo a bolt", but "I want to replace my wheel, because I have a puncture"]

Edit: You may find that PEEKTEXT fails because the address of this is in the stack, so the data segment rather than the text (code) segment?

--
Mats

Quote:

---

Originally Posted by matsp

What are you ACTUALLY trying to do? [not the "I want to undo a bolt", but "I want to replace my wheel, because I have a puncture"]

Edit: You may find that PEEKTEXT fails because the address of this is in the stack, so the data segment rather than the text (code) segment?

--
Mats

---

Eventually I'd like to ride down the hill :)

I think PEEKTEXT fails because passing it a string from a character array can't work. This is why I asked "given that char address[9] is a string containing a memory address, how can I actually get the content of that address". Here's what I mean:

Code:

---

#include <stdio.h>

int main () {
        char this[]="that", that[9];
        sprintf(that, "%x", this);
        printf("%s\n", that);  //returns same as &that 
}

---

This just prints the address -- which is to say that is a string containing an address (as a string), but it's useless for obtaining the contents of an actual location in memory. So that's probably true of argv[2] in program2. Generally, one would use *ptr=this and never deal with addresses as string values. But I don't see a way to pass "the information" otherwise...

What, you want to convert a string to an unsigned long? Why not use strtoul? (You'll probably have to specify the base appropriately.)

Quote:

---

Originally Posted by tabstop

What, you want to convert a string to an unsigned long? Why not use strtoul? (You'll probably have to specify the base appropriately.)

---

I guess this is where my ignorance of these matters is really exposed! I can't even ask the right question!

If I convert take the address as an unsigned long int it still seems useless.

Code:

---

#include <stdio.h>

int main () {
        unsigned long addr;
        char this[]="that", that[12];
        sprintf(that, "&#37;s\n", this);
        addr=atoi(that);
        printf("%s\n", &addr);
}

---

The goal here is to print "that" (literally) without using anything except a literal number or string as the address (no "%p"). Besides w/ the ptrace example, this would be the same as if you asked for user input in the form of a memory address, where the user might type:

0xbfbc446d

Now, how could you use that address (a string literal inputted by the user) the same way you would a *ptr? It seems it cannot be done...

[I'm going to move this question to a new thread...]

Not &addr, but *addr. (Edit: not tested, but I think it should work. If it doesn't work, make addr an actual pointer type.)

It is hard to understand
but - do you want something like

Code:

---

char sAddr[] = "0x00ac0098";
unsigned int uAddr = strtoul(sAddr,NULL,0);
int* pAddr = (int*) uAddr;

int res = *pAddr;
printf("%d", res);

---

Quote:

---

Originally Posted by tabstop

Not &addr, but *addr. (Edit: not tested, but I think it should work. If it doesn't work, make addr an actual pointer type.)

---

Wrong on both counts.

Quote:

---

Originally Posted by vart

It is hard to understand
but - do you want something like

Code:

---

char sAddr[] = "0x00ac0098";
unsigned int uAddr = strtoul(sAddr,NULL,0);
int* pAddr = (int*) uAddr;

int res = *pAddr;
printf("%d", res);

---

---

And this causes a segfault.

Quote:

---

Originally Posted by MK27

Wrong on both counts.



And this causes a segfault.

---

AS it should. What to you expect to get dereferencing some random address?

You can only expect a fixed address like this if you have some way of making your executable operate within a fixed address. Which is highly unlikely that you have this capability at your disposal. Thus you need to go about acquiring the address location you are wanting to manipulate via other means.

Have you ever though of using the shared memory functions that are part of IPC from Unix SVR4?

Take a look at this:

http://www.cs.cf.ac.uk/Dave/C/node27.html

Quote:

---

Originally Posted by rmetcalf

Have you ever though of using the shared memory functions that are part of IPC from Unix SVR4?

Take a look at this:

http://www.cs.cf.ac.uk/Dave/C/node27.html

---

But that assumes that the first and second applicaiton are agreeing to communicate this way. I think what MK27 is trying to do is to get data out of a non-agreeing application (commonly this question comes from people who are trying to cheat in games, but seeing as this is under Linux, I find it less likely).

Back to the original thread: If we assume you have a valid address, then ptrace(PEEKDATA, address) would be the right thing for this. If you figure out what the address of "this" is in the sample code, you could hard-code the address into the ptrace() call for the test-case. Then figure out how to communicate the address.

--
Mats

Actually I did get all this to work in the end thanks mostly to vart. And for anyone who's still curious, the answer produced another question:

Code:

---

//this produces a pid and memory address to test, and "pauses"
//sometimes the stop signal from ptrace makes ptrace think the process is gone tho
//but it can be run again on the stopped process..
#include <stdio.h>             

int main () {
        short int pid=getpid();
        char this[]="that\n";
        printf("%d %p\n", pid, this);
        getc(stdin); 
}

---

And the ptracer itself:

Code:

---

#include <stdio.h>            // supply with a pid and a pointer address
#include <unistd.h>           
#include <sys/types.h>
#include <sys/ptrace.h>
       
int main (int argc, char *argv[]) {
        int pid=atoi(argv[1]), word, next, i, save;
        unsigned int addr = strtoul(argv[2],NULL,0);    // thanks again vart
        if ((ptrace(PTRACE_ATTACH,pid,NULL,NULL)) != 0) {perror("ptrace fail");return -1;}
        for (i=0; i<=5; i++) {      // nb. a character at each address
                if ((word=ptrace(PTRACE_PEEKTEXT,pid,addr+i,NULL)) == -1) perror("peektext fail");
                else printf("%c", word);
                if (i==0) save=word;
        }
        ptrace(PTRACE_DETACH,pid,NULL,NULL); //preserves process
        printf("%d\n",save);    // my next mystery
}

---

The purpose of int save is to reproduce the plain number at addr. addr may vary but this number is always 1952540788, so it can't be another address...for the life of me I can't see "t" or "that" in it, and this hung me up initially because I was looking for something with 116. Does anyone know what the number is?

ps. matsp: I would cheat at games, but I don't seem to have time to play any.

Save, in Hex is 74616874, which is ascii text:

Code:

---

74: t
61: a
68: h
74: t

---

So you have found your data.

--
Mats

Quote:

---

Originally Posted by matsp

Save, in Hex is 74616874, which is ascii text:

Code:

---

74: t
61: a
68: h
74: t

---

---

Backward, because it's little endian? So I didn't have to go through a byte at a time then...

Thanks matsp.

Quote:

---

Originally Posted by MK27

Backward, because it's little endian? So I didn't have to go through a byte at a time then...

Thanks matsp.

---

Well, it's only backwards becuase you are printing it as an INT, rather than dealing with your string as a sequence of char. The bytes in memory are 74 68 61 74 in that order from low to high address (Low -> unsigned value closer to zero just to make sure we use the same nomenclature).

When reading another process's memory, you do need to know what the memory represents. strings are pretty meaningless when displayed as an int (especially in decimal), and integers make very weird strings, and floating point makes weird things both as integers and as strings. Of course, if you spend enough time viewing memory, you sooner or later learn to recognize strings, floating point and integer data by the data patterns they have [and code].

--
Mats

Quote:

---

Originally Posted by matsp

Well, it's only backwards becuase you are printing it as an INT, rather than dealing with your string as a sequence of char. The bytes in memory are 74 68 61 74 in that order from low to high address (Low -> unsigned value closer to zero just to make sure we use the same nomenclature).

---

Okay (that's what little endian byte order means, doesn't it?).
Note that ptrace will only return an int. I was just fiddling around and noticed that altho int=0x6f is valid, there is no way to turn

int=1952540788;

into

int=0x74616874;

It can be rendered as a string containing "74616874" with sprintf, but then atoi or strtol, etc. do not give hex numbers either. This is unfortunate because the only way to extract a string from 1952540788 is to convert it to hexadecimal.

Now, even if I parse the string into two character units, (eg, "74", "61", etc.) I would still be stuck with a bunch of unconvertable strings, unless I make some function with a table in it (if strcmp(char X,"61") int Y=97, so on). Whew!

I'm very very surprised that I can't find any simple C functions to do base conversions on integers both ways.

printf functions will take a character, but not a string, from a decimal number (the latter would be impossible), and altho it would be possible to take a string from a hex number, they won't. So I guess the "byte by byte" solution MUST remain?

Judging from your posts, I think you are in slightly above your depth.

You can use a char * cast to the address of the int to get the string out.

To get the complete string, you will need to read another byte too, since the string ends with a zero byte. So you would need to read the data into a temporary buffer that can hold 5 bytes. [If you have a 4-byte string, you could print it with

Code:

---

printf("%s\n", &x);

---

where x is an integer].

--
Mats

You can make sprintf print "0x" in front of numbers, and you have to tell strto(whatever) what the underlying base is anyway, so you can just tell it "hex" and be done with it.

(At least I think that's what you're asking.)

And of course four characters is the largest you're going to get in an int.

Quote:

---

Originally Posted by tabstop

You can make sprintf print "0x" in front of numbers, and you have to tell strto(whatever) what the underlying base is anyway, so you can just tell it "hex" and be done with it.

---

Code:

---

x = strtoul("74616874", 16, NULL);

printf("0x%x\n", x);

---

will produce
0x74616874 (of course, you could just as well print("0x74616874\n"); but that's cheating... )

Quote:

---

Originally Posted by matsp

Code:

---

x = strtoul("74616874", 16, NULL);

printf("0x%x\n", x);

---

will produce
0x74616874 (of course, you could just as well print("0x74616874\n"); but that's cheating... )

---

I was thinking %#x, but sure.

strtoul("74616874", 16, NULL);

2 last parameters are other way round