Evernote for iOS

Overview

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 (https://evernote.com/privacy) 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:

iOS-Backup/Documents/Logs

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:

iOS-backup/Documents/pending/3*2*9*1-personal-www.evernote.com/LocalNoteStore.sqlite

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'
from ZENNOTE

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.

Evernote-localnotestore

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

Overview

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: https://accounts.snapchat.com/accounts/downloadmydata
  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…

#Instagood

com.burbn.instagram.plist

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.

#Earworms

ShazamDataModel.sqlite

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…

screen-shot-2018-05-12-at-12-42-16-pm-e1526093015189.png

#SIMS

CellularUsage.db

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.

screen-shot-2018-05-12-at-11-58-54-am.png

Last Known ICCID and telephone number can also be seen in the com.apple.commcenter.plist file.

#locationlocationlocation

CallHistory.Storedata

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.

screen-shot-2018-05-12-at-10-49-23-pm.png

#layouts

iconstate.plist

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.

iconstate

iconstate2

#podcasts

MTLibrary.sqlite

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

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

Installation

Installing Homebrew is pretty trivial and instructions for this can be seen on the Homebrew site: https://brew.sh/

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

 

Extraction

Running the ideviceinfo command initially shows the following output:

ideviceinfo

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.

iTunes

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

screen-shot-2018-05-09-at-9-58-47-pm-e1525867202811.png

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.

Reference:

http://www.libimobiledevice.org/

https://brew.sh/

https://www.zdziarski.com/blog/

https://graykey.grayshift.com/