Silk Road forums
Discussion => Security => Topic started by: astor on April 15, 2013, 06:56 pm
-
Once in a while we get questions here in the Security forum about how to erase all evidence of Tor on a computer. Is it enough to simply delete the browser bundle folder? I'm a paranoid person and usually recommend a full disk wipe, even though LE is not going to forensically analyze the free disk space of the average SR user. Mainly my recommendation comes from not knowing what the TBB is leaving behind.
Finally we have answers! Runa Sandvik of the Tor Project is forensically analyzing the traces left behind by the TBB on Linux, Windows and OS X. Her first analysis, published a few days ago, covers Linux (specifically Debian).
======
As part of a deliverable for two of our sponsors (Sponsor J, Sponsor L), I have been working on a forensic analysis of the Tor Browser Bundle. In this three part series, I will summarize the most interesting or significant traces left behind after using the bundle. This post will cover Debian Linux (#8166), part two will cover Windows 7, and part three will cover OS X 10.8.
Process
I set up a virtual machine with a fresh install of Debian 6.0 Squeeze, logged in once and shut it down cleanly. I then connected the virtual drive to another virtual machine and used dd to create an image of the drive. I also used hashdeep to compute hashes for every file on the drive, and rsync to copy all the files over to an external drive.
After having secured a copy of the clean virtual machine, I rebooted the system, connected an external drive, and copied the Tor Browser Bundle (version 2.3.25-6, 64-bit) from the external drive to my Debian home directory. I extracted the package archive and started the Tor Browser Bundle by running ./start-tor-browser inside the Tor Browser directory.
Once the Tor Browser was up and running, I browsed to a few pages, read a few paragraphs here and there, clicked on a few links, and then shut it down by closing the Tor Browser and clicking on the Exit-button in Vidalia. The Tor Browser did not crash and I did not see any error messages. I deleted the Tor Browser directory and the tarball using rm -rf.
I repeated the steps with dd, hashdeep, and rsync to create a copy of the tainted virtual machine.
Results
Using hashdeep, I compared the hashes from the tainted virtual machine against the hashes from the clean virtual machine: 68 files had a hash that did not match any of the hashes in the clean set. The most interesting files are:
~/.local/share/gvfs-metadata/home: contains the filename of the Tor Browser Bundle tarball: tor-browser-gnu-linux-x86_64-2.3.25-5-dev-en-US.tar.gz. GVFS is the virtual filesystem for the GNOME desktop, so this result will probably vary depending on the window manager used. I have created #8695 for this issue.
~/.xsession-errors: contains the following string: “Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3800089 (Tor Browse)”. It is worth noting that a file named .xsession-errors.old could also exist. I have created #8696 for this issue.
~/.bash_history: contains a record of commands typed into the terminal. I started the Tor Browser Bundle from the command line, so this file contains lines such as ./start-tor-browser. I have created #8697 for this issue.
/var/log/daemon.log, /var/log/syslog, /var/log/kern.log, /var/log/messages: contains information about attached devices. I had an external drive attached to the virtual machine, so these files contain lines such as “Mounted /dev/sdb1 (Read-Write, label “THA”, NTFS 3.1)” and “Initializing USB Mass Storage driver…”.
======
She doesn't discuss the results, but I find them interesting. The bash commands in the history file are obvious (and won't exist when starting TBB from the file manager or a menu item), but I didn't expect the TBB archive filename to show up in something called gvfs-metadata. I wonder if there is some way to prevent that? And if there isn't at least you now know to shred the files in that folder!
Mitigation strategies are mentioned in the bug reports below.
In her next blog post, she will cover Windows. I bet there will be a lot more traces.
References
https://blog.torproject.org/blog/forensic-analysis-tor-linux
https://trac.torproject.org/projects/tor/ticket/8166
https://trac.torproject.org/projects/tor/ticket/8695
https://trac.torproject.org/projects/tor/ticket/8696
https://trac.torproject.org/projects/tor/ticket/8697
-
good stuff from Astor as always
-
Wow. I wouldn't have expected a single execution of the bundle to provide such obvious records that it was used. BTW, gvfs is the "GNOME virtual file system" stuff. I know very little about it, but it basically provides exactly what the acronym suggests -- virtual file system services for GNOME projects (or any other software that uses their VFS).
It disturbs me a little, as I think it has some kind of syncing capabilities, but it obviously doesn't disturb me enough to bother looking it up. Then again, I don't use Ubuntu or GNOME, so... it's not a priority for me.
-
The first item she listed isn't an issue for most people, since they'll start Tor from their desktop / file manager, not the command line.
The second item is the most troubling, since I think very few of us are/were aware of it.
The third item may only be an error when starting Tor from the command line. I grepped my own .xsession-errors and got nothing.
The fourth item is only an issue when attaching external media, which is not the most common method of getting the browser bundle. Most people will simply download it.
There may be other traces left behind when starting TBB from the file manager, which this analysis would have missed. An example is recently-used.xbel. Launching from a menu or panel item doesn't leave a trace that I know of.
Will be interesting to see how many traces are left on Win7.
Also, none of this even touches true forensic analysis of free and swap space.
To me, the take away message is, use FDE or Tails, or forget about trying to cover up your Tor use.
-
There's actually a very simple solution:
1. Create a new user 'tbb'.
2. Edit /etc/fstab and put both /var/log and /home/tbb in tmpfs.
3. $ sudo mount -o remount -a && sudo -u tbb -i
4. Download and extract TBB.
5. Use it, and when you're done...
6. $ logout && sudo mount -o remount -a
There will be no trace left of you ever downloading or using TBB.
You can also do something like this before running TBB with your regular user:
$ ln -s /dev/null ~/.xsession-errors
-
Is bleachbit a solution for this?
-
Is it possible to remove all traces of tbb on windows?
-
Subbing for future reference ;)
-
The first item she listed isn't an issue for most people, since they'll start Tor from their desktop / file manager, not the command line.
The second item is the most troubling, since I think very few of us are/were aware of it.
The third item may only be an error when starting Tor from the command line. I grepped my own .xsession-errors and got nothing.
The fourth item is only an issue when attaching external media, which is not the most common method of getting the browser bundle. Most people will simply download it.
There may be other traces left behind when starting TBB from the file manager, which this analysis would have missed. An example is recently-used.xbel. Launching from a menu or panel item doesn't leave a trace that I know of.
Will be interesting to see how many traces are left on Win7.
Also, none of this even touches true forensic analysis of free and swap space.
To me, the take away message is, use FDE or Tails, or forget about trying to cover up your Tor use.
Tor isn't against the terms of use of my ISP. If I am ever asked about it, I will say the TRUTH: ;)
I am going to school of PR, and I am fascinated by it's ability to allow censored countries (N. Korea, Iran, China) to access free press without fear of discrimination or recourse. That's somewhat truthy.
-
I'll be the first to admit it, I'm truly a beginner when it comes to this shit, and I know I've exchanged at least two forums posts with Astor regarding this, so I hope he doesn't get tired of me, but if someone can eplain how this effects/ affects me as a Whonix user, it would be GREATLY appreciated.
On a separate note, happy 4/20
-
Sub'd
-
Relevant information here to help keep everyone safe. Another great thread Astor. Really curious about the Win 7 results also.
-
Is it possible to remove all traces of tbb on windows?
That's the next blog post, which hasn't been published yet. When it is, I will post it here.
However, I'm going to preemptively say no. :)
If you want to hide your Tor use from someone who has physical access to your computer, you should use a bootable distro like Tails. Even running the browser bundle from an encrypted thumb drive is probably not safe, since references to the files will exist in various places after you access them.
-
Thanks for the great info (like you always post) & +1 !
and my 200'th post woohoo :)
-
subbed
-
The long-awaited part two is here!
======
Forensic Analysis of Tor on Windows
As part of a deliverable for two Tor Project sponsors (Sponsor J, Sponsor L), I have been working on a forensic analysis of the Tor Browser Bundle. In this three part series, I will summarize the most interesting or significant traces left behind after using the bundle, deleting it, and then shutting down the computer. Part one covered Debian Linux (#8166), this part will cover Windows 7 (#6845), and part three will cover OS X 10.8 (#6846).
Process
I set up a virtual machine with a fresh install of Windows 7, logged in with the default admin account, installed available updates, and shut it down cleanly. I connected the virtual drive to another virtual machine, used hashdeep to compute hashes for every file on the drive, and then rsync to copy all the files over to an external drive.
After having secured a copy of the clean virtual machine, I rebooted the system, connected an external drive, and copied the Tor Browser Bundle (version 2.3.25-6, 64-bit) from the external drive to the Desktop. I extracted the package archive by clicking on the file, then started the Tor Browser Bundle by going into the Tor Browser folder and clicking on Start Tor Browser.exe.
Once the Tor Browser was up and running, I browsed to a few pages, read a few paragraphs here and there, clicked on a few links, and then shut it down by closing the Tor Browser and clicking on the Exit-button in Vidalia. The Tor Browser did not crash and I did not see any error messages. I deleted the Tor Browser folder and the package archive by moving the folder and the archive into the Recycle Bin, right-clicking on it and choosing Empty Recycle Bin.
I repeated the steps with hashdeep and rsync to create a copy of the tainted virtual machine. I also used Noriben, written by Brian Baskin, to create a report of everything the Tor Browser Bundle did while it was running.
Results
Using hashdeep, I compared the hashes from the tainted virtual machine against the hashes from the clean virtual machine: 256 files have hashes that do not match any of the hashes in the clean set. Additionally, the Noriben output shows the Tor Browser Bundle create, edit, and remove a bunch of files.
I have sorted the most interesting findings into different groups, depending on the location, how they were created, and so on. Windows 7 has built-in symbolic links designed for backward compatibility, which is why Noriben and hashdeep list the same files in different locations.
Prefetch
Windows keeps track of the way the system starts and which programs the user commonly opens. This information is saved as a number of small files in the prefetch folder:
C:\Windows\Prefetch\START TOR BROWSER.EXE-F5557FAC.pf
C:\Windows\Prefetch\TBB-FIREFOX.EXE-350502C5.pf
C:\Windows\Prefetch\TOR-BROWSER-2.3.25-6_EN-US.EX-1354A499.pf
C:\Windows\Prefetch\TOR.EXE-D7159D93.pf
C:\Windows\Prefetch\VIDALIA.EXE-5167E0BC.pf
The following cache files are most likely similar to prefetch files and might contain traces of the Tor Browser Bundle:
C:\Users\runa\AppData\Local\Microsoft\Windows\Caches\cversions.1.db
C:\Users\runa\AppData\Local\Microsoft\Windows\Caches{AFBF9F1A-8EE8-4C77-AF34-C647E37CA0D9}.1.ver0x0000000000000006.db
C:\Windows\AppCompat\Programs\RecentFileCache.bcf
I have created #8916 for this issue.
SetupAPI
SetupAPI and the Plug and Play (PnP) manager write entries to SetupAPI.dev.log and SetupAPI.app.log about operations that install devices and drivers. The following files contain information about the attached external drive:
C:\Windows\inf\setupapi.dev.log
C:\Windows\System32\DriverStore\FileRepository\usbstor.inf_amd64_ neutral_0725c2806a159a9d\usbstor.PNF
Thumbnail Cache
Windows stores thumbnails of graphics files, and certain document and movie files, in Thumbnail Cache files. The following files contain the Onion Logo icon associated with the Tor Browser Bundle:
C:\Users\Runa\AppData\Local\Microsoft\Windows\Explorer\thumbcache_32.db
C:\Users\Runa\AppData\Local\Microsoft\Windows\Explorer\thumbcache_96.db
C:\Users\Runa\AppData\Local\Microsoft\Windows\Explorer\thumbcache_256.db
Other Thumbnail Cache files, such as thumbcache_1024.db, thumbcache_sr.db, thumbcache_idx.db, and IconCache.db, may also contain the Onion Logo icon. I have created #8921 for this issue.
Windows Defender
Windows Defender is the default anti-virus software on Windows 7. Windows Defender will write log files to the following location:
C:\ProgramData\Microsoft\Windows Defender\Support\
The log files will contain traces of the Tor Browser Bundle if Windows Defender ever decides to flag it as malware. This is true for any anti-virus software.
Windows Error Reporting (WER)
Windows Error Reporting (WER) captures and logs information about software crashes and other issues. I found information about the attached external drive in the following file:
C:\Users\runa\AppData\Local\Microsoft\Windows\WER\ReportQueue\NonCritical_x64_ 84cd279a5e83221bfa7edcb36665592c1974e4_cab_0b21673a/DMI671B.tmp.log.xml
The logs will probably contain traces of the Tor Browser Bundle if any part of the bundle, such as the Tor Browser or Vidalia, ever hangs or crashes.
Windows Event Log
The following two event logs contain information about the attached external drive:
C:\Windows\System32\winevt\Logs\Application.evtx
C:\Windows\System32\winevt\Logs\System.evtx
Windows Paging File
Microsoft Windows uses a paging file, called pagefile.sys, to store frames of memory that do not currently fit into physical memory. The file C:\pagefile.sys contains information about the attached external drive, as well as the filename for the Tor Browser Bundle executable. I have created #8918 for this issue.
Windows Registry
The Windows Registry is a databse that stores various configuration settings and options for the operating system. HKEY_CURRENT_USER, abbreviated HKCU, stores settings that are specific to the currently logged-in user. Each user’s settings are stored in files called NTUSER.DAT and UsrClass.dat.
The path to the Tor Browser Bundle executable is listed in the following two files:
C:\Users\runa\AppData\Local\Microsoft\Windows\UsrClass.dat
C:\Users\runa\AppData\Local\Microsoft\Windows\UsrClass.dat.LOG1
I did not find traces of the Tor Browser Bundle in any of the NTUSER.DAT files. I have created #8919 for this issue.
Additionally, the output from Noriben indicates that the Tor Browser Bundle touches the registry by creating keys and setting values. The following value points to the Tor Browser Bundle executable on the attached external drive:
[Set Value] Explorer.EXE:1196 > HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache\E:\tor-browser-2.3.25-6_en-US.exe = 7z SFX
The output also makes it look like the Tor Browser Bundle adds the following keys and values:
[Set Value] tbb-firefox.exe:1124 > HKCU\Software\Classes\Local Settings\MuiCache\11\52C64B7E\LanguageList = en-US, en
[CreateKey] tbb-firefox.exe:1124 > HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist{CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}
[CreateKey] tbb-firefox.exe:1124 > HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist{CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}\Count
[CreateKey] tbb-firefox.exe:1124 > HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}
[CreateKey] tbb-firefox.exe:1124 > HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}\Count
I found that these keys and values are present on a clean Windows 7 system where the Tor Browser Bundle has never been used. I also downloaded and tested the German version of the Tor Browser Bundle to make sure that the LanguageList value does not represent the language of the Tor Browser Bundle.
Windows Search
Windows Search, which is enabled by default, builds a full-text index of files on the computer. One component of Windows Search is the Indexer, which crawls the file system on initial setup, and then listens for file system notifications to index changed files. Windows Search writes a number of files to the following location:
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\
I have not found a way to read the Windows Search database files, but I would say it is likely that Windows Search picked up the Tor Browser Bundle at some point. I have created #8920 for this issue.
======
As expected, it leaves a lot more traces on Windows.
References
http://blog.encrypted.cc/blog/2013/05/20/forensic-analysis-of-tor-on-windows/
https://trac.torproject.org/projects/tor/ticket/6845
https://trac.torproject.org/projects/tor/ticket/8916
https://trac.torproject.org/projects/tor/ticket/8921
https://trac.torproject.org/projects/tor/ticket/8918
https://trac.torproject.org/projects/tor/ticket/8919
https://trac.torproject.org/projects/tor/ticket/8920
-
tyvm - informative :)
-
great thread!
dont mean to sound ignorant, but are there instances when accessing Tor is illegal in and of itself?? or are the implications that one would not want to leave traces on a shared machine or for forensic analysis?
just wondering
vw
The main concern as Astor highlighted is that a file which hints at old sessions is present, meaning it could contain information about activities which occured in the session such as what URL's you visited, cookies, a cache etc? I'm not technically proficient but that's my understanding of it and that would be a very serious concern especially for vendors.
@Astor - Looks like I'm getting another hard drive tomorrow :/ My first Tor & SR usage was from a regular desktop when I was new and I still have that computer since I don't use SR through it for any orders etc. Guess it could do with a storage upgrade anyway.
-
dont mean to sound ignorant, but are there instances when accessing Tor is illegal in and of itself?? or are the implications that one would not want to leave traces on a shared machine or for forensic analysis?
There are plenty of instances where it is illegal, in China, Iran, Syria. Even if no law exists on the books, they may arbitrarily imprison or torture you for using Tor. However, I've never heard of someone in a Western country being prosecuted for merely using Tor.
Yes, the threat model for us is to avoid leaving traces of Tor use that help to build a case against us.
Looks like I'm getting another hard drive tomorrow :/ My first Tor & SR usage was from a regular desktop when I was new and I still have that computer since I don't use SR through it for any orders etc. Guess it could do with a storage upgrade anyway.
You could save some money by DBANing it and reinstalling the OS. http://dban.org
-
Looks like I'm getting another hard drive tomorrow :/ My first Tor & SR usage was from a regular desktop when I was new and I still have that computer since I don't use SR through it for any orders etc. Guess it could do with a storage upgrade anyway.
You could save some money by DBANing it and reinstalling the OS. http://dban.org
I'm too cautious for just that. It's too late now anyway xD I'd usually DBAN then my 2nd destruction method, but I just went right ahead this time and tried my new destruction idea. Using a high-speed sander to take the layers off the disks until there was virtually nothing left of each disk in the HD. Worked a treat.
-
StExo, you might be interested in this: http://dkn255hz262ypmii.onion/index.php?topic=99520.msg699299#msg699299
-
StExo, you might be interested in this: http://dkn255hz262ypmii.onion/index.php?topic=99520.msg699299#msg699299
If I can ever be as helpful as you are to me, let me know :) Many thanks for that, good information from somebody who actually understands what they are talking about and not just repeating information they've heard through Chinese whispers is refreshing and much needed!
-
Hey thanks. :)
I originally posted that to disprove the persistent myth that you need 7, or 15, or -- laughably -- 35 writes to make data unrecoverable.
Under controlled conditions, where the researchers know where to look and what to look for, a single write is sufficient to prevent recovering anything except random, useless bits of information. Under realistic conditions, it should be even harder to recover anything useful. Even the NSA admits that additional overwrites offer no benefit (this is their recommendation to other government agencies that require secure data erase, for example to comply with HIPAA regulations, so it's unlikely they're lying to screw us over).
The analysis paper happens to contain a lot of other useful information. One reason that I like full disk/volume encryption is it allows for near-instant secure data wipes. All you have to do is write over the first 10 or 100 megabytes of the drive, which takes a few seconds to a few tens of seconds, and you have securely wiped your disk. DBANing can take hours to days.
-
Hey thanks. :)
I originally posted that to disprove the persistent myth that you need 7, or 15, or -- laughably -- 35 writes to make data unrecoverable.
Under controlled conditions, where the researchers know where to look and what to look for, a single write is sufficient to prevent recovering anything except random, useless bits of information. Under realistic conditions, it should be even harder to recover anything useful. Even the NSA admits that additional overwrites offer no benefit (this is their recommendation to other government agencies that require secure data erase, for example to comply with HIPAA regulations, so it's unlikely they're lying to screw us over).
The analysis paper happens to contain a lot of other useful information. One reason that I like full disk/volume encryption is it allows for near-instant secure data wipes. All you have to do is write over the first 10 or 100 megabytes of the drive, which takes a few seconds to a few tens of seconds, and you have securely wiped your disk. DBANing can take hours to days.
Agreed, but my method was far more entertaining.
I use 3 passes, simply to play it safe, just as how the more secure of us use logless VPN's to access Tor even though in theory Tor should be perfectly fine on it's own. Better safe than sorry!
-
Agreed, but my method was far more entertaining.
LOL.
I use 3 passes, simply to play it safe, just as how the more secure of us use logless VPN's to access Tor even though in theory Tor should be perfectly fine on it's own. Better safe than sorry!
Yeah, assuming they really don't log, or won't immediately start logging when they get an LE request.
That's called privacy by policy, where someone promises not to look at what you're doing. Tor offers privacy by design, where it would be extremely difficult for anyone, including the Tor devs, to see what you're doing, even if they wanted to or got an LE request that they could not turn down.
-
Forensic Analysis of Tor on OS X
As part of a deliverable for two Tor Project sponsors (Sponsor J, Sponsor L), I have been working on a forensic analysis of the Tor Browser Bundle. In this three part series, I will summarize the most interesting or significant traces left behind after using the bundle, deleting it, and then shutting down the computer. Part one covered Debian Linux (#8166) and part two covered Windows 7 (#6845). This third, and final, part will cover OS X 10.8 (#6846).
Process
I set up a virtual machine with a fresh install of OS X 10.8, created a normal, non-admin user account, installed available updates, and shut it down cleanly. I connected the virtual drive to another virtual machine, used hashdeep to compute hashes for every file on the drive, and then rsync to copy all the files over to an external drive.
After having secured a copy of the clean virtual machine, I rebooted the system, connected an external drive, and copied the Tor Browser Bundle (version 2.3.25-6, 64-bit) from the external drive to the Desktop. I extracted the package archive by clicking on the archive, then started the Tor Browser Bundle by clicking on the TorBrowser_en-US app.
Once the Tor Browser was up and running, I browsed to a few pages, read a few paragraphs here and there, clicked on a few links, and then shut it down by closing the Tor Browser and clicking on the Exit-button in Vidalia. The Tor Browser did not crash and I did not see any error messages. I deleted the Tor Browser folder and the package archive by moving the folder and the archive into the Trash, clicking on it and choosing Empty Trash. I repeated the steps with hashdeep and rsync to create a copy of the tainted virtual machine.
Results
Using hashdeep, I compared the hashes from the tainted virtual machine against the hashes from the clean virtual machine: 131 files had a hash that did not match any of the hashes in the clean set. I have sorted the most interesting findings into different groups, depending on the location, how they were created, and so on.
Apple System Log (ASL)
The following Apple System Log (ASL) files contain traces of the attached external drive and the Tor Browser Bundle:
/var/log/asl/2013.05.22.U0.G80.asl
/var/log/asl/2013.05.22.U501.asl
I have created #8982 for this issue. I have been not been able to open the following two files, but they may contain traces of the attached drive and the bundle as well:
/var/log/asl/StoreData
/var/log/asl/SweepStore
Crash Reporter and Diagnostic Messages
The Tor Browser Bundle did not crash or hang, but I still found traces of the Tor Browser Bundle in the following files:
/Library/Application Support/CrashReporter/Intervals_00000000-0000-1000-8000-000C2976590B.plist
/var/log/DiagnosticMessages/2013.05.22.asl
I have not been able to open the file StoreData, which can be found in the same DiagnosticMessages directory, but it may also contain traces of the bundle. I have created #8983 for this issue.
FSEvents API
The FSEvents API allows applications to register for notifications of changes to a given directory tree. Whenever the filesystem is changed, the kernel passes notifications to a process called fseventsd. The following file contains the path to the attached external drive, the path to the Tor Browser Bundle on the Desktop, and the path to the Tor Browser Bundle in the Trash:
/.fseventsd/0000000000172019
Other files in the .fseventsd directory may also contain traces of the Tor Browser Bundle and/or the attached external drive. I have created #8984 for this issue.
HFS+
HFS+ is the default filesystem on OS X; it supports journaling, quotas, Finder information in metadata, hard and symbolic links, aliases, etc. HFS+ also supports hot file clustering, which tracks read-only files that are frequently requested and then moves them into a “hot zone”. The hot file clustering scheme uses an on-disk B-Tree file for tracking.
I have not been able to open /.hotfiles.btree and /.journal, but they might contain traces of the Tor Browser Bundle and/or the attached external drive. I have created #8985 for this issue.
Preferences
OS X applications store preference settings in plist files, and the files below are related to system fonts, the file manager, recent items, and the Tor Browser Bundle. These files contain traces of the Tor Browser Bundle and the attached external drive. I have created #8986 for this issue.
/Users/runa/Library/Preferences/com.apple.ATS.plist
/Users/runa/Library/Preferences/com.apple.finder.plist
/Users/runa/Library/Preferences/com.apple.recentitems.plist
/Users/runa/Library/Preferences/org.mozilla.torbrowser.plist
Saved Application State
Resume is one of the new features in OS X 10.7 and 10.8. The feature allows applications to save their last known state when they are closed, and then return to this state when they are later reopened.
While the Tor Browser does not use this feature, it does leak information in the files which are written to the /Users/runa/Library/Saved Application State/ directory:
/Users/runa/Library/Saved Application State/org.mozilla.torbrowser.savedState/data.data
/Users/runa/Library/Saved Application State/org.mozilla.torbrowser.savedState/window_3.data
/Users/runa/Library/Saved Application State/org.mozilla.torbrowser.savedState/windows.plist
The windows.plist file contains the HTML title tag of the last active tab in the Tor Browser (or currently active tab, if the browser is still open). If the last active tab was torproject.org, then the following string will be present in the file:
Tor Project: Anonymity Online
I have created #8987 for this issue.
Spotlight
Spotlight, and the Metadata Server (mds), indexes all items and files on a system and allows the user to perform system-wide searches for all sorts of items; documents, pictures, applications, system preferences, etc.
I have not been able to open the files in /.Spotlight-V100 and /var/db/mds/messages/, but I would say it is likely that Spotlight and mds picked up the Tor Browser Bundle and the attached external drive at some point. I have created #8988 for this issue.
Swap
OS X relies on swap files and paging for memory and cache management. I have not been able to open the swap file, but I would say it is likely that /var/vm/swapfile0 contains traces of the Tor Browser Bundle and/or the attached external drive. I have created #8989 for this issue.
System Log
The system log file, /var/log/system.log, contains traces of the attached drive.
Temporary data
OS X stores per-user temporary files and caches in /var/folders/. The following files contain the path to the attached external drive, the path to the Tor Browser Bundle on the Desktop, and the path to the Tor Browser Bundle in the Trash:
/var/folders/fb/v5wqpgls029d8tp_pcjy0yth0000gn/C/com.apple.LaunchServices-036501.csstore
/var/folders/fb/v5wqpgls029d8tp_pcjy0yth0000gn/C/com.apple.QuickLook.thumbnailcache/index.sqlite
/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/C/com.apple.LaunchServices-0360.csstore
/var/folders/fb/v5wqpgls029d8tp_pcjy0yth0000gn/C/com.apple.QuickLook.thumbnailcache/thumbnails.data
These files also contain strings such as org.torproject.torbrowserbundle, org.mozilla.torbrowser, torbrowser_en-us.app, torbrowser.app, net.vidalia-project.vidalia, and vidalia.app. I have not been able to open the last file, thumbnails.data but it might contain traces of the Tor Browser Bundle and/or the attached external drive. I have created #8990 for this issue.
References
http://encrypted.cc/post/51552592311/forensic-analysis-of-tor-on-os-x
https://trac.torproject.org/projects/tor/ticket/8982
https://trac.torproject.org/projects/tor/ticket/8983
https://trac.torproject.org/projects/tor/ticket/8984
https://trac.torproject.org/projects/tor/ticket/8985
https://trac.torproject.org/projects/tor/ticket/8986
https://trac.torproject.org/projects/tor/ticket/8987
https://trac.torproject.org/projects/tor/ticket/8988
https://trac.torproject.org/projects/tor/ticket/8989
-
sub'd
-
really great thread...your dedication is a great tool for all of us here and you deserve recognition for the services you provide! +1 and a bump for an amazing and informative thread..