A few minor issues around formatting collisions, nothing huge.
.gitignore fixes too
Conflicts:
source/common/base_dispatch_common.c
source/extensions/stdapi/server/stdapi.c
This is a new command in the stdapi which allows the caller to pass in a set of
environment variable names and retrieve a hash of the names and values.
I felt into the C progrmmer's trap of accidentally using `=` instead of `==`. This is
not good. Good catch @jlee-r7.
This commit fixes this, swaps the values around and tidies up code a bit.
MSF side has been attempting to open keys to see if they exist, which isn't
fantastic as it results in an error. This change adds a function which indicates
to the caller if the given reg key exists.
The work that was done a while back to fix up command dispatching allowed
inline commands to run so that the server could be told to shutdown. Those
commands that want the server to terminate (such as migrate and shutdown)
should have returned `FALSE` instead of `TRUE` to tell the server thread to
stop.
I have no idea why those values were incorrect, but it's my work so it's
definitely my fault. I will have to sick back and lick my wounds for a while.
I hate it when I'm stupid.
Thanks to Kevin Mitnick for the bug, and @todb-r7 for the investigating the
history.
Redmine: [FixRM #8696]
I found that the BREAK_* macros behaved differently on POSIX and in
some cases this was causing a brutal exit of POSIX meterpteter in
cases where it should just gracefully fail.
After talking to egypt, we decided to use `break` statements instead
given that's how it should function.
During the call which establishes a TCP client channel, the call
to `connect` can sometimes fail if the settings that are used are
incorrect (such as an invalid port number). When this call fails
the result was being set to `GetLastError()`, which isn't correct.
On Windows it should be `WSAGetLastError()` and on POSIX the `errno`
value should be used instead. This wasnt causing issues on Windows
but on POSIX it was causing problems because the `GetLastError()`
call was returning zero, which was returned to the function that
invokes `create_tcp_client_channel()`.
Given that `ERROR_SUCCESS` == 0, the caller believed the function
had completed successfully and hence relied on context being set up
correctly. This was resulting crashes because this obviously wasn't
the case.
I also added a code chance which makes meterpreter attempt to bind
to `0.0.0.0` if binding to the specified address fails.
In previous work done during the command refactor the mechanism for overriding
commands changed such that it wasn't invoking commands if they were overriden
by an extension. This, it would appear, broke some stuff. Badly.
This commit fixes this issue by reinstating the way things were done before.
If a base command exists, it is always executed. If an extension also exists
which overrides this command then the base command result is ignored, the
extension command is executed, and the result of that command is returned.
Fixed up the cusom command declarations in the sniffer extension so
that they're using the new macros. I don't know how they were missed.
Various bits of tidying up, while trying to sort out the sniffer prob.
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.
