You can choose to convert exploits to Metasploit from a different format for many reasons, not the least of which is to give back to the community and the Framework. Not all exploits are based on the Metasploit Framework; some are programmed in Perl and Python or C and C++.
When you port exploits to Metasploit, you convert an existing stand-alone exploit, such as a Python or Perl script, for use within Metasploit. And, of course, after you have imported an exploit into the Framework, you can leverage the Framework’s many high-end tools to handle routine tasks, so that you can concentrate on what is unique about your particular exploit. In addition, although stand-alone exploits often depend on your using a certain payload or operating system, once ported to the Framework, payloads can be created on the fly and the exploit can be used in multiple scenarios.
This chapter will walk you through the process of porting two stand-alone exploits to the Framework. With your knowledge of these basic concepts and a bit of hard work on your part, you should be able to begin porting exploits into the Framework yourself by the end of this chapter.
To get the most out of this chapter, you’ll need a basic understanding of the assembly programming language. We use a lot of low-level assembly language instructions and commands in this chapter, so let’s take a look at the most common ones.
Registers are placeholders that store information, perform calculations, or hold values that an application needs in order to run. The two most important registers for the purposes of this chapter are EIP, the extended instruction pointer register, and ESP, the extended starter pointer register.
The value in EIP tells the application where to go after it has executed some code. In this chapter, we’ll overwrite our EIP return address and tell it to point to our malicious shellcode. The ESP register is where, in our buffer overflow exploit, we would overwrite the normal application data with our malicious code to cause a crash. The ESP register is essentially a memory address and placeholder for our malicious shellcode.
The JMP instruction set is the “jump” to the ESP memory address. In the overflow example that we’ll explore in this chapter, we use the JMP ESP instruction set to tell the computer to go to the ESP memory address that happens to contain our shellcode.
A NOP is a no-operation instruction. Sometimes when you trigger an overflow, you won’t know exactly where you’re going to land within the space allocated. A NOP instruction simply says to the computer “Don’t do anything if you see me,” and it is represented by a x90 in hexadecimal.
A NOP slide is a handful of NOPs, combined to create a slide to our shellcode. When we go through and actually trigger the JMP ESP instructions, we will hit a bunch of NOPs, which will slide down until we hit our shellcode.