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.
This commit includes a bunch of changes that are working towards being
able to build the Meterpreter source from CMake. Changes include:
* Updated `make.bat` which does the stuff that we need.
* Removed a bunch of stuff from the python extension source tree so that
CMake generator would not include them.
* Moved a few things around in the priv extension.
* Created `CMakeFileLists.txt` for all the projects.
There are a few hacks required in things like stdapi and kiwi to ignore
files that are on disk but shouldn't be included in the build.
Initial testing indicates that sessions run, extensions load, but some
things don't work as intended. It's a start! Still much to do.
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.
Warnings as errors, builds clean. Had to do some horrible hacks:
1) Include custom implementation of a lib function just so we could
link against stuff built with older VS.
2) Include legacy symbols for old io for the same reason.
DCSync functionality is exposed, and from this it is possible to enumerate all users in the domain and dump each user's hash one by one. This code has a few extension functions built into the runner, and also has some baked-in powershell functions that are available in every powershell runner session in the host.
I've also added a powershell version of the build command that lets us generate the source to the powershell assembly wiring from PSH as well as Python.
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.
The package script was (stupidly) written (by me) to replace '\\' with
'.' when generating python import module names. Of course, this works
great on windows, but it means if you generate the package on linux
things break horribly. The result was that the latest package wouldn't
resolve anything useful when importing key stuff like ctypes or pty.
This PR fixes the issue so that the modules are correctly wired in
regardless of the OS that the package was constructed on.
This commit includes code that was missing from the original Python PR which adds support for the multiprocessing module in Python. I have no idea why this was missed, but it was. The code also includes adjustments to the loader which attempts to resolve modules appropriately based on name. This is a bit of a kludge thanks to the way that Python module resolution hooks work, as it's not clear exactly which namespace the module is intended to be loaded from at runtime as it's not passed to the resolver. Down the track we may need to get smarter with the resolver so that we have a per-module resolver (ie. a tree of resolvers).
