MSP-11671
Add command line option --defer-module-loads to msfconsole. It will
stop `Msf::Ui::Console::Driver` from calling
`framework.modules.init_module_paths` AND
`framework.modules.refresh_cache_from_database`. This flag is only
meant to speed up msfconsole boot when modules do not need to accessed,
such as during cucumber testing of command help or command line options.
MSP-11672
Pass `'DeferModuleLoads' => false` to `Msf::Simple::Framework.create` so
that `framework.modules.init_module_paths` is only called once (directly
in `Msf::Ui::Console::Driver#initialize`) instead of twice (in
`Msf::Simple::Framework.create` and `Msf::Ui::Console::Driver#initialize).
MSP-11672
Calling init_module_paths takes 6 seconds on my machine even when there are no
files to that are changed just because it takes that long to walk the
directories and gather the mtime for each file. Therefore, calling it
more than once should be avoided. Also, there is no reason to call it
twice as to add paths later, `modules.add_module_paths` should be used.
This allows HandlerSSLCert to be used to pass a SSL certificate into the Meterpreter handler. The datastore has to be passed into handle_connection() for this to work, as SSL needs to be initialized on Session.new. This still doesn't pass the datastore into Meterpreter directly, but allows the Session::Meterpreter code to extract and pass down the :ssl_cert option if it was specified. This also fixes SSL certificate caching by expiring the cached cert from the class variables if the configuration has changed. A final change is to create a new SSL SessionID for each connection versus reusing the SSL context, which is incorrect and may lead to problems in the future (if not already).
The exploit works with the URLs fixed, installs the APK, but hangs at the Installing...
screen and never actually launches. We tried opening the APK in a setTimeout() intent
URI, but the previously launched intent seemed unresponsive. Andre had the bright
idea of re-opening the previously launched intent with invalid args, crashing it and
allow us to launch the payload.
MSP-11614
`Msf::TaskManager` was only used for `Msf::DBManager#sink`, which was
removed because it was unused, so `Msf::TaskManager` can also be
removed.
MSP-11614
`Msf::DBManager::Sink` contains code for a `sink` that is a meant to
serialize database events, but it's unneeded because all database events
go directly through ActiveRecord, which handles threading.
MSP-11605
`Msf::Framework#threads?` returns whether `Msf::Framework#threads` was
ever initialized. If `Msf::Framework#threads?` is true, then threads
need to be cleaned up, while if it is false then no threads need to be
cleaned up from the current framework.
MSP-11605
`Rex::ThreadFactory.provider` needs to be set in
`Msf::Framework#initialize`, but setting it directly to
`Msf::Framework#threads` eliminates the laziness of
`Msf::Framework#threads`. In order keep `framework.threads` lazy,
`framework` is wrapped in a
`Metasploit::Framework::ThreadFactoryProvider`, which responds to
`spawn`, which is needed by `Rex::ThreadFactory`, by calling
`framework.threads.spawn`, which lazily initialized `framework.threads`
when the first thread needs to be spawned.
MSP-11605
Switch `Msf:Framework#db` from being set in `#initialize` to a custom
method that uses `||=` to lazily initialize the `Msf::DBManager` inside
a `synchronize` block to make it thread safe.
MSP-11605
Store options `Hash` passed to `Msf::Framework#new` in `#options` so
that lazily initialized children, such as DBManager, have access to
those options.
Luke Imhoff