The nMaxInstances argument refers only to subsequent calls to CreateNamedPipe and not to calls that just open the pipe.
There is no reason to enable anybody else but us to create a pipe with the same name.
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.
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?
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.
Added /MP for parallel builds, and removed precompiled headers as /Yc
isn't compat with /MP.
Not enabled for the Powershell extension because of it's .NET-ness.
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.
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.
