Watched this, and ended up being the one one to ask a question.
(HTF does the non-coder guy with the scarred brain end up being the only one who asks a question…?)
I understand what he was doing, but I’m not understanding how you could gather any real useful information from the tool unless you have access to the running binary’s source.
The bit he’s using relies on use of the fork() function.
Maybe that’s still widely in use. Perhaps it’s one of the lazy programming techniques facilitated by fast machines, and virtualization. I don’t know. I haven’t written a line of code in probably a decade.
But even for sloppily-written kludges, you can really restrict what binaries can do, with things like setting maximums on processes that can be forked. Hell, one of the old ways to crash a system was a fork bomb; any admin worth a shit would easily be able to prevent that from working these days.
From the coding side, look at this.
The thing to do if running a problematic program, though, is be really stingy with things that could be exploited. This relies on child processes; prevent them by tracking the number of processes created with a clean binary.
Add to that things like cryptographic hashes on the binaries, and irrelevant.
Now this stuff might be useful if you can test binaries in a lab prior to deployment, but I don’t think that’s what the speaker was really getting at.