sepinf-inc / IPED

IPED Digital Forensic Tool. It is an open source software that can be used to process and analyze digital evidence, often seized at crime scenes by law enforcement or in a corporate investigation by private examiners.
Other
884 stars 209 forks source link

Multicases does not find images processed with portable option #2238

Closed arisjr closed 3 weeks ago

arisjr commented 3 weeks ago

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:

2024-06-05 08:45:31     [INFO]  [app.ui.ExternalFileOpen$1]                     Externally Opening file /item02_M231589.dd/vol_vol6/$Unalloc/Unalloc_229215_212459005440_320062092800-Frag0>>Carved-2682275840.avi
org.sleuthkit.datamodel.ReadContentInputStream$ReadContentInputStreamException: Error reading file 'Unalloc_229215_212459005440_320062092800' (id=229230) at offset 2682275840.
        at org.sleuthkit.datamodel.ReadContentInputStream.read(ReadContentInputStream.java:105)
        at iped.engine.sleuthkit.SleuthkitInputStream.read(SleuthkitInputStream.java:32)
        at iped.utils.LimitedSeekableInputStream.read(LimitedSeekableInputStream.java:53)
        at java.base/java.io.BufferedInputStream.fill(Unknown Source)
        at java.base/java.io.BufferedInputStream.read1(Unknown Source)
        at java.base/java.io.BufferedInputStream.read(Unknown Source)
        at java.base/java.io.InputStream.transferTo(Unknown Source)
        at java.base/java.nio.file.Files.copy(Unknown Source)
        at iped.engine.data.Item.getTempFile(Item.java:608)
        at iped.app.ui.ExternalFileOpen$1.run(ExternalFileOpen.java:38)
Caused by: org.sleuthkit.datamodel.TskCoreException: Error stat(ing) image file (raw_open: image "../item02_M231589.dd" - No such file or directory)
        at org.sleuthkit.datamodel.SleuthkitJNI.openImgNat(Native Method)
        at org.sleuthkit.datamodel.SleuthkitJNI.openImage(SleuthkitJNI.java:894)
        at org.sleuthkit.datamodel.SleuthkitJNI.openImage(SleuthkitJNI.java:837)
        at org.sleuthkit.datamodel.Image.getImageHandle(Image.java:128)
        at org.sleuthkit.datamodel.LayoutFile.readInt(LayoutFile.java:171)
        at org.sleuthkit.datamodel.AbstractFile.read(AbstractFile.java:1048)
        at org.sleuthkit.datamodel.ReadContentInputStream.read(ReadContentInputStream.java:89)
        ... 9 more

Opening an active item:

2024-06-05 08:56:09     [INFO]  [app.ui.ExternalFileOpen$1]                     Externally Opening file /item02_M231589.dd/vol_vol2/Documents and Settings/adm/Configuraþ§es locais/Dados de aplicativos/Google/Chrome/User Data/Default/Pepper Data/Shockwave Flash/556.tmp
org.sleuthkit.datamodel.ReadContentInputStream$ReadContentInputStreamException: Error reading file '556.tmp' (id=10419) at offset 0.
        at org.sleuthkit.datamodel.ReadContentInputStream.read(ReadContentInputStream.java:105)
        at iped.engine.sleuthkit.SleuthkitInputStream.read(SleuthkitInputStream.java:32)
        at java.base/java.io.BufferedInputStream.fill(Unknown Source)
        at java.base/java.io.BufferedInputStream.read1(Unknown Source)
        at java.base/java.io.BufferedInputStream.read(Unknown Source)
        at java.base/java.io.InputStream.transferTo(Unknown Source)
        at java.base/java.nio.file.Files.copy(Unknown Source)
        at iped.engine.data.Item.getTempFile(Item.java:608)
        at iped.app.ui.ExternalFileOpen$1.run(ExternalFileOpen.java:38)
Caused by: org.sleuthkit.datamodel.TskCoreException: Error stat(ing) image file (raw_open: image "../item02_M231589.dd" - No such file or directory)
        at org.sleuthkit.datamodel.SleuthkitJNI.openImgNat(Native Method)
        at org.sleuthkit.datamodel.SleuthkitJNI.openImage(SleuthkitJNI.java:894)
        at org.sleuthkit.datamodel.SleuthkitJNI.openImage(SleuthkitJNI.java:837)
        at org.sleuthkit.datamodel.Image.getImageHandle(Image.java:128)
        at org.sleuthkit.datamodel.FileSystem.getFileSystemHandle(FileSystem.java:113)
        at org.sleuthkit.datamodel.FsContent.loadFileHandle(FsContent.java:149)
        at org.sleuthkit.datamodel.FsContent.readInt(FsContent.java:184)
        at org.sleuthkit.datamodel.AbstractFile.read(AbstractFile.java:1048)
        at org.sleuthkit.datamodel.ReadContentInputStream.read(ReadContentInputStream.java:89)
        ... 8 more

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.

wladimirleite commented 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?

wladimirleite commented 3 weeks ago

@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.

arisjr commented 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?

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.

arisjr commented 3 weeks ago

@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.

wladimirleite commented 3 weeks ago

Meanwhile I will try to reproduce the issue here.

arisjr commented 3 weeks ago

@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!!

wladimirleite commented 3 weeks ago

Thank you @arisjr!