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

Fix scan_pattern_page read bytes out of range. #112

Merged
merged 1 commit into from
Jun 25, 2024

Conversation

SakuraHentai
Copy link
Contributor

fix #111

@jmctune
Copy link
Contributor

jmctune commented Oct 19, 2023

With this patched in, I'm unfortunately still receiving WinApi 299 errors from read_bytes.

@SakuraHentai
Copy link
Contributor Author

With this patched in, I'm unfortunately still receiving WinApi 299 errors from read_bytes.

Is your system is x64, and the target process is x86?

@jmctune
Copy link
Contributor

jmctune commented Oct 19, 2023

Is your system is x64, and the target process is x86?

Yes, that is correct. I'm using a 32-bit version of Python 3.11 as well.

@SakuraHentai
Copy link
Contributor Author

Is your system is x64, and the target process is x86?

Yes, that is correct. I'm using a 32-bit version of Python 3.11 as well.

I just read your library code, it is scanning memory directly with pattern_scan_all, there starts with 0 that should be no offset problem, it is probably caused by other places.

But I've tried the 32-bit process on my computer and it doesn't reproduce it, sorry can't help you.

@jmctune
Copy link
Contributor

jmctune commented Oct 19, 2023

Yep, it's nothing fancy. Just a class that's wrapping pattern_scan_all.

I have a few functions that will run a scan indefinitely. It could work for minutes or hours, but it will eventually throw a 299. No changes to the pattern, but the exception is in my linked mention above.

It's not pattern_scan_all itself, but scan_pattern_page, which is called from above. As it's iterating over the pages, there's one page that trips it up while it's executing read_bytes over the pages.

@SakuraHentai
Copy link
Contributor Author

SakuraHentai commented Oct 19, 2023

Yep, it's nothing fancy. Just a class that's wrapping pattern_scan_all.

I have a few functions that will run a scan indefinitely. It could work for minutes or hours, but it will eventually throw a 299. No changes to the pattern, but the exception is in my linked mention above.

It's not pattern_scan_all itself, but scan_pattern_page, which is called from above. As it's iterating over the pages, there's one page that trips it up while it's executing read_bytes over the pages.

Oh, I thought it reported an error on first run.

You can ignore this error, as the program may be freeing memory or switching page properties.

jmctune added a commit to dqx-translation-project/dqxclarity that referenced this pull request Oct 19, 2023
`pymem` is sometimes throwing this error when you're just standing
still. There's a [proposed
fix](srounet/Pymem#112) upstream that might
resolve these. It looks like this issue started (at least for clarity)
when I forked over some changes that were made to how bytes were read.
@srounet
Copy link
Owner

srounet commented Nov 28, 2023

@StarrFox what's your thoughts on this ?

@StarrFox
Copy link
Collaborator

@StarrFox what's your thoughts on this ?

seems fine to me

@StarrFox StarrFox merged commit fa895c9 into srounet:master Jun 25, 2024
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.

pymem.pattern.scan_pattern_page throw windows api error, code 299
4 participants