Closed arisjr closed 3 weeks ago
One possible solution that comes to mind is, when using multicases opening on a read-only file systems (and perhaps on every multicases opening), to copy the original sleuth.db's (when it exists) to a user temporary location, change its image_names table entries for absolute paths and modify the sleuthkit JNI IPED flow to read the modified temporary sleuth.db's.
Isn't this already implemented?
@arisjr, does it happen only with multicases? Can you try with the latest release? I think the issue may be related to #1782, which was fixed in 4.1.4.
One possible solution that comes to mind is, when using multicases opening on a read-only file systems (and perhaps on every multicases opening), to copy the original sleuth.db's (when it exists) to a user temporary location, change its image_names table entries for absolute paths and modify the sleuthkit JNI IPED flow to read the modified temporary sleuth.db's.
Isn't this already implemented?
At least on 4.1.3 I think not. I think this is implemented on iped files (markers) only, since long time ago.
does it happen only with multicases?
This happens only on multicases with this version. multiple -d files and individual portable openings are not affected as I could test.
I think the issue may be related to https://github.com/sepinf-inc/IPED/issues/1782, which was fixed in 4.1.4.
Will take a look on that right away.
@wladimirleite
I think the issue may be related to https://github.com/sepinf-inc/IPED/issues/1782, which was fixed in 4.1.4.
Our scenario has some similarities, but most of the case does not apply. We are using a shared read-only file system (windows network) as you were, but it is a mapped file system.
I only added read only file system to the issue because it would not be possible to turn the original sleuth.db into absolute path on our case.
Anyway, I will try to implement a test with two small dd evidences with the latest IPED, running with portable.
Meanwhile I will try to reproduce the issue here.
@wladimirleite I tested with some small images with IPED 4.1.6, processing with portable on windows (two evidences) and linux (two evidences) and analyzing on windows, on the same read-only shared file system.
All tests passed! Your correction on 4.1.4 solved the issue.
Thanks and sorry to submit an already solved issue. The case I had issues was already processed back then and issue you corrected wasn't clear that corrected my case too.
Keep up the great work!!
Thank you @arisjr!
SCENARIO
We have several IPED (4.1.3) cases processed with portable option, and images and cases are on the same read-only file system. On our case, this images are processed on a linux platform and analysed on an windows platform, but the same problem applies to a windows to windows process/analysis scenario.
When the analyst opens the portable processed cases with multicase, it opens fine at first, loads all indexes, and the interface works fine for searches also, but when the user choose to open a file, the IPED interface loaded does not find the related image (dd, e01, ...), and the file opening fails.
The same processed IPED case when opened individually does the same operation normally, without errors.
LOGS
LOGS of the multicase interface file opening operations follows bellow.
Opening a carved item:
Opening an active item:
POSSIBLE SOLUTIONS
One possible solution that comes to mind is, when using multicases opening on a read-only file systems (and perhaps on every multicases opening), to copy the original sleuth.db's (when it exists) to a user temporary location, change its image_names table entries for absolute paths and modify the sleuthkit JNI IPED flow to read the modified temporary sleuth.db's.
Another possible solution (with less bandwidth usage, but harder to implement, I think) is to record the base path when it loads an index (I think it already does that, because it appends it to the item full path when selecting an item - it occurs on the status bar at least), and somehow inject it into the sleuthkit JNI as a path correction when opening an item.