dfvfs icon indicating copy to clipboard operation
dfvfs copied to clipboard

Add support for EWF-L01 files

Open dc3-plaso opened this issue 10 years ago • 3 comments

  • [ ] Release new libewf and pyewf
  • [ ] Add L01 and Lx01 support

The current implementation uses pyewf to open E01 files and then uses pytsk3 to manage the file system. However, this doesn't work for L01s even though pyewf supports them because pytsk3 does not.

I suggest either adding support for L01s in pytsk3 or developing EWF file entry and file system objects to manage these directly. The pyewf library has all the necessary function calls to handle this.

dc3-plaso avatar Sep 03 '15 21:09 dc3-plaso

FYI this is also on the roadmap: https://github.com/log2timeline/dfvfs/wiki/Roadmap, so this is definitely a feature we want to put in. However currently the main priority is improving NTFS support seeing there are more interesting artifacts to be obtained and L01 can be also be read after mouting with "ewfmount -f files".

I suggest either adding support for L01s in pytsk3 or developing EWF file entry and file system objects to manage these directly.

This would add yet another abstraction layer and seeing the state of TSK abstraction I rater not. Also L01 is more like an archive file than a disk image.

joachimmetz avatar Sep 04 '15 05:09 joachimmetz

This would add yet another abstraction layer and seeing the state of TSK abstraction I rater not. Also L01 is more like an archive file than a disk image.

This is why I suggested developing an EWF file entry and file system separate from using TSK. It would remove a layer of abstraction. The pyewf library contains enough methods to traverse through the internal directories to implement our own dfvfs file system type that does not rely on TSK.

L01 can be also be read after mouting with "ewfmount -f files".

Thank you for pointing me to this tool. This solution will work until there is official support.

dc3-plaso avatar Sep 11 '15 19:09 dc3-plaso

This is why I suggested developing an EWF file entry and file system separate from using TSK. It would remove a layer of abstraction. The pyewf library contains enough methods to traverse through the internal directories to implement our own dfvfs file system type that does not rely on TSK.

Agree, I'll try to bump the priority on this but libewf needs some love as well but currently other features have a higher priority e.g. improving NTFS support which has uncovered some limitations in pytsk/TSK that need to solved or worked-around.

joachimmetz avatar Sep 12 '15 07:09 joachimmetz