sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.

Re: [sleuthkit-users] tsk_recover whole dd image

[<sle...@fa...>]

I investigated my problem a bit further. tsk_recover calls tsk_fs_open_img() (in auto.cpp, line 439). So if I don't provide an offset it tries to open a file system at offset 0 instead of walking through the volume system to find the file systems first. I don't know how useful a patch for this "issue" would be since other tools already spit out the respective offset(s) and one could just call tsk_recover from a script (like Nanni's).

-----Original message-----
Sent: Wednesday, 25 November 2015 at 08:47:40
From: sle...@fa...
To: sleuthkit-users <sle...@li...>
Subject: Re: [sleuthkit-users] tsk_recover whole dd image
Without specifying the offset I get the same output as before. 
Thanks Nanni, I will have a look at this.

>-----Original message-----
>Sent: Tuesday, 24 November 2015 at 17:15:14
>From: "Derrick Karpo" <dk...@gm...>
>To: sle...@fa...
>Subject: Re: [sleuthkit-users] tsk_recover whole dd image
>Hello.
>
>What happens when you run it without the offset, but leave the sector size?
>
>Derrick
>

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: [sleuthkit-users] istat Output - Direct Blocks Question

[Efstratios S. <esk...@gm...>]

I did a bit research on how to find direct blocks on local storage so I
used the exact commands on the Xen guest vm (running Ubuntu 12.04) :

sudo debugfs /dev/storage_containing_filesystem
stat /path_to_file

And as output I got the same direct block numbers - " addresses " as istat
provides !! Here is a screenshot : http://prntscr.com/9a6m1k

So I guess they are the correct block addresses? :/ correct me if I am
wrong. .

Thanks for your time,
Efstratios


On Fri, Dec 4, 2015 at 2:02 AM, Kazi Fazal <ka...@gm...> wrote:

> I believe those are virtual offsets, not actual addresses. I'm pretty sure
> about that but I could be wrong as I've done this a while back. Please look
> it up. I once had similar problems with sleuthkit in the past.
> On Dec 3, 2015 4:38 PM, "Efstratios Skleparis" <esk...@gm...>
> wrote:
>
>> Dear all,
>>
>> I have a question about the tool istat from sleuth kit library API.
>> Using the tool we get some Direct block "addresses" like on the
>> following example :
>>
>> inode: 2670461
>> Allocated
>> Group: 326
>> Generation Id: 2797282208
>> uid / gid: 1000 / 1000
>> mode: rrw-------
>> size: 6613
>> num of links: 1
>>
>> Inode Times:
>> Accessed:       2015-12-03 11:03:34 (EET)
>> File Modified:  2015-03-27 14:05:13 (EET)
>> Inode Modified: 2015-11-30 18:16:04 (EET)
>>
>> Direct Blocks:
>> 21120876 21120877
>>
>>  Those Direct Blocks (numbers) are the Physical Addresses of Blocks on
>> the virtual storage ? Virtual addresses of the blocks ? what exactly?
>>
>>  If I use blkcat and one of those number I get correct output of the
>> file I am viewing.
>>
>>  My intention is to write a file on a domU of Xen from a dom0
>> perspective. I tried to use write() function but got a bad file
>> descriptor error ..
>>
>> Thanks,
>> Efstratios
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>> Give your users amazing mobile app experiences with Intel(R) XDK.
>> Use one codebase in this all-in-one HTML5 development environment.
>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
>> OSs.
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>>
>

[sleuthkit-users] istat Output - Direct Blocks Question

[Efstratios S. <esk...@gm...>]

Dear all,

I have a question about the tool istat from sleuth kit library API.
Using the tool we get some Direct block "addresses" like on the
following example :

inode: 2670461
Allocated
Group: 326
Generation Id: 2797282208
uid / gid: 1000 / 1000
mode: rrw-------
size: 6613
num of links: 1

Inode Times:
Accessed:	2015-12-03 11:03:34 (EET)
File Modified:	2015-03-27 14:05:13 (EET)
Inode Modified:	2015-11-30 18:16:04 (EET)

Direct Blocks:
21120876 21120877

 Those Direct Blocks (numbers) are the Physical Addresses of Blocks on
the virtual storage ? Virtual addresses of the blocks ? what exactly?

 If I use blkcat and one of those number I get correct output of the
file I am viewing.

 My intention is to write a file on a domU of Xen from a dom0
perspective. I tried to use write() function but got a bad file
descriptor error ..

Thanks,
Efstratios

[sleuthkit-users] Autopsy Media Viewer Issue

[Hoyt H. <hoy...@gm...>]

I posted the following to the forum today, but I think I might get a faster
response this way...

Windows 7 Professional, sp1, x64
Autopsy 4.0.0
Plugins: Video Triage, MultiContentViewer, SmutDetect4Autopsy,
KeywordSearch, RecentActivity, Email Parser, TestNG, ImageGallery,

I'm working a case (1.7TB) involving picture evidence. I opened the case
using "Tools > View Images/Videos", which took quite a while to work
through the data. I left it to work over a weekend and when I came back,
the Image/Video Gallery was blank. I closed that and returned to the
Directory Listing tab. Now picture files, when highlighted in the Data
Sources or Views nodes, only show up black in the Results node. Thumbnail
views works, but the Media tab in the Results node doesn't display the
picture file. Further, it doesn't seem to be attempting to do anything when
opening"Tools > View Images/Videos". I've tried opening the case using
different machines that also have Autopsy 4 installed with the same results.

Any ideas? This is an extremely important case and I'm starting to sweat a
little. Thanks in advance!

-- 
Hoyt
-----------------

Re: [sleuthkit-users] tsk_recover whole dd image

[<sle...@fa...>]

Without specifying the offset I get the same output as before. 
Thanks Nanni, I will have a look at this.

>-----Original message-----
>Sent: Tuesday, 24 November 2015 at 17:15:14
>From: "Derrick Karpo" <dk...@gm...>
>To: sle...@fa...
>Subject: Re: [sleuthkit-users] tsk_recover whole dd image
>Hello.
>
>What happens when you run it without the offset, but leave the sector size?
>
>Derrick
>

Re: [sleuthkit-users] tsk_recover whole dd image

[Derrick K. <dk...@gm...>]

Hello.

What happens when you run it without the offset, but leave the sector size?

Derrick


On Tue, Nov 24, 2015 at 7:03 AM,  <sle...@fa...> wrote:
> This command runs fine. Good so far, but I want to automate the whole process, so just giving the image as argument should be enough so that all partitions are processed.
>
> -----Original message-----
> Sent: Tuesday, 24 November 2015 at 14:34:04
> From: "Derrick Karpo" <dk...@gm...>
> To: sle...@fa...
> Subject: Re: [sleuthkit-users] tsk_recover whole dd image
> Hello.
>
> What happens if you run it against a single partition with an offset,
> and force the sector size like this?
>
>   `tsk_recover -v -e -i raw -o 206848 -b 512 wip/image.dd recovered'
>
> Derrick
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] tsk_recover whole dd image

[<sle...@fa...>]

This command runs fine. Good so far, but I want to automate the whole process, so just giving the image as argument should be enough so that all partitions are processed.

-----Original message-----
Sent: Tuesday, 24 November 2015 at 14:34:04
From: "Derrick Karpo" <dk...@gm...>
To: sle...@fa...
Subject: Re: [sleuthkit-users] tsk_recover whole dd image
Hello.

What happens if you run it against a single partition with an offset,
and force the sector size like this?

  `tsk_recover -v -e -i raw -o 206848 -b 512 wip/image.dd recovered'

Derrick

Re: [sleuthkit-users] tsk_recover whole dd image

[Derrick K. <dk...@gm...>]

Hello.

What happens if you run it against a single partition with an offset,
and force the sector size like this?

  `tsk_recover -v -e -i raw -o 206848 -b 512 wip/image.dd recovered'

Derrick


On Tue, Nov 24, 2015 at 2:05 AM,  <sle...@fa...> wrote:
> Hi,
> I am using version 4.2.0 of TSK and I am trying to recover all files from an image. For testing purposes I am using the image from http://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html
> Unfortunately it is not working. I run "tsk_recover -v -e -i raw wip/image.dd recovered/" and get the following output:
>
> tsk_img_open: Type: 1   NumImg: 1  Img1: wip/image.dd
> tsk_img_findFiles: wip/image.dd found
> tsk_img_findFiles: 1 total segments found
> raw_open: segment: 0  size: 21474836480  max offset: 21474836480  path: wip/image.dd
> fsopen: Auto detection mode at offset 0
> raw_read: byte offset: 0 len: 65536
> raw_read: found in image 0 relative offset: 0 len: 65536
> raw_read_segment: opening file into slot 0: wip/image.dd
> ntfs_open: invalid sector size: 190
> fatxxfs_open: Invalid sector size (190)
> exfatfs_get_fs_size_params: Invalid sector size base 2 logarithm (190), not in range (9 - 12)
> fatxxfs_open: Invalid sector size (190)
> ext2fs_open: invalid magic
> raw_read: byte offset: 65536 len: 65536
> raw_read: found in image 0 relative offset: 65536 len: 65536
> ufs_open: Trying 256KB UFS2 location
> raw_read: byte offset: 262144 len: 65536
> raw_read: found in image 0 relative offset: 262144 len: 65536
> ufs_open: Trying UFS1 location
> ufs_open: No UFS magic found
> raw_read: byte offset: 156160 len: 65536
> raw_read: found in image 0 relative offset: 156160 len: 65536
> raw_read: byte offset: 426496 len: 65536
> raw_read: found in image 0 relative offset: 426496 len: 65536
> raw_read: byte offset: 561664 len: 65536
> raw_read: found in image 0 relative offset: 561664 len: 65536
> raw_read: byte offset: 696832 len: 65536
> raw_read: found in image 0 relative offset: 696832 len: 65536
> raw_read: byte offset: 832000 len: 65536
> raw_read: found in image 0 relative offset: 832000 len: 65536
> raw_read: byte offset: 967168 len: 65536
> raw_read: found in image 0 relative offset: 967168 len: 65536
> raw_read: byte offset: 1102336 len: 65536
> raw_read: found in image 0 relative offset: 1102336 len: 65536
> raw_read: byte offset: 1083392 len: 65536
> raw_read: found in image 0 relative offset: 1083392 len: 65536
> raw_read: byte offset: 1237504 len: 65536
> raw_read: found in image 0 relative offset: 1237504 len: 65536
> raw_read: byte offset: 1218560 len: 65536
> raw_read: found in image 0 relative offset: 1218560 len: 65536
> raw_read: byte offset: 1372672 len: 65536
> raw_read: found in image 0 relative offset: 1372672 len: 65536
> raw_read: byte offset: 1507840 len: 65536
> raw_read: found in image 0 relative offset: 1507840 len: 65536
> raw_read: byte offset: 1643008 len: 65536
> raw_read: found in image 0 relative offset: 1643008 len: 65536
> raw_read: byte offset: 1778176 len: 65536
> raw_read: found in image 0 relative offset: 1778176 len: 65536
> raw_read: byte offset: 1913344 len: 65536
> raw_read: found in image 0 relative offset: 1913344 len: 65536
> raw_read: byte offset: 2048512 len: 65536
> raw_read: found in image 0 relative offset: 2048512 len: 65536
> raw_read: byte offset: 2183680 len: 65536
> raw_read: found in image 0 relative offset: 2183680 len: 65536
> raw_read: byte offset: 2318848 len: 65536
> raw_read: found in image 0 relative offset: 2318848 len: 65536
> raw_read: byte offset: 2454016 len: 65536
> raw_read: found in image 0 relative offset: 2454016 len: 65536
> raw_read: byte offset: 2589184 len: 65536
> raw_read: found in image 0 relative offset: 2589184 len: 65536
> raw_read: byte offset: 2724352 len: 65536
> raw_read: found in image 0 relative offset: 2724352 len: 65536
> raw_read: byte offset: 2859520 len: 65536
> raw_read: found in image 0 relative offset: 2859520 len: 65536
> raw_read: byte offset: 2994688 len: 65536
> raw_read: found in image 0 relative offset: 2994688 len: 65536
> raw_read: byte offset: 3129856 len: 65536
> raw_read: found in image 0 relative offset: 3129856 len: 65536
> raw_read: byte offset: 3265024 len: 65536
> raw_read: found in image 0 relative offset: 3265024 len: 65536
> raw_read: byte offset: 3400192 len: 65536
> raw_read: found in image 0 relative offset: 3400192 len: 65536
> raw_read: byte offset: 3535360 len: 65536
> raw_read: found in image 0 relative offset: 3535360 len: 65536
> raw_read: byte offset: 3670528 len: 65536
> raw_read: found in image 0 relative offset: 3670528 len: 65536
> raw_read: byte offset: 3805696 len: 65536
> raw_read: found in image 0 relative offset: 3805696 len: 65536
> raw_read: byte offset: 3940864 len: 65536
> raw_read: found in image 0 relative offset: 3940864 len: 65536
> raw_read: byte offset: 4076032 len: 65536
> raw_read: found in image 0 relative offset: 4076032 len: 65536
> raw_read: byte offset: 4211200 len: 65536
> raw_read: found in image 0 relative offset: 4211200 len: 65536
> raw_read: byte offset: 4346368 len: 65536
> raw_read: found in image 0 relative offset: 4346368 len: 65536
> raw_read: byte offset: 4481536 len: 65536
> raw_read: found in image 0 relative offset: 4481536 len: 65536
> raw_read: byte offset: 4616704 len: 65536
> raw_read: found in image 0 relative offset: 4616704 len: 65536
> raw_read: byte offset: 4751872 len: 65536
> raw_read: found in image 0 relative offset: 4751872 len: 65536
> raw_read: byte offset: 4887040 len: 65536
> raw_read: found in image 0 relative offset: 4887040 len: 65536
> raw_read: byte offset: 5022208 len: 65536
> raw_read: found in image 0 relative offset: 5022208 len: 65536
> raw_read: byte offset: 5157376 len: 65536
> raw_read: found in image 0 relative offset: 5157376 len: 65536
> raw_read: byte offset: 5292544 len: 65536
> raw_read: found in image 0 relative offset: 5292544 len: 65536
> raw_read: byte offset: 5427712 len: 65536
> raw_read: found in image 0 relative offset: 5427712 len: 65536
> raw_read: byte offset: 5562880 len: 65536
> raw_read: found in image 0 relative offset: 5562880 len: 65536
> raw_read: byte offset: 5698048 len: 65536
> raw_read: found in image 0 relative offset: 5698048 len: 65536
> raw_read: byte offset: 5833216 len: 65536
> raw_read: found in image 0 relative offset: 5833216 len: 65536
> raw_read: byte offset: 5968384 len: 65536
> raw_read: found in image 0 relative offset: 5968384 len: 65536
> raw_read: byte offset: 6103552 len: 65536
> raw_read: found in image 0 relative offset: 6103552 len: 65536
> raw_read: byte offset: 6238720 len: 65536
> raw_read: found in image 0 relative offset: 6238720 len: 65536
> raw_read: byte offset: 6373888 len: 65536
> raw_read: found in image 0 relative offset: 6373888 len: 65536
> raw_read: byte offset: 6509056 len: 65536
> raw_read: found in image 0 relative offset: 6509056 len: 65536
> raw_read: byte offset: 6644224 len: 65536
> raw_read: found in image 0 relative offset: 6644224 len: 65536
> raw_read: byte offset: 6779392 len: 65536
> raw_read: found in image 0 relative offset: 6779392 len: 65536
> raw_read: byte offset: 6914560 len: 65536
> raw_read: found in image 0 relative offset: 6914560 len: 65536
> raw_read: byte offset: 7049728 len: 65536
> raw_read: found in image 0 relative offset: 7049728 len: 65536
> raw_read: byte offset: 7184896 len: 65536
> raw_read: found in image 0 relative offset: 7184896 len: 65536
> raw_read: byte offset: 7320064 len: 65536
> raw_read: found in image 0 relative offset: 7320064 len: 65536
> raw_read: byte offset: 7455232 len: 65536
> raw_read: found in image 0 relative offset: 7455232 len: 65536
> raw_read: byte offset: 7590400 len: 65536
> raw_read: found in image 0 relative offset: 7590400 len: 65536
> raw_read: byte offset: 7571456 len: 65536
> raw_read: found in image 0 relative offset: 7571456 len: 65536
> raw_read: byte offset: 7725568 len: 65536
> raw_read: found in image 0 relative offset: 7725568 len: 65536
> raw_read: byte offset: 7706624 len: 65536
> raw_read: found in image 0 relative offset: 7706624 len: 65536
> raw_read: byte offset: 7860736 len: 65536
> raw_read: found in image 0 relative offset: 7860736 len: 65536
> raw_read: byte offset: 7841792 len: 65536
> raw_read: found in image 0 relative offset: 7841792 len: 65536
> raw_read: byte offset: 7995904 len: 65536
> raw_read: found in image 0 relative offset: 7995904 len: 65536
> raw_read: byte offset: 7976960 len: 65536
> raw_read: found in image 0 relative offset: 7976960 len: 65536
> raw_read: byte offset: 8131072 len: 65536
> raw_read: found in image 0 relative offset: 8131072 len: 65536
> raw_read: byte offset: 8112128 len: 65536
> raw_read: found in image 0 relative offset: 8112128 len: 65536
> raw_read: byte offset: 8266240 len: 65536
> raw_read: found in image 0 relative offset: 8266240 len: 65536
> raw_read: byte offset: 8247296 len: 65536
> raw_read: found in image 0 relative offset: 8247296 len: 65536
> raw_read: byte offset: 8401408 len: 65536
> raw_read: found in image 0 relative offset: 8401408 len: 65536
> raw_read: byte offset: 8382464 len: 65536
> raw_read: found in image 0 relative offset: 8382464 len: 65536
> raw_read: byte offset: 8536576 len: 65536
> raw_read: found in image 0 relative offset: 8536576 len: 65536
> raw_read: byte offset: 8517632 len: 65536
> raw_read: found in image 0 relative offset: 8517632 len: 65536
> yaffsfs_open: could not find valid spare area format
> See http://wiki.sleuthkit.org/index.php?title=YAFFS2 for help on Yaffs2 configuration
> raw_read: byte offset: 1024 len: 65536
> raw_read: found in image 0 relative offset: 1024 len: 65536
> iso9660_open img_info: 139756571050000 ftype: 2048 test: 1
> iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001
> Trying RAW ISO9660 with 16-byte pre-block size
> fs_prepost_read: Mapped 32768 to 37648
> iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001
> Trying RAW ISO9660 with 24-byte pre-block size
> fs_prepost_read: Mapped 32768 to 37656
> iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001
> iso9660_open: Error loading volume descriptor
> Cannot determine file system type (Sector offset: 0)Files Recovered: 0
>
> mmls gave me:
>
> DOS Partition Table
> Offset Sector: 0
> Units are in 512-byte sectors
>
>       Slot      Start        End          Length       Description
> 000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
> 001:  -------   0000000000   0000002047   0000002048   Unallocated
> 002:  000:000   0000002048   0000206847   0000204800   NTFS / exFAT (0x07)
> 003:  000:001   0000206848   0041940991   0041734144   NTFS / exFAT (0x07)
> 004:  -------   0041940992   0041943039   0000002048   Unallocated
>
> So can you help me please how to get it working?
>
> Kind regards
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] tsk_recover whole dd image

[<sle...@fa...>]

Hi,
I am using version 4.2.0 of TSK and I am trying to recover all files from an image. For testing purposes I am using the image from http://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html
Unfortunately it is not working. I run "tsk_recover -v -e -i raw wip/image.dd recovered/" and get the following output:

tsk_img_open: Type: 1   NumImg: 1  Img1: wip/image.dd
tsk_img_findFiles: wip/image.dd found
tsk_img_findFiles: 1 total segments found
raw_open: segment: 0  size: 21474836480  max offset: 21474836480  path: wip/image.dd
fsopen: Auto detection mode at offset 0
raw_read: byte offset: 0 len: 65536
raw_read: found in image 0 relative offset: 0 len: 65536
raw_read_segment: opening file into slot 0: wip/image.dd
ntfs_open: invalid sector size: 190
fatxxfs_open: Invalid sector size (190)
exfatfs_get_fs_size_params: Invalid sector size base 2 logarithm (190), not in range (9 - 12)
fatxxfs_open: Invalid sector size (190)
ext2fs_open: invalid magic
raw_read: byte offset: 65536 len: 65536
raw_read: found in image 0 relative offset: 65536 len: 65536
ufs_open: Trying 256KB UFS2 location
raw_read: byte offset: 262144 len: 65536
raw_read: found in image 0 relative offset: 262144 len: 65536
ufs_open: Trying UFS1 location
ufs_open: No UFS magic found
raw_read: byte offset: 156160 len: 65536
raw_read: found in image 0 relative offset: 156160 len: 65536
raw_read: byte offset: 426496 len: 65536
raw_read: found in image 0 relative offset: 426496 len: 65536
raw_read: byte offset: 561664 len: 65536
raw_read: found in image 0 relative offset: 561664 len: 65536
raw_read: byte offset: 696832 len: 65536
raw_read: found in image 0 relative offset: 696832 len: 65536
raw_read: byte offset: 832000 len: 65536
raw_read: found in image 0 relative offset: 832000 len: 65536
raw_read: byte offset: 967168 len: 65536
raw_read: found in image 0 relative offset: 967168 len: 65536
raw_read: byte offset: 1102336 len: 65536
raw_read: found in image 0 relative offset: 1102336 len: 65536
raw_read: byte offset: 1083392 len: 65536
raw_read: found in image 0 relative offset: 1083392 len: 65536
raw_read: byte offset: 1237504 len: 65536
raw_read: found in image 0 relative offset: 1237504 len: 65536
raw_read: byte offset: 1218560 len: 65536
raw_read: found in image 0 relative offset: 1218560 len: 65536
raw_read: byte offset: 1372672 len: 65536
raw_read: found in image 0 relative offset: 1372672 len: 65536
raw_read: byte offset: 1507840 len: 65536
raw_read: found in image 0 relative offset: 1507840 len: 65536
raw_read: byte offset: 1643008 len: 65536
raw_read: found in image 0 relative offset: 1643008 len: 65536
raw_read: byte offset: 1778176 len: 65536
raw_read: found in image 0 relative offset: 1778176 len: 65536
raw_read: byte offset: 1913344 len: 65536
raw_read: found in image 0 relative offset: 1913344 len: 65536
raw_read: byte offset: 2048512 len: 65536
raw_read: found in image 0 relative offset: 2048512 len: 65536
raw_read: byte offset: 2183680 len: 65536
raw_read: found in image 0 relative offset: 2183680 len: 65536
raw_read: byte offset: 2318848 len: 65536
raw_read: found in image 0 relative offset: 2318848 len: 65536
raw_read: byte offset: 2454016 len: 65536
raw_read: found in image 0 relative offset: 2454016 len: 65536
raw_read: byte offset: 2589184 len: 65536
raw_read: found in image 0 relative offset: 2589184 len: 65536
raw_read: byte offset: 2724352 len: 65536
raw_read: found in image 0 relative offset: 2724352 len: 65536
raw_read: byte offset: 2859520 len: 65536
raw_read: found in image 0 relative offset: 2859520 len: 65536
raw_read: byte offset: 2994688 len: 65536
raw_read: found in image 0 relative offset: 2994688 len: 65536
raw_read: byte offset: 3129856 len: 65536
raw_read: found in image 0 relative offset: 3129856 len: 65536
raw_read: byte offset: 3265024 len: 65536
raw_read: found in image 0 relative offset: 3265024 len: 65536
raw_read: byte offset: 3400192 len: 65536
raw_read: found in image 0 relative offset: 3400192 len: 65536
raw_read: byte offset: 3535360 len: 65536
raw_read: found in image 0 relative offset: 3535360 len: 65536
raw_read: byte offset: 3670528 len: 65536
raw_read: found in image 0 relative offset: 3670528 len: 65536
raw_read: byte offset: 3805696 len: 65536
raw_read: found in image 0 relative offset: 3805696 len: 65536
raw_read: byte offset: 3940864 len: 65536
raw_read: found in image 0 relative offset: 3940864 len: 65536
raw_read: byte offset: 4076032 len: 65536
raw_read: found in image 0 relative offset: 4076032 len: 65536
raw_read: byte offset: 4211200 len: 65536
raw_read: found in image 0 relative offset: 4211200 len: 65536
raw_read: byte offset: 4346368 len: 65536
raw_read: found in image 0 relative offset: 4346368 len: 65536
raw_read: byte offset: 4481536 len: 65536
raw_read: found in image 0 relative offset: 4481536 len: 65536
raw_read: byte offset: 4616704 len: 65536
raw_read: found in image 0 relative offset: 4616704 len: 65536
raw_read: byte offset: 4751872 len: 65536
raw_read: found in image 0 relative offset: 4751872 len: 65536
raw_read: byte offset: 4887040 len: 65536
raw_read: found in image 0 relative offset: 4887040 len: 65536
raw_read: byte offset: 5022208 len: 65536
raw_read: found in image 0 relative offset: 5022208 len: 65536
raw_read: byte offset: 5157376 len: 65536
raw_read: found in image 0 relative offset: 5157376 len: 65536
raw_read: byte offset: 5292544 len: 65536
raw_read: found in image 0 relative offset: 5292544 len: 65536
raw_read: byte offset: 5427712 len: 65536
raw_read: found in image 0 relative offset: 5427712 len: 65536
raw_read: byte offset: 5562880 len: 65536
raw_read: found in image 0 relative offset: 5562880 len: 65536
raw_read: byte offset: 5698048 len: 65536
raw_read: found in image 0 relative offset: 5698048 len: 65536
raw_read: byte offset: 5833216 len: 65536
raw_read: found in image 0 relative offset: 5833216 len: 65536
raw_read: byte offset: 5968384 len: 65536
raw_read: found in image 0 relative offset: 5968384 len: 65536
raw_read: byte offset: 6103552 len: 65536
raw_read: found in image 0 relative offset: 6103552 len: 65536
raw_read: byte offset: 6238720 len: 65536
raw_read: found in image 0 relative offset: 6238720 len: 65536
raw_read: byte offset: 6373888 len: 65536
raw_read: found in image 0 relative offset: 6373888 len: 65536
raw_read: byte offset: 6509056 len: 65536
raw_read: found in image 0 relative offset: 6509056 len: 65536
raw_read: byte offset: 6644224 len: 65536
raw_read: found in image 0 relative offset: 6644224 len: 65536
raw_read: byte offset: 6779392 len: 65536
raw_read: found in image 0 relative offset: 6779392 len: 65536
raw_read: byte offset: 6914560 len: 65536
raw_read: found in image 0 relative offset: 6914560 len: 65536
raw_read: byte offset: 7049728 len: 65536
raw_read: found in image 0 relative offset: 7049728 len: 65536
raw_read: byte offset: 7184896 len: 65536
raw_read: found in image 0 relative offset: 7184896 len: 65536
raw_read: byte offset: 7320064 len: 65536
raw_read: found in image 0 relative offset: 7320064 len: 65536
raw_read: byte offset: 7455232 len: 65536
raw_read: found in image 0 relative offset: 7455232 len: 65536
raw_read: byte offset: 7590400 len: 65536
raw_read: found in image 0 relative offset: 7590400 len: 65536
raw_read: byte offset: 7571456 len: 65536
raw_read: found in image 0 relative offset: 7571456 len: 65536
raw_read: byte offset: 7725568 len: 65536
raw_read: found in image 0 relative offset: 7725568 len: 65536
raw_read: byte offset: 7706624 len: 65536
raw_read: found in image 0 relative offset: 7706624 len: 65536
raw_read: byte offset: 7860736 len: 65536
raw_read: found in image 0 relative offset: 7860736 len: 65536
raw_read: byte offset: 7841792 len: 65536
raw_read: found in image 0 relative offset: 7841792 len: 65536
raw_read: byte offset: 7995904 len: 65536
raw_read: found in image 0 relative offset: 7995904 len: 65536
raw_read: byte offset: 7976960 len: 65536
raw_read: found in image 0 relative offset: 7976960 len: 65536
raw_read: byte offset: 8131072 len: 65536
raw_read: found in image 0 relative offset: 8131072 len: 65536
raw_read: byte offset: 8112128 len: 65536
raw_read: found in image 0 relative offset: 8112128 len: 65536
raw_read: byte offset: 8266240 len: 65536
raw_read: found in image 0 relative offset: 8266240 len: 65536
raw_read: byte offset: 8247296 len: 65536
raw_read: found in image 0 relative offset: 8247296 len: 65536
raw_read: byte offset: 8401408 len: 65536
raw_read: found in image 0 relative offset: 8401408 len: 65536
raw_read: byte offset: 8382464 len: 65536
raw_read: found in image 0 relative offset: 8382464 len: 65536
raw_read: byte offset: 8536576 len: 65536
raw_read: found in image 0 relative offset: 8536576 len: 65536
raw_read: byte offset: 8517632 len: 65536
raw_read: found in image 0 relative offset: 8517632 len: 65536
yaffsfs_open: could not find valid spare area format
See http://wiki.sleuthkit.org/index.php?title=YAFFS2 for help on Yaffs2 configuration
raw_read: byte offset: 1024 len: 65536
raw_read: found in image 0 relative offset: 1024 len: 65536
iso9660_open img_info: 139756571050000 ftype: 2048 test: 1
iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001
Trying RAW ISO9660 with 16-byte pre-block size
fs_prepost_read: Mapped 32768 to 37648
iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001
Trying RAW ISO9660 with 24-byte pre-block size
fs_prepost_read: Mapped 32768 to 37656
iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001
iso9660_open: Error loading volume descriptor
Cannot determine file system type (Sector offset: 0)Files Recovered: 0

mmls gave me:

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000206847   0000204800   NTFS / exFAT (0x07)
003:  000:001   0000206848   0041940991   0041734144   NTFS / exFAT (0x07)
004:  -------   0041940992   0041943039   0000002048   Unallocated

So can you help me please how to get it working?

Kind regards

Re: [sleuthkit-users] Get direct blocks pointers for files/dirs

[Pasquale R. <pjr...@gm...>]

Efstatios,

Two things I see in the first code provided:

1. fs_file_block_number *+=* size / 4096; seem like it should be
fs_file_block_number *=* size / 4096, otherwise with each loop it should be
fs_file_block_number = 0 + 2, then fs_file_block_number = 2 + 2, etc for
the required loops.

2. inside the loop, the blockstring[i] isn't provided the right answers to
coincide with your addr printf's. the printf's should be

addr = 24172552
blockstring[0] = 24172552

addr = 24172553
blockstring[1] = 24172552

which would show the current address value which gets replaced (addr) is
being stored in your array (blockstring) which is incrementing and not
overwriting its value (0, 1, etc...)

When in doubt, debug the crap out of it with more minute variable
debug/printf statements.

Let me know if any of those help you out,

Pasquale


On Tue, Nov 17, 2015 at 4:43 PM, Efstratios Skleparis <esk...@gm...>
wrote:

> Dear all,
>
> I tried to implement a linked list like this :
>
> struct List {
> struct List *next;
> TSK_DADDR_T addr;
> };
>
> struct List *list; /*Global list*/
>
> void createL() {
> list = NULL;
> }
>
> void insertL(TSK_DADDR_T addr) {
> struct List *node;
>
> if (list == NULL) { /*First node of our list*/
> list = malloc(sizeof(struct List));
> list->next = NULL;
> list->addr = (TSK_DADDR_T*) malloc(4096 * sizeof(TSK_DADDR_T)); /*allocate
> space*/
> if (list->addr == NULL) {
> printf("Error in insertL malloc \n");
> return;
> }
> list->addr = addr;
> printf(" First Node - InsertL, list - > addr : %lu\n", list->addr); //
> just for debugging
> } else {
> node = malloc(sizeof(struct List));
> node->next = list; /* This node becomes head of the list*/
> list->addr = (TSK_DADDR_T*) malloc(4096 * sizeof(TSK_DADDR_T)); /*allocate
> space*/
> if (node->addr == NULL) {
> printf("Error in insertL malloc \n");
> return;
> }
> node->addr = addr;
> list = node;
> printf("____InsertL - > list - > addr : %lu\n", node->addr); // just for
> debugging
> }
> }
>
> void display(struct List *list)
> { // just print the list
> while (list != NULL)
> {
> printf("Direct Blocks: %lu\t", list->addr);
> list = list->next;
> }
> printf("\n");
> }
>
> void reversedisplay(struct List *head)
> { // print the list in reverse
> if (head != NULL)
> {
> reversedisplay(head->next);
> printf("%d\t", head->addr);
> }
> }
>
>
> ---------------------------------------------------------------------------------
>
> And in GetBlockAddress I am calling insertL like this :
>
>
> TSK_WALK_RET_ENUM GetBlockAddress(TSK_FS_FILE *fs_file, TSK_OFF_T off,
> TSK_DADDR_T addr, char *buf, size_t size,
>                                   TSK_FS_BLOCK_FLAG_ENUM flags, void *ptr)
> {
>
> int  s;
>
> if (flags & TSK_FS_BLOCK_FLAG_CONT) {
>
> /* Bitwise and , SK_FS_BLOCK_FLAG_CONT = Block contains file content.*/
>
> //printf("addr = %lu\n", addr );
>
> for (  s = (int) size ; s > 0 ; s -= fs_file->fs_info->block_size ) {
> /* Parse all the blocks, every 4096 bytes */
>
>
> insertL(addr);
> printf("Blockstring after insertion = %lu\n",  list->addr ); // just for
> debugging
>
> /* Calculate how many direct blocks the file has */
> fs_file_block_number += size / 4096;
>
> printf(" iteration [%d], s = %d \n", fs_file_block_number,  s);
>
> } /* end of for*/
>
> } /* end of if*/
>
> return TSK_WALK_CONT;
>
> }// end of GetBlockAddress
>
>
> But still when i am printing the list on the main function i get this :
>
> First Node - InsertL, list - > addr : 24172552
> Blockstring after insertion = 24172552
>  iteration [1], s = 4096
> ____InsertL - > list - > addr : 24172553
> Blockstring after insertion = 24172553
>  iteration [2], s = 4096
>
>  fs_file_block_number = 2 // just for debugging - correct
>
> //reverse(display)
> 34986192 24172553
>
> //display(list)
> Direct Blocks: 24172553 Direct Blocks: 34986192
>
> I still can't get the first block number !! Thought when I am calling the
> GetBlockAddress the direct block numbers inside the function  is correct,
> when I am inserting it on the global list the number is correct again!!!
> But on main.c it's not I can only get the second block number ( my file has
> a size of 6113 bytes - > 2 blocks only - each block has 4096 size , Correct
> direct block numbers are : 24172552 and 24172553 verified by istat and
> checked on the raw storage )
>
> I am starting to believe there is a "problem" with the calling of :
>  tsk_fs_file_walk(fs_file, (TSK_FS_FILE_WALK_FLAG_ENUM)(TSK_FS_FILE_WALK_FLAG_AONLY
> | TSK_FS_FILE_WALK_FLAG_SLACK), GetBlockAddress, NULL);    Correct me if I
> am wrong or is it something with my implementation??
>
> Thanks again for your time,
> Efstratios
>
>
> On Tue, Nov 17, 2015 at 10:26 PM, Jean-François Gingras <
> jea...@gm...> wrote:
>
>> If I'm not mistaking, each time GetBlockAddress gets call, you
>> reinitialize your blockstring variable (malloc).
>>
>> You should probably use a linked list of TSK_DADDR_T object and add your
>> block in GetBlockAddress to that list.
>>
>> Or you could resize the array.
>>
>> Also, I'm not sure the size parameter of GetBlockAddress has anything to
>> do with the TSK_DADDR_T structure.
>>
>> Hope this will help
>> Le 17 nov. 2015 3:02 PM, "Efstratios Skleparis" <esk...@gm...> a
>> écrit :
>>
>>> Pasquale,
>>>
>>> You are right, sorry ! here is what I have done :
>>>
>>>
>>> Global variables :
>>>
>>> TSK_DADDR_T *blockstring ; // array where i want to store block numbers
>>>
>>> int fs_file_block_number; // numbers of direct blocks per files
>>>
>>> GetBlockAddress Function code :
>>>
>>> TSK_WALK_RET_ENUM GetBlockAddress(TSK_FS_FILE *fs_file, TSK_OFF_T off,
>>> TSK_DADDR_T addr, char *buf, size_t size,
>>>                                   TSK_FS_BLOCK_FLAG_ENUM flags, void
>>> *ptr) {
>>>
>>> /*Memory Allocation for Block Addresses Array*/
>>> blockstring = malloc(size * sizeof(TSK_DADDR_T));
>>>
>>> int i = 0, s;
>>>
>>> if (flags & TSK_FS_BLOCK_FLAG_CONT) {
>>>
>>> /* Bitwise and , SK_FS_BLOCK_FLAG_CONT = Block contains file content.*/
>>>
>>> printf("addr = %lu\n", addr );
>>>
>>> for (  s = (int) size ; s > 0 ; s -= fs_file->fs_info->block_size ) {
>>> /* Parse all the blocks, every 4096 bytes */
>>>
>>> if (addr) {
>>>
>>> blockstring[i] = addr;
>>> i++;
>>>
>>> /* Calculate how many direct blocks the file has */
>>> fs_file_block_number += size / 4096;
>>> s -= fs_file->fs_info->block_size;
>>>
>>> printf("blockstring[%d] = %lu\n", i, blockstring[i] );
>>> printf(" iteration [%d], s = %d \n", i, s);
>>>
>>> // tsk_printf("blockstring :%"
>>> //            PRIuDADDR
>>> //            "\n ", blockstring[fs_file_block_number]);
>>>
>>> // tsk_printf("[%d]\n", fs_file_block_number);
>>>
>>> }
>>> } /* end of for*/
>>>
>>> } /* end of if*/
>>>
>>> return TSK_WALK_CONT;
>>>
>>> }// end of GetBlockAddress
>>>
>>> How I call - use the above function in main :
>>>
>>>
>>> TSK_FS_FILE *fs_file = NULL;
>>>
>>>
>>> fs_file = tsk_fs_file_open_meta(fs, NULL, inum); // open file based on
>>> inode number
>>>
>>> if ((fs_file != NULL) && (fs_file->meta != NULL)) {
>>> /* Error Checking*/
>>>
>>> if (fs_file->fs_info->ftype == TSK_FS_TYPE_EXT4) {
>>>
>>> /*Ext4 file system*/
>>>
>>> tsk_fs_file_walk(fs_file,
>>>                 (TSK_FS_FILE_WALK_FLAG_ENUM)(
>>>                     TSK_FS_FILE_WALK_FLAG_AONLY |
>>> TSK_FS_FILE_WALK_FLAG_SLACK),
>>>                 GetBlockAddress, NULL);
>>>
>>>
>>> }
>>>
>>> }
>>>
>>> printf("\n fs_file_block_number = %d \n", fs_file_block_number);
>>> for (i = 0; i < fs_file_block_number; i++) {
>>> printf("Direct Blocks: %lu\n", blockstring[i] );
>>> }
>>>
>>>
>>> And the output i get is the following :
>>> >>> inside function printfs <<<
>>> addr = 24172552
>>> blockstring[1] = 0
>>>  iteration [1], s = 0
>>> addr = 24172553
>>> blockstring[1] = 0
>>>  iteration [1], s = 0
>>>
>>> >>> main printfs <<<
>>>  fs_file_block_number = 2
>>>
>>> Direct Blocks: 24172553
>>>
>>> Direct Blocks: 0
>>>
>>> Thanks for your time,
>>> Efstratios
>>>
>>> On Tue, Nov 17, 2015 at 8:24 PM, Pasquale Rinaldi <pjr...@gm...>
>>> wrote:
>>>
>>>> Efstratios,
>>>>
>>>> Without seeing the code, its hard to tell. It sounds like you have the
>>>> array initialization inside your looping function,  which would reset the
>>>> array and then only store the last value in the loop since you just reset
>>>> the array.
>>>>
>>>> It's hard to say without seeing the code though. Its purely a guess
>>>> based on common mistakes I make when doing this kind of looping.
>>>>
>>>> Pasquale
>>>>
>>>> On Tue, Nov 17, 2015 at 5:34 AM, Efstratios Skleparis <
>>>> esk...@gm...> wrote:
>>>>
>>>>> Pasquale,
>>>>>
>>>>> Thanks a lot for the information you provided me :-) I finally managed
>>>>> to get the direct block pointers of a file !!
>>>>>
>>>>> That if(flags & TSK_FS_BLOCK_FLAG_CONT) did the work, on
>>>>> GetBlockAddress function! :-)
>>>>>
>>>>> My question is there a reason you can only "Save" the last one from
>>>>> NumberX,NumberY,NumberZ [block pointers, numbers] ? or am I doing something
>>>>> wrong? I am using C not C++ for my introspection tool.
>>>>>
>>>>> I tried using an array but still only NumberZ is saved the others are
>>>>> lost. . I placed some printfs and for some reason every time the array
>>>>> is initialized after it returns the NumberX, NumberY.
>>>>>
>>>>> Thanks a lot for your time and help,
>>>>> Efstratios
>>>>>
>>>>> On Mon, Nov 16, 2015 at 3:23 AM, Pasquale Rinaldi <pjr...@gm...
>>>>> > wrote:
>>>>>
>>>>>> Efstratios,
>>>>>>
>>>>>> Check out this function on a program I am working on which
>>>>>> incorporates the sleuthkit c library functions. I calculate the direct
>>>>>> block addresses and store this value in my db table. The functions to look
>>>>>> at are "BlockFile", "GetBlockAddress" and the "tsk_fs_file_walk" functions.
>>>>>> They are on lines: 517-588.
>>>>>>
>>>>>>
>>>>>> https://github.com/pjrinaldi/wombatforensics/blob/master/wombatfunctions.cpp
>>>>>>
>>>>>> I hope it helps.
>>>>>> Pasquale
>>>>>>
>>>>>> On Sat, Nov 14, 2015 at 12:25 PM, Efstratios Skleparis <
>>>>>> esk...@gm...> wrote:
>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I am using Sleuth kit library in order to write an introspection
>>>>>>> tool for *XEN* hypervisor running on ubuntu 12.04.5 x64bit and my
>>>>>>> question is if we have the inode number of a file on a disk [ guest VM -
>>>>>>> *ext4* filesystem], for example 6031126 and want to handle the *direct
>>>>>>> block pointers of a file/directory* later in a program,how can we
>>>>>>> get them(Direct Blocks : *NumberX*,*NymberY* etc) ? I used the
>>>>>>> sleuth kit function *istat* inside my program like on istat.cpp
>>>>>>> program of the library:
>>>>>>>
>>>>>>> if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
>>>>>>> tsk_error_print(stderr);
>>>>>>> fs->close(fs);
>>>>>>> img->close(img);
>>>>>>> exit(1);
>>>>>>> }
>>>>>>>
>>>>>>> to get information about this inode and i got this :
>>>>>>>
>>>>>>> inode: 6031126
>>>>>>> Allocated
>>>>>>> Group: 736
>>>>>>> Generation Id: 3880935525
>>>>>>> uid / gid: 1000 / 1000
>>>>>>> mode: rrw-------
>>>>>>> Flags: Extents,
>>>>>>> size: 6613
>>>>>>> num of links: 1
>>>>>>>
>>>>>>> Inode Times:
>>>>>>> Accessed:   2015-11-12 17:47:55.857360000 (EET)
>>>>>>> File Modified:  2015-03-27 14:05:13.000000000 (EET)
>>>>>>> Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
>>>>>>> File Created:   2015-07-12 00:51:07.489188000 (EEST)
>>>>>>>
>>>>>>> Direct Blocks:
>>>>>>> 24172552 24172553
>>>>>>>
>>>>>>> I know the block numbers by calling that function but i don't know
>>>>>>> where they are stored and how to retrieve them in a variable..? in order to
>>>>>>> use them later in my tool!
>>>>>>>
>>>>>>> Any tips/suggestions or documentation would be appreciated!
>>>>>>> Thanks in advance!
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sleuthkit-users mailing list
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>>>>> http://www.sleuthkit.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>>>
>>>
>

Re: [sleuthkit-users] Get direct blocks pointers for files/dirs

[Efstratios S. <esk...@gm...>]

Dear all,

I tried to implement a linked list like this :

struct List {
struct List *next;
TSK_DADDR_T addr;
};

struct List *list; /*Global list*/

void createL() {
list = NULL;
}

void insertL(TSK_DADDR_T addr) {
struct List *node;

if (list == NULL) { /*First node of our list*/
list = malloc(sizeof(struct List));
list->next = NULL;
list->addr = (TSK_DADDR_T*) malloc(4096 * sizeof(TSK_DADDR_T)); /*allocate
space*/
if (list->addr == NULL) {
printf("Error in insertL malloc \n");
return;
}
list->addr = addr;
printf(" First Node - InsertL, list - > addr : %lu\n", list->addr); // just
for debugging
} else {
node = malloc(sizeof(struct List));
node->next = list; /* This node becomes head of the list*/
list->addr = (TSK_DADDR_T*) malloc(4096 * sizeof(TSK_DADDR_T)); /*allocate
space*/
if (node->addr == NULL) {
printf("Error in insertL malloc \n");
return;
}
node->addr = addr;
list = node;
printf("____InsertL - > list - > addr : %lu\n", node->addr); // just for
debugging
}
}

void display(struct List *list)
{ // just print the list
while (list != NULL)
{
printf("Direct Blocks: %lu\t", list->addr);
list = list->next;
}
printf("\n");
}

void reversedisplay(struct List *head)
{ // print the list in reverse
if (head != NULL)
{
reversedisplay(head->next);
printf("%d\t", head->addr);
}
}

---------------------------------------------------------------------------------

And in GetBlockAddress I am calling insertL like this :


TSK_WALK_RET_ENUM GetBlockAddress(TSK_FS_FILE *fs_file, TSK_OFF_T off,
TSK_DADDR_T addr, char *buf, size_t size,
                                  TSK_FS_BLOCK_FLAG_ENUM flags, void *ptr) {

int  s;

if (flags & TSK_FS_BLOCK_FLAG_CONT) {

/* Bitwise and , SK_FS_BLOCK_FLAG_CONT = Block contains file content.*/

//printf("addr = %lu\n", addr );

for (  s = (int) size ; s > 0 ; s -= fs_file->fs_info->block_size ) {
/* Parse all the blocks, every 4096 bytes */


insertL(addr);
printf("Blockstring after insertion = %lu\n",  list->addr ); // just for
debugging

/* Calculate how many direct blocks the file has */
fs_file_block_number += size / 4096;

printf(" iteration [%d], s = %d \n", fs_file_block_number,  s);

} /* end of for*/

} /* end of if*/

return TSK_WALK_CONT;

}// end of GetBlockAddress


But still when i am printing the list on the main function i get this :

First Node - InsertL, list - > addr : 24172552
Blockstring after insertion = 24172552
 iteration [1], s = 4096
____InsertL - > list - > addr : 24172553
Blockstring after insertion = 24172553
 iteration [2], s = 4096

 fs_file_block_number = 2 // just for debugging - correct

//reverse(display)
34986192 24172553

//display(list)
Direct Blocks: 24172553 Direct Blocks: 34986192

I still can't get the first block number !! Thought when I am calling the
GetBlockAddress the direct block numbers inside the function  is correct,
when I am inserting it on the global list the number is correct again!!!
But on main.c it's not I can only get the second block number ( my file has
a size of 6113 bytes - > 2 blocks only - each block has 4096 size , Correct
direct block numbers are : 24172552 and 24172553 verified by istat and
checked on the raw storage )

I am starting to believe there is a "problem" with the calling of :
 tsk_fs_file_walk(fs_file,
(TSK_FS_FILE_WALK_FLAG_ENUM)(TSK_FS_FILE_WALK_FLAG_AONLY
| TSK_FS_FILE_WALK_FLAG_SLACK), GetBlockAddress, NULL);    Correct me if I
am wrong or is it something with my implementation??

Thanks again for your time,
Efstratios


On Tue, Nov 17, 2015 at 10:26 PM, Jean-François Gingras <
jea...@gm...> wrote:

> If I'm not mistaking, each time GetBlockAddress gets call, you
> reinitialize your blockstring variable (malloc).
>
> You should probably use a linked list of TSK_DADDR_T object and add your
> block in GetBlockAddress to that list.
>
> Or you could resize the array.
>
> Also, I'm not sure the size parameter of GetBlockAddress has anything to
> do with the TSK_DADDR_T structure.
>
> Hope this will help
> Le 17 nov. 2015 3:02 PM, "Efstratios Skleparis" <esk...@gm...> a
> écrit :
>
>> Pasquale,
>>
>> You are right, sorry ! here is what I have done :
>>
>>
>> Global variables :
>>
>> TSK_DADDR_T *blockstring ; // array where i want to store block numbers
>>
>> int fs_file_block_number; // numbers of direct blocks per files
>>
>> GetBlockAddress Function code :
>>
>> TSK_WALK_RET_ENUM GetBlockAddress(TSK_FS_FILE *fs_file, TSK_OFF_T off,
>> TSK_DADDR_T addr, char *buf, size_t size,
>>                                   TSK_FS_BLOCK_FLAG_ENUM flags, void
>> *ptr) {
>>
>> /*Memory Allocation for Block Addresses Array*/
>> blockstring = malloc(size * sizeof(TSK_DADDR_T));
>>
>> int i = 0, s;
>>
>> if (flags & TSK_FS_BLOCK_FLAG_CONT) {
>>
>> /* Bitwise and , SK_FS_BLOCK_FLAG_CONT = Block contains file content.*/
>>
>> printf("addr = %lu\n", addr );
>>
>> for (  s = (int) size ; s > 0 ; s -= fs_file->fs_info->block_size ) {
>> /* Parse all the blocks, every 4096 bytes */
>>
>> if (addr) {
>>
>> blockstring[i] = addr;
>> i++;
>>
>> /* Calculate how many direct blocks the file has */
>> fs_file_block_number += size / 4096;
>> s -= fs_file->fs_info->block_size;
>>
>> printf("blockstring[%d] = %lu\n", i, blockstring[i] );
>> printf(" iteration [%d], s = %d \n", i, s);
>>
>> // tsk_printf("blockstring :%"
>> //            PRIuDADDR
>> //            "\n ", blockstring[fs_file_block_number]);
>>
>> // tsk_printf("[%d]\n", fs_file_block_number);
>>
>> }
>> } /* end of for*/
>>
>> } /* end of if*/
>>
>> return TSK_WALK_CONT;
>>
>> }// end of GetBlockAddress
>>
>> How I call - use the above function in main :
>>
>>
>> TSK_FS_FILE *fs_file = NULL;
>>
>>
>> fs_file = tsk_fs_file_open_meta(fs, NULL, inum); // open file based on
>> inode number
>>
>> if ((fs_file != NULL) && (fs_file->meta != NULL)) {
>> /* Error Checking*/
>>
>> if (fs_file->fs_info->ftype == TSK_FS_TYPE_EXT4) {
>>
>> /*Ext4 file system*/
>>
>> tsk_fs_file_walk(fs_file,
>>                 (TSK_FS_FILE_WALK_FLAG_ENUM)(
>>                     TSK_FS_FILE_WALK_FLAG_AONLY |
>> TSK_FS_FILE_WALK_FLAG_SLACK),
>>                 GetBlockAddress, NULL);
>>
>>
>> }
>>
>> }
>>
>> printf("\n fs_file_block_number = %d \n", fs_file_block_number);
>> for (i = 0; i < fs_file_block_number; i++) {
>> printf("Direct Blocks: %lu\n", blockstring[i] );
>> }
>>
>>
>> And the output i get is the following :
>> >>> inside function printfs <<<
>> addr = 24172552
>> blockstring[1] = 0
>>  iteration [1], s = 0
>> addr = 24172553
>> blockstring[1] = 0
>>  iteration [1], s = 0
>>
>> >>> main printfs <<<
>>  fs_file_block_number = 2
>>
>> Direct Blocks: 24172553
>>
>> Direct Blocks: 0
>>
>> Thanks for your time,
>> Efstratios
>>
>> On Tue, Nov 17, 2015 at 8:24 PM, Pasquale Rinaldi <pjr...@gm...>
>> wrote:
>>
>>> Efstratios,
>>>
>>> Without seeing the code, its hard to tell. It sounds like you have the
>>> array initialization inside your looping function,  which would reset the
>>> array and then only store the last value in the loop since you just reset
>>> the array.
>>>
>>> It's hard to say without seeing the code though. Its purely a guess
>>> based on common mistakes I make when doing this kind of looping.
>>>
>>> Pasquale
>>>
>>> On Tue, Nov 17, 2015 at 5:34 AM, Efstratios Skleparis <
>>> esk...@gm...> wrote:
>>>
>>>> Pasquale,
>>>>
>>>> Thanks a lot for the information you provided me :-) I finally managed
>>>> to get the direct block pointers of a file !!
>>>>
>>>> That if(flags & TSK_FS_BLOCK_FLAG_CONT) did the work, on
>>>> GetBlockAddress function! :-)
>>>>
>>>> My question is there a reason you can only "Save" the last one from
>>>> NumberX,NumberY,NumberZ [block pointers, numbers] ? or am I doing something
>>>> wrong? I am using C not C++ for my introspection tool.
>>>>
>>>> I tried using an array but still only NumberZ is saved the others are
>>>> lost. . I placed some printfs and for some reason every time the array
>>>> is initialized after it returns the NumberX, NumberY.
>>>>
>>>> Thanks a lot for your time and help,
>>>> Efstratios
>>>>
>>>> On Mon, Nov 16, 2015 at 3:23 AM, Pasquale Rinaldi <pjr...@gm...>
>>>> wrote:
>>>>
>>>>> Efstratios,
>>>>>
>>>>> Check out this function on a program I am working on which
>>>>> incorporates the sleuthkit c library functions. I calculate the direct
>>>>> block addresses and store this value in my db table. The functions to look
>>>>> at are "BlockFile", "GetBlockAddress" and the "tsk_fs_file_walk" functions.
>>>>> They are on lines: 517-588.
>>>>>
>>>>>
>>>>> https://github.com/pjrinaldi/wombatforensics/blob/master/wombatfunctions.cpp
>>>>>
>>>>> I hope it helps.
>>>>> Pasquale
>>>>>
>>>>> On Sat, Nov 14, 2015 at 12:25 PM, Efstratios Skleparis <
>>>>> esk...@gm...> wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I am using Sleuth kit library in order to write an introspection tool
>>>>>> for *XEN* hypervisor running on ubuntu 12.04.5 x64bit and my
>>>>>> question is if we have the inode number of a file on a disk [ guest VM -
>>>>>> *ext4* filesystem], for example 6031126 and want to handle the *direct
>>>>>> block pointers of a file/directory* later in a program,how can we
>>>>>> get them(Direct Blocks : *NumberX*,*NymberY* etc) ? I used the
>>>>>> sleuth kit function *istat* inside my program like on istat.cpp
>>>>>> program of the library:
>>>>>>
>>>>>> if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
>>>>>> tsk_error_print(stderr);
>>>>>> fs->close(fs);
>>>>>> img->close(img);
>>>>>> exit(1);
>>>>>> }
>>>>>>
>>>>>> to get information about this inode and i got this :
>>>>>>
>>>>>> inode: 6031126
>>>>>> Allocated
>>>>>> Group: 736
>>>>>> Generation Id: 3880935525
>>>>>> uid / gid: 1000 / 1000
>>>>>> mode: rrw-------
>>>>>> Flags: Extents,
>>>>>> size: 6613
>>>>>> num of links: 1
>>>>>>
>>>>>> Inode Times:
>>>>>> Accessed:   2015-11-12 17:47:55.857360000 (EET)
>>>>>> File Modified:  2015-03-27 14:05:13.000000000 (EET)
>>>>>> Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
>>>>>> File Created:   2015-07-12 00:51:07.489188000 (EEST)
>>>>>>
>>>>>> Direct Blocks:
>>>>>> 24172552 24172553
>>>>>>
>>>>>> I know the block numbers by calling that function but i don't know
>>>>>> where they are stored and how to retrieve them in a variable..? in order to
>>>>>> use them later in my tool!
>>>>>>
>>>>>> Any tips/suggestions or documentation would be appreciated!
>>>>>> Thanks in advance!
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> sleuthkit-users mailing list
>>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>>>> http://www.sleuthkit.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>>
>>

Re: [sleuthkit-users] Get direct blocks pointers for files/dirs

[Efstratios S. <esk...@gm...>]

I forgot to erase one line as I was copying the code  "s -=
fs_file->fs_info->block_size;" . don't mind it when you see it inside for
loop

On Tue, Nov 17, 2015 at 9:57 PM, Efstratios Skleparis <esk...@gm...>
wrote:

> Pasquale,
>
> You are right, sorry ! here is what I have done :
>
>
> Global variables :
>
> TSK_DADDR_T *blockstring ; // array where i want to store block numbers
>
> int fs_file_block_number; // numbers of direct blocks per files
>
> GetBlockAddress Function code :
>
> TSK_WALK_RET_ENUM GetBlockAddress(TSK_FS_FILE *fs_file, TSK_OFF_T off,
> TSK_DADDR_T addr, char *buf, size_t size,
>                                   TSK_FS_BLOCK_FLAG_ENUM flags, void *ptr)
> {
>
> /*Memory Allocation for Block Addresses Array*/
> blockstring = malloc(size * sizeof(TSK_DADDR_T));
>
> int i = 0, s;
>
> if (flags & TSK_FS_BLOCK_FLAG_CONT) {
>
> /* Bitwise and , SK_FS_BLOCK_FLAG_CONT = Block contains file content.*/
>
> printf("addr = %lu\n", addr );
>
> for (  s = (int) size ; s > 0 ; s -= fs_file->fs_info->block_size ) {
> /* Parse all the blocks, every 4096 bytes */
>
> if (addr) {
>
> blockstring[i] = addr;
> i++;
>
> /* Calculate how many direct blocks the file has */
> fs_file_block_number += size / 4096;
> s -= fs_file->fs_info->block_size;
>
> printf("blockstring[%d] = %lu\n", i, blockstring[i] );
> printf(" iteration [%d], s = %d \n", i, s);
>
> // tsk_printf("blockstring :%"
> //            PRIuDADDR
> //            "\n ", blockstring[fs_file_block_number]);
>
> // tsk_printf("[%d]\n", fs_file_block_number);
>
> }
> } /* end of for*/
>
> } /* end of if*/
>
> return TSK_WALK_CONT;
>
> }// end of GetBlockAddress
>
> How I call - use the above function in main :
>
>
> TSK_FS_FILE *fs_file = NULL;
>
>
> fs_file = tsk_fs_file_open_meta(fs, NULL, inum); // open file based on
> inode number
>
> if ((fs_file != NULL) && (fs_file->meta != NULL)) {
> /* Error Checking*/
>
> if (fs_file->fs_info->ftype == TSK_FS_TYPE_EXT4) {
>
> /*Ext4 file system*/
>
> tsk_fs_file_walk(fs_file,
>                 (TSK_FS_FILE_WALK_FLAG_ENUM)(
>                     TSK_FS_FILE_WALK_FLAG_AONLY |
> TSK_FS_FILE_WALK_FLAG_SLACK),
>                 GetBlockAddress, NULL);
>
>
> }
>
> }
>
> printf("\n fs_file_block_number = %d \n", fs_file_block_number);
> for (i = 0; i < fs_file_block_number; i++) {
> printf("Direct Blocks: %lu\n", blockstring[i] );
> }
>
>
> And the output i get is the following :
> >>> inside function printfs <<<
> addr = 24172552
> blockstring[1] = 0
>  iteration [1], s = 0
> addr = 24172553
> blockstring[1] = 0
>  iteration [1], s = 0
>
> >>> main printfs <<<
>  fs_file_block_number = 2
>
> Direct Blocks: 24172553
>
> Direct Blocks: 0
>
> Thanks for your time,
> Efstratios
>
> On Tue, Nov 17, 2015 at 8:24 PM, Pasquale Rinaldi <pjr...@gm...>
> wrote:
>
>> Efstratios,
>>
>> Without seeing the code, its hard to tell. It sounds like you have the
>> array initialization inside your looping function,  which would reset the
>> array and then only store the last value in the loop since you just reset
>> the array.
>>
>> It's hard to say without seeing the code though. Its purely a guess based
>> on common mistakes I make when doing this kind of looping.
>>
>> Pasquale
>>
>> On Tue, Nov 17, 2015 at 5:34 AM, Efstratios Skleparis <
>> esk...@gm...> wrote:
>>
>>> Pasquale,
>>>
>>> Thanks a lot for the information you provided me :-) I finally managed
>>> to get the direct block pointers of a file !!
>>>
>>> That if(flags & TSK_FS_BLOCK_FLAG_CONT) did the work, on
>>> GetBlockAddress function! :-)
>>>
>>> My question is there a reason you can only "Save" the last one from
>>> NumberX,NumberY,NumberZ [block pointers, numbers] ? or am I doing something
>>> wrong? I am using C not C++ for my introspection tool.
>>>
>>> I tried using an array but still only NumberZ is saved the others are
>>> lost. . I placed some printfs and for some reason every time the array
>>> is initialized after it returns the NumberX, NumberY.
>>>
>>> Thanks a lot for your time and help,
>>> Efstratios
>>>
>>> On Mon, Nov 16, 2015 at 3:23 AM, Pasquale Rinaldi <pjr...@gm...>
>>> wrote:
>>>
>>>> Efstratios,
>>>>
>>>> Check out this function on a program I am working on which incorporates
>>>> the sleuthkit c library functions. I calculate the direct block addresses
>>>> and store this value in my db table. The functions to look at are
>>>> "BlockFile", "GetBlockAddress" and the "tsk_fs_file_walk" functions. They
>>>> are on lines: 517-588.
>>>>
>>>>
>>>> https://github.com/pjrinaldi/wombatforensics/blob/master/wombatfunctions.cpp
>>>>
>>>> I hope it helps.
>>>> Pasquale
>>>>
>>>> On Sat, Nov 14, 2015 at 12:25 PM, Efstratios Skleparis <
>>>> esk...@gm...> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I am using Sleuth kit library in order to write an introspection tool
>>>>> for *XEN* hypervisor running on ubuntu 12.04.5 x64bit and my question
>>>>> is if we have the inode number of a file on a disk [ guest VM - *ext4*
>>>>> filesystem], for example 6031126 and want to handle the *direct block
>>>>> pointers of a file/directory* later in a program,how can we get
>>>>> them(Direct Blocks : *NumberX*,*NymberY* etc) ? I used the sleuth kit
>>>>> function *istat* inside my program like on istat.cpp program of the
>>>>> library:
>>>>>
>>>>> if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
>>>>> tsk_error_print(stderr);
>>>>> fs->close(fs);
>>>>> img->close(img);
>>>>> exit(1);
>>>>> }
>>>>>
>>>>> to get information about this inode and i got this :
>>>>>
>>>>> inode: 6031126
>>>>> Allocated
>>>>> Group: 736
>>>>> Generation Id: 3880935525
>>>>> uid / gid: 1000 / 1000
>>>>> mode: rrw-------
>>>>> Flags: Extents,
>>>>> size: 6613
>>>>> num of links: 1
>>>>>
>>>>> Inode Times:
>>>>> Accessed:   2015-11-12 17:47:55.857360000 (EET)
>>>>> File Modified:  2015-03-27 14:05:13.000000000 (EET)
>>>>> Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
>>>>> File Created:   2015-07-12 00:51:07.489188000 (EEST)
>>>>>
>>>>> Direct Blocks:
>>>>> 24172552 24172553
>>>>>
>>>>> I know the block numbers by calling that function but i don't know
>>>>> where they are stored and how to retrieve them in a variable..? in order to
>>>>> use them later in my tool!
>>>>>
>>>>> Any tips/suggestions or documentation would be appreciated!
>>>>> Thanks in advance!
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> sleuthkit-users mailing list
>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>>> http://www.sleuthkit.org
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [sleuthkit-users] Get direct blocks pointers for files/dirs

[Jean-François G. <jea...@gm...>]

If I'm not mistaking, each time GetBlockAddress gets call, you reinitialize
your blockstring variable (malloc).

You should probably use a linked list of TSK_DADDR_T object and add your
block in GetBlockAddress to that list.

Or you could resize the array.

Also, I'm not sure the size parameter of GetBlockAddress has anything to do
with the TSK_DADDR_T structure.

Hope this will help
Le 17 nov. 2015 3:02 PM, "Efstratios Skleparis" <esk...@gm...> a
écrit :

> Pasquale,
>
> You are right, sorry ! here is what I have done :
>
>
> Global variables :
>
> TSK_DADDR_T *blockstring ; // array where i want to store block numbers
>
> int fs_file_block_number; // numbers of direct blocks per files
>
> GetBlockAddress Function code :
>
> TSK_WALK_RET_ENUM GetBlockAddress(TSK_FS_FILE *fs_file, TSK_OFF_T off,
> TSK_DADDR_T addr, char *buf, size_t size,
>                                   TSK_FS_BLOCK_FLAG_ENUM flags, void *ptr)
> {
>
> /*Memory Allocation for Block Addresses Array*/
> blockstring = malloc(size * sizeof(TSK_DADDR_T));
>
> int i = 0, s;
>
> if (flags & TSK_FS_BLOCK_FLAG_CONT) {
>
> /* Bitwise and , SK_FS_BLOCK_FLAG_CONT = Block contains file content.*/
>
> printf("addr = %lu\n", addr );
>
> for (  s = (int) size ; s > 0 ; s -= fs_file->fs_info->block_size ) {
> /* Parse all the blocks, every 4096 bytes */
>
> if (addr) {
>
> blockstring[i] = addr;
> i++;
>
> /* Calculate how many direct blocks the file has */
> fs_file_block_number += size / 4096;
> s -= fs_file->fs_info->block_size;
>
> printf("blockstring[%d] = %lu\n", i, blockstring[i] );
> printf(" iteration [%d], s = %d \n", i, s);
>
> // tsk_printf("blockstring :%"
> //            PRIuDADDR
> //            "\n ", blockstring[fs_file_block_number]);
>
> // tsk_printf("[%d]\n", fs_file_block_number);
>
> }
> } /* end of for*/
>
> } /* end of if*/
>
> return TSK_WALK_CONT;
>
> }// end of GetBlockAddress
>
> How I call - use the above function in main :
>
>
> TSK_FS_FILE *fs_file = NULL;
>
>
> fs_file = tsk_fs_file_open_meta(fs, NULL, inum); // open file based on
> inode number
>
> if ((fs_file != NULL) && (fs_file->meta != NULL)) {
> /* Error Checking*/
>
> if (fs_file->fs_info->ftype == TSK_FS_TYPE_EXT4) {
>
> /*Ext4 file system*/
>
> tsk_fs_file_walk(fs_file,
>                 (TSK_FS_FILE_WALK_FLAG_ENUM)(
>                     TSK_FS_FILE_WALK_FLAG_AONLY |
> TSK_FS_FILE_WALK_FLAG_SLACK),
>                 GetBlockAddress, NULL);
>
>
> }
>
> }
>
> printf("\n fs_file_block_number = %d \n", fs_file_block_number);
> for (i = 0; i < fs_file_block_number; i++) {
> printf("Direct Blocks: %lu\n", blockstring[i] );
> }
>
>
> And the output i get is the following :
> >>> inside function printfs <<<
> addr = 24172552
> blockstring[1] = 0
>  iteration [1], s = 0
> addr = 24172553
> blockstring[1] = 0
>  iteration [1], s = 0
>
> >>> main printfs <<<
>  fs_file_block_number = 2
>
> Direct Blocks: 24172553
>
> Direct Blocks: 0
>
> Thanks for your time,
> Efstratios
>
> On Tue, Nov 17, 2015 at 8:24 PM, Pasquale Rinaldi <pjr...@gm...>
> wrote:
>
>> Efstratios,
>>
>> Without seeing the code, its hard to tell. It sounds like you have the
>> array initialization inside your looping function,  which would reset the
>> array and then only store the last value in the loop since you just reset
>> the array.
>>
>> It's hard to say without seeing the code though. Its purely a guess based
>> on common mistakes I make when doing this kind of looping.
>>
>> Pasquale
>>
>> On Tue, Nov 17, 2015 at 5:34 AM, Efstratios Skleparis <
>> esk...@gm...> wrote:
>>
>>> Pasquale,
>>>
>>> Thanks a lot for the information you provided me :-) I finally managed
>>> to get the direct block pointers of a file !!
>>>
>>> That if(flags & TSK_FS_BLOCK_FLAG_CONT) did the work, on
>>> GetBlockAddress function! :-)
>>>
>>> My question is there a reason you can only "Save" the last one from
>>> NumberX,NumberY,NumberZ [block pointers, numbers] ? or am I doing something
>>> wrong? I am using C not C++ for my introspection tool.
>>>
>>> I tried using an array but still only NumberZ is saved the others are
>>> lost. . I placed some printfs and for some reason every time the array
>>> is initialized after it returns the NumberX, NumberY.
>>>
>>> Thanks a lot for your time and help,
>>> Efstratios
>>>
>>> On Mon, Nov 16, 2015 at 3:23 AM, Pasquale Rinaldi <pjr...@gm...>
>>> wrote:
>>>
>>>> Efstratios,
>>>>
>>>> Check out this function on a program I am working on which incorporates
>>>> the sleuthkit c library functions. I calculate the direct block addresses
>>>> and store this value in my db table. The functions to look at are
>>>> "BlockFile", "GetBlockAddress" and the "tsk_fs_file_walk" functions. They
>>>> are on lines: 517-588.
>>>>
>>>>
>>>> https://github.com/pjrinaldi/wombatforensics/blob/master/wombatfunctions.cpp
>>>>
>>>> I hope it helps.
>>>> Pasquale
>>>>
>>>> On Sat, Nov 14, 2015 at 12:25 PM, Efstratios Skleparis <
>>>> esk...@gm...> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I am using Sleuth kit library in order to write an introspection tool
>>>>> for *XEN* hypervisor running on ubuntu 12.04.5 x64bit and my question
>>>>> is if we have the inode number of a file on a disk [ guest VM - *ext4*
>>>>> filesystem], for example 6031126 and want to handle the *direct block
>>>>> pointers of a file/directory* later in a program,how can we get
>>>>> them(Direct Blocks : *NumberX*,*NymberY* etc) ? I used the sleuth kit
>>>>> function *istat* inside my program like on istat.cpp program of the
>>>>> library:
>>>>>
>>>>> if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
>>>>> tsk_error_print(stderr);
>>>>> fs->close(fs);
>>>>> img->close(img);
>>>>> exit(1);
>>>>> }
>>>>>
>>>>> to get information about this inode and i got this :
>>>>>
>>>>> inode: 6031126
>>>>> Allocated
>>>>> Group: 736
>>>>> Generation Id: 3880935525
>>>>> uid / gid: 1000 / 1000
>>>>> mode: rrw-------
>>>>> Flags: Extents,
>>>>> size: 6613
>>>>> num of links: 1
>>>>>
>>>>> Inode Times:
>>>>> Accessed:   2015-11-12 17:47:55.857360000 (EET)
>>>>> File Modified:  2015-03-27 14:05:13.000000000 (EET)
>>>>> Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
>>>>> File Created:   2015-07-12 00:51:07.489188000 (EEST)
>>>>>
>>>>> Direct Blocks:
>>>>> 24172552 24172553
>>>>>
>>>>> I know the block numbers by calling that function but i don't know
>>>>> where they are stored and how to retrieve them in a variable..? in order to
>>>>> use them later in my tool!
>>>>>
>>>>> Any tips/suggestions or documentation would be appreciated!
>>>>> Thanks in advance!
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> sleuthkit-users mailing list
>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>>> http://www.sleuthkit.org
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

Re: [sleuthkit-users] Get direct blocks pointers for files/dirs

[Efstratios S. <esk...@gm...>]

Pasquale,

You are right, sorry ! here is what I have done :


Global variables :

TSK_DADDR_T *blockstring ; // array where i want to store block numbers

int fs_file_block_number; // numbers of direct blocks per files

GetBlockAddress Function code :

TSK_WALK_RET_ENUM GetBlockAddress(TSK_FS_FILE *fs_file, TSK_OFF_T off,
TSK_DADDR_T addr, char *buf, size_t size,
                                  TSK_FS_BLOCK_FLAG_ENUM flags, void *ptr) {

/*Memory Allocation for Block Addresses Array*/
blockstring = malloc(size * sizeof(TSK_DADDR_T));

int i = 0, s;

if (flags & TSK_FS_BLOCK_FLAG_CONT) {

/* Bitwise and , SK_FS_BLOCK_FLAG_CONT = Block contains file content.*/

printf("addr = %lu\n", addr );

for (  s = (int) size ; s > 0 ; s -= fs_file->fs_info->block_size ) {
/* Parse all the blocks, every 4096 bytes */

if (addr) {

blockstring[i] = addr;
i++;

/* Calculate how many direct blocks the file has */
fs_file_block_number += size / 4096;
s -= fs_file->fs_info->block_size;

printf("blockstring[%d] = %lu\n", i, blockstring[i] );
printf(" iteration [%d], s = %d \n", i, s);

// tsk_printf("blockstring :%"
//            PRIuDADDR
//            "\n ", blockstring[fs_file_block_number]);

// tsk_printf("[%d]\n", fs_file_block_number);

}
} /* end of for*/

} /* end of if*/

return TSK_WALK_CONT;

}// end of GetBlockAddress

How I call - use the above function in main :


TSK_FS_FILE *fs_file = NULL;


fs_file = tsk_fs_file_open_meta(fs, NULL, inum); // open file based on
inode number

if ((fs_file != NULL) && (fs_file->meta != NULL)) {
/* Error Checking*/

if (fs_file->fs_info->ftype == TSK_FS_TYPE_EXT4) {

/*Ext4 file system*/

tsk_fs_file_walk(fs_file,
                (TSK_FS_FILE_WALK_FLAG_ENUM)(
                    TSK_FS_FILE_WALK_FLAG_AONLY |
TSK_FS_FILE_WALK_FLAG_SLACK),
                GetBlockAddress, NULL);


}

}

printf("\n fs_file_block_number = %d \n", fs_file_block_number);
for (i = 0; i < fs_file_block_number; i++) {
printf("Direct Blocks: %lu\n", blockstring[i] );
}


And the output i get is the following :
>>> inside function printfs <<<
addr = 24172552
blockstring[1] = 0
 iteration [1], s = 0
addr = 24172553
blockstring[1] = 0
 iteration [1], s = 0

>>> main printfs <<<
 fs_file_block_number = 2

Direct Blocks: 24172553

Direct Blocks: 0

Thanks for your time,
Efstratios

On Tue, Nov 17, 2015 at 8:24 PM, Pasquale Rinaldi <pjr...@gm...>
wrote:

> Efstratios,
>
> Without seeing the code, its hard to tell. It sounds like you have the
> array initialization inside your looping function,  which would reset the
> array and then only store the last value in the loop since you just reset
> the array.
>
> It's hard to say without seeing the code though. Its purely a guess based
> on common mistakes I make when doing this kind of looping.
>
> Pasquale
>
> On Tue, Nov 17, 2015 at 5:34 AM, Efstratios Skleparis <
> esk...@gm...> wrote:
>
>> Pasquale,
>>
>> Thanks a lot for the information you provided me :-) I finally managed to
>> get the direct block pointers of a file !!
>>
>> That if(flags & TSK_FS_BLOCK_FLAG_CONT) did the work, on GetBlockAddress
>> function! :-)
>>
>> My question is there a reason you can only "Save" the last one from
>> NumberX,NumberY,NumberZ [block pointers, numbers] ? or am I doing something
>> wrong? I am using C not C++ for my introspection tool.
>>
>> I tried using an array but still only NumberZ is saved the others are
>> lost. . I placed some printfs and for some reason every time the array
>> is initialized after it returns the NumberX, NumberY.
>>
>> Thanks a lot for your time and help,
>> Efstratios
>>
>> On Mon, Nov 16, 2015 at 3:23 AM, Pasquale Rinaldi <pjr...@gm...>
>> wrote:
>>
>>> Efstratios,
>>>
>>> Check out this function on a program I am working on which incorporates
>>> the sleuthkit c library functions. I calculate the direct block addresses
>>> and store this value in my db table. The functions to look at are
>>> "BlockFile", "GetBlockAddress" and the "tsk_fs_file_walk" functions. They
>>> are on lines: 517-588.
>>>
>>>
>>> https://github.com/pjrinaldi/wombatforensics/blob/master/wombatfunctions.cpp
>>>
>>> I hope it helps.
>>> Pasquale
>>>
>>> On Sat, Nov 14, 2015 at 12:25 PM, Efstratios Skleparis <
>>> esk...@gm...> wrote:
>>>
>>>> Dear all,
>>>>
>>>> I am using Sleuth kit library in order to write an introspection tool
>>>> for *XEN* hypervisor running on ubuntu 12.04.5 x64bit and my question
>>>> is if we have the inode number of a file on a disk [ guest VM - *ext4*
>>>> filesystem], for example 6031126 and want to handle the *direct block
>>>> pointers of a file/directory* later in a program,how can we get
>>>> them(Direct Blocks : *NumberX*,*NymberY* etc) ? I used the sleuth kit
>>>> function *istat* inside my program like on istat.cpp program of the
>>>> library:
>>>>
>>>> if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
>>>> tsk_error_print(stderr);
>>>> fs->close(fs);
>>>> img->close(img);
>>>> exit(1);
>>>> }
>>>>
>>>> to get information about this inode and i got this :
>>>>
>>>> inode: 6031126
>>>> Allocated
>>>> Group: 736
>>>> Generation Id: 3880935525
>>>> uid / gid: 1000 / 1000
>>>> mode: rrw-------
>>>> Flags: Extents,
>>>> size: 6613
>>>> num of links: 1
>>>>
>>>> Inode Times:
>>>> Accessed:   2015-11-12 17:47:55.857360000 (EET)
>>>> File Modified:  2015-03-27 14:05:13.000000000 (EET)
>>>> Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
>>>> File Created:   2015-07-12 00:51:07.489188000 (EEST)
>>>>
>>>> Direct Blocks:
>>>> 24172552 24172553
>>>>
>>>> I know the block numbers by calling that function but i don't know
>>>> where they are stored and how to retrieve them in a variable..? in order to
>>>> use them later in my tool!
>>>>
>>>> Any tips/suggestions or documentation would be appreciated!
>>>> Thanks in advance!
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> sleuthkit-users mailing list
>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>> http://www.sleuthkit.org
>>>>
>>>>
>>>
>>
>

Re: [sleuthkit-users] Get direct blocks pointers for files/dirs

[Pasquale R. <pjr...@gm...>]

Efstratios,

Without seeing the code, its hard to tell. It sounds like you have the
array initialization inside your looping function,  which would reset the
array and then only store the last value in the loop since you just reset
the array.

It's hard to say without seeing the code though. Its purely a guess based
on common mistakes I make when doing this kind of looping.

Pasquale

On Tue, Nov 17, 2015 at 5:34 AM, Efstratios Skleparis <esk...@gm...>
wrote:

> Pasquale,
>
> Thanks a lot for the information you provided me :-) I finally managed to
> get the direct block pointers of a file !!
>
> That if(flags & TSK_FS_BLOCK_FLAG_CONT) did the work, on GetBlockAddress
> function! :-)
>
> My question is there a reason you can only "Save" the last one from
> NumberX,NumberY,NumberZ [block pointers, numbers] ? or am I doing something
> wrong? I am using C not C++ for my introspection tool.
>
> I tried using an array but still only NumberZ is saved the others are
> lost. . I placed some printfs and for some reason every time the array
> is initialized after it returns the NumberX, NumberY.
>
> Thanks a lot for your time and help,
> Efstratios
>
> On Mon, Nov 16, 2015 at 3:23 AM, Pasquale Rinaldi <pjr...@gm...>
> wrote:
>
>> Efstratios,
>>
>> Check out this function on a program I am working on which incorporates
>> the sleuthkit c library functions. I calculate the direct block addresses
>> and store this value in my db table. The functions to look at are
>> "BlockFile", "GetBlockAddress" and the "tsk_fs_file_walk" functions. They
>> are on lines: 517-588.
>>
>>
>> https://github.com/pjrinaldi/wombatforensics/blob/master/wombatfunctions.cpp
>>
>> I hope it helps.
>> Pasquale
>>
>> On Sat, Nov 14, 2015 at 12:25 PM, Efstratios Skleparis <
>> esk...@gm...> wrote:
>>
>>> Dear all,
>>>
>>> I am using Sleuth kit library in order to write an introspection tool
>>> for *XEN* hypervisor running on ubuntu 12.04.5 x64bit and my question
>>> is if we have the inode number of a file on a disk [ guest VM - *ext4*
>>> filesystem], for example 6031126 and want to handle the *direct block
>>> pointers of a file/directory* later in a program,how can we get
>>> them(Direct Blocks : *NumberX*,*NymberY* etc) ? I used the sleuth kit
>>> function *istat* inside my program like on istat.cpp program of the
>>> library:
>>>
>>> if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
>>> tsk_error_print(stderr);
>>> fs->close(fs);
>>> img->close(img);
>>> exit(1);
>>> }
>>>
>>> to get information about this inode and i got this :
>>>
>>> inode: 6031126
>>> Allocated
>>> Group: 736
>>> Generation Id: 3880935525
>>> uid / gid: 1000 / 1000
>>> mode: rrw-------
>>> Flags: Extents,
>>> size: 6613
>>> num of links: 1
>>>
>>> Inode Times:
>>> Accessed:   2015-11-12 17:47:55.857360000 (EET)
>>> File Modified:  2015-03-27 14:05:13.000000000 (EET)
>>> Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
>>> File Created:   2015-07-12 00:51:07.489188000 (EEST)
>>>
>>> Direct Blocks:
>>> 24172552 24172553
>>>
>>> I know the block numbers by calling that function but i don't know where
>>> they are stored and how to retrieve them in a variable..? in order to use
>>> them later in my tool!
>>>
>>> Any tips/suggestions or documentation would be appreciated!
>>> Thanks in advance!
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>>>
>>>
>>
>

Re: [sleuthkit-users] Get direct blocks pointers for files/dirs

[Efstratios S. <esk...@gm...>]

Pasquale,

Thanks a lot for the information you provided me :-) I finally managed to
get the direct block pointers of a file !!

That if(flags & TSK_FS_BLOCK_FLAG_CONT) did the work, on GetBlockAddress
function! :-)

My question is there a reason you can only "Save" the last one from
NumberX,NumberY,NumberZ [block pointers, numbers] ? or am I doing something
wrong? I am using C not C++ for my introspection tool.

I tried using an array but still only NumberZ is saved the others are lost.
. I placed some printfs and for some reason every time the array
is initialized after it returns the NumberX, NumberY.

Thanks a lot for your time and help,
Efstratios

On Mon, Nov 16, 2015 at 3:23 AM, Pasquale Rinaldi <pjr...@gm...>
wrote:

> Efstratios,
>
> Check out this function on a program I am working on which incorporates
> the sleuthkit c library functions. I calculate the direct block addresses
> and store this value in my db table. The functions to look at are
> "BlockFile", "GetBlockAddress" and the "tsk_fs_file_walk" functions. They
> are on lines: 517-588.
>
>
> https://github.com/pjrinaldi/wombatforensics/blob/master/wombatfunctions.cpp
>
> I hope it helps.
> Pasquale
>
> On Sat, Nov 14, 2015 at 12:25 PM, Efstratios Skleparis <
> esk...@gm...> wrote:
>
>> Dear all,
>>
>> I am using Sleuth kit library in order to write an introspection tool for
>> *XEN* hypervisor running on ubuntu 12.04.5 x64bit and my question is if
>> we have the inode number of a file on a disk [ guest VM - *ext4*
>> filesystem], for example 6031126 and want to handle the *direct block
>> pointers of a file/directory* later in a program,how can we get
>> them(Direct Blocks : *NumberX*,*NymberY* etc) ? I used the sleuth kit
>> function *istat* inside my program like on istat.cpp program of the
>> library:
>>
>> if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
>> tsk_error_print(stderr);
>> fs->close(fs);
>> img->close(img);
>> exit(1);
>> }
>>
>> to get information about this inode and i got this :
>>
>> inode: 6031126
>> Allocated
>> Group: 736
>> Generation Id: 3880935525
>> uid / gid: 1000 / 1000
>> mode: rrw-------
>> Flags: Extents,
>> size: 6613
>> num of links: 1
>>
>> Inode Times:
>> Accessed:   2015-11-12 17:47:55.857360000 (EET)
>> File Modified:  2015-03-27 14:05:13.000000000 (EET)
>> Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
>> File Created:   2015-07-12 00:51:07.489188000 (EEST)
>>
>> Direct Blocks:
>> 24172552 24172553
>>
>> I know the block numbers by calling that function but i don't know where
>> they are stored and how to retrieve them in a variable..? in order to use
>> them later in my tool!
>>
>> Any tips/suggestions or documentation would be appreciated!
>> Thanks in advance!
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>>
>>
>

Re: [sleuthkit-users] Get direct blocks pointers for files/dirs

[Pasquale R. <pjr...@gm...>]

Efstratios,

Check out this function on a program I am working on which incorporates the
sleuthkit c library functions. I calculate the direct block addresses and
store this value in my db table. The functions to look at are "BlockFile",
"GetBlockAddress" and the "tsk_fs_file_walk" functions. They are on lines:
517-588.

https://github.com/pjrinaldi/wombatforensics/blob/master/wombatfunctions.cpp

I hope it helps.
Pasquale

On Sat, Nov 14, 2015 at 12:25 PM, Efstratios Skleparis <esk...@gm...
> wrote:

> Dear all,
>
> I am using Sleuth kit library in order to write an introspection tool for
> *XEN* hypervisor running on ubuntu 12.04.5 x64bit and my question is if
> we have the inode number of a file on a disk [ guest VM - *ext4*
> filesystem], for example 6031126 and want to handle the *direct block
> pointers of a file/directory* later in a program,how can we get
> them(Direct Blocks : *NumberX*,*NymberY* etc) ? I used the sleuth kit
> function *istat* inside my program like on istat.cpp program of the
> library:
>
> if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
> tsk_error_print(stderr);
> fs->close(fs);
> img->close(img);
> exit(1);
> }
>
> to get information about this inode and i got this :
>
> inode: 6031126
> Allocated
> Group: 736
> Generation Id: 3880935525
> uid / gid: 1000 / 1000
> mode: rrw-------
> Flags: Extents,
> size: 6613
> num of links: 1
>
> Inode Times:
> Accessed:   2015-11-12 17:47:55.857360000 (EET)
> File Modified:  2015-03-27 14:05:13.000000000 (EET)
> Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
> File Created:   2015-07-12 00:51:07.489188000 (EEST)
>
> Direct Blocks:
> 24172552 24172553
>
> I know the block numbers by calling that function but i don't know where
> they are stored and how to retrieve them in a variable..? in order to use
> them later in my tool!
>
> Any tips/suggestions or documentation would be appreciated!
> Thanks in advance!
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

[sleuthkit-users] Get direct blocks pointers for files/dirs

[Efstratios S. <esk...@gm...>]

Dear all,

I am using Sleuth kit library in order to write an introspection tool for
*XEN* hypervisor running on ubuntu 12.04.5 x64bit and my question is if we
have the inode number of a file on a disk [ guest VM - *ext4* filesystem],
for example 6031126 and want to handle the *direct block pointers of a
file/directory* later in a program,how can we get them(Direct Blocks :
*NumberX*,*NymberY* etc) ? I used the sleuth kit function *istat* inside my
program like on istat.cpp program of the library:

if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
tsk_error_print(stderr);
fs->close(fs);
img->close(img);
exit(1);
}

to get information about this inode and i got this :

inode: 6031126
Allocated
Group: 736
Generation Id: 3880935525
uid / gid: 1000 / 1000
mode: rrw-------
Flags: Extents,
size: 6613
num of links: 1

Inode Times:
Accessed:   2015-11-12 17:47:55.857360000 (EET)
File Modified:  2015-03-27 14:05:13.000000000 (EET)
Inode Modified: 2015-07-12 00:51:07.489188000 (EEST)
File Created:   2015-07-12 00:51:07.489188000 (EEST)

Direct Blocks:
24172552 24172553

I know the block numbers by calling that function but i don't know where
they are stored and how to retrieve them in a variable..? in order to use
them later in my tool!

Any tips/suggestions or documentation would be appreciated!
Thanks in advance!

[sleuthkit-users] Basic fls questions

[olcay y. <olc...@gm...>]

Hi,

I am a phd student in forensic science and I have started to work on
tsk/fls about a project. I have some basic questions about fls and I
appreciate if you could answer my questions.

1-) We have a very active ext3 filesystem which has 4 directories inside
it. Around 100 thousand files are created and deleted inside this
filesystem daily. Is it possible to recover filenames (or actual files)
which are deleted more than one year ago?

2-) How long does it last for a command like "fls /dev/sdb1 -p -r -d" to
give an output on the above active filesystem? Since new files are
created/deleted while the fls command runs, how is the fls command affected
with this situation? Does it handle deleted files which are deleted after
the start of its first execution?

3-) Does it have any side effects to run fls on a live filesystem (if we
can not unmount the filesystem)?

4-) Is the evidence admissable in courtrooms which are collected with fls
on live filesystems (without unmounting the filesystem)?

5-) If we use the "-l (long format)" parameter, we can list the
mod_time, acc_time, chg_time and cre_time of the files. Can we trust these
time values? I mean are these time values really belong to the filename
which is listed in the output or is it overriden by other files' time
values?

6-) Can fls detect any anomalies in the filesystem? I mean if someone (with
ill will) changes the system time and adds a file in the filesystem as if
the file was created and deleted at some time in the past, is it possible
to detect this manipulation with fls or with any other forensic tool?

Thanks in advance.

[sleuthkit-users] Autopsy Module Competition Winners

[Brian C. <ca...@sl...>]

At OSDFCon last week, we saw some new Autopsy modules. The winners and links to their modules are listed on the competition page.  The modules included a prefetch analyzer by Mark McKinnon, context adding module (using hash databases) by John Lukach, and OpenPGP detector by Rob Hansen. 

    http://www.osdfcon.org/2015-event/2015-module-development-contest/

thanks,
brian

[sleuthkit-users] Autopsy 4.0.0 is released

[Brian C. <ca...@sl...>]

Autopsy 4.0.0 adds support for multi-user cases. This allows you to have multiple examiners with the same case open at the same time and you can see their updates and results in real-time.  It also has minor bug fixes and enhancements. 

You can download it from here:

    http://www.sleuthkit.org/autopsy/download.php


If you are curious about setting up a multi-user environment, check out the installation instructions here:

    http://www.sleuthkit.org/autopsy/docs/user-docs/4.0/install_multiuser_page.html


thanks,
brian

[sleuthkit-users] Get Direct Block numbers from istat

[Efstratios S. <esk...@gm...>]

Dear all,

I am new into Sleuthkit library and I am trying to write an introspection
tool using Sleuthkit on XEN hypervisor running Ubuntu 12.04 x64 bit and
trying to inspect a guestVM - domU running ubuntu 12.04 x64bit as well ..

After successfuly getting information about an inode given to my program
running the following code :

if (fs->istat(fs, stdout, inum, numblock, sec_skew)) {
tsk_error_print(stderr);
fs->close(fs);
img->close(img);
exit(1);
}

I get as output the following [numblock initialized as 0 , sec_skew as
well] :

Bla bla bla
. . .
. . .
 Direct Blocks : numberX,numberY. .

problem is how can i get those block numbers : numberX and nymberY in order
to use them on my program later? I tried reading many source files [ ntfs.c
where fs->istat is located , fs_block.c , blkstat.c and others ] but it
didn't help me .

Thanks in advance !
Efstratios

Re: [sleuthkit-users] Compiling Framework on 4.2.0

[Roberto M. <rma...@ch...>]

I had posted a question about this on GitHub.
We built a Sleuthkit module and were under the impression that it would be picked up by Autopsy somehow.
I’ve read in several places that Autopsy is a GUI for Sleuthkit, but it seems like it just runs Java/Python plugins.

Is there a way to launch the Sleuthkit module from within Autopsy?

- Roberto




Hi John,

At one point it compiled on Linux.  To be honest though, we don’t use the framework anymore in active development.  We’re using Autopsy for all of those projects.

thanks,
brian


> On Sep 23, 2015, at 4:58 PM, slo.sleuth@... wrote:
>
> Please disregard the Poco error from make.  I failed to notice that the Ubuntu package was poco version 1.3.8.  I installed poco 1.6 from source and compiled the framework successfully.
>
> On Wed, Sep 23, 2015 at 1:11 PM, slo.sleuth@... <slo.sleuth@...> wrote:
> I have never installed the framework under linux, but it appears it is possible.  However, I get the following error on ./configure



Roberto Machorro   Software Development, Child Rescue Coalition
Email: rma...@ch...<mailto:ww...@ch...>
Address: 4530 Conference Way South
Boca Raton, FL  33431

[sleuthkit-users] Online Training

[Brian C. <ca...@sl...>]

The online training is less than 1 month away if you were interested in attending the new course.  We’ll be doing a join online and in person training on Oct 29 (the day after OSDFCon in Herndon, VA).  Sorry to the non-US folks for whom the 9-5 hours (Eastern) are not entirely convenient.   We’ve been thinking about recording this to make it available for other uses. 

Registration details are available at:

   http://www.basistech.com/digital-forensics/autopsy/training/

The 1-day course provides hands-on experience with Autopsy.  We cover the basic concepts of the tool and how each module works.  We assume that you have a background in forensics and we do not cover basic investigation concepts.  At the end of this course attendees will be able to use Autopsy 3 to execute an end-to-end digital investigation on a hard drive and understand the best practices when using Autopsy for optimal results.

thanks,
brian

Re: [sleuthkit-users] Autopsy Question - ZIP files that can't be opened

[Brian C. <ca...@sl...>]

I’m not sure that task management requires a multi-user system if a single person is working a case on a single analysis computer.

That being said, version 4 (released at OSFCon in a month) will have multi-user support!  Using PostgreSQL though and not MySQL.  It will also work in basic stand-alone, SQLite mode too though, so you don’t need to setup the centralized infrastructure.





> On Sep 28, 2015, at 11:05 PM, Simson Garfinkel <si...@ac...> wrote:
> 
> Brian,
> 
> Interesting files seems like a fine approach.
> 
> If you are going to add task management, then are you going to allow it to host on MySQL and have multi-user support?
> 
> Pretty soon, you will have re-implemented PyFlag...
> 
> 
>> On Sep 28, 2015, at 10:44 PM, Brian Carrier <ca...@sl...> wrote:
>> 
>> Flagging the file so that it is in the tree for easy follow on analysis seems to be a common theme with the suggestions.
>> 
>> We could do a few things:
>> 1) Make a new artifact, such as “TSK_FILE_CANNOT_OPEN” that could have a description that says why.
>> 
>> 2) Use the generic “TSK_INTERESTING_FILES” artifact with a set name that is why it could not be opened. 
>> — For those who have not used the Interesting Files module yet, it exists to flag files that meet certain criteria and there is a special section in the tree for them. 
>> 
>> They are both equivalent.  Any strong opinions?
>> 
>> This is also making me think about adding “task management” to Autopsy to help people track what needs to be done because it occurred to me that we could also make “tasks” to help you track which of the unsupported files that you have looked at yet or not. We could do this either with specially named tags (that can be deleted or moved to different “priorities”) or a new data type.
>> 
>> Is this task tracking of interest?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Sep 24, 2015, at 4:14 PM, Derrick Karpo <dk...@gm...> wrote:
>>> 
>>> I don't mind the log message with an additional pop up in the lower
>>> right.  That works for me.  I don't recall but, are those problematic
>>> files marked somehow so that we can manually examine them after
>>> without digging through the log to identify them?
>>> 
>>> Derrick
>>> 
>>> 
>>> On Thu, Sep 24, 2015 at 1:57 PM, Simson Garfinkel <si...@ac...> wrote:
>>>> I think that there should be a general "alert" framework where any scanner can post processing alerts, and have them show up in the results like other results.
>>>> 
>>>>> On Sep 24, 2015, at 3:50 PM, Brian Carrier <ca...@sl...> wrote:
>>>>> 
>>>>> Autopsy will sometimes encounter allocated ZIP files that cannot be opened by 7Zip (or other tools).  We’re currently creating a log message, but no one probably sees though.   Would you rather that we pop up an error message in the lower right?  I’d suggest this only be done for allocated files rather than deleted files (that could be corrupt).
>>>>> 
>>>>> Opinions?
>>>>> 
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> sleuthkit-users mailing list
>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>>> http://www.sleuthkit.org
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> sleuthkit-users mailing list
>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>> http://www.sleuthkit.org
>>> 
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org