This reverts commit d66779ba4c.
Specifically, this commit was causing trouble when a datastore was
getting an Integer. For some reason (as yet undiscovered), the option
normalizer wasn't trying to Integer#to_s such arguments.
This kind of thing is going to happen a lot. For now, I'd rather just
end up with the ducktype, and attack the normalizer in a seperate fix.
SEERM #4821
while looking into what it would take to fix bug 4821, I found that there are no specs
for any of the other methods in command dispatcher. I have attempted to add stubs for a
few of the methods and tested a few of the help outputs.
PacketFu should be required from the gem, not from the shipped msf
library. Several modules depend on it being available, so this rspec
test mostly just ensures that Msf::Exploit::Capture mixin is still
around.
[#47720609]
Msf::PayloadSet#add_module does NOT return an annotated module class as
Msf::ModuleSet#add_module does because a payload module is defined as a
ruby Module instead of a ruby Class. Since add_module doesn't always
return an annotated_class, the logic in
Msf::ModuleManager#on_module_load needed to change to NOT use
annotated_class and create #add_module as return [void]. Thus, it is
necessary to pass in all the metasploit module metadata to
Msf::ModuleManager#cache_in_memory instead of assuming they can be
derived from the (payload) Module or (other) Class.
[#47720609]
Msf::ModuleManager#module_info_by_path was not being updated when a
module was loaded, so if a load_module was called again, say during
start up of prosvc, the module would reload even though there was no
change in the file because file_changed? couldn't find an entry for the
module's path in module_info_by_path.
[#50179803]
Move Msf::DBManager#migrate and the migrated attribute to
Msf::DBManager::Migration module to lower complexity of db_manager.rb
and in preparation for more migration related code on this branch.
[#49858419]
[SEERM #7958]
metasploit_data_models 0.14.3 relaxes the validation on
Mdm::Module::Detail#stance so it only needs to be in
Mdm::Module::Detail::STANCES if Mdm::Module::Detail#mtype is 'auxiliary'
or 'exploit' as framework only supplies a stance for those types when
using Mdm::Module::Detail.
[#47979793]
Multiple files define Msf::DBManager, but it's better to have one spec
for Msf::DBManager, so change spec structure to reflect module and class
hierarchy instead of file hierarchy of defining files.
[#47979793]
[#48414569]
Even though using Timecop locally on OS X makes the `should == <Time>`
work, it fails on travis-ci, so try using `should
be_within(1.second).of(<Time>)` instead.
[#46491831]
Move Msf::DBManager#import_msf_xml into
Msf::DBManager::ImportMsfXml#import_msf_xml and include
Msf::DBManager::ImportMsfXml to cut down size of the infamous db.rb.
Break up #import_msf_xml to have separate methods for parsing web_forms,
web_pages, and web_vulns. The method for
web_vulns, #import_msf_web_vuln_element is needed so that it can be overridden in
Pro to handle the Pro-only changes to Mdm::WebVuln.
[Fixes#38426061, #38097411]
Msf::Modules::Loader::Directory#read_module_content may calculate a non-existent
module_path that gets passed to File.open causing an Errno::ENOENT exception
to be raised when using the module cache with a module that has been
moved to a new path (as is the case that originally found this bug) or
deleted. Now, the exception is rescued and read_module_content returns
an empty string (''), which load_module detects with
module_content.empty? and returns earlier without attempting to module
eval the (empty) content.
As having Msf::Modules::Loader::Directory#read_module_content rescue the
exception, meant there was another place that needed to log and error
and store an error in Msf::ModuleManager#module_load_error_by_path, I
refactored the error reporting to call
Msf::Modules::Loader::Base#load_error, which handles writing to the log
and setting the Hash, so the error reporting is consistent across the
loaders.
The exception hierarchy was also refactored so that
namespace_module.metasploit_class now has an error raising counter-part:
namespace_module.metasploit_class! that can be used with
Msf::Modules::Loader::Base#load_error as it requires an exception, and
not just a string so the exception class, message, and backtrace can be
logged.
Msf::Modules::Loader::Archive#each_module_reference_name tried to check
the enabled types for the module_manager by accessing the
enabledment_by_type Hash, which is protected. Instead, it should use
the public type_enabled? method.
Add specs to test all of Msf::Modules::Loader::Archive while testing
each_module_reference_name. In order to properly test that modules
could be found in archives, I had to produce a fastlib archive, so there
is now a spec for FastLib.dump and FastLib.load. Some specs are marked
pending as I found a bug in FastLib, which has a work-around. The bug
is filed in PivotalTracker as
https://www.pivotaltracker.com/story/show/38730815 and the pending tests
include the URL also in their tags.
Just had a brain fart when converting the hash key names and translated
:mtype to :modification_time instead of the correct :type. Correct key
names are in
Msf::ModuleManager::Cache#module_info_by_path_from_database!.
Msf::Config.install_root already existed, but I didn't know about it
until egypt pointed it out, so remove the new Msf.root and use
Msf::Config.install_root in the specs instead.
[Fixes#37630057]
Modules were always being detected as having file changes because the
parent_path directory, instead of the actual module_path, was being
passed to module_manager.file_changed?, which caused the modification
times to not match.
To ensure this change fixes the ambiguous module warnings, a full spec
for Msf::Core::Modules::Loader::Base has been written.
spec/msf has moved to spec/lib/msf to match conventional spec layout and
allow for the spec/support directory to not be confused as a lib
subdirectory being tested.