Volshell: Display types pointer upgrade #1748
Conversation
- Introduced `_get_type_name_with_pointer` to properly display pointer types. - Enhanced `display_type` to follow and display pointer chains up to `MAX_DEREFERENCE_COUNT` levels. - Added `_display_simple_type` to standardize type information display. - Improved `_display_value` to highlight null and unreadable pointers.
…er fuctions Previously, `getattr(volobject, member)` in `display_type()` would incorrectly retrieve method references (e.g., `.write`) instead of the intended object addresses, causing an `AttributeError` when `_display_value()` attempted to access `.vol.offset`. This commit replaces `getattr(volobject, member)` with `volobject.member(member)`, ensuring that the correct object address is retrieved instead of method references. Fixes: volatilityfoundation#1705
Replaced `member_type.vol.object_class == objects.Pointer` with `isinstance(member_type, objects.Pointer)` to identify pointer types consistently. Thanks to @ikelos for the suggestion!
…ter marker being calculated correctly
ikelos
left a comment
ikelos
left a comment
There was a problem hiding this comment.
Looking good! I think the last _display_value function is a little brittle in places, but once that's hardended up a bit, this should be good to go in! 5:D
ikelos
left a comment
ikelos
left a comment
There was a problem hiding this comment.
Thanks, feels better to have made the distinction on type early on... 5:)
…es breaking the output
Tidy up case where type_name is very long by @ikelos Co-authored-by: ikelos <[email protected]>
volatility3/cli/volshell/generic.py
Outdated
| if self.context.layers[self.current_layer].is_valid( | ||
| value.vol.offset | ||
| ): | ||
| return f"offset: {hex(value.vol.offset)}" |
There was a problem hiding this comment.
Think this can be 0x{value.vol.offset:x} rather than {hex(value.vol.offset)}. Absolutely a stylistic choice though... 5;)
There was a problem hiding this comment.
I don't mind either way - would you rather 0x{value.vol.offset:x}? (can add it to the style guide PR?)
There was a problem hiding this comment.
Yeah, I think so? Using built in format modifiers seems better than a separate function call to convert it? Sure, I'll get it added to the coding style...
There was a problem hiding this comment.
Makes sense - done! 😄
3 participants
Hello 👋
This PR updates volshell display types to follow pointers and display more information, and IMHO makes it easier to use.
This is a replacement for PR #1028 as my git-fu is not strong enough to survive a rebase.
Fixes #1714
Fixes #1705
dt() updates
dt()will now follow pointers as needed to display information, up to a maximum ofMAX_DEREFERENCE_COUNTtimes (currently set to 4).With the a dt() of a
task_structyou get a small hint at the changes. Here we see thatstackandfilesare actually pointers as denoted by the*- we can also see what kind of struct it is, e.g.filesis afiles_struct. Previously it would have only displayedpointerso you wouldn't know what it was. The value displayed is still the actual pointer data as before. It will show pointers in hex e.g.0x880001f60000rather than149533614276608as this feels more natural.The
@ 0x88001d06c800also shows where in the layer this object is. Previously you'd need to use.vol.offsetor similar to find this out as an extra step.However things get useful when we would need to follow pointers, e.g. the
filesmember oftask_structHere we can see that
.filesis a pointer. It was located at offset0x88001d06cc80and points to0x88001cbd59c0. At0x88001cbd59c0we have thefiles_structand dt will display the details of it. The results forfiles_structis indented to show that it is the result of following a pointer. Previously if you diddt(task.files)you would simply be told it was a pointer, you'd need to typedt(task.files.dereference())to get the results. I personally struggle to spell dereference correctly most of the time and these changes make my life a little easier!The changes will follow multiple pointers if needed too. If we look at the
fdthere we can see that thefdmember is a double pointer which eventually gets to afileas denoted by the**.Lastly we can see
fdjust as easily by usingdt(task.files.fdt.fd). Here we see the first pointer located at0x88001cbd59d8points to0x88001cbd5a58. The second pointer at0x88001cbd5a58then points to0x88001d145580. Finally at0x88001d145580we have thefileitself. You still get all the information about the pointers themselves if that is what you're interested in but you quickly get to the struct information which is what I think is the more common use case.Fixing #1705
Before the changes, you cannot
dt()afile_operationsstruct as it includeswritewhich is a python function for the vol object.With the change to use
.member()as suggested by @atcuno (#1714 (comment)) it now works as expected:Fixing #1714
Previously if you used dt() on a struct where a member was paged out it would backtrace and show no future results. As per @atcuno suggestion it will now just display
N/Aand continue. Here is a short example with a nonsensical dt at 0x0.Let me know what you think! Huge thanks to @atcuno and @ikelos for the encouragement. 🙏