This commit adds several constants for TRANS2, QUERY_PATH_INFO, MAX_DATA_COUNT,
and NT2 FLAG2 Bits to smb/constants.rb, which have then been utilised in smb/server.rb
to reduce the use of magic values.
Rather than operating on a passed-in HKEY, these open and close the registry
key directly for each operation.
This pattern better reflects the actual API usage within msf, and removes extra
round-trips to open and close the registry key, reducing traffic and increasing
performance. I did not add direct versions of every registry operation.
There was no benefit for more rarely-used operations, other than requiring more
churn in the meterpreters.
The primary beneficiary of this is post exploitation modules that do registry
or service enumeration. See #3693 for test cases.
This patch fixes#4711.
The problem here is that the browser sometimes will shutdown some of our
exploit's connections (in my testing, all Java), and that will cause Ruby
to call a rb_sys_fail with "getpeername(2)". The error goes all the
way to Rex::IO::StreamServer's monitor_listener method, which triggers a
"break" to quit monitoring. And then this causes another chain of reactions
that eventually forces BrowserAutoPwn to quit completely (while the
JavaScript on the browser is still running)
This commit add a draft of an NTFS Parser and a post module
to gather file using the raw NTFS device (\\.\C:)
bypassing restriction like already open file with lock
Can be used to retreive file like NTDS.DIT without volume shadow copy
Rather than assume that the destination argument is a directory, check
first, and then do the same thing that 'cp' would do.
- If dest exists and is a directory, copy to the directory.
- If dest exists and is a file, copy over the file.
- If dest does not exist and is a directory, fail.
- If dest does not exist and is a file, create the file.
In #4475, I incorrectly interpreted the role of the 'incomplete' array
in monitor_socket, and that change should be reverted.
What appears to happen is, we play a kind of 3-card monty with the list
of received packets that are waiting for a handler to use them.
monitor_socket continually loops between putting the packets on @pqueue,
then into backlog[] to sort them, then into incomplete[] to list all of
the packets that did not have handlers, finally back into @pqueue again.
If packets don't continually get shuffled back into incomplete, they are
not copied back into @pqueue to get rescanned again.
The only reason anything should really get into incomplete[] is if we
receive a packet, but there is nothing to handle it. This scenario
sounds like a bug, but it is exactly what happens with the Tcp Client
channel - one can open a new channel, and receive a response packet back
from the channel before the subsequent read_once code runs to register a
handler to actually process it. This would be akin to your OS
speculatively accepting data on a TCP socket with no listener, then when
you open the socket for the first time, its already there.
While it would be nice if the handlers were setup before the data was
sent back, rather than relying on a handler being registered some time
between connect and PacketTimeout, this needs to get in now to stop the
bleeding. The original meterpreter crash issue from #4475 appears to be
gone as well.
jvazquez-r7