COMP 4027 Macs, Unix and Forensics

1. COMP 4027Macs, Unix and Forensics This module draws on Introduction to Unix for forensic examiners [electronic resource] / Warren G. Kruse II, Jay G. Heiser and Guide to Computer Forensics and Investigations by Nelson et al

2. Learning Objectives • Understand Macintosh Disk Structures • Explore Macintosh Boot Tasks • Examine UNIX and Linux Disk Structures • Understand UNIX and Linux Boot Processes • Examine Compact Disk (CD) Data Structures • Understand Other Disk Structures

3. Understand Macintosh File Structure Berkeley Software Design (BSD) UNIX – A variation of UNIX created at the University of California at Berkeley.

4. Understand Macintosh File Structure Hierarchical File System – The system used by the MAC OS to store files, consisting of folders and subfolders, which can be nested.

5. Understand Macintosh File Structure File Manager – In Macintosh file system, it handles the reading, writing, and storage of data to physical media. It also collects data to maintain the HFS along with manipulation of files, folders, and volumes.

6. Understand Macintosh File Structure Finder – Works with the Macintosh OS to keep track of files and maintain the user’s desktop.

7. Understand Macintosh File Structure Data Fork – The part of the Macintosh file structure that contains the actual data of a file. Resource Fork – The part of the Macintosh file system that contains the resource map, header information for the file, window locations, and icons.

8. Understand Macintosh File Structure

9. Understand Macintosh File Structure • The resource fork contains the following information: • Resource map • Resource header information for each file • Window locations • Icons

10. Understand Macintosh File Structure Volume – Refers to any storage media in the Macintosh file system. A volume can be a single floppy disk, a partition on a hard drive, the entire drive, or several drives.

11. Understand Macintosh File Structure

12. Understand Macintosh File Structure Allocation Blocks – The number of logical blocks assembled in the Macintosh file system when a file is saved. Logical Blocks – In the Macintosh file system, a collection of data that cannot exceed 512 bytes. These are assembled in allocation blocks to store files.

13. Understand Macintosh File Structure

14. Understand Macintosh File Structure Logical EOF – In the Macintosh file system, the number of bytes that contain data. Physical EOF – In the Macintosh file system, the number of allocation blocks assigned to the file.

15. Understand Macintosh File Structure

16. Understand Macintosh File Structure Clumps – In the Macintosh file system, a contiguous allocation block. Clumps are used to keep file fragmentation to a minimum.

17. Explore Macintosh Boot Tasks Master Directory Block (MDB) – On older Macintosh systems, the location where all information about a volume is stored. A copy of the MDB is kept in the next to the last block on the volume. Volume Information Block (VIB) – Another name for the Master Directory Block.

18. Explore Macintosh Boot Tasks Extents Overflow File – Used by the Macintosh File Manager when the list of contiguous blocks of a file becomes too long. The overflow of the list is placed in the extents overflow file. Any file extents not in the MDB or VCB are contained here.

19. Explore Macintosh Boot Tasks Volume Control Block (VCB) – Contains information from the MDB and is used by the File Manager in the Macintosh file system. Catalog –Is used to maintain the relationships between files and directories on a volume. Volume Bitmap – Tracks each block on a volume. B*-Tree –Organizes the directory hierarchy and file block mapping for the File Manager. Header Node – Stores information about the B*-Tree file.

20. Explore Macintosh Boot Tasks Index Node – Stores link information to the previous node and the next node. Map Node – Stores a node descriptor and a map record. Leaf Node – A node in the B*-Tree system that contains data in the Macintosh file system.

21. Examining UNIX and Linux Disk Structures GNU General Public License (GPL) – Define Linux as open source software, meaning that anyone can use and distribute the software without owing royalties or licensing fees to another party.

22. Examining UNIX and Linux Disk Structures

23. Examining UNIX and Linux Disk Structures

24. Examining UNIX and Linux Disk Structures Second Extended File System (Ext2fs) – Standard Linux file system. Can support disks as large as 4 TB and files as large as 2 GB.

25. Examining UNIX and Linux Disk Structures

26. Examining UNIX and Linux Disk Structures Meta Data – Includes items such as the user ID (UID), group ID (GID), size, and permission for each file. Data – The contents of a file in the Linux file structure. Data Block – In the Linux file system, a cluster of hard disk sectors, normally 4096 or 8192 bytes in size.

27. Examining UNIX and Linux Disk Structures

28. Examining UNIX and Linux Disk Structures Inode – information node Bad Block Inode – The inode that tracks the bad sectors on a drive.

29. Examining UNIX and Linux Disk Structures • An assigned inode contains the following information about a file or directory: • The mode and type of the file or directory. • The number of links to a file or directory. • The UID and GID of the file’s or directory’s owner. • The number of bytes contained in the file or directory. • The file’s or directory’s last access time and last modified time. • The inode’s last file status change time.

30. Examining UNIX and Linux Disk Structures • Continued... • The block address for the file data. • The indirect, double indirect, and triple indirect block addresses for the file data. • Current usage status of the inode. • The number of actual blocks assigned to the file. • File generation number and version number. • The continuation inodes link.

31. Examining UNIX and Linux Disk Structures

32. Examining UNIX and Linux Disk Structures

33. Examining UNIX and Linux Disk Structures

34. Examining UNIX and Linux Disk Structures

35. Examining UNIX and Linux Disk Structures

36. Understanding UNIX and Linux Boot Process • ROM loads instructions. • Instruction code checks hardware. • Boot device and kernel are located. • Kernel is executed and detects devices. • Kernel loads processes and identifies the root directory, swap file, and dump file. • Information such as time zone, hostname, network services, and partitions are started.

37. Understanding UNIX and Linux Boot Process Linux Loader (LILO) – Linux utility that initiates the boot process which usually runs from the master boot record (MBR).

38. Linux and forensics You could make an image : • dd if=practical.floppy.dd of=/dev/fd0 Youcould make a directory to keep evidence: • mkdir ~/evidence

39. Linux and forensics • There are simple tools available for determining the structure of a disk attached to your system. Replace the “x” with the letter of the drive that corresponds to the subject drive. • fdisk –l /dev/hdx • Disk /dev/hda: 255 heads, 63 sectors, 1582 cylinders • Units = cylinders of 16065 * 512 bytes • Device Boot Start End Blocks Id System • /dev/hda1 1 255 2048256 b Win95 FAT32 • /dev/hda2 * 256 638 3076447+ 83 Linux • /dev/hda3 639 649 88357+ 82 Linux swap • /dev/hda4 650 1582 7494322+ f Win95 Ext'd (LBA) • /dev/hda5 650 1453 6458098+ b Win95 FAT32 • /dev/hda6 1454 1582 1036161 b Win95 FAT

40. Linux and forensics • You can make an image of a suspect disk. Execute the command from within the /root/evidence/ directory: • dd if=/dev/fd0 of=image.disk1 bs=512 • This takes your floppy device (/dev/fd0) as the input file (if) and writes the output file (of) called image.disk1 in the current directory (/root/evidence/). • The bs option specifies the block size. This is really not needed for most block devices (hard drives, etc.) as the Linux kernel handles the actual block size. It’s added here for illustration • You may change the read-write permissions of your image to read-only. • chmod 444 image.disk1 • The 444 gives all users read-only access.

41. Linux and forensics • If you have created an image file, you can restore the image to another disk for analysis and viewing. Put another (blank) floppy in and type: • dd if=image.disk1 of=/dev/fd0 bs=512 • This is the same as the first dd command, only in reverse.

42. Linux and forensics • Mounting a restored image • Mount the restored (cloned) working copy and view the contents. • mount -t vfat -o ro,noexec /dev/fd0 /mnt/analysis • This will mount your working copy (the new floppy you created from the forensic image) on “/mnt/analysis”. The “–o ro,noexec” specifies the options ro (read-only) and noexec (prevents the execution of binaries from the mount point) in order to protect the disk from you, and your system (and mountpoint) from the contents of the disk.

43. Linux and forensics • Another way to view the contents of the image without having to restore it to another disk is to mount using the loop interface. Basically, this allows you to “mount” a file system within an image file (instead of a disk) to a mount point and browse the contents. • mount -t vfat -o ro,noexec,loop image.disk1 /mnt/analysis

44. Linux and forensics We can use Linux to get a file hash: • sha1sum /dev/fd0 Or • md5sum/dev/fd0 • You can also use Linux to do your verification for you. To verify that nothing has been changed on the original floppy, you can use the -c option with sha1sum. If the disk was not altered, the command will return “ok”. • Type: • sha1sum -c /root/evidence/SHA.disk1 • Output should be “OK”

45. Analysis with Linux • Navigate through the directories and see what you can find. The ls command in the following form might be useful: • ls –al • This will show all the hidden files (-a), give the list in long format to identify permission, date, etc. (-l). You can also use the –R option to list recursively through directories.

46. Analysis with Linux Making a list of all files • List of all the files and their owners and permissions on the suspect disk. For example, you could use the –i option to include the inode in the list, the –u option can be used so that the output will include and sort by access time (when used with the –t option). • ls –laiRtu > /root/evidence/file.list

47. Analysis with Linux Making a list of file types • What if you are looking for JPEG’s but the name of the file has been changed, or the extension is wrong? You can also run the command file on each file and see what it might contain. • file filename • The file command compares each file’s header (the first few bytes of a raw file) with the contents of the “magic” file (usually found in /usr/share/magic). It then outputs a description of the file.

48. Analysis with Linux Viewing files • For text files and data files, you might want to use cat, more or less to view the contents. • cat filename and more filename Searching unallocated and slack space for text • Create text file ‘searchlist.txt’ with search string: • $50,000, ransom, unleash a virus • Use grep • grep –aibf searchlist.txt image.disk1 > hits.txt

49. Using Sleuth Kit • The Sleuthkit’s tools are organized by what the author calls a “layer” approach. • File system layer – fsstat, • File name layer – fls, ffind • Content (data) layer – dcalc, dcat, dls, dstat • Meta data (inode) layer – icat, ils, ifind, istat • Notice that the commands that correspond to the analysis of a given layer begin with a common letter. For example, the file system command starts with “fs”, and the inode layer commands start with “i”.

50. Sleuthkit • Run on a partition called able2 • ./fsstat /root/able2/able2.part2.dd • InCompat Features: Filetype, • Read Only Compat Features: Sparse Super, • META-DATA INFORMATION • -------------------------------------------- • Inode Range: 1 - 12880 • Root Directory: 2 • CONTENT-DATA INFORMATION • -------------------------------------------- • Fragment Range: 0 - 51299 • Block Size: 1024 • Fragment Size: 1024 • ....