Various values were adjusted to become QWORD values in MSF an windows
meterpreter, but the changes were not ported over to python, php and
java. This commit fixes this inconsistency.
Unfortunately, though, there seems to be a stealthy set, somewhere, of
datastore['DLL']. Not sure where yet. The stack trace in the
framework.log is:
````
[06/19/2014 17:53:34] [i(0)] core: windows/meterpreter/reverse_http: iteration 1: Successfully encoded with encoder x86/fnstenv_mov (size is
366)
[06/19/2014 17:53:35] [e(0)] rex: Proc::on_request: Errno::ENOENT: No such file or directory -
/home/todb/git/rapid7/metasploit-framework/data/meterpreter/metsrv.x86.dll
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/reflective_dll_loader.rb:26:in `initialize'
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/reflective_dll_loader.rb:26:in `open'
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/reflective_dll_loader.rb:26:in `load_rdi_dll'
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/payload/windows/reflectivedllinject.rb:56:in `stage_payload'
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/handler/reverse_http.rb:212:in `on_request'
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/handler/reverse_http.rb:129:in `block in setup_handler'
/home/todb/git/rapid7/metasploit-framework/lib/rex/proto/http/handler/proc.rb:38:in `call'
/home/todb/git/rapid7/metasploit-framework/lib/rex/proto/http/handler/proc.rb:38:in `on_request'
/home/todb/git/rapid7/metasploit-framework/lib/rex/proto/http/server.rb:365:in `dispatch_request'
/home/todb/git/rapid7/metasploit-framework/lib/rex/proto/http/server.rb:299:in `on_client_data'
/home/todb/git/rapid7/metasploit-framework/lib/rex/proto/http/server.rb:158:in `block in start'
/home/todb/git/rapid7/metasploit-framework/lib/rex/io/stream_server.rb:48:in `call'
/home/todb/git/rapid7/metasploit-framework/lib/rex/io/stream_server.rb:48:in `on_client_data'
/home/todb/git/rapid7/metasploit-framework/lib/rex/io/stream_server.rb:192:in `block in monitor_clients'
/home/todb/git/rapid7/metasploit-framework/lib/rex/io/stream_server.rb:190:in `each'
/home/todb/git/rapid7/metasploit-framework/lib/rex/io/stream_server.rb:190:in `monitor_clients'
/home/todb/git/rapid7/metasploit-framework/lib/rex/io/stream_server.rb:73:in `block in start'
/home/todb/git/rapid7/metasploit-framework/lib/rex/thread_factory.rb:22:in `call'
/home/todb/git/rapid7/metasploit-framework/lib/rex/thread_factory.rb:22:in `block in spawn'
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/thread_manager.rb💯in `call'
/home/todb/git/rapid7/metasploit-framework/lib/msf/core/thread_manager.rb💯in `block in spawn'
````
Still tracking this down.
This was a whoops on my part. I will reland this when I have the
Meterpreter bins all sorted.
This reverts commit 40b5405053, reversing
changes made to 86e4eaaaed.
This code adds support for the new service_control feature in meterpreter
and also supports the status field that comes from the service_query function.
The call to `getenv` failed when `%` or `$` were used because of the
differences between Meterpreter handling and MSF handling.
Meterpreter effectively ignores (ie. strips out) the platform-specific
characters which are used for environment variables. In the `getenv`
call, MSF was invoking `getenvs` and getting a full hash of values, then
attempting to index into the hash using a string which may be "polluted"
with those platform-specific characters. This meant that there was a
discrepency between what was returned and what was used to index and
as a result, the value would come out as `nil`.
For example, calling `getenv('%FOO%')` would result in a hash with
`{'FOO'=>'bar'}`, so looking for '%FOO%' in this result would yield
nothing.
This commit changes this so that the name is ignored and the first
value is returned.