Currently, if any payload fails to generate that has a dynamic size, it causes a Framework instance to throw an exception on start. This can happen for a number of reasons, and more often than not it is enviromental (files missing, Y2k38 bugs, etc.). Instead of failing entirely, catch the exception and log as an error, don't register the payload, but continue booting.
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 :(
Push read_size to edx as suggested by Adam, optimize shellcode a
bit by selecting using dx instead of edx for sizes under 64K.
Testing:
Internal only, creates session on every try instead of every 5th.
See notes for x64.
This part does not appear to be working properly yet - stages
generated with this commit recv 102b on the first call to read(),
but subsequently things seem to go off the rails after the
intermediate stage is loaded.
Needs testing and fixup at present for x86 (no worse than before
in terms of success rate however).
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
Also uses the class refname where appropriate since an instances refname
reflects the alias currently in use and if a module is reloaded while
using an alias the old behavior would generate spurious cache entries
that would not be cleaned up or modified. Specifically, this could
register a self-referential alias that would cause a stack overflow when
trying to `use` such an alias.
Additionally, some other `fullname`s were changed to `realname`s for
clarity.
Metasploit