Hacker News Reader

Comment by x0 | Hacker News Reader

here it is: 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.

View on HN

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.

The equivalent on OSX to catting /proc/<pid>/maps is running vmmap -w <pid>

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

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.

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.

Yeah I'm thinking you're right, if I set the environment variable DYLD_SHARED_REGION=avoid, it only prints out about 300kb ofstuff.

3gb of them? Really? That would be the largest runtime library I have ever heard of, forget any other libc in existence.

I'm getting ~300m out. I suspect the author made a power-of-10 mistake in reading the output of ls.

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

Reply on news.ycombinator.com