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

Feature : Hibernation Layer and plugins. #1036

Open
wants to merge 11 commits into
base: develop
Choose a base branch
from

Conversation

forensicxlab
Copy link

Hello,

  • Adding a new translation layer and plugins to allow modern Windows (Win8-Win11) hibernation file conversion to a raw memory image
  • Adding new codecs : LZ77, LZ77Huffman decompression algorithms.

Details about the feature : https://www.forensicxlab.com/posts/hibernation/

Best regards.

@forensicxlab forensicxlab changed the title Feature/hibernation Feature : Hibernation Layer and plugins. Nov 12, 2023
@ikelos
Copy link
Member

ikelos commented Nov 15, 2023

Thanks very much for your contribution! This is quite a big change, so may take us some time to review (I also need to pull in some of the other guys who wrote our previous hibernation code to check it). So please don't despair, but this may take us some time...

@forensicxlab
Copy link
Author

Hello @ikelos,

Finally found some time to make adjustments to the code.
Added a bunch of comments for better readability for the reviewer(s).

I still have doubts about some of my choices for the implementation 🧐
Any news on your side about this PR review ?

Kind regards,
Félix.

@ikelos
Copy link
Member

ikelos commented Feb 8, 2024

Thanks Félix, unfortunately the chap that knows the hibernation stuff best ( @awalters ) is a little busy at the moment, so we haven't made much progress with it, but we haven't forgotten about it either. Could you describe your worries about the implementations choices you're not sure about please and hopefully one of us will be able to check out your concerns?


# Temporary comment:
Copy link
Author

Choose a reason for hiding this comment

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

I wonder what's the best way to integrate algorithms into the "codecs" from the framework standpoint.
What are your recommandations about that ? Should I implement algorithms In seperate files ? I feel like I should but I have put both algorithms here for now :)

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I'd probably put them both in different files, but there needs to be a way to register them (either the main code seeks them out, or they add themselves to a shared singleton object when they're imported). I don't know if it'll be overkill, but it might be pretty cool to build them into the existing python codec framework?

https://docs.python.org/3/library/codecs.html

Copy link
Author

Choose a reason for hiding this comment

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

Thanks, I'll get right on that.

{}
) # This will hold the mapping between the PageNumber in the decompressed data vs the physical page number.

if "plugins.Dump.version" in context.config:
Copy link
Author

Choose a reason for hiding this comment

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

The fact that this translation layer is meant to be used with the hibernation.Dump plugin makes me feel bad about this part.
Indeed the FirstKernelRestorePage and KernelPagesProcessed offsets can only be determine via the user input for now.

Is making a translation layer partially dependant to a plugin is an acceptable concept in the volatility3 framework ?

This concept is working well with this implementation and seems to have no side effects from all the tests I've made but an external eye from your side will be delightful :D I propably missed something.

Copy link
Member

Choose a reason for hiding this comment

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

If this is the only requirement for the layer, then make it a requirement (like the kernel_virtual_offset for Intel layers), then anything can instantiate it as long as they provide the right version number for the layer (it might be better if the layer could figure it out for itself, but if not then ask the instantiator to provide it).

Copy link
Author

Choose a reason for hiding this comment

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

Did not find a way to figure the version out by itself in my research at time of writing, I'll look at what’s done in the Intel layer thanks for the tip!

Copy link
Member

@ikelos ikelos Feb 18, 2024

Choose a reason for hiding this comment

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

Probably add a PluginRequirement and that should do you. 5:)

),
]

def _generator(self):
Copy link
Author

Choose a reason for hiding this comment

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

The Idea here is to check if the HibernationLayer is indeed stacked before trying to make the conversion to the raw file using the layerwriter plugin. Feel like it's ugly though, did not find another cleaner way right now. I'll be happy to have your insights :D

Copy link
Member

Choose a reason for hiding this comment

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

I mean, that's ok and it does reuse the LayerWriter class rather than implementing itself. If this whole plugin doesn't do anything other than call layerwriter, why don't we just document that to write out a hibernation layer, you should use layerwriter? A specific plugin for a specific layer type doesn't make a lot of sense? We might be able to update layerwriter so you can easily ask it to write all layers of a particular type (so you could say write out all HibernationLayer layers or something)? Essentially, improve the UI of the existing plugin to avoid the need for the new plugin.

Copy link
Author

Choose a reason for hiding this comment

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

That's a very interesting idea.

I’ll leave both plugins in this PR so that the tests by the reviewer(s) can all be done on this branch. If the conclusion goes indeed in this way, I will implement your idea as soon as I can in a dedicated PR (if not proposed by somebody else in time :-) )

@forensicxlab
Copy link
Author

Thanks Félix, unfortunately the chap that knows the hibernation stuff best ( @awalters ) is a little busy at the moment, so we haven't made much progress with it, but we haven't forgotten about it either. Could you describe your worries about the implementations choices you're not sure about please and hopefully one of us will be able to check out your concerns?

Hi @ikelos,
I've added some comments about some of my worries and questions :D

Thank you for your quick responses every time.

Kind Regards.
Félix.

@KamilPacanek
Copy link

KamilPacanek commented Mar 11, 2024

FYI, just used that one on my local vol3 installation during the weekend and must say worked flawlessly. I could convert with no issues the hiberfil.sys to the raw image file that can be analyzed later with vol3 plugins.
Thank you @forensicxlab, you're my savior 💚

EDIT:
As a bonus, it helped me tremendously at first stage of solving HTB CTF challenge: https://blog.cyberethical.me/htb-cyber-apocalypse-forensics-oblique-final, I really wish the PR got completed soon :) !

@ikelos
Copy link
Member

ikelos commented Mar 12, 2024

Thanks for the feedback, much appreciated! This is still waiting on @awalters for review at the moment, but we'll get to it once things have calmed down for everyone... 5:)

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.

None yet

5 participants