Synopsis

Forensics Question: What sort of information can be parsed from Kik messages? Can we show if attachments were sent or received? Were any images stuck in a pending upload status?
OS Version: iOS version 14.3 Kik Messenger version 15.25.1
Tools: DB Browser for SQLite v3.12.2 Plist Editor Pro v2.5 iLEAPP v1.16.9

There is always room for improvement to parsers of the past. That was the case when I asked to look into some Kik Messenger artifacts. There has already been support for Kik in iLEAPP for months but you can always squeeze out more information. Starting with the basics we can open up Josh Hickman’s well documented test image of an iPhone SE. We can look at the main sqlite database file found at the following path:

private\var\mobile\Containers\Shared\AppGroup\<APP_GUID>\cores\private\<USER_ID>\kik.sqlite

Don't forget the -wal file! I still hate the naming conventions iOS uses for sqlite tables but I digress. Here is what the Tables look like:

Figure 1: kik.sqlite Tables

The main focus will be surrounding the following:

ZKIKMESSAGE - A list of all messages

ZKIKUSER - A list of user info, including user names

ZKIKATTACHMENT - Attachment information including file name that can be correlated to a message

Since Alexis already had the main pieces of the ZKIKMESSAGE table done in the initial parser, I decided to whip up a quick SQLite query to add more user information.

One thing missing from the original parser was attachments. In the ZKIKATTACHMENT table we see a column called ZCONTENT with a GUID:

Figure 2: ZKIKATTACHMENT table, ZCONTENT column

After trolling through the folder structure looking for a reference to this GUID, I came across the following folder:

private\var\mobile\Containers\Shared\AppGroup\<APP_GUID>\cores\private\<USER_ID>\content_manager\data_cache

Easily enough, we get extension-less files with the same names as seen in the ZCONTENT column in the kik.sqlite database. One thing I've learned from creating other parsers in Python for ALEAPP & iLEAPP is that these can be embedded quickly into their reports. With some quick updates we can now see better results into Kik Messenger conversations including sent and received images.

Figure 3: iLEAPP Report for Kik Messages

You have to love the great content shared in Josh Hickman's test images. Next up, we are going to look at the following folder:

private\var\mobile\Containers\Shared\AppGroup\<APP_GUID>\cores\private\<USER_ID>\attachments

Inside we get a little more context on the attachments we saw prior. The files found here are extension-less bplists. In collaboration with Alexis and a colleague who shall remain anonymous, we were able to discover what these bplists were all about. One of the first metadata items we get are the hashes of the attachments.

Figure 4: Attachments bplist Hashes

From testing I found out that the SHA1-Scaled hash directly matches the file we previously found in the "data_cache" folder. My assumption is that when files are uploaded to Kik they are compressed down for sending. The next grouping of keys we can see some app information as well as file attachment info.

Figure 5: Attachments bplist app and file info

What I can comprehend here is that we show that the attachment is a photo and came from the Gallery. We also can see the file size is available as well as a temporary file name (note, seemed like all temp names were the same). We also once again see the file name GUID of the file which also matches the bplist here.

The last item we get from this bplist is the actual thumbnail hexadecimal:

Figure 6: Attachments bplist snippet of thumbnail

The full image bytes can be found here, albeit encoded with Base64. After all is said and done, we get another parser for the Kik metadata into iLEAPP, thanks for the coding Alexis! Some things to note, the bplists may still reside after an attachment or if the chat is deleted. More testing needs to be done to see if this is true but we had one case instance where it was. It also appears that the bplists are found in an Advanced Logical dump in Cellebrite so we may get this information out of an iTunes backup as well.

Figure 7: Kik Bplist metadata in iLEAPP

The last artifact of interest that I found during exploring the app folder was Pending Uploads. Basically we can find another extension-less file at the following path:

private\var\mobile\Containers\Shared\AppGroup\<APP_GUID>\cores\private\<USER_ID>\chunked_upload_storage\pending_uploads

It is an XML file that is pretty straight forward.

Figure 8: pending_uploads file

Contained is a list of metadata related to file attachments that are naturally pending to be uploaded. We can see we get application ID information, a content ID which is the file name, as well as progress percentage, retries and an upload start time. I'm not quite sure what the "state" key is used for at this time. Any pending picture uploads can be found at the following folder path:

private\var\mobile\Containers\Shared\AppGroup\<APP_GUID>\cores\private\<USER_ID>\chunked_upload_storage\data_cache

iLEAPP now has a parser for this one as well, hope this helps people in their investigations.

Figure 9: Pending Uploads report in iLEAPP

DFIR Review

The article details the databases and various tables of interest, as well as the format in which attachments can be found and their metadata. Since the article is written in the first person, it was suggested that writing author should be indicated to distinguish between the two authors.

One of the reviewers was able to validate many of the author’s findings.

A reference was made to the testing performed to determine that the scaled SHA-1 hash matched the file. One of the reviewers asked what testing methodology was used to determine this?

Reviewers were curious if any of this information would be retained if the message containing the attachment was individually deleted (as opposed to deleting the entire chat)? Also, if the attachment was uploaded but not sent, would there still be a plist file created in the content_manager\data_cache folder?

Future Work

Reviewers are interested in knowing if the attachments are linked to the messages in the report or not.

Future work on this topic could also include research into other types of attachments such as videos and hyperlinks. For instance, during validation, it was found that hyperlinks store their base64-encoded link previews as well as URLs and (in some cases) bot information in their corresponding attachment plist files. However, they do not have a corresponding file in data_cache.

It would also be interesting to conduct additional research on the effect of deletions as well as the meaning of some other fields in the ZKIKATTACHMENT table (e.g. ZSTATE, ZTYPE).

Below figure 6, it is mentioned that the bplists with the Base 64 code of the attachment is extracted by Cellebrite. Are those also parsed by Cellebrite, or other widespread commercial solutions? This information would be useful to practitioners, to know whether the need to parse their extraction specifically with iLEAPP or not if they want to see the attachments.

Reviewers

Nickolas Ligman (Methodology Review)

Aurèle Scoundrianos (Methodology Review)

Linda Shou (Methodology Review, Validated Review using Reviewer Generated Datasets)