Frictionless
- 2 Devlogs
- 20 Total hours
Process tracing timeline in use of ETW
Process tracing timeline in use of ETW
Devlog #2 of my Task Manager-History tool using Rust or whatever I should call it
Code progress
I have successfully managed to start both a classic ETW session and a modern one and receive events from them.
The difference in how the two work is that the latter uses EnableTraceEx2() (or earlier in its’ lifetime named something similar) to enable all kinds of providers while the former uses flags for the session start to enable only kernel-providers.
I’ve also cleaned all of the comments from my code and pasted all of the commented versions into a .md file.
Logging
I’ve also logged about my understanding of the two different session versions, how they work and what the contrast between them tell me about the ETW architecture.
Also written about wrappers in windows code, type casting, the difference between references and pointers in Rust, written a summary of how ETW works etc.
Logging is definitely helping me remember what I’ve learned about Rust and the windows API as well as keeping both my progress and where I am going clear.
Next?
Next up is probably going to be the UI of my program as a desktop application, I have a vision of how I want it to look and I think starting to design it now is going to help me get to know what kind of data I am looking to receive from the events.
Other
I think I’m gonna keep these a little shorter just saying what I’ve done instead of explaining how everything works.
Also if my logging shouldn’t count as hackatime time please let me know asap
(Friendly note: if your devlog is more than 4000 characters when posting, it will disappear)
You know Task Manager? You know how it only shows you the processes that are running in the instant that you’re looking at it? My main idea since the start has been to make an app like it but that also shows the “process history” since boot.
The point of the project is to allow the user more insight into what’s happening on their device, whether it’s to detect malware that sort of runs for a little while and then turns off, to see what unnecessary programs launch upon startup or just to get a better hint of what’s going on in the device.
Figuring this out was what the first part of my project was about and I came to a surprisingly clean conclusion.
ETW (Event Tracing for Windows) is an event-tracing framework built into windows whose entire role consists of tracing events (yup)
I’m not too familiar with it yet but I know that it works like this in a nutshell:
You start an ETW session by passing a struct which basically contains the settings for the session into a function called StartTraceW().
You enable what providers you want the session to listen to with EnableTraceEx2(), where the “providers” respectively emit notifications for different events.
To receive the notifications, you use function OpenTraceW() which you also pass a struct which contains information mostly about the session you’re connecting to but also a pointer to one of your own functions (which needs a specific parameter). So basically:
*my_function(trace_data) + other session info ->
session_info_for_OpenTraceW ->
OpenTraceW(session_info_for_OpenTraceW)
And the reason you pass one of your own functions is so that ETW can call it to give you said trace data.
The final stage is deciphering the above-mentioned trace_data argument that your registered function receives in order to perchance turn it into UI.
And all of these functions exist inside of windows so you need a Linker so that your code can “link against” them aka. you write the definitions of the code you want to access in your code and the linker will make it so that calling your code accesses the real logic.
And because there was a lot of code that I’d have to declare I used a Crate, which is basically like a built-in mechanic for code-dependencies in Rust and they work pretty much like header files in C/C++, except that they are managed through another file which is called Cargo.toml which installs the crates specified from the web where they are managed and upkept.
And I haven’t mentioned that all of the windows logic including ETW is written primarily in C which might make it seem impossible for my code that interacts with it to be written in Rust but there’s something called FFI (Foreign Function Interface) which covers this completely.
Although my coding time has consisted of mostly logging thus far as I am learning both a new programming language and how to use ETW, at the moment I’ve made four scripts which are main.rs, ffi0.rs, ffi1.rs, misc.rs which basically covers stage 1 and 3 of the ETW explanation that I gave above.
The immediate next step is probably going to be to make my code do what it’s supposed to and start a session, after that it’s stage 2 and then a little into stage 4.
That’s a few things necessary before configuring the UI and such.
Something else I want to manage before that is schedule an ETW session for next boot that writes its’ data into a file which my program will then read.