5 ms·

Bit lost here, not really a C programmer, by "zeroing pages" are we talking about zeroing out memory? Because I wrote a little C program that just reads memory

by x0 11y ago

Bit lost here, not really a C programmer, by "zeroing pages" are we talking about zeroing out memory? Because I wrote a little C program that just reads memory until it segfaults, usually I can get about 3gb of stuff out, random little bits of files. I've noticed it works much better on OS X than Linux.

umanwizard 11y ago
...what? Uh, I don't know how memory allocation works in detail in OSX, so you could be right, but it'd surprise me. Can you show me your program?
- x0 11y ago
  here it is: https://gist.github.com/raincoats/7b2631106c74f759eb5d https://gist.github.com/raincoats/7b2631106c74f759eb5d A few things though: - Last time I ran this, in the memory dump, every second character was the letter "f". Like, in the dump, instead of saying "Words" it would say "Wfofrfdfsf". It changes each time, probably to do with my char onechar variable. (Actually now that I think about it, it should probably only be onechar[1] instead of onechar[2]. It was called onechar because I was trying to printf 1 char at a time) - Before I changed "p" to &memcpy, it was "p = &p", and it would only read my environ before segfaulting. - This program, on linux, dies almost immediately. It only spits out a few bytes.
  - cowsandmilk 11y ago
    your program doesn't allocate memory, so it is unrelated to memory allocation. You instead are taking the address of a function in memory (memcpy); and then printing out the function. This isn't a leak in any way since your program has to be able to reach memcpy and call it. So, no, you aren't printing out bits of files. You're printing out functions that your program has the ability to call.
    - umanwizard 11y ago
      It is "bits of files" in the sense that Libc is a file. He's basically printing out some of the object files his program is linked with, starting with memcpy.
    - klibertp 11y ago
      3gb of them? Really? That would be the largest runtime library I have ever heard of, forget any other libc in existence.
      - umanwizard 11y ago
        I'm getting ~300m out. I suspect the author made a power-of-10 mistake in reading the output of ls.
    - x0 11y ago
      I can grep for -----BEGIN and find a few public keys and certificates, I doubt they're part of the program (but they might be, as I said I don't really know) http://i.imgur.com/IXgkWNu.png http://i.imgur.com/IXgkWNu.png
    - umanwizard 11y ago
      Well, they are files. Runtime libraries. He's starting somewhere in /usr/lib/system/libsystem_platform.dylib (where memcpy lives) and printing the rest of the executable code his program has mapped in. It doesn't surprise me that some of this contains public keys and certificates. They are probably used by some OSX networking library.
      - x0 11y ago
        Yeah I'm thinking you're right, if I set the environment variable DYLD_SHARED_REGION=avoid, it only prints out about 300kb ofstuff.
      - x0 11y ago
        Yeah I'm thinking you're right, if I set the environment variable DYLD_SHARED_REGION=avoid, it only prints out about 300kb ofstuff.
  - neopallium 11y ago
    First of all even a simple program like that will have standard libraries mapped into it's address space. Your program is reading from a region of the processes address space that has the binary code for the memcpy() function. On linux you can dump a processes address space mapping from file "/proc/<pid>/maps". Or to see an example just run: cat /proc/self/maps That cat command will dump the address space mapping for that instance of the cat command. If you run it multiple times it will show different address ranges because of a security feature (ASLR, address space layout randomization). Also you shouldn't use fprintf or printf to print 1 char. printf will try to look for format characters in the "string" you are passing it. It would be better to use fputc(*p, stdout), then you don't even need to call memcpy() or the "onechar" array. If you set "p" to a block of allocated memory, then your program should segfault shortly after reading past the end of the memory. How many bytes you can read past the end of the allocated block of memory depends on how the memory allocator manages pools of memory and it's own bookkeeping information is stored.
    - umanwizard 11y ago
      The equivalent on OSX to catting /proc/<pid>/maps is running vmmap -w <pid>
  - umanwizard 11y ago
    Your program has several bugs, but you already know about that :). I can't get it to print 3g of stuff on OSX. It prints about 300m , which makes a lot more sense. http://pastebin.com/uBHEW7X8 http://pastebin.com/uBHEW7X8

by x0 11y ago

umanwizard 11y ago

...what? Uh, I don't know how memory allocation works in detail in OSX, so you could be right, but it'd surprise me. Can you show me your program?

x0 11y ago
here it is: https://gist.github.com/raincoats/7b2631106c74f759eb5d https://gist.github.com/raincoats/7b2631106c74f759eb5d A few things though: - Last time I ran this, in the memory dump, every second character was the letter "f". Like, in the dump, instead of saying "Words" it would say "Wfofrfdfsf". It changes each time, probably to do with my char onechar variable. (Actually now that I think about it, it should probably only be onechar[1] instead of onechar[2]. It was called onechar because I was trying to printf 1 char at a time) - Before I changed "p" to &memcpy, it was "p = &p", and it would only read my environ before segfaulting. - This program, on linux, dies almost immediately. It only spits out a few bytes.
- cowsandmilk 11y ago
  your program doesn't allocate memory, so it is unrelated to memory allocation. You instead are taking the address of a function in memory (memcpy); and then printing out the function. This isn't a leak in any way since your program has to be able to reach memcpy and call it. So, no, you aren't printing out bits of files. You're printing out functions that your program has the ability to call.
  - umanwizard 11y ago
    It is "bits of files" in the sense that Libc is a file. He's basically printing out some of the object files his program is linked with, starting with memcpy.
  - klibertp 11y ago
    3gb of them? Really? That would be the largest runtime library I have ever heard of, forget any other libc in existence.
    - umanwizard 11y ago
      I'm getting ~300m out. I suspect the author made a power-of-10 mistake in reading the output of ls.
  - x0 11y ago
    I can grep for -----BEGIN and find a few public keys and certificates, I doubt they're part of the program (but they might be, as I said I don't really know) http://i.imgur.com/IXgkWNu.png http://i.imgur.com/IXgkWNu.png
  - umanwizard 11y ago
    Well, they are files. Runtime libraries. He's starting somewhere in /usr/lib/system/libsystem_platform.dylib (where memcpy lives) and printing the rest of the executable code his program has mapped in. It doesn't surprise me that some of this contains public keys and certificates. They are probably used by some OSX networking library.
    - x0 11y ago
      Yeah I'm thinking you're right, if I set the environment variable DYLD_SHARED_REGION=avoid, it only prints out about 300kb ofstuff.
    - x0 11y ago
      Yeah I'm thinking you're right, if I set the environment variable DYLD_SHARED_REGION=avoid, it only prints out about 300kb ofstuff.
- neopallium 11y ago
  First of all even a simple program like that will have standard libraries mapped into it's address space. Your program is reading from a region of the processes address space that has the binary code for the memcpy() function. On linux you can dump a processes address space mapping from file "/proc/<pid>/maps". Or to see an example just run: cat /proc/self/maps That cat command will dump the address space mapping for that instance of the cat command. If you run it multiple times it will show different address ranges because of a security feature (ASLR, address space layout randomization). Also you shouldn't use fprintf or printf to print 1 char. printf will try to look for format characters in the "string" you are passing it. It would be better to use fputc(*p, stdout), then you don't even need to call memcpy() or the "onechar" array. If you set "p" to a block of allocated memory, then your program should segfault shortly after reading past the end of the memory. How many bytes you can read past the end of the allocated block of memory depends on how the memory allocator manages pools of memory and it's own bookkeeping information is stored.
  - umanwizard 11y ago
    The equivalent on OSX to catting /proc/<pid>/maps is running vmmap -w <pid>
- umanwizard 11y ago
  Your program has several bugs, but you already know about that :). I can't get it to print 3g of stuff on OSX. It prints about 300m , which makes a lot more sense. http://pastebin.com/uBHEW7X8 http://pastebin.com/uBHEW7X8