Mobile App Analysis Archives

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.

March 31, 2017 by Sara Martin

Mobile App Analysis Part 4

Introduction

The Mobile Application Forensics team has begun to wrap up analysis on their second mobile app, Bumble, and are getting ready to move onto their next set of mobile apps, Facebook Lite for Android and the Weather Channel App for iOS. During analysis, both the iOS and Android team found important digital artifacts left behind by Bumble, which can be viewed in the Analysis section of this blog.

As we have already reached the halfway mark of the school semester, our plan is to examine two more mobile applications within the next month. The iOS team plans to look into the Weather Channel mobile app, and Tumblr, and the android team plans to look at Facebook Lite, and Strava.

Analysis iOS

To find artifacts created by Bumble, the iOS team used UFED to image the iPad Air, and UFED Physical Analyzer to parse through the image. Data for Bumble was located in Sam’s iPad/Applications/com.moxco.bumble. Within /com.moxco.bumble, there is a /Documents/yap-database.sqlite/database2 database, which contained pLists for the Bumble account. Within this database, we found the username for the Bumble account “Sam” within the userName pList, and the user ID “1409166234” for Sam in the userID pList. Both of these pLists can be viewed below.

Within the /yap-database.sqlite/database2 database, we also found a settings pList which contained settings information in regards to generating a list of potential Bumble matches. Within this pList, we found keys for the user’s preferred age group (“fromAgeValue” and “toAgeValue”), radius, in miles, that the user set to search for matches (“distance”), whether the user had Vibee enabled (vibeeEnabled), and the user’s preferred gender (“femaleShown” and “maleShown”).

The “fromAgeValue” and “toAgeValue” key, defined as years, determines how many years the user wants to go below/above from their current age. The value for “distance”, represented in miles, sets the maximum radius for people that get added to the user’s search list. The “vibeeEnabled” key shows whether the user has VIBee status of not. The VIBee feature is designed to connect users who have had positive interactions on Bumble together. The “femaleShown” key and “maleShown” key sets whether the account is looking for a male or female match. The settings pList can be viewed below.

Also within the /yap-database.sqlite/database2 database, we found a pList titled lastLocation, which contained information regarding the last location Bumble logged for our user. This pList can be viewed below.

Android

The Android team found all of their digital artifacts within the com.bumble.app folder inside userdata/Root/data. Within com.bumble.app are three subdirectories (com.bumble.app/files, com.bumble.app/databases, and com.bumble.app/cache) that held the most information relevant for a mobile investigation. The first subdirectory we are going to look at is com.bumble.app/files.

com.bumble.app/files

Within the com.bumble.app/files folder, was a document titled c2V0dGluZ3M= or “settings” (once you throw c2V0dGluZ3M= through a base64 converter, it decodes to “settings”). Inside the settings file, we found profile information such as the user’s username, user’s data of birth, user ID, email associated with the account, and a link to the user’s profile image. Inside this file, there was also information regarding the user’s preferred language and country on profile. It was through finding this information, that we concluded information stored within the /files directory are files that contain user information. Below is a screenshot of the user ID we found within the /settings file inside the com.bumble.apps/files folder.

com.bumble.app/databases

Within the badoo.db database inside com.bumble.apps/databases, we were able to recover the messages sent from the Nexus 5x to the Google Pixel. Along with text-based messages, we were able to see that an image was sent from the Nexus 5x to the Pixel, along with the location of that image on our mobile device. Using the user ID we found in the settings file within the /files folder, we were able to pick out who sent what message. Below, is an image showing the badoo.db database within userdata/Root/data/com.bumble.app/databases that contained the text messages we sent, along with sender and recipient information, and timestamp information.

com.bumble.app/cache

Within the com.bumble.app/cache folder, we found two folders (/decorator and /downloader) and a file that contained links to images on our user’s profile. The /decorator folder contained images that the user directly interacted with, e.g., images sent or received through Bumble, and images stored on the profile the user interacted with. The /downloader folder contained all the images the user saw while they were using the app. Below is an image that was stored inside the /decorator folder, which our user received from the Bumble user on the Google Pixel.

Within the /downloader folder were all the images the user saw the last time they used the app. This includes the profile pictures of other users we saw when using the app. For privacy reasons, a screenshot of this will not be included in this report.

Conclusion

The iOS team found most of their data within pLists inside the /yap-database.sqlite/database2 database in /Applications/com.moxco.bumble. Through looking through the /yap-database.sqlite/database2 database, the iOS team was able to recover username information, the user’s ID, user’s last known location, and account preferences set by the user. Although the iOS team was able to find a lot, we were unable to find any of the messages sent, or received through Bumble.

The Android team was able to find user account data on Bumble, chat data, and images associated with our account, and the accounts we interacted with.

With the Mobile Application Forensic team wrapping up analysis on Bumble, and shifting their focus on their third set of apps, we hope to publish an interesting and informative report at the end of the semester. Stay tuned!

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 4 appeared first on The Leahy Center for Digital Investigation.