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.
Webcam code was sometimes causing crashes in Meterpreter when attempting
to stop the camera after a frame had been captured. This appeared to be
because the thread that started the capture was not the same thread that
ended it.
CoInitialize() and CoUninitialize() need to be called on the same thread
and objects created on one thread need to be released on the same thread.
This change results in a new worker thread that is used for the lifetime
of the capture, and the callers have to interact with this thread via
basic threading events.
This is currently "proof of concept" code, rather than production-ready
code. The goal is to see if it solves the issue on the known targets
before tidying it up and locking it down for release.
The main issue with things being broken was because the calling
convention was not defaulting to "stdapi" and hence the call would
fail. Adding the default fixed it.
While fixing this, I brought the mulit-call functionality up to speed
with the error message functionality, so the calls all return the
properly formatted error message.
Thanks to @jvazquez-r7 doing some investigation we have a better solution
to this crash. This commit implements this fix and removes the need to
check the status of the memory that's being read.
Exploitation of the System process on Windows XP SP0 resulted in crashes
when metepreter was enumerating network interfaces. It appears that the
System process isn't able to read from the address that contains prefixes
(stored in pPrefix in interfaces.c). In other cases, such as exploitation
of svchost.exe or via an msfpayload-generated exe, there was no such
crash. This is not an issue on later versions of Windows.
This crash happens in the current "production" version of Meterpreter that
was deployed with MSF v4.7.
The MS08-067 exploit targets the System process, and hence crashes.
The MS03-26 exploit targets svchost, and hence does not crash.
Checking the protection of the memory in each of those cases showed that
the MEM_COMMIT was set when not the System process, and was MEM_RESERVED
when it was. Sample runs can be seen here: http://pastebin.com/2WHqJ90A
This commit is an attempt to avoid this crash down the track, and it just
does a simple check to see if querying the area of memory for the current
process shows a state of MEM_COMMIT. If so, it carries on as per normal,
if not it uses the other legacy code path to traverse the network
interfaces.
With this "fix" in place I have not seen a crash at all on Windows XP,
Windows 7, Windows 8 and Windows 2012.
This code was lost in the transition when the meterpreter source was
removed from the metasploit-framework source. I'm pulling this in by
request of @dmaloney-r7 who originally requested this code be inculded
as part of https://github.com/rapid7/metasploit-framework/pull/740
I added an extra bit of code to free up memory that is allocated by the
call to FormatMessage and forced the ASCII-version (FormatMessageA) of
the call.
* make_pair() changed in C++11 so this change fixes the code so that the
compiler doesn't complain any more.
* Compiler was also complaining about redefinition of U_CHAR. Undefining
before redefining resolves the issue.
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.
Instead of invoking the Watson crashamajigger when the process
associated with a connection has a long executable name, truncate to the
length available in the buffer.
[See #609]
