Re: [sleuthkit-users] weirdness in file_act callback when reading $OrphanFiles/OrphanFile-56231 from Honeynet scan15

[Simson G. <si...@ac...>]

Hi, Brian. Thanks for the information. I will document in my code that  
sector #0 is a magical sector which indicates "all nulls".  I'm  
wondering what is the best way to represent this in the XML that I'm  
generating, though, since the byte run doesn't really have a starting  
point, just a length.

Perhaps this would make more sense:

<byte_runs>
<run start='235197440' len='12288'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='1024'/>
<run fill='0' len='367'/>
</byte_runs>

What do you think?

Thanks for the information about the other flags. I'll need to figure  
out what to do about them.

I will have a draft of the XML paper ready in a few weeks. I'll post  
it to this list.



On Dec 29, 2008, at 10:19 AM, Brian Carrier wrote:

> Hi Simson.  Sorry for the delay.  I was away last week.  The  
> behavior you are seeing is expected, but you did show me a bug in  
> 'istat'.  The fix is checked in.
>
> Address 0 is reserved in ExtX and FFS to denote a "sparse" block  
> (one which is all zeros).  TSK knows this and returns zeros when a  
> file refers to block 0.  The bug was that 'istat' was not displaying  
> the 0 entries.  You can check the 'flags' argument to the callback  
> to determine if the data is from sparse or compressed data. RAW  
> means that the data in the buffer was read from the disk.
>
> TSK_FS_BLOCK_FLAG_RAW
> TSK_FS_BLOCK_FLAG_SPARSE
> TSK_FS_BLOCK_FLAG_COMP
>
> brian
>
>
>
> On Dec 22, 2008, at 4:05 PM, Simson Garfinkel wrote:
>
>> I'm finding that the third argument (TSK_OFF_T a_off) of my  
>> file_act()
>> callback for tsk_fs_file_walk is not being set properly for some of
>> the calls when attempting to access  $OrphanFiles/OrphanFile-56231 of
>> Honeynet scan15.
>>
>> You can download the scan from   http://old.honeynet.org/scans/ 
>> scan15/
>>
>> I'm looking at inode 56231:
>>
>> r/r * 56231:	$OrphanFiles/OrphanFile-56231
>>
>> It's an orphan file:
>>
>> 12:52 PM m:~/honeynet$ istat honeypot.hda8.dd  56231
>> inode: 56231
>> Not Allocated
>> Group: 28
>> Generation Id: 2386177400
>> uid / gid: 0 / 0
>> mode: rrw-r--r--
>> size: 33135
>> num of links: 0
>>
>> Inode Times:
>> Accessed:	Thu Mar 15 03:17:36 2001
>> File Modified:	Thu Mar 15 03:17:36 2001
>> Inode Modified:	Thu Mar 15 03:17:36 2001
>> Deleted:	Thu Mar 15 03:17:36 2001
>>
>> Direct Blocks:
>> 229685 229686 229687 229688 229689 229690 229691 229692
>> 229693 229694 229695 229696
>> 12:53 PM m:~/honeynet$
>>
>>
>> icat does give me 33135 bytes:
>>
>> 12:53 PM m:~/honeynet$ icat honeypot.hda8.dd  56231 |wc
>>        0       1   33135
>> 12:53 PM m:~/honeynet$
>>
>>
>> i have a program called fiwalk which takes the output of TSK and  
>> turns
>> it into easy-to-use XML. Here is the XML for this orphan file:
>>
>> <filename>$OrphanFiles/OrphanFile-56231</filename>
>> <byte_runs><run start='235197440' len='12288'/><run start='0'
>> len='1024'/><run start='0' len='1024'/><run start='0' len='1024'/ 
>> ><run
>> start='0' len='1024'/><run start='0' len='1024'/><run start='0'
>> len='1024'/><run start='0' len='1024'/><run start='0' len='1024'/ 
>> ><run
>> start='0' len='1024'/><run start='0' len='1024'/><run start='0'
>> len='1024'/><run start='0' len='1024'/><run start='0' len='1024'/ 
>> ><run
>> start='0' len='1024'/><run start='0' len='1024'/><run start='0'
>> len='1024'/><run start='0' len='1024'/><run start='0' len='1024'/ 
>> ><run
>> start='0' len='1024'/><run start='0' len='1024'/><run start='0'
>> len='367'/></byte_runs>
>> <md5>3bfc6509b2fba0d38c09342ab5c0cfe5</md5>
>> <sha1>8f980058a1b15a40b08c0514db38c212b68f24d4</sha1>
>> <fragments>22</fragments>
>> <frag1startsector>229685</frag1startsector>
>> <frag2startsector>0</frag2startsector>
>> </fileobject>
>>
>> the start is from the beginning of the disk, which is conveniently  
>> the
>> beginning of the file system.
>>
>> As you can see, TSK tells me that there are multiple runs, each  
>> with a
>> starting byte offset of 0.
>>
>> I've instrumented the callback:
>>
>> TSK_WALK_RET_ENUM
>> file_act(TSK_FS_FILE * fs_file, TSK_OFF_T a_off, TSK_DADDR_T addr,
>> char *buf,
>>          size_t size, TSK_FS_BLOCK_FLAG_ENUM flags, void *ptr)
>> {
>>     content *ci = (content *)ptr;
>>
>>     if(opt_debug){
>>         printf("file_act(fs_file=%p,addr=%"PRIuDADDR" buf=%p size=%d)
>> \n",
>>                fs_file,addr,buf,(int)size);
>>         if(opt_debug>1 && ci->segs.size()==0){
>>             (void)fwrite(buf,size,1,stdout);
>>             printf("\n");
>>         }
>>     }
>>
>>
>> And this is what I'm getting:
>>
>> Processing $OrphanFiles/OrphanFile-56231
>> file_act(fs_file=0x502f10,addr=229685 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229686 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229687 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229688 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229689 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229690 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229691 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229692 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229693 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229694 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229695 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=229696 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=1024)
>> file_act(fs_file=0x502f10,addr=0 buf=0x804600 size=367)
>>
>> I've determined the TSK is NOT reading sectors 0 and 1 to satisfy the
>> callback (I put test data in sector 1 and it didn't show up when I
>> icat the file.)
>> 	
>>
>> Any clues?
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>