Android torrentappskeep pertinent data in app defined folders and sqlite stores. Downloaded file access can be found in the history databases of the media player apps in use. Some example of that here. In the case of the "Flud - Torrent Dowloader" app the databases and directory locations of interest are as follows:
Flud SQLite databases:
- Contains user typed searched terms.
- Keeps list of added and finished times per torrent.
- Default location for downloaded files.
Traditional file system forensics, like index searching and file carving, will be used in cases where downloaded data via torrent is deleted. More on that in the long version below.Long version:
A few days ago @TroySchnack tweeted his success in analyzing the Android artifacts generated by the uTorrent app using @XWaysSoftware.
|Nice!!! Want to know more!!!|
Troy also shared some of his process.
Being familiar with torrent artifacts in Windows operating system, but not so much with torrent artifacts in Android, I decided to see if I could reach similar results to the ones Troy had by using free and open source tools only.Hardware and software used
Exemplar phone: Huawei Nexus 6P - Details here
Forensic image generation: Magnet Acquire 18.104.22.16866
Forensic image processing: Autopsy 4.6.0
SQlite viewer: SQLite Browser 3.10.1
Target software: Flud Torrent DownloaderTesting
First step was to download the Flud app. I decided to test it since it is one of the most popular apps for torrents at 10 million downloads. Next some torrents needed to be downloaded. I searched for the terms "cars" and "submarine" in the Flud search icon. The app would open a Chrome google search instance where the query was the joining of the user term with the word "torrent". For example if you search for "cars" the google query would be "cars torrent". All provided links in the google search were for torrents sites that are notorious for pirated content. To avoid this I searched for torrents to test at LegitTorrents.info.
|No piracy thank you very much.|
It goes without saying that forensic imaging should only be done only on devices you own (like the one I used for this post), devices which you have consent for, or due to a search warrant in the case of law enforcement.
After imaging I tried to view the acquired file system using FTK Imager. It wouldn't let me access the contents of the "/data/" directory. I turned to Autopsy. It was able to access and parse the image no problem. Quickly too.Torrent Location
Since the torrent file was downloaded using Chrome it was placed by default in the downloads folder. In my exemplar phone the path is "/media/0/Download". This directory is defined as emulated storage since my exemplar phone does not support SD card storage. For more details see here. It is also of note that the Chrome browser history will have data regarding the torrent downloaded.
Downloaded Files Location
- Downloaded files history: /data/com.android.providers.downloads/databases/downloads.db
- Chrome history: /data/com.android.chrome/app_chrome/Default/History
- Default downloaded files directory: /media/0/Download
By default the app will place the downloaded files responsive to the torrent in the default download folder. The app has options to change those settings.
|Know thyself. Know thy app. Know thyer (lol) app.|
It is good practice to familiarize yourself with the user options of an app in a emulator like Noxor in an exemplar phone first. This will save you time and inform your analysis. For this post I left the default options untouched.Application Folder and Relevant Databases
The Flud app databases were located in the "/data/com.delphicoder.flud/databases/" directory.
|Flud database folder.|
The first database of interest is the "suggestions.db" database. It contained the search terms typed by the user within the app. Notice that it has a date field. It is in Unix time and corresponds to when the user searched for the term.
|Date of term search? NIIIIICEEEE!!!!|
Below is a query that changes the Unix time to local time. Details on how to do that here.
|Suggestions as in, do you want to search this again?|
It is usually no accident nor a coincidence when content responsive to a search is found in a device. The evidentiary value of the "suggestons.db" database is obvious.
The second database of interest is the"torrents_db" database. It contains the torrent names, date added and date finished. The times are not in Unix time but in local time.
|More dates. Nice!|
It is of note that if the downloaded files referenced in this table are deleted the entries in this table are deleted as well. The deletion was done via the app interface.
|Files gone, entry in DB gone too. Sad.|
Interestingly enough the torrent file itself, in the downloads folder, is not affected. Always be aware of the app settings since deletion of the torrent file along with deletion of the downloaded content can be set up in many of these apps.File Deletion and Recovery
So what is to be done when downloaded files from a torrent app are deleted? Traditional file recovery forensics are in order. The following are some suggestions to aid in the recovery of deleted data.
- Look for directories/files marked for deletion responsive to the relevant paths discussed above. For example Autopsy shows us a directory and a folder as deleted within the "Download" directory.
|The red X marks the spot.|
- Locate the torrent file. This file has metadata regarding the files to be downloaded or already downloaded. The torrent file can be provided by the interested party in a torrent investigation or it can be found in allocated/unallocated space.
|These ARE the terms you are looking for.|
- Use the terms in the torrent file, or terms provided by the interested party, to do an index search on the imaged media.
|Highlighted terms are the search terms in question.|
- Look for results that might contains the searched terms or that the tool identifies as types of interested. Item that hits on both at the same time even better. In this analysis mp3 files were identified as types of interest as seen in the .torrent file above. In many torrent cases the types of interest are movies, images and documents that contain contraband images.
|File carved by type.|
- Carved media files might contain internal metada which could be relevant to the case or that could have possibly mirrored information now lost to the file system like filename or title of media.
|Player shows the song name per internal file metadata. File plays too.|
Be aware that this analysis can be achieved in reverse. Look for pertinent media types first and tie them back to the application via the index searches, download history and application database information. For the careful examiner all roads lead to Rome.Take Aways and Thoughts
There are powerful free and open source tools that can aid you in your case work. If you are interested in learning about digital forensics the only cost is time and effort. Magnet Acquire is my go to imaging tool for research and Autopsy is quickly becoming one of my favorite tools for research analysis and validation. Price of $0. Some drawbacks from open source tools, like Troy mentions in his thread, are not as user friendly bookmarking/tagging options as well as difficult to understand tool reports.
Never forget that validation is key. Never assume or go with what seems to make sense by itself. Dig in and go with what the artifacts show. Test, test, test and test again. Ask someone to review. Test again.
|Constant self-checks are in order. Me first.|
Last but not least share. There is nothing revolutionary in the preceding analysis. Best-case scenario someone finds it useful, worse-case scenario I continued my writing, ability to summarize findings, and English practice (considering i'm a native Spanish speaker.)