Here at the Happy Macs Lab, we have a unique issue. In the lab, you will find vintage Power Macintosh models, running everything from Mac OS 7.5.3 up through Mac OS 9.1, a maxed out Power Mac G4 Cube running all of Mac OS 9.2.2, Mac OS X Tiger and Mac OS X Leopard, Power Mac G5s running Mac OS X Tiger and Mac OS X Leopard, multiple older PCs running various versions of Linux and even a sampling of older Windows machines, running Windows NT 4.0, Windows 95, Windows 98SE, Windows ME, Windows 2000 and finally Windows XP. It is quite the “tower of babel” from a computing perspective, and getting all these machines to talk to each other is a real challenge.
- Richard - Part One Mac Os 11
- Richard - Part One Mac Os X
- New Mac Os 11
- Os Parts Online
- Download New Mac Os
- Richard - Part One Mac Os Download
- For those who want to install Mac OS X Snow Leopard on an Acer Aspire One D250, this tutorial has been optimized for you. This tutorial can work on other sys.
- Much like prior versions of Mac OS, you can easily create a bootable install drive for MacOS Mojave 10.14. These boot install drives allow for things like easily formatting a Mac to perform a clean install of macOS Mojave, installing macOS Mojave onto multiple Macs without them each having to download the installer, or even as a troubleshooting tool since it can be booted from by any.
- Newest compatible operating system: macOS High Sierra 10.13.6 Tech Specs: MacBook Pro (15-inch, Late 2011) User Guide: MacBook Pro (15-inch, Late 2011) MacBook Pro (13-inch, Late 2011) Model Identifier: MacBookPro8,1 Part Numbers: MD314xx/A, MD313xx/A Newest compatible operating system: macOS High Sierra 10.13.6.
- An application that plays the go-between for the commands that you enter and the Unix kernel at the core of Mac OS X. There are in fact several shells available. By default Mac OS X uses a shell called tcsh. O'Reilly Network: Learning the Mac OS X Terminal: Part 1 3/11/02 1:10 PM.
Its successor Mac OS X 5 also ran on PowerPC when it first launched; it wasn’t until 10.4 that Apple began to switch to Intel processors instead, and 10.6 when PowerPC was finally dropped. Mac OS X was a huge step forward from Mac OS 9 in a number of ways, including preemptive multitasking so that you could actually run multiple things at.
Happily, there are multiple solutions that achieve the desired result, and this blog post is the first of a series where we will look at the best of them, one by one. Some of the solutions are point-to-point, connecting just one OS to one other OS (such as Mac OS to Windows), and some are all encompassing, connecting everything to everything.
In this first post of the series, we will look at the first of two “traditional” point-to-point solutions for connecting Mac OS Classic and Windows, Thursby Software’s Dave. In the second post of this series, we will examine the other classic solution to this problem, Connectix’s DoubleTalk.
Throughout this series of networking posts, “Mac OS Classic” is used to imply Mac OS 9.x and lower, and specifically excludes all versions of Mac OS X. Similarly, throughout this series of posts, “Windows” implies Windows NT 4.0 and higher. For the purposes of this series, I used two principal Macs, a Power Macintosh 7500/100, upgraded with a NewerTech 366 MHz G3, and running Mac OS 8.6, and a fairly stock Power Macintosh 7300/200 running Mac OS 9.1. I used a 200 MHz dual CPU Pentium Pro PC running Windows NT 4.0 as the Windows representative in this networking duet.
Hoggy 2 mac os. Windows, Networking and SMB
OK, lets get going. A little background is in order first. Windows communicates with the networked world using the Server Management Block (SMB) protocol, renamed CIFS (Common Internet File System) in later versions of Windows. Pretty much all versions of Windows since Windows NT 3.x have incorporated both an SMB server and an SMB client, meaning that the OS can both read and write other SMB-based machines and can itself be read and written by those same other machines. I have seen, but not yet been able to confirm, that even the creaky Windows for Workgroups 3.11 included an SMB capability.
Since Windows speaks SMB, if a Mac wants to engage in file sharing with a Windows platform, it needs to speak SMB as well. Functionally speaking, this means that it needs to implement an SMB server and /or an SMB client. The two well-regarded third party applications mentioned above, Thursby Software’s Dave and Connectix’s DoubleTalk, do just this.
Thursby’s Dave seems to be the preferred solution in this space, although both garner a recommendation on Apple’s website.
Dave is preferred because it implements both an SMB server and an SMB client, while DoubleTalk only implements and SMB client. Having both an SMB server and an SMB client, a Dave-equipped Mac can seamlessly read and write files to and from a Windows machine and that Windows machine can seamlessly read and write files to and from the Mac.
Installing and Configuring Dave
I tested Dave and can attest that this is all true. I loaded Dave onto my Power Macintosh 7500, running Mac OS 8.6, and took it for a spin. The above mentioned 200 MHz Pentium Pro PC, running Windows NT 4.0, acted as its Windows counterpart in this testing.
Now before we go any further, there is a pink elephant in the room that we should all acknowledge. Astonishingly, not only is Thursby still a going commercial concern, Dave is still an active product at Thursby, and they want a staggering $119 for a current license for it! This will no doubt stop many folks from experimenting with it further.
Of course, the Dave software, and license numbers for it, are available from multiple “abandonware” sites, but none of the licenses I could find this way worked – all were rejected by Dave as “expired”. Thursby has protected their product well. Already having a valid Dave 4.0 license, I was able to proceed, but those of you not in this happy position will need to either pony up a big $119 to Thursby, or make your peace with trolling the web in search of non-expired licenses. I did this yesterday as a test, and successfully unearthed multiple apparently valid licenses. A little bit of persistence may serve you well in this area.
In an effort to save would be users of Dave from having to pay the hefty $119 fee for what is fundamentally an obsolete product, I queried Thursby’s email support, asking if they would be willing to provide a free license, given the lack of remaining commercial trade in Mac OS 9.x and below. The answer back was a firm “no”, followed by an admonition that Dave should not be considered abandonware. The response concluded with a request to know where I had downloaded Dave from! Realizing that this line of inquiry was not likely to result in a free Dave license, I abandoned it and moved on.
I will leave the licensing issue in your capable hands. Moving on, I can report that Dave is an excellent product. It was simple to install and configure, easy to use, and 100% effective at doing what it said it would do.
Installation and setup was a snap.
Richard - Part One Mac Os 11
Dave’s setup runs you through a few simple questions, the most complex of which may be its query for your workgroup name. If you don’t know the answer, just type in “WORKGROUP”, which is what most PCs default it to. Confirm this by visiting the Network control panel of the PC you are trying to connect to, and change the name on the PC side or the Mac side, if need be. Once the installation is done, you will need to restart your Mac and then you are ready to network with your PC friends.
Networking with Dave: Mac to PC
Networking with Dave from a Mac to a PC is quite intuitive, in a very Mac OS Classic sort of way – you go through Chooser, just like you would for the native form of Mac networking. In Chooser, you will now be greeted by a new connection type in the left hand pane, Dave Client.
When you click this, there will be a disconcerting pause, during which you will wonder whether Dave is working at all, and then the right hand pane will suddenly populate, hopefully showing you the PCs you want to share files with (and anything else on your network that has an SMB server – in my case, this included two Power Mac G5s and my current main Mac, a 2012 27” iMac).
Double click the entry for the PC of interest (in this case it was DualPro200 – so named because it is a dual CPU Pentium Pro 200 MHz) and you will get the expected password prompt. Enter the correct user name and password (this is the user name and password from the PC, or just select Guest instead) and Chooser will pop up a dialog showing the “shares” on the selected PC that are available for you to choose from (a “share” is SMB-speak for an available, shared folder).
Richard - Part One Mac Os X
You may just run into some trouble here – I did. Initially, the share list was blank! There is not a lot of latitude to share files when the list of possible sharing targets is empty! Happily, Dave provides an “Add Share” button below the list, and I took advantage of this to add the shared folders on the PC to the dialog.
This point requires a brief moment of explanation. When you share a folder in Windows NT 4.0, you give it a “Share Name”. This name should show up in the list of available shares that Dave presents you, but in my case, it did not. The share name did show up in the list of available shares when I connected to the PC from either of my Power Mac G5s, but did not from my older Power Macintosh 7300 or 7500 machines. The reason for this will be explained in a postscript at the end of this post.
For now, I was presented with a blank list of shares, but had the potential of adding shares through the Dave “Add Share” dialog. Back at the Pentium Pro PC, I went to Control Panels -> Server, and clicked the Shares button. This presented me with the following list of the available shares:
As you can see there were a LOT of shares there, but most ended with the “$” sign, indicating that they were administrative shares, automatically created by and internal to Windows NT, and not generally advertised for external connection (although they can be connected to if you wish).
I took note of three shares of interest, C$, D$ and DP200SharedFolder, which corresponded to C:, D: and the folder I was actually trying to share, DP200SharedFolder. One by one, using Dave’s Add Share button, I added these to the list, and they worked. When I double clicked any one of them, Dave promptly mounted the appropriate share on the Windows NT machine and at that point, I could drag and drop, read files, create folders, and in general, do all the things I could do with any local file folder.
I must apologize for the loss of continuity in the screen shot above. The share name mounted on the desktop is different from what is described – I no longer have the original screen shot.
Setting aside the cause of the blank list of shares for a moment, Dave’s Add Share dialog allowed me to work around a potentially show stopping issue and arrive at networking success, at least in the Macintosh to PC direction. What about the other direction, PC to Macintosh?
Networking with Dave: PC to Mac
This was not such a happy story initially. The Power Macintosh 7500 simply did not show up at all in the Network Neighborhood of the PC, nor could I see it in the Network selection of the two G5s I have on the network (both running 10.4.11 Tiger). Guessing that Dave’s SMB server was not enabled, I went hunting for a Dave Control Panel on the Macintosh. Nope, no such thing. There WAS a NetBIOS control panel with Dave labeling in it, so I hunted around in there, but there were no obvious selections to enable or disable visibility of the SMB Server.
My next stop was the Dave installation in the Macintosh’s Applications folder. There was a single file there, a program named, appropriately enough, Dave. Following this obvious lead, I launched the program, selected Dave Sharing and was greeted with what amounts to a Dave control panel.
Of course I immediately noticed that File Sharing was off, which would imply that the Dave SMB Server was not running. I enabled this and then checked to see if Dave was sharing any folders. The list at the top of the window was empty suggesting that it was not. Using Finder, I dropped my AppleTalk shared folder, “PowerMac7300SharedFolder” into the list. It “took” and thereafter, Dave showed that it was sharing this folder. It did warn me that shares with names over 12 characters long might not share properly, but I ignored that for the moment.
Again I must offer my apologies for the discontinuity in the image above – the file share name is slightly different from what I have described – I seem to have misplaced the original screenshot.
Back at the Windows NT machine, success. The Power Macintosh 7500 now showed up in the Network Neighborhood. I double clicked the icon, full of confidence that I had solved the problem, and was greeted with … a blank window. The PC could see the Macintosh, but the Macintosh didn’t appear to be sharing anything. I checked this with both of the G5s, and Tiger pretty much agreed – there was nothing being shared. Tiger’s rather obscure way of indicating this to me was to tell me that it could not open the alias because the original item could not be found. Somewhat of a misleading error indication, but I got the message. Something was still definitely wrong at the Macintosh end.
I went back to the Dave application and removed the current folder I was sharing, suspecting that either you could not share a folder over both AppleTalk and SMB, and/or perhaps the file name really DID have to be 12 characters or less. I created a new folder called “PMAC7500-SMB” (EXACTLY 12 characters) and dropped it into the Dave “Shares” list. I specifically did not share this folder through the usual Mac OS way of doing this – it was only shared via Dave’s SMB server.
This did the trick. The Network Neighborhood window that I got when I doubled clicked the icon for the Power Macintosh 7500 now presented one accessible folder, PMAC7500-SMB. This folder could be opened, read, written to… it was fully accessible. Success! PC to Macintosh networking was now up and running as well.
Networking with Dave – Summary
With both Mac to PC and PC to Mac networking up and running, I can now summarize the recipe for success with Dave:
- On the Macintosh side, make sure you have a unique share folder for Dave, and make sure that the name of that folder is less than 12 characters. Do not share this folder via the normal Mac OS Sharing mechanism. Share it only via Dave.
- On the PC side, make sure that you have one or more shared folders, and take note of the “Share As” name you assign to each. Like the Macintosh side, keep the filename of each shared folder to 12 characters or less as well.
- Still on the PC side, if you CANNOT keep the share names to 12 characters or less (perhaps the machine is not under your control), compensate for this on the Macintosh side. On that side, when you use Chooser to select the PC, if you are greeted with a blank list of available shares, use Dave’s Add Share button to manually add the shares whose names you took note of in the last step. You will only have to do this once. Dave remembers the names.
- That’s it! Apply the above and you should be happily networking in both directions between a Macintosh running Dave and a PC running Windows NT 4.0.
Closing Thoughts
A final note on Dave. Dave will very considerately interrupt the Macintosh shutdown sequence to warn you if it is hosting any connected users, giving you a chance to warn them before their favorite Mac suddenly disappears from cyberspace. As I said above, Thursby has done a very nice job.
That’s it for this post. In our next post on networking, we will look at doing the same sort of thing using the other classic application in this space, Connectix DoubleTalk. Until then, happy networking with Dave!
The Promised Postscript on The Empty Share List Problem
p.s.> A postscript to this story. As outlined above, the “empty list of shares” problem is easily resolved. Reasoning that since Dave warned that Macintosh share names over 12 characters might not share correctly, I concluded that perhaps share names on the Windows NT side should ALSO be 12 characters or less. I went back to the Windows NT 4.0 machine and checked the length of the share name for the folder I was trying to share. Sure enough, it was MUCH longer than 12 characters. When I shortened it to 12 characters (8 characters actually, in this case), it showed up instantly in the Chooser selections of both Mac OS Classic machines. So, one final word to the wise – all share names should be 12 characters or less.
And as if that is not enough, Windows NT 4.0 gently reminds you that if you want the share to be visible to DOS and Windows 3.x class machines, its’ name needs to be 8 characters or less! Just so you know…. ?
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. They are created in the parent folder of any folder that is viewed using the “Icons”, “List”, or “Gallery” views within Finder. Note that no .DS_Store file is created when viewing a folder in the “Columns” view. For example, if you opened your ~/Music/iTunes/ folder in Finder in “Gallery” view, a .DS_Store file would be created at ~/Music/.DS_Store.
Thus, these .DS_Store files are (theoretically) created in every folder that Finder accesses, including 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?
New Mac Os 11
Well, it turns out the .DS_Store format is documented here. Given its format is published, it’s likely a parser already exists for it. But, sometimes I just like to see what I can find myself before I go an easy(er) route. So, how should we start exploring what’s inside these files?
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. Hextraterrestrials mac os. 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. See my post “Know Your Tools: Linux (GNU) vs. Mac (BSD) Command Line Utilities” for more about all of that and why.
Fail.
So, you can go a few different ways here:
![One One](https://media.s-bol.com/733JKvvDDP5Q/550x830.jpg)
- Stick with native utilities
- Install/use a third-party utility that can identify Unicode strings (particularly big-endian Unicode)
- 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})/0x1 /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
- Enter CPAN shell
$ perl -MCPAN -e shell
- Install DSStore
$ cpan[1] > install Mac::Finder:DSStore
- Install Switch
$ cpan[1] > install Switch
- Run FDB
$ ./fdb.pl --type ds --filename /Users//.Trash/.DS_Store --base_url /Users//
Using ds_store Go Parser
https://github.com/gehaxelt/ds_store
- Download and Install Go
- Download OS X Package from here: https://golang.org/dl/
- Set Go Path in shell
- One-time (I set mine as the following but it’s up to you)
$ export GOPATH=~/Projects/Go
- Permanent
- Place above line in /etc/bashrc
- Reload shell “
source /etc/bashrc
” or close and relaunch terminal
- One-time (I set mine as the following but it’s up to you)
- Download ds_store go files
$ go get github.com/gehaxelt/ds_store
- Change to the directory of the go project
$ cd $GOPATH/src/github.com/gehaxelt/ds_store
- Make a directory for the new project/files (I opted to name mine “dsdump”, but feel free to alter yours) and cd to it
$ mkdir -p bin/dsdump && cd '$_'
- (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
$ nano dsdump.go
- Copy/paste the Example Code into this file and save it
- Build the Go binary
$ go build
- Run dsump
$ ./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.)
— Update 7/31/19 --
Using DSStoreParser
Nicole Ibrahim recently presented at the SANS DFIR Summit on .DS_Store files and pointed us all to a parser she built.
https://github.com/nicoleibrahim/DSStoreParser
Using it is as simple as downloading it and running it (with Python2.7).
- Download the source
$ git clone https://github.com/nicoleibrahim/DSStoreParser.git
- Change into the directory
$ cd DSStoreParser
- Install the requirements (unicodecsv), if needed
$ pip2.7 install unicodecsv --user
- Run it by pointing it to the source folder containing the .DS_Store file(s) you’d like to parse, and provide the output folder for the results
$ python2.7 DSStoreParser.py -s /path/to/source/ -o output_dir/
Comparing the .DS_Store Parsing Solutions
Os Parts Online
As you can see, there are a variety of useful tools, both native and third-party, that can assist in analyzing .DS_Store files. 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. And, Nicole’s DSStoreParser is a nice, clean Python-based solution that provides a variety of output reports to better assist in seeing/understanding the information contained within the files.
Wrapping It All Up
Regardless of why/how this ~/Trash/.DS_Store file re-creation 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).
Download New Mac Os
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.
Richard - Part One Mac Os Download
/JP