Windows: Allow windows.dlllist to report back DLLs from wow64 processes#1572
Conversation
hsarkey
force-pushed
the
hsarkey/wow64-dlllist
branch
from
f332a9e to
be26247
Compare
… back DLLs from wow64 processes.
hsarkey
force-pushed
the
hsarkey/wow64-dlllist
branch
from
be26247 to
af9bd53
Compare
ikelos
left a comment
ikelos
left a comment
There was a problem hiding this comment.
Thanks, this is really nice! I like the way you've handled dealing with both type of pebs irrespective of which what it actually is and you've handled all the corner cases I can think of, good work! Also, awesome comments, just what was needed when it was needed! 5:D
Just a couple of little points, I think it's probably better to check if the pointer's right, than check if it's specifically an unsigned long and then cast it. Really good though, thanks!
| """Constructs a PEB32 object""" | ||
| if constants.BANG not in self.vol.type_name: | ||
| raise ValueError( | ||
| f"Invalid symbol table name syntax (no {constants.BANG} found)" |
There was a problem hiding this comment.
I can't recall if this is strictly true. I suspect it's true but I think it's possible you could ask the symbol table directly for this type, and it wouldn't necessarily include the table name. Were you running into errors or is this just defensive coding?
ikelos
added
the
awaiting-author-response
|
Ok, looks good now, thanks. Still not sure the constants.BANG check is necessary, but it shouldn't hurt to leave it in... 5:) |
|
Thanks for the feedback and review! For what it's worth, I did run into errors without the constants.BANG check, so felt it was best to keep it in. |
That's fair enough. We probably want to iron those out at some point, but good to know it was necessary at least. Thanks for reporting back! 5:) |
3 participants
Updates to allow windows.dlllist to report back DLLs from wow64 processes. Created a new get_peb32() function and created a new symbol table (framework/symbols/windows/wow64.json).