So, just how would we develop an exploit for this? From a high-level view, we would continue from where we left off. We would need to use a tool to generate a random set of bytes, that is, 74 bytes.

This tool would need to keep track of this randomly generated string of bytes so that when we go through this process again with this randomly generated string of bytes, we could determine exactly how many bytes into the string the RIP overwrite happens and use this tool to determine this. This is known as the offset. Tools such as Metasploit's pattern create and pattern offset can handle this and, in fact, are designed to do this. Both come with the community version of Metasploit and the Metasploit Framework.

From here, we'd need to search the binary for an instruction we could use to execute our own shellcode. For the shellcode, we would either code it ourselves or use an exploitation tool to develop it for us. There are several commercial and paid tools that do this. If we were to break this down into a series of steps, it would resemble something like the following:

1. Cause the program to crash.
2. Replicate the crash and determine how many bytes it took to cause the crash.
3. Replicate the crash in a debugger with the same input string to validate that RIP is overwritten.
4. Replicate the crash in a debugger with a randomly generated, non-repeating input string.
5. Determine which bytes in that string are stored in RIP, or which bytes are on the stack and used in a RET instruction.
6. Determine how many bytes into the input string those bytes occur.
7. Search the program within the debugger for an instruction that will allow your shellcode to execute.
8. Replace the bytes in RIP or on the stack in the RET instruction with an address to the discovered instruction in step 7.
9. Determine whether your shellcode contains bad characters that prevent it from executing properly and replace those if possible.
10. Test the input to make sure the shellcode executes.

The offset value will be different on each system based on several variables, such as the current patch level, operating system version, and system architecture. There are also plenty of great online resources that you can use to take this knowledge further if you plan on moving onto exploit development in the future.