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.
I am sad. Like.. really sad. I'm sad for so many reasons. For nearly
7 years I've worked on this god forsaken source, and for many of those
7 years I have had the ext_server_mimikatz project configured to have
warning level 3, and warnings as errors. While making changes to the
build systems in the last week or so, I've even rebuilt this on updated
toolsets on multiple platforms.
Despite all this, one thing slipped through the cracks. I have NO idea
why this warning wasn't shown in th past. Also.. how did this ever
work!? Why is it that it's only rearing its ugly head now? I honestly
don't know. Based on the code that I've had to fix in this PR, there's
no reason why this should build without warnings on any machine. Yet, it
does. It builds clean on my Windows 10 desktop with VS2013/2017/2019.
Same on most of my other virtual machines. For some reason it only
failed on this one VM after I had to fight to reproduce it when Brent
hand an issue.
The issue here was that a `string` type was being constructed from an
iterator over a `wstring` type, and hence there was an implicit
character conversion from `wchar_t` to `char`. This SHOULD be a warning,
because clearly that's not a good thing. BUT HERE WE ARE.
Anyway, we're proxying via the `_bstr_t` type now to avoid having to do
horrible manual character conversions. Given that we're in C++ land
already there's no point in working any harder. Also, this extension is
probably going to go away soon anyway, so a temporary fix that does the
job is good enough.
RIP my morning. I won't be getting that back.
The video and audio capture things didn't do anything other than leave
artifacts on disk. So this commit removes the code that does that,
resulting in just one feature being available for this extension. Might
be worth ditching it entirely?
