This project is a Windows Driver written in Rust.
Sanctum EDR is an Endpoint Detection and Response proof-of-concept product I am building, that I will use to try combat modern malware techniques that I develop.
I have started a blog series on Sanctum, you can check it out on my blog here. I'm keeping track of the progress and milestones of the project there, so please check that out!
Currently in its early stages, I have a plan for the project which I will update in due course. If you like this project, or my work, please feel free to reach out!
This is a high level overview for how I would like to structure this project.
A high level view of my API design for the internal application (not counting any web API's) looks as below. I have opted to try keep the interface UmEngine a singleton. The design is somewhat problematic in that if the UmEngine were to be mutable, a mutex would be required to mutate any internal state. The difficulty with this is that this could significantly block the main thread depending on what the mutation / action is. So I am opting at the moment for a non-publicly mutable singleton which maintains it's own state internally, allowing actions to be carried across either OS threads or green threads. The API overview (this may not be up-to-date in terms of exported functions etc):
I started writing this driver in C, but having stepped away from C for some time, i missed a lot of Rust's features.
Rust is suited to operate in embedded and kernel environments through libcore no_std, and with Microsoft's support for developing drivers in Rust, Rust comes up as an excellent candidate for a "safer" approach to driver development. I use "safer" in quotes because, despite Rust's safety guarantees, we still need to interact with unsafe APIs within the OS.
The EDR code is logically separated in one solution into the kernel mode driver (the driver folder found here), the usermode engine (found here), and usermode DLL (todo).
The usermode aspect of this application includes a GUI for you to use as a native windows program.
Scanning a file:
Scanning a folder:
The driver can be communicated with both via IOCTLs and named pipes, here is an example of data being sent from the driver back up to user land:
Driver checks compatibility with the client version and will panic (usermode) and unload the driver if the versions are not compatible.
- Cargo (obviously..)
- Nightly
- cargo make
- Windows Driver Kit & Developer Console (as admin for building the driver)
- May wish to add a symlnk for .vscode/settings.json in the driver to that in the root for spelling etc.
- To see driver install config, regedit: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sanctum.
- The app will create a location in %AppData% where the IOC file and settings are created. You will also need to drop the built driver into this location. A built driver is not shipped with this repo, so it must be built after cloned with cargo make from the driver directory.