-
Notifications
You must be signed in to change notification settings - Fork 223
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
Processing of supported forensic/virtual disk images recursively #102
Comments
Removed non portuguese text. I also took a look at libvhdi and libvmdk projects, and seems they support snapshots, that is great. |
I started to work on this. At first I will add a basic solution without snapshot support. Maybe the disk without the snapshot could contain more relevant data, maybe not... And if there are many snapshots, decoding all of them could be very expensive and an overkill... |
Embedded images could also be splited, at least for dd & e01, I don't know about vmdk and vhd, not sure if I will target this for now. |
- current approach add all items from all embedded disks to the same sleuthkit DB, this should be single threaded. A future improvement could create separate DBs for each virtual disk, so image decoding could be done in parallel for different disks
Just to document here, splitted/segmented images aren't supported for now and this was left as a future improvement. |
I'm reopening this to implement splited image support, shouldn't be hard. The only disadvantage is that all embedded disks should be sent to second processing queue to allow finding image parts. |
Conflicts: iped-engine/src/main/java/dpf/sp/gpinf/indexer/datasource/SleuthkitReader.java
Reopening to change the logging level to warn instead of error (this goes to console) when processing embedded disks. |
Closed by commit f5765a8 |
This is processing ufdr files recursively too? If I process the folder where the ufdr is it will be expanded? |
Unfortunately not at the moment, the primary goal was to support common image formats that could be found in suspect's machines (plus others processed in the same way). AD1 is another format that maybe might be supported. |
PS: actually the UFDR will be processed like generic zip files not like UFDR evidences |
When a forensic image (eg E01) contains virtual disks (eg VHD) among its files, it would be useful if IPED had the functionality to automatically export these virtual disks, process them and include them in the case as new evidences.
The text was updated successfully, but these errors were encountered: