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.
Note that there are some cases of host-endian left, these
are intentional because they operate on host-local memory
or services.
When in doubt, please use:
```
ri pack
```
Ruby treats endianess in pack operators in the opposite way
of python. For example, using pack('<I') actually ignores the
endianess specifier. These need to be 'I<' or better yet, 'V'.
The endian specify must occur after the pack specifier and
multiple instances in meterpreter and exe generation were
broken in thier usage.
The summary:
Instead of I/L or I< use V
Instead of I/L or I> use N
For Q, you need to always use Q< (LE) or Q> (BE)
For c/s/l/i and other lowercase variants, you probably dont
need or want a *signed* value, so stick with vV nN and cC.
This reverts commit 9b35b0e13a.
This should not land on master until the Metasploit Pro folks (@trosen-r7
and friends) get their Meterpreter path specifications working the
same way as Framework's does.
a change was made to protspec that allowed port 0
when we explicitly dissallowed port 0. This change caused
other code that depended on this behaviour to break
JodaZ reported that the handle_connection() sock.put call can
result in the entire reverse_tcp stager hanging if the client
stops receiving or is on a very slow link. The solution emulates
what ReverseTcpDouble already does, which is stage each connection
in a new thread. However, given that a high number of threads
can be a problem on some operating systems (*ahem* win32) this
option is not enabled by default.
We should look into thread pooling and handle_connection() timeouts
as well as event-based polling of multiple clients as alternatives,
but this option will improve the situation for our existing users.
Even though there are calls to has_read_data(), it doesn't prevent
the put() call from blocking in a dead client or slowaris-like
situation. By moving the inp/out detection into the thread, we
allow the main handler to keep processing connections even if
a single connection hangs.
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.