3 ms·
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 pri
by 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 agoIt 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 ago3gb of them? Really? That would be the largest runtime library I have ever heard of, forget any other libc in existence.
- umanwizard 11y agoI'm getting ~300m out. I suspect the author made a power-of-10 mistake in reading the output of ls.
- x0 11y agoI 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 agoWell, 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.