Ponder The Bits

Musings and confusings. All things DFIR.

Category: Mac

Generating File System Listings from the Command Line (with Full MACB Timestamps and Hashes)

!!IMPORTANT NOTE!!
———————————-
Before you go testing/implementing the commands that are described in this article, PLEASE ensure you first understand the following major caveat of performing certain actions/commands against files on a live system:

Reading a file changes its atime eventually requiring a disk write, which has been criticized as it is inconsistent with a read only file system.”
https://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime

You DO NOT WANT TO DO THIS on a target of which you are attempting to perform forensic analysis.

Further reading on the matter
https://superuser.com/questions/464290/why-is-cat-not-changing-the-access-time

When in doubt and/or fear of possibly affecting a target system’s access timestamps, you should ensure the following is true before running the below commands:

  • The target file system (or whatever directory you are running this against) has been (re)mounted read-only and/or with the “noatime” and/or “relatime” mount parameters.

You can mount a target disk/filesystem read-only via the following:

$ sudo mount -o ro,... </src/disk> </mount/point/>

You can remount a live filesystem/directory read-only via the following:

$ sudo mount -o ro,noload </path/to/fs/directory/> </mount/point/>

You can remount a live filesystem/directory disabling access timestamp updates via the following:

$ sudo mount -o remount,noatime </path/to/fs/directory/> </mount/point/>

———————————-

Disclaimer: I did not search the internet for a solution to this article’s challenge as I wanted to come up with one myself. Thus, a solution may already exist that is similar (or not). However, the point of the below article was not to just find a solution and move on. Rather, I wanted to walk readers through a problem statement, step-by-step piecing together a solution, thoroughly documenting and “teaching a man to fish” versus just giving out a fish. That said, I am in no way guaranteeing the below commands to work perfectly in ensuring it finds and properly processes every single file on the filesystem. In fact, when running this live, we are actively avoiding certain areas of the filesystem that are actively changing/ephemeral to minimize the error outputs. The only thing I can guarantee, in true *nix ad-hoc one-liner development, is (dis)function in ways beyond the imagination. ‘Tis a fact we just live with. This post simply describes *options* you can add to your toolkit that can always very much benefit from testing, troubleshooting, and improving.

In addition, while I attempted to identify and explain various aspects of each of my commands, I recognize that there are still improvements that can be done to this command. I attempted to find the balance of thorough explanation and efficiency while not bleeding over into the esoteric.

TL;DR – YYMMV*

*The first Y stands for “Yuuuuuuge”

Enough with the caveats and disclaimers, let’s get down to it…

Linux

Recently, a teammate posed a request to be able to generate a file listing of a directory in Linux showing the size and hash of each file in the output format of “ls -lhS” (list files in long format, with human-readable sizes, in decreasing size output).

As I hit Reply to the email, my initial thoughts were “Why don’t you use FLS?” as that is essentially the de-facto standard for producing a file system listing from an image. However, I got to thinking… FLS doesn’t really provide a comprehensive solution here for a few reasons:

  1. We need a command to run against a LIVE system and FLS only runs against a dead system image*
  2. FLS requires a second step to convert its output to bodyfile format for human-readable timestamps
  3. FLS doesn’t perform any file hashing

*Actually, this is not true. As one of my colleagues ever-so-graciously reminded me… Although it is not well documented, FLS can run against live systems. You can run it against a live Windows system by using named pipes, a la “fls [options] \\.\<X>:“, where <X> is a logical drive letter like C:, D:, etc.  And, a September 2011 SANS blog post here describes it in operation for Windows. To run it against a live Linux or Mac/OS X system, you may do so as such “fls [options] /dev/sd<X><Y>“, where <X> is the physical drive letter like /dev/sda, /dev/sdb, etc. and <Y> is the partition number like /dev/sda1, /dev/sda2, etc.

At any rate, the last two points remain, so it’s good thing I waited to hit send before looking like a dummy.

Instead, I took the challenge in attempting to come up with a command line one-liner to provide what was requested. Initially, I came up with the following:

$ find /path/to/dir -maxdepth 1 -type f -print0 | xargs -0 -r ls -lh | awk '{cmd="md5deep -q "$9; cmd | getline md5; close(cmd); cmd="sha1sum "$9; cmd | getline sha1; close(cmd); print $1","$2","$3","$4","$5","$6" "$7" "$8","$9","md5","sha1}' | awk '{$NF=""}1' | sed 's/ ,/,/g’ | sort -t',' -hr -k5


*You may need to Right-Click and Open/View Image in New Tab to see these inserted screenshots in full resolution. Sorry about that.

However, as we can see here, the timestamps produced from a simple “ls -lh” were rather lacking in both what was provided (solely last modification time by default) as well as precision (only precise to the second by default*, and a LOT can happen on a system in a singular second that we’d need to distinguish during an investigation).

== Sidebar 1 ==
You might be wondering why I am piping find’s output to xargs to execute the “ls -lh” against the results versus simply using find’s built-in “-exec” parameter that ostensibly does the same thing. In short, this is for performance reasons which you can read about at the below links.
https://www.everythingcli.org/find-exec-vs-find-xargs/
https://www.endpoint.com/blog/2010/07/28/efficiency-of-find-exec-vs-find-xargs
== /Sidebar 1 ==

== Sidebar 2 ==
Also note that all timestamps will be in the system’s local time. So, it would behoove you to collect that information from the system as well for future reference during analysis. This can be done a few different ways, as shown below:

== /Sidebar 2 ==

In light of the aforementioned issues (lacking additional timestamps and precision), I worked through a few different solutions and came up with the following which included not only timestamps with much greater precision (now with full nanosecond precision*) but also included all of the GNU “find” command’s printable timestamps (i.e., Last Modified, Last Accessed, and Inode Changed).

$ find /root -maxdepth 1 -type f -printf '%i,%M,%n,%g,%u,%s,%TY-%Tm-%Td %TT,%AY-%Am-%Ad %AT,%CY-%Cm-%Cd %CT,”%p"\n' | awk -F"," '{cmd="md5deep -q "$9; cmd | getline md5; close(cmd); cmd="sha1sum "$9; cmd | getline sha1; close(cmd); print $1","$2","$3","$4","$5","$6","$7","$8","$9","md5","sha1}' | awk '{$NF=""}1' | sed 's/ ,/,/g’ | sort -t',' -hr -k5

**Note that printf’s time field format is precise to 10 digits, while nanoseconds are (by definition) only precise to 9 digits. Thus, it is appending a 0 in the 10-th digit spot. Why? I frankly don’t know. I mean… uhh… “the reason of which will be left as an exercise to the reader.” 🙂

== Sidebar 3 ==
*I later discovered that you can show timestamps with full nanosecond resolution in ls via the “–full-time” parameter as I will show below.

$ ls -l --full-time
total 55088
drwxr-xr-x 2 root root 4096 2017-11-22 14:22:30.165725454 -0800 Desktop

== Sidebar 3 ==

At any rate, we’re making progress, but we’re still missing something. What about Inode (File) Creation? Is that not recorded in Linux? In short, Ext3 filesystems only record Last Modified (mtime, Last Accessed (atime), and Inode Changed (ctime), while Ext4 filesystem (on which a large majority of Linux distress operate) fortunately include the additional Inode Creation time (crtime). Lucky for us, I am doing this on an Ext4 filesystem, so we should be seeing those times if they’re implemented and recorded, right? You’d think so… but you’d be wrong.

Unfortunately, Linux decided not to implement an easy way (aka a natively integrated API) to view/include these (crtime) timestamps in various tools’ output (as seen here in the “find” command, and shortly in the “stat” command). Alas, FRET NOT, as there is a way to extract this timestamp using the debugfs utility. Intended as a “ext2/ext3/ext4 file system debugger”, it provides a “-R” option to execute a given command for debugging purposes. We will (ab)use this option to extract more information (i.e. the crtime timestamp) from the “stat” command than is originally provided by running the command on its own.

First, we will run “stat” against a file:

$ stat /root/VMwareTools-10.1.15-6627299.tar.gz
File: /root/VMwareTools-10.1.15-6627299.tar.gz
Size: 56375699 Blocks: 110112 IO Block: 4096 regular file
Device: fe01h/65025d Inode: 405357 Links: 1
Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2018-01-12 15:16:03.524147591 -0800
Modify: 2017-11-24 17:38:44.799279489 -0800
Change: 2017-11-24 17:38:44.799279489 -0800
Birth: -

Now, we will use the “debugfs” command to get the Inode/File Birth (crtime) timestamp. Keep in mind, you will need to provide the volume/partition on which the referenced file resides as a parameter to the command, otherwise the command will not work (namely yielding a “No such file or directory while opening filesystem” error). For my example below, my system is using LVM volumes and the file we’re querying resides on my root “k2–vg-root” LVM volume/partition.

$ debugfs -R 'stat /root/VMwareTools-10.1.15-6627299.tar.gz' /dev/mapper/k2--vg-root
Inode: 405357 Type: regular Mode: 0444 Flags: 0x80000
Generation: 763788199 Version: 0x00000000:00000001
User: 0 Group: 0 Project: 0 Size: 56375699
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 110112
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5a18c9a4:be902604 -- Fri Nov 24 17:38:44 2017
atime: 0x5a5941b3:7cf76e1c -- Fri Jan 12 15:16:03 2018
mtime: 0x5a18c9a4:be902604 -- Fri Nov 24 17:38:44 2017
crtime: 0x5a18c9a4:5740e928 -- Fri Nov 24 17:38:44 2017
Size of extra inode fields: 32
Inode checksum: 0x53c3b2b6
EXTENTS:
(0-10239):1859584-1869823, (10240-12287):1873920-1875967, (12288-13763):1902149-1903624

There’s actually a lot of great output here that can be very useful to us as forensic analysts, but we really only need the crtime for our purposes today. So, we can do a little command-line fu to just extract the human readable portion of the crtime timestamp we care about.

$ debugfs -R 'stat /root/VMwareTools-10.1.15-6627299.tar.gz' /dev/mapper/k2--vg-root |& sed -n 's/^crtime.*- \(.*\)$/\1/p'
Fri Nov 24 17:38:44 2017

To go a bit further and match stat’s default timestamp formatting, we can do a bit more command-line fu to yield the following:

$ date +"%Y-%m-%d %H:%M:%S.%N %z" -d "$(debugfs -R 'stat /root/VMwareTools-10.1.15-6627299.tar.gz' /dev/mapper/k2--vg-root |& sed -n 's/^crtime.*- \(.*\)$/\1/p')"
2017-11-24 17:38:44.000000000 -0800

Great, now we have a crtime (Inode/File Creation) timestamp we know and love. But, wait… anyone else noticing something here? The nanoseconds are all zeroes. Hmmm. Well, if we trace our process back a bit, we can see that this is because we are attempting to produce a nanosecond-precision datetime object from a source that obviously doesn’t include it. Obviously, we can’t extract nanosecond precision from an input that doesn’t contain it. So, where do we go from here?

Well, if we look back at the crtime output (crtime: 0x5a18c9a4:5740e928 -- Fri Nov 24 17:38:44 2017) we can see that the second column there contains two sets of hex digits (0x5a18c9a4:5740e928) delineated by a colon. Could it be that this is simply a hex version of the decimal and nanosecond epoch timestamps? Oh, it could, and it is. It turns out the first entry (previous to the colon) is the epoch seconds and the second entry (after the colon) is the nanoseconds. So, we’ll need to go back to our command and alter it to extract, convert, and construct the nanosecond epoch timestamp we’re looking to produce.

The below command extracts both the first and second set of hex digits (epoch seconds and epoch nanoseconds, respectively), converts both of the hex sets to decimal, converts the epoch seconds to a human-readable datetime object using Awk’s strftime formatting, and then divides the nanoseconds portion by four (essentially performing a two-bit shift) as is necessary per Hal Pomeranz’s article on EXT4 Timestamps here.

**Big thanks to Dan (aka @4n6k) for his assist here in leading me to Hal’s article as I was banging my head on this last portion for a bit until discovering this bitwise shift needed to be done. Also, of course, huge thanks to Hal (@hal_pomeranz) as well for this monumental efforts in painstakingly documenting EXT4 Timestamps and these nuances.**

$ debugfs -R 'stat /root/VMwareTools-10.1.15-6627299.tar.gz' /dev/mapper/k2--vg-root |& sed -n 's/^ mtime: \(0x[0-9a-f]+\):\([0-9a-f]+\).*/\1.0x\2/p' | awk -F'.' '{n = strtonum($2) / 4; print strftime("%Y-%m-%d %T",strtonum($1))"."n}'
2017-11-24 17:38:44.799279489

AWESOME. We can now successfully extract the crtime file timestamps programmatically.

Now, let’s put it alllll together and build our one-liner that’s going to help us reach our original goal here of outputting a file listing with all the available timestamps (in MACB order) as well as file hashes (MD5 and SHA1). We will be using the largely native md5sum and sha1sum utilities to produce our hashes so as to avoid the need to install any additional third-party tools.

And, here it is. I give the ugliest (most epic?) command to date to output everything we’ve been looking for:

# find /path/to/dir -maxdepth 1 -type f -printf '%i#%M#%n#%g#%u#%s#%TY-%Tm-%Td %TT#%AY-%Am-%Ad %AT#%CY-%Cm-%Cd %CT#"%p"\n' | awk -F"#" '{cmd="debugfs -R '\''stat <"$1">'\'' /dev/mapper/k2--vg-root 2>/dev/null | grep -Po \"(?<=crtime: 0x)[0-9a-f]+:[0-9a-f]+(?=.*)\" | tr \":\" \" \" | { read e n; echo \"$(date +\"%Y-%m-%d %H:%M:%S\" -d @$(printf %d 0x$e)).$(printf %09d $(( $(printf %d 0x$n) / 4 )) )\";}"; cmd | getline crt; close(cmd); cmd=“md5sum "$10" | cut -d \" \" -f1"; cmd | getline md5; close(cmd); cmd="sha1sum "$10" | cut -d \" \" -f1"; cmd | getline sha1; close(cmd); print $1","$2","$3","$4","$5","$6","$7","$8","$9","crt","$10","md5","sha1}' | sed 's/ *,/,/g’ | sort -t',' -hr -k6

Note that we had to do a few things to deal with various unsavory characters that may occur within filenames (e.g., spaces, parentheses, comma’s, etc.). First, we can’t use comma’s as our print output delimiter as filenames with comma’s would then screw up our Awk parsing. So, we needed to use a non-standard character (i.e. one we would never expect to see in our output). In this case I chose “#”, but you could use whatever you’d like. To get our debugfs stat output, as well as MD5 and SHA1 hashes, we utilize Awk’s ability to execute commands and retrieve the output with its getline function. You may notice that the debugfs stat command one-liner strings together a RegEx with a Lookbehind assertion, along with some bash read/print/date functions in order to translate the hex -> decimal -> formatted human-readable datetime for us.

So… How ‘bout them apples?? WE’VE DONE IT!! All of that painstaking work has paid off in spades. We’ve put together a command that is essentially FLS on steroids (with hashes) that we can run against BOTH a live and dead system! THIS IS WHAT DREAMS ARE MADE OF!

If you’d like to use this* as an FLS replacement against a (dead) system image, simply mount the image’s file system (Read-Only, of course), adjust the command to point to the root of the file system, remove the last “sort” command (as we can do that later during analysis as needed), and simply output to CSV. Like so:

*AGAIN, I PROVIDE NO GUARANTEES HERE, only a best effort here and initial pass on doing this. For example, in one of my test VM’s I kept getting what appeared to be random “sh: 1: printf: 0x: not completely converted” errors that output a default crtime date of “1969-12-31 16:00:00.000000000” which makes no sense as I’ve verified that the crtimes on these files are present and properly output via stat/debugfs and a manual conversion of the values yields success. Yet, it did not happen in other VM’s. So, just a heads up in case something goes awry on your end.

# echo "Inode,Permissions,HardLinks,GroupName,UserName,Size(Bytes),LastModified,LastAccess,Changed,Birth,Filename,MD5,SHA1" > FS_Listing.csv

# find / -xdev ! -path '/var/run/*' ! -path '/run/*' ! -path '/proc/*' -type f -printf '%i#%M#%n#%g#%u#%s#%TY-%Tm-%Td %TT#%AY-%Am-%Ad %AT#%CY-%Cm-%Cd %CT#"%p"\n' | awk -F"#" '{cmd="debugfs -R '\''stat <"$1”>'\'' /dev/mapper/k2--vg-root 2>/dev/null | grep -Po \”(?<=crtime: 0x)[0-9a-f]+:[0-9a-f]+(?=.*)\" | tr \":\" \" \" | { read e n; echo \"$(date +\"%Y-%m-%d %H:%M:%S\" -d @$(printf %d 0x$e)).$(printf %09d $(( $(printf %d 0x$n) / 4 )) )\";}"; cmd | getline crt; close(cmd); cmd="md5sum "$10" | cut -d \" \" -f1"; cmd | getline md5; close(cmd); cmd="sha1sum "$10" | cut -d \" \" -f1"; cmd | getline sha1; close(cmd); print $1","$2","$3","$4","$5","$6","$7","$8","$9","crt","$10","md5","sha1}' | sed 's/ *,/,/g' >> FS_Listing.csv

Note that we are:

  1. First writing a “header” line to the CSV file for easier reference during analysis
  2. Now operating from a ROOT prompt (e.g. the leading “#” denoting a root prompt versus the “$” denoting a standard user prompt) as we will need root privileges to access/read the entire filesystem
  3. Avoiding traversal of external mounted filesystems (i.e. network shares, external media, etc.) via the “-xdev” parameter, and
  4. Specifically avoiding a few directories via the “! -path /path/to/avoid/*” as the aforementioned paths store ephemeral process information we aren’t interested in collecting (at least not for our purposes here).

Excel ProTips: If you are using Excel to review the CSV file, be aware that Excel only displays time precision down to the milliseconds (and no further). Alas, you will be missing everything beyond the 3 digits past the decimal place. In order to display this millisecond precision, you will want to highlight all the MACB timestamp cells, right-click, select Format Cells, select Custom under the Number tab, input the Type as mm/dd/yyyy hh:mm:ss.000 (or whatever you like, the important part is the timestamp’s trailing .000), then click OK. And, Voila!, millisecond timestamp precision. Obviously, it is most valuable to be able to actually see the full nanosecond precision but at least it’s something for those who are die-hard Excel fans.

Also, for whatever reason, Excel does something weird with displaying some of the leading permissions entries by prepending a “=“ to them. Why, I have no idea. Maybe Excel gets confused and sometimes tries to interpret “-“ text as an intended negative or minus sign and thus attempts to “fix” it for us (in true Microsoft fashion) by denoting it as a formula and prepending the “=”? ¯\_(ツ)_/¯ For whatever reason, it’s happening (see below). Just be aware that this is something Excel is adding and that it is NOT present in the original CSV if you’re using any other tools for analysis.

Now… how about doing this on a Mac? OF COURSE we’re going to translate this over…

Mac

If you’ve been reading my blog (and/or working between Linux and Mac systems for a while), you’ll know that things do not often translate directly to from Linux (GNU) to Mac (BSD) as the core utilities seem to always differ just enough to make your life a pain when working between systems. And, this situation is no different.

As you might assume, we are going to use the “stat” command again as the basis for extracting all of our timestamps. However, we will of course be using the BSD stat command and not the GNU version as used in Linux. Below is the default BSD “stat” output (the format of which is of course different from GNU “stat” because… why not):

$ stat .vimrc
16777220 1451064 -rw-r--r-- 1 jp staff 0 54 "Sep 22 12:08:02 2017" "Dec 26 10:36:32 2016" "Dec 26 10:36:32 2016" "Dec 26 10:12:15 2016" 4096 8 0 .vimrc

The upside here is that, by default, BSD “stat” outputs all 4 HFS+ filesystem timestamps we care about! Great, but which are what? Saving you some time and research, BSD “stat” outputs timestamps in the following order by default:

Last Accessed, Last Modified, Inode Changed, Inode Birth - (A,M,C,B)

Just as we discussed earlier, these reflect the time file was last accessed, the time the file was last modified, the time the inode was last changed, and birth time of the Inode. So, in order to get them into an order we like (okay, the order that I like) such as MACB (because this is how we most often see the timestamp acronym), we can perform the following:

$ stat -t "%b %-d %Y %T %Z %Y" .vimrc | awk -F'"' '{print "Modified: "$4; print "Accessed: "$2; print "Changed: "$6; print "Birth: "$8}'
Modified: Dec 12 2016 10:36:32 PST 2016
Accessed: Sep 9 2017 12:08:02 PDT 2017
Changed: Dec 12 2016 10:36:32 PST 2016
Birth: Dec 12 2016 10:12:15 PST 2016

And, there we have it, full timestamp information in the order we (I) like it. Do note that HFS+ timestamp precision is only down to the second as it does not implement nanosecond resolution like some other filesystems. And, for that, we do a hearty ¯\_(ツ)_/¯. Fortunate for us in the future, APFS has implemented nanosecond timestamp resolution. But, that’s a separate discussion you can read about here.

Now that we’ve taken care of that timestamp acquisition and formatting issue, let’s move on to building the command line statement we’re going to run. While GNU’s find utility provides a “-printf” option to format and customize find’s output, BSD’s find lacks such an option. Alas, we will need to be a bit more creative here. What I ended up doing here was piping find’s output to BSD’s “stat” command which DOES provide a formatting option “-f” that we can utilize. But, again, it’s not as straight forward as just copy/paste of the previous formatting we used on Linux because OF COURSE the print delimiters don’t directly translate over either.

So, first we need to translate over the previous GNU print formatting string ('%i#%M#%n#%g#%u#%s#%TY-%Tm-%Td %TT#%AY-%Am-%Ad %AT#%CY-%Cm-%Cd %CT#”%p”\n') into the correlated BSD values, which end up being the following:

'%i^%Sp^%l^%Sg^%Su^%z^%Sm^%Sa^%Sc^%SB^"%N"'

I’m using “^” as a delimiter this time instead of “#” as I ended up actually having files with hash/pound signs in their name on my system (THANKS, ATOM APP). Also, note that I’m using single-tick’s for the print statement and using full quote encapsulation for the filename. I’m doing this in order to avoid issues with dollar signs ($) in filenames. Again, no, using such delimiters is not very pretty, but it’s required. And, if you for some reason have files with “^” in their names, it will break this as well. So, YMMV.

$ find /Users/jp -maxdepth 1 -type f -print0 | xargs -0 stat -t "%Y-%m-%d %H:%M:%S" -f '%i^%Sp^%l^%Sg^%Su^%z^%Sm^%Sa^%Sc^%SB^"%N"' | sort -t'^' -nr -k6

Note that I also needed to specify stat’s “-t” argument to format the datetime output in the printf statement.

So, there we have it, listing directory output in decreasing file size.

Now, on to calculating and appending our MD5 and SHA1 hashes to the output. For this, we will use BSD’s native md5 and shasum utilities. Using much of the same structure from our Linux one-liner, we then come up with the following:

# find /Users/jp -maxdepth 1 -type f -print0 | xargs -0 stat -t "%Y-%m-%d %H:%M:%S" -f '%i^%Sp^%l^%Sg^%Su^%z^%Sm^%Sa^%Sc^%SB^"%N"' | awk -F"^" '{cmd="md5 "$11" | cut -d \" \" -f4"; cmd | getline md5; close(cmd); cmd="shasum "$11" | cut -d \" \" -f1"; cmd | getline sha1; close(cmd); print $1","$2","$3","$4","$5","$6","$7","$8","$9","$10","$11","md5","sha1}' | sort -t',' -nr -k6

And there we have it, a directory listing with hashes sorted in decreasing file size. Note that were are now again in a root shell to avoid file access permissions.

Now, on to the final one-liner to do a full filesystem listing:

# echo "Inode,Permissions,HardLinks,GroupName,UserName,Size(Bytes),LastModified,LastAccess,Changed,Birth,Filename,MD5,SHA1" > OSX_Listing.csv

# find -x / -type f -print0 | xargs -0 stat -t "%Y-%m-%d %H:%M:%S" -f '%i^%Sp^%l^%Sg^%Su^%z^%Sm^%Sa^%Sc^%SB^"%N"' | awk -F"^" '{cmd="md5 "$11" | cut -d \" \" -f4"; cmd | getline md5; close(cmd); cmd="shasum "$11" | cut -d \" \" -f1"; cmd | getline sha1; close(cmd); print $1","$2","$3","$4","$5","$6","$7","$8","$9","$10","$11","md5","sha1}' >> OSX_Listing.csv

Note that OS X find’s “-x” parameter is equivalent to GNU’s “-xdev”, meaning not to enumerate external disks/mounted filesystems.

When I ran this against my full system, I realized it choked on files containing “$”. So, I needed to add in some Awk substitution to escape the dollar sign with a leading “\” so that the shell wouldn’t attempt to interpret the “$” as (mis)indication of a variable when it was simply a dollar sign in a file name. Full disclosure: it may also choke on other files with special characters, but I’ve shown you how you can use Awk substitution as a way around it. So, update/augment this as needed.

Conclusion

Sooooo, Wow. That was a bit of hard work. Actually, it was A LOT of hard work, much of which was not captured in the blog post for the sake of brevity and everyone’s sanity, as it surely tested mine many a time. However, hopefully you can see the value of spending the time building effective and efficient processes on the front end so you are not always paying for it on the back end. Suffice to say, IMHO, sometimes it is ok to work harder and not smarter, when the process will help you become more of the latter.

If you wanted to run any of the above commands against a mounted evidence image, you’d simply specify its mount point in the find command, like so:

# find /mnt/point/ ...

Note that we don’t use the “-xdev” or “-x” parameter here as we do actually want it to enumerate an external filesystem (i.e. our mounted evidence image’s filesystem which is likely from an external disk or network share).

And, now that we’ve walked through doing all of that the hard way using native Linux utilities, I will say that another filesystem enumeration capability to include hashes has also been built in Python in Jim Clausing’s macrobber.py script. However, due to Python’s os.stat call limitations, this script does not/cannot pull the btime (aka crtime) attributes that we are able to identify and extract through our commands here. Nonetheless, it is another option, which is always great.

Thanks to everyone for hanging in there through this whole post. It obviously takes way more time to painstakingly walk through every step of a process; however, I feel it is well worth my time to teach people to fish, and hopefully you all do too.

Did you enjoy this post? Share it!

OSX (Mac) Memory Acquisition and Analysis Using OSXpmem and Volatility

Macs don’t get much love in the forensics community, aside from @iamevltwin (Sarah Edwards), @patrickolsen (Patrick Olsen), @patrickwardle (Patrick Wardle), and a few other incredibly awesome pioneers in the field. We see blog posts all the time about Windows forensics and malware analysis techniques, along with some Linux forensic analysis, but rarely do we see any posts about Mac technical/forensic analysis or techniques. I find this odd, considering the surge in usage and deployment over the last several years, particularly within enterprises. Well, with my most recent two part Mac post as well as this one, I’m attempting to change this, my friends!

Macs need love and disk/memory analysis as well, amirite?

Let’s have a look at memory acquisition of OSX systems using a nifty tool called OSXpmem.

OSXpmem is a part of the pmem suite created by the developers of Rekall. Rekall itself is actually a very useful utility built for both memory acquisition and live memory analysis on Windows, Linux, and OSX systems. While I will be delving into Rekall in a future post, for this we will simply be focusing on OSXpmem, which is an awesome command-line utility for quickly and easily collecting RAM from a Mac system. One of its greatest features is its output to an AFF4 volume, which has a ton of useful features (likely to be discussed in a dedicated post in the future as well).

Acquiring Memory

So, what’s the easiest way to get up and running with the tool for memory acquisition?

  1. Download latest release (as of this post, the latest osxpmem release is “2.1.post4”).
  2. Unzip the package
    1. $ unzip osxpmem.osxpmem-2.1.post4.zip
  3. Run it to collect memory from the local system
    1. $ ./osxpmem.app/osxpmem -o <output_dir>

Super simple, right?

Wellll, maybe not that simple. When you run it, even as sudo/root, you may get the following error:

$ sudo osxpmem.app/osxpmem -o Memory_Captures/mem.aff4
Imaging memory
E1229 15:17:26.335978 3375588288 aff4_file.cc:289] Can not open file /dev/pmem :No such file or directory
/Users/jp/Projects/osxpmem.app/MacPmem.kext failed to load - (libkern/kext) authentication failure (file ownership/permissions); check the system/kernel logs for errors or try kextutil(8).
E1229 15:17:26.606639 3375588288 osxpmem.cc:283] Unable to load driver at /Users/jp/Projects/osxpmem.app/MacPmem.kext
E1229 15:17:26.606714 3375588288 pmem_imager.cc:328] Imaging failed with error: -8

How usefully nondescript. Let me save you some time, as searching the system/kernel logs as suggested yields nothing useful.

So, instead, let’s use the native utility kextutil’s “test” parameter (-t) to see if that gets us anywhere…

$ sudo kextutil -t osxpmem.app/MacPmem.kext/
Diagnostics for osxpmem.app/MacPmem.kext:
Authentication Failures:
File owner/permissions are incorrect (must be root:wheel, nonwritable by group/other):
osxpmem.app/MacPmem.kext
Contents
_CodeSignature
CodeResources
Info.plist
MacOS
MacPmem

Nice. It finally tells us what’s wrong. The file ownership/permissions must be changed to “root:wheel”. Easy enough…

$ sudo chown -R root:wheel osxpmem.app/

So, let’s try again…

$ sudo osxpmem.app/osxpmem -o Memory_Captures/mem.aff4
Imaging memory
Creating output AFF4 ZipFile.
Reading 0x8000 0MiB / 8095MiB 0MiB/s
Reading 0xe38000 14MiB / 8095MiB 56MiB/s
Reading 0x1c88000 28MiB / 8095MiB 56MiB/s
Reading 0x2ac0000 42MiB / 8095MiB 56MiB/s
Reading 0x3978000 57MiB / 8095MiB 58MiB/s
Reading 0x47c8000 71MiB / 8095MiB 56MiB/s
Reading 0x5678000 86MiB / 8095MiB 58MiB/s
Reading 0x6500000 101MiB / 8095MiB 57MiB/s

Reading 0x1f7478000 8052MiB / 8095MiB 39MiB/s
Reading 0x1f7d68000 8061MiB / 8095MiB 35MiB/s
Reading 0x1f8708000 8071MiB / 8095MiB 38MiB/s
Reading 0x1f9150000 8081MiB / 8095MiB 41MiB/s
Reading 0x1f9c00000 8092MiB / 8095MiB 41MiB/s

YES! It worked! As you can see, my system has 8GB of memory that was (by default) exported to an AFF4 volume/file called “mem.aff4”.

You also have the option to include additional local files within the resulting AFF4 volume/file via the “-i </path/to/file> -i </path/to/file> …” command line option(s), which can be useful in producing a singular output volume containing not only memory but other files (binaries/logs/etc.) you’d like to analyze as well. In the past, I used this option to collect the local /bin/bash file when Volatility used to require the bash shell’s memory address be provided in order to parse command history and produce associated timestamps when using the linux_bash plugin. Though the documentation still shows it as a requirement, it’s actually not needed anymore and parses it all just fine.

In addition, you may also export the memory image to a singular RAW or ELF file by using the “–format elf” or “–format raw” command line options if that suits your fancy. However, for this post, I am using the default AFF4 output so that we may explore its use and features a bit.

So, without further ado, let’s take a look at the resulting AFF4 volume/file.

$ sudo osxpmem.app/osxpmem -V Memory_Captures/mem.aff4
Password:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix aff4: <http://aff4.org/Schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix memory: <http://aff4.org/Schema#memory/> .
<aff4://7f482355-5683-46bb-87c0-21afd75dbbeb/dev/pmem>
aff4:category memory:physical ;
aff4:stored <aff4://7f482355-5683-46bb-87c0-21afd75dbbeb> ;
a aff4:map .
<aff4://7f482355-5683-46bb-87c0-21afd75dbbeb/dev/pmem/data>
aff4:chunk_size 32768 ;
aff4:chunks_per_segment 1024 ;
aff4:compression <https://www.ietf.org/rfc/rfc1950.txt> ;
aff4:size 8488656896 ;
aff4:stored <aff4://7f482355-5683-46bb-87c0-21afd75dbbeb> ;
a aff4:image .
Objects in use:
Objects in cache:
aff4://7f482355-5683-46bb-87c0-21afd75dbbeb - 0
aff4://7f482355-5683-46bb-87c0-21afd75dbbeb/information.turtle - 0
file:///Users/jp/Projects/Memory_Captures/mem.aff4 - 0

Here, you can see that we extracted a memory image to the AFF4 stream “7f482355-5683-46bb-87c0-21afd75dbbeb/dev/pmem“.

Now, what can we do with this? Well, one thing you could do (if not using Rekall to analyze this image) might be to extract the AFF4 memory image stream into a singular raw file for parsing/analysis by other tools such as Volatility, page_brute, yara, strings, etc. To do that, we perform the following:

$ sudo osxpmem.app/osxpmem -e /dev/pmem -o Memory_Captures/mem.raw Memory_Captures/mem.aff4
Extracting aff4://7f482355-5683-46bb-87c0-21afd75dbbeb/dev/pmem into file:///Users/jp/Projects/Memory_Captures/mem.raw
Reading 0x8000 0MiB / 9968MiB 0MiB/s
Reading 0x750000 7MiB / 9968MiB 28MiB/s
Reading 0xde0000 13MiB / 9968MiB 25MiB/s
Reading 0x1480000 20MiB / 9968MiB 25MiB/s

Reading 0x26d938000 9945MiB / 9968MiB 21MiB/s
Reading 0x26deb8000 9950MiB / 9968MiB 21MiB/s
Reading 0x26e418000 9956MiB / 9968MiB 20MiB/s
Reading 0x26eab0000 9962MiB / 9968MiB 25MiB/s

$ ls -l Memory_Captures/
total 25665056
-rwxr-xr-x 1 root staff 2688302741 Dec 29 15:30 mem.aff4
-rwxr-xr-x 1 root staff 10452205568 Dec 29 16:10 mem.raw

As you can see, the raw image is uncompressed and thus substantially larger than the AFF4 volume (one of the useful features of AFF4 is its compression options). Nonetheless, there you have it. A raw memory image to parse to your heart’s content with whatever tools you like.

However, before we move on, I personally like to unload the kernel extension for one last good measure so that it’s not just hanging out there for no purpose.

$ sudo osxpmem.app/osxpmem -u
Unloading driver /Users/jp/Projects/osxpmem.app/MacPmem.kext

Creating a Memory Profile

Acquiring a memory image is great, but unfortunately is useless (with respect to Volatility) without the appropriate profile to parse it. Volatility requires a memory profile be specified when parsing a memory image via the “–profile=<profile>” command line option. By default, Volatility includes a ton of profiles for Windows, but such is not the case for Linux and Mac. Though a profiles repository has been created containing a substantial set of profiles for Linux and Mac, YMMV. In my situation, I’m running the latest MacOS Sierra release 10.12.3, for which no profile existed as of this post (nor did it for 10.12.2 until I created and submitted one to the repo as well :D). Therefore, I had to create my own profile. Luckily, the folks at Volatility do a great job walking us through building a profile on a Mac. Though, there are a few clarifications I’d like to address.

To begin, I need to provide some clarification/correction for the initial step, focusing on the part in italics:

“To create a profile, you first need to download the KernelDebugKit for the kernel you want to analyze. This can be downloaded from the Apple Developer’s website (click OS X Kernel Debug Kits on the right). This account is free and only requires a valid Email address.

After the DebugKit is downloaded, mount the dmg file. This will place the contents at “/Volumes/KernelDebugKit”.”

While the above statement is true, if you immediately dismount a package once it’s installed like I do, you should instead pay attention to the installer to see where it is putting the files for long term access. Independent of the mounted package, the KDK is installed in the following location, which will need to be referenced for future use once the package is dismounted post-install:

/Library/Developer/KDKs/KDK_<version>.kdk/

As of current, for macOS Sierra 10.12.2 and 10.12.3, the <version> will be “10.12.2_16C67” and “KDK_10.12.3_16D32.kdk“, respectively.

/Library/Developer/KDKs/KDK_10.12.2_16C67.kdk/
/Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/

Thus, “Step 1” for building a 10.12.3 profile would be the following (for a 64-bit 10.12.3 system):

$ dwarfdump -arch x86_64 /Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel.dSYM > 10.12.3_x64.dwarfdump

Also note that the referenced kernel file names vary from the current instructions (e.g., “mach_kernel.dSYM” is now “kernel.dSYM”, and “mach_kernel” is now just “kernel”). So, do exercise additional caution when running the commands. For ease of reference, below should be the locations for both of these files on a macOS Sierra 10.12.3 64-bit system (but note that this may change with future versions):

/Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel
/Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel.dSYM

All of the above is actually noted during the install as well:

To save everyone a bit of time and translation from current Volatility documentation, I’ve written out the latest required steps below for relatively easy copy/paste into your terminal. For this, we are using the latest 10.12.3 release and associated KDK as an example:

  1. Check to see if a profile is already available for your particular OSX version/release
    1. https://github.com/volatilityfoundation/profiles/tree/master/Mac
  2. If not, download and install the KDK appropriate for your current (or targeted) OSX version/release
    1. http://developer.apple.com/hardwaredrivers
  3. Get the dwarf debug info from the kernel.
    1. $ dwarfdump -arch x86_64 /Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel.dSYM > 10.12.3_x64.dwarfdump
  4. Convert the dwarfdump output to Linux style output readable by Volatility
    1. $ python tools/mac/convert.py 10.12.3_x64.dwarfdump converted-10.12.3_x64.dwarfdump
  5. Create the types from the converted file
    1. $ python tools/mac/convert.py converted-10.12.3_x64.dwarfdump > 10.12.3.64bit.vtypes
  6. Generate symbol information
    1. $ dsymutil -s -arch x86_64 /Library/Developer/KDKs/KDK_10.12.3_16D32.kdk/System/Library/Kernels/kernel > 10.12.3.64bit.symbol.dsymutil
  7. Create a zip file of the *.dsymutil and *.vtypes files
    1. $ zip 10.12.3.64bit.zip 10.12.3.64bit.symbol.dsymutil 10.12.3.64bit.vtypes
    2. **See note at end of instructions**
  8. Copy the zip file to to the volatility/plugins/overlays/mac/ directory (remember, we are already inside the root /volatility directory)
    1. $ cp 10.12.3.64bit.zip volatility/plugins/overlays/mac/
  9. Verify your profile is registered and ready for use
    1. $ python vol.py --info | grep "A Profile for Mac"
      1. The profile name presented is the string you will pass to the “–profile=” parameter when analyzing a memory image from this version/release in Volatility

**Note: While I append “x64” or “64bit” to my various output files to keep track of which architecture build I’m producing, doing so for the final .zip output file yields profile names with rather weird-looking duplicate 64-bit identifiers (e.g., “Mac10_12_3_64bitx64”). If you would like cleaner looking profile names (at the cost of losing the filename identifier denoting the arch build), you should instead drop the trailing identifier and provide a name the file like the following “10.12.3.zip”, thus yielding a prettier (IMO) profile name like “Mac10_12_3x64”.

Using Volatility for Analysis

Once we have successfully created the appropriate profile for the acquired image, we can now use the plethora of native Volatility Mac OSX plugins provided to us for analysis.

To see the list of available plugins, simply type the following:

#Executed from within the root /volatility folder of a git cloned repo
$ python vol.py --info | grep "mac_"

#Using the standalone binary
$ ./volatility_2.6_mac64_standalone --info | grep "mac_"

Conclusion

That pretty much wraps it up for this post. There is certainly more to explore with OSXpmem, the AFF4 format, and Volatility. However, I encourage you to explore it on your own as I would like to save some feature exploration for future in-depth posts focused on using both Volatility and the Rekall suite.

/JP

Did you enjoy this post? Share it!

Mac Dumpster Diving – Identifying Deleted File References in the Trash (.DS_Store) Files – Part 2

In Part 1 of this post, we identified where these artifacts reside along with options for parsing them. However, we still have not addressed why/how this anomaly occurs. Thus, in Part 2 of this post, we must now test to see how/why this occurs.

The behavior we’re seeing led me to the following hypothesis for testing:

  1. Although the .DS_Store file is “deleted”, when it is re-created it is created in the same space on disk within the same previously allocated blocks on the volume.
    1. *Note: This same situation often occurs on Windows when event logs are cleared/deleted and the event log file is re-created. The re-created log file often inhabits an area on disk surrounding previously deleted entries that may or may not be relevant to the current log at hand. Thus, carving of that file for entries can yield various event entries.
  2. The .DS_Store entries are stored somewhere else on disk and/or memory and are referenced and re-populated within the file upon re-creation for some reason (what reason, I have no idea).
  3. …or another theory that might make sense. (Please share your hypothesis or factual knowledge!)

I tested #1 above by using the “stat” command to see if a deleted and then re-created .DS_Store file would occupy the same inode and it does not. However, I still leave room for the possibility that even though a new inode is associated with the file each time it is re-created, it may still be somehow occupying (some of) the same space on disk.

I tested the on-disk aspect of #2 by searching across all files on disk for any references to a file that was previously deleted (since reboot) – the installer for BlockBlock named “BlockBlock_Installer.app”. The following files stood out to me:

$ sudo sift -z -a -l --err-skip-line-length BlockBlock_Installer.app /
...
/private/var/audit/20161217022600.crash_recovery
/private/var/db/uuidtext/AC/AF78F7097534A2A72631F3DD0AFE52
/private/var/folders/q4/r796r6tx2sd7zhjsxn2bjmv00000gn/0/com.apple.LaunchServices-175-v2.csstore
/private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/0/com.apple.LaunchServices-175-v2.csstore
/.Spotlight-V100/Store-V2/3AF86A9A-8A7B-414A-8479-E5FACBC49DF1/Cache/0000/0000/000f/997405.txt
...

While each of the above files did contain references to the given file name, none of them contained anything relevant to our research here to indicate they were the culprit of our .DS_Store file entry repopulation issue.

As an aside, the last entry was actually the Spotlight indexed (cached) Evernote page I have been using to take notes for this research 🙂 Do note that the Spotlight database and cache directories are also great places to search for references to deleted files as well, to possibly include full content that has been cached by indexing.

Moving on, I then tested the in-memory aspect of #2 by capturing a memory image (will author a separate blog post on doing this later) from my system and using Volatility’s yarascan and strings plugins to identify where in memory these entries may reside. I debated just showing the end results here, but I figure there is merit in showing how I got to the results as well. So, bonus for everyone!

Volatility’s yarascan plugin (specifically, mac_yarascan for our use on a Mac image) takes a yara rules file, finds matches across a memory image with the associated files/processes/memory areas, and (optionally) dumps the resulting files for analysis. So, this would seem rather useful for our situation here in trying to identify where in memory the historical deleted file references currently exist. To begin, I created the following yara rules file containing references to files that have been deleted from my system but whose entries still remain in the .Trash./DS_Store file.

rule ds_store_searches
{
strings:
$s1=”BlockBlock_Installer.app”
$s2=”canon-mx920-19_1_0a-ea11.dmg”
$s3=”FileZilla-Installer.app”
$s4=”SpotifyInstaller.zip”

condition:
any of them
}

As you can see, I’ve installed a few programs recently, the packages of which I deleted upon successful installation. However, these entries continue to be re-populated back into the .Trash/.DS_Store file on my system as I have not rebooted since I deleted them.

Using the latest release (2.6) of Volatility’s standalone OSX executable along with a custom macOS Sierra 10.12.2 profile I manually generated (and is now available in the Mac profiles repository for all to use!), I scanned the memory image for references to the above files using the mac_yarascan plugin as shown below.

$ ./volatility_2.6_mac64_standalone --plugins=/Users/jp/Projects/volatility/volatility/plugins/ --profile=Mac10_12_2_x64x64 -f ~/Projects/Memory_Captures/mem.raw mac_yarascan -A -y ~/Projects/Yara/ds_store.yar

I’m not going to lie to you, this ran for the better part of a day on my 2015 Core i5 MBA against an 8GB memory image. So, don’t expect speedy results from running this plugin.

=== Begin Sidebar ===

In comparison to the above, running Yara against the image took just under 3 minutes. However, the two tools are doing different things (to an extent) and producing different results.

Yara simply scanned the image and output the location(s) within memory where each hit was identified:

$ yara -s -p 8 ~/Projects/Yara/ds_store.yar mem.raw
0x1fd2cb6:$s1: BlockBlock_Installer.app
0xd380f26:$s1: BlockBlock_Installer.app
0x27b8d40c:$s1: BlockBlock_Installer.app
0x45dbd248:$s1: BlockBlock_Installer.app
0x46fa6195:$s1: BlockBlock_Installer.app

0x17efc11:$s2: canon-mx920-19_1_0a-ea11.dmg
0x1908620:$s2: canon-mx920-19_1_0a-ea11.dmg
0xd11f441:$s2: canon-mx920-19_1_0a-ea11.dmg
0x1831f101:$s2: canon-mx920-19_1_0a-ea11.dmg
0x42748dd1:$s2: canon-mx920-19_1_0a-ea11.dmg

0x1fd2c26:$s3: FileZilla-Installer.app
0x4dbb356:$s3: FileZilla-Installer.app
0x5c208e5:$s3: FileZilla-Installer.app
0x141bbf81:$s3: FileZilla-Installer.app
0x22be06cc:$s3: FileZilla-Installer.app
...
0x1fd22c6:$s4: SpotifyInstaller.zip
0xc5030c6:$s4: SpotifyInstaller.zip
0x41c95ee6:$s4: SpotifyInstaller.zip
0x54c9c5d9:$s4: SpotifyInstaller.zip
0x54c9c5f6:$s4: SpotifyInstaller.zip

These hits can be verified and further investigated by hexdump:

$ hexdump -C -s 0x1fd2cb6 -n 100 mem.raw
01fd2cb6 42 6c 6f 63 6b 42 6c 6f 63 6b 5f 49 6e 73 74 61 |BlockBlock_Insta|
01fd2cc6 6c 6c 65 72 2e 61 70 70 20 0a ad be b5 29 2e a8 |ller.app ....)..|
01fd2cd6 dd ba 80 f9 45 00 00 60 00 00 00 00 00 00 00 00 |....E..`........|
01fd2ce6 00 00 00 00 00 00 00 00 00 00 a4 fa ef 3d 33 33 |.............=33|
01fd2cf6 eb 3f 00 00 00 00 00 00 00 00 08 00 00 00 00 00 |.?..............|
01fd2d06 00 00 40 04 00 00 00 00 00 00 1b 04 00 00 00 00 |..@.............|
01fd2d16 00 00 00 98 |....|

While this is great and shows us that these historical references exist across a ton of areas within memory, it doesn’t really help us identify any useful context. Nonetheless, Yara is an incredibly useful tool that has a variety of purposes, so it’s just a matter of knowing your tools and which one you need to do a given job.

=== End Sidebar ===

Volatility’s mac_yarascan output provided a lot of useful results with context. Just what we needed! Below is a sample entry:

Task: lsd pid 230 rule ds_store_searches addr 0x10c0462bc
0x000000010c0462bc 46 69 6c 65 5a 69 6c 6c 61 2d 49 6e 73 74 61 6c FileZilla-Instal
0x000000010c0462cc 6c 65 72 2e 61 70 70 00 39 31 30 2e 2f 56 6f 6c ler.app.910./Vol
0x000000010c0462dc 75 6d 65 73 2f 52 65 63 6f 76 65 72 79 20 48 44 umes/Recovery.HD
0x000000010c0462ec 00 46 46 2d 2f 70 72 69 76 61 74 65 2f 76 61 72 .FF-/private/var
0x000000010c0462fc 2f 74 6d 70 2f 4d 50 50 5a 4c 50 52 50 00 69 6f /tmp/MPPZLPRP.io
0x000000010c04630c 6b 69 74 2e 2f 64 65 76 2f 64 69 73 6b 30 73 31 kit./dev/disk0s1
0x000000010c04631c 00 6c 79 00 2f 70 72 69 76 61 74 65 2f 74 6d 70 .ly./private/tmp
0x000000010c04632c 2f 44 64 6b 4a 57 79 6f 65 00 70 6c 2f 64 65 76 /DdkJWyoe.pl/dev
0x000000010c04633c 2f 64 69 73 6b 32 73 31 00 72 61 67 2f 56 6f 6c /disk2s1.rag/Vol
0x000000010c04634c 75 6d 65 73 2f 44 6f 63 73 00 6c 6f 2f 64 65 76 umes/Docs.lo/dev
0x000000010c04635c 2f 64 69 73 6b 32 73 31 00 00 00 00 2f 70 72 69 /disk2s1..../pri
0x000000010c04636c 76 61 74 65 2f 74 6d 70 2f 52 78 53 54 49 64 78 vate/tmp/RxSTIdx
0x000000010c04637c 41 00 63 73 2f 64 65 76 2f 64 69 73 6b 32 73 31 A.cs/dev/disk2s1
0x000000010c04638c 00 61 62 6c 2f 56 6f 6c 75 6d 65 73 2f 44 6f 63 .abl/Volumes/Doc
0x000000010c04639c 73 00 6c 6f 2f 64 65 76 2f 64 69 73 6b 32 73 31 s.lo/dev/disk2s1
0x000000010c0463ac 00 72 61 67 2f 55 73 65 72 73 2f 6a 70 2f 44 6f .rag/Users/jp/Do

While it identified references to the above files in a multitude of processes (a surprising amount, actually, that may need to be revisited in future research), we are trying to identify references to all of these files within a common process/context. So, the next step is to do a bit of analysis to see which process/context had at least 4 hits (because we had 4 file names to find). A bit of command line kung fu (gotta plug Hal Pomeranz‘s site, though *cough* he needs some new entries *cough*) yields the following:

$ grep 'Task:' ../Memory_Captures/mem.raw_yara_output | awk '{print $2}' | sort | uniq -c | sort -r
43 Finder
10 BlockBlock
6 mds
5 lsd
5 Google
2 loginwindow
2 coreservicesd
1 system_installd
1 sharingd
1 revisiond
1 pbs
1 mobileassetd
1 mdworker
1 crashpad_handler
1 configd
1 com.apple.geod
1 apsd
1 airportd
1 XprotectService
1 UserEventAgent
1 SubmitDiagInfo
1 Microsoft

We can weed out anything with less than 4 entries, leaving Google, lsd, mds, BlockBlock, and Finder. Google, lsd, and mds processes only had entries for FileZilla, so those are ruled out. BlockBlock is actually an awesome app by Patrick Wardle at Objective-See that watches for any applications that attempt persistence. So, it is of no surprise that all of these entries exist within its memory space as it has overseen each in their installation and alerted me if/when persistence (auto-start) mechanisms were implemented. Usefulness aside, it’s not our culprit here.

Now, we are left with Finder. So, let’s see what entries it found within the Finder process on my machine:

$ grep -A16 'Task: Finder' ../Memory_Captures/mem.raw_yara_output
Task: Finder pid 236 rule ds_store_searches addr 0x10ef4e2bc
0x000000010ef4e2bc 46 69 6c 65 5a 69 6c 6c 61 2d 49 6e 73 74 61 6c FileZilla-Instal
0x000000010ef4e2cc 6c 65 72 2e 61 70 70 00 39 31 30 2e 2f 56 6f 6c ler.app.910./Vol
0x000000010ef4e2dc 75 6d 65 73 2f 52 65 63 6f 76 65 72 79 20 48 44 umes/Recovery.HD
0x000000010ef4e2ec 00 46 46 2d 2f 70 72 69 76 61 74 65 2f 76 61 72 .FF-/private/var
0x000000010ef4e2fc 2f 74 6d 70 2f 4d 50 50 5a 4c 50 52 50 00 69 6f /tmp/MPPZLPRP.io
0x000000010ef4e30c 6b 69 74 2e 2f 64 65 76 2f 64 69 73 6b 30 73 31 kit./dev/disk0s1
0x000000010ef4e31c 00 6c 79 00 2f 70 72 69 76 61 74 65 2f 74 6d 70 .ly./private/tmp
0x000000010ef4e32c 2f 44 64 6b 4a 57 79 6f 65 00 70 6c 2f 64 65 76 /DdkJWyoe.pl/dev
0x000000010ef4e33c 2f 64 69 73 6b 32 73 31 00 72 61 67 2f 56 6f 6c /disk2s1.rag/Vol
0x000000010ef4e34c 75 6d 65 73 2f 44 6f 63 73 00 6c 6f 2f 64 65 76 umes/Docs.lo/dev
0x000000010ef4e35c 2f 64 69 73 6b 32 73 31 00 00 00 00 2f 70 72 69 /disk2s1..../pri
0x000000010ef4e36c 76 61 74 65 2f 74 6d 70 2f 52 78 53 54 49 64 78 vate/tmp/RxSTIdx
0x000000010ef4e37c 41 00 63 73 2f 64 65 76 2f 64 69 73 6b 32 73 31 A.cs/dev/disk2s1
0x000000010ef4e38c 00 61 62 6c 2f 56 6f 6c 75 6d 65 73 2f 44 6f 63 .abl/Volumes/Doc
0x000000010ef4e39c 73 00 6c 6f 2f 64 65 76 2f 64 69 73 6b 32 73 31 s.lo/dev/disk2s1
0x000000010ef4e3ac 00 72 61 67 2f 55 73 65 72 73 2f 6a 70 2f 44 6f .rag/Users/jp/Do
--
Task: Finder pid 236 rule ds_store_searches addr 0x6000001fd248
0x00006000001fd248 42 6c 6f 63 6b 42 6c 6f 63 6b 5f 49 6e 73 74 61 BlockBlock_Insta
0x00006000001fd258 6c 6c 65 72 2e 61 70 70 2f 1b 00 00 00 00 00 00 ller.app/.......
0x00006000001fd268 00 63 6f 6d 2e 6f 62 6a 65 63 74 69 76 65 53 65 .com.objectiveSe
0x00006000001fd278 65 2e 42 6c 6f 63 6b 42 6c 6f 63 6b 04 00 20 01 e.BlockBlock....
0x00006000001fd288 00 00 00 00 8e 00 10 00 02 00 00 00 c4 e5 c7 1d ................
0x00006000001fd298 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00006000001fd2a8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00006000001fd2b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00006000001fd2c8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00006000001fd2d8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00006000001fd2e8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00006000001fd2f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00006000001fd308 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00006000001fd318 00 00 00 00 00 00 00 00 47 09 00 00 00 00 00 00 ........G.......
0x00006000001fd328 00 00 00 00 00 00 00 00 47 0a 00 00 00 00 00 00 ........G.......
0x00006000001fd338 47 0b 00 00 00 00 00 00 47 0c 00 00 00 00 00 00 G.......G…….
--
Task: Finder pid 236 rule ds_store_searches addr 0x60000044e501
0x000060000044e501 63 61 6e 6f 6e 2d 6d 78 39 32 30 2d 31 39 5f 31 canon-mx920-19_1
0x000060000044e511 5f 30 61 2d 65 61 31 31 2e 64 6d 67 00 00 00 71 _0a-ea11.dmg...q
0x000060000044e521 91 d8 c5 ff ff 1d 00 8c 07 00 00 01 00 00 00 15 ................
0x000060000044e531 64 6e 67 2e 61 64 6f 62 65 2e 6e 69 6b 6f 6e 64 dng.adobe.nikond
0x000060000044e541 34 2e 63 61 6d 00 00 00 00 00 00 00 00 00 00 71 4.cam..........q
0x000060000044e551 91 d8 c5 ff ff 1d 00 8c 07 00 00 01 00 00 00 14 ................
0x000060000044e561 70 65 66 2e 70 65 6e 74 61 78 2e 37 37 39 37 30 pef.pentax.77970
0x000060000044e571 2e 63 61 6d 00 00 00 00 00 00 00 00 00 00 00 71 .cam...........q
0x000060000044e581 91 d8 c5 ff ff 1d 00 8c 07 00 00 01 00 00 00 10 ................
0x000060000044e591 61 72 77 2e 73 6f 6e 79 2e 32 39 36 2e 63 61 6d arw.sony.296.cam
0x000060000044e5a1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 ................
0x000060000044e5b1 9c d8 c5 ff ff 1d 00 01 00 00 00 00 00 00 00 00 ................
0x000060000044e5c1 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 02 ................
0x000060000044e5d1 00 00 00 00 00 00 00 d0 65 01 00 00 60 00 00 71 ........e...`..q
0x000060000044e5e1 91 d8 c5 ff ff 1d 00 8c 07 00 00 01 00 00 00 11 ................
0x000060000044e5f1 6e 65 66 2e 6e 69 6b 6f 6e 2e 64 39 30 2e 63 61 nef.nikon.d90.ca
--
Task: Finder pid 236 rule ds_store_searches addr 0x600000a48d41
0x0000600000a48d41 53 70 6f 74 69 66 79 49 6e 73 74 61 6c 6c 65 72 SpotifyInstaller
0x0000600000a48d51 2e 7a 69 70 00 00 00 00 00 00 00 00 00 00 00 51 .zip...........Q
0x0000600000a48d61 93 d8 c5 ff ff 1d 00 c3 14 00 00 01 00 00 00 48 ...............H
0x0000600000a48d71 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
0x0000600000a48d81 00 00 00 00 00 00 00 00 ab 1f 00 00 60 00 00 71 ............`..q
0x0000600000a48d91 91 d8 c5 ff ff 1d 00 8c 07 00 00 01 00 00 00 17 ................
0x0000600000a48da1 64 6e 67 2e 61 64 6f 62 65 2e 63 61 6e 6f 6e 65 dng.adobe.canone
0x0000600000a48db1 6f 73 6d 2e 63 61 6d 00 00 00 00 00 00 00 00 e0 osm.cam.........
0x0000600000a48dc1 41 db c5 ff 7f 00 00 01 00 00 00 00 00 00 00 c0 A...............
0x0000600000a48dd1 be 43 00 00 60 00 00 d8 be 43 00 00 60 00 00 d8 .C..`....C..`...
0x0000600000a48de1 be 43 00 00 60 00 00 00 00 00 00 00 00 00 00 71 .C..`..........q
0x0000600000a48df1 91 d8 c5 ff ff 1d 00 8c 07 00 00 0b 00 00 00 13 ................
0x0000600000a48e01 49 6e 73 74 61 6c 6c 20 53 70 6f 74 69 66 79 2e Install.Spotify.
0x0000600000a48e11 61 70 70 00 00 00 00 00 00 00 00 00 00 00 00 11 app.............
0x0000600000a48e21 9c d8 c5 ff ff 1d 00 01 00 00 00 00 00 00 00 00 ................
0x0000600000a48e31 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 02 ................
...

Sure enough, looks like we’ve likely found the harborer of our historical entries! And, it makes sense, as I surmise Finder is the process responsible for creating these .DS_Store files when they are moved to the trash. How might we be able to find out what process is responsible for creating this file? OSX has a nice little utility called fs_usage that can monitor all sorts of file system, disk, I/O aspects. For our purposes/testing here, we are going to filter on filesystem events and grep for the .Trash/.DS_Store file we care about while I go into Finder and delete (send to the Trash) a file:

$ sudo fs_usage -w -f filesystem | grep ".Trash/.DS_Store"
09:15:48.854558 fsgetpath /Users/jp/.Trash/.DS_Store 0.000010 Finder.2394967
09:15:49.357252 fsgetpath /Users/jp/.Trash/.DS_Store 0.000008 Finder.2395226
09:15:53.751509 getattrlist /Users/jp/.Trash/.DS_Store 0.000041 Finder.2395226
09:15:53.751556 fsgetpath /Users/jp/.Trash/.DS_Store 0.000008 Finder.2395226
09:15:53.751576 getattrlist /Users/jp/.Trash/.DS_Store 0.000019 Finder.2395226
09:15:53.751589 fsgetpath /Users/jp/.Trash/.DS_Store 0.000005 Finder.2395226
09:15:53.751717 fsgetpath /Users/jp/.Trash/.DS_Store 0.000007 Finder.2395226
09:15:53.751738 open F=21 (_W____) /Users/jp/.Trash/.DS_Store 0.000019 Finder.2395226
09:15:53.752898 HFS_update (__M_____) /Users/jp/.Trash/.DS_Store 0.000009 Finder.2395226
09:15:53.752905 HFS_update (__MN_c_m) /Users/jp/.Trash/.DS_Store 0.000003 Finder.2395226
09:15:53.752929 HFS_update (___N____) /Users/jp/.Trash/.DS_Store 0.000004 Finder.2395226
09:15:53.752956 HFS_update (___N_c_m) /Users/jp/.Trash/.DS_Store 0.000004 Finder.2395226
09:15:53.753005 HFS_update (_FMN_c_m) /Users/jp/.Trash/.DS_Store 0.000004 Finder.2395226
09:15:53.753157 getattrlist /Users/jp/.Trash/.DS_Store 0.000016 Finder.2395226
09:15:53.754084 WrData[AN] D=0x043832a0 B=0x5000 /dev/disk1 /Users/jp/.Trash/.DS_Store 0.001077 W Finder.2395226
09:15:53.804058 fsgetpath /Users/jp/.Trash/.DS_Store 0.000005 Finder.2395372
09:15:54.293014 lstat64 /Users/jp/.Trash/.DS_Store 0.000030 fseventsd.2395383

Sure enough, there it is. We can see Finder (re)creating the .Trash/.DS_Store file. Pretty cool, huh?

Now, why these entries are re-populated instead of just creating a blank/zero’ed file, we don’t yet quite know (this would take some more intensive inspection of the Finder code itself). Nonetheless, the Finder process definitely looks like a solid candidate responsible for (re)storing these these historical entries.

For even further testing and corroboration of our above findings (additional corroboration is ALWAYS a good idea in both investigations and research), we can use Volatility’s strings plugin. For most effective use, this plugin actually relies on a strings output file (fed as input to the plugin) with each string entry prepended with the decimal offset at which it was found (e.g., “102515331 file.dmg”). Keep in mind that in addition to the standard ASCII strings, we will also want to extract the Unicode 16-bit Big Endian strings as well.

Here we will use the GNU strings utility (gstrings on OSX via brew) to acquire this needed output. As a bit of a pro-tip, below is a great way to extract both ASCII and Unicode (16-bit Big Endian) in parallel using a FIFO queue:

$ mkfifo part-out
$ gstrings -a -td part-out > Memory_Captures/mem.raw.strings.ascii &

[1] 40780
$ cat Memory_Captures/mem.raw | tee part-out | gstrings -a -td -eb > Memory_Captures/mem.raw.strings.be

Once completed, let’s check out the format and see what it found for both the ASCII and Unicode Big-Endian strings:

$ sift "canon-mx920-19_1_0a-ea11.dmg" Memory_Captures/mem.raw.strings.ascii
25099281 canon-mx920-19_1_0a-ea11.dmg
26248704 ;/Volumes/Untitled/.Trashes/501/canon-mx920-19_1_0a-ea11.dmg
219280449 canon-mx920-19_1_0a-ea11.dmg
405926145 canon-mx920-19_1_0a-ea11.dmg
1114934737 canon-mx920-19_1_0a-ea11.dmg
1422508032 e: canon-mx920-19_1_0a-ea11.dmg
1913326497 canon-mx920-19_1_0a-ea11.dmg
4364841040 File: canon-mx920-19_1_0a-ea11.dmg
4454621776 File: canon-mx920-19_1_0a-ea11.dmg
4897694289 canon-mx920-19_1_0a-ea11.dmg
5379226560 ;/Volumes/Untitled/.Trashes/501/canon-mx920-19_1_0a-ea11.dmg
6315679704 File: canon-mx920-19_1_0a-ea11.dmg
7262910545 canon-mx920-19_1_0a-ea11.dmg
7624221584 File: canon-mx920-19_1_0a-ea11.dmg
7720217424 File: canon-mx920-19_1_0a-ea11.dmg
7720218576 File: canon-mx920-19_1_0a-ea11.dmg
8317281252 File: canon-mx920-19_1_0a-ea11.dmg
8317281288 File: canon-mx920-19_1_0a-ea11.dmg
8317283615 File: canon-mx920-19_1_0a-ea11.dmg
8317283651 File: canon-mx920-19_1_0a-ea11.dmg
8555763408 File: canon-mx920-19_1_0a-ea11.dmg
8800666640 File: canon-mx920-19_1_0a-ea11.dmg
8876241680 File: canon-mx920-19_1_0a-ea11.dmg
9351045649 canon-mx920-19_1_0a-ea11.dmg
9821317328 File: canon-mx920-19_1_0a-ea11.dmg
10051278021 $File: canon-mx920-19_1_0a-ea11.dmg
10051278106 $File: canon-mx920-19_1_0a-ea11.dmg
10058241281 canon-mx920-19_1_0a-ea11.dmg
10166913457 canon-mx920-19_1_0a-ea11.dmg
10166914465 canon-mx920-19_1_0a-ea11.dmg
10215457371 File: canon-mx920-19_1_0a-ea11.dmg
10215457407 File: canon-mx920-19_1_0a-ea11.dmg
10215459734 File: canon-mx920-19_1_0a-ea11.dmg
10215459770 File: canon-mx920-19_1_0a-ea11.dmg

And, now for Unicode Big-Endian:

$ sift "canon-mx920-19_1_0a-ea11.dmg" Memory_Captures/mem.raw.strings.be
5128627554 canon-mx920-19_1_0a-ea11.dmg
5128627664 canon-mx920-19_1_0a-ea11.dmg
5128627732 canon-mx920-19_1_0a-ea11.dmg
10079999330 canon-mx920-19_1_0a-ea11.dmg
10079999440 canon-mx920-19_1_0a-ea11.dmg
10079999508 canon-mx920-19_1_0a-ea11.dmg
10090625584 ile:///Users/jp/Downloads/canon-mx920-19_1_0a-ea11.dmg}

As we saw before when running our Yara scans against memory, we find many resident artifacts of our file name strings. A bit less in our Unicode output, but possibly useful findings nonetheless. No surprise here. But, let’s feed each of these into Volatility’s strings plugin to get some more context.

$ ./volatility_2.6_mac64_standalone --plugins=/Users/jp/Projects/volatility/volatility/plugins/ --profile=Mac10_12_2_x64x64 -f ~/Projects/Memory_Captures/mem.raw mac_strings -s ~/Projects/Memory_Captures/mem.raw.strings.ascii

And, now we wait… one day… two days… until Schrödinger’s cat got the best of me and I killed the process. After receiving a pro-tip from @attrc to filter down the strings file to just what we cared about (the 4 file names we put int our Yara rules file), I whittled it down to approximately 288 string entries (down from over 45 million – gah!) and re-ran it:

$ ./volatility_2.6_mac64_standalone --plugins=/Users/jp/Projects/volatility/volatility/plugins/ --profile=Mac10_12_2_x64x64 -f ~/Projects/Memory_Captures/mem.raw mac_strings -s ~/Projects/Memory_Captures/mem.raw.strings.ascii_FILTERED

…and waited another day before killing it and instead running it on a much faster desktop machine. Alas, it still took over a day to run on a 2.8GHz core i7 with 32GB memory, and yielded the following output:

25099281 [kernel:feacc17efc11] canon-mx920-19_1_0a-ea11.dmg
26248704 [kernel:feacc1908600] ;/Volumes/Untitled/.Trashes/501/canon-mx920-19_1_0a-ea11.dmg
33366720 [kernel:feacc1fd22c0] File: SpotifyInstaller.zip
33369120 [kernel:feacc1fd2c20] File: FileZilla-Installer.app
33369264 [kernel:feacc1fd2cb0] File: BlockBlock_Installer.app
81507152 [kernel:feacc4dbb350] File: FileZilla-Installer.app
96602320 [kernel:feacc5c208d0] +/Users/jp/Downloads/FileZilla-Installer.ap
...
10215459594 [kernel:feaf20e38b0a] File: BlockBlock_Installer.app
10215459626 [kernel:feaf20e38b2a] File: BlockBlock_Installer.app
10215459658 [kernel:feaf20e38b4a] File: BlockBlock_Installer.app
10215459734 [kernel:feaf20e38b96] File: canon-mx920-19_1_0a-ea11.dmg
10215459770 [kernel:feaf20e38bba] File: canon-mx920-19_1_0a-ea11.dmg
10230120017 [kernel:feaf21c33e51] BlockBlock_Installer.app

“kernel”? That’s it? No process association?

Well, that’s unfortunately less than useful for us. According to the wiki entry for the strings plugin, “For a given image and a file with lines of the form :, or , output the corresponding process and virtual addresses where that string can be found.” In reading that, I expected output similar to (or better than) the yarascan plugin in being able to pair the string hit(s) to the associated process. Alas, ’tis not the case.

Nonetheless, we seem to have some very useful findings to satisfy hypothesis #2.

Conclusion

In conclusion, while hypothesis #2 looks rather satisfied by our testing, we are still left with the following questions:

1) Why are these entries re-populated when a .DS_Store file is re-created?
2) What causes this behavior?
3) How is this information pulled into the re-created .DS_Store file?
4) Why are only certain files resident and not every file ever deleted from the machine?*
*My testing shows that the entries are purged upon reboot, so this last question is mostly answered. Though, we still don’t know why it happens.

If anyone has any insight into this, I would be INCREDIBLY interested to hear about it.

/JP

Did you enjoy this post? Share it!

Mac Dumpster Diving – Identifying Deleted File References in the Trash (.DS_Store) Files – Part 1

If you have ever plugged a USB drive into a Mac, done some things, then plugged it into a Windows system, you have no doubt seen (if you have viewing of hidden files enabled) various “.DS_Store” files (among others) strewn throughout the folders on the drive. Though essentially useless to a Windows system, they do in fact serve a particular purpose on an HFS+ file system.

While I won’t re-invent the wheel on describing “What is a .DS_Store File?” (here as well), I would like to highlight its possible use for DFIR in containing/referencing artifacts that may be useful to investigations – traces of deleted files, with filenames and sometimes paths!

In a nutshell, the .DS_Store file stores metadata used by Finder for folder-specific display options such as window placement, layout, custom icons, background, etc. Thus, these .DS_Store files are (theoretically) created in every folder that Finder accesses, even remote network shares and external devices. Are those annoying .DS_Store files you see in Windows on your FAT32-formatted thumb drive making more sense now?

A part of this metadata is the filename, which got me to thinking… I wonder whether or not any traces get left behind when a file is moved or deleted.

For this post/research, I focused solely on the deletion aspect of when a user deletes a file through Finder.

In testing on my systems (OS X 10.10.5 and macOS Sierra 10.12.2), when a file gets “deleted” through Finder (not via “rm” on the command line, that’s a very different story), it first gets moved to the user’s ~/.Trash/ folder. If at least one file already exists within the user’s Trash, an entry for the yet-to-be-deleted file is added to the existing ~/.Trash/.DS_Store file denoting the full path on disk where the file resided before being moved to the Trash. This entry is part of how the “Put Back” feature works. If no files currently exist in the Trash (due to the user previously emptying the trash), I assumed (more on this in a bit) a new .DS_Store file would be created (“new” meaning a clear/empty file) to again begin storing entries for “Put Back”. Upon emptying the trash (via either the “Empty Trash” or “Secure Empty Trash” option in Finder for pre-Sierra systems), the files are deleted (according to the deletion method associated with each action) from the ~/.Trash/ folder and the ~/.Trash/.DS_Store file is also “deleted” (stay tuned for why I put this in quotes). Here is a great little writeup on the HFS+ volume structure and what happens “When Mac deletes it!”.

At this point, since all of the Trash source files are deleted upon emptying the Trash, we would assume that the .DS_Store file and all of its entries would be deleted as well. But, is this the case?

Answer: Not Quite!

In my testing, while the source data files within the ~/.Trash/ folder appear to be reliably deleted (short of carving the disk), various file and path entries within the ~/.Trash/.DS_Store file do not appear to be deleted! In fact, when you move another file to the trash, the ~/.Trash/.DS_Store file is re-created and historical entries* are re-populated into the file! Even if you “Put Back” the file(s), the associated .DS_Store file and entries remain. WIN!


*Note: These appeared to only be files I’ve deleted since the last reboot of my machine. Rebooting the machine seems to finally remove all historical entries. Various hypotheses of why/how this happens and where these entries come from will be tested later in this post.

We now have the opportunity to identify references to historical file deletions (sometimes with full path)! This doesn’t just apply to the Trash’s .DS_Store files, either. This applies to any given directory’s .DS_Store file that may contain (or have contained) references to files that existed within it.

Pretty AWESOME, right? How many of you are already putting together the “find” command to identify all the .DS_Store files on your systems?

*Hint: # find / -name .DS_Store

But, we kinda started this whole story at the end, well after I had finished muddling my way through researching and experimenting to find out how to actually parse these .DS_Store files. So, let’s rewind a bit

Upon first look at a .DS_Store file, they aren’t exactly straight forward, and they can’t apparently be opened with any native system tool or application. There is no native “ds_store_viewer” utility that simply parses the file information from the command line. So, how would we be even go about trying to figure out how to parse this thing? After all, the information it contains does us no good if we can’t parse and extract it!

Your initial thought may be “strings!” That’s a solid idea to start, let’s see what that yields…

[jp@jp-mba (:) ~]$ strings -a ~/.Trash/.DS_Store
Bud1
pptbNustr
gptbLustr
xptbLustr
xptbNustr
gptbNustr
...
DSDB
gptbNustr
gptbLustr
gptbNustr
gptbLustr
gptbNustr
fptbLustr

Well, that was less than useful. Oh, wait… maybe they’re Unicode strings instead of ASCII. Let’s see what the option is for Unix strings to search for Unicode strings instead of ASCII:

[jp@jp-mba (:) ~]$ man strings

At this point you may already know what I’m about to say – the BSD strings utility does NOT have the capability to search for Unicode strings. Fail.

So, you can go a few different ways here:

  1. Stick with native utilities
  2. Install/use a third-party utility that can identify Unicode strings (particularly big-endian Unicode)
  3. Install/use a third-party utility that can directly read .DS_Store format files

Native Utilities

So, what else might exist that we can use to view strings?

When in doubt, Hex it out!

I typically use of two native hex viewers – hexdump and xxd. They are both useful in different ways, but we’ll start with hexdump.

Using hexdump, you can dump hex+ASCII by doing the following:

$ hexdump -C

[jp@jp-mba (:) ~]$ hexdump -C ~/.Trash/.DS_Store
00000000 00 00 00 01 42 75 64 31 00 00 38 00 00 00 08 00 |....Bud1..8.....|
00000010 00 00 38 00 00 00 10 0c 00 00 02 09 00 00 20 0c |..8........... .|
00000020 00 00 30 0b 00 00 00 00 00 00 00 00 00 00 08 00 |..0.............|
00000030 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 03 00 00 00 01 00 00 00 4e |...............N|
00000050 00 00 00 04 00 00 10 00 00 65 00 61 00 73 00 65 |.........e.a.s.e|
00000060 00 5f 00 44 00 00 00 00 00 00 00 00 00 00 00 00 |._.D............|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 00 00 00 00 00 00 00 02 00 00 00 02 00 00 00 04 |................|
00000210 00 00 00 30 00 50 00 6c 00 65 00 61 00 73 00 65 |...0.P.l.e.a.s.e|
00000220 00 5f 00 44 00 6f 00 63 00 75 00 53 00 69 00 67 |._.D.o.c.u.S.i.g|
00000230 00 6e 00 5f 00 74 00 68 00 69 00 73 00 5f 00 64 |.n._.t.h.i.s._.d|

Here we see the notable “Bud1” header followed by readable text. Score! But, how do we extract JUST the readable text in some effective way? You can mess around with hexdump to try to make sense of the output formats, or you could do like I did and get so overwhelmed at one point that you just use xxd to create this incredibly unpretty, certainly less than efficient, convoluted, but “working” one-liner:

$ xxd -p <path/to/.DS_Store> | sed 's/00//g' | tr -d '\n' | sed 's/\([0-9A-F]\{2\}\)/0x\1 /g' | xxd -r -p | strings | sed 's/ptb[LN]ustr//g'

Voilà. Strings output from Unicode strings only using the built-in utilities. It is very ugly and it is certainly separating at points/lines where it should not, but hey… you get what you get. At least you can more legibly make out filenames and paths that could get you somewhere.

This is an ugly hack. I do not recommend it, but sometimes ugly is better than nothing. YMMV.

Note: I would be very interested if someone who is WAY more versed in hexdump output formatting would create a much simpler way of doing the above solely using the hexdump utility.

Third-Party Utilities

GNU Strings

Believe it or not, you can actually install various GNU utilities on your Mac via a handy little thing called Homebrew. Just takes a command line one-liner to install and opens your Mac to world a new and useful utilities called “formulas”. Note that Xcode is a pre-req for installing Homebrew.

For our purposes, we want to install strings, which is a part of the GNU coreutils package. With homebrew installed, all it takes is a “brew install coreutils” and we’re up and running. Do note that various GNU utilities will be prepended with “g” due to naming conflicts. For example, the GNU strings utility must be called/run as “gstrings” (yeah, I laugh a little each time I see that).

Once installed, we now have full GNU strings capabilities, namely for searching big-endian Unicode text, a la the following:

$ gstrings -a -eb

You don’t necessarily need the “-a” option that tells strings “I don’t care whether or not you think it’s a searchable file, do it anyway”, but I add it out of habit of searching files that the system likes to gripe about.

Using FDB

https://digi.ninja/projects/fdb.php

  1. Enter CPAN shell
    1. $ perl -MCPAN -e shell
  2. Install DSStore
    1. $ cpan[1] > install Mac::Finder:DSStore
  3. Install Switch
    1. $ cpan[1] > install Switch
  4. Run FDB
    1. $ ./fdb.pl --type ds --filename /Users//.Trash/.DS_Store --base_url /Users//

Using ds_store Go Parser

https://github.com/gehaxelt/ds_store

  1. Download and Install Go
    1. Download OS X Package from here: https://golang.org/dl/
  2. Set Go Path in shell
    1. One-time (I set mine as the following but it’s up to you)
      1. $ export GOPATH=~/Projects/Go
    2. Permanent
      1. Place above line in /etc/bashrc
      2. Reload shell “source /etc/bashrc” or close and relaunch terminal
  3. Download ds_store go files
    1. $ go get github.com/gehaxelt/ds_store
  4. Change to the directory of the go project
    1. $ cd $GOPATH/src/github.com/gehaxelt/ds_store
  5. Make a directory for the new project/files (I opted to name mine “dsdump”, but feel free to alter yours) and cd to it
    1. $ mkdir -p bin/dsdump && cd "$_"
  6. (If not already done) Create a .go file (I named mine dsdump.go) and copy/paste the Example Code from https://github.com/gehaxelt/ds_store
    1. $ nano dsdump.go
    2. Copy/paste the Example Code into this file and save it
  7. Build the Go binary
    1. $ go build
  8. Run dsump
    1. $ ./dsump -i <path/to/.DS_Store>

**Note: One of the awesome things about Go is its ability to build static binaries (no additional files needed) for a variety of operating systems. For example, if you wanted to build a binary for a Windows x64 system, you would simply run “GOOS=windows GOARCH=amd64 go build -o dsdump.exe”. Then, just copy that to whatever Windows x64 system and run it. Pretty sweet, huh?

(Shout out to Slavik at Demisto for quickly getting me up and running with Go before I spent any time looking at documentation.)

Comparing the .DS_Store Parsing Solutions

At this point in my testing, I don’t think I would stick with only one solution, as each provides its own merits. A hex viewer is an invaluable tool for so many reasons, namely for assisting in identifying unknown structures, artifacts, or items within a given file. Gstrings offers an easy way to search for the appropriate strings with an easily installable pseudo-native utility. Fdb allows the option to specify the “base_url” to prepend its results with the appropriate path, based on the given .DS_Store file’s location. The ds_store Go parser does the job as well and it can be compiled to be portable to any major OS, which can be very handy in a Mac Forensics go-kit of sorts.

Regardless of why/how it occurs (which we’ll address in Part 2 of this post) and what option(s) you choose to parse/extract these items, you may now at least have an additional DFIR investigation method and artifact(s) to identify previously deleted files that are no longer resident on (allocated) disk.

Though we focused solely on .DS_Store files in this post, do note that it is not just .DS_Store files that can assist in identifying deleted files on a system. There are several other files/areas that should be searched for such investigations; however, I wanted to hone in on analysis of these files as it is possibly lesser known (at least in my research and experience).

At any rate, I hope this can be somehow useful in your investigations moving forward! As usual, YMMV, so I’m interested to hear feedback and stories of if/how this works in the field for everyone.

/JP

Did you enjoy this post? Share it!

Know Your Tools: Linux (GNU) vs. Mac (BSD) Command Line Utilities

Welcome to first post in the “Know Your Tools” series!

Without further ado…

Have you ever wondered if/how *nix command line utilities may differ across distributions? Perhaps it never even occurred to you that there was even a possibility the tools were any different. I mean, they’re basic command line tools. How and why could/would they possibly differ?

Well, I’m here to say… thy basic command line utilities art not the same across different distributions. And, the differences can range from those that can cause a simple nuisance to those that can cause oversight of critical data.

Rather than going into aspects of this discussion that have already been covered such as how Linux and BSD generally differ, I would instead like to focus on a few core utilities commonly used in/for DFIR artifact analysis and some caveats that may cause you some headache or even prevent you from getting the full set of results you’d expect. In highlighting the problems, I will also help you identify some workarounds I’ve learned and developed over the years in addressing these issues, along with an overarching solution at the end to install GNU core utilities on your Mac (should you want to go that route).

Let’s get to it.

Grep

Grep is one of the most useful command-line utilities for searching within files/content, particularly for the ability to use regular expressions for searching/matching. To some, this may be the first time you’ve even heard that term or “regex” (shortened version of it). Some of you may have been using it for a while. And, nearly everyone at some point feels like…

Amirite?

Regardless of whether this is your first time hearing about regular expressions or if you use them regularly albeit with some level of discomfort, I HIGHLY suggest you take the time to learn and/or get better at using them – they will be your most powerful and best friend for grep. Though there is a definite regex learning curve (it’s really not that bad), knowing how to use regular expressions translates directly to performing effective and efficient searches for/of artifacts during an investigation.

Nonetheless, even if you feel like a near master of regular expressions, equally critical to an expression’s success is how it is implemented within a given tool. Specifically for grep, you may or may not be aware that it uses two different methods of matching that can highly impact the usefulness (and more important, validity) of results returned – Greedy vs. Lazy Matching. Let’s explore what each of these means/does.

At a very high level, greedy matching attempts to find the last (or longest) possible match, and lazy matching attempts to find the first possible match (and stops there). More specifically, greedy matching employs what is called backtracking and look-behind’s but that is a separate discussion. Suffice to say, using an incorrect, unintended, and/or unexpected matching method can completely overlook critical data or at the very least provide an inefficient or invalid set of results.

Now having established some foundational knowledge about how grep searches can work, we will drop the knowledge bomb – the exact same grep expression on Linux (using GNU grep) may produce completely different or no results on Mac (using BSD grep), especially when using these different types of matching.

…What? Why?

The first time I found this out I spent an inordinate and unnecessary amount of time banging my head against a wall typing and re-typing the same expression across systems but seeing different results. I didn’t know what I didn’t know. And, well, now I hope to let you know what I didn’t know but painfully learned.

While there is an explanation of why, it doesn’t necessarily matter for this discussion. Rather, I will get straight to the point of what you need to know and consider when using this utility across systems to perform effective searches. While GREEDY searches execute pretty much the same across systems, the main difference comes when you are attempting to perform a LAZY search with grep.

We’ll start with GREEDY searches as there is essentially little to no difference between the systems. Let’s perform a greedy search (find the last/longest possible match) for any string/line ending in “is” using grep’s Extended Regular Expressions option (“-E”).

(Linux GNU)$ echo “thisis” | grep -Eo ‘.+is'
thisis
(Mac BSD)$ echo “thisis” | grep -Eo ‘.+is'
thisis

Both systems yield the same output using a completely transferrable command. Easy peasy.

Note: When specifying Extended Regular Expressions, you can (and I often do) just use “egrep” which implies the “-E” option.

Now, let’s look at LAZY searches. First, how do we even specify a lazy search? Well, to put it simply, you append a “?” to your matching sequence. Using the same search as before, we’ll instead use lazy matching (find the first/shortest match) for the string “is” on both the Linux (GNU) and Mac (BSD) versions of grep and see what both yield.

(Linux GNU)$ echo “thisis” | grep -Eo ‘.+?is'
thisis
(Mac BSD)$ echo “thisis” | grep -Eo ‘.+?is'
this

Here the fun begins. We did the exact same command on both systems and it returned different results.

Well, for LAZY searches, Linux (GNU) grep does NOT recognize lazy searches unless you specify the “-P” option (short for PCRE, which stands for Perl Compatible Regular Expressions). So, we’ll supply that this time:

(Linux GNU)$ echo “thisis” | grep -Po ‘.+?is'
this

There we go. That’s what we expected and hoped for.

*Note: You cannot use the implied Extended expression syntax of “egrep” here as you will get a “conflicting matchers specified” error. Extended regex and PCRE are mutually exclusive in GNU grep.

Note that Mac (BSD), on the other hand, WILL do a lazy search by default with Extended grep. No changes necessary there.

While not knowing this likely won’t lead to catastrophic misses of data, it can (and in my experience will very likely) lead to massive amounts of false positives due to greedy matches that you have to unnecessarily sift through. Ever performed a grep search and got a ton of very imprecise and unnecessarily large (though technically correct) results? This implementation difference and issue could certainly have been the cause. If only you knew then what you know now…

So, now that we know how these searches differ across systems (and what we need to modify to make them do what we want), let’s see a few examples where using lazy matching can significantly help us (note: I am using my Mac for these searches, thus the successful use of Extended expressions using “egrep” to allow for both greedy and lazy matching)…

User-Agent String Matching
Let’s say I want to identify and extract the OS version from Mozilla user-agent strings from a set of logs, the format of which I know starts with “Mozilla/“ and then contains the OS version in parenthesis. The following shows some examples:

  • Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
  • Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2226.0 Safari/537.36
  • Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.0 Safari/537.36
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36

Greedy Matching (matches more than we wanted – fails)
(Mac BSD)$ echo "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" | egrep -o 'Mozilla.+\)'
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko)

Lazy Matching
(Mac BSD)$ echo "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" | egrep -o 'Mozilla.+?\)'
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1)

Searching for Malicious Eval Statements
Let’s say I want to identify and extract all of the base64 eval statements from a possibly infected web page for analysis, so that I can then pipe it into sed to extract only the base64 element and decode it for plaintext analysis.

Greedy Matching (matches more than we wanted – fails)
(Mac BSD)$ echo "date=new Date(); eval(base64_decode(\"DQplcnJvcl9yZ=\")); var ua = navigator.userAgent.toLowerCase();" | egrep -o 'eval\(base64_decode\(.+\)'
eval(base64_decode("DQplcnJvcl9yZ=")); var ua = navigator.userAgent.toLowerCase()

Lazy Matching (matches exactly what we want)
(Mac BSD)$ echo "date=new Date(); eval(base64_decode(\"DQplcnJvcl9yZ=\")); var ua = navigator.userAgent.toLowerCase();" | egrep -o 'eval\(base64_decode\(.+?\)'
eval(base64_decode("DQplcnJvcl9yZ=“))

There you have it. Hopefully you are now a bit more informed not only about the differences between Lazy and Greedy matching, but also about the difference in requirements across systems.

Strings

Strings is an important utility for use in extracting “human-readable” strings from files/binaries. It is particularly useful in extracting strings from (suspected) malicious binaries/files to attempt to acquire some insight into what may be contained within the file, its capabilities, hard-coded domains/URL’s, commands, … the list goes on.

However, not all strings are created equal. Sometimes, Unicode strings exist within a file/program/binary for various reasons, those of which are also important to identify and extract. By default, the GNU (Linux) strings utility searches for simple ASCII encoding, but also allows you to specify additional encodings for which to search, to include Unicode. Very useful.

By default, the Mac (BSD) strings utility also searches for simple ASCII encoding; however, I regret to inform you that the Mac (BSD) version of strings does NOT have the native capability to search for Unicode strings. Do not ask why. I highly encourage you to avoid the rabbit hole of lacking logic that I endured when I first found this out. Instead, we should move on and instead just be asking ourselves, “What does this mean to me?” Well, if you’ve only been using a Mac to perform string searches using the native BSD utility, you have been MISSING ALL UNICODE STRINGS. Of all the pandas, this is a very sad one.

So, what are our options?

There are several options, but I personally use one of the following (depending no the situation and my mood) when I need to extract both Unicode and ASCII strings from a file using a Mac (BSD) system:
1. Willi Ballenthin’s Python strings tool to extract both ASCII and Unicode strings from a file
2. FireEye’s FLOSS tool (though intended for binary analysis, it can also work against other types of files)
3. GNU strings*

*Wait a minute. I just went through saying how GNU strings isn’t available as a native utility on a Mac. So, how can I possibly use GNU strings on it? Well, my friends, at the end of this post I will revisit exactly how this can be achieved using a nearly irreplaceable third-party package manager.

Now, go back and re-run the above tools against various files and binaries from your previous investigations you performed from the Mac command line. You may be delighted at what new Unicode strings are now found 🙂

Sed

Sed (short for “Stream editor”) is another useful utility to perform all sorts of useful text transformations. Though there are many uses for it, I tend to use it mostly for substitutions, deletion, and permutation (switching the order of certain things), which can be incredibly useful for log files with a bunch of text.

For example, let’s say I have a messy IIS log file that somehow lost all of its newline separators and I want to extract just the HTTP status code, method, and URI from each line and output into its own separate line (restoring readability):

…2016-08-0112:31:16HTTP200GET/owa2016-08-0112:31:17HTTP200GET/owa/profile2016-08-0112:31:18HTTP404POST/owa/test…

Looking at the pattern, we’d like to insert a newline before each instance of the date, beginning with “2016-…”. Lucky for us, we’re on a Linux box with GNU sed and it can easily handle this:

(Linux GNU)$ sed 's/ \(.+\?\)2016/\1\n2016/g' logfile.txt
2016-08-0112:31:16HTTP200GET/owa
2016-08-0112:31:17HTTP200GET/owa/profile
2016-08-0112:31:18HTTP404POST/owa/test
...

You can see that it not only handles lazy matching, but also handles ANSI-C escape sequences (e.g., \n, \r, \t, …). This statement also utilizes sed variables, the understanding of which I will leave to the reader to explore.

Sweet. Let’s try that on a Mac…

(Mac BSD)$ sed 's/\(.+\?\)\(.+\)/\1\n2016/g' logfile.txt
2016-08-0112:31:16HTTP200GET/owa2016-08-0112:31:17HTTP200GET/owa/profile2016-08-0112:31:18HTTP404POST/owa/test

… Ugh. No luck.

Believe it or not, there are actually two common problems here. The first is the lack of interpretation of ANSI-C escape sequences. BSD sed simply doesn’t recognize any (except for \n, but not within the replacement portion of the statement), which means we have to find a different way of getting a properly interpreted newline into the statement.

Below are a few options that will work around this issue (and there are more clever ways to do it as well).

1. Use the literal (i.e., for a newline, literally insert a new line in the expression)
(Mac BSD)$ sed ’s//\*Press Enter*
> /g'

2. Use bash ANSI-C Quoting (I find this the easiest and least effort, but YMMV)
(Mac BSD)$ sed 's//\'$'\n/g’
3. Use Perl
(Mac BSD)$ perl -pe ‘s||\n|g'

Unfortunately, this only solves the first of two problems, the second being that BSD sed still does not allow for lazy matching (from my testing, though I am possibly just missing something). So, even if you use #1 or #2 above, it will only match the last found pattern and not all the patterns we need it to.

“So, should I bother with using BSD sed or not?”

Well, I leave that up to your judgment. Sometimes yes, sometimes no. In cases like this where you need to use both lazy matching and ANSI-C escape sequences, it may just be easier to skip the drama and use Perl (or perhaps you know of another extremely clever solution to this issue). Options are always good.

Note: There are also other issues with BSD sed like line numbers and using the “-i” parameter. Should you be interested beyond the scope of this post, this StackExchange thread actually has some useful information on the differences between GNU and BSD sed. Though, I’ve found that YMMV on posts like this where the theory and “facts” may not necessarily match up to what you find in testing. So, when in doubt, always test for yourself.

Find

Of all commands, you might wonder how something so basic as find could differ across *nix operating systems. I mean, what could possibly differ? It’s just find, the path, the type, the name… how or why could that even be complicated? Well, for the most part they are the same, except in one rather important use case – using find with regular expressions (regex).

Let’s take for example a regex to find all current (non-archived/rotated) log files.

On a GNU Linux system this is somewhat straight forward:

(Linux GNU)$ find /var/log -type f -regextype posix-extended -regex "/var/log/[a-zA-Z\.]+(/[a-zA-Z\.]+)*"

You can see here that rather than using the standard “-name” parameter, we instead used the “-regextype” flag to enable extended expressions (remember egrep from earlier?) and then used the “-regex” flag to denote our expression to utilize. And, that’s it. Bless you, GNU!

Obviously, Mac BSD is not this straight forward, otherwise I wouldn’t be writing about it. It’s not exactly SUPER complicated, but it’s different enough to cause substantial frustration as your Google searches will show that the internet is very confused about how to do this properly. I know. Shocking. Nonetheless, there is value in traveling down the path of frustration here so that you don’t have to when it really matters. So, let’s just transfer the command verbatim over to a Mac and see what happens.

(Mac BSD)$ find /var/log -type f -regextype posix-extended -regex "/var/log/[a-zA-Z\.]+(/[a-zA-Z\.]+)*"
find: -regextype: unknown primary or operator

Great, because why would BSD find use the same operators, right? That would be too easy. By doing a “man find” (on the terminal, not in Google, as that will produce very different results from what we are looking for here) you will see that BSD find does not use that operator. Though, it still does use the “-regex” operator. Easy enough, we’ll just remove that bad boy:

(Mac BSD)$ find /var/log -type f -regex "/var/log/[a-zA-Z\.]+(/[a-zA-Z\.]+)*
(Mac BSD)$

No results. Ok. Let’s look at the manual again… ah ha, to enable extended regular expressions (brackets, parenthesis, etc.), we need to use the “-E” option. Easy enough:

(Mac BSD)$ find /var/log -E -type f -regex "/var/log/[a-zA-Z\.]+(/[a-zA-Z\.]+)*"
find: -E: unknown primary or operator

Huh? The manual says the “-E” parameter is needed, yet we get the same error message we got earlier about the parameter being an unknown option. I’ll spare you a bit of frustration and tell you that it is VERY picky about where this flag is put – it must be BEFORE the path, like so:

(Mac BSD) $> find -E /var/log -type f -regex "/var/log/[a-zA-Z\.]+(/[a-zA-Z\.]+)*"
/var/log/alf.log
/var/log/appfirewall.log
/var/log/asl/StoreData
/var/log/CDIS.custom
/var/log/corecaptured.log
/var/log/daily.out
/var/log/DiagnosticMessages/StoreData
/var/log/displaypolicyd.log
/var/log/displaypolicyd.stdout.log
/var/log/emond/StoreData
/var/log/install.log
/var/log/monthly.out
/var/log/opendirectoryd.log
/var/log/powermanagement/StoreData
/var/log/ppp.log
/var/log/SleepWakeStacks.bin
/var/log/system.log
/var/log/Tunnelblick/tunnelblickd.log
/var/log/vnetlib
/var/log/weekly.out
/var/log/wifi.log

Success. And, that’s that. Nothing earth shattering here, but different and unnecessarily difficult enough to be aware of in your switching amongst systems.

So, now what?

Are you now feeling a bit like you know too much about these little idiosyncrasies? Well, there’s no going back now. If for no other reason, maybe you can use them to sound super smart or win bets or something.

These are just a few examples relevant to the commands and utilities often used in performing DFIR. There are still plenty of other utilities that differ as well that can make life a pain. So, now that we know this, what can we do about it? Are we doomed to live in constant translation of GNU <—> BSD and live without certain GNU utility capabilities on our Macs? Fret not, there is a light at the end of the tunnel…

If you would like to not have to deal with many of these cross-platform issues on your Mac, you may be happy to know that the GNU core utilities can be rather easily installed on OS X. There are a few options to do this, but I will go with my personal favorite method (for a variety of reasons) called Homebrew.

Homebrew (or brew) has been termed “The missing package manager for OS X”, and rightfully so. It allows simple command-line installation of a huge set of incredibly useful utilities (using Formulas) that aren’t installed by default and/or easily installed via other means. And, the GNU core utilities are no exception.

As a resource, Hong’s Technology Blog provides a great walk-through of installation and considerations.

You may already be thinking, “Great! But wait… how will the system know which utility I want to run if both the BSD and GNU version are installed?” Great question! By default, homebrew installs the binaries to /usr/local/bin. So, you have a couple options, depending on which utility in particular you are using. Some GNU utilities (such as sed) are prepended with a “g” and can be run without conflict (e.g., “gsed” will launch GNU sed). Others may not have the “g” prepended. In those cases, you will need to make sure that /usr/local/bin is in your path (or has been added to it) AND that it precedes those of the standard BSD utilities’ locations of /usr/bin, /bin, etc. So, your path should look something like this:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

With that done, it will by default now launch the GNU version installed in /usr/local/bin instead of the standard system one located in /usr/bin. And, to use the native system utilities when there is a GNU version installed with the same name, you will just need to provide their full path (i.e., “/usr/bin/<utility>”).

Please feel free to sound off in the comments with any clever/ingenious solutions not covered here or stories of epic failure in switching between Linux and Mac systems 😃

/JP

Did you enjoy this post? Share it!

Powered by WordPress & Theme by Anders Norén