iOS 13 – Swipe to Type

iOS 13 has brought along a lot of interesting new features and one of these which i’ve started using is Swipe to Type. I’ve been quite impressed by the accuracy.

This functionality has long been around for a long time in third party apps and has been a native function in Android (I think) for some time.

What does the native iOS version look like under the hood?

Swipe to Type – Files of interestingness


This database contains much the same content as you’d expect to see in the dynamic-text.dat dictionary file. The only apparent useful table is called shapes and this stores the swiped word as string_representation, there is also a blob entry for shape_data which presumably stores data relating to gesture tracking accuracy, however this is just an assumption.


This database appears to be the real interesting one. There are a few tables in this database but the ones we would be interested in are:

  • usermodeldurablerecords 
  • usermodeltransientrecords


This table seems pretty basic, it shows a total number or typed words and the number of words pathed, presumably this second value relates the number of words created through the Type to Swipe feature.

Screen Shot 2019-09-23 at 12.46.43 pm


This table has a number of fields or keys relating to user activity on the keyboard:

  • tium.wordsTyped
  • tium.pathEligibleWordsTapped
  • tium.durationTappedWords
  • tium.wholeWordDeleted

I have not figured out which each of these relate to as yet, although some will be quite obvious, and as you can see there are last update timestamps.

Screen Shot 2019-09-23 at 1.52.25 pm

When paired with messaging activity in the SMS.db, web browsing or other application data, this will make good evidence for identifying when a user was actually interacting with their device.

Further work is required but this is a nice new artefact which can be in the investigators toolkit for finding evidence of hands-on device usage.

Evernote for iOS


New iOS applications are always coming up in our forensic examinations. I’ve found that commercial tools we commonly use to acquire and analyse data from mobile devices are not able to parse the majority of third party apps. This is an inherent issue with the app update cycle. We can’t really blame those commercial products or developers, they really are fighting a futile battle.

So for this piece of testing, I used some open source tools to acquire a backup of my iPhone 7 running iOS 12.1.  I’ve been using Evernote for a number of years but oddly have never really come across it during the course of an investigation.

More recently I have been using the Evernote application on my phone to access shared teaching notebooks created by course instructors and discovered some really interesting artefacts relating to logging and locations.

I won’t go into too much of the information you can acquire from the Evernote plist and database files stored by the application, but here are some of what I consider to be some more interesting findings:

Application Logging

Evernote retains a number of logs relating to application usage on iOS and these logs contain a statement about their intended purpose, which is rather handy:

“The Activity Log contains a detailed list of the steps the Evernote application performs, as well as information about your account, your device and location information (if enabled). Your Note titles, tags, Notebook names and occasionally Note content also may be included. We treat your Activity Log data as confidential, and the terms of our Privacy Policy ( apply.If sending your log to Evernote, you may want to email the file to yourself and edit out any sensitive information first.”

Based on this statement alone, it’s clear to me as a bit of a log monkey that I’m going to be drawn to these.

The logs are stored in the following location in iOS:


As you will see from the log names below, they follow a standard naming convention and a quick look at the file names shows us some useful timeline information. I haven’t used the app particularly often but the dates in the table below, specifically relate to the days in which I was attending the teaching events I previously mentioned.

com.evernote.iPhone.Evernote 2018-04-21--21-39-27-026.log

com.evernote.iPhone.Evernote 2018-05-04--02-28-25-844.log

com.evernote.iPhone.Evernote 2018-05-09--01-59-14-135.log

com.evernote.iPhone.Evernote 2018-05-17--07-12-09-464.log

com.evernote.iPhone.Evernote 2018-07-21--03-38-13-286.log

com.evernote.iPhone.Evernote 2018-08-23--07-51-43-715.log

com.evernote.iPhone.Evernote 2018-11-07--10-17-36-152.log

A simple cat command across these files will allow us to aggregate them for bulk searching:

cat /logs/*.log > /new-logs/All-evernotelogs.log

Some useful information we can gather from these logs includes:

  • Evernote username
  • Hardware (iPhone Model) and iOS version at the time when the log was created
  • Carrier in use when the log was created
  • Note titles

There are many timestamps stored in these logs and clearly a fountain of information relating to application functions, user activity and previous devices which may have been used by the subject.

There were a number of entries which I found interesting and these lines contained the text “Preview updated“. In most occurrences, there were note titles appearing but some of the entries appeared to be error entries.

Screen Shot 2018-11-28 at 10.54.26 pm

As you can see there’s some repetition here, which is why I believe these log entries directly relate to the previewing of the note that is shown to the user on-screen when the application is launched. This would be useful in proving knowledge of notes or device usage at a specific time.


Geo-locating third parties via Database files

So, when I set out on this journey I expected we might find that there are some databases containing notes and other things like usage history and content. What I didn’t expect to find was very specific information relating to the movements of the individuals who have shared their notebooks publicly.

I pulled the following database out to examine:


This database contains a pure mountain of Evernote goodness, which may be of forensic interest:

  • Timestamps: note created, deleted, last viewed, last updated and date shared
  • Note Author: Often this is the email address used to register the Evernote account
  • Last Evernote user to edit a note: As above
  • Note Title
  • Note URL
  • Latitude, Longitude and Altitude for the note creation: If location services are enabled when the note is created
  • Source application: iPhone, web browser or Mac (These were the methods I tested, there may be others for Android)

I wrote a quick SQL query to parse out some of the relevant information from the ‘ZENNOTE‘ table which contained all of the relevant note information:

Select DateTime(ZDATECREATED + 978307200, 'unixepoch') as 'Date Created (UTC)',
DateTime(ZDATEDELETED + 978307200, 'unixepoch') as 'Date Deleted (UTC)',
DateTime(ZDATELASTVIEWED + 978307200, 'unixepoch') as 'Date Last Viewed (UTC)'
DateTime(ZDATEUPDATED + 978307200, 'unixepoch') as 'Date Updated (UTC)',
ZAUTHOR as 'Note Author', ZTITLE as 'Note Title', 
ZSOURCEURL as 'Note URL', ZLATITUDE as 'Latitiude', 
ZLONGITUDE as 'Longitude', ZSOURCE as 'Source', 
ZSOURCEAPPLICATION as 'Source Application'

As you will see from the query above and some sample results below, we can determine many timestamps related to specific notes. We can also see the application used to create the note, either mobile or desktop (Source), the author’s name (Note Author), the source URL for the note and most importantly the Geo-location information.


The Evernote shared notebook I identified most of the valuable information was shared by the instructor (Note Author) of a teaching event I attended. This seemed like the most useful for review.

The first thing I did was take a look at one of the locations which featured in the shared notebook and punched the coordinates into google maps to see what was going on.

Screen Shot 2018-11-28 at 11.17.23 pm.png

It looks like the Note Author may have spent some time at the Dupont Circle Hotel in Washington back in 2016. It appears from the geo-location information that the hotel was actually mobile at this point and positioned on top of this young man’s melon.

I looked closer at the extracted database entries and quickly identified a number of locations where notes were created or added to the Note Author’s notebook by filtering on the Note Author column. There were a number of entries with locations associated. These ranged from Singapore and London to multiple spots across the United States.

Most of these locations appeared to be hotels, although a residential address appeared a number of times too, which I suspect was the Note Author’s home address.

It should be noted that most of this geo-location information appears to have been added by using the Evernote desktop application rather than the mobile application, although both allow locations to be added to notes. Enabling of location services and sharing of notebooks requires specific user interaction at the time of installation and shared notebook creation.

Why is this information interesting?

  • Many different users can add to shared, publicly accessible notebooks
  • We can track their activity over time through our own iOS device and EverNote account

What can we deduce?

  • Associated email addresses to device/app users (Note Author)
  • Other contacts with an individual (Last Edited By)
  • Activity relating to the application usage and specific notes (Note Title, Date Created, Date Deleted etc)
  • Location information over time (Lat, Long, Alt)
  • Devices used by specific individuals (Source)

How could this be abused?

  • Nefarious actors attempting to find information about an individual or many individuals, may find ways to scrape URL’s for publicly accessible Evernote Notebooks. This may allow them to leverage this information to gain knowledge of movements, locations such as homes for theft etc.
  • Once these Notebooks are subscribed to using an account on the iOS device that the nefarious actor is using, it would be trivial to dump the LocalNoteStore.sqlite file and find out all of this information, including work and business addresses.

Thanks for reading,

Update: Rather than publishing these findings at the end of 2018, I approached Evernote who have since disabled the sharing of note locations in public notebooks. Evernote were kind enough to feature me on their 2019 Security list of contributors.

(Not Quite) Snapchat Forensics


For those of us who don’t have access to those GrayKey boxes or Cellebrite services to acquire physical images of devices, we are generally reliant upon logical extractions of iOS due to legal limitations or similar. After a recent enquiry relating to snapchat data and what was held on a device, I later found out that Snapchat have a download your data service much like Google Takeout.

I had a look into what data is held online and accessible by the user with their basic login. As it happens, as long as you have permission to access the account online, there’s quite a wealth of metadata available.

Points of Interest from an investigative standpoint

I’ve summarised some of the main points I think are interesting. The majority of these I believe would be more useful in criminal matters such as harassment, stalking, sexual abuse or missing person cases but are certainly interesting when considering the lack of available information from the device.

  • Contains Account Creation dates, devices used with the account
    • Useful if there is a dispute over dates of communication and whether there are further devices involved
  • Snap and chat history (no content and goes back at least as far as 1 month back)
    • Shows communication between specific individuals
  • Lists of friends, friend requests sent, friends blocked, friends deleted  (no timestamps)
    • Any of these could be useful in identifying attempted communication or attempted ceasing communication with an individual.
  • Search history (Including search term and Lat, Long coordinates from where those searches were performed)
    • Could indicate some form intent if searching for a specific individual
  • Frequent locations, locations you have visited and Latest location

To download your Snapchat data

  1. Login using account credentials and browse to:
  2. Once you’re in, scroll to the bottom of the page and hit ‘Submit Request’
  3. Wait…
  4. You should receive an email to the account used to set up the Snapchat account containing a hyperlink to the download page.
  5. Alternatively, if you log back in the zip file will be available on the /downloadmydata page.

Once you download the data, it’ll be much like the format of a google takeout download, html and JSON.

and that’s it…

If you’re in a bit of a pickle and lacking device data, downloading account data directly from Snapchat may be a second best alternative.

A Few Interesting iOS Forensic Artefacts

As of 2017, there were over 2.8 Million apps available on the Apple app store and close to that number on the Google play store. This is an uncanny number of applications, most of which are unlikely to ever be parsed and decoded by existing forensic tools.

How do we fill that gap?

As I’m sure we are all aware, common mobile forensic tools tend to parse applications pretty well but as with any forensic tool, these should always be validated. Tools are from time to time known to get things wrong or miss things.

At the start of our case, in order to not get bogged down, we should carefully consider the questions we aim to answer. Also, if the method of dumping a handset and relying on decoded data from our tool is going to answer these questions.

I thought I would try to identify some artefacts which exist in common apps which might help answer some attribution questions an analyst may be faced with.

The age-old question of ‘putting bums on seats’ or in our instance, ‘hands on the mobile device’ is often the aim for prosecution cases. Digging through some common application plist and database files should hopefully help show some of this type of activity.

Let’s take a look…



Screen Shot 2018-05-10 at 9.47.08 am

As you can see we have a timestamp which shows the Instagram swipe down or page reload function.

Great for proving your kids were on Instagram when they said they were asleep.



Shazam provides users with the ability to identify music while on the go, great for those wriggly little earworms. Although, what you may not know is that Shazam is recording your location and times every time you Shazam a track. The format of this database table doesn’t appear to have changed over the last two years.

Highly useful for showing user interaction and bad taste in music…




Apple does quite a good job of preserving the list of SIM card ICCID’s which have been present in an iPhone and sometimes you may also see the phone number (MSISDN) which has been saved on that SIM card. This varies between providers and may not always be present.

The field storing the phone number (MSISDN) on a SIM is editable so not 100% reliable, although I have never seen it being modified in recent years.


Last Known ICCID and telephone number can also be seen in the file.



Perhaps not all that useful for cases where your device has always been in the same country but if you’re investigating someone who tends to travel, it would be nice to know where they were when they calls were made. Again, with a simple SQL query, you can pull out this information.




If you are interested in identifying how the UI looked then you will notice that you can identify the custom strings, including emojis as headers for the groups of app icons on iOS. In our iconstate.plist file these can be read from left to right, top to bottom to visualise the layout of the apps and second panes of apps are nested in another array, as can be seen in the example below.





According to FastCompany “In March 2018, Apple Podcasts passed 50 billion all-time episode downloads and streams.” Thankfully for us, Podcast episodes are all tracked in a database stored on the iPhone and there’s useful information in here about when the podcast was downloaded to the device and also when it was last played.

Showing when a podcast was last played could go some way to corroborating whether or not someone was listening to their headphones when they should have been listening to their college lecturer.

Screen Shot 2018-05-14 at 2.53.21 pm

If you don’t listen to the Wired UK Podcasts, then it’s definitely worth a pop.

Hopefully, this quick write up on some iOS artefacts will help someone out. I believe these may be of some assistance along the way to attributing usage and location of devices at very specific times. I’m sure the commercial tools out there already extract some of this information but an analyst should be able to parse this information themselves.  Identifying app data that a tool may have missed and ensuring your evidence is verified as accurate should be paramount.

Budget iOS Device Extraction

Back in the early days of iOS extraction, the Zdziarski Method was the goto for acquiring a forensic image of an iPhone. This was quickly adopted by many of the main products and for a short period, all was well with the world of Apple device forensics, until Apple applied hardware encryption.

This has since left analysts with the options of varying levels of logical acquisition and decoding provided by the main vendor’s products, provided you have the passcode/backup password for the device. Obviously, there have been recent advances with offers to LE from main vendors to bypass passcodes and the new Grayshift black boxes on offer.

A large portion of the information which we as analysts want to parse and analyse does tend to sit in many of the logical areas accessible by these tools and some of the extraction methods are essentially just iTunes backups.

So what if we could extract iTunes backups using some open source tools using just our Mac or Linux box?

Enter Homebrew and the libimobiledevice tools.


Homebrew is a package manager for macOS which allows you to run Linux tools natively on the mac.


Installing Homebrew is pretty trivial and instructions for this can be seen on the Homebrew site:

Once Homebrew is installed, we need to then add the libimobiledevice cask.

This can be done by running the command to install:

brew install libimobiledevice



Running the ideviceinfo command initially shows the following output:


We will be required by iTunes to unlock the iPhone with the users passcode and then selecting trust on the handset, and entering the passcode a second time.


iPhone Trust

Once we have trust between the iPhone and Computer we can then continue to query the device.

With the ideviceinfo tool, we can establish some basic information about the device.

BluetoothAddress: 8x:xe:x2:xa:1x:xa
EthernetAddress: xc:8x:x2:xa:x6:ax
FirmwareVersion: iBoot-4076.50.126
IntegratedCircuitCardIdentity: 8961xx46xxxxxxxxx9
InternationalMobileEquipmentIdentity: 358xxxxxxxx66
InternationalMobileSubscriberIdentity: 50502xxxxxxxx6
MobileEquipmentIdentifier: 35xx71xx553xx6
PhoneNumber: +61 000 000 000
ProductName: iPhone OS
ProductType: iPhone8,1
ProductVersion: 11.3.1
TimeZone: Australia/Sydney
WiFiAddress: 8c:8e:xx:4a:16:xx

For analysts who have worked in units or departments where they have the authority to perform subscriber checks, you will spot some important information here which can be used and go a long way to attribution. You will also notice that there is information here which can be used to identify the device on wireless networks.

I will generally send the output from this command to a text file to accompany the backup. As you can see there are a number of options including one to dump a list of files to CSV, unpack the backup and also to disable backup encryption (you will need to feed it the backup password to do this).

Screen Shot 2018-05-11 at 9.44.34 am

We can perform an iTunes backup from Terminal using the following command:

idevicebackup2 backup /pathtobackup

Screen Shot 2018-05-09 at 9.50.49 pm

Screen Shot 2018-05-09 at 9.51.23 pm


Once it completes, we are free to start interrogating our backup using other tools whether that be a product from one of the main vendors, other open source tools or some of the cheaper products which fall somewhere in-between. Please note that the iTunes backup password will be required to decode the contents of the backup.