When Mac deletes it!

Disclaimer: Information presented here may have inaccuracies. Please don't expect otherwise.

Introduction: 
 
   This post is going to be a discussion of what happens when you delete a file on a Mac. I'm going to try and give an explanation of what happens "behind the curtains" in the OSX system, and how its filesystem works with the files that pertain to deleted files. That will be here in the beginning part of the post. Whereas the second part will discuss the steps of what exactly happens to a file when it's deleted.

Some of the 9 structures that make up the HFS+ volume to be familiar with. (Also an add on to my Mac Filesystem post):

• Volume header: contains file system attributes, such as the version and the allocation block size, and information to locate the metadata files.
• Allocation file: tracks the usage status of allocation blocks.
• Catalog file: contains the majority of a file and folders metadata in a volume.
• The information stored includes 
• File type - file creator - files location in a window - directory path - finder flags
• Extents overflow file: contains recorded allocation blocks that are allocated to each file as an extents. They contain the records for forks that have more than 8 extents allocated to them.
• Extents based filesystems: Instead of using singular blocks for storing a file, extents use a continuous area of storage reserved for that particular file. So when a file is created the filesystem allocates the data in a volume, and when new data is added to the stored file, it simply continues on where it left off. This helps alleviate file fragmentation.
• Each file record in the Catalog file is capable of recording eight extents for each fork of a file. So once those are used, additional extents are recorded in the Extents Overflow File.
• In NTFS, this involves the resident and non resident files in the MFT records. When a file becomes non-resident, the MFT contains pointers to data runs (also called extents).

• Attributes file: Contains attribute information regarding files and folders. You'll see these used in features like access control lists.

    The reason why i'm refreshing these particular structures is because they are relative to a file when it's deleted. Its a good idea to have a strong understanding of an OS's file system, because it lets us know where and how files are stored. Given these understandings, we can start to connect where to look for remnants of a deleted file and discover attributes that tells us what was in that file and how it was connected to a system. This concept is also applied when simply looking through a file system and remembering file paths for OSX artifacts. But back to an HFS+ volume. Of the 7 categories in a volume, there are two particular ones that are more closely examined when examining the process of a deleted file.

• Journaling: keeps track of the changes to a file. If an individual file is updated, it will result in several related disk updates. This minimizes the chance of losing the changes you've made to a file in a crash. These can involve changes to occur in a Catalog file, Volume Bitmap, Extents overflow, attributes, and the volume header. These being the structures i described earlier. But for now i want to discuss how the Journal file and the Catalog file relate to deleted files.
• Journaling facilitates deleted file content because of its recovery characteristics.
• This methodology allows Journaling to find Catalog file records that represent files that have been deleted from a file system.
• Journaling doesn't just log meta data changes.
• So journaling is somewhat problematic for a forensic investigator only because of the overwhelming information it will contain.

• Catalog File: The catalog file serves many of the same functions as the MFT in NTFS, therefore recovery of a deleted file can be achieved if it's Catalog nodes are found within Journaling. (I don't wanna discuss the ils -a, or any scripts in general that can be used at the command prompt to view a list of these files. Google offers a ton off tutorials on how to run scripts to view content like this. I'm more interested in explaining the "what is" instead of the "how to's".)
• When you want to find metadata information about a deleted file, this is one area it is recorded. And then recorded again in the Journal file :).  This doesn't give information about the actual content of the deleted file, or even it's time of deletion, just its metadata about the files activity prior. Which is a confusing bummer, i know. (The Journal is a more super place to look for a forensicator). I believe you would need to pair a deleted files catalog file to its correlating extents overflow content which is saved separately in order to get a bigger picture of a deleted file. This isn't always possible, depending on how many times the deleted file has been overwritten.
• It's important to note, that all of the structures that i've been talking about will be easily accessible if a deleted file hasn't been permanently deleted yet. Heck, you can just click on the bin and there your work is. Not exactly forensics. But forensic tools will be looking for traces of these structures tossed into unallocated spaces, hoping to salvage the best it can.

• So lets get into the MacOSX trash bin, and it's overwriting ninja skills. I'd understand if what i've been writing about is irrelevant to most, but it was a novice attempt at the technical digging of a deleted file in a filesystem.

    I'm not exactly sure of all the reasons, but i can recall from most of the literature i've read, that it's more difficult to perform forensics in a Mac OS X. I remember a couple years ago when i first began my interest as a computer forensic student, I noticed how difficult it was to find readings on a Mac OSX internals. That being said, it's possible Mac forensics is posing more of a complexity because of the way it allocates blocks of data. Or because of how MacOSX has taken the initiative of reducing file fragmentation, and by doing so, possibly over writing data more often, making it more difficult to recover these files? I really don't know for sure. But Macs seem to be more innate to overwriting the crap out of data.

Trash bin vs. Recycle Bin:
  
    The "Trash" bin is Apples version of the Windows "Recycle" bin. The Mac Trash doesn't automatically empty the trash like the Windows RB. Through what i have read, you can set a limit to the Mac trash bin can so it can then start deleting files automatically, but by default it doesn't do so like Windows. (*Note that regardless how many times you move a file back an forth to a trash bin, OSX preserves the original date and time stamps.)
    You can delete a file in many of the ways you can in Windows. Through the Finder, terminal, or right clicking a file. And just like when you place a file in the trash in Windows, it's not actually going to a new location in the filesytem, it's header is reformatted to unallocated and ready to be written over. 
    The Trash bin is represented as an icon on your desktop. When you have files you want to remove from the trash to Permanently delete, OSX calls this method the "Secure empty trash." Right click the bin and you'll see it. And like i mentioned earlier, OSX has Ninja wiping skills when it comes to overwriting data. OSX contains wiping features that are easy and user friendly, which allow you to wipe parts of a drive. So for now, all i can explain as a difference in a permanent delete with an OSX, is its strong ability to overwrite deleted data with a whole bunch of "junk" data, making evidence harder to find. After you secure empty trash of a bunch of files, you can go to the disk utility where the Erase Free Space options is on your Mac and make sure those deleted files won't be recoverable by writing all those zeros. Thanks Mac.
    Unlike Windows, OSX and Unix based systems in general have a unique way of dealing with external devices. Each storage device that you plug into a Mac, the device will gets its own trash location. I believe on the system as well as on the USB or external device itself. Or a better way to look at it, when plugging a USB into a Mac, OSX creates a number of hidden files on the stick itself, including a Spotlight index and a .Trash folder on the system you're plugging it into (in what exact location i can't say at this moment). I think if external devices get their own volumes in a *nix, there must also be a new .trash folder for that USB on the system you're plugging it into. Here's what happens when deleting files off a USB:

• When you have a USB plugged in, and you drag and drop the items into the trash bin, it doesn't stop there. Because of the hidden Spotlight index that's put directly on the USB device and the new .trash index, your USB may look empty, but it isn't. Say for example if i were to take this USB device i just tried emptying, took it down the street and plugged it into a totally different Macbook, i would be able to recover the hidden trash information on that USB onto the new Macbook.

    External devices aside, when you send a file to the Trash on a Mac, a hidden folder entitled the ".Trash folder", is created and located in the root directory ~/.Trash. And under this root directory there are a few other folders created, one of which being the .DS_Store folder. Remember when dealing with a Windows XP system, when you deleted a file, there is a hidden directory that keeps track of what your deleting called the C:\Recycler. The C:\Recycler folder has an Info2 file inside of it, that gives information about the deleted file. But here in OSX, the hidden directory that keeps track of files sent to the trash is called the .Trash folder, and it too also has a file like the Info2 file called the ".DS_Store" file, which retains information of files in the trash. So OSX = .Trash > .DS_Store, Windows = \Recycler < Info2 file.

• .DS_Store: holds the information that controls the way a folder will be opened, ex: the shape and size of a window, the position of the window on the desktop and whether the file, folder or icon view has been selected. So the OSX Finder assigns these hidden files to all the folders that are accessed by you or someone remotely from another system.
•  In regards to deleted files, the .DS_Store contains information of where the deleted file came from. You can easily determine this by viewing the file in any Hex editor.

Conclusion:
   
    And there you have it. The many digital paths taken, when following deleted files. Although Macs may be great for forensics when it comes to mounting and un-mounting their many volumes to maintain sanitation, Macs are a nightmare when it comes to their wiping capabilities and looking for deleted files. But thanks to Spotlight and the Finder, deleted files are either getting copied and/or a folder index accompanying it.

References
Using the HFS+ journal for deleted file recovery.
Mac OS X, iPod, and iPhone Forensic Analysis Toolkit.
Mac Forensics: Mac OS X and the HFS+ File System.
Digital Forensics with open source tools 2011.

When Windows deletes it!

Disclaimer: Information presented here may have inaccuracies. Turn back while you can.

Introduction:
   
    What function could be more synonymous in Digital Forensics than deleting a file on a computer? The Recycle Bin is where deleted files end up. Done by either the user, or automatically by the system. If the bin is full, windows will start automatically deleting the files. The RB can be accessed either from the desktop icon, or through Windows Explorer (Explorer is where windows allows you to view the contents of your filesystem and where you access files). If you were to click on the desktop icon, you would see the file you deleted with it's original name, path, and date of deletion. It really makes no difference how you navigate to the RB folder, either through the desktop or explorer, you're brought to the same place with the file's original name, date placed, size, and time last modified. It looks normal.
    Each user on a system has their own file RB directory of deleted files, each with their own SID. It is also important to know that each drive has their own $Recycle.Bin. And by drive i mean drive letter. And each partition has it's own drive letter. Example of a drive letter is C:\. C standing for the partition you're currently under. So if there's 3 users and 2 drives, each user will have their own directory on each of the 2 drives.
    An SID is a security identifier that is kinda like a fingerprint paired with each user. Although there are many digital details in DFIR that can be considered a fingerprint for a user. This is one of them. An SID indicates the system a user is using and the level of access it has. In XP systems, SID is only used with the Recycle Bin. This means SID's only show their user ID when connecting deleted files, with what user deleted it. But in Vista and up, SID's are not only used in the RB, but also used with the Registry SAM hives, for all security access controls. (Access control lists). These are valuable to a forensic investigation. They usually look something like this: S-1-5-21-51003140-4199384537-3980697693-500. This naming convention looks like this for XP, Vista, and 7, and is based on the user. The numbers serve a purpose. The 500 at the end is the Relative ID RID, which means the user is a system admin. So just know the numbers indicate level of access and so on.

What happens?
   
    When a file is "deleted" and sent to the Bin, the file doesn't really go anywhere. You're simply nullifying the files access indicators to the Master File Table MFT. Entries within the B-tree of the MFT are not completely removed when a file deletion occurs. They are marked as deleted using a corresponding $BITMAP attribute. All this really means is that a deleted file doesn't really go anywhere, the OS simply has it's own way of letting it know it's been deleted. So the RB is simply a folder that records deletions.
    With this newly deleted file in the RB icon, there is more to it than meets the eye. The reason why people are commonly mistaken (or used to be) with assuming a file is gone when sent to the RB, is because the RB isn't the only thing keeping track of your deletions. How do you think you're able to "Restore" a file when it's sent to the Bin? It's because when you delete a file, there are hidden folders that keep track of these deleted files. And by hidden, i mean they aren't accessible unless you manually configure your system to view these files. I'll touch on these hidden files in a moment.
    When you permanently delete a file (either through a shift+delete or through the command prompt), the file isn't sent to the RB directory, but is now labeled as unallocated. The file is now labeled as "00" which means it is unallocated and ready to be written over. File carving techniques are the only genuine manner in which to re-spawn these files.
    So back to those hidden files. Why are they hidden? Well much like the registry or security access controls, if you go thumbing around in these files, you may cause configuration problems. The OS likes how it keeps things neat, and you don't know how she likes to keep it. And how many times can you remember when you deleted something, and wanted to bring it back to life?
   There are differences between Windows XP and Vista with these hidden files. The differences you'll see will involve the locations of the deleted file and how the path of the file looks. In XP a deleted file is sent to the "RECYCLER" directory, and in Vista/7 a deleted file is brought to the "$Recycle.Bin" directory. Here are what these hidden files will look like:

• Example for XP: C:\Recycler\<USER SID>\INFO2. 
• Example for Vista: C:\$Recycle.Bin\<USER SID>\

Windows XP
   
    Keep in mind when accessing the C:\Recycler\<USER SID>  file with admin rights in Windows Explorer, it will be in a B-tree format. Under Recycler is SID, and under SID is the Info2 file. There is also an accompanying file under SID with the Info2 file that will look something like DC1.txt. These are the two files that retain information of your deleted file in order to bring it back to life. The DC1.txt file is where the actual content of the deleted file is stored in readable text format. Whereas the Info2 file retains the deleted files metadata. Here's a little information of these two files:

INFO2 file: 
   
    The info2 file is basically a secondary index that stores info of deleted files and tracks a file if and when it's moved from the RB. Info2 are hidden files, that stores a files original path and original name in binary format. So if you restore a file from the RB, the system checks the Info2 file to properly restore. When a file is sent to the RB, there is a date and time stamp saved of when this occurred in the info2 file. SO say for example you were looking for a file by it's original name, this is where you would discover it. The Info2 File saves the following:

1. A files full path name
2. Size of file
3. Date and time when deleted
4. The files unique identifying number
5. The drive letter where the file came from 
•  What Info2 looks like in a Hex editor

DC1.txt file:

    The first letter D, will always be the first letter regardless of user or file. So whenever you look for this file in XP, there it will be with the first letter D. C on the other hand refers to the identifying drive in which the file came from. Ex: C:\. The number 1 is the unique identifying number of the deleted file. They are assigned according to what file was deleted before they other. Like the 2nd or 3rd file deleted. An ordering number. Then there is of course the extension, depending on what the original files extension was, will be the extension placed here.

Vista/7
    
    Since the newer versions of Windows no longer uses the Info2 file or the DC1.text file, they've adopted their own method of re-spawing deleted files from the RB. Here is a second look at the new hidden location of deleted files in Vista/7: C:\$Recycle.Bin\<USER SID>\. As you can see the Recycler is renamed to the $Recycle.Bin.
   Before i get into the differences, keep in mind that Vista still assigns a new $Recycle.Bin folder to every user and every user on a new partition. So as i tried explaining up top, if you have 3 drives and 2 users, each user is going to have their own $Recycle.Bin folder on each drive. Equating a total of 6 $Recycle.Bin folders. It's simply their locations, content, and how they save metadata that changes up. And also, SID's are still implemented when connecting a user to a Bin. Just remember when looking through the RB hidden directory and you see an SID, it is representing a RB icon, tied to a specific user. So if you see 2 SID numbers, there are two users with their own RB's.
    And remember how XP had DC1.ext and Info2 within the hidden directories? Well instead of using these two directories to hold the wealth of information, Vista/7 has their own two hidden directories replacing those from XP. The first one you'll see will look something like this: $R<set of 6 random numbers and letters>.<original extension>. Example: $RGDRVPB.txt. This file is similar to the DC1.txt in xp, in that it holds all the textual data that you will find in a deleted file. And unlike in XP, the $R files don't seem to have a ordering convention. They're just placed randomly.
    And the second file accompanying the $R, is the $I file. If you look at this hidden file, you'll see it similar in construction as the $R file. Example $I<six random numbers or letters>.<original ext>. This file is also similar to the Info2 file, but it contains a little less metada. The $I only contains 1. original file name 2. files original size 3. and date and time of when the file was deleted.And unlike the Info2 file, the $I is not in plain readable text.

Concluding pointers:

    So there you have it. Windows recycle bin in all her wonders. But what happens if you are looking for files that were executed in a Permanent delete? Well this is where forensics comes into play. The techniques in which to find this data on a disk include file carving, and string searching. Both these terms generally follow the same methods of looking for a files header and footer, and then "carving" out these two blocks of information to use in comparison of finding them on a disk. Although i probably shouldn't have listed string searching, because that kinda applies to searching any type of file on a disk, not just the deleted ones. Carving of course can be more specific in definition. Meaning you can select certain sectors in a search. But if you want to a tool to find a deleted file, headers is what they look for. And then there is carving with fragmented files, when a footer isn't available. This poses an issue. And that's really as far as my brain can go. I think this would entail the body of the file, when conducting a search.
   Most of these tools are presented in an easy to use GUI environment, and do the heavy lifting of searching for these headers and footers in unallocated space. And also, when using these techniques of searching for deleted files, it isn't a guarantee you'll find what you're looking for. Aside from file damage and corrupted errors, there exists the problem of anti-forensics, with things like stenography, data hiding, or file signature forging.
   There is also an important area of data that should be considered when you're looking for lost files from the Recycle Bin. The Volume Shadow Copy Service VSS, is away Windows periodically creates backups from parts of your system, so in cases where it's need, can restore information from the restore points. But back to the Recycle Bin. Fortunately for an ininvestigator,  the RB is no exception to the VSS backups, and could include information regarding deleted files from the past. There is an article referencing this topic entitled, "Shadow Volume Trash", by Timothy Leschke. He has a few forensic articles out there, one of which was the main reference of me writing this article.

References
"Cyber dumpster diving". Timothy R. Leschke.
"Windows Forensic Analysis". Harlan Carvey.
Dereknewton.com. Derek Newton.
Image of Info2 in hex, by Steve Hailey.


   

Mac vs Windows Encryption 101

Introduction: This post will be a basic introduction to the common encryption formats used on Mac and Windows operating systems. Defeating drive encryption is an extensive struggle that should be analyzed in depth when studying Memory Forensics.

Windows

BitLocker

• Is a full volume encryption feature from Vista to Win7, and now even Win8.
•  A volume may or may not be the entire disk.
• There are also server editions.
• In Win7 you can encrypt USB drives. (Bitlocker To Go).

• Encrypts all personal and system files on the operating system drive.
• Unlike EFS which doesn't encrypt the entire contents of the drive.
• Bitlocker does not depend on each user assigned to a computer to encrypt a full drive.
• According to Microsoft sources, Bitlocker does not contain an intentionally built-in backdoor.
• It uses a Trusted Platform Module TPM, which is a special microchip in many computers that supports these security features. Here are some modes of TPM:
• TPM + Pin: user provides authentication to a pre-boot.
• TPM + Pin + USB Key: must be supported by the users BIOS first.
• **Both of these methods are vulnerable to a bootkit.
• You must have administrative privileges in Windows, in order to turn BL on or off.
• This can be considered a deterrent for users that may find BL difficult to use. 

•  In order for Bitlocker to work on a Windows OS, you'll need the following:
• Two NTFS partitions (one for the operating system, and the other from which the operating system boots.)
• BL requires the boot volume to remain unencrypted and assigned a drive like C:
• Win7 creates this secondary boot volume by default.
• The BIOS configures so that the hard drive boots first before checking the CD/DVD drive.

• When the system is booted, the integrity of the OS and hardware is verified.

Methods of encryption:

• BL uses Advanced Encryption Standards AES that can configure to use one of four encyrption methods.
• AES-CBC
• AES-CBC with Elephant Diffuser
• AES-CCM
• The default mode is to use a 128-bit AES with the diffuser enabled. 
• This of course goes into grand details of cryptography (which i will not be attempting to discuss in this blog.) 

Keys used in BitLocker:

• Volume Master key VMK:  256-bit in size and is stored encrypted with either a recovery key, external key, or the TMP.
• A malicious boot loader can decrypt its way to the VMK, which would then allow access to decrypt or modify any of the information.

• Commands to encrypt or decrypt comes from the Full Volume Encryption Key FVEK (512 bit)
• There are keys that are encrypted to protect even more keys.
• These keys are located within the TMP chip, located on the motherboard of a hard drive.
• Bitlocker keys are 64 bytes in length.

• Recovery key: An external key in a USB. And then there is the Recovery Password that is used to determine a recovery key itself. 
• Volume Header: Similar to an NTFS volume header, BitLocker has the signature -FVE-FS-.
• Some differences from an NTFS header, includes BL metadata. I didn't recognize anything i could add as significant.

• As a forensic analyst, it is imperative to recognize the level of encryption on a drive. Since without doing so Bitlocker will make drive analysis infeasible.
• A quick look at each volumes primary volume boot sector (which is sector offset 3), can reveal whether the volume is encrypted with Bitlocker.
• Where you will usually see the NTFS at offset 3 you'll see instead -FVE-FS- (\x2d\x46\x56\x45\x2d\x46\x53\x2d), indicating that the volume is encrypted by BL full disk encryption.
• A script to display the status of a BL volume: Manage-bde.exe
• This script is included in Win7. It is located in %systemdrive%\Windows\system32
• The drive may need to be configured with a BL device tool preparation in Vista. (Creating a list of parameters to be run).
• But if the script is issued on a live machine, and no results are received in CMD, it may be safe to say that BL is not enabled.
• With a privileged CMD run cscript manage-bde.wsf -protectors -get c: -rp to unlock Bitlocker.
• This script is supposed to give access to the Recovery Password.
• This process is put into action here http://www.forensicfocus.com/Content/pid=360/page=4/ when working with a Windows Live CD you're going to want scripts to run when analyzing a machine. 
• After which a dd command will allow you to image a drive: but still with encrypted data, since it is only the recovery password. (Logical level is decrypted, but Physical is not).
• I myself have not tried to run a Live CD against a BL fully encrypted drive. 

• BiLocker keys (64-bytes) are held in memory while the system is up and running.
• There are laws in the UK that focus on making it mandatory for a systems owner to hand over keys, if suspected in a legal case. Currently know laws like this in the US.

Mac OS X 

FileVault 1

• In Leopard and Snow Leopard: FileVault is built into the operating system, encrypts the users home directory, utilizing the login password and comes standard with every distribution of a Mac OS X.
• Given this more convenience method of encryption, it is more likely a Mac computer will be using encryption than encryption on a Windows os.
• Setup is easier, and similar to EFS, FV works with each of its users, instead of only have the option of a full drive encryption.
• This means encryption applies to users "home directories", instead of the startup volume.
• So the Users Home Folders are encrypted as one large volume file. And each user account is isolated from the other.
• Can be 20 gb in size
• FV creates a secure user Home Folder by creating either a sparseimage or a sparsebundle (which can function like a disk itself). These are simply a disk image or DMG used for recovery or backup.
• When an individual has the motivation of wiping their drive, they will want to make sure this file isn't accessible anymore. 
• Sparsebundle has AES 128 encryption to it when a new file is added to a users Home folder. (This only applies if a user activates FileVault).

• There are a few sets of keys to be aware of in FV:
• The Master key gives root access
• The User password: gives access to the account. If a user password is forgotten, the master password or recovery key may be used to bypass.
• Recovery Password.
• A Master password is created when FV is enabled.
• A Master password is not to be confused with a "root password". 

• When FV is used on a Mac, it works with other utilities on the computer.
• Such as Time Machine and the secure erase option. 

• File sharing is disabled when FV is in use.  

• FileVault is off by default (unlike with BitLocker).
• It is not a full disk encryption utility. 
• Uses AES 128-bit encryption.  

FileVault 2 

• However,  in OS X Lion: FileVault 2 is a newer design that does encrypt the entire volume startup and typically includes encrypting the home directory, but again doesn't entire the entire volume (which includes the operating system).
• Apple has referred to this link between the volume and the OS as the CoreStorage manager.
• This is an idea how CoreStorage works when organizing volumes:

 

• When the authorized users information is encrypted, it is booted separately from a non encrypted boot volume. (Similar to BitLocker).
• The EncryptedRoot.plist.wipekey contains all the information needed to extract the volume master key from  the users password recovery token. 
• the encryption key is easily available in the header of the CoreStorage volume.
• The header also contains the size of the entire volume
• (I won't be getting into the value of plists in this blog.)   

• Instead of using FV 2 to encrypt a users home directory, using Disk Utility (diskutil list), a user can create an encrypted disk image themselves and store any subset of their home directory in there. This encrypted image behaves similar to a FV encrypted home directory, but is under the users maintenance. 

Concluding pointers

• When comparing Bitlocker or Filevault in terms of which one is more effective, strength from brute force attacks and encryption protection, the winner seems to be in favor of Bitlocker.
• A rule in encryption dictates that in order to have complete security with your files, you must implement full drive encryption, instead of singular volumes and folders. If an attacker is able to gain access to your partially accessible account, it makes his job easier.
• This can be a downfall for FV, because hackers can boot up an account with FV enabled. Even though FV is preventing them from your home directory files, they still have an upper hand when being allowed to boot up into your account. 
• BL encrypting the entire operating system is definitely a major positive. 
• But since FV is more convenient for the user, encrypting on the fly will deter the hackers that are constrained by time. 

 

Mac File System

Mac File System

Hierarchical File System Plus (HFS+)

• Replaced HFS.
• Supports much larger files 32 bit in length, instead of 16.
• Mac OS X is built on a core called Darwin, which consists of BSD Unix.
• Mac is Unix based.
• Primary difference between HFS and HFS+ is that HFS is limited to 512 bytes per volume, and HFS+ raised the number of blocks to 4 billion.
• But HFS+ supports smaller file sizes on larger volumes (resulting in more efficient disk use).
• Macintosh file systems maintain most of their information in the Catalog and Extent files.

Technologies

• Bonjour
• Filevault
• Spotlight
• Target Disk Mode
• Bootcamp

File Manager

• Is a utility that handles reading, writing, and storing data on the physical media.
• It also collects data to maintain  the HFS and manipulates files, directories, and other items.

The Finder

• Is another Mac utility that keeps track of files and maintains the users desktop.

HFS & HFS+

• Each file will consist of a two "forks" connection:
• Data Fork - where data is stored. Typically contains data the user creates.
• Resource Fork - where file metadata and app information is stored.
• If a mac file is copied to a file system that doesn't support resource forks, the fork will be lost (creating a hidden file)
• Can be best equated to Windows Alternate Data Streams.

 B.Nelson, 2010

• Example: A word processing file might store its text in the data fork, while storing any embedded images in the same file's resource fork. 
• Resource forks are used mostly by executables, but every file is able to have a resource fork.
• Both forks can be empty in HFS+ because file manager is in charge of reading and writing information to files, it can access both forks.
• Resource forks are sometimes used to store metadata of a file, although it can also be used for storing the actual data.
• Note that the Macintosh file systems also have a separate area for metadata distinct from either the Data or Resource fork. Being part of the catalog entry for the file, it is much faster to access this.
• Catalog file: contains timestamps, and catalog nodes. (Metadata stuff).
• is a B-tree that contains records for all the files and directories stored in a volume.
• HFS+ is able to work with larger records to allow more fields and to allow for those fields to be larger than in HFS.

• Extents Overflow file: is another B-Tree that records the allocation blocks that are allocated to each file as extents. Each file record in the Catalog File is capable of recording eight extents for each fork of a file, and once those are used, additional extents are recorded in the Extents Overflow file.

• So resource forks and catalog files can both contain metadata of a file.

Mac Volumes

• A volume is any storage medium used to store files.
• It can either take up, or all of a storage medium.
• Volumes have allocation blocks and logical blocks.
• Logical block: is a collection of data that can't exceed 512 bytes.
• When you save a file, the File manager assigns the file to an allocation block (which is a group of consecutive logical blocks.)

• Allocation Blocks: HFS divides the total space on a volume into equal sized pieces called Allocation blocks - which is usually one logical block.
• Allocation block numbers are stored as 32-bit integers, with 4Kb as a common block size.
• As volumes increase in size, one allocation block might be composed of three or more logical blocks. And while this volume increases, so will the amount of unused space.
• More allocation blocks means a smaller allocation block size. 
• which in turns leaves less wasted space. which means you can have more files.

• Allocation File: which keeps track of which allocation blocks are free and which are in use. It is similar to the Volume Bitmap in HFS, in which each allocation block is represented by one bit.
• The Volume Bitmap in HFS is different in that the allocation file is stored as a regular file, it does not occupy a special reserved space near the beginning of the volume.
• It tracks each block on a volume to determine which blocks are in use and which ones are available to receive data.

• Volume Header: Stores a wide variety of data about the volume itself, for example the size of allocation blocks 
• timestamps that indicates when the volume was created or the location of other volume structures such as the Catalog File or Extent Overflow File
• the VH is always located in the same place.

The Volume Format:
Ryan R. Kubasiak, Sean Morrissey, 2009
From top to bottom, is the beginning to the end. At offset (or the beginning) is the byte 0 which is where the Boot Blocks are located. Followed by the Volume Header, then so on and so forth.

Additional Terms
HFS Wrapper: Made for older versions to be compatible with newer versions
Startup File: allows for storing large blocks of variable size in extent headers.
Alternate Volume Header: if there is a corrupt file in the startup volume header, this acts as a bakup.
Inodes: central location for data that is shared between hard links on a volume.
Property lists (plist): Are the greatest source of information for settings and configuration. They are often simple text files formatted in XML to be read on the system. They contain strings and encoded binary. (I will discuss examination of these valuable files at a later time).
Keychain: is an Apply password management system, along with other various types of data for websites, FTP servers, SSH accounts, encrypted disk images, certificates.

Sources
Guide to computer forensics and investigations, 2010
Wikipedia: http://en.wikipedia.org/wiki/HFS_Plus
Handbook of digital forensics and investigations, 2010
Mac OS X, iPod, and Iphone Analysis Toolkit, 2009