Since these stagers can shrink based on the expected size of the next
stage, do our best to anticipate a small size. This makes the cached
payload size consistent for now, though if the x64 mettle stager grows
past 128 bytes I think we'll see the stager start oscillating in size
again. If you run into that and are reading this, sorry :(
The linux x64 reverse tcp stager is hardcoded to read 4K off the
socket. When a small intermediate stager is used, this can result
in reading part of the next stage as well, which means that the
intermediate stager will never recv the # of bytes it needs and
hang indefinitely.
Break out the mettle piece to use separate methods for assembly and
binary payload generation as well as actually putting the product
on the existing session socket.
Change the first part of the stage to check for the intermediate
stager generation method, and use the size of the produced stager
in the recvfrom call or fall back to the prior 4K read size.
Testing:
None yet
Ping @bcook-r7, @acammack-r7, @OJ, @ZeroSteiner
RageLtMan