Thread: [sleuthkit-users] Autopsy and TSK Releases
Brought to you by:
carrier
From: Brian C. <ca...@sl...> - 2017-01-18 21:47:33
|
There are new releases of both The Sleuth Kit and Autopsy. New things in Autopsy 4.3.0 are: * Support for slack space on files (as separate virtual files) to enable keyword searching and other analysis * Simple mode for the file extension mismatch module that focuses on only only multimedia and executable files to reduce false positives * New view in tree that shows the MIME types * Tagged items are highlighted in table views * Ordering of columns is saved when user changes them * Support for Android devices with preloaders (uses backup GPT) * Support for images with no file systems (all data is added as unallocated space * User can bulk add list of keywords to a keyword list * New "Experimental" module (activate via Tools, Plugins) with auto ingest feature * Assorted bug fixes and minor enhancements. You can download it from: http://www.sleuthkit.org/autopsy/download.php As was pointed out, we didn't officially release TSK 4.3.1, so this binary release has new things from that release and the 4.4.0 release: 4.4.0: * Compiling in Windows now uses Visual Studio 2015 * tsk_loaddb now adds new files for slack space and JNI was upgraded accordingly. 4.3.1: * NTFS works on 4k sectors * Added support in Java to store local files in encoded form (XORed) * Added Java Account object into datamodel You can download it from: http://www.sleuthkit.org/sleuthkit/download.php |
From: Ketil F. <ke...@fr...> - 2017-01-23 15:56:13
|
Hi Brian, On 18 January 2017 at 22:47, Brian Carrier <ca...@sl...> wrote: > There are new releases of both The Sleuth Kit and Autopsy. > > New things in Autopsy 4.3.0 are: [snip] > * Support for images with no file systems (all data is added as unallocated space This doesn't seem to work for all cases, are there any limitations? The test image linked below doesn't add to Autopsy 4.3.0, I get the usual error message: ------------------------- Add Image Log Errors occured while ingesting image 1. Cannot determine file system type (Sector offset: 0) ------------------------- Image link: https://www.dropbox.com/s/ywmfpwgtznqzam8/add-fail.img.gz?dl=0 This is a small test image (100MB), which originally had a DOS partition table and two (empty) file systems (FAT and EXT4). After creating the file systems, most data before the first file system was overwritten with random bytes, so the partition table is gone. I was hoping to test if it's possible to add an image that has no (recognized) partition table, and then find and add the file systems within autopsy. I'd be interested to learn how this can be done, if it's possible. The file systems start at sector 2048 and 104448: $ file - < <(dd if=add-fail.img bs=512 count=4) /dev/stdin: data $ file - < <(dd if=add-fail.img bs=512 count=4 skip=2048) /dev/stdin: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", Media descriptor 0xf8, sectors/track 63, heads 255, sectors 100353 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 772, serial number 0xb3e93cf7, unlabeled $ file - < <(dd if=add-fail.img bs=512 count=4 skip=104448) /dev/stdin: Linux rev 1.0 ext4 filesystem data, UUID=d86165df-56d5-43a1-b1ea-3d28ebba8c47 (extents) (large files) (huge files) Regards, Ketil |
From: Brian C. <ca...@sl...> - 2017-01-23 16:18:48
|
Hi Ketil, You should now use the new pull down in the “Add Data Source” wizard and choose “Unallocated Space Image File” instead of “Disk Image”. At this point, there is no way to identify a range as a file system, though its a feature that we could now think about adding. One challenge though is that we add the image as unallocated space. If you were to identify a subset of that as a file system, we could easily define a file system over that range and find the files in it. But, we’d probably get a lot of duplicate keyword hits and files if we analyze and carve the original Unallocated space file. So, it would seem more ideal to remake the original unallocated space files to not include the file system, but it could be too late if carving and keyword searching already ran…. in an ideal world, this is probably best done by making the “Disk Image” data source processor have some logic to allow the user to specify an offset for a file system when one can’t be found from the partition table. > On Jan 23, 2017, at 9:53 AM, Ketil Froyn <ke...@fr...> wrote: > > Hi Brian, > > On 18 January 2017 at 22:47, Brian Carrier <ca...@sl...> wrote: >> There are new releases of both The Sleuth Kit and Autopsy. >> >> New things in Autopsy 4.3.0 are: > [snip] >> * Support for images with no file systems (all data is added as unallocated space > > This doesn't seem to work for all cases, are there any limitations? > The test image linked below doesn't add to Autopsy 4.3.0, I get the > usual error message: > > ------------------------- > Add Image Log > Errors occured while ingesting image > 1. Cannot determine file system type (Sector offset: 0) > ------------------------- > > Image link: https://www.dropbox.com/s/ywmfpwgtznqzam8/add-fail.img.gz?dl=0 > > This is a small test image (100MB), which originally had a DOS > partition table and two (empty) file systems (FAT and EXT4). After > creating the file systems, most data before the first file system was > overwritten with random bytes, so the partition table is gone. I was > hoping to test if it's possible to add an image that has no > (recognized) partition table, and then find and add the file systems > within autopsy. I'd be interested to learn how this can be done, if > it's possible. > > The file systems start at sector 2048 and 104448: > > $ file - < <(dd if=add-fail.img bs=512 count=4) > /dev/stdin: data > > $ file - < <(dd if=add-fail.img bs=512 count=4 skip=2048) > /dev/stdin: DOS/MBR boot sector, code offset 0x58+2, OEM-ID > "mkfs.fat", Media descriptor 0xf8, sectors/track 63, heads 255, > sectors 100353 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 772, > serial number 0xb3e93cf7, unlabeled > > $ file - < <(dd if=add-fail.img bs=512 count=4 skip=104448) > /dev/stdin: Linux rev 1.0 ext4 filesystem data, > UUID=d86165df-56d5-43a1-b1ea-3d28ebba8c47 (extents) (large files) > (huge files) > > Regards, Ketil |