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.