mandiant / strace Goto Github PK

it seems that after using some kernel32.lib apis :
the tool returns :

12:10:06.446  INF #3  14976  Log has been initialized.
12:10:06.446  INF #3  14976  Starting DLL load
12:10:06.446  ERR #3  14976  [!] DLL Imports GetPrivateProfileStringA from KERNEL32.dll. Imports are not supported...fatal
12:10:06.446  ERR #3  14976  [!] DLL Imports GetFullPathNameA from KERNEL32.dll. Imports are not supported...fatal
12:10:06.446  ERR #3  14976  [!] DLL Load Failed
12:10:06.446  ERR #3  14976  [!] Plugin Loading Failed

or is it limited to the KernelLand apis only ?

The PID and FBT probe types can't be supported until the signing requirements of the dtrace system/kernel extensions is changed by microsoft - as they use the windows hypervisor which doesn't boot when SB and DSE are set to off. The ETW probe type however doesn't rely on the hypervisor and should be implementable. If someone wants to perform that research, lets chat here.

i keep having this error on the CLI .

[+] Opening driver
[+] Driver Opened Successfully
Input command: load, unload, exit
LOAD
Input command: load, unload, exit
LOAD
Input command: load, unload, exit
load
[+] Asking for plugin
Input command: load, unload, exit
load

Instead of blowing up the driver plugin architecture issue more, I figured I would create a separate issue. A lot of the plugins have a cut and paste of the same header files. I say we create a single shared include folder. There needs to be some thought into which projects will share what considering we have three subsystems here: STrace driver, plugins, CLI. This is a lot easier now that plugins live in drivers and we don't need a complex interface anymore.

If anyone wants to create a plugin there are a lot of little settings in the project that would lend better to a template. Also a lot of skeleton code. Instead of asking people to copy another plugin and make it work we can have a nice template for a new plugin.

Allow plugins to have configs. When logging syscalls we hardcode our target binary. We could support more than one binary, change binary on the fly, even have a follow children option.

Have a default config for a plugin then a way to read and write the plugin from the CLI.

Converting to a Driver Plugin brings a simpler architecture:

1. Drivers are loaded and unloaded using ZwLoadDriver and ZwUnloadDriver
2. No manual mapping required which makes symbolic debugging easier
3. Still use export functions, this requires custom GetProcAddress
4. Simpler interfaces from kernel to plugin
5. No more programming as a user dll, but run in kernel.

Architecture Decisions

1. Keep exports, other ideas that were investigate: Driver Callbacks, Calling Drivers
2. Minimize Plugin API functions
3. ZwLoadDriver and ZwUnloadDriver require a Registry path. Since STrace is a single plugin architecture the plugin will always be Registry\Machine\System\CurrentControlSet\Services\StracePlugin, with a binary path of \\systemroot\\system32\drivers\StracePlugin.sys. It will be the responsibility of the CLI to rename the plugin chosen as done prior and copy it to StracePlugin.sys. When debugging the symbols will remain the original binary to help distinguish. Possibly add an IOCTL that returns the plugin name.

Hi,

I compiled the entire project on VS Community 2022 without any errors. I ran the install script as admin, and it was completed successfully. But after rebooting with DSE disabled, the STrace service did not start.

As described in readme, I tried to start it manually but I'm having the following error.

I'm using a Windows 10 VM (Flare VM) on VirtualBox with nested virtualization enabled. Is there anyone else having this issue?

There's an issue with the DDK setup in the windows image being used. I am unsure how to resolve.

Hi, I made pdb-addr2line and saw the following comment in your code:

https://github.com/mandiant/STrace/blame/27e57cd6f990b824063a1c27a7612e3226af5340/Rust/PDBReSym/src/main.rs#L307

// if a line has no end rva, the start of the next block defines it's end. Lots of symbols are like this.

How up-to-date is that comment? Do you still get lots of symbols with a missing end_rva? I tried to mostly fix this issue in pdb-addr2line 0.7.2, with these commits:
mstange/pdb-addr2line@8787f38
mstange/pdb-addr2line@0bdb486

So I'd expect basically all symbols to have an end_rva now. If this is true, it might simplify your code.