A bug in the read function would cause a too-large read when there are multiple
packets or other things in the control channel. This would cause the subsequent
packet to fail to parse, leading to the current message getting discarded.
This is the payloads section of MSF #7669
Implement SSL transport via streams, atop the current version of
PHP meterpreter (with GUIDs and all).
This version does everything in a single file, relying on the MSF
payload generation component to perform string substitution in
order to convert the "connect($ipaddr, $port, $proto='tcp')" to
"function connect($ipaddr, $port, $proto='ssl')."
Crypto context stuff appears to have only ever been supported in
Meterpreter on Windows. The only thing it allowed for is XOR, which is
redundant given that we have packet level XOR in place. Also, it would
appear that MSF didn't have support for it anyway!
With the move torwards packet-level encryption, this is unnecessary so
it needs to go bye bye.
This commit fixes cases where stageless meterpreter payloads may not run
if they are loaded within a PHP context that's already inside the
opening and closing <?php ... ?> tags. While this is rare, it's possible
that this may happen. This approach matches that which we use for staged
payloads.
When we read from a channel in PHP, if there is more data returned by
read() than the caller asked for, the data is cached in a 'data' element
in the channel hash. However, since get_channel_by_id() returns a copy,
we immediately lose all of that extra data on the first read. We need to
get the hash by reference in order to modify its elements.
See #4400. This should be all of them, except for, of course, the module
that targets Redmine itself.
Note that this also updates the README.md with more current information
as well.
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.
