Torrent Applications in Android - Flud Torrent Downloader

Short version:

Android torrent apps keep 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:

• /userdata/data/com.delphicoder.flud/databases/suggestions.db
• Contains user typed searched terms.
• /userdata/data/com.delphicoder.flud/databases/torrents_db
• Keeps list of added and finished times per torrent.
• /media/0/Download  
• 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.

Good stuff.

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 2.2.6.10966
Forensic image processing: Autopsy 4.6.0
SQlite viewer: SQLite Browser 3.10.1
Target software: Flud Torrent Downloader

Testing

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 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

Downloaded Files Location

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 Nox or 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.)

¡Gracias!

Local Storage - Firefox Focus Privacy Browser Artifacts in Android

Short version: 

Data placed by websites in the Local Storage folder LevelDB database for the Firefox Focus Privacy Browser (FF-Focus) app will remain and be accessible even after browsing history deletion.  The data will be located at '/userdata/data/org.mozilla.focus/app_webview/Local Storage/leveldb' directory.

Long version: 

First I want to thank Ryan Benson (@_Ryan Benson) and Phill Moore (@phillmoore) for their help and guidance with this analysis.  I am thankful for their generosity in regards to their expertise and time. Any and all shortcomings with this analysis obviously reside with me. And like anything else in life always make sure to validate, validate, validate.

FF-Focus is a privacy oriented browser developed by the Mozilla organization. As stated in the picture below the app blocks ads, trackers and deletes all browsing related items like history and cookies.

No ads, no history, no nothing!!!

Testing 

I wondered how much data could remain, if any, after the app completed its privacy routines. In order to test I used some of the equipment mentioned in the following link for testing and analysis.

Android - Mobile testing hardware and software

After downloading the app to my exemplar phone, I did some browsing and imaged the device before closing the app. As can be seen below, the app had created all the files we would expect to see in a typical browser directory when in use. The cache folder has contents and the current session cookies are accessible.

Cookies are there. Yum.

If called to image a target device, being able to do so when FF-Focus is open would be the ideal thing, it will also be the most unlikely scenario. After the app is closed all those browser artifacts are gone.

All gone except...

The was only one remaining directory, Local Storage, and within it the LevelDB folder. The files within it were:

• 000003.log
• CURRENT
• LOCK
• LOG
• LOG.old
• MANIFEST-000001

After a quick view of contents of each file, the 000003.log seemed immediately relevant because it contained the domain names of the websites I had browsed previously.

I can see domain names.

After consulting with Phill Moore he referred me to Ryan Benson and his excellent presentation on browser forensics which he delivered at the SANS DFIR Summit 2017. The presentation can be seen at Youtube in the following link.

Deciphering Browser Hierogplyphics - min 17:20 onwards

I strongly encourage the reader to check out the whole of Ryan's presentation since my summary of the aforementioned data stores will do no justice to the depth of the explanation found in the video. 

In summary, the files seen in the Local Storage directory are responsive to website data stores that use the Google developed LevelDB database. This data store is based on key - value pairs unlike the traditional SQLite databases found everywhere in mobile devices. If a web page inserts a key-value pair where either the key or the value is the domain website, it will remain there even after the app deletes all the browsing history. It is also interesting to note that new key-values are added to the data store across browsing sessions.

These observations led to the following questions:

• Do all web pages leave data in the data store?
• Can all the domain names in the data store be attributable to a deliberate user request for a page?
• How are these records accessed? How are they ordered? Are there any timestamps available? Any ordering values?

Local Storage usage by web sites

In order to have an idea of what type of values a web page might place in the data store I examined the values being pushed to the browser by using the developer options functionality in Chrome and Firefox on my testing desktop. Ryan's video has a detailed explanation and a visual of such tools. 

The next image shows one of the pages I visited using FF-Focus for testing.

There is no key-value for the domain name.

Notice there is no key-value pair for the domain name. As expected I did not find the domain name for the visited page in the data store of the phone either. This seems to indicate that not all websites will leave a trace of the domain name in the store in question.

Now lets look a the following image from CNN.com

Local Storage values from CNN.com

The values in the image mirror the values found in the data store in the FF-Focus app directory. And yes, the domain name was there. But also notice that some domain names I did not visit explicitly, like Youtube, do appear in the data store. It is my hypothesis that video content played within the page will leave such traces in the data store. This needs further testing.

It is also worth nothing that these behaviors in FF-Focus might also be mirrored in most if not all browsers. 

Data Extraction

In order to view the key-value pairs more easily I needed to dump the data from the data store. The data was located in the 000003.log file. For this purpose Ryan shared with me a python script he quickly wrote that uses the leveldb wrappers to access data store. For my testing I collected 8 versions of the data store at different times after browsing a growing number of web pages per extraction. The following process was the most consistent way of dumping the values in the data store. It worked for all extractions tested.

1. Export the 'leveldb' directory from Local Storage and run the lvl.py script here. The script will access the data in the log file and move it over to a .ldb file. This is expected behavior of a LevelDB data store. I used the Linux version of the SIFT Workstation due to limitations with LevelDB python support in Windows.
   
   The usage is as follows:
   Run 'python lvl.py ~/location-of-the-leveldb-folder/leveldb'
   
   The script will dump the contents to the file to the screen (or to a file using a redirector) as it iterates through it. In some of my test data the contents did not show. The only consistent way of accessing the data was by dumping the data directly from the generated .ldb file.
   
2. To dump the data from the generated .ldb file I used the ldbdump tool found in Golang. Steps for my testing environment:
   
   - Install Golang for Windows. Link here.
   - Install Git for Windows. Link here.
   - Get the Golang leveldb repo. Run 'go get github.com/golang/leveldb'.
   - Navigate to 'C:\Users\username\go\src\github.com\golang\leveldb\cmd\ldbdump'.
   - Run 'go build -o ldbdump main.go'.
   - Take the ldbdump file and add the .exe extension.
   - Run 'ldbdump target.ldb > exportedldb.txt' where target.ldb is the extracted file name.

The exported data will look something similar to this:

Key value pairs. Some hex.

Pending items

After the data is extracted a noticeable pattern of hex values accompany the key in the data store. Currently I don't know what those values mean. They could be artifacts from the browser, some sort of data store ordering scheme or something totally different.

The formatting of the exported data still needs work. Further work on a script that can address the need is also to be done.

Why does this matter?

Being able to have some clues regarding subject browsing habits might be key to an investigation. This is even more essential when the involved individual/s are using a no history, privacy centric application like FF-Focus.

Android - Mobile testing hardware and software

Android Hardware

• Exemplar phone 0: Nexus 6P - Rooted - OS 8.1.0 
• Exemplar phone 1: Samsung Galaxy Prime - Rooted - OS 5.1.1
• Exemplar phone 2: Samsung S3 - Rooted - OS 4.1.2

Imaging Software

• Magnet Acquire 2.2.6
• Cellebrite UFED4PC

Image file system viewer / exporter /processing

• FTK Imager 3.4.2.2
• Cellebrite Physical Analyzer
• Autopsy / Sleuth Kit

Database viewer

• SQLite Browser

Scripting/Developer software

• Python
• Golang

OS platforms

• Windows 10
• SIFT Workstation - Linux

Was the video played? - Android video player apps

Was a particular video in an Android device viewed? At what time? How many times? Was the video not played at all? Where would such information reside within the Android file system? Since there are so many video player apps for Android this blog post will do a quick rundown on played video artifacts for five of the most popular players per the Google Play Store.

For this analysis the following tools were used:

• Exemplar phone - Samsung Galaxy Prime phone - rooted - OS version 5.1.1
• Magnet Acquire 2.2.6 - Full/Physical extraction.
• FTK Imager 3.4.2.2 - View file system and export files.
• SQLite Browser - View database contents.

Methodology:

1. Record three videos with the exemplar's camera functionality.
2. Download five popular video players from Google Play Store.
3. Play two out of three videos with each player.
4. Use Magnet Acquire to get a physical image of the exemplar's storage.
5. Use FTK Imager to locate each applications' files/databases and export them for review.
6. Use SQLite Browser to view the content of the exported files if needed.

All paths are located in the userdata folder,  identified in the rest of the blog post as [root].

VLC

One of the most popular video players with 100+ million downloads. 

Pertinent file location and name: [root]/data/org.videolan.vlc/app_db/vlc_media.db

The table named 'media' within the vlc_media.db database contains most of the information we are looking for.

Schema for the 'media' table.

Notice the 'play_count', 'filename', and 'duration' fields. As expected the video that was not played had a null value on the 'play_count' field as opposed to the value 1 for the played videos. The table named 'file' contains the location/storage of the played videos.

MX PLAYER

Another popular video player with 100+ million downloads.

Pertinent file location and name: [root]/data/com.mxtech.videoplayer.ad/databases/medias.db

The table named 'VideoFile' within the medias.db database has the following schema:

Schema for the 'VideoFile' table.

This table has more detail than the one found in VLC. Notice the 'LastWatchTime' and the 'FinishTime' fields. The two played videos had a Unix timestamp (see here for time conversion) in the 'LastWatchTime' field. One of the played videos I did not play all the way to the end. That one had no timestamp in the 'FinishTime' field. The video that was not played at all had null values on both fields. Another table named 'VideoStates' contained additional information like the location of the files but only for the files that were played.

ARCHOS

Unlike the previous apps, Archos does not identify native videos automatically. The user has to navigate to the folder where the videos are located in order to play them.

Pertinent file location:[root]/data/com.archos.mediacenter.videofree/databases/media.db

The table named 'files' within the media.db database has the following schema:

Schema for the 'files' table.

The table contained not only data about the video files but also contained data about files that are not playable media. At first impression it seemed to populate the table with the items it encountered as the user navigated to the desired video files location. More testing needs to be done to confirm this. In addition the videos, after played, did not create entries in fields like 'Archos_lastTimePlayed' where one would expect to encounter timestamps. Again, more testing is in order for this app.

PLEX

It is of notice that on the Google Play Store page for Plex it says that the app has a tendency to crash if selecting local and synced content.

Yup.

I found out that the warning was well warranted. None of the local videos would play since it crashed the app every single time. A log detailing the app's attempt at playing the videos was located at [root]/data/com.plexapp.android/Plex Media Server/Logs/Plex Media Server.5.log

Fail log.

No SQLite database was found containing additional information. Further testing with files that are neither local nor synced will need to be done to ascertain if a database is used to store any data about the played files.

LOCALCAST

This app is not a video player but a casting application for Chromecast and other Google devices. I selected two videos to play on my Google home. They did.

Pertinent file location:[root]/data/de.stefanpledl.localcast/databases/notes-db

The table named 'RECENT_ITEM' within the notes-db database has the following schema:

Schema for 'RECENT_ITEMS' table.

The table contained two entries, one for each video I had sent to my Google Home for playback. Not much historical data contained in this table or any other I could find. The table named 'QUEUE_ITEM' contained and entry for each of the three videos. Again no additional historical information was located.

As time permits I will try and fill in more details regarding the apps described here as well as look into new ones as they become popular. As always, for case work, one must do multiple rounds of testing and validation before arriving at a conclusion. Everything stated previously is just a guide for further testing.