Skip to content
MSF database code, gemified
Ruby Other
Find file
Pull request Compare This branch is 1 commit ahead, 1247 commits behind rapid7:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



The database layer for Metasploit


MetasploitDataModels exists to do several key things:

  1. Allow code sharing between Metasploit Framework (MSF) and the commercial versions of Metasploit (Community, Express, Pro -- usually referred to collectively as "Pro")

  2. Create an easy-to-use mechanism to guide the future development of both commercial and FOSS features.

  3. Give FOSS developers a lightweight entry point to MSF's backend for use in developing lightweight tools that gather data intended for later use with MSF (e.g. specialized scanners).



When MetasploitDataModels is included by a Rails application, it simply makes mixins available to ActiveRecord models that provide high-level behavior for those models. After performing the top-level include in an initializer, we mixins in an appropriate module from metasploit_data_models for each model that is shared.


When MetasploitDataModels is included by MSF, the gem dynamically creates ActiveRecord model classes.

Both of these behaviors are based on the assumption that the files in lib/metasploit_data_models/active_record_models, though implemented here as mixins, actually represent the ActiveRecord models that both MSF and Pro use.

Developer Info


The gem includes a console based on Pry

Give it a path to a working MSF database.yml file for full ActiveRecord-based access to your data.

Note: only "development" mode is supported now. I.e. your YAML file needs to have a "development" portion just like a Rails database.yml would.

ActiveRecord::ConnectionError issues

Because the gem is defining mixins, there can be no knowledge of the specifics of any "current" ActiveRecord connection. But if ActiveRecord encounters something in a child class that would require knowledge of the connection adapter (e.g. the use of an RDBMS-specific function in a named scope's "WHERE" clause), it will check to see if the adapter supports it and then throw an exception when the connection object (which provides the adapter) is nil.

This means that, for all but the most trivial cases, you need to use Arel versions of queries instead of ones utilizing straight SQL.

You'll encounter this sometimes as you add things to this gem. A good rule of thumb: anything that goes into the class_eval block must be able to work without knowledge of the AR connection type.

Something went wrong with that request. Please try again.