When running a command that takes host ranges as arguments (e.g.,
`hosts`, `services`), the arguments get parsed by
Rex::Socket::RangeWalker. If RangeWalker was unable to parse, it would
return nil, which in this context means "all hosts." If the user is
searching, they get all hosts instead of the ones they were interested
in -- this is annoying, but not too big a deal. Unfortunately, the same
logic applied when *deleting* hosts, with `hosts -d ...`, causing all
hosts to be deleted when giving it an invalid range.
It appears that testing of the original submit was performed
on VMWare which worked. On a non virtualized machine the
payload would crash.
[Closes#2373] [FixRm #8271]
Tested in the following configurations:
* WinXP SP0 x86 - reverse_http, reverse_tcp, ms08-067, ms03-026
* Win7 x64 fully patched - reverse_https, reverse_tcp, x64/reverse_tcp
Tested with all public extensions. Behaviour matches that of the currently released MSF.
x64 binaries no longer show up in auto-complete for x86.
This makes x86 more consistent with x64.
Also replaces a bunch of instances of:
File.join(Msf::Config.install_root, 'data', ...)
with the simpler
File.join(Msf::Config.data_directory, ...)
[See rapid7/meterpreter#19]
Instead of depth=1, try depth=5. This way, if something gets landed
before travis had a chance to build, it'll still get tested, at least
post-facto.
This is the root cause of the build failure at
https://travis-ci.org/rapid7/metasploit-framework/builds/11436293
That commit is not available because the HEAD pointer moved past it with
the next commit; IOW, we landed too quick for Travis to rspec each
change, which is generating failed build messages.
If there was really a failure in there, it'd be a pain now to determine
which commit actually broke the build.
In some cases, it was possible to end up in a situation where the x64
reflective library hadn't been loaded by the time a user typed migrate.
If the target process was 64-bit, msfconsole would error out with a
NoMethodError and much sadness would ensue.
[See #2356]