The issue lied in the fact that Pythonw.exe is not a cmd.exe
application, but rather a GUI application. In turn GUI applications
don't have stdin/stdout/stderr and thus if we'd create subprocesses from
a Pythonw application that will automatically retrieve those file
descriptors we'd receive a couple of exceptions as they don't exist.
This commit works around the issue by not using the file descriptors in
the first place.
Bugfix as per 2e9f663da6ca90cc46b8a578bdd8c801eda1eec0 by spender. This
avoids the issue where the socket timeout remains at 0.1 second after
connecting, providing the possibility to throw around exceptions.
Send over the whole memory dump from the Analyzer. Update to the latest
monitor which sends out the KILL message to the Analyzer. Resolve page
access permissions, ignore dump files not ending with .dmp, and rename
space to regions.
The monitor now informs the Analyzer when a process is about to finish.
This allows the Analyzer to dump the process memory right before it
actually finishes and thus adds support for dumping memory of processes
that terminate before reaching the critical analysis timeout (if that
even occurs in the first).
Furthermore the new dumping logic, which is now embedded in monitor's
inject.exe utility, also dumps metadata about the memory pages such as
their protection, size, etc. (And by separating the functionality into
a separate utility we now also support 32-bit vs 64-bit differences).
And last but not least we also support dumping processes multiple times
just in case this appears useful in the future.
When we analyze a URL we don't Internet Explorer to take a minute to
fully load while appearing to freeze all the time, this simply doesn't
work practically speaking.
In the iexplore monitoring mode we only look at a very small subset of
the functionality provided by the monitor so to load websites close to
as fast as they would be loaded without the iexplore mode. Of course
this subset should still containing all the critical functionality such
as following created sub-processes, but if anything is missing as-is
this can be added later on.
One final note; including monitoring functions related to exploitation
techniques shouldn't fall under the iexplore monitoring mode per se as
we can simply combine the iexplore mode with the to-be-implemented
"exploit" monitoring mode.
The _winreg API doesn't play nice under Windows XP due to Volatile
Registry limitations. Therefore we fallback to using the Windows API,
which does apparently work.
After having been overwriting the binaries in analyzer/windows/bin for
too many years now, it's time to start building up a small but useful
database of monitoring binaries in data/monitor/.
When releasing new features or bug fixes which also affect the monitor,
we can now update the data/monitor/latest symbolic link to point to the
Git hash of the required monitor version. Upon start of Cuckoo we can
then check whether the symbolic links target exists and report to the
user the need to upgrade to the latest monitoring binaries if it does
not. (In the end this will only occur when a user manually updates his
or her Cuckoo setup or does a Git clone of the Git repository).
Aside from the improved user experience this will also improve our
ability to bisect the monitor against older versions of it. Sometimes
new features break older features or introduce crashes. Being able to
replay analyses with older monitoring binaries we should be able to
have bisect-like functionality more easily (without race condition
problems that are introduced when overwriting the analyzer/windows/bin
directory while running multiple analyses in parallel).
This makes our Java package compatible with future versions of Java
without having to update Cuckoo with new paths later on. Thanks to
Statixs for reporting that the latest version of Java was not found.
Jurriaan Bremer