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

Current binaries with logical file options? #31

Open
Jon-Rowe opened this issue Jun 8, 2021 · 11 comments
Open

Current binaries with logical file options? #31

Jon-Rowe opened this issue Jun 8, 2021 · 11 comments

Comments

@Jon-Rowe
Copy link

Jon-Rowe commented Jun 8, 2021

We're interested in running a standalone aff4imager with logical file copy options to test it out. Is there a current .exe build we can download? I noticed the latest WinPmem doesn't include the feature.

Thanks!

@scudette
Copy link
Contributor

scudette commented Jun 8, 2021

We currently do all logical images using velociraptor in offline collector mode. This can also collect memory and it's far better than the old aff4imager.

Here is a video that explains how that works https://youtu.be/DX1CcoNl_q8

@Jon-Rowe
Copy link
Author

Jon-Rowe commented Jun 8, 2021 via email

@Jon-Rowe
Copy link
Author

Jon-Rowe commented Jun 9, 2021 via email

@scudette
Copy link
Contributor

scudette commented Jun 9, 2021

Aff4 is not currently supported by velociraptor. We support writing to a regular zip container instead and the metadata is written as Json files.

I did consider previously adding aff4 support but it's not clear that aff4 will provide a large advantage for this use case. It's potentially better for large single images because it allows them to be spilt into chucks that can be compressed in parallel, but for a large number of smaller files that advantage disappears and compatibility with regular zip files is more important.

The metadata scheme in aff4 is not that useful for the general case of collecting arbitrary artifacts, so we will always write Json files anyway, and converting back and forth from rdf just burns CPU cycles and memory, so even if we did write aff4 probably we will skip a lot of the rdf stuff.

Interested to hear your view on this though?

@Jon-Rowe
Copy link
Author

Jon-Rowe commented Jun 9, 2021 via email

@scudette
Copy link
Contributor

scudette commented Jun 9, 2021

Just to clarify, aff4 is just a zip file with some metadata.

I believe there are some libraries that support it in the aff4 GitHub org https://github.com/aff4 and there are some commercial tools that image to aff4.

@Jon-Rowe
Copy link
Author

Jon-Rowe commented Jun 9, 2021 via email

@scudette
Copy link
Contributor

scudette commented Jun 9, 2021

AFF4 standard is here https://github.com/aff4/Standard it does not define any encryption or signing. The standard does define hashing and also a block based hashing scheme which can be parallelized for speed. The underlying storage format is a zip file therefore standard zip tools can read/write it.

Therefore it is fairly easy to alter the file directly - which is why users need to record hashes as part of the chain of custody as is always the case.

This BTW this is not different from many of the other formats (EWF, dd) etc. AFF4 is just a way to store multiple streams in the same zip file with metadata geared towards forensic imaging use case.

@Jon-Rowe
Copy link
Author

Jon-Rowe commented Jun 9, 2021 via email

@scudette
Copy link
Contributor

scudette commented Jun 9, 2021

The code is kept in different projects in the aff4 github org

@Jon-Rowe
Copy link
Author

Jon-Rowe commented Jun 9, 2021 via email

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

No branches or pull requests

2 participants