iOS App Forensics — A Closer Look at The MySudo Privacy App
Abstract
Today there are millions of mobile App that exist and are used daily. This number continues to grow and forensics analysis are finding it had to keep up. This research was performed to identify new mobile artifacts for mobile applications that have never been forensically analyzed. The MySudo app is a free-to-use privacy app that allow users to create anonymous accounts for communications, web browsing, and payment transactions. An iPhone 6s was used as the test device for this research. The iPhone was wiped and data was generated using the MySudo app. A full file system acquisition of the iPhone 6s was performed and later analyzed for artifacts. All generated data were recovered from the iPhone 6s file system image. Most, if not all, of the user generated data were found in SQLite database at the path private/var/mobile/Containers/Shared/AppGroup. Also, all of the data recovered were stored in plaintext and not encrypted like the App may suggest. Lately, the SQLite database may give indications on whether records were deleted (as the database schema suggest). Carving for the deleted records to prove this were unsuccessful and future research showed be performed.
MySudo Application
MySudo is a personal privacy app that was designed by Anonyome Labs. The app advertises as a “privacy app…to disconnect online accounts and activity with personal information in order to increase privacy and security” and requires “No user registration or login for zero attribution, hacks, or spam”. The app is free to download, has a 4.7 out of 5 stars on Apple’s AppStore, and over 6,900 reviews by users. The app requires little-to-no user personal identifiable information (PII) to register for a Sudo account/identity and claims to use end-to-end encryption between Sudo accounts. At first glance, you can see that the app allows for SMS/MMS messaging and voice/video calls with a phone number you select when setting up an account. The app also creates an email address using the username that was entered during registration. Lastly, the app offers a feature that allows users to create “Virtual Credit Cards” that can be used to purchase at merchants and retailers. These virtual cards are funded by your personal card, but the billing details and personal information are not passed to merchants during transactions. MySudo essentially acts as a middleman for payment transactions.
**The Virtual Credit Card feature was not examined during this research but may be something for future research.
To my knowledge, MySudo has not been researched or examined for mobile artifacts as of yet. The purpose of this research is to identify important mobile artifacts that could help inform the forensics community.
Test Device
For this research, the mobile device used was a pre-owned Apple iPhone 6s. iPhones in general are a very popular mobile phone platform, which is one of the reasons it was chosen as I am hoping this research will be applicable to others in the future. Another reason was simply that I was the previous owner of the device and it was easily accessible without any expense. Table 1 below, show the details and specifications of the Apple iPhone 6s that was used in this research.
Software and Environments
The follow tools and equipment, shown in Table 2, were used to conduct this research. The tools in red were used during the acquisition of the full file system image of the iPhone 6s. The tools in blue were used in the analysis of the data.
Device Preparation
In order to get the device ready for acquisition, three steps had to be taken to ensure the research of the mobile artifact were accurate.
- Wipe of the iPhone 6s
- Data Population
- Jailbreak
Wipe of iPhone 6s
Since the iPhone 6s was previously owned by myself, to avoid mixing my old personal data with the data that will be examined, a wipe of the iPhone 6s had to be performed. This was done by going to “Settings > General > Reset” on the iPhone 6s and selecting the “Erase All Content and Settings” option. This will wipe the iPhone and restore it to the factory settings as seen in Figure 1 below.
Data Population
After the iPhone 6s was wiped, the device was setup as a device intended for the research of the MySudo application. A new Apple ID was created, and the phone was set up as a new device. Afterwards, the MySudo application was downloaded and installed from the Apple App Store. An account was created following the instructions of the app. A Sudo account named “CFRS762-User1” was created following the instructions from the app. These steps can be seen in Figure 2 below. The MySudo app will ask the user to enter a name for the Sudo account. This name is used to identify the account and will be used to generate an email account for the user as well. The app also prompts you to choose a telephone number that it will assign to the account.
Since MySudo is a communications app, there needs to be a separate user for it to communicate with; therefore, a second Sudo account was created on my personal mobile device. This second Sudo account will be used for the sole purpose of creating communication data between the research device. The second account named “CFRS762-User2” can also be seen in the Figure 2 below.
Using the created Sudo account (CFRS762-User1) on the iPhone 6s, communication data was generated between that Sudo account and the second created Sudo account (CFRS762-User2), the new Apple ID email (justin.cfrs762@icloud.com), and my person mobile telephone number. A contact entry was made for each device that was communicated with and stored in the MySudo App (the Apple ID and personal telephone number was named “Personal Cell Phone”). A brief overview of the communications can be seen below in Figure 3. A more detailed table of the specifics of the communications can be seen in Table 3 — Table 6.
The MySudo app also has a built-in web browser. Web browsing data was also generated and bookmarks were created as seen in Figure 4 below.
Jailbreak
The last step to prepare the iPhone for a full file system image acquisition is to jailbreak the device. Jailbreaking an iPhone will remove the security protocols and permissions on the device. To make the entire file system visible, the phone needs to be put into a privileged state. Jailbreaking the iPhone will do just that!
To jailbreak the iPhone 6s, I used the software called CheckRa1n. CheckRa1n is a popular utility that is often used to jailbreak iPhones and can be found Here. The utility only runs on Mac or Linux environments, so the jailbreaking process was performed on a MacBook Pro.
After downloading an installing CheckRa1n, the iPhone 6s was connected to the MacBook Pro. It was at this time that I notice that CheckRa1n only supports up to iOS 14.3 (Figure 5). The iPhone 6s was running iOS version 14.4 for this research and I was not able to downgrade the device.
After doing some research, I found that many people have had success using CheckRa1n to Jailbreak iPhone running iOS 14.4. To perform the jailbreak, I had to select the “options” button (seen in Figure 5 above) and select “Allow untested iOS/iPadOS/tvOS versions” and “Dark Blockchain” seen in Figure 6 below. The option for “Verbose Boot” is optional.
**If you are on an iPhone 8 or newer, its recommended that you also select the option to “Skip A11 BPR check”.
Even though there were several reports of this being successful, I went ahead and performed a backup of the iPhone 6s in case anything unexpected were to happen. Thankfully, everything went as expected and the iPhone 6s running iOS 14.4 was jailbroken successfully.
Acquisition
Since MySudo is a new mobile artifact that has not been researched before, a full image acquisition of the iPhone 6s’ file system is needed. While Magnet Axiom supports quick image acquisitions of iPhone 6s running iOS 14 starting from Axiom version 4.7, there was no notice of the newer versions of Axiom supporting a Full image acquisition yet. An attempt to perform a full image acquisition of the jailbroken iPhone 6s running iOS 14.4 resulted in multiple failures when building the image. As a result, a manual forensic acquisition was performed. Using guidance from a great post by Malay Patel found here, a full image of the iPhone 6s running iOS 14.4 was performed successfully using SSH as a means to extract the data within the device.
Analysis
After successfully acquiring a full file system image of the iPhone 6s, the image was loaded into Autopsy for analysis. Using Autopsy, I was able to identify several artifacts that were related to the MySudo application and also their stored locations on the iPhone file system. Once I identified the locations of interest that contained data from the MySudo app, the files were extracted. The three main locations that store data from the app or about the app were found at:
~/private/var/containers/Bundle/Application/6FA8AFC1-D760–42EB-A862–0682F71D9227/MySudo.app
~/private/var/mobile/Containers/Data/Application/D7309142-A21D-4B79–8AA4-DBBD2FE6D96C
~/private/var/mobile/Containers/Shared/AppGroup/97B2F5A0–8BD6–45EE-A0D2-E527D976ABEC
This change happened starting from iOS 8. Apple started separating app data into 3 main locations. Prior to iOS 8, app data were stored together as a bundle. Another change that has happened in the recent years, Apple has stopped using/started rejecting apps that require UUID starting from 2013 with iOS 6. With iOS 11, Apple also stopped passing MAC addresses to apps. This was done as a way of further protecting its users’ privacy.
In 2012, Apple introduced their Identifier for Advertisers (IDFA). Currently, the IDFA is the only persistent ID app developers can access. The IDFA is a string of alphanumeric characters. Three IDFA are shown in Figure 1 above.
MySudo.app Directory
The files and directories found at this location primarily contains data pertaining to the app itself and how it operates. In other words, this directory contains the code, frameworks, and resources that operate the app. This makes sense since the private/var/containers/Bundle/Application path is generally used to store the application bundle. The directory is made up of:
.nib file — An interface builder, it store the user interfaces of iOS and Mac apps.
.caf file — contains data referenced by supported applications developed by Apple.
.lproj file — contains text files and other resources for individual languages supported by a MacOS or iOS program.
.def file — digital certificates in binary format.
.string file — contains text strings which are commonly used by MacOS and iOS programs and operating systems.
.bundle file — A plug-in that adds extra features to the operating system or an application in MacOS and iOS.
While these files don’t reveal much information about a user using the app, the code, string, and certificates can give you insight about the nature and capabilities of the application. For example, when looking in this directory, information regarding the “Virtual Credit Card” was revealed. In the strings file found at ~/private/var/containers/Bundle/Application/6FA8AFC1-D760–42EB-A862–0682F71D9227/MySudo.app/VirtualCardsUI.bundle/en.lproj/ Localizable.strings (Figure 7), the contents revealed that the Virtual Card from the App is a Mastercard issued by Sutton Bank and provided through Marqeta payment platform.
private/var/mobile/Containers/Data/Application Directory
Most applications use the private/var/mobile/Containers/Data/Application path to store its application data. In this directory, the network cache from the MySudo app’s built-in browser can be found. Only network cache is store in this location; compared to the emails, calls, and messages; because this data does not need to be shared. The network cache pertains to the MySudo browsers only and is not shared to other applications on the device. The emails, calls, and messages are shared so they will be found in a location path for shared data that will be discussed later.
If you remember from the data generation part of this research; dfir.training, thisweekin4n6.com, duckduckgo.com, apple.com, and google.com were visited. From the D7309142-A21D-4B79–8AA4-DBBD2FE6D96C directory, the network cache can be found at Library/Caches/WebKit/NetworkCache as seen in figure 8.
Traversing further through the directory will reveal a Blobs directory and Records directory. The Blobs directory contains Binary Large OBjects (BLOBs) for all the visited websites. In the Records directory, the website cache is split into separate “Resource” directories for each website that the app has cached memory from (Figure 9).
Data from the data generation step:
1F56BC48FCD4654B392450F6028C3ADE4ED5C63E/Resource — dfir.training
4622262EDA72CCECAC402C409945C73EBA80D49A/Resource — thisweekin4n6.com
81367A93E4BEC465ECDA2E36F7444B2EE2F6A03E/Resource — duckduckgo.com
BD18EF5B2637F48FF351A679510AEF5FE32FB097/ Resource — apple.com
BD7E1486CBFDA745E5A972FC6FFE9D2FDCD32621/Resource — google.com
Of course, these file names may differ from user-to-user as they may visit other websites, but the overall location of Network/Web cache from the websites visited by the MySudo browser will be in this general location on the file system.
private/var/mobile/Containers/Shared/AppGroup Directory
Like alluded to earlier, this path stores the data from the MySudo app that is shared to other applications and extensions on the device. Like mentioned before, emails, calls, messages, and other information from the MySudo app will be found here. For my particular case, the IDFA used to identify MySudo on my device was 97B2F5A0–8BD6–45EE-A0D2-E527D976ABEC. At this locations are a collection of .plist and .sqlite files. The SQLite databases found here contain most of the identifying information from the app. This is similar to what has been seen with other communications apps like WhatsApp, Telegram, and Signal. Below are several figures of the SQLite tables that contain the information that were generated during the data generation stage of this research.
/BKBookmarkItem.sqlite Database
- All the bookmarked websites from the MySudo web browser can be found in the BKBookmarkItem_3 table.
/BKHistory.sqlite Database
- All internet history from the MySudo web browser can be found in the BK_History_1 table.
/CallRecord.sqlite Database
- All call records from the MySudo account (dialed, received, and missed) can be found in the CallRecords_0 table.
/Contact.sqlite Database
- All contacts information saved in the MySudo app (names, phone numbers, notes, emails, etc.) can be found in the Contact_2 table.
/EmailAccount.sqlite
- The email account tied to the MySudo account can be found in the EmailAccount_1 table
/EmailMessage.sqlite
- All emails messages involving the MySudo account (sent and received) can be found in the EmailMessage_3 table. The table also include information about the encryption (Keys, algorithm, etc.)
/Message.sqlite
- All SMS and MMS messages (sent and received) from the MySudo account can be found in the Message_0 table.
/Telephone.sqlite
- The phone number and greeting information tied to the MySudo account can be found in the Telephone_1 table.
Final notes on the SQLite databases
In all of the database tables I was able to see important time stamp information for each entry. The creation and modification times were stored in Epoch time. Lastly, you may have noticed that each database table had a column for “deleted”. A closer look into the database schema (figure 18) revealed that this column store Boolean values, where “1” represents deleted and “0” represents not deleted.
To see if we could observe this change, I deleted all messages and trashed all emails from the MySudo app. I then performed another acquisition of the device and analyzed the database using the same procedures as before.
Unfortunately, I was unable to see any of the deleted messages in the Messages_0 table in the Messages.sqlite database. The table itself was empty (Figure 19). For the emails, I noticed that the column for “trash” was changed to “1” for the trashed emails. The “deleted” column in the EmailMessage_3 table remained as “0” (Figure 20). I realized that this is because the emails were only moved to the trash folder and not actually deleted yet.
Doing additional research into the SQLite databases, I found that generally SQLite do not delete records immediately, like a computer’s file system and for performance reasons, deleted records are not wiped but rather marked as free until they are overwritten by other data. In most cases, it is possible to carve for SQLite records that have been deleted from the SQLite table.
My attempt at carving the deleted SQLite records with an open-source tool, “SQLite-Parser”, was unsuccessful. However, given how the database schema is set up, if records were recovered, I expect them to all have a “1” set in the “deleted” column. More research and testing will need to be performed to see if the deleted records can be carved.
Conclusion
In conclusion, all generated data (communications, contacts, and web browsing) that were stored on the iPhone 6s test device were successfully recovered by performing a full file system image acquisition. The data recovered were all store in plaintext and could be easily read in the SQLite database that were found during my analysis. This showed that while MySudo advertises as a “Secure” method of communicating, it is only in terms of communication during transit. My analysis showed that the data is not encrypted at rest. In addition, an analysis of the SQLite databases hinted that the database may show indications whether records are deleted (the “deleted” column). While I was unable to carve the deleted SQLite records, if MySudo is anything like WhatsApp or Telegram, it should be possible to recover the deleted records through carving. Further research and testing will need to be performed to see if we can obtain the expected outcomes; but if possible, the indication of deleted records could help law enforcement greatly when it comes to proving potential obstruction of justice.
Acknowledgement
This research would not have been possible had it not been for Jessica Hyde. Thank you for providing the tools, knowledge, and support needed to conduct this mobile research.
References
Checkra1n Jailbreak, Checkm8 Exploit Analysis | Checkm8. (n.d.). Retrieved April 3, 2021, from https://checkm8.info/blog/checkra1n-jailbreak-exploit
Mdegrazia. (2015, June 22). SQLite-Deleted-Records-Parser. Retrieved April 7, 2021, from https://github.com/mdegrazia/SQLite-Deleted-Records-Parser
Patel, M. (2020, December 17). Mobile device forensics — Ios 14 manual forensic acquisition and user data population. Retrieved April 3, 2021, from https://pateldfir-20.medium.com/mobile-device-forensics-ios-14-manual-forensic-acquisition-and-user-data-population-cbfe2933bc21
