Closed pjrinaldi closed 3 years ago
Currently working on switching from ewfmount/fusermount to mount/unmount an e01 image to now simply making an ewfimage subclass of QIODevice, which allows me to read and write from the raw image inside the e01. need to look at modifying the functions and see what happens... look into reimplementing ewfimage::read() which calls ewfimage::readData and then returns a qbytearray..., then it would make stuff simpler for the code calls...
if i can get it to all work with ewf, then i need to implement for aff, and zmg.l
progress with implementing e01 support, continuing to implement and will know how it goes when i get through it, but it seems like it will work.
memory issues have been resolved so far. I am more efficiently calling what i need on demand from the forensic image, rather than whole swatchs of bytes from the image. It makes it harder to get the correct offset when navigating, but is more efficient when the code actually runs and currently is using minimal extra memory from the program running by default. Still a long way to go to switch all the code to the more efficient process. Only handle 1 case for GPT and NTFS info for the partition.
working on mbr partition tables, then extended partition tables, and then the other gpt. also need to fix size in bytes by converting uint32_t sector values returned to qulonglong or qint64.
Then i need to move the allocated and unallocated partitions to a function cause i am repeating them all over the place...
also need to reduce the stat files... based on new case opening, i don't need the id in the stat file, that can be built from the dir/file naming convention. also for evidence segments, i should store the image path, i.e. /projects/testimages/, the image prefix name, i.e. ntfs1, and the suffix segment(s), i.e. 000|001|002, etc.. this is more compact, and i can build the filenames from this easily. the partition, i only really need the offset & size, (maybe type) name isn't called from the file under new case opening implementation, etc...
this ticket is in tandem with the code efficiency ticket. For this ticket I need to improve the stat code as described in the previous comment and also ensure I implement aff, multi-raw, zmg, squashfs, and other images by using their read rather than fuse.
It is implemented for e01 and RAW (dd). once i get the other forensic image formats supported and all the previous file system parsers re-implemented, then i can test and if still no memory usage across all the forensic image formats and file system parsers, then i can reactivate the hexviewer and implement it wtih the new paradigm, and also fix digging, exporting, reporting, opening a case, etc...
aff is implemented, but goes painstakingly slow. i won't worry about that now since almost no one uses aff (AFF3) anymore. working on implementing split raw.
smraw has an error and i can't figure out what it is. it seems like it doesn't detect the segment suffix correctly. will try to implement mine own, but not sure what i'll do if a file splits segments.
initial split raw is working. i'll handle the file that crosses segments when i get to it and reimplement the hexviewer, otherwise i won't have examples to test out.
getting rid of fuse, i will probably get rid of zmg and squashfs (sfs).
zmg and squash are commented out, so fuse is gone and i can delete code during the code cleanup, so i'm closing this one.
Need to look into switching from fuse mount programs to using the fuse library calls at some point.