In the computer security ecosystem, the exploit is king. There is certain mystique about the lines of code that can vanquish a system and entice it into doing ones bidding. These same lines of code embody the power that the exploit writer wields in the electronic world; the power to influence and control the code execution path of a program that someone else wrote to serve some entirely different purpose.
If one looks at the traditional exploit development process, or for that matter, analyzes the vast amount of proof‐of‐concept (PoC) code freely available; it becomes immediately apparent that a significant portion of this code is re‐useable. For example, most buffer overflow exploits will have to construct a buffer with shellcode, and all remote exploits will have to call socket routines to launch the attack at the target across the network. As a result, most regular exploit writers maintain libraries of commonly used methods that they can plug in from exploit to exploit.
The Metasploit Framework goes far beyond that. While it does give the security researcher reliable libraries of code for everything from assembler routines to RPC methods and buffer conversion functions, it also gives us an engine which makes exploit code so modular that almost any parameter can be dynamically changed at runtime. This is no small feat when one considers that the traditional exploit is usually very static. It is precisely tailored to run just one particular payload on just one version of a service that runs on one specific version of an O/S.
It is fast becoming an essential tool for anyone who deals with computer security at the blood and guts, non‐theoretical plane. No matter what shade of hat you wear, if you don’t understand the framework beyond its simple use as an exploit execution engine, you are not doing justice to one of the most versatile weapons in your exploitation arsenal.
Click Here to download this paper