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
|
