Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pytsk/libtsk: overlapping partition slots #70

Open
joachimmetz opened this issue Jan 16, 2021 · 2 comments
Open

pytsk/libtsk: overlapping partition slots #70

joachimmetz opened this issue Jan 16, 2021 · 2 comments

Comments

@joachimmetz
Copy link
Member

mmls mbr_512_single_primary.raw 
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   0000000000   0000000001   Unallocated
002:  000:000   0000000001   0000000129   0000000129   Linux (0x83)
003:  -------   0000000130   0000008191   0000008062   Unallocated

Partition slots can overlap and the reason for this is unclear. Filed sleuthkit/sleuthkit#2123 to get more context.

@joachimmetz
Copy link
Member Author

joachimmetz commented Aug 21, 2021

Maybe status value can be of help here?

mac_load: 0  Starting Sector: 1  Size: 63 Type: Apple_partition_map Status: 3
mac_load: 1  Starting Sector: 64  Size: 8112 Type: Apple_HFS Status: 1073741875
mac_load: 2  Starting Sector: 8176  Size: 16 Type: Apple_Free Status: 0
MAC Partition Map
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  -------   0000000000   0000000000   0000000001   Unallocated
001:  000       0000000001   0000000063   0000000063   Apple_partition_map
002:  Meta      0000000001   0000000003   0000000003   Table
003:  001       0000000064   0000008175   0000008112   Apple_HFS
004:  002       0000008176   0000008191   0000000016   Apple_Free

Does not look like the status value is exposed in TSK_VS_PART_INFO but mapped to flags https://github.com/sleuthkit/sleuthkit/blob/develop/tsk/vs/tsk_vs.h#L93

part.addr, part.desc.decode('utf-8'), part.start, part.len, part.flags
0 Unallocated 0 1 2
1 Apple_partition_map 1 63 1
2 Table 1 3 4
3 Apple_HFS 64 8112 1
4 Apple_Free 8176 16 2

Thought the information might not be sufficiently expressive for all slots e.g. Apple_partition_map would make more sense to be marked as metadata, it does seem to indicate Table is metadata and Apple_Free is "unallocated"

Though the check to determine if a slot is allocated / unallocated seems to be very rudimentary: https://github.com/sleuthkit/sleuthkit/blob/develop/tsk/vs/mac.c#L121

        if (part_status == 0)
            flag = TSK_VS_PART_FLAG_UNALLOC;
        else
            flag = TSK_VS_PART_FLAG_ALLOC;

Where the APM status flags can contain various values https://github.com/libyal/libvsapm/blob/main/documentation/Apple%20partition%20map%20(APM)%20format.asciidoc#status_flags

@joachimmetz
Copy link
Member Author

Same for BSD disklabel

mmls bsd-disklabel.raw 
BSD Disk Label
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  002       0000000000   0000008191   0000008192   Unused (0x00)
001:  Meta      0000000001   0000000001   0000000001   Partition Table
002:  000       0000000016   0000008191   0000008176   Unused (0x00)
disk -t bsd -l bsd-disklabel.raw
Disk bsd-disklabel.raw: 4 MiB, 4194304 bytes, 8192 sectors
Geometry: 1 heads, 63 sectors/track, 130 cylinders
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: bsd

Slice Start   End Sectors Size Type     Fsize Bsize Cpg
a        16  8191    8176   4M unused       0     0   0
c         0  8191    8192   4M unused       0     0   0

Partition table entries are not in disk order.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant