Glasgow Caledonian University: Kik Messenger Forensic Analysis Report

This report details a forensic analysis of Kik Messenger on Apple iOS devices. The study focuses on identifying and recovering artifacts created or modified by Kik messenger, including chat histories and multimedia files. Experiments were conducted to locate and document artifacts on iOS devices and within iTunes backup files. The research reveals the recoverability of deleted images from both the device and Kik servers. A process for linking data from multiple database tables to reconstruct accurate chat histories is explained. The findings offer valuable insights for law enforcement in investigating crimes and for software developers in creating forensic tools. The study also reviews related research on instant messaging applications and iOS device forensics, providing context for the Kik messenger analysis. The methodologies include the use of freely available tools to extract and present Kik artifacts, which can also be used by other software developers to create more forensic tools that can accurately retrieve relevant data.

Digital Investigation 17 (2016) 40e 52
Forensic analysis of Kik messenger on iOS devices
Kenneth M. Ovens*, Gordon Morison
School of Engineering & Built Environment, Glasgow Caledonian University, Cowcaddens Road, Glasgow, G4 0BA, Scotland, United
Kingdom
a rt i c l e i nf o
Article history:
Received 4 November 2015
Received in revised form 30 March 2016
Accepted 1 April 2016
Available online 30 April 2016
Keywords:
Kik
Instant messaging
iOS
Mobile device forensics
Apple
a b s t r a c t
Instant messaging applications continue to grow in popularity as a means of comm
cating and sharing multimediafiles. The information contained within these applications
can prove invaluable to law enforcement in the investigation of crimes.
Kik messenger is a recently introduced instant messaging application that has become ver
popular in a short period of time, especially among young users. The novelty of Kik means
that there has been little forensic examination conducted on this application.
This study addresses this issue by investigating Kik messenger on Apple iOS devices. The
goal was to locate and document artefacts created or modified by Kik messenger on de- vices
installed with the latest version of iOS, as well as in iTunes backupfiles. Once ach- ieved,
the secondary goal was to analyse the artefacts to decode and interpret their meaning and
by doing so, be able to answer the typical questions faced by forensic investigators.
A detailed description of artefacts created or modified by Kik messenger is provided. Re-
sults from experiments showed that deleted images are not only recoverable from
device, but can also be located and downloaded from Kik servers. A process to link data fr
multiple database tables producing accurate chat histories is explained. These out- comes
can be used by law enforcement to investigate crimes and by software developers to creat
tools to recover evidence.
© 2016 Elsevier Ltd. All rights reserved.
Introduction
Instant messaging is not new; in fact, it has been claimed
to be older than the Internet itself (Van Vleck, 2012).The
popularity of messaging applications grew in the 1990's
when graphical user interfaces replaced text-based
interfaces. At that time, the popular applications included
AOL Instant Messenger, ICQ and Yahoo! Messenger.
What is relatively novel is the popularity they have gained
on the mobile platform. Just as smartphones and tablets
overtake laptops and personal computers as the most
popular method of accessing the Internet, instant
* Corresponding author.
E-mail address: [e-mail] (K.M. Ovens).
messaging applications are significantly gaining ground on
traditional phone calls and text messaging as the favoured
means of communication, especially for the younger gen-
eration (Ofcom, 2015).
There are now billions of instant messaging user ac-
counts; currently the most popular applications include
WhatsApp, Facebook Messenger, Skype, and Viber. A more
recent addition to instant messaging, and one that is
especially popular among younger users, is the application,
Kik. Launched in 2010, Kik's user base has currently grown
to over 200 million, including 40% of American youth, ac-
cording to the developer's website (Kik, 2015b).
As Kik has grown in popularity, crimes that have in some
way involved the application, have also increased, partic-
ularly crimes that involve bullying and child abuse (Alvarez,
2013; Federal Bureau of Investigation, 2015; Zauzmer,
http://dx.doi.org/10.1016/j.diin.2016.04.001
1742-2876/© 2016 Elsevier Ltd. All rights reserved.
Contents lists available at ScienceDirect
Digital Investigation
journal homepage: www.elsevier.com/locate/diin

K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52 41
2014). These types of crimes are not unique to Kik, but weak
user identification, no age verification, as well as user's
perceived anonymity, may be combining to create user
behaviours that are of concern to law enforcement (Godfrey,
2013; Larson, 2015).
During registration of a new account, the user is
prompted to submit afirst and last name, a unique user-
name, email address, password, and a date of birth. How-
ever, there is no requirement to link a mobile phone number
and failure to verify the email address does not prohibit the
user sending messages. In comparison to registering a new
account with Facebook, where it is a requirement to use your
real name, if email addresses are not verified, the accounts
cannot continue to be used. New account registrations for
WhatsApp and Viber require phone numbers to be linked
and verified. While it is not too difficult for a determined
person to bypass these verifica- tion steps, there is little
effort required to bypass Kik's verification procedures and
age restrictions. Kik states that users are required to be at
least thirteen years old, as this also is not verified, it is very
easy for younger users to enter a fake date of birth and begin
communicating immediately (Kik, 2015c).
What will be of further concern to law enforcement, is
that Kik do not store and cannot retrieve any sent or received
messages (Kik, 2015a). It is therefore crucial that forensic
examiners are able to obtain as much information as
possible from recovered mobile devices to aid investigations.
While there has been a growing body of research concerning
the more established instant messaging applications, to
date, there is a distinct lack of detailed forensic investigation
focused on Kik messenger.
The situation prompts this study into the identification,
recovery, and analysis of artefacts relating to the usage of Kik
messenger. This study provides thefirst detailed forensic
analysis of Kik on Apple iOS devices. Other plat- forms on
which Kik can be installed (Android, Windows, Amazon) are
outside the scope of this study and are left for future work.
Preconditions to accessing these artefacts are that the iOS
device is not password locked and the inves- tigator has
access to unencrypted backupfiles.
The following proposed questions, common to forensic
examinations, are the focus of this study:
1. Who has the user been communicating with and when?
2. What was the content of the communications?
3. What attachments were exchanged and where can they
be found?
The study was conducted using tools that are freely
available to practitioners. The results were used to develop
open-source software that can be used to extract and present
Kik artefacts, and can likewise be used by other software
developers to create more forensic tools that can accurately
retrieve relevant data. It also contributes to the documenta-
tion and analysis of artefacts created by Kikmessenger,
benefiting law enforcement in their investigations.
The rest of this paper is structured as follows: Section
Related work presents an overview of research conducted
into instant messaging applications and discusses methods
used to acquire data from iOS devices. Section
Methodology describes the experiments undertaken to
address the typical questions that would arise in a forensic
investigation. Section Forensic analysis of Kik messenger
reports the results and analysis of the exper- iments. Finally,
Section Conclusions and future work draws conclusions
from the study and proposes avenues for future research.
Related work
A brief summary of the research methods, limitations,
and conclusions for each study has been provided.
Early instant messaging research on mobile devices
focused on the popular applications of the time. Husain and
Sridhar (2010) examined artefacts from three applications:
AIM, Yahoo! and Google Talk. With a limited data set (two
messages for each application), the authors locatedarte-
facts that could have been of evidentiary value. This was
achieved by searching the backupfiles of an iPhone 3G which
had a firmware version (later named iOS) of2.2.1. The
backup files were produced by Apple's mobile device
management application, iTunes.
A more comprehensive examination of the iTunes backup
data was performed by Bader and Baggili (2010), to establish
what data of forensic value could be recovered. The
researchers manually searched through the backupfiles of
an iPhone 3GS installed withfirmware version 3.1.2, and
located various types of data using command-line tools such
as ‘grep ’ and ‘find’. The iTunes backup files were then
matched against the originalfiles located on the iPhone. This
research isuseful and can be applied to studies of any
application that is backed up by iTunes.
Al Mutawa et al. (2012) researched social networking
applications that also offer instant messaging features,
namely Facebook, MySpace, and Twitter. The devices
examined were iPhone 4 (iOS 4.3.3), Android, and Black-
Berry mobile phones. The methods employed for the study
involved installing the social networking applications on the
devices, performing common user activities, then obtaining
a logical image of each device before conducting a manual
analysis. For the iOS device, the researchers used the iTunes
application to obtain a backup of the userfiles. From this,
they were able to extract artefacts relatingto the social
networking applications.
Tso et al. (2012) also focused on examining social
networking applications and chose the most popular ap-
plications at that time, Facebook Chat, Viber, Skype, What-
sApp, and Windows Live Messenger. One of the reasons
stated as justification for the study was that the applications
provide instant and convenient information transmission
used by criminals. The researchers examined an iPhone 4
with iOS 4.3.5 installed. Again, the iTunes backup applica-
tion was leveraged to acquire the relevant artefacts.
Sgaras et al. (2015) also highlighted the growing concern
of instant messaging applications being used by criminals to
communicate with victims or to evade detec- tion. The
researchers suggested that published studies focused mainly
on Android devices, whereas iOS devices had not been
extensively examined. Commercial tools, namely Cellebrites
UFED (Universal Forensic Extraction Device), were used to
extract and classify data from

42 K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52
messaging applications WhatsApp, Viber, Skype, and Tango,
on an iPhone (iOS 6.1.3) and an Android device.
Comparing various data extraction methods available at
the time of the study, Hay et al. (2011) concluded that in
order to perform a comprehensive examination of an iOS
device, it would need to be jailbroken and manually ana-
lysed. This method has raised concerns regarding changes
made to the device during the jailbreaking process (Husain
et al., 2011; Piccinelli and Gubian, 2011). However, it could
be used initially, to gain an understanding of Kik messen-
ger's mechanics by observing the creation and modification
of data as the application is used.
As with most research in digital forensics, these studies
have focused mainly on the forensic acquisition of data from
devices, with less emphasis on the analysis and
interpretation of that data. Studies that have investigated
how recovered data could be interpreted and applied to
criminal investigations include Levinson et al. (2011). This
study used a mock scenario where Facebook Chat artefacts
found on an iOS device provided key evidence in a police
investigation.
Another study that focused on the interpretation of
recovered instant messaging data was provided by Anglano
(2014). The researcher examined the WhatsApp Messenger
application on an Android operating system installed in a
virtual environment. As well as documenting the locations of
databases and logfiles, these artefacts were then ana- lysed
to provide detailed descriptions of how data from disparate
sources can be linked to infer meaning. While the study was
based on a different mobile platform and messaging
application to those used in this study, the focus on artefact
analysis and interpretation is very relevant.
Just one year after Kik was released, Hoog and Strzempka
(2011) briefly described Kik artefacts on iPhones installed
with iOS 3.1.3 and 4.0. At the time of this study the main Kik
database only had four tables (it has now grown to sixteen)
and the researchers report that the user passwordswere
found on the devices stored unencrypted.
A more recent study was conducted by Walnycky et al.
(2015). The researchers used a novel approach to acquire the
related mobile data, setting up a‘man-in-the-middle ’ attack to
intercept messaging application traffic. A total of twenty
popular instant messaging applications were used in the
experiments, including Kik messenger. The results, relating
to Kik, revealed that some network traffic, con- cerning the
sharing of sketches (electronic drawings), was found to be
unencrypted and could be captured in transit. The study
highlighted further privacy concerns regarding a large
section of the messaging applications. However, as would be
expected in a high level and wide-ranging study, it did not
explore Kik databases or other relevant artefacts in any
detail.
There have been various articles and blogs regarding Kik
iOS forensic research published online. These articles are
mainly brief overviews of Kik artefacts or tutorials on how to
use the commercial tools being promoted (Magnet
Forensics, 2014; Timofeev et al., 2015; Manon, 2015;
Sanderson, 2015). Other articles are from educational in-
stitutions discussing outputs from forensic courses
(Computer and Digital Forensics Blog, 2015), and industry
practitioners describing specific cases (Bridgey the Geek,
2013). Of particular note is this last article, described by the
author as a“work in progress”. It aimed to identify ar- tefacts
that the commercial tools did not. Although the study was
incomplete and is now dated (both iOS and Kik have
modified theirfile structures, new tables have been added to
the main database,flag structures have changed and more
features have been added to the application), it provided
insight into the workings of Kik messenger and helped define
various flags used in the databases, some of which are still
applicable in the latest versions of Kik.
This research builds upon the previous efforts of re-
searchers and practitioners and will be focussing solely on
Kik messenger on iOS devices, to provide detailed, up-to-
date, descriptions of Kik artefacts, locations and in-
terpretations as well as practical guidelines on how to parse
databases to provide human-readable reconstructionsof
user conversations.
Methodology
The main purpose of this study was to identify, locate and
analyse artefacts modified or created by the Kik messenger
application in order to answer the typical questions faced by
forensic investigators in their efforts to solve crimes.
The goal of this study was achieved by conducting a set of
controlled experiments using Kik messenger on iOSde-
vices, simulating specific user scenarios: one-to-one chats,
group communications,image and video exchange, etc.
After each experiment, the relevant data was copied to a
forensic workstation for manual analysis.
Access to the iOSfi le system was required to observe
whatfi les were being created and modified during usage of
the Kik application. As this meant that a comprehensive
manual examination was required, two of the iOS devices
were jailbroken to bypass the access restrictions placed on
the iOSfi le system by Apple.
Jailbreaking is a process that allows users to install and
execute applications that have not been approved by Apple.
These applications were required by the researcher to ac-
cess the iOS devices with a fully interactive shell and query
the file system to observe changes as they happened within
the Kik application.
After the analysis revealed which Kik artefacts were of
potential forensic interest, a backup of the third iOS device
was performed using iTunes. This was done to ensure that
the same type of artefact could be acquired by a forensic
investigator without having to jailbreak the device.
The experiments were broken down into three main
stages: Thefirst stage consisted of preparing the iOS de-
vices. A factory reset of the iOS device was performed to wipe
all previous contents and settings. iOS 9.02 was installed
before jailbreakingtwo of the devices and installingthe
software package manager, Cydia, and variousfile system
tools detailed in Table 1. Kik messenger was downloaded
from the App Store and installed in all three iOS devices.
New user accounts were created for each device.
The second stage involved querying the jailbroken iOS
devices to identify artefacts that were created or modified
after thefirst step. Thefi le systems were queried to identify

K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52 43
Table 1
Devices and software used in application testing.
Device/Software Use
Compa
ny/
Developer
Version
Analysis techniques included file identification, string
searching,filtering, file carving, and browsingfile systems.
Databases were analysed with thesqlite3 command utility
and then converted, using a crafted Python script (available
iPad mini× 3
(MD531B/A)
Devices to
be analysed
Apple iOS 9.0.2 from author), to a spreadsheet format for easier viewing
and analysis. Binary property lists (plists) were converted
Kik Application
testing
iTunes Create backup
of iPads
Taig Jailbreak Gain access to
Tool iOS file system
Kik Interactive 9.6.0
Inc.
Apple 12.3.2.35
Taig 2.4.1
to XML and analysed using a text editor.
After the study was completed, and to confirm that the
important artefacts identified were able to be acquired using
an established method, a logical acquisition of the iOS
device, that was not jailbroken, was performed using the
Cydia Software manager
to installfile
system tools
Jay Freeman
(saurik)
1.1.26 iTunes application. A logical acquisition interacts with the
devicefile system and can produce many important arte-
www.hexed.it Online hex editor to
analyse binaryfi les
Jens Duttke 2015.09.02 facts. A limitation of this method is that deleted items are
not recovered. However, all artefacts referred to in this
openSSH Secure Shell (ssh)
connection to iPads
Jay Freeman
(saurik)
6.7p1-13 study can be acquired from the iTunes backupfiles.
Other established methods could also have been used to
SQLite3 View SQLite
databases
Python Code scripts for
data analysis
and file carving
sqlite.org 3.8.10.2
Python Software 2.7.10
Foundation
acquire the data, such as the commercial tools, Lantern by
Katana Forensics, Forensic Extractor by Oxygen Forensics,
and the Elcomsoft Mobile Forensic Bundle. However,
iTunes was utilised as it is free application used for syn-
Find Utilities Indexes and Jay Freeman 4.2.33e7 chronising and backing up various Apple devices. While not
searchesfi le systems (saurik)
newly created or modified files using the following Unix
fi nd command:
This command is broken down and explained as follows:
● find e search
● /- from the root of the file system
● -type f e for a regularfile
● -mmin — 2 e that has been modified in the past 2 min
● > kikFiles.txt e redirect output to a text document
This query inevitably produced many false positives, as
there are continuous non-related background processes also
running. The false positives were reduced by repeating the
process at various times, not using other applications before
executing the message exchange, monitoring network
activity and manual inspection andfiltering of non-related
data.
The relevantfiles were then hashed and copied over to a
forensic workstation for further analysis. This step was
repeated after every interaction, in order to identify the
changes made to thefile systems. The types of interactions
included: searching for friends and groups to initiate chats,
sending and receiving messages from users and groups,
sending and receiving images and videos.
On occasion, for example, when trying to identify
changes in message status, the analysis would take place on
the iOS devices. The relevant databases would be system -
atically queried at source fromthe command-line using
sqlite3 , to monitor the changing flags that indicatedthe
progress of the message as it left the device and was
delivered to the recipient.
The third and final stage involved manually analysing
the artefacts. To begin with thefiles were hashed again to
confirm that they had not been modified in transition.

44 K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52
a forensic data acquisition tool, this method hasbeen
leveraged by various researchers to extract iOS device ar-
tefacts (Bader and Baggili, 2010; Said et al., 2011; Hay et
al., 2011; Al Mutawa et al., 2012).
If the artefacts were available from backupfiles, then it
would be expected that commercial tools would have little
difficulty in acquiring the relevant data. The iTunes appli-
cation offers users the choice of storing backupfiles locally
on a host computer, with our without encryption, or
remotely on Apple servers in an iCloud account. Following
the procedures established by Bader and Baggili (2010),
all the important artefacts discussed in the following
section, were located and identified.
Forensic analysis of Kik messenger
Without any need to provide a mobile phone number
or validated email address, users can immediately begin
communicating with other Kik users after downloading
and installing the Kik messenger application fromthe
iTunes store. After creating a profile consisting of a unique
username and optional profile picture, users can search
for the username of friends orfind the hashtag of public
groups they wish to join. This is all that is required to begin
exchanging text messages, pictures, and videos in relative
anonymity.
Kik messenger uses a client-server model with Kik's
servers relaying the messages between users, storing user
profiles for indexing and searching, as well as authenti-
cating users to their profiles when logging in.
The rest of this section discusses the artefacts created
by the usage of the Kik messenger application, beginning
with the installation locations, then focussing on contact
arte- facts andfinally analysing message exchanges.
Kik installation files
Prior to Kik version 9.5, application code and other re-
sources used by the code, were installed in theBundle

K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52 45
directory:/private/var/mobile/Containers/
Bundle/Application/ < UUID > /Kik-Release-
< x.x > .app/
User data was stored in theData directory:/private/
var/mobile/Containers/Data/Application/
<UUID> /
Since the release of Kik version 9.5 in February 2016,
there is now a third location for user data in aShared
directory: /private/var/mobile/Containers/
Shared/AppGroup/ < UUID > /cores/private/ < 32-
digit-hex > /
This new directory was created to take advantage of a new
feature of iOS that allows data to be shared across different
applications (Apple, 2016). It contains the artefactsthat
would be of most interest to a forensic investigator.
These directories andfi les were discovered using the
fi nd command described in thesecond stage of Section
Methodology and allowed this study to focus the analysis in
this location.
Since the introduction of iOS 8 in September 2014, ap-
plications are no longer stored in folders of their name.
Instead, the application folders are assigned a Universally
Unique Identifier (UUID), that changes every time the
application is updated. Consequently, locating the correct
Kik folder, among the many applications the user may have
installed, requires a recursive search of theBundle , Data and
Shared folders to locate Kikfiles, such as the main database,
kik.sqlite .
The main database and other important artefact loca-
tions are listed in Table 2 and were all found in the new
Shared location mentioned above. For Kik versions prior to
9.5, these artefacts can be found in theData folder.
Alternatively, thekik.sqlite database and other artefacts
can be acquired from the iTunes backup files. On Mac
computers, the iTunes backupfiles are located in:
/Users/ < username > /Library/Application Sup-
port/MobileSync/Backup/
On Microsoft Windows PCs the backupfiles can be found
in:
C:\Users\ < username > \AppData\Roaming\Apple
Computer\MobileSync\Backup
Apart from message attachments, which are stored with
an UUID filename, most Kik relatedfiles on the iOS device
have names and suffixes that hint at their content. How-
ever, allfiles that are backed up to a computer using iTunes
are obfuscated using a forty-character alpha-numeric name,
making it difficult to know whatfiles relate to the Kik
application among the hundreds, and sometimes thousands,
of other backupfiles. However, there is a
method available to link backupfiles to the originalfile
location (Crosby, 2010).
The backupfilenames are derived from a SHA1 hash of:
a) the application's iOS domain, and b) part of thefile's
original directory on the iOS device. For example, the Kik
application is part of theAppDomainGroup (a list of do-
mains and fi les can be found inManifest.mbdb , in the
iTunes backup folder).
The SHA1 hash of the string:AppDomainGroup-
group.com.kik.chat-cores/private/ < 32-digit-
hex > /kik.sqlite produced thefilename of thekik.sqlite
database stored in the iTunes backup during testing. The
fi lename will differ for every user due to the unique path-
names created by the variance in 32-digit hex numbers
used. This is a significant change from previous versions of
Kik.
As stated previously, prior to Kik version 9.5, the
kik .sqlite database was stored in theData directory on iOS
devices. The SHA1 hash of the string:‘ AppDomain-com.-
kik.chat-Documents/kik.sqlite ’ is 8e281be6657d
4523710d96341b6f86ba89b56df7 . Therefore, when
investigating Kik versions prior to 9.5, this is thefilename
(for all users) for thekik.sqlite database stored in the iTunes
backup.
Forensic software that searches for thekik.sqlite data-
base in iTunes backupfi les using the previously staticfil-
ename 8e281be6657d4523710d96341b6f86ba89b56 df7 ,
will require an update tofind the database, of newer Kik
versions, by another means. Furthermore, each new
version of Kik can result in variations in database struc-
tures. For example, from Kik version 8 to version 9, there
are now three new tables within thekik .sqlite database:
ZKIKATTRIBUTION , Z_MODELCACHE and ZKIKMESSA-
GEEXTRA . Also, table names have changed, possibly
relating to the version numbering e.g.Z_6ADMINSINVERSE
is now namedZ_8ADMINSINVERSE .
Analysis of contact information
Of the artefacts identified in this study and listed in Table
2, the majority of important information relating toKik
messenger usage is located within the SQLite database,
kik.sqlite . Table 3 shows the sixteen tables that make up the
database together with descriptions for each table. A thor-
ough analysis of these tables is discussed in later sections.
Forensic investigators will often need to know with whom
a suspect, or victim, has been communicating.Con- tact
information is invaluable to any investigation. This section
analysis the contacts table,ZKIKUSER , detailing the
Table 2
Kik version (9.6.0) artefacts found in the basefolder:/private/var/mobile/Containers/Shared/AppGroup/ < UUID > /cores/private/ < 32- digit-
hex> /
Row Content Folder (relative to base folder) File
1 Kik database . kik.sqlite, see Table 3
2 Plists containing image previews /attachments/ various UUIDs
3 Attachments /content_manager/data_cache/ various UUIDs
4 Plists containing image previews and URLs /content_manager/metadata_cache/ various UUIDs
5 Profile pictures /profpix/ [e-mail]
6 Username, preferences, SHA1 of password /Library/Preferences/ group.com.kik.chat.plist

46 K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52
Table 3
Structure of thekik .sqlite version (9.6.0) database.
Row Table Description
1 ZKIKATTACHMENT time stamps and associated
message number, see Table 7
2 ZKIKATTACHMENTEXTRA list of attachments received
3 ZKIKATTRIBUTION links users to groups
4 ZKIKCHAT time stamps and status of last
message, see Table 5
5 ZKIKCHATEXTRA last messages between contacts
6 ZKIKMESSAGE time stamps and content of
messages, see Table 6
7 ZKIKMESSAGEEXTRA messages that have been
displayed on user's screen
8 ZKIKUSER list of contacts and search results
for contacts, see Table 4
9 ZKIKUSEREXTRA kik user's status and activity
10 Z_4MESSAGES sequence of messages for each
individual chat
11 Z_8ADMINSINVERSE group and administrator's ID
12 Z_8BANSINVERSE group ID and banned users' ID
13 Z_8MEMBERS group and member's ID
14 Z_METADATA plist containing hashes of table
model versions
15 Z_MODELCACHE data blob
16 Z_PRIMARYKEY index of database tables
location of contact artefacts and then discusses how this
data can be used to a) retrieve and list the current contacts,
b) determine whether a contact has been blocked, c) recover
deleted contacts, and d) understand group membership.
Retrieving contact information
The analysis of theZKIKUSER table, the structure of
which is shown in Table 4, revealed that it not only con-
tained contacts that the user communicated with, but also
other Kik users suggested by the search engine when the user
searched for friends using theFind People feature.
There had been no communications with these other Kik
users, which was confirmed by observing the user status
field, ZFLAGS . Other names that appeared in theZKIKUSER
table were fellow members of public groups that had no
direct contact with the user.
There also appeared non-human users ebots, which are
software programs used to chat with Kik users using pattern
matching techniques to appear human. Thesebots are run by
Kik's administrators, as well as companies who market their
brands through a feature calledPromoted Chats .
Within theZKIKUSER table there are variousfields used
for names or identifiers. One of thesefields,ZUSERNAME , is
the unique username that is created during registration of a
new Kik account. This is the only piece of information that
Kik uses to identify an account and it cannot be changed by
the user. However, users can change their displayname
(ZDISPLAYNAME ) whenever they wish to. Both username
and display names are visible to other users.
The unique username is used to create the JabberID,
ZJID. This relates to the original Extensible Messaging and
Presence Protocol (XMPP), which is the basis of Kik's, and
many other messaging applications, communication
architecture.
Public and private groups are given a thirteen-digit
number appended with [e-mail] for their
Jabber ID. Public groups have theZGROUPTAG field populated
in the form of a hashtag. The hashtag is the name of the group
and it is what is used by people to search and join groups.
Finally, each user and group are also assigned a number
in the ZEXTRA fi eld. The number is based on when the user
or groupfirst appeared in the user's database; the higher the
number, the more recent the user or group was added to the
database. This number is used in tables throughoutthe
database, often in theZUSER fi eld, and can be used to link
data together from the various tables.
Table 4
ZKIKUSER version (9.6.0) database table.
Row Field name Description
1 Z_PK primary key
2 Z_ENT relates toZ_PRIMARYKEY table; 8¼ ZKIKUSER table
3 Z_OPT unknown - integer accumulates with messages and status changes
4 ZADDRESSBOOKID always 0
5 ZFLAGS contact status
6 ZINTERNALID always 0
7 ZPRESENCE always 1
8 ZTYPE always 1
9 ZATTRIBUTION links to theZKIKATTRIBUTION table
10 ZCHATUSER relates toZKIKCHAT table
11 ZEXTRA local ID of user
12 ZLASTMESSAGE blank
13 ZDISPLAYNAME the current name being used.
14 ZDISPLAYNAMEASCII as above, in ASCII
15 ZEMAIL blank
16 ZFIRSTNAME chosenfirst name
17 ZGROUPTAG hashtag name of group (deprecated)
18 ZJID Jabber ID in the format of< ZUSERNAME > _ < abc >[e-mail] .
19 ZLASTNAME chosen last name
20 ZPPTIMESTAMP 13 digit Unix epoch time (UTC) of when the contact uploaded their profile picture
21 ZPPURL web URL location of the contact's profile picture
22 ZSTATUS blank
23 ZUSERNAME the unique name that the user has registered with Kik.
24 ZCONTENTLINKSPROTODATA web links

K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52 47
With so many contacts appearing within theZKIKUSER
table, it is important to be able to differentiatebetween
contacts that the user has communicated with and other Kik
users that are of no interest to an investigation. The
relationship status of other Kik users is defined by the
ZFLAGS fi eld. Numeric codes are used to representthis
relationship. Experiments undertaken appear to show the
following codes defined as:
2 e unknown
8,14e groups user has left
9,11e groups user is a member of
128e132 e KikPromoted Chats/bots (marketing feature)
256 e group members and search engine suggestions, no
connections.
257e other users the account holder has communicated
with
258 e Kik account user
260 e unknown
288e289 e blocked users
385 e kikteam administrators and connectedPromoted
Chats
● 417e previousPromoted Chats , inactive
The ZFLAGS codes only relate to the relationship status
at the time of data acquisition and there appears to be no
way of discovering previous relationship statuses.
The profile picture a user chooses could be a clue to their
identity. Whether it is a self portrait, an identifiable back-
ground object or location, or a favourite image previously
used on other accounts, these artefacts can be of eviden-
tiary value. Table 2, row no. 5, details where an investigator
can locate the thumbnail profile images of Kik contacts. A
further source of profile images was discovered in the
ZPPURL fi eld. This provided a uniform resource locator
(URL) pointing to the Internet location of the contact's
profile picture. Entering the URL into a web browser and
appending /orig.jpg or/thumb.jpg retrieved a copy of
the image. The time a contact last updated their profile
picture was revealed in theZPPTIMESTAMP fi eld, which is
written in a thirteen-digit Unix epoch time format, reflecting
Coordinated Universal Time (UTC).
The ZKIKCHAT table, shown in Table 5, stored details of
other users that were either blocked or had been involved in
message exchanges with the user. The interactions that
involved message exchanges were indicated by the
ZLASTMESSAGE and ZDATEUPDATED field being populated.
Table 5
Structure of the ZKIKCHAT version (9.6.0) table.
Row Field name Description
1 Z_PK primary key
2 Z_ENT from Z_PRIMARYKEY table,
4 ¼ ZKIKCHAT
3 Z_OPT linked to volume of interactions
4 ZFLAGS unknown
5 ZDRAFTMESSAGE blank
6 ZEXTRA sequence of interactions
7 ZLASTMESSAGE last message with user or group
8 ZUSER local user ID
9 ZDATEUPDATED Mac Absolute time stamp (UTC)
of last message
The interactions that had no messages or time stamps
appear to be other users that had been blocked before any
chats were initiated. TheZ_OPT fi eld relates to the volume
of activity between users. It was noticeable that the greater
the volume of messages exchanged between the user or
group, the greater theZ_OPT number. Therefore, this data
correlates with whom the user had communicated most.
Dealing with blocked contacts
Kik provides a facility to block unwanted contact from
other users. Any subsequent messages from a blocked person
will be hidden from the user. However, experiments showed
that messages from a blocked user were still delivered to the
device and could be found in theZKIKMESSAGE table in the
kik.sqlite database. Although the Kik website states that all
chats with the blocked person will be deleted, this only
applied to what was displayed to the user. Previous chat
messages were still present in theZKIKMESSAGE table and
were used to reinstate the con- versation exchange when the
other Kik user was unblocked. This included messages
previously not dis- played while the other Kik user was
blocked. Attachments from blocked users were still present
in the locations shown in Table 2, row no. 3. The other user's
status, shown in theZFLAGS fi eld, changed from257 to 256
when the user was blocked, and reverted back to257 when
unblocked. No evidence could be found as to when a con-
tact was blocked or unblocked.
Recovering deleted contacts
Kik provides users with the option to delete contacts
from their chat lists. Selecting this option removes the
contact, and any previous conversations with that contact,
from the chat list display. From the perspective of the Kik
user, the‘deleted ’ contact and chats are no longer available.
From the perspective of a forensic investigator, the‘deleted ’
contact and chats could still be recoverable from within the
kik.sqlite database. Experiments undertakenshowed that
deleting a contact had no noticeable effect on the
ZKIKUSER table (which stores contacts' details) and no
noticeable effect on theZKIKMESSAGE table (which stores
the content and details of previous chats). How long this
data remains within the database is dependent upon the
volume of messages the user subsequently sends and re-
ceives, as the data will eventually be overwritten with new
data. This issue is discussed further in SectionDeleted
messages .
Understanding group membership
Kik messenger provides the facility for users to chat with
each other as part of a group. The groups can have up tofifty
members and are either private, where entry is by invitation,
or public, open to anyone.
Analysis of thekik.sqlite database found four tables
concerned exclusively with Kik groups, Table 3, rows 3 and
11e13. TheZ_8MEMBERS table listed number codes relating
to each group the user was currently a member of, along with
the number codes of other group members. These number
codes refer to theZEXTRA fi eld in theZKIKUSER table,
which provides group names and the unique user- names of
members. Group administrators could be
●
●
●
●
●
●
●
●
●
●

48 K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52
identified from theZ_8ADMINSINVERSE table and a list of
banned users was found in theZ_8BANSINVERSE table.
Group members were added to theZKIKMESSAGE table
when they joined, left or posted messages to the group.
Despite being members of the same group, theZFLAGS
status of other group members remained at256, unless the
user engaged in a one-to-one chat with the other member.
Group administrative messages notified group mem-bers
when new users joined groups, users were blocked, and
group profile picture was changed. If the original group
message is still in the database, the time stamp of this
message can be used to determine when a user joined the
group, as the original message comes from the Kik
administration account stating the user has joined. Other
than the initialjoin message, there was no other evidence
found that could relate to when an individual was added to
a group.
When the user sent a message to a group, the group's
ZEXTRA number from theZKIKUSER table was used to
indicate the recipient. However, messages received from a
group appear as they would from an individual, i.e. it is the
individual's ZEXTRA number that appears in the user's
database, not the group number. This can make it difficult for
an investigator to reconstruct conversations, as it is not clear
on first viewing, if a message was received as a direct message
from the other user, or if it came via the group and therefore
visible to all other group members. This issue is discussed
further in SectionReconstructing the chat history .
As well as proactively joining a group, users could be
added to a group by other Kik users. For this to happen there
would need to have been previous communication between
the two users, i.e. theZFLAGS status of the user must be257 ;
a user cannot be added to a group unless they have
previously chatted with them. Once the user was added to a
group theZKIKMESSAGE table contained a message stating
the user has been added. Subsequent messages and
attachments were downloaded into the user's database even
if the user had not accessed the group. It should be noted
that the user may not know the nature and content of the
group to which they have been added, and they may have not
actually accessed or viewed any messages from the group.
This section dealt with the question as to whom a user
has been communicating with. More information is pro-
vided in relation to communications, including content and
timing in the next section.
Analysis of exchanged messages
As well as knowing with whom a user has been
communicating, investigators will want to know when the
communications took place and the content of themes-
sages. Furthermore, an investigator will want to know if any
attachments were exchanged and where these could be
found on the devices.
The following section,Structure of the message exchange
table , starts by revealing where exactly in thekik.sqlite
database, message content can be found. It then explains
how to recreate a message exchange timeline inRecon-
structing the chat history. How to identify and extract at-
tachments is discussed inMessage Attachments . Messages
Table 6
Structure of the ZKIKMESSAGE version (9.6.0) table.
Row Field name Description
1 Z_PK primary key
2 Z_ENT from Z_PRIMARYKEY
6 ¼ ZKIKMESSAGE
3 Z_OPT unknowne No's. 1 to 9 displayed
4 ZFLAGS 4 ¼ attachment, 0¼ all other
messages
5 ZINTERNALID chat sequence
6 ZSTATE delivery statuse see Section
Analysis of exchanged messages
7 ZSYSTEMSTATE 12 ¼ sent messages, 0¼ all other
messages
8 ZTYPE 1¼ received, 2¼ sent,
3 ¼ housekeeping messages to
group admin, 4¼ housekeeping
messages to group
9 ZCHATEXTRA links toZKIKCHATEXTRA table
10 ZDRAFTMESSAGECHAT blank
11 ZEXTRA links toZKIKMESSAGEEXTRA table
12 ZLASTMESSAGECHAT relates to last message from user
displayed on Kik app home screen
13 ZLASTMESSAGEUSER blank
14 ZUSER ZEXTRA ID fromZKIKUSER table
15 ZRECEIVEDTIMESTAMP Mac Absolute time (UTC) of
received message
16 ZTIMESTAMP Mac Absolute time (UTC) of sent
message
17 ZBODY message content
18 ZSTANZAID UUIDs
19 ZRENDERINSTRUCTIONSET blank
pass through various stages en route from sender to receiver
and these stages are clarified in Determining the status of a
message . Finally, Deleted messages discusses the forensic
implications of messages the user has attempted to delete.
Structure of the message exchange table
Message content, as well as metadata, is stored in the
ZKIKMESSAGE table, shown in Table 3, row no. 6, within
the kik.sqlite database. Table 6 shows the nineteenfields that
make up the table and, where known, provides a definition.
The mainfields of interest includeZBODY , which contains
the actual message text, theZFLAGS fi eld, which indicates if
the message contains attachments, and the time stampfields,
ZTIMESTAMP and ZRECEIVEDTIMESTAMP .
Reconstructing the chat history
To construct a meaningful chat timeline the information
sought from thekik.sqlite database consisted of:
what was said?e message content
who said it and who did they say it to?e sender/
receiver
● when were the messages sent?e message time stamps
● the correct sequence of the conversatione chronology
Data fromfi elds in four different tables was threaded
together to produce the chat history. Fig. 1 illustrates the
connections between the tables and thefields required to
reconstruct the chat. The following process shows how a
forensic investigator would use this information to isolate a
specific chat history:
●
●

K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52 49
¼ ¼
Fig. 1. Data taken from four tables to produce the chat history. The arrows link correspondingfields.
1. Starting with the username to be investigated (ZDIS-
PLAYNAME ), a query of theZKIKUSER table would pro-
vide theZEXTRA number relating to this user.
2. Locating this number within the ZUSER field of the
ZKIKCHAT table, the investigator would note theZEX-
TRA number, which is the conversation chat number.
3. This number links to the Z_4CHAT field in the
Z_4MESSAGES table and will provide all message
numbers that relate to that chat number in the
Z_6MESSAGES fi eld.
4. Finally, the message numbers can then be used to select
the message content from theZKIKMESSAGE table, along
with the time of receipt and message type (sent, received,
etc).
Combining these details from the various tables isolated
the conversations that had taken place between the user and
specific Kik contacts or groups. It also clarified if messages
were sent as direct messages to an individual or as part of a
group discussion. Fig. 2 shows the sqlite3 query that
produced a more human-readable format.
The command shown in Fig. 2 has been broken down to
provide an explanation:
Line 1e open the database with SQLite3 and display in
columns with headings
Line 2 e select the following:ZBODY but rename it to
‘Message’
Line 3e ZRECEIVEDTIMESTAMP and convert it to local
time in a human-readable format, renaming it‘Date’
Lines 4e9 e ZTYPE renamed as‘Type’ and change the
values: 1 rcvd, 2 sent, 3& 4 are group related
messages
Line 10 eZDISPLAYNAME but rename it‘User’
Line 11e Z_6MESSAGES but rename it‘Message No.’
Line 12 e fromZKIKMESSAGE table …
Line 13e … join to theZKIKUSER table whereZEXTRA
and ZUSER match
Line 14e and join to theZ_4MESSAGES table where
Z_6MESSAGES andZ_PK match, displaying the mes-
sages that relate to a chat number (1 in this instance)
Fig. 3 shows the output of thesqlite3 query presented it in
a more informative format. The output is colour-coded with
the field colours of Fig. 1, to link the query output back to
the original table location of the data.
This method of threading together conversations would
also apply to version 8 of Kik. However, thefield and table
names would need to be adjusted to suit i.e.Z_4MESSAGES ,
Z_6MESSAGES and Z_4CHAT were previously named
Z_3MESSAGES , Z_5MESSAGES and Z_3CHAT respectively.
Message attachments
This section addresses the questions an investigator
would have relating to a Kik user's exchange of pictures and
other attachments. As well as exchanging text messages,
●
●
●
●
●
●
●
●
●

50 K.M. Ovens, G. Morison / Digital Investigation 17 (2016) 40 e52
Fig. 2. The SQLite query used to parse the chat history.
Fig. 3. The output of the SQLite query.
Kik allows its users to send picture and videofiles. There is
also the facility to share web content e stickers, viral videos,
sketches, etc. This section will discuss the process and
creation of new artefacts when sending and receiving
attachments, the structure of the attachments database table
and the consequences of users deleting messages containing
attachments.
When a Kik user sends an image or video to another
contact or a group, thefile is uploaded to Kik servers at
htt ps: //p lat for m.k ik. com /conte nt/ file s/ < UUID >
and a copy of the attachment is stored on the device. A plist
containing a preview version of the attachment is also
created and stored. A further plist containing a link to the
URL is also created. The locations of thesefiles are shown in
Table 2, rows 2, 3 and 4.
On the recipient side, the user is notified of a new
message by a push notification, if this has been permitted in
the iOS security settings. When the recipient opens the Kik
application, all chats are updated and attachments are
downloaded to the same location mentioned above for sent
files; Table 2, rows 2, 3 and 4. The recipient does not have to
view thefiles for them to be downloaded onto their device.
This happens automaticallywhen the Kik application is
opened.
When accessing specific chats or groups, the preview or
thumbnail version of the attachment appears on the chat
timeline. The user can click on thefile to view the full version
on the screen. If the recipient chooses to save the
attachment, copies are made and are located in the usual iOS
media locations, e.g.
● /private/var/mobile/Media/DCIM/100APPLE/
● /private/var/mobile/Media/PhotoData/MISC/
● /private/var/mobile/Media/PhotoData/
Thumbnails/
● /private/var/mobile/Media/Photo-
StreamsData/8265296843/100APPLE/
Experiments showed that the process of saving an
attachment, modified the Exif data to include a thumbnail
image, resulting in a hash value mismatch with the original
image stored in/content_manager/datacache/ Table
2, row no. 3. The images and videos exchanged during the
experiments were analysed to check for identifiable
metadata, such as geolocation tags. However, none were
found.
With regards to the URLs embedded within plists, the Kik
application used a key or token for authentication