Skip to content

Windows: update psscan to fix issue #591 #1788

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

Draft
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

eve-mem
Copy link
Contributor

@eve-mem eve-mem commented Apr 25, 2025

Hello 👋

This is a continuation of PR #1215 but I completely messed up that branch with a rebase that went very wrong, and my git-fu isn't strong enough to fix it.

This fixes an issue where if you attempt to use the --physical option on some windows samples psscan will crash. This PR fixes those issues and includes the changes suggested by @ikelos in the previous PR.

🦊

@eve-mem
Copy link
Contributor Author

eve-mem commented Apr 25, 2025

I'll get that test fixed!

Copy link
Member

@ikelos ikelos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I'm a little concerned that the support for scanning physical layers won't ever actually get used, because we only ever ask the poolscanner to scan the kernel image?


if self.config["dump"]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we'd guard for if vproc is None:. If we hand it in, it will debug log but otherwise return None, so it's not catastrophic, but feels like an easy thing we can check (and catchall exception handlers aren't ideal, so that may go away at some point in the future)...


# windows 10 objects (maybe others in the future) are already in virtual memory
# if the proc native_layer_name and layer_name match then it is in 'virtual' memory.
if proc.vol.layer_name == proc.vol.native_layer_name:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a robust test (it only works when scan_processes returns carved processes), and I don't really want people using it to determine whether an address is physical or not. The poolscanner's been asked to scan the kernel layer, so... it should only ever return virtual results? Have you verified that the "else" branch ever gets hit?

@eve-mem eve-mem marked this pull request as draft April 28, 2025 06:30
@eve-mem
Copy link
Contributor Author

eve-mem commented Apr 28, 2025

@ikelos that's a really good point. I've just been focused on getting rid of the back trace for @garanews rather than looking at the plugin as a whole.

The windows psscan is very different to the linux one. Linux will always scan the 'memory layer' and produce results from that, e.g. always physical addresses and it doesn't scan an intel layer.

What are peoples thoughts on changing the windows one to be closer to the linux counterpart? It's a bigger change to how psscan works but to my knowledge there aren't any public plugins that rely on psscan. It would make the logic a lot simpler.

@ikelos
Copy link
Member

ikelos commented Apr 28, 2025

I think as long as we don't lose functionality (ie, it can still give you virtual addresses, if that's what you expect) then it should be fine?

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

Successfully merging this pull request may close these issues.

2 participants