The purpose of Msf::Post::Windows::Process is have all the common
functions you might need to do something to a process, for example:
injecting something to a process and then run it.
Functional tests in msfconsole passing, as are MSF and Pro specs. References in Pro to items that appeared session related were either debug oriented or commented out.
Changing spool setting caused problems with prompt and color. This
fix makes the following changes:
- Saves the color setting and re-applies it to the new output console
- Sets the prompt in the same way that cmd_use does
After many tests, it turns out address 0x0c0d2020 is the most
consistent location acorss various IE versions. For dev purposes,
it's rather important to have this documented somewhere.
Thanks to corelanc0d3r for the data.
Also replaces dead code in lib/msf/core/exploit/local.rb with what was
actually being used for the Exploit::Local class that lived in
lib/msf/core/exploit.rb.
Aside from codebase-wide changes, nearly all of these tests haven't been
touched since before 2010, and there is no effort to maintain this style
of testing. We've moved on to (correctly) seperating out our tests from
our codebase.
While it makes lots of sense to bring check to all modules, of course
some modules will not be able to actually use it. Namely modules like
nop and payload modules. If you're feeling creative, you could probably
come up with semantically similar checks for those, too.
[#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.
[#47720609]
Fix some docs and variable names to make it clearer when methods are
expecting module instance and module classes. Change some 'name'
variables to 'reference_name' since that's the proper terminology.
[#50179803]
[SeeRM #7967]
[SeeRM #7870]
Because metasploit-framework runs migrations with the same process and
with the same connection as it later accesses the database, the column
information can become cached prematurely and be incorrect by the end of
the migrations. Fix the bad cache by automatically resetting the column
information for all model classes after the migrations have run.
[#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.
Allows console users to use the 'run' command for exploits as well as
auxiliary and post, in the same way that 'exploit' works for all three.
Saves some typing and makes it do the right thing so users don't have to
remember what kind of module they're using.
- Added sorting to cmd_notes
- Added make_sortable function so that sorts work happily even
when the disparate notes don't have content of the same types
in the fields the sort is requested over.
[#50099107]
If Msf::DBManager#initialize_metasploit_data_models is run multiple
times, such as during specs, ActiveRecord::Migrator.migrations_paths was
getting populated with multiple copies of the metasploit_data_models
db/migrate path, which would lead to 'DB.migrate threw an exception:
Multiple migrations have the version number 0' errors in framework.log.