Wickr. Alright. We’ll Call It A Draw.

Ugh.  Not again.

Portions of this blog post appeared in the 6th issue of the INTERPOL Digital 4n6 Pulse newsletter. 

I would like to thank Heather Mahalik and Or Begam, both of Cellebrite, who helped make the Android database portion of this blog post possible, and Mike Williamson of Magnet Forensics for all the help with the underpinnings of the iOS version.

I have been seeing the above pop-up window lately.  A  lot.  Not to pick on any particular tool vendor, but seeing this window (or one simmilar to it) brings a small bit of misery.  Its existence means there is a high probability there is data on a particular mobile device that I am not going to get access to, and this is usually after I have spent a considerable amount of time trying to gain access to the device itself.  Frustrating.

One of my mentors from my time investigating homicides told me early in my career that I was not doing it right unless I had some unsolved homicides on the books; he felt it was some sort of badge of honor and showed a dedication to the craft.  I think there should be a similar mantra for digital forensic examiners.  If you conduct digital forensic examinations for any substantial amount of time you are going to have examinations where there is inaccesible data and nothing you do is going to change that.  You can throw every tool known to civilization at it, try to manually examine it, phone a friend, look on Twitter, search the blog-o-sphere, search the Discord Channel, query a listserv, and conduct your own research and you still strike out.  This is a reality in our discipline.

Not being able to access such data is no judgment of your abilities, it just means you may not win this round.  Keep in mind there is a larger fight, and how you react to this setback is a reflection of your dedication to our craft.  Do you let inaccessible data defeat you and you give up and quit, or do you carry on with that examination, getting what you can, and apply that same tenacity to future examinations?

One needs the latter mindset when it comes to Wickr.  For those that are unfamilar, Wickr is a company that makes a privacy-focused, ephemeral messaging application. Initially available as an iOS-only app, Wickr expanded their app to include Android, Windows, macOS, and Linux, and branched out from personal messaging (Wickr Me) to small teams and businesses (Wickr Pro – similar to Slack), and an enterprise platform (Wickr Enterprise).  Wickr first hit the app market in 2012, and has been quietly hanging around since then.  Personally, I am surpised it is not as popular as Signal,  but I think not having Edward Snowden’s endorsement and initially being secretive about its protocal may have hurt Wickr’s uptake a bit.

Regardless, this app can bring the pain to examinations.

Before I get started, a few things to note.  First, this post encompasses Android, iOS, macOS, and Windows.  Because of some time constraints I did not have time to test this in Linux.  Second, the devices and respective operating system versions/hardware are as follows:

Platform                    Version                 Device                                                   Wickr Version

Android                      9.0                         Pixel 3                                                    5.22

iOS                               12.4                       iPhone XS and iPad Pro 10.5            5.22

macOS                        10.14.6                  Mac Mini (2018)                                  5.28

Windows 10 Pro       1903                      Surface Pro                                           5.28

Third, Wickr Me contains the same encryption scheme and basic functionality as the Pro and Enterprise versions: encrypted messaging, encrypted file transfer, burn-on-read messages, audio calling, and secure “shredding” of data. The user interface of Wickr Me is similar to the other versions, so the following sections will discuss the functionality of Wickr while using the personal version.

Finally, how do you get the data?  Logical extractions, at a minimum, should grab desktop platform Wickr data during an extraction.  For Android devices, the data resides in the /data/data area of the file system, so if your tool can get to this area, you should be able to get Wickr data.  For iOS devices, you will need a jailbroken phone or an extraction tool such as one that is metal, gray, and can unlock a door to get the Wickr database.  I can confirm that a backup nor a logical extraction contains the iOS Wickr database.

Visual Walkaround

Wickr is available on Android, iOS, macOS, and Windows, and while these platforms are different, the Wickr user interface (UI) is relatively the same across these platforms. Figure 1 shows the Windows UI, Figure 2 shows the macOS UI, Figure 3 shows the iPhone, and Figure 4 shows the iPad. The security posture of the Wickr app on Android prevents screenshots from being taken on the device, so no UI figure is available.  Just know that it looks very similar to Figure 3.

Figure 1
Figure 1.  Wickr in Windows.
Figure 2.png
Figure 2.  Wickr in macOS.


Figure 3.png
Figure 3.  Wickr on iPhone.
Figure 4
Figure 4.  Wickr on iPad.

Each figure has certain features highlighted. In each figure the red box shows the icons for setting the expiration timer and burn on read (setting that allows the sender of a message to set a self-destruction timer on a message before it is sent – the recipient has no control over this feature), the blue arrow shows the area where a user composes a message, the orange arrow shows the area where conversations are listed, and the purple arrow shows the contents of the highlighted conversation (chosen in the conversations list).  Not highlighted is the phone icon seen in upper right corner of each figure. This initiates an audio call with the conversation participant(s).

The plus sign seen in the screen (red boxes) reveals a menu that has additional options: send a file (including media files), share a user’s location, or use one of the installed quick responses. Visually, the menu will look slightly different per platform, but the functionality is the same.  See Figure 5.

Figure 5
Figure 5.  Additional activity options (Windows UI).

The sending and receiving of messages and files works as other messaging applications with similar capabilities. Figure 6 shows an active conversation within the macOS UI.

Figure 6.png
Figure 6.  A conversation with a text message and picture attachments (macOS UI).

Wickr is similar to Snapchat in that messages “expire” after a set period of time. The default time a message is active is six (6) days, which is the maximum amount of time a message can be available, but a user can set message retention times as short as one second. This setting is device specific; if a user has multiple devices they can choose different retention periods for each device.

Users can also set “burn-on-read” times in which a message will expire (“burn”) after a certain period of time after the message has been read. This setting is controlled by the message sender, regardless of the recipient’s message retention period setting.  The retention period for burn-on-read messages can also be set anywhere between 1 second and 6 days. Figure 7 shows the Windows Wickr UI when a burn-on-read message has been received and opened (bottom of the active conversation window pane), and Figure 8 shows the same UI after the burn-on-read retention period expired.

Figure 7
Figure 7.  A burn-on-read message (timer in red).
Figure 8
Figure 8.  Poof! The message has been burned.

The Secure Shredder function is Wickr’s feature by which data that has been deleted by the app is rendered unrecoverable by overwriting the deleted data.  Secure Shredder is an automated feature that runs in the background but has a manual configuration feature if a user is part of the Wickr Pro Silver or Gold tiers, which allows users to manually initiate the function.  Testing showed this feature automatically runs every +/- one (1) minute while the device is idle.

Encryption.  All Of The Encryptions.

Wickr is designed with total privacy in mind, so all three versions use the same encryption model. The app not only protects messages, media, and files in transit, but it also protects data at rest. The app has been designed with perfect forward secrecy; if a user’s device is compromised, historical communications are still protected unless the attacker has the user’s password and the messages have not expired.

When a new message is received, it arrives in a “locked” state.  See Figure 9.

Figure 9.png
Figure 9.  A new message.

When a message is sent, the sender’s device will encrypt the message using a symmetric key. To generate the symmetric key, internal APIs gather random numbers which are then run through the AES-256 cryptographic algorithm in Galois/Counter Mode (GCM). Each message is encrypted using a new symmetric key, and this operation occurs strictly on the sender’s device. This encryption happens regardless of whether the message contains text, a file, or a combination of the two. The cipher text and the symmetric key (i.e. the package) are encrypted using the signed public key of the recipient’s device (I’ll discuss asymmetric operations in a minute), and then sent to the recipient who then decrypts the package using their private key. The symmetric key is then applied to the cipher text in order to decrypt it.

The takeaway here is that unlocking a received message = decrypting a received message.  A user may set their device to automatically unlock messages, but the default behavior is to leaved them locked on receipt and manually initiate the unlock.

Asymmetric operations are applied to messages in transit.  As previously mentioned, cipher text and the symmetric key used encrypt it are packaged up and encrypted using the public key of the intended recipient’s device.  The public key is signed with components from said device.  The recipient device uses the corresponding private key to decrypt the package, and then the symmetric key is used to decrypt the cipher text  (unlocking the message) so the recipient can read it. If a message is intended for multiple recipients or for a recipient who has multiple devices, a different set of keys is used for each destination device.

Here is where the pain starts to come. The keys used in the asymmetric operations are ephemeral; a different set of public/private key pairs are used each time a message is exchanged between devices. Wickr states in its technical paper that pools of components (not the actual keys themselves) of private-public pairs are created and refreshed by a user’s device while they are connected to Wickr’s servers.  If a device is disconnected from the Wickr servers, it will use what key pairs it has, and will then refresh its pool once it has re-established the connection.

Even if a private key is compromised, the only message that can be decrypted is the one that corresponds to that specific private/public key pair; the rest of the messages are still safe since they use different pairs.

But wait, it gets worse.  Just to turn the knife a bit more, Wickr has a different encryption scheme for on-device storage that is separate from message transfers.  When Wickr is first installed on a device a Node Storage Root Key (Knsr) is generated. The Knsr is then applied to certain device data (described as “device specific data and/or identifiers derived from installed hardware or operating system resources that are unique, constant across application installs but not necessary secret“) to generate the Local Device Storage Key (Klds). The Klds is used to encrypt Wickr data stored locally on the device, including files necessary for Wickr to operate.

The Klds is itself encrypted using a key derived from the user’s password being passed through scrypt. When a user successfully logs in to the Wickr app, the Klds is decrypted and placed into the device’s memory, allowing for successful exposure of the locally stored Wickr data through the app UI. When the app is terminated, placed in an inactive state, or a user logs out, the Klds is removed from memory, and the Wickr data is no longer available.

For those who have legal processes at their disposal (court orders, search warrants, & subpoenas), the news is equally dire.  Wickr does keep undelivered messages on their servers for up to six (6) days, but, as I previously mentioned, the messages (which are in transit) are encrypted.  Wickr states they do not have acess to any keys that would decrypt what messages are stored.  There is some generic account and device information, but no message content.  For more information on what little they do have, please read their legal process guide.

So, Is There Anything I Can Actually Get?

The answer to this question is the standard digital forensics answer:  “It depends.” The encryption scheme combined with the on-device security measures makes it extremely difficult to recover any useful data from either the app or Wickr, but there is some data that can be retrieved, the value of which depends on the goal of the examination.

Testing has shown a manual examination is the only way, as of the time of this post, to recover message content from iOS, macOS, and Windows (files not included). This requires unfettered access to the device along with the user’s Wickr password. Due to a change in its encryption scheme (when this happened is unknown), Wickr is not supported by any tool I tested on any platform, which included the current versions of Cellebrite, Axiom, and XRY. This included the Android virtualization options offered by two mobile vendors.  Along those same lines, I also tried Alexis Brignoni’s virtualization walkthrough using Nox Player, Virtual Box, and Genymotion, with no luck on all three platforms.

Things can be slightly different for those of you who have Wickr deployed in an enterprise environment.  The enterprise flavor of Wickr does have compliance (think FOIA requests and statutory/regulatory requirements) and eDiscovery features, which means message content may be retained so as long as the feature is enabled (I didn’t have access to this version so I could not ascertain if this was the case).  Just be aware that if the environment includes Wickr, this may be an option for you.

The type and amount of data an examiner can possibly get is dependant upon which platform is being examined. The nice thing is there is some consistency, so this can help examiners determine, rather quickly, if there is anything to be recovered.  The consistencey can be broken up in to two categories:  iOS and Android/macOS/Windows. One thing is consistent across ALL platforms, though: an examiner should not expect to find any message content beyond six (6) days from the time of examination.


The most important thing to remember for Android, macOS, and Windows platforms is that order matters when doing a manual examination. That is, the order in which you examine the device for Wickr content is important. Failure to keep this mind may result in recoverable data being deleted unnecessarily.  Android can be slightly different, which I will discuss shortly.

I will go ahead and get one thing out of the way with all three platforms: the databases containing account information, conversation information, contacts, and message content are all encrypted.  The  database is protected with SQL Cipher 3, and the Wickr user password is not the password to the database (I tried to apply the correct Wickr password in DB Browser for SQLite, and none would open – you’ll see why below). Figure 10 shows the macOS database in hexadecimal view and Figure 11 shows the Windows database.  While not shown here, just know the Android database looks the same.

Figure 10.png
Figure 10.  Wickr database in macOS
Figure 11.PNG
Figure 11.  Wickr database in Windows.

You may have noticed the file name for both macOS and Windows is the same:  wickr_db.sqlite.  The similarities do not stop there.  Figure 12 shows the location of the database in macOS, Figure 13 shows the database’s location in Windows.

Figure 12
Figure 12.  Home in macOS.  ~/Users/%UserName%/Library/ApplicationSupport/Wickr, LLC/WickrMe/
Figure 13
Figure 13.  Home in Windows.  C:\Users\%UserName%\AppData\Local\Wickr, LLC\WickrMe\

As you can see, most of the file names in each home directory are the same.  Note that the last folder in the path, “WickrMe,” may be different depending on what version is installed on the device (Wickr Me, Wickr Pro, Enterprise), so just know the last hop in the path may not be exactly the same.

Interesting note about the “preferences” file in Windows:  it is not encrypted.  It can be opened, and doing so reveals quite a bit of octet data.  The field “auid” caught my attention, and while I have a theory about its value, I’ll save it for another blog post.

For Android, the directory and layout should look familar to those who examine Android devices.  The database file, wickr_db, sits in the databases folder.  See Figure 14.

Figure 14
Figure 14.  Home in Android.  /data/data/com.mywickr.wickr2

If you will recall, when a user unlocks a message it is actually decrypting it.  This also applies to files that are sent through Wickr.  Unlike messages, which are stored within the database, files, both encrypted and decrypted, reside in the Wickr portion of the file system.  When a message with a file unlocked, an encrypted version is created within the Wickr portion of the file system.  When the file is opened (not just unlocked), it is decrypted, and a decrypted version of that file is created within a different path within the Wickr portion of the file system.  Figure 15 shows the Android files, Figure 16 shows the macOS files, and Figure 17 shows the Windows files.  The top portion of each figure shows the files in encrypted format and the bottom portion of the figure shows the files in decrypted format.

Figure 15.png
Figure 15.  Encrypted/decrypted files in Android.
Figure 16
Figure 16.  Encrypted/decrypted files in macOS.
Figure 17
Figure 17.  Encrypted/decrypted files in Windows.

When a file is sent through Wickr it is given a GUID, and that GUID is consistent across devices for both the sender and the recipient(s).  In the figures above, Android represents Test Account 1 and macOS/Windows represents Test Account 2, so you will notice that the same GUIDs are seen on both accounts (all three platforms).

The fact an encrypted version of a file exists indicates a device received the file and the message was unlocked, but doesn’t necessarily indicate the file was opened.  It isn’t until the user chooses to open the file within the Wickr UI that a decrypted version is deposited onto the device as seen above.  An example of the open dialogue is seen in Figure 18.  The triple dots in the upper righthand corner of the message bubble invokes the menu.

Figure 18.png
Figure 18.  Open dialogue example (Windows UI).

If a picture is received and the message is unlocked, then a thumbnail is rendered within the Wickr UI message screen, as seen in Figure 18, but this doesn’t deposit a decrypted version of that picture; the user must open the file.  Any other file type, including vidoes, merely display the original file name in the Wickr UI.  A user will have to open the file in order to view its contents.

The directories for files on each platform is as follows (path starts in the Wickr home directory):

Platform                                   Encrypted Files                                    Decrypted Files

Android                                    ~/files/enc                                             ~/cache/dec

macOS                                      ~/temp/attachments                           ~/temp/preview

Windows                                 ~/temp/attachments                           ~/temp/preview

This behavior applies to files both sent and received.  Also keep in mind there is a probability that you may find encrypted files with no corresponding decrypted version.  This may be due to the message retention time expiring, which is why the order of examination is important, or it may mean the user never opened the file.

For both macOS and Windows, the only way to recover message content is via a manual examination using the Wickr UI, which means that a logical image should contain the sought after data.  However, the order of your examination can impact your ability to recover any decrypted files that may be present on the device.  Since the Wickr application is keeping track of what files may have passed their message retention period, it is extremely important to check for decrypted files prior to initiating Wickr on the device for a manual examination.  Failure to do so will result in any decrypted file whose message retention time has expired being deleted.

The Android database.  Slightly different

While the databases for macOS and Windows are inaccessible, the story is better for Android.  While conducting research for this post I discovered Cellebrite Physical Analyzer was not able to decrypt the wickr_db database even though it was prompting for a password.  Cellebrite confirmed Wickr had, in fact, changed their encryption scheme and Physical Analyzer was not able to decrypt the data.  A short time later they had a solution, which allowed me to proceed with this part of the post.  While not currently available to the public, this solution will be rolled out in a future version of Physical Analyzer.  Fortunately, I was granted pre-release access to this feature.

Again, thank you Heather and Or.  🙂

While there is still a good deal of data within the wickr_db file that is obfuscated, the important parts are available to the examiner, once decrypted.  The first table of interest is “Wickr_Message.”  See Figure 19.

Figure 19.png
Figure 19.  Wickr_Message table.

The blue box is the timestamp for sent and received message (Unix Epoch) and the orange box contains the text of the message or the original file name that was either sent or received by the device.  The timestamp in the red box is the time the message will be deleted from the Wickr UI and database.  The values in the purple box are inteteresting.  Based on testing, each file I sent or received had a value of 6000 in the messageType column.  While not that important here, these values are important when discussing iOS.

The blobs in the messagePayload column are interesting in that they contain a lot of information about file transfers between devices.  See Figure 20.

Figure 20.png
Figure 20.  Message payload.

The file sender can be seen next to the red arrow, the file type (e.g., picture, document, etc.) is next to the blue arrow, the GUID assigned to the file is seen in green box.  The GUID values can be matched up to the GUIDs of the files found in the /enc and /dec folders.  Here, the GUID in the green box in Figure 20 can be seen in both folders in Figure 21.  Finally, you can see the original name of the file next to the purple arrow (iOS_screenshot).  The original file name also appears in the cachedText colum in Figure 19.

Figure 21
Figure 21.  Matching GUIDs

The orange box in Figure 20 contains the recipients username along with the hash value of the recipient’s Wickr User ID.  That value can be matched up to the value in the senderUserIDHash column in the same table (see the red box in Figure 22).  The title of this column is deceptive, because it isn’t actually the userID that is represented.

Figure 21
Figure 22.  Sender’s hashed ID

Figure 23 shows the same hash in the serverIDHash column in the table Wickr_ConvoUser table.

Figure 23
Figure 23.  Same IDs.

Also of note in this table and the one seen in Figure 22 is the column vGroupID.  Based on testing, it appears every conversation is considered to be a “group,” even if that group only has two people.  For example, in my testing I only had my two test accounts that were conversing with each other.  This is considered a “group,” and is assigned a GUID (seen in the blue box).  The good thing about this value is that it is consistent across devices and platforms, which could come in handy when trying to track down conversation participants or deleted conversations (by recovering it from another device).  An example of this cross-platform-ing is seen in Figure 24, which shows the table ZSECEX_CONVO from the Wickr database in iOS.  Note the same GroupID.

Figure 24
Figure 24.  Same group ID.

Figure 25 shows, again, the serverIDHash, but this time in the table Wickr_User.  It is associated with the value userIDHash.  The value userAliasHash (the same table) is seen in Figure 26.

Figure 25
Figure 25.  serverIDHash and the userIDHash.
Figure 26
Figure 26.  userIDHash (Part 2).

Figure 27 shows some telemetry for the users listed in this table.

Figure 27
Figure 27.  User telemetry.

The columns isHidden (purple box) and lastMessaged (red box) are self-explanatory.  The value of 1 in the isHidden column means the user does not appear in the Conversations section of the UI.  That value coupled with the value of 0 in the lastMessaged column indicates this row in the table probably belongs to the logged in account.

The lastRefreshTime column (blue box) has the same value in both cells.  The timestamp in the cell for row 1 is when I opened the Wickr app, which, undoubtedly, caused the app to pull down information from the server about my two accounts.  Whether this is what this value actually represents requires more testing.  The same goes for the values in lastActivityTime column (orange box).  The value seen in the cell in row 1 is, based on my notes, the last time I pushed the app to the background.  The interesting thing here is there was activity within the app the after the timestamp (the following day around lunch time PDT).  More testing is required in order to determine what these values actually represent.  For now, I would not trust lastActivityTime at face value.

The table Wickr_Settings contains data of its namesake.  The first column of interest is appConfiguration (red box).  See Figure 28.

Figure 28.PNG
Figure 28.  Wick_Settings

The data in this cell is in JSON format.  Figure 29 shows the first part of the contents.

Figure 29
Figure 29.  JSON, Part 1.

There are two notable values here.  The first, in the blue box, is self explanatory:  locationEnabled (Wickr can use location services).  I let Wickr have access to location services during initial setup, so this value is set to ‘true.’  The value in the red box, alwaysReauthenticate, refers to the setting that determines whether or not a user has to login into Wicker each time the app is accessed.  It corresponds to the switch in the Wickr settings seen in Figure 30 (red box).

Figure 30.PNG
Figure 30.  Login each time?  No thanks.

Because I didn’t want to be bothered with logging in each time, I opted to just have Wickr save my password and login automatically each time, thus this value is set to ‘false.’  If a user has this set and does not provide the Wickr password, a manual examination will be impossible.

The rest of the contents of the JSON data are unremarkable, and is seen in Figure 31.

Figure 31
Figure 31.  JSON, Part 2.  Nothing much.

There are three additional columns that are notable in this table.  The first is the setting for the Secure Shredder, autoShredderEnabled.  This value is set to 1, which means that it is enabled.  I would not expect to see any other value in this cell as Secure Shredder runs automatically in Wickr Me and some tiers of the Wickr Pro versions; there is no way to disable it unless the Silver, Gold, or Enterprise versions of Wickr is present.  See Figure 32.

Figure 32
Figure 32.  Anonymous Notifications, Secure Shredder, and Auto Unlock.

The second notable column is unlockMessagesEnabled (red box).  As its name implies, this setting dictates whether a message is unlocked on receipt, or if a user has to manually initiate the unlock.  I took the default setting, which is not to unlock a received message (database value of 0).  Figure 33 shows the setting in the Wickr Settings UI.

Figure 33
Figure 33.  Message Auto Unlock switch.

Figure 32 also shows anonymousNotificationsEnabled (orange box).  This setting dictates whether Wickr notifications provide any specific information about a received message/file (e.g., sender’s user name, text of a message, file name), or if the notification is generic (e.g., “You have a new message”).  Again, the default is to show generic notifications (database value of 1).  Figure 34 shows the setting in the Wickr Settings UI.  Note the switch is off, but since I have Auto Unlocks disabled, this switch is not used because my messages are not automatically unlocked on receipt.

Figure 34.PNG
Figure 34.  Anonymous Notification setting.

I want to address one last table;  Wickr_Convo.  Using the conversation GUIDs, you can determine the last activity within each conversation that is stored on the device.  In Figure 35, this conversation GUID is the same as the ones seen in Figure 23 and 25.

Figure 35
Figure 35.  Conversations listed by GUID.

There are two values that are notable.  The first is is the lastOutgoingMessageTimestamp (red box). That is a pretty self-explanatory label, right?  Not quite, and examiners should be careful interpreting this value.  That same timestamp appears in the Wickr_Message table seen in Figure 37, but with a different label.

Figure 36
Figure 36.  Wickr_Convo table timestamps.
Figure 37.png
Figure 37.  Wickr_Message table timestamps.

It appears that the lastOutgoingMessageTimestamp from Wickr_Convo applies to the last message that did not involve a file transfer (value timestamp seen in the Wickr_Message table) .  The value lastUpdatedTimestamp (blue box in Figure 36) actually represents the last communication (message or file transfer) in the conversation, which is seen in the blue-boxed timestamp value in the Wickr_Message table (blue box in Figure 37).

The value messageReadTimestamp (orange box in Figure 36) represents the time the last message was unlocked.  Notice that the value is just about the same as that seen in lastUpdatedTimestamp, but with more granularity.

A couple more things

There are two more files I’d like to touch on with regards to the Android version.  The first is com.google.android.gms.measurement.prefs.xml found in the /shared_prefs folder.  See Figure 38.

Figure 38
Figure 38.  Measurement data for the app.

This file keeps track of certain data about app usage.  The most obvious data points are the install time for the app itself (orange box) and the first time the app was opened (red box).  The next two data poins are app_backgrounded (yellow box) and last_pause_time (green box).  The app_backgrounded value, as you can see, is a boolean value that indicates whether the app is active on the device screen or if the app is running in the background (i.e. not front-and-center on the device).  The value last_pause_time is the last time the app was pushed to the background by the user (“paused”).  If an examiner is pulling this data from a seized device is highly likely that the app_backgrounded value will be true, unless the device is seized and imaged while Wickr is actively being used.

The value in the blue box, last_upload, is a deceiving value, and I have yet to figure out what exactly it represents.  I have a theory that it may be the last time the app uploaded information about its current public key which is used in the asymmetric encryption operations during message transport, but I can not be totally sure at this point.  Just know that last_upload may not necessarily represent the last time a file was uploaded.

The last file is COUNTLY_STORE.xml.  Based on research, it appears this file may be used for analytical purposes in conjunction with the Countly platform.  This file keeps some metrics about the app, including the cell service carrier, platofrm version (SDK version), hardware information, and a unique identifier, which, on Android, is the advertising ID (adid).  The data appears to be broken up into transactions with each transaction containing some or all of the data points I just mentioned. Each transaction appears to be separated by triple colons.  Each also contains a timestamp.

A representitive example can be seen in Figure 39; it does not contain all of the data points I mentioned but it gives you a good idea as what to expect.

Figure 40
Figure 39.  COUNTLY_STORE.xml in Android.

This file is inconsistent.  On some of my extractions the file was empty after app use and on others it was full of data.  Sometimes the timestamps coincided with my being in the app, and others did not.  There does not seem to be enough consistency to definatively say the timestamps seen in this file are of any use to examiners.  If someone has found otherwise please let me know.

There is a iOS equivalent:  County.dat.  This file contains most of the same data points I already described, and while it has a .dat extension, it is a binary plist file.  In lieu of the adid (from Android), a deviceID is present in the form of a GUID.  I think this deviceID serves more than one purpose, but that is speculative on my part.

Speaking of iOS…

iOS is different. Of course it is.

The iOS version of Wickr behaves a little differently, probably due to how data is naturally stored on iOS devices.  The data is already encrypted, and is hard to access.  The two biggest differences, from a forensic standpoint, are the lack of decrypted versions of opened files, and the database is not encrypted.

Before I proceed any further, though, I do want to say thank you again to Mike Williamson for his help in understanding how the iOS app operates under the hood.  🙂

I searched high and low in my iOS extractions, and never found decrypted versions of files on my device.  So there are two possible explanations:  1, they are in a place I didn’t look (highly unlikely but not completely impossible), or 2, they are never created in the first place.  I’m leaning towards the latter.  Regardless, there are no decrypted files to discuss.

Which leaves just the database itself.  While it is not encrypted, a majority of the data writtent to the table cells is encrypted.  I will say I am aware of at least two mobile device forensic vendors, who shall not be named at this time, that will probably have support for Wickr on iOS in the near future.  In the meantime, though, we are left with little data to review.

The first table is ZWICKR_MESSAGE, and, as you can guess, it contains much of the same data as the Wickr_Message table in Android.  Remember when I mentioned the messageType value in Android?  In iOS that value is ZFULLTYPE.  See Figure 40.

Figure 38
Figure 40.  Type 6000.

The value of 6000 is seen here, and, as will be seen shortly, correspond to files that have been sent/received.  Also, note the Z_PK values 8 and 10, respectively, because they will be seen in another table.

Figure 41 shows some additional columns, the titles of which are self-explanatory.  One I do want to highlight, though, is the ZISVISIBLE column.  The two values in red boxes represent messages I deleted while within the Wickr UI.  There is a recall function in Wickr, but I was not able to test this out to see if this would also place a value of 0 in this column.

Figure 39.png
Figure 41.  Deleted message indicators.

Figure 42 shows another set of columns in the same table.  The columns ZCONVO and Z4_CONVO actually come from a different table within the database, ZSECEX_CONVO.  See Figures 42 and 43.

Figure 40.png
Figure 42.  Conversation and Calls.
Figure 41
Figure 43.  ZSECX_CONVO table.

In Figure 42 the two columns highlighted in the orange box, ZLASTCALLCONVO and Z4_LASTCALLCOVO, appear to keep track of calls made via Wickr; in my case these are audio calls.  Here, the value indicates the last call to take place, and what conversation it occured in.  This is interesting since the Android database did not appear to keep track of calls as far as I could tell (the data may have been encrypted).  Remember, this table is equivalent to the Wickr_ConvoUser table in the Android database, so you will be able to see the ZVGROUPID, shortly.

The next bit of the table involves identifying the message sender (ZUSERSENDER), the timestamp of the message (ZTIMESTAMP), the time the message will expire (ZCLEANUPTIME), and the message identifier (ZMESSAGEID).  The timestamps in this table are stored in Core Foundation Absolute Time (CFAbsolute).  See Figure 44.

Figure 42.png
Figure 44.  Messages and their times.

The values in the ZUSERSENDER column can be matched back to the Z_PK column in the ZSECX_USER table.

That’s it for this table!  The rest of the contents, including the ZBODY column, are encrypted.

The ZSECX_CONVO table has some notable data as seen in Figure 45.  The one column I do want to highlight is ZLASTTIMESTAMP, which is the time of the last activity (regardless of what it was) in the conversation (the “group”).  Interestingly, the times here are stored in Unix Epoch.

Figure 43.png
Figure 45.  Last time of activity in a conversation (group).

Figure 46 shows some additional data.  The last conversation in which a call was either placed or received is seen in the column ZLASTCALLMSG (orange box – timestamp can be gotten from the ZWICKR_MESSAGE table), along with the last person that either sent/received anything within the conversation  (ZLASTUSER – red box). The value in the ZLASTCALLMSG column can be matched back to the values in the Z_PK column in the ZWICKR_MESSAGE table.  The value in the ZLASTUSER column can be matched back to the Z_PK column in the ZSECX_USER table. And, finally, as I previously showed in Figure 24, the ZVGROUPID (blue box).

Figure 44
Figure 46.  The last of the ZSECX_CONVO table.

The table ZSECEX_USER, as seen in Figures 47 and 48, contains data about not only the account owner, but also about users who the account holder may be conversing with.  The table contains some of the same information as the Wickr_User table in Android.  In fact, Figure 47 looks very similar to Figure 27.  The values represent the same things as well.

Figure 47
Figure 47.  Hidden status and last activity time.

Figure 48 shows the same items as seen in Figure 26, but, as you can see, the hash values are different, which makes tracking conversation participants using this informaiton impossible.

Figure 48
Figure 48.  Same participants, different hashes.

File transfers in iOS are a bit tricky because some of the data is obfuscated, and in order to figure out which file is which an examiner needs to examine three tables:  Z_11MSG, ZWICKR_MESSAGE, and ZWICKR_FILE.  Figure 49 shows the Z_11MSG table.

Figure 49
Figure 49.  Z_11MSG.

The colum Z_13MSG refers to the ZWICKR_MESSAGE table, with the values 8 and 10 referring to values in the Z_PK column in that table.  See Figure 50.

Figure 50
Figure 50.  Trasferred files.

Obviously, associated timestamps are found in the same row further into the table.  See Figure 51.

Figure 51
Figure 51.  Timestamps for the transferred files.

The column Z_11Files in Figure 49 refers to the ZWICKR_FILE table.  See Figure 52.

Figure 52
Figure 52.  Files with their GUIDs.

The values in Z_11FILES column in Figure 49 refer the values in the Z_PK values seen in Figure 52.  Figure 53 shows the files within the file system.  As I previously mentioned, there are no decrypted versions of these files.

Figure 53
Figure 53.  The file GUIDs from the database table.

Figure 54 shows values ZANONYMOUSNOTIFICATION and ZAUTOUNLOCKMESSAGES values  from the ZSECEX_ACCOUNT table (the Android values were seen in Figure 32).  Both values here are zero meaning I had these features turned off.

Figure 54
Figure 54.  Anonymous Notification and Auto Unlock settings in iOS.

The last table I want to highlight is the ZSECX_APP table.  See Figure 55.

Figure 55
Figure 55.  Users and their associated app installations.

The values in the ZUSER column relate back to the values seen in the Z_PK column in the ZWICKR_USER table.  Each different value in the ZAPPIDHASH represents a different app install on a device.  For example, Test Account 1 appeared on four different devices (iPhone, iPad, Windows, macOS).  This means four different devices each with their own individual installation of Wickr, which translates to a different ZAPPIDHASH value for each individual device.  Knowing a user has multiple devices could be beneficial.  Warning:  be careful, because this isn’t the only way to interpret this data.

As part of the testing, I wanted to see if this value could change on a device, and, as it turns out, it can.  Test Account 2 was only logged in on the Pixel 3.  I installed the app, used it, pulled the data, wiped the Pixel and flashed it with a new install of Android, and then reinstalled Wickr.  I repeated those steps one more time, which means Wickr was installed on the same device three different times, and, as you can see, there are three different hash values for ZUSER 2 (Test Account 2).

The morale of this story is that while this value can possibly represent different devices where a user may be logged in, it actually represents instances of app installation, so be careful in your interpretation.


Wickr is a tough one.  This app presents all sorts of forensic challenges.  At the moment there is very little data that is recoverable, but some insights about communication and app usage can be gleaned from what little data is available.  Sometimes, files can be recovered, and that may be all an examiner/investigator needs.

The good news is, though, there is help on the horizon.

Ridin’ With Apple CarPlay

I have been picking on Google lately.  In fact, all of my blog posts thus far have focused on Google things.  Earlier this year I wrote a blog about Android Auto, Google’s solution for unifying telematic user interfaces (UIs), and in it I mentioned that I am a daily CarPlay driver.  So, in the interest of being fair, I thought I would pick on Apple for a bit and take a look under the hood of CarPlay, Apple’s foray into automotive telematics.

Worldwide, 62 different auto manufacturers make over 500 models that support CarPlay.  Additionally, 6 after-market radio manufacturers (think Pioneer, Kenwood, Clarion, etc.) support CarPlay.  In comparison, 41 auto manufacturers (again, over 500 models – this is an increase since my earlier post) and 19 after-market radio manufacturers support Android Auto.  CarPlay runs on iPhone 5 and later.  It has been a part of iOS since its arrival (in iOS 7.1), so there is no additional app to download (unlike Android Auto).  A driver simply plugs the phone into the car (or wirelessly pairs it if the car supports it) and drives off; a wired connection negates the need for a Bluetooth connection.  The toughest thing about CarPlay setup is deciding how to arrange the apps on the home screen.

In roughly 5 years’ time CarPlay support has grown from 3 to 62 different auto manufacturers.  I can remember shopping for my 2009 Honda (in 2012) and not seeing anything mentioned about hands-free options.  Nowadays, support for CarPlay is a feature item in a lot of car sales advertisements.  With more and more states enacting distracted driving legislation, I believe using these hands-free systems will eventually become mandatory.

Before we get started, let’s take a look at CarPlay’s history.

Looking in the Rearview Mirror

The concept of using an iOS device in a car goes back further than most people realize.  In 2010 BMW announced support for iPod Out, which allowed a driver to use their iPod via an infotainment console in select BMW & Mini models.

iPod Out-1
Figure 1.  iPod Out.  The great-grandparent of CarPlay.
iPod Out-2
Figure 2.  iPod Out (Playback).

The iPod connected to the car via the 30-pin to USB cable, and it would project a UI to the screen in the car.  iPod Out was baked in to iOS 4, so the iPhone 3G, 3GS, 4, and the 2nd and 3rd generation iPod Touches all supported it.  While BMW was the only manufacturer to support iPod Out, any auto manufacturer could have supported it; however, it just wasn’t widely advertised or adopted.

In 2012 Siri Eyes Free was announced at WWDC as part of iOS 6.  Siri Eyes Free would allow a user to summon Siri (then a year old in iOS) via buttons on a steering wheel and issue any command that one could normally issue to Siri.  This differed from iPod Out in that there was no need for a wired-connection.  The car and iOS device (probably a phone at this point) utilized Bluetooth to communicate.  The upside to Siri Eyes Free, beyond the obvious safety feature, was that it could work with any in-car system that could utilize the correct version of the Bluetooth Hands-Free Profile (HFP).  No infotainment center/screen was necessary since it did not need to project a UI.  A handful of auto manufacturers signed on, but widespread uptake was still absent.

At the 2013 WWDC Siri Eyes Free morphed in to iOS in the Car, which was part of iOS 7.  iOS in the Car can be thought of as the parent of CarPlay, and closely resembles what we have today.  There were, however, some aesthetic differences, which can be seen below.

Figure 3.  Apple’s Eddy Cue presenting iOS in the Car (Home screen).
Figure 4.  Phone call in iOS in the Car.
FIgure 5.  Music playback in iOS in the Car.
Screen Shot 2013-06-10 at 12.59.52 PM
Figure 6.  Getting directions.
Screen Shot 2013-06-10 at 2.09.12 PM
Figure 7.  Navigation in iOS in the Car.

iOS in the Car needed a wired connection to the vehicle, or so was the general thought at the time.  During the iOS 7 beta, switches were found indicating that iOS in the Car could, potentially, operate over a wireless connection, and there was even mention of it possibly leveraging AirPlay (more on that later in this post).  Unfortunately, iOS in the Car was not present when iOS 7 was initially released.

The following spring Apple presented CarPlay, and it was later released in iOS 7.1.  At launch there were three auto manufactures that supported it:  Ferrari, Mercedes-Benz, and Volvo.  Personally, I cannot afford cars from any of those companies, so I am glad more manufacturers have added support.

CarPlay has changed very little since its release.  iOS 9 brought wireless pairing capabilities to car models that could support it, iOS 10.3 added recently used apps to the upper left part of the screen, and iOS 12 opened up CarPlay to third party navigation applications (e.g. Google Maps and Waze).  Otherwise, CarPlay’s functionality has stayed the same.

With the history lesson now over, there are a couple of things to mention.  First, this research was conducted using my personal phone, an iPhone XS (model A1920) running iOS 12.2 (build 16E227).  So, while I do have data sets, I will not be posting them online as I did with the Android Auto data.  If you are interested in the test data, contact me through the blog site and we’ll talk.

Second, at least one of the files discussed (the cache file in the locationd path) is in a protected area of iPhone, so there are two ways you can get to it:  jailbreaking iPhone or using a “key” with a color intermediate between black and white. The Springboard and audio data should be present in an iTunes backup or in an extraction from your favorite mobile forensic tool.

Let’s have a look around.

Test Drive

I have been using CarPlay for the past two and a half years.  A majority of that time was with an after-market radio from Pioneer (installed in a 2009 Honda), and the last six months have been with a factory-installed display unit in a 2019 Nissan.  One thing I discovered is that there are some slight aesthetic differences in how each auto manufacturer/after-market radio manufacturer visually implements CarPlay, so your visual mileage may vary.  However, the functionality is the same across the board.  CarPlay works just like iPhone.

Figure 8 shows the home screen of CarPlay.

IMG_0769 2
Figure 8.  CarPlay’s home screen.

The home screen looks and operates just like iPhone, which was probably the idea.  Apple did not want users to have a large learning curve when trying to use CarPlay.  Each icon represents an app, and the apps are arranged in rows and columns.  Unlike iPhone, creating folders is not an option, so it is easy to have multiple home screens. The icons are large enough to where not much fine motor skill is necessary to press one, which means you probably won’t be hunting for or pressing the wrong app icon very often.

The button in the orange box is the home button.  It is persistent across the UI, and it works like the iPhone home button:  press it while anywhere and you are taken back to the home screen.  The area in the blue box indicates there are two home screens available, and the area in the red box shows the most recently used apps.

Most of the apps should be familiar to iPhone users, but there is one that is not seen on iPhone:  the Now Playing app.  This thing is not actually an app…it can be thought of more like a shortcut.  Pressing it will bring up whatever app currently has control of the virtual sound interface of CoreAudio (i.e. whatever app is currently playing or last played audio if that app is suspended in iPhone’s background).

Swiping left, shows my second home screen (Figure 9).  The area in the red box is the OEM app.  If I were to press it, I would exit the CarPlay UI and would return to Nissan Connect (Nissan’s telematic system); however, CarPlay is still running in the background.  The OEM app icon will change depending on the auto maker.  So, for example, if you were driving a Honda, this icon would be different.

IMG_0771 1.jpg
Figure 9.  The second batch of apps on the second home screen.

A user can arrange the apps any way they choose and there are two ways of doing this, both of which are like iPhone.  The first way is to press and hold an app on the car display unit, and then drag it to its desired location.  The second way is done from the screen seen in Figure 10.

Figure 10.  CarPlay settings screen.

The screen in Figure 10 can be found on iPhone by navigating to Settings > General > CarPlay and selecting the CarPlay unit (or units – you can have multiple)…mine is “NissanConnect.”  Moving apps arounds is the same here as it is on the display unit (instructions are present midway down the screen).  Apps that have a minus sign badge can be removed from the CarPlay home screen.  When an app is removed it is relegated to the area just below the CarPlay screen; in Figure 10 that area holds the MLB AtBat app, AudioBooks (iBooks), and WhatsApp.  If I wanted to add any relegated apps to the CarPlay home screen I could do so by pushing the plus sign badge.  Some apps cannot be relegated:  Phone, Messages, Maps, Now Playing, Music, and the OEM app.  Everything else can be relegated.

One thing to note here.  iOS considers the car to be a USB accessory, so CarPlay does have to abide by the USB Restricted Mode setting on iPhone (if enabled).  This is regardless of whether the Allow CarPlay While Locked toggle switch is set to the on position.

The following screenshots show music playback (Figure 11), navigation (Figure 12), and podcast playback (Figure 13).

Figure 11.  Music playback.
Figure 12.  Navigation in CarPlay.
Figure 13.  Podcast playback.

Messages in CarPlay is a stripped-down version of Messages on iPhone.  The app will display a list of conversations (see Figure 14), but it will not display text of the conversations (Apple obviously doesn’t want a driver reading while driving).  Instead, Siri is used for both reading and dictating messages.

Figure 14.  Messages conversation list.

Phone is seen in Figures 15; specifically, the Favorites tab.  The tabs at the top of the screens mirror those that are seen on the bottom in the Phone app on iPhone (Favorites, Recents, Contacts, Keypad, and Voicemail).  Those tabs look just like those seen in iPhone.

Figure 15.  Phone favorites.
Figure 16.  The keypad in Phone.

If I receive a phone call, I can answer it in two ways:  pressing the green accept button (seen in Figure 17) or pushing the telephone button on my steering wheel.  Answering the call changes the screen to the one seen in Figure 18.  Some of the items in Figure 18 look similar to those seen in iOS in the Car (Figure 4).

Figure 17.  An incoming call.
Figure 18.  An active phone call.

Most apps will appear like those pictured above, although, there may be some slight visual/functional differences depending on the app’s purpose, and, again, there may be some further visual differences depending on what car or after-market radio you are using.

Speaking of purpose, CarPlay is designed to do three things:  voice communication, audio playback, and navigation.  These things can be done fairly well through CarPlay, and done safely, which, I believe, is the main purpose.  Obviously, some popular apps, such as Twitter or Facebook, don’t work well in a car, so I don’t expect true social media apps to be in CarPlay any time soon if at all (I could be wrong).

Now that we have had a tour, let’s take a look under the hood and see what artifacts, if any, can be found.

Under the Hood

After snooping around in iOS for a bit I came to a realization that CarPlay is forensically similar to Android Auto:  it merely projects the apps that can work with it on to the car’s display unit, so the individual apps contain a majority of the user-generated data.  Also, like Android Auto, CarPlay does leave behind some artifacts that may be valuable to forensic examiners/investigators,  and, just like any other artifacts an examiner may find, these can be used in conjunction with other data sources to get a wholistic picture of a device.

One of the first artifacts that I found is the cache.plist file under locationd.  It can be found in the private > var > root > Library > Caches > locationd path.  cache.plist contains the times of last connect and last disconnect.  I did not expect to find connection times in the cache file of the location daemon, so this was a pleasant surprise.  See Figure 19.

Figure 19.  Last connect and last disconnect times.

There are actually three timestamps here, two of which I have identified.  The timestamp in the red box is the last time I connected to my car. It is stored in CF Absolute Time (aka Mac Absolute Time), which is the number of seconds since January 1, 2001 00:00:00 UTC.  The time, 576763615.86389804, converts to April 12, 2019 at 8:06:56 AM (EDT).  I had stopped at my favorite coffee shop on the way to work and when I hopped back in the car, I plugged in my iPhone and CarPlay initialized.  See Figure 20.

Figure 20.  Time of last connect.

The time stamp in the green box just under the string CarKit NissanConnect, is a bit deceptive.  It is the time I disconnected from my car.  Decoding it converts it to April 12, 2019 at 8:26:18 AM (EDT).  Here, I disconnected from my car, walked into work, and badged in at 8:27:14 AM (EDT).  See Figure 21.

Figure 21.  Time of last disconnect.

The time in the middle, 576764725.40157998, is just under a minute before the timestamp in the green box.  Based on my notes, it is the time I stopped playback on a podcast that I was listening to at the time I parked.  I also checked KnowledgeC.db (via DB Browser for SQLite) and found an entry in it for “Cached Locations,” with the GPS coordinates being where I parked in my employer’s parking lot.  Whether the middle timestamp represents the time the last action was taken in CarPlay is a good question and requires more testing.

The next file of interest here is the com.apple.carplay.plist file.  It can be found by navigating to the private > var > mobile > Library > Preferences path.  See Figure 22.

Figure 22.  carplay.plist

The area in the red box is of interest.  Here the name of the car that was paired is seen (NissanConnect) along with a GUID.  The fact that the term “pairings” (plural) is there along with a GUID leads me to believe that multiple cars can be paired with the same iPhone, but I wasn’t able to test this as I am the only person I know that has a CarPlay capable car.  Remember the GUID because it is seen again in discussing the next artifact.  For now, see Figure 23.

Figure 23.  Main CarPlay setting page in iOS.

Figure 23 shows the settings page just above the one seen in Figure 10.  I show this merely to show that my car is labeled “NissanConnect.”

The next file is 10310139-130B-44F2-A862-7095C7AAE059-CarDisplayIconState.plist.  It can be found in the private > var > mobile > Library > Springboard path.  The first part of the file name should look familiar…it is the GUID seen in the com.apple.carplay.plist file.  This file describes the layout of the home screen (or screens if you have more than one).  I found other files in the same path with the CarDisplayIconState string in their file names, but with different GUIDs, which causes me to further speculate that multiple CarPlay units can be synced with one iPhone.  See Figure 24.

Figure 24.  CarPlay Display Icon State.

The area in the red and blue boxes represent my home screens.  The top-level Item in the red box, Item 0, represents my first home screen, and the sub-item numbers represent the location of each icon on the first home screen.  See Figure 25 for the translation.

Figure 25.  Home screen # 1 layout.

The area in the blue box in Figure 24 represents my second home screen, and, again, the sub-item numbers represent the location of each icon on the screen.  See Figure 26 for the translation.

Figure 26.  Home screen # 2 layout.

The entry below the blue box in Figure 24 is labeled “metadata.”  Figure 27 shows it in an expanded format.

Figure 27.  Icon state “metadata.”

The areas in the green and purple boxes indicate that the OEM app icon is displayed, and that it is “Nissan” (seen in Figure 26).  The areas in the orange and blue boxes describe how the app icon layout should be (four columns and two rows).  The area in the red box is labeled “hiddenIcons,” and refers to the relegated apps previously seen in Figure 10.  As it turns out, the items numbers also describe their position.  See Figure 28.

Figure 28.  Hidden icon layout.

Notice that this file did not describe the location of the most recently used apps in CarPlay (the area in the upper left portion of the display screen).  That information is described in com.apple.springboard, which is found in the same path.  See Figure 29.

Figure 29.  Springboard and most recently used apps.

Just like the app icon layout previously discussed, the item numbers for each most recently used app translate to positions on the display screen.  See Figure 30 for the translation.

IMG_0769 1
Figure 30.  Most recently used apps positions.

The next file is the com.apple.celestial.plist, which is found in the private > var > mobile > Library > Preferences path.  This file had a bunch of data in it, but there are three values in this file that are relevant to CarPlay.  See Figure 31.

Figure 31.  Celestial.

The string in the green box represents what app had last played audio within CarPlay prior to iPhone being disconnected from the car.  The area in blue box is self-explanatory (I had stopped my podcast when I parked my car).  The item in the red box is interesting.  I had been playing a podcast when I parked the car and had stopped playback.  Before I disconnected my iPhone, I brought the Music app to the foreground, but did not have it play any music, thus it never took control of the virtual sound interface in CoreAudio. By doing this, the string in the red box was generated.  Just to confirm this, I tested this scenario a second time, but did not bring the Music app to the foreground; the value nowPlayingAppDisplayIDUponCarPlayDisconnect was not present in the second plist file.  I am sure this key has some operational value, although I am not sure what that value is.  If anyone has any idea, please let me know.

As I mentioned earlier in this post, Siri does a lot of the heavy lifting in CarPlay because Apple doesn’t want you messing with your phone while you’re driving.  So, I decided to look for anything Siri-related, and I did find one thing…although I will say that this  is probably not exclusive to CarPlay.  I think this may be present regardless of whether it occurs in CarPlay or not (more testing).  In the path private > var > mobile > Library > Assistant there is a plist file named PreviousConversation (there is no file extension but the file header indicates it is a bplist).  Let me provide some context.

When I pick up my child from daycare in the afternoons, I will ask Siri to send a message, via CarPlay, to my spouse indicating that my child and I are on the way home, and she usually acknowledges.  The afternoon before I extracted the data from my iPhone (04/11/2019), I had done just that, and, after a delay, my spouse had replied “Ok.”

PreviousConversation contains the last conversation I had with Siri during this session. When I received the message, I hit the notification I received at the top of the CarPlay screen, which triggered Siri.  The session went as so:

Siri:                 “[Spouse’s name] said Ok.  Would you like to reply?”

Me:                  “No.”

Siri:                 “Ok.”

See Figure 32.

FIgure 32.  Session with Siri.

The area in the red box is the name of the sender, in this case, my spouse’s (redacted) name.  The orange box was spoken by Siri, and the blue box is the actual iMessage I received from my spouse.  The purple box is what was read to me, minus the actual iMessage.  Siri’s inquiry (about my desire to reply) is seen in Figure 33.

Figure 33.  Would you like to reply?

Figure 34 contains the values of the message sender (my spouse).  Inside of the red box the field “data” contains the iMessage identifier…in this case, my spouse’s phone number.  The field “displayText” is my spouse’s name (presumably pulled from my Contact’s list).  Figure 35 has the message recipient information:  me.

Figure 34.  Message sender.
Figure 35.  Message recipient (me) plus timestamp.

Figure 35 also has the timestamp of when the message was received (orange box), along with my spouse’s chat identifier (blue box).

Figure 36.  Siri’s response.

Figure 36 shows Siri’s last response to me before the session ended.

Interesting note:  this plist file had other interesting data in it.  One thing that I noticed is that each possible response to the inquiry “Would you like to reply?” had an entry in here:  “Call” (the message sender), “Yes” (I’d like to reply), and “No” (I would not like to reply).  It might be a good research project for someone.  🙂

The next artifact actually comes from a file previously discussed:  com.apple.celestial.plist.  While examining this file I found something interesting that bears mentioning in this post.  My iPhone has never been paired via Bluetooth with my 2019 Nissan.  When I purchased the car, I immediately started using CarPlay, so there has been no need to use Bluetooth (other than testing Android Auto).  Under the endointTypeInfo key I found the area seen in Figure 37.

Figure 37.  What is this doing here?

The keys in the red box contain the Bluetooth MAC address for my car.  I double-checked my Bluetooth settings on the phone and the car, and the car Bluetooth radio was turned off, but the phone’s radio was on (due to my AppleWatch).  So, how does my iPhone have the Bluetooth MAC address for my car?  I do have a theory, so stay with me for just a second.  See Figure 38.

Figure 38.  AirPlay indicator.

Figure 38 shows the home screen of my iPhone while CarPlay is running.  Notice that the AirPlay/Bluetooth indicator is enabled (red box).  Based on some great reverse engineering, it was found that any device that uses the AirPlay service will use its MAC address in order to identify itself (deviceid).  Now, see Figure 39.

Figure 39. Virtual Audio Interfaces for AirPlay and CarPlay.

Figure 39 shows two files, both of which are in the Library > Audio > Plugins > HAL path.  The file on the left is the info.plist file for the Halogen driver (the virtual audio interface) for AirPlay and the file on the right is the info.plist file for the Halogen driver for CarPlay.  The plug-in identifiers for each (both starting with EEA5773D) are the same.  My theory is that CarPlay may be utilizing AirPlay protocols in order to function, at least for audio.  I know this is a stretch as those of us that use AirPlay know that it typically is done over a wireless connection, but I think there is a small argument to be made here.  Obviously, this requires more research and testing, and it is beyond the scope of this post.


CarPlay is Apple’s attempt at (safely) getting into your car.  It provides a singular screen experience between iPhone and the car, and it encourages safe driving.  While a majority of the user-generated artifacts are kept by the individual apps that are used, there are artifacts specific to CarPlay that are left behind.  The app icon layout, time last connected and disconnected, and last used app can all be found in these artifacts.  There are also some ancillary artifacts that may also be useful to examiners/investigators.

It has been a long time since I really dug around in iOS, and I saw a lot of interesting things that I think would be great to research, so I may be picking on Apple again in the near future.