Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process destructive actions don't work #51

Open
samrussell opened this issue Nov 2, 2023 · 7 comments
Open

Process destructive actions don't work #51

samrussell opened this issue Nov 2, 2023 · 7 comments

Comments

@samrussell
Copy link

I can do kernel destructive actions (discovered the hard way that breakpoint() works) but user destructive actions don't work.

This is on the latest win11 running in admin mode, sample script looks like this:

./dtrace -wn 'syscall::NtOpenFile:return /pid==1428/ { stop(); raise(1); printf(\"NtOpenFile hit\"); }'

Am I using this wrong? Nothing happens here, but if I do this it works:

./dtrace -wn 'syscall::NtOpenFile:return /pid==1428/ { breakpoint(); }'
@mhndr
Copy link

mhndr commented Nov 3, 2023

Hi, have you tried using the following option in your script?
"#pragma D option destructive "

@samrussell
Copy link
Author

I can give that a try, that's the same as the -w flag though right? I get an error from the usermode dtrace utility when I don't pass this.

Also the breakpoint() action does work, which means I've definitely enabled kernel destructive actions, I just have no luck with proc destructive actions

@samrussell
Copy link
Author

So in the docs setting destructive with pragma or -x is equivalent to using the -w flag: https://docs.oracle.com/cd/E18752_01/html/817-6223/chp-opt-1.html

@samrussell
Copy link
Author

Looking at dtrace.sys in a disassembler and comparing it against the code, it looks like the dtrace_action_stop() and dtrace_action_raise(val) calls in dtrace_probe() have just been commented out, as both appear to hit the inlined dtrace_priv_proc_destructive() function and then hit the continue in the loop.

What's the state of support for these actions? Are these not supposed to be supported in windows dtrace or is this a bug?

@samrussell
Copy link
Author

Also worth noting I've run this with a kernel debugger, at dtrace!dtrace_state_create+0x1dc it's preserving all the destructive privileges (TraceFilterAccess() is setting KernelAccess and UserAccess to true and the state->dts_cred.dcr_action bitmask is 0x7f == DTRACE_CRA_ALL), and the inlined dtrace_priv_proc_destructive() check at dtrace!dtrace_probe+0xccb is returning true.

i.e. on my machine I can confirm inside the driver the correct flags are being set, just there's no code to execute that would suspend or signal the process

@samrussell
Copy link
Author

Okay I think I've answered my own question:

static void
dtrace_action_raise(uint64_t sig)
{
	if (dtrace_destructive_disallow)
		return;

#ifndef _WIN32
/* ... */
#endif
}
static void
dtrace_action_stop(void)
{
	if (dtrace_destructive_disallow)
		return;

#ifndef _WIN32
/* ... */
#endif
}

So it looks like these were just ported from https://github.com/opendtrace/opendtrace as-is.

At a minimum can we at least update the docs to show that these aren't implemented yet?

@samrussell
Copy link
Author

My goal here isn't necessarily to get signal (doesn't exist on windows?) or process suspend support, but actually to find a way to use dtrace to allow debuggers to breakpoint on syscalls. If there's a way to do this either via the DLL or via direct IOCTL to the driver then that would be useful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants