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.
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.
The goal is to avoid pointer truncation where possible so this commit
changes parameter types to qword where it makes the most sense. This
includes all handles (event, process, thread, registry), addresses
and generic parameters.
The create thread functionality would work in all cases except where
the thread was being created in an x64 process from an x86 process.
This commit adds support for this by reusing the wow64 injection code
in this case.
Previous commits removed the stack size parameter from the remote thread
creation function call. This caused issues in systems prior to Vista/2k8.
This fix puts that value back in and now everything is honky dory.
Tested on 2k/XP/2k3/Vista/7/2k8
Crashes were occuring when the underlying channel had no more output
because the value of the `bytesRead` variable was not set to zero.
Consumers of the function assumed that bytesRead was value if non-zero.
POSIX would also hang when unsupported commands are executed, this
commit changes this so that a response is returned when the command
isn't supported.
Does as it says on the tin. Various tweaks made to source and to project
files to make the builds come out with ZERO warnings.
Let's keep it clean from here!
This changeset brings windows into line with the last set of POSIX
changes. With this changeset we are now in a position where both POSIX and
Windows are able to create and open interactive channels, put them in the
background, and terminate them without crashing, hanging or leaving
processes running behind the scenes.
POSIX was out of whack with Windows as a result of the changes made
around channels. The schedular in posix was very different, and this
commit brings it into line.
Other than the obvious issues, a non-obvious issue with the changes
was that the channel was being freed up on close prior to the thread
terminating. This doesn't appear to be an issue on Windows, but was
causing crashes on close in POSIX.
The changes go quite deep. This changeset requires a lot of testing.
The goals of this work are:
* To fix issue where backgrounding and re-interacting with channels wasn't
working.
* To fix issue where closing of meterpreter was not closing off background
prcoesses (such as cmd.exe).
The two things preventing this stuff from working were:
* When interactive channels are backgrounded their handles were destroyed
along with the context that wraps them up. Making them interactive again
had no impact because the handle and context were invalid. If anything,
this made meterpreter unstable. Sometimes the session would die when
attempting to interact with the channel again.
* When closing channels, there was no way of terminating the process that
sat behind the scenes because no reference to the process was retained.
Channels would close and handles would close, but no process termination
was done.
To fix these problems:
* The interactive thread no longer terminates when backgrounded. Instead
its put in a suspended state where it's waiting a signal from a resume
handle that's associated with the channel's context. This means that the
destruction of the context doesn't happen at all until the termination
of the channel, which is exactly when it should happen anyway.
* Process handles are stored alongside the input/output handles so that
when the time comes, the process can be terminated if required. This
means that when the channels are closed, the code has a reference to the
associated process which can be terminated. This is only done for
interactive processes, non-interactive processes do not have this
problem because meterpreter doesn't have to keep track of them.
Big job, this documentation lark. Also modified the prototype the
packet_is_tlv_null_terminated function, which used to take a Packet
instance as well as the TLV, but never used the packet in its
implementation.
Initial commit of in-mem-exe.c modifications for Windows x64.
Initial boolean wrapper checks to see if the image supplied is a
valid 64bit PE and calls a 64bit injection function. wow64 not yet
implemented.
64bit execution is a bit tricky since we can't get the entrypoint
of the existing thread from ThreadContext.Eax and we need to make
sure that our images are properly aligned. The 64 bit mapper is
based on MemExec64 source code by Steve10120 [at] icode.org.
TODO:
Write wow64 based injector. Write conditional to check that
source and destination images are the same architecture and call
the arch appropriate injection method.
Write "Heaven's Gate" based injector for running x86 process in
x64 space.
Fixes client.sys.process.execute for posix, which previously (since
2010!) would always return nil, or a single byte. This makes sense
considering the value of bytesRead would always be either 0 or 1 because
it was being assigned the result of the comparison instead of the return
value of read().
[Fixes#681]
Fixes some TypeError exceptions when attempting most operations on
spawned processes, e.g.:
p = client.sys.process.execute("/bin/sh", nil, "Channelized"=>true)
p.close
# raises TypeError: can't convert nil into Integer
[FIXRM #7005]
commit df6eef12147a294d7f198d057c27e87ed4ffbeb3
Author: MM <gaspmat@gmail.com>
Date: Tue Mar 20 18:01:50 2012 +0100
ps support for linux meterpreter
[Closes#250]
In posix, a command like "echo 'foo bar'" would previously get parsed
out into arguments for execve like [ "echo", "'foo", "bar'" ] which
obviously isn't what you want. After this commit, it sticks the whole
thing in an arg to sh so the execve call ends up looking like
execve("/bin/sh", ["sh", "-c", "echo 'foo bar'"], [/* 26 vars */]) = 0
This is still a little less than ideal because shell escapes become a
problem; fortunately, that's easy to deal with on the client side as
long as module developers take it into account.
