ohio813 / ghost-usb-honeypot Goto Github PK

Whenever a process writes data to the emulated device, the honeypot should 
collect data about that process.

The information about writing processes that is collected in kernel mode must 
be transmitted to user mode in order to be displayed in the UI.

The system sends our emulated device a variety of IOCTLs. We don't support all 
of them - some more should be handled in order for the device to appear more 
realistic.

When an image file is unmounted, we should compress it so that it consumes less 
disk space. This is independent from file system-specific mechanisms like 
sparse files.

Currently, the user-mode tool can choose the location of the image file. We 
need some mechanism to avoid this - there should be a fixed location, so that 
attackers can't overwrite arbitrary files.

Installing the drivers is a bit tedious at the moment. The controlling 
user-mode library (see issue 9) should automatically install/update the driver 
if necessary.

The NTFS file system supports sparse files. Making the images sparse should 
save a lot of disk space.

Hallo 

Bei mir funktionierte das mounten nicht !

Ich erhielt danach eine Datei gd9.img im Ordner.
Nach dem ändern der Zeile in gohst.cs
        protected const int GhostDeviceID = 9;
in
        protected const int GhostDeviceID = -1;
war das mounten korrekt.

MfG Roy

At the moment, the frontend itself manages the interaction with the kernel-mode 
components. In order to support other uses of the kernel-mode part (such as 
analysis within sandboxes, other frontends), we'll encapsulate the interaction 
in a separate DLL.

The current command line frontend only offers basic functionality. We'll 
develop a graphical application that allows to control the honeypot, change its 
configuration and view results.

What steps will reproduce the problem?
1. Install Windows 7 x64
2. Launch the "Setup.exe" in admin

What is the expected output? What do you see instead?
It is expected to work. It can't install the bus. It is not said anywhere that 
Windows x64 is not supported. I had to go look in source.

What version of the product are you using? On what operating system?
0.2 and 0.2.1 both output the same results.

Please provide any additional information below.
Good luck.

Add support for Windows 7 and, if possible without too much effort, also for 
64-bit systems.

The driver's write function must be called within the context of the writing 
process, because only then we're able to collect information about the writer. 
However, write is sometimes called from a system worker thread (PID 4).

We need to find out why this happens and how to avoid it. Alternatively, we 
might be able to find the writing process even in that situation.