Welcome to this module on the architecture of the Metasploit Framework.
We'll talk more about how the framework is put
together and some of the key components.
This will help you later as you begin to learn more about using
Metasploit for testing. In this module, we'll focus our time on the
modular design of the Metasploit Framework,
how files and folders are laid out in the framework and its alignment
to that modular design, the libraries used by Metasploit and their
capabilities, how modules are configured,
how exploits work together with payloads, and finally, more
on using Meterpreter. The Metasploit Framework uses a
modular approach in its assembly.
You've already heard me refer to auxiliary and post modules in
this course. Exploits, payloads, and several other parts of
the framework are also modules.
Modular programming is a software architecture design that decomposes
functionality into smaller divisible pieces, or modules.
For Metasploit, this means that each type of scanner, fuzzer,
exploit, or payload is a distinct piece of functionality.
These modules are independent from each other,
meaning that the functionality of one module is not related to or
dependent on another module. Metasploit has not 1 exploit,
but 2000 separate exploit modules.
The modules are interchangeable and can be replaced as needed.
The developers for Metasploit can replace just a single module with
a better one with no impact on the framework.
You could also build your own modules, and Metasploit can incorporate them.
Let's look at the current module types in the Metasploit Framework.
We've already talked about auxiliary, exploit, payload, and post module types.
The remaining types are specific to payloads.
There are encoder modules that are used to transform the payload code
into something that antivirus tools do not recognize.
Evasion modules transform payload code to evade specific software restrictions.
NOPs, or NoOps, refer to assembly language
instructions that perform no operation.
These are used to create NoOp sleds used in exploits.
They slide the execution flow to a point where the payload code is executed.
These are instruction set specific, so there are modules for each processor type.
The framework was designed from the beginning to be extensible and
allow the community of penetration testers to help grow its
capabilities through their contributions.
The modular nature of the framework allows the improvement of existing modules.
You can create a copy of existing code of a specific
module and make it more useful or fix bugs.
You can create your own modules for testing vulnerabilities,
exploits, or specialized payloads, which have unique functionality.
You can submit those modules to the Metasploit Project for
inclusion in the framework. Metasploit modules are self‑contained
with their own documentation included.
Shown here is the information that is included with a specific
module. You can see a short description,
the author, actions, and options.
We'll talk more about those options later. On the Globomantics Red Team,
there's an emphasis on having the right tool for the right job.
The team wants each member to learn the penetration testing
tools that they need for the job and to understand how they work
so that they can use them quickly and effectively and expand
their capabilities as needed.
We'll spend more time on the architecture and operations of the
Metasploit Framework to help you along with these objectives.