Re: [sleuthkit-developers] regression bug in sleuthkit iso9660

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

Hi Michael,

Someone reported this a little while ago and I fixed it as you  
suggested.  I force it to the big endian layout with:

     tmpguess[0] = 0;
     tmpguess[1] = 0;
     tmpguess[2] = 0;
     tmpguess[3] = 1;
     tsk_fs_guessu32(fs, tmpguess, 1);

The idea of notifying if the different orderings are different is an  
interesting one.

thanks,
brian

On Jun 23, 2008, at 7:08 AM, Michael Cohen wrote:

> Hi All,
>   There seems to be a regression bug in sk iso9660 handling. The
> problem started during version 2.10 (i.e. 2.09 worked correctly).
> Version 2.09 defines the following macro:
>
> #define parseu32(foo, x) \
>     (uint32_t)( (foo->endian & TSK_LIT_ENDIAN)  ? \
>     ((uint32_t) \
>         ((uint32_t)((uint8_t *)(x))[0] << 0) + \
>         ((uint32_t)((uint8_t *)(x))[1] << 8) + \
>         ((uint32_t)((uint8_t *)(x))[2] << 16) + \
>         ((uint32_t)((uint8_t *)(x))[3] << 24)) \
>         : \
>     ((uint32_t) \
>         ((uint32_t)((uint8_t *)(x))[7] << 0) + \
>         ((uint32_t)((uint8_t *)(x))[6] << 8) + \
>         ((uint32_t)((uint8_t *)(x))[5] << 16) + \
>         ((uint32_t)((uint8_t *)(x))[4] << 24)) )
>
> Note that x is an unsigned char [8]. In particular this is called from
> iso9660_open as:
> fs->block_count = parseu32(fs, iso->pvd->pvd.vol_spc)
>
> In sk 2.10 the primary volume descriptor was redefined to have better
> granularity. In particular the volume size was split into 2 parts:
>
>     uint8_t vs_sz_l[ISODCL(81, 84)];    /* volume space size in  
> blocks - le */
>     uint8_t vs_sz_m[ISODCL(85, 88)];    /* volume space size in  
> blocks - be */
>
> presumable the iso header specifies the same quantity both in big and
> little endian. iso9660_open then goes to calculate the block_count as:
>
> if (iso->pvd) {
>         fs->block_size = tsk_getu16(fs->endian, iso->pvd- 
> >pvd.blk_sz_m);
>         fs->block_count = tsk_getu32(fs->endian, iso->pvd- 
> >pvd.vs_sz_m);
>     }
>
> This is wrong now because fs->endian can be big or little presumably,
> but iso->pvd->pvd.vs_sz_m is always big endian. The correct call
> should be (or equally we can choose the big endian version too):
> if (iso->pvd) {
>         fs->block_size = tsk_getu16(TSK_LIT_ENDIAN, iso->pvd- 
> >pvd.blk_sz_l);
>         fs->block_count = tsk_getu32(TSK_LIT_ENDIAN, iso->pvd- 
> >pvd.vs_sz_l);
>     }
>
> That is we should just pick an endianess and use the corresponding
> vs_sz_X.  I guess from a forensic pov what if they say different
> things? Presumably the os which mounts it would only look at either
> the big endian version or the little endian version. Maybe this can
> result in a disk which shows more files if mounted on a big endian
> machine vs a little endian machine???  Maybe SK should issue warnings
> if the fields contradict.
>
> Michael.
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers