Im getting acquainted with Buffer Overflows (BOF) and was replicating a simple attack described by Techorganic. They create a simple C program called "classic", which contains an obvious BOF vulnerability (when it reads up to 400bytes into an 80byte buffer from STDIN), and then create the proper buffer to exploit it, and save said buffer it to "in.txt". Despite it running its course smoothly, once all preparations are done with, they execute the program with the following command:

user@pc$ (cat in.txt ; cat) | ./classic

My first thought was "holy moly, what's going on there?", the original idea was simple, run classic and input the buffer, my intention was to execute it as:

user@pc$ ./classic < in.txt

Just like any other mortal would do. But to my surprise, their way works, and mine doesn't.

Bottom line is: What does the first syntax do and what is the key difference that made their solution work and mine not, despite them being semantically equal (or similar, apparently).

1 Answer 1


The first cat command feeds the input from in.txt to stdin of the program. The second cat command just reads from the current stdin and feeds it to the program, thus providing the one executing this command line with a way to feed its own data from the terminal to the program and this way probably to some /bin/sh or similar executed from this program.

Contrary to this just using program < in.txt just feeds the in.txt to the stdin of the program and after this stdin of the program gets closed. This means that no user input from the terminal is fed to the program and to the shell running inside it.

  • But I HAVE used ./program < buffer.txt in other similar projects to successfully run a BOF attack and have valid command line access. My point is, what is the necessary condition that needs to be true, in order to exclusively allow a cat;cat invocation, instead of program<file.txt invocation? Apr 6, 2017 at 14:43
  • @Fernando: this depends on what the program does internally. If it for example starts a shell which reads from stdin then it is very bad if stdin is closed. See also my comment on system(“/bin/sh”) exits without waiting for user input Apr 6, 2017 at 15:02
  • I supposed something like that, but needed confirmation from a reliable source. Thank you very much. Apr 6, 2017 at 15:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .