SNAPCHAT IMAGE RECOVERY
Posted on January 23, 2014 by admin
SNAPCHAT UNVEILED: AN EXAMINATION OF SNAPCHAT ON ANDROID DEVICES
Snapchat is a mobile application that is available on iOS and Android mobile devices. The application allows the user to share pictures and videos with other users, and allows the sender to set a specific time limit from one to ten seconds that the receiver can view the message. The receiver of the message has that long to view the message, then the message “disappears forever.”
Snapchat moves “upward of 150 million photos through the service on a daily basis.” Compared to Facebook’s Instagram, which moves 40 million photos a day, that is a lot of photos moved for such a new company. The app differs in the fact that images and videos are ephemeral rather than permanent, something that is attractive to teens and young adults.
We wanted to know if “snaps” really do “disappear forever,” if there is metadata associated with “snaps,” if “snaps” can be recovered after becoming expired, and if they can be recovered, if there is metadata associated with the expired “snap.”
Based on the home screen for Snapchat, it is clear that these time stamps are stored some place, it is just unclear if they are recoverable. However, they are stored somewhere, even for expired “snaps.”
We used two android devices to examine artifacts left behind by Snapchat. An account (rhickman1989) was created on a Samsung Galaxy Note 2, and pictures and videos were sent to another account (DeciphForensics). The receiving account was logged into on a Samsung Galaxy S3, when some of the images and videos were viewed, while others were not. We then acquired the phone using AccessData’s Mobile Phone Examiner+ version 18.104.22.1689. After the acquisition was complete, the image was exported as an .AD1 image file, and then imported to AccessData’s Forensic Toolkit version 22.214.171.124.
After a brief examination of the contents, a different account (decipforensics2) was created on the Samsung Galaxy Note 2, and more pictures and videos were sent to the account on the Samsung Galaxy S3 (rhickman1989). This was to determine if there are identifiers for the sender account of a “snap.” The same acquisition process was followed again after the second batch of “snaps” were sent.
After another brief examination of the contents, pictures and videos were sent from the Samsung Galaxy S3 with the rhickman1989 account to both the DeciphForensics and DecipForensics2 accounts. The same acquisition process was followed again after sending these “snaps.”
All examination took place using AccessData’s Forensic Toolkit version 126.96.36.199.
The majority of Snapchat data is stored within the data/data/com.snapchat.android folder. There are four folders within this directory, with two folders within the cache folder.
Examination of the Samsung Galaxy S3 revealed that within the shared_prefs folder are several XML files: CameraPreviewActivity.xml, com.google.android.gcm.xml, com.snapchat.android_preferences.xml, and SnapPreviewActivity.xml.
The com.snapchat.android_preferences.xml File
This file is where the majority of information stored by Snapchat is located. Within this file is a listing of all the contacts stored on the device. This is done with the permission allowed by the user for the application to read the contacts on the device.
Below the list of contacts is a listing of Snapchat messages. It appears that there is a set of fields stored for each message in Snapchat. The following are the fields stored in this section of the XML file: type, mSender, mWasViewed, mCaptionPosition, mCaptionOrientation, mIsLoading, mIsTimerRunning, mIsBeingViewed, MWasOpened, mWasScreenshotted, mDisplayTime, mId, mTimestamp, mStatus, mIcon, and mMediaType.
We sent only two pictures from the DecipForensics2 account, and one was viewed and expired. Within this XML file are two records that show the mSender field set to “decipforensics2.” Of those two records, one has the mWasOpened set to “true.” The author kept documentation as to which images were opened and allowed to expire and which are not, so it is known which image is tied to this record.
The mTimestamp field is stored in Epoch format. Upon conversion of this value, it showed the time that the image was either taken or viewed. Further research will need to be done to determine which it is, however, the time is within the timeframe of both being sent and viewed. Unfortunately, the author did this within a few minutes of each other and did not record the exact time sent.
The mId field for the picture shown to the left is “270518365528484358r.” The mTimestamp field in the same record is “1365528484358.” After converting the Epoch time format to readable format, the time stamp is for April 9, 2013 11:28:04 MDT. The similarities here will be address further in a later section of this paper
The received_image_snaps Folder
Within this folder were located every image sent to the DeciphForensics account on the Samsung Galaxy S3, including the images that had been viewed and were expired. There were some duplicate images with different names as well, the reason for this is unknown.
Android developers created a way for media files such as graphics to be stored on the phone for application use and function without being put into the Gallery application as an image to be viewed. The way that they did this was with .nomedia files. “If a directory has a file named .nomedia, then the media store will not scan and record the metadata of files in that directory” (Hoog, 2011).
Each of the images within the received_image_snaps folder had a .nomedia extension appended to the end of the file name. For example, the name of the file figure 3 is “h1a81hurcs00h1365528700423.jpg.nomedia”. This was likely done to prevent the images stored within this directory from being placed in the gallery or from being scanned by the media store. AccessData’s Forensic Toolkit recognized the .nomedia extension that was appended to the end of the file name and ignored it, displaying the images.
Correlations between the XML Records and the Image Names
There is a small correlation between records within the com.snapchat.android_preferences.xml file and the name of the image file stored in the received_image_snaps folder.
As shown above, there are three correlations between the name of the image, the mTimestamp value, and the mId value. While this is consistent with this image, it is not always consistent with all images. The section in blue is present in several of the other images, only with different numbers following to separate the image.
The author began this research in an attempt to answer several vital questions about the Snapchat application as it is stored and used on Android devices. The author has concluded that metadata is stored for Snapchat images, as shown by the com.snapchat.android_preferences.xml file, and that it contains metadata about expired “snaps” as well as unexpired “snaps,” and that images that are sent via Snapchat are indeed recoverable, and do not “disappear forever.”
Recommendations for Further Research
We recommend several avenues for further research into Snapchat and how it stores data. Figuring out how to correlate the XML records to the actual images is vital. The author was able to do so in one instance because of known facts, but this will not be the case for examiners in live cases. The author also recommends research be done into finding where sent “snaps” are stored, as well as recovering video “snaps.”
We finally recommends that all of this research should also be done on iOS devices to find out if “snaps” are recoverable and can have time stamp and sender information associated with the “snaps.”
Any questions about this research should be directed to [email protected]
This research was done as part of the Advanced Mobile Forensics course at Utah Valley University.