Got an issue where certain functions aren't being resolved and hence are
null when being invoked. Need to debug the loading of the DLL to see why
this is the case.
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.
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.
