Add support for loading RDI-related stuff using ordinals instead of
function names. Remove exports from the extensions/etc. This is another
step in the direction to make the DLLs less obvious.
Extensions no longer have their own name in the library metadata.
They're all "extension.dll". Metsrv is now "server.dll" and the two
non-extensions are "plugin.dll". I was going for something a little less
obvious.
This required changes to the RDI functionality.
Enumeration of commands was a bit of a hack, and still resultsed in
strings (like "stdapi") to appear in binaries, and also meant that
extensions needed to identify themselves.
This code changes the way this works. Extensions no longer have a name.
Instead they have an internal ID tha maps to the command sets they
support. To enumerate extension commands, MSF will ask for a range of
commands, and if any command IDs fit within that range, they'll be
returned.
This moves us towards a nicer way of handling things across all the
meterpreters.
We now use ints, and hopefully this means we don't have as much obvious
stuff in the binaries!
```
$ # Before:
$ strings metsrv.x86.dll | grep core_ | wc -l
46
$ # After:
$ strings metsrv.x86.dll | grep core_ | wc -l
0
```
Big win, and it's even bigger for the likes of stdapi.
Had to fix a bunch of other stuff along the way, including a subtle
issue with the Powershell Meterp bindings.
The 'common' library has been removed. The only project that actually
used it was metsrv, so the code that metsrv required from common is now
directly compiled in as part of that project.
The common folder now contains files that are importanta cross all of
the projects, with a primary focus on the new "API" style function. What
this means is that MetSrv has an API that it exposes through a function
pointer that is passed to the extension when it's initialised. This
pointer references a structure with all the API functions wired in. This
means that:
* Extensions don't need to know anything about metsrv at compile time.
* The delay loading code can be removed, which was one of the last
instances of "metsrv.dll" as a string.
* Metsrv.dll no longer exports any functions.
More to come.
This was a bit of a pain, but was well worth it. Had to add a couple of
hacks to make it all work, but this is a nicer solution than having to
depend on OpenSSL and its horrendous build experience.
I found an edge case where stageless payloads did not work when they
were embedded in .NET applications. The reason for this is because the
configuration block is stored alongside the code in stageless payloads
and hence is loaded into memory as part of the section when it's mapped.
This section, in native world, remains RWX, and hence we don't have a
problem reading from and writing to it. We write to it for various
reasons, such as when the session guid changes.
In .NET land, this section is mapped as RX instead of RWX. This means
that when we try to write to it, the program segfaults due to an access
violation.
This code modifies the loading of the configuration so that instead of
maintaining a pointer to the original configuration, it instead creates
a copy of it on the heap. I preferred this fix over marking the memory
as RWX, which obviously stands out a bit more.
Windows Meterpreter that uses http/s-based transports wasn't correctly checking for cases where pivoted packets were handled. When pivoted packets are forwarded to the correct handler, the packet is set to NULL. For TCP transports, a check already existed to carry on when the packet was NULL, but this wasn't the case for HTTP/S.
This commit fixes this problem and so the pivot session no longer dies when Meterpreter is using an HTTP/S transport.
For funzies, the fix for this was implemented on a live stream to help other people learn some of Meterp's internals. That video can be found here: https://www.youtube.com/watch?v=de-UYWnafow
This updates the packet header so that the encryption byte flag is now
32 bits. This also updates the powershell and python extensions so that
both of the bindings work correctly as a result of the TLV packet header
changes.
