Mobile App Analysis Archives

December 14, 2018 by LCDI

Mobile App Intern Final Blog Post

Project Wrap Up

The Mobile App Intern team chose 3 travel apps to analyze. Kayak, Expedia, and Google Trips. All three apps stored their data within the internal storage of each device it was downloaded onto. However, Expedia proved to show very little artifacts that could be useful for forensic analysts. Most of the data kept by Expedia is not data meant for the user or analysts’; it is meant for the app itself (data logs etc). Google Trips saved the most user data out of all three of the apps. It kept user info (username and password hash), trip details (title, locations, etc), and location data. Kayak mainly stored location data, the names of hotels, and rental company information. For example, if one were to use Kayak in order to rent a Mercedes-Benz for $60 USD a day, they can set what dates to rent said car and Kayak will keep all of that information about the car and company stored. The same was true for plane and bus tickets. Company, price, dates of departure/arrival, and user timestamps are all stored.

Final Thoughts

The Mobile App Intern Team is grateful to the LCDI to have been given the chance to utilize their devices in order to perform projects and research. The team was able to acquire new skills (like rooting Android devices) and read many useful journal articles relating to mobile forensics.

The post Mobile App Intern Final Blog Post appeared first on The Leahy Center for Digital Investigation.

November 2, 2018 by LCDI

Application Analysis

Introduction:

The Application Analysis team is a group of technical interns at the Leahy Center for Digital Investigation. The LCDI offers great opportunities for students to gain knowledge and skills in digital forensics and cybersecurity. This project is how four intern students have gone about testing some consumer mobile tracking & monitoring software.

Experience:

The Application Analysis team has currently been researching four different mobile tracking & monitoring programs available in today’s market. The programs we are looking at are mSpy, FlexiSpy, Mobistealth, and Highster Mobile. We are researching the specifications that each of these applications claims to have. We have five Nexus 7 tablets, four of which are rooted using Nexus Root Toolkit and one that is being used as the control device. A control device is a device that you leave in its original state to compare with other devices so you can see what has changed. Sometimes unexpected things will change and that is how you can confirm that it has been altered. We have a laptop that is being used to monitor the traffic via WireShark and also used as the control panel for the software.

Our team is using the following apps: Google Hangouts, Facebook, Facebook Messenger, Kik, and Skype. We are generating data by sending information between the rooted device and the control device using these various applications. We are seeing if we are able to view all the information that we generated and are checking on whether any data is not collected.

In addition, we are testing if video calls are recorded and sent to the parents’ account. We have set a keyword to test the capability of specific programs to see if it alerts the parent when the keyword is used. Since the first program that we tested has the capability of Geo-Fencing, we decided to test for this capability as well. Geo-fencing means if a device leaves a certain location, there would be an alert sent to notify the parent that the device has left the specified location.

Conclusion:

We have created a variety of questions that we would like to look further into with each of the programs, including if the software can be hidden on the device. Stay tuned to read further updates on this project and the information we continue to gather from our devices.

To learn more about this and other blogs of the LCDI visit us here: LCDI Blog.

Stay in the loop on our current and upcoming projects and events by following us on Facebook, Twitter, or Instagram.

The post Application Analysis appeared first on The Leahy Center for Digital Investigation.

April 14, 2017 by LCDI

Mobile App Analysis Part 5

Introduction

The Mobile Application Forensics team is beginning to wind down on application analysis, and have started working on their final report. So far, both the iOS team and Android team worked on Open Whisper Systems’s Signal, an end-to-end encryption chat app, and Bumble, a new mobile dating app. The iOS team then did analysis on The Weather Channel app, and are now finishing analysis on Tumblr. The Android team began work on Facebook Lite and Facebook Messenger Lite, and are starting data generation for Strava, a run and cycling tracking social app.

In this week’s blog, the iOS team will showcase their findings for The Weather Channel app, and the Android team will showcase their findings so far for Facebook Lite, and Messenger Lite.

Analysis iOS

The iOS team conducted data analysis on The Weather Channel app this week and were able to find user account information, and user location data. Within The Weather Channel app, under the com.weather.TWCiPadMax/Library/PrivateDocuments folder, the iOS team found a database titled WXUPSService.coredata which contained 12 tables. The tables we will focus on for this blog post are ZCD_WXUPSDEMOGRAPHICS and ZCD_WXPUSPLOCATION.

User account information

Within the ZCD_WXUPSDEMOGRAPHICS table, we found user account information such as the user’s age range (ZAGERANGE column), email associated with the account (ZEMAIL column), user’s first name and last name (ZFIRSTNAME column and ZLASTNAME column), user’s gender (ZGENDER column), username on the account (ZUSERNAME column), and much more. Below, is an image of the ZCD_WXUPSDEMOGRAPHICS table within the WXUPSService.coredata database, showing the user account information we found for The Weather Channel app.

User location data

Within the ZCD_WXPUSPLOCATION table, we found Latitude and Longitude coordinates to locations our user was the last time the app ran in that location, and any locations the user saved on their app. Within the ZCD_WXPUSPLOCATION table, we also found the name of the city the user was in (ZCITYNAME column), the country the user was in (ZCOUNTRYCODE column), and the elevation the user was at the time the The Weather Channel app called out (ZELEVATION column). Below, is an image of the ZCD_WXPUSPLOCATION table, showing the cities, along with their country codes and county names, the user saved on The Weather Channel app.

Within the com.weather.TWCiPadMax/Library/Preferences folder, we found a pList titled com.weather.TWCiPadMax.plist which contained settings information for the first time The Weather Channel app was used. As you can see in the image below, the pList showed us the Longitude and Latitude coordinates, and city, where the app was first used.

Android

The Android team conducted data analysis on Facebook Lite, and Facebook Messenger Lite this week. We were able to recover a lot of information in regards to; user account and user activity information on both apps. For this blog post, we will be focusing on Facebook Messenger Lite, specifically on the messages sent and received through the Facebook Messenger Lite app. In order to create a realistic messaging scenario, we decided to send two images, one video, and an emoji, to see if we could recover all the media sent through this app, on top of the text messages themselves.

Within the com.facebook.mlite/databases exist two databases, core.db and omnistore.db. core.db stores a plethora of tables, the most important being the messages table. Within the messages table, we were able to find all the messages Joseph Mitchell (the account on the Nexus 5x) sent. This included the locations of any images Joseph sent from the Nexus 5x, and internet links to images and videos Aaron Guirre sent.

Image received by Nexus

During data generation, we had Aaron send Joseph an image of a question mark. The way Aaron got this image was by downloading it from the internet, and then sending it to Joseph through the desktop version of Facebook. When looking through the messages table within the core.db database, we found a link that seems to be pointing us to a facebook server which, when we followed the link, showed us the image Aaron sent to Joseph. Below, is an image of the messages table within the core.db database showing the message Aaron sent, as well as the media_playable_url column showing the link that took us to the image sent by Aaron.

As you can see on the image above, under the media_playable_url column, we got a url that points to a Facebook server which contains the image Aaron sent to Joseph.

Video received by Nexus

Just like the image we received from Aaron, we found a url that points to a Facebook server that allowed us to download the video sent by Aaron. Below, is an image of the messages table within the core.db database showing us that a video was sent, and the media_playable_url column showing the link that took us to the video Aaron sent.

Image sent from Nexus

During data generation, we had Joseph send Aaron an image of a security camera from the Nexus 5x mobile device. Unlike the message we received from Aaron, we did not get a URL, but, instead, got an absolute path to where the image was stored on the Nexus 5x mobile device. As you can see below, we got an absolute path under the media_playable_url column to the image Joseph sent to Aaron from the Nexus 5x mobile device.

Emoji sent Nexus 5x

As you can see in the image below, the emoji sent by Joseph to Aaron appears as a box in the db browser.

When we copied the text out and placed it in an Emoji keyboard (https://emojikeyboard.org/), we were able to see what emoji Joseph sent to Aaron through Facebook Messenger Lite. Below, is an image of what the online Emoji keyboard we used translated through the text Joseph sent to Aaron.

The Emoji seen above is the exact Emoji Joseph sent to Aaron.

Messages sent to and from Facebook Lite Messenger

Through the messages table in the core.db database, we were able to recover all the messages ever sent and received through Joseph’s Facebook account. The reason we were able to recover all the messages ever sent was because Facebook imports all the messages ever sent from the main Facebook app to the Messenger app once the user installs it. Because we are using a lite version of the Messenger app, we did not expect all the messages to be present within the core.db database.

Within the messages table, we were able to find user ID information, and a link to the user image, the timestamp information in respect to the actual message, if the message was a multimedia message (we were able to see what type of multimedia message it was under the attachment_meme_type column), and a link or absolute path to the multimedia message sent.

Conclusion

As the iOS team finishes data analysis on Tubmlr, and the Android team finishes analysis on Facebook Lite, Facebook Messenger Lite, and Strava, we hope to show all of our results in a detailed report that will be released later this semester.

Questions or comments? Please share with us in the comment section below! You can also reach out to our Twitter and Facebook or email us at lcdi@champlain.edu.

The post Mobile App Analysis Part 5 appeared first on The Leahy Center for Digital Investigation.