-
Notifications
You must be signed in to change notification settings - Fork 590
Add Stack Plugin #1816
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
base: develop
Are you sure you want to change the base?
Add Stack Plugin #1816
Conversation
It might be worth making an issue for the dt() problem. Perhaps i broke something with #1748 |
maybe this plugin can be enhanced to list the actual callstack? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks reasonable, but from a code perspective makes me cry when people use volatility to scalpel their way to some data and then use a machete to hack it raw from the layer! 5:P
# Stack Base is at NT_TIB + 8 | ||
# https://github.com/wine-mirror/wine/blob/master/include/winternl.h#L494 | ||
# https://github.com/wine-mirror/wine/blob/master/include/winnt.h#L2445 | ||
stack_base = struct.unpack( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please try to avoid reading bytes directly. Either make a struct or at least instantiate a new object of the right type for windows on it. Having to 0 index the results of unpack basically throws away all the extra goodness we provide through the volatility model (keeping track of the type, the offset, which layer it came from, etc).
The entire volatility framework is a giant parser, so if you're resorting to struct.unpack yourself please consider if there's no other way of doing it (or if you're doing it so often efficiency comes into question, which ones per thread, isn't the case here).
|
||
if self.config["dump"]: | ||
fname = f"{proc.UniqueProcessId}.{thread.Cid.UniqueThread}.dmp" | ||
stack = proc_layer.read(offset=thread_rsp, length=stack_size) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a reasonable use of read, because it's a big chunk of unstructured (or unknown structure) data, that you just want to write out as a big blob and aren't going to use again inside volatility.
Hello @ikelos, thank you for all the pointers (and apologies for the tears). I will make the code more modular and also create the Would migrating (a part of) this over to
|
@SolitudePy, I think this is a nice addition, but I'm afraid I don't have the time to debug a process and find a way to follow the call stack, at least not right now. Maybe I will revisit it when my program is a bit lighter, but feel free to contribute if you want! |
A plugin that dumps the stack for each (running) thread.
It grabs the current
RSP
from the TrapFrame_ETHREAD->_KTHREAD->_KTRAP_FRAME.Rsp
, and the Stack base from_ETHREAD->_KTHREAD->_TEB.NT_TIB.StackBase
This could (and probably should) be part of another plugin like
memmap
, but I figured I would submit it for review and then change it.Edit: No issues with the
_NT_TIB
object, see referenced 'issue'