Skip to content

Cache Update Issues #1255

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.

Sign up for GitHub

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

Jump to bottom
Open
SeattleForensics opened this issue Sep 9, 2024 · 4 comments · May be fixed by #1751
Open

Cache Update Issues #1255

SeattleForensics opened this issue Sep 9, 2024 · 4 comments · May be fixed by #1751
Assignees
@ikelos

Comments

@SeattleForensics
Copy link

Describe the bug
When having and using both the latest release version of Volatility 3 and the latest development version of Volatility 3 on the same system, the "updating caches" function has to re-update frequently.

Context
Volatility Version: Volatility 3, v 2.7.0 & the latest development version
Operating System: Windows 10
Python Version: 3.11
Suspected Operating System: (not sure what this means... of the memory sample? If so, Windows 10 and Windows 8)
Command: C:\Python311\python.exe "C:\Tools\Volatility\3.X\vol.py" -f "C:\Temp\memimage.mem" windows.cachedump.Cachedump

To Reproduce
Steps to reproduce the behavior:

  1. Download and unzip the latest release version of Volatiltiy 3 (2.7.0, at the time of this writing) to C:\Tools\Volatility\3.x
  2. Download and unzip the latest dev version of Volatility 3 to C:\Tools\Volatility\3.x-DEV
  3. Download all symbol table packs and place the appropriate directories
    3a. C:\Tools\Volatility\3.X\volatility3\symbols
    3b. C:\Tools\Volatility\3.X-DEV\volatility3\volatility3\symbols
  4. Run the windows.cachedump.Cachedump plugin with the command above using the release version, then the developement version, then the release version again.
  5. You will see that 3.X release updates the caches, then 3.x-DEV updates its caches, then 3.X release has to update its caches again, if you alternate running the same command back and forth between release and development versions in the folder structure I've described.

Expected behavior
I expect that each version (3.X release and 3.X DEV) will only need to update it's caches once.

Example output
Please copy and paste the text demonstrating the issue, ideally with verbose output turned on (vol.py -vvv ...).
-The output in the CMD window doesn't keep the cache updating output text in the window when the command has completed running.

Text is preferred to screenshots for searching and to talk about specific parts of the output.

Additional information
Add any other information about the problem here.
@ikelos
Copy link
Member

ikelos commented Sep 9, 2024

Each time you run volatility, it will update a single shared cache on the computer, but each time it will be using a different symbols directory, so each time it will find "new" files and remove old entries that aren't present anymore (so clear out the competing version's files). We could probably change the cache code not to delete entries where the file still exists, I'd need to look into how difficult that would be to do. Otherwise, you can specify the same symbol directory for both, and then you'll only need one set of symbols and they'll both use it. You can also wire that into a config file (vol.json under %appdata% on windows or ~/.config/volatility3 on linux) that gets picked up on every run, but again, it'll be a single config that provides the same options to both...

I'll leave this open while I work up a potential patch. I need to figure out whether anyone might rely on the old behaviour...

@ikelos ikelos self-assigned this Sep 9, 2024
@ikelos
Copy link
Member

ikelos commented Sep 9, 2024 •
edited
Loading

I haven't tested it yet, so I don't know whether os.path.exists will accept URIs, but the branch I'm working on is issues/issue1255 if you want to give it a try. I'll check it once I'm back from work.

@github-actions GitHub Actions
Copy link

This issue is stale because it has been open for 200 days with no activity.

@github-actions github-actions bot added the stale label Mar 29, 2025
@ikelos
Copy link
Member

ikelos commented Mar 29, 2025

No one ever tested the fix which is how this went stale, but I'm concerned that we need to take the user's request for which directory should be examined into account. That means we should really be prioritizing paths that are in the user's symbol directory list over ones that aren't (if we leave the old ones in place). So this will require a bit more work (but since the original poster went quiet and no one else chipped in, I'm guessing this isn't a significant issue)...

@ikelos ikelos linked a pull request Mar 29, 2025 that will close this issue
Open
@ikelos ikelos removed the stale label Mar 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ikelos ikelos

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Don't delete files that are still accessible from the cache volatilityfoundation/volatility3
2 participants
@ikelos @SeattleForensics