This is a weak attempt to solve a race condition between modules loading
and cmd_use being fired. Upon startup, saved configurations, running
resource scripts, and running commands will sometimes jump ahead of the
module loading procedure.
I have not discovered where the race actually is and how to cause the
race to happen. However, the timing seems to be fairly close to a second;
by waiting three seconds after trying use again, we seem to be in the
clear, at least according to testing.
Fixes#4549, but better solutions are welcome!
This adds an extra parameter to most of the post/windows/registry
methods called 'view' that specifies if a registry key should be
accessed as a native process, 32-bit or 64-bit.
Support is added to both the Meterpreter and command-line backends. For
the command backend, a lot of boilerplate is removed from each method in
favor of a few shared commands. There is an error hash that never gets
used, so I removed it as well.
This passes the post/test/registry module with meterpreter, but fails
the command line backend. However, it fails in the same way without
these changes (tested on Windows 8), so I suspect that the command line
session was already not working well, at least with newer versions of
Windows. I might look into figuring out how to fix that, but it looks
pretty fragile to me, parsing for english phrases in the output.
I have been using the script in real life cases which have bigger e-mailboxes then in the testing environment. Because of execute_script default time_out no results return, as the powershell scripts run longer then 15 seconds. Changed the timeout to 120.