If you don't know by now Bumble is an online social application where you can find friends, dates and other people with a swipe style matching system (like Tinder). In playing the Magnet User Summit onsite this year, in the iOS image we had some artifacts that I didn't see any commercial tools parsing so I decided to give it a go and see what I could pull out.
Chat Messages
From my limited prior knowledge of using the app, you can connect with other people and chat so that was the first thing I wanted to look for. It would appear that chat conversations reside at the following path of a full file system dump:
private\var\mobile\Containers\Data\Application\<APP_GUID>\Library\Caches\Chat.sqlite*
Note: Always make sure to get the -shm and -wal
The table structure of the database looks like this:
Figure 1: Table structure of Chat.sqlite
iOS always has to complicate things because of course they have embedded bplists in blobs in the tables. The main table "database2" contains the most amount of information that we will be looking at but we also pull in some fields from "secondaryIndex_isReadIndex". Using my formulated query, we can get a little more information surrounding the chat message direction and read status.
select
database2.data,
case secondaryIndex_isReadIndex.isIncoming
when 0 then 'Outgoing'
when 1 then 'Incoming'
end as "Direction",
case secondaryIndex_isReadIndex.isRead
when 0 then ''
when 1 then 'Yes'
end as "Message Read"
from database2
join secondaryIndex_isReadIndex on database2.rowid = secondaryIndex_isReadIndex.rowid
Figure 2: Query results from DB Browser
I made some assumptions around direction and read status but this seems to line up with what I could tell from further information found in the blobs. Speaking of those data column blobs, let's dig into those embedded bplists.
Since it is serialized we need to normalize it to be able to read it more properly. Yogesh Khatri has an executable (as well as a Python library) that can handle this. After downloading and running the bplist through it we get a deserialized version that can be opened something like pListEditorPro.
Switching over to List View, we get a much nicer way of identifying certain keys:
Figure 3: Sample deserialized bplist, not complete
A few quick fields stick out to me:
- self.dateCreated - created date of the message in Unix epoch miliseconds offset
- self.dateModified - modified date of the message in Unix epoch miliseconds offset
- self.fromPersonUid - message sender UID
- self.toPersonUid - message receiver UID
- self.messageText - contents of the actual message
- self.isRead - I assume this is the local read flag
There are some other interesting fields related to latitude and longitude coordinates but not sure the purpose just yet. Maybe you can share location through the app perhaps? More tested needs accomplished for more user interface data creation. For the time being we can pull out some preliminary chat information using iLEAPP.
Figure 4: Test chat messages from Bumble in iLEAPP
User Account Details
The students over at Champlain already have a blog post up a few years back about some details you can find about the user account settings including . The database can be found at the path.
private\var\mobile\Containers\Data\Application\<APP-GUID>\Documents\yap-database.sqlite*
Figure 5: yap-database.sqlite file, database2 table structure
- userID - user ID for the local account
- userName - name of the user for the local account (appears to be only first name)
- lastLocation - lots of coordinate details such as latitude and longitude (more on this later)
- lastDate - presumed last date the location was updated (to be confirmed)
- appVersion - the version number of the app itself
Each key includes a data bplist blob. Luckily most just have a value in the root and nothing else although we still have to parse the blob. For the "lastLocation" key we get a bunch of potential data which we will dig into a bit further.
Here is what the deserialized bplist looks like:
Figure 6: lastLocation key bplist deserialized
We can see latitude and longitude coordinates as well as some altitude, horizontal and vertical accuracy and much more that need to be determined. I'm not sure the difference between the regular and the raw coordinates but for this instance they were exactly the same. We also get a timestamp of presumed when the last location was calculated. The timestamp is in Mac Absolute format.
These artifacts are also now parsed in iLEAPP.
As I find more useful features, I will update this post.