Hacker News Reader

Comment by sp332 | Hacker News Reader

Just curious about one of the last steps:

  cat /proc/53165/exe > /tmp/oldBash

I would have reached for 'cp /proc/53165/exe /tmp/oldBash', instead of using cat. Is there an advantage to using cat here, or is it just the same?

View on HN

Indeed! No idea what went through my brain when I wrote that :-)

Hey, working code is the only justification you need :)

Could you just use `gdb --pid 53165 /proc/53165/exe`?

Probably - will try it out next week and adjust my GitHub script if it works.

If that works, is there any reason why gdb shouldn't automatically use the /proc/PID/exe?

I wonder, too... It could pick it up automatically.

Probably because /proc is very Linux-specific, and gdb is not.

I recently did exactly the same, it's those times when everything with similar functionality depending on what context you are in blurs together because you should probably be outside, taking a walk, or staring at a tree.

However, reaching for one way of doing things when the justification for the other way of doing things is because you've seen them done that way more, is not really good justification. So maybe that blurry brain is a good brain sometimes, in retrospect.

:-)

And cp would have also saved permissions (the executable bit). Not that GDB would have an issue without it, as the OP showed it can look for symbols inside an ELF regardless of the inode bits.

I would have tried running 'strings'on the process's memory instead of gdb. Ugly, but likely would have worked with some manual intervention.

As to 'cp' vs 'cat': neither is a builtin, so they both are risky. What if you also accidentally did a rm -rf / on that system?

Mac OS X doesn't have a /proc filesystem, so I cannot test it, but from reading the man page

   read -N 1000000000 /proc/53165/exe $bash

should read all of bash into $bash, if it isn't ridiculously large, and

   echo -nE $bash > myBash

should then complete the copy.

Why are cp and cat "risky"?

It's just that in some emergency situations, where for example someone deleted a lot of files on the disk, you might not have /bin/cat or /bin/cp anymore.

I don't see how that ("rm -rf /") is relevant... The OP feared for a reboot that would make him recode his command line.

Ah, fair enough. Good point :)

    read -N 1000000000 /proc/53165/exe $bash

That shouldn't work, due to NUL bytes.

Reply on news.ycombinator.com