accessing memory used by another program

This is a discussion on accessing memory used by another program within the C Programming forums, part of the General Programming Boards category; Originally Posted by rmetcalf Have you ever though of using the shared memory functions that are part of IPC from ...

  1. #16
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by rmetcalf View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  2. #17
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #18
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #19
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by matsp View Post
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #20
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by MK27 View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #21
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by matsp View Post
    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?
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  7. #22
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #23
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    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.

  9. #24
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by tabstop View Post
    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... )
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #25
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by matsp View Post
    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.

  11. #26
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    strtoul("74616874", 16, NULL);

    2 last parameters are other way round
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Client-server system with input from separate program
    By robot-ic in forum Networking/Device Communication
    Replies: 3
    Last Post: 01-16-2009, 03:30 PM
  2. Assignment Operator, Memory and Scope
    By SevenThunders in forum C++ Programming
    Replies: 47
    Last Post: 03-31-2008, 07:22 AM
  3. Program that displays amount of free memory
    By trancedeejay in forum Linux Programming
    Replies: 3
    Last Post: 01-13-2006, 01:27 PM
  4. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 09:32 AM
  5. my C++ program hangs during memory deallocation.
    By the-tzar in forum C++ Programming
    Replies: 6
    Last Post: 03-06-2004, 10:39 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21