Many modules were updated to specially support iOS 12 including those below. Many were already available on iOS 12 (Powerlog, Passes, SMS, etc). If the files are were available without a jailbreak. As always, let me know if I missed something! Remember the ‘yolo’ option can always be used to attempt to get those entries if official support in the module has not been added.
Routined - Looks like Apple changed the database schema to change/remove much of the location reverse geolocation protobuf BLOBs that were in the Cache.sqlite, Local.sqlite, Cloud.sqlite databases. Queries have been updated to account for this.
Still working on a few other queries like Screen Time as well as a few more programatic updates.
Just got back from a wonderful time hanging out with the who’s who of Mac security folk in swanky Monaco at the Objective by the Sea conference. I’ve uploaded my presentation Watching the Watchers in my Resources section. This presentation goes through some of the forensically useful artifacts of the following 3rd party monitoring software:
I cannot recommend enough that the OBTS conference is absolutely worth going to if you are at all involved in Apple Security. Next one is ~Q1 2020 and back in Maui!
I had the pleasure last week to attend MacDevOpsYVR in Vancouver, Canada. While I barely saw the city, I got to hang out with some awesome Mac Sys Admins and Dev Ops people. I’ve not been to a conference outside of Security/Forensics before so it was a delight to see the types of presentations and insight these fine folks had to offer.
The presentation includes how my APOLLO project has evolved over the last few months since it was introduced in November, 2018. I also go though some of my real life pattern-of-life examples from my iOS 12 device. We talked about everything including to my health, moving bodes (and chopping them up!), taking selfies, and how much I will spend for good food. Once the video is released I will be sure to upload a link to it, it will certainly provide more (humourous) context to the slides.
A unique addition to normal conference presentations was the use of a graphic recorder (Ashton of Mind’s Eye Creative) to provide additional context to the presentations. She records in real time key points of each presentation and does an absolutely fantastic job at it. This allows for additional context for discussions after the presentation with fellow attendees. Example of my talk is below:
Image may be NSFW. Clik here to view.
As always, my presentations are always available on my Resources page.
Always a good time and love seeing friends every year. Still one of my favorite conferences! It was a nice surprise winning a couple of Forensic 4cast awards too! Thank for your votes! ☺️
I added preliminary KMZ (zipped KML) support to APOLLO. If any APOLLO module’s SQL query has “Location” in its Activity field, it will extract the location coordinates in the column “Coordinates” as long as they are in Latitude, Longitude format (ie: 38, -77). These are more a less an upgrade/replacement from my previous iOS location scripts. (FYI: Those will not likely be updated further.)
You can find more details on the different modules and outputs here. The APOLLO output will also show counts of how many location data points were extracted from each module. An example from my own data contained 41,262 points! Due to the amount of data points and how applications like Google Earth might handle them I’ve decided to split them by module to be loaded separately. It’s not ideal, but my goal is not to crash Google Earth. (FWIW, I’m still working on other solutions, if you have experience in this area - drop me a line.) The most troublesome module (by a large magnitude) is routined_cache_zrtcllocationmo since it keeps track of extremely granular locations for about the last week. Mine had ~38,000 coordinates!
Let’s take a look at some examples! This data was collected on 07/18/2019 on iOS 12.1.1 to give you an idea on timeframe.
These are some of my “Significant Locations”, you can click on any coordinate and gather more detail. This is the same output that is captured in the APOLLO database or CSV file.
Image may be NSFW. Clik here to view.
The next example is from routined_local_learned_location_of_interest_entry. Here you can see some of my travels since 2017! These contain the “Learned Locations of Interest”. You will probably see a bit more historical location data. Looks like I need to visit the middle of the US more!
Image may be NSFW. Clik here to view.
Last but not least is the massive amount of data points from the routined_cache_zrtcllocationm module. This will show nearly exact, granular location for about the last week before collection. Here is my trip to Portland, OR for DFRWS! Not many guesses as to how I got to download Portland from the airport is there! (This is the module that produces many, many datapoint. It took patience with Google Earth to even get this screenshot, this is your warning.)
Image may be NSFW. Clik here to view.
I hope this adds a bit of visual context to some of the APOLLO output, let me know if you have different ideas on how to represent some of this data! Pictures can certainly tell a story where it might otherwise get lost in the noise.
My previous article showed a new capability of APOLLO with KMZ location file support. It worked great…for routined data, but there was something missing. What about the cellular and Wi-Fi locations that are stored in databases? Well, turns out I need to test better. I fixed the locationd modules to have the activity as “Location” versus “LOCATION”. Case sensitivity is apparently thing in Python…my bad. 🤷🏻♀️😉
I should also mention with the fixes, my total location data points for a iOS 12.1.1 device jumped to ~57,000! I should note this is not inclusive of workout locations. Those are a bit different as they are stored as separate records, one for latitude and one for longitude. In the future I might attempt to pair these up for KMZ support.
The previous article showed the routined (user/device patterns) data, I have found these locations to be quite accurate. To be fair, I have not looked at all (40k+) of them specifically, only spot checked. When I visualized the locationd data, I saw some interesting outliers.
The first module I found particularly interesting is the output from the locationd_cacheencryptedAB_celllocation module. Most of the locationd output is kept for about a week. This particular week I traveled from DC to Portland via Chicago for DFRWS and then back to DC (again via Chicago). You will notice that there are some data point clusters around DC, Chicago and Portland as expected – but there are a few scattered data points in the Midwest. I do not remember for sure if my device was in Airplane Mode, but this may be an artifact of potentially being able to access cell towers during my flight. (The locationd_cacheencryptedAB_ltecelllocation module output showed a similar pattern.)
Image may be NSFW. Clik here to view.
The next module, locationd_cacheencryptedAB_ltecelllocationlocal, shows my path home from fairly accurately. These locations tend to be kept for less time. I was going north on 95, past the DC Beltway (near Springfield, VA) and onto Glebe Road towards Arlington, VA. It may be hard to see in the screenshot but the airport to the right near the Potomac is DCA. Just north of that is the Pentagon and Arlington Cemetery.
Image may be NSFW. Clik here to view.
Finally, we have the output from the locationd_cacheencryptedAB_wifilocation module. This one has a few more outliers that I have a hard time explaining. I was DC and Chicago in this screenshot but not in Buffalo (NY), Pennsylvania, or NYC.
Image may be NSFW. Clik here to view.
These are good examples of not completely believing and relying on what you see in the data. I can only imagine forensics cases relying heavily on this data. While I have found routined data points to be far more accurate, locationd on the other hand does have its oddities. Perhaps it is something with how the data is populated or the coordinates being reported by cell towers and/or access points. This requires additional investigation. TL;DR – Don’t assume what you are looking at is the end all be all of the data – always investigate further and correlate with other information.
In other news, if anyone knows more about how this data is populated – I’d love to know. Drop me a note!
I was first introduced to the protobuf data format years ago accidentally when I was doing some MITM network analysis from an Android device. The data I was looking at was being transferred in this odd format, I could tell there were some known strings and some patterns to it - but I did not recognize the format. It had no magic number or file header. I started looking at it more in depth, it did have a structure. I spent an embarrassingly amount of time trying to reverse engineer this structure before I realized it was in fact a protobuf data blob. I think it was a moment of frustration in reversing this structure that lead me to searching something like “weird data format Android network traffic” that finally lead me to protobufs.
Image may be NSFW. Clik here to view.
Ok, so what the heck is a protobuf? It actually stands for Protocol Buffer, but everyone calls them protobufs. It is a “language-neutral, platform-neutral extensible mechanism for serializing structured data” created by Google. It is a super-efficient way of storing and transferring data.
Since I was looking at an Android device, a protobuf made perfect sense. This was a Google thing afterall. I started noticing them more and more on Android devices, not just in the network traffic but also storing data on disk as well. It took me a long time to also notice that they were being stored on Apple devices! Native applications, 3rdparty applications, they are used EVERYWHERE! A great example was found by my friend Phill Moore in the iOS Spotify application to keep track of items listened to.
In this article I’ll introduce you to some of the Apple-specific protobufs that I’ve come across. Some are fairly straight forward, others are less so. The kicker with protobufs is that there is an accompanying *.proto file that contains the definition to what is contained in these buffers. Unfortunately, we likely do not have this file as it is most likely server-side or inaccessible therefore we need to reverse engineer the contents and meaning of the items stored in this blob.
To parse these protobufs, I use protoc from Google to get a raw output. If you have the .proto file you can use this as well, but I have yet to give that a go. On a Mac, I would do a ‘brew install protobuf’ to get protoc installed. To parse a given buffer I will use the following command:
protoc --decode_raw < [protobuf_blob_file]
I will parse out some protobufs from different applications to give you an idea of what is stored in them - Maps, Locations, Health, and Notes.
Maps Data
The Maps application on both macOS and iOS use many protobufs to store location data. These can be found in quite a few different Maps related plist files. I will focus on GeoHistory.mapsdata plist file from iOS which stores historical locations that were mapped. This plist has GUID keys that contain a “contents” subkey. This “contents” blob contains the protobuf of the mapped location. I chose a small example to begin with as some of these can be very large.
Image may be NSFW. Clik here to view.
I’ve extracted this blob and put into a hex editor. You can see some visible strings in this blob but really no context. This is where parsing with protoc can be helpful.
Image may be NSFW. Clik here to view.
I saved this protobuf to a file I named geohistory.pb. Using protoc I decoded it to the output below. I can see the same GUID and location name but now I get some other hex based values. This is where you will have to determine what these values mean and what they are used for, it may not be obvious initially.
Image may be NSFW. Clik here to view.
At this time, I believe the highlighted pairs of hex in the screenshot above are coordinates. To read these, I copy them into a hex editor to read their values highlighted below. On the left is latitude, on the right is longitude. Plotting these two pairs above I get one location in Manassas, VA and another in Bethesda, MD. Clearly, neither of these are in Fairfax, VA. This is the tricky part, what do these values mean? More testing needs to be done here.
Image may be NSFW. Clik here to view.
Location Data
The next example shows a protobuf blob being stored inside of a SQLite database. The example below is from the Local.sqlite routine locations database from iOS 11. (In iOS 12, the same data exists but has been placed into separate columns – which IMHO, is far easier to interpret.) The ZRTLEARNEDLOCATIONOFINTERESTMO table contains “learned” locations of interest or significant locations. This example is Heathrow Airport. Two columns contain protobuf data - ZPLACEMAPITEMGEOMAPITEMHANDLE (highlighted), and ZPLACEMAPITEMGEOMAPITEM. To decode these with protoc, I will need to extract them to separate files. In DB Browser for SQLite, I can use the export feature.
Taking the highlighted hex coordinates and plotting them using Google Maps, they make more sense than the ones highlighted above. These coordinates are right at Heathrow Airport in London.
Image may be NSFW. Clik here to view.
Health Data
Protobufs are not just used for location data, but also for other data storage such as split times when I have a running or walking workout. The healthdb_secure.sqlite database on iOS contains this information. Shown below is the “workout_events” table. I have selected the BLOB data for one “event” or one split time (a workout may consist of multiple split times for multiple associated “events”).
Image may be NSFW. Clik here to view.
I exported and decoded with protoc using the same methods described above. The example below is from a walk I took in Monaco. Presumably the labels “s” is for seconds and “m” is for meters, however I’m still verifying this assumption.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
Notes Data
One last example brings us to the Notes application. Anyone who has looked into this database likely knows that it is a complicated one. I created a sample note to show how it may look in the protobuf produced. This note has some text, a link, and a cat meme that I’ve been enjoying recently.
Image may be NSFW. Clik here to view.
This example comes from MacOS in the NotesStore.sqlite database (iOS is similar). The “ZICNOTEDATA” table contains the contents of each note. Some eagle-eyed readers may notice the highlighted bytes in the binary output. It stores note contents in gzip archives embedded in the SQLite database.
Image may be NSFW. Clik here to view.
I exported this gzip archive and used gzcat and xxd to preview the contents of it. I can see the text and link in the note along with some media information. What we have here is another protobuf!
Image may be NSFW. Clik here to view.
The protoc output is below, many of the same strings are visible but there are some odd ones in there.
Image may be NSFW. Clik here to view.
One in strange one in particular is the line "\033\'w\213\256?@Q\251IHEn\221\242\260". This is escaped octal. You will find this being used in a variety of different protobuf data. Some are smaller, some are much larger. I recall the one that Heather Mahalik and I looked at for Android Auto. That one was just full of octal nastiness, it was awful.
This one is small and converts well using echo. What does it represent? I have no idea…yet.
Image may be NSFW. Clik here to view.
The media itself is stored in the file system (you can use information in the database to find the proper path). We can use the GUID in the protoc output to find the preview thumbnail.
Image may be NSFW. Clik here to view.
Summing Up
I will be very honest, I have been looking at these weird data blobs for years without knowing what they were. I am at the point now where I’m a little obsessed with protobufs. I know…its weird – but now every time I see rando-blob-data with a bunch of 0x0A hex bytes – I think protobuf, and nine out of ten times, I am correct!
If you happen to know where I can find more information on the .proto files, please let me know!
On this third day, we will focus on application usage. We will cover three databases:
KnowledgeC.db
Be sure to check out more detailed information on this database in my two previousarticles.
Access to this database is limited to a file system dump, it will be located in /private/var/mobile/Library/CoreDuet/Knowledge/KnowledgeC.db
InteractionC.db
Access to this database is limited to a file system dump, it will be located in /private/var/mobile/Library/CoreDuet/People/InteractionC.db
CurrentPowerlog.PLSQL
Access to this database is usually limited to a file system dump, but I recently learned that if you can perform a sysdiagnose on the iOS device you can get this log as well! This method is certainly not forensically sound, but it will get you access to the database. You will have to rename this database to “CurrentPowerlog.PLSQL” from something like “powerlog_YYYY-MM-DD_##-##_########.PLSQL” to parse it with APOLLO. I have plans to update the script to support this naming scheme.
In a file system dump, you can find this database in /private/var/containers/Shared/SystemGroup/<GUID>/Library/BatteryLife/CurrentPowerlog.PLSQL
It is worth a mention here that additional historical Gzipped PowerLog databases may be found in the /Archives directory in the path above. (My APOLLO script does not handle auto unarchiving of these yet, but it is planned for the future.)
Application Information, Installation, & Deletion
Let’s start by getting some basic app information. The Powerlog has a nice listing of iOS applications with their App name, executable name, bundle ID, and version and app type. These entries are not exactly an ongoing log file, but it does get updated frequently. The app type column can provide information on what type of application it is.
1 – Background iOS Service
3 – iOS Native App
4 – 3rdParty App
These entries will also have information on if the app has been deleted. This listing can be extracted by using the powerlog_app_info module.
Image may be NSFW. Clik here to view.
I have a very similar module called powerlog_app_deletion that uses the application deletion time as its key to get just the recently deleted applications.
Image may be NSFW. Clik here to view.
To get a listing of recent application installs, we need to go to the KnowledgeC.db database. You will see in this blog series that you cannot rely on one database for all the answers. The module knowledge_app_install will extract the time of install and Bundle ID for the newly installed app.
Image may be NSFW. Clik here to view.
Application Play by Play
Knowing what application was being used at any given moment, down to the second, can be a huge forensic win. Fortunately, we have a couple of options, each a little different.
The first is the KnowledgeC.db database. The knowledge_app_inFocus module shows the app Bundle ID, day of the week, GMT offset, start/end of the usage time from which I calculate usage time in seconds.
Image may be NSFW. Clik here to view.
Another option is the powerlog_app_usage module which uses the CurrentPowerlog.PLSQL database. The output contains the app Bundle ID and a few other metadata items.
You will notice a few additional columns in the output:
ORIGINAL_SCREEN_STATE_TIMESTAMP
OFFSET_TIMESTAMP
TIME_OFFSET
These additional columns are needed because the timestamps need to be normalized. The original timestamp is stored with an offset, sometimes in the future, sometimes in the past. This offset is stored in PLSTORAGEOPERATOR_EVENTFORWARD_TIMEOFFSET table in the CurrentPowerlog.PLSQL database. This offset gets used in many of the Powerlog tables. I want to provide a warning to other investigators to not always believe the timestamp provided in a database. You MUST test this, I’ve seen offsets from as little as a few seconds to as much as 15 minutes. In my queries I’ve done my best to test what I can, but I’m sure I’ve missed some and they may change per iOS version (we will see an instance of this in the next module). Noticed I missed one? Please let me know!
Image may be NSFW. Clik here to view.
The modules powerlog_app_usage_by_hour and powerlog_app_usage_by_hour_iOS12 extract data usage on a per hour basis. During the research for this blog article, I was using my own iOS 12 Powerlog output from sysdiagnose to test differences with iOS 12. I came across one issue with this particular module, I determined in iOS 12 that the timestamp in this table now implements the same time offset that we saw above, however on iOS 11 (and older) it did not. Soon I will implement a function in the script to determine which iOS to perform which queries, however now it will run both so please be aware of this.
Below is an example from iOS 11.
Image may be NSFW. Clik here to view.
Below is an example from iOS 12 with the time offset applied (offset columns are hidden from view). Not shown in the screenshot is a bug where the applied time offset may show the ADJUSTED_TIMESTAMP off by a single second for earlier records. If anyone has recommendations on a better SQLite query to perform this offset adjustment, drop me a line!
These modules extract an applications usage on a per hour basis. The query will extract the app bundle ID, screen and background time, and additional background usage with audio and location.
Image may be NSFW. Clik here to view.
Context Providers
The next step is to provide more context to each application being used. We have quite a few modules for this.
The InteractionC.db database contains lots of information to correlate contact information with application activity. The screenshot below only shows a portion of the contact data for each record, but it should be a good indication of what email was being read or what contact was being texted. This module is named interaction_contact_interactions.
Image may be NSFW. Clik here to view.
Curious what the user was browsing when they were using Safari, try the knowledge_safari_browsing module. There are a few catches to this one, it will not record private browsing and entries will be removed when they are history is cleared (either by the system or user).
Image may be NSFW. Clik here to view.
Using application activity streams in the KnowledgeC.db database we can extract more information using knowledge_app_activity module on to determine items like Apple Map directions, Mailbox or Message views, specific 3rd party application usage, and other native Apple iOS app activities.
Image may be NSFW. Clik here to view.
I created a similar module, knowledge_app_calendar_activity, specifically for Calendar activity since it has a bit more calendar related metadata items associated with it.
Image may be NSFW. Clik here to view.
Again using the KnowledgeC.db for context, I can use the knowledge_app_intents module to determine more details of application usage, including sent messages, map searches and navigation, Safari browsing, and phone calls. A keen eye will notice the data blob in the SERIALIZED INTERATION (HEX) column starts with the hex of a binary plist. This binary plist contains more specific contact information, such as who a message was sent to or what contact was called. I saved it in hex to easily copy/paste it into a hex editor or to save off as a plist file.
Image may be NSFW. Clik here to view.
Finally, we can use the knowledge_application_portrait to get even more contact information for messages or account information for an associated email account. The items in GROUP ID can vary but usually if it’s a GUID it will correspond to a specific email account that can be found in the user’s Accounts database.
Image may be NSFW. Clik here to view.
Have you been naughty or nice? Us forensic analysts are watching!
The fourth day brings us media artifacts using the knowledgeC.db and CurrentPowerlog.PLSQL databases. Each database stores similar yet somewhat different records when it comes to audio, and video usage.
The example below is audio inputs. Two different devices can be seen in the screenshot below, a CarPlay device and my AirPods.
Image may be NSFW. Clik here to view.
In the output example we see the same two devices. Common to both is the fact that you may see it bouncing back and forth as devices are being used. For example, if you are using CarPlay rocking out to WHAM’s Last Christmas, it will bounce between playing your music and using the microphone/speaker to listen/dictate messages as they come in.
Image may be NSFW. Clik here to view.
The knowledge_audio_media_nowplaying is where the real truth of your guilty musical pleasures will make an appearance. It provides a detailed listing of what the user was listening to at a particular time. The example below shows me listening to music, podcasts, and audio books. There is no denying that you started listening to holiday music entirely too early!
Image may be NSFW. Clik here to view.
CurrentPowerlog.PLSQL
The powerlog_app_nowplaying module sounds like it should extract the same information as above, however it is different in that it will just show the application’s bundle ID being used to play the media.
Image may be NSFW. Clik here to view.
More context can be found by using the powerlog_app_audio module. This module will extract the app/service name and/or bundle ID for the app using the audio function. In the screenshot below, I received a phone call and a bit later connected the iPhone to my car to listen to music. During that time, I was also using Siri (assistantd) to dictate messages. Fortunately for me, this database doesn’t show what I was listening to! 🤭
Image may be NSFW. Clik here to view.
Similar to the module above, is the powerlog_audio_routing module. This shows where the audio was routed to, either the Speaker, Receiver, or Car in this example.
Image may be NSFW. Clik here to view.
Finally, the Powerlog populates a table just for videos. The powerlog_video module will show the application bundle ID that the video was played with, however not what video was playing.
Today we go over one of the stranger databases on iOS, the Aggregate Dictionary database, or ADDataStore.sqlitedb. This database is only available with a physical file system dump in the /private/var/mobile/Library/AggregateDictionary/ directory. The database also has a different way of storing its data. Instead of a “this time this event happened” storage system like many of the other database I’ve gone over. This one aggregates data for the last seven days. It only records data on a per-day basis so the APOLLO modules will only store a day timestamp.
This database is good to find random bits of useful stuff, not every case will need it but you might be surprise what it is tracking. The Distributed Keys and the Scalars are each keeping track of seemingly obscure items. In my opinion, the Scalars are more interesting. On my example database I have 5398 unique keys for Scalars and 795 keys for the Distributed table. I can’t even begin to show you everything this database tracks, its best just to take a look at one yourself to see what might help in your own investigations. I will focus here on a few of the more interesting Scalars entries.
APOLLO only has two modules for the Aggregate Dictionary. Since these are using only a per-day timestamp, I’ve made them easy to filter out or as a user choose to not use these modules. They can look a tad messy in the final output.
The first item I pulled out of the stocking is CarPlay data. The example below shows how many cars I’ve connected using CarPlay in com.apple.CarPlay.VehicleCount. I’ve connected this device to three different cars. I’m still testing the difference between*.CarPlayCar.* and *.tCarPlayPhone.* keys, however I could guess that Activations has something to do with how many times the app was selected while the ActiveTime is how long the app was in use.
Image may be NSFW. Clik here to view.
The next item has to do with the Messages application. This app is collecting metrics on the different types of items sent and received over SMS or iMessage protocols.
Image may be NSFW. Clik here to view.
The Settings applications (com.apple.Preferences) keeps track of which setting got viewed. The example below shows I viewed the Bluetooth menu twice on the 10th, and the privacy settings once on the 14th. I encourage everyone to search for various bundle IDs of interest in this output – you never know what the apps are going to store!
Image may be NSFW. Clik here to view.
The Clock app (com.apple.MobileTimer) keeps track of how many alarms the device has set, if any are active, number repeating, and named alarms. Some apps are better at storing data like this than others.
Image may be NSFW. Clik here to view.
Safari records the number of tabs open on a particular day
Image may be NSFW. Clik here to view.
The Photos app (com.apple.mobileslideshow) keeps track of how many photos there are in the albums.
Image may be NSFW. Clik here to view.
Curious how many times a device was plugged in during a day, try the com.apple.power.state.pluggedin.count key. We will revisit this action in an upcoming device state article.
Image may be NSFW. Clik here to view.
When I say obscure, I mean obscure – it also keeps track of button presses…because why not!
Image may be NSFW. Clik here to view.
Some settings are also stored in this database. You can perform a filter for a couple of keywords – enabled or disabled. I’ve provided a screenshot for both. For the “Enabled” keys, I chose to filter on the main interface, Springboard (com.apple.Springboard). The value is a binary value that means on (1) or off (0). This is different for the “Disabled” keys.
Image may be NSFW. Clik here to view.
If the keys have the term “disabled” in them, you have to think opposite. For example, all these Accessibility features are actually turned on or enabled. If the disabled setting is a 0, it means it is turned on (you can see many of the settings in the iOS screenshot, Shake to Undo and Vibration for example.)
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
Finally, in the toe of the stocking we can get some data usage information. I’ve filtered here by the Twitter application (com.atebits.Tweetie2). The screenshot shows how much data was transferred in kilobytes over Wi-Fi and/or WWAN – incoming or outgoing.
Image may be NSFW. Clik here to view.
Looks like Nick is ready to analyze what’s in his stocking!
On this sixth day we’re going to go back to looking at the knowledgeC.db and CurrentPowerlog.PLSQL databases. If you are unfamiliar with these databases, please go back a few blogs. Today is all about what state the device is in.
Let’s start with the battery level. This is surprisingly covered in a couple of databases and multiple tables in these databases, plenty of places to get this information. The first one is using the knowledgeC.db database with the knowledge_device_batterylevel module. This database provides the usage time between battery levels which may be used to determine amount of usage during a particular time period by the user or device.
Image may be NSFW. Clik here to view.
Similar is a couple of modules using the CurrentPowerlog.PLSQL database. These two have slight differences. The powerlog_battery_level_ui module just has the battery level as shown in the GUI, while the powerlog_battery_level shows additional information such as raw level and if the device is charging or is fully charged.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
The next state is if the device is locked or not. Again, we’ll start with the knowledgeC.db knowledge_device_locked module.
Image may be NSFW. Clik here to view.
Going back to the CurrentPowerlog.PLSQL database we have a couple of modules for the same stat. The difference between these is that the latter keeps track of devices locks if the device is using the timed auto-lock function, that “1” just shows that it is in a locked state. The first example shows lock and locked states.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
The next few modules are all random device states that may come in handy. The first is the button state. The powerlog_button_state module appears to keep track of which button are being pressed. I’m still testing this one, but this data came from an iPhoneX that has just the power button (apart from the volume buttons). I believe button 48 may be the power button as the timestamps seem to align with locking the device.
Image may be NSFW. Clik here to view.
The powerlog_camera_state module will keep track of which app and which camera is being used. This will truly tell how many duckface selfies you’ve taken.
Image may be NSFW. Clik here to view.
Care to know if THE DEVICE IS AT FULL VOLUME PLAYING ANNOYING YOUTUBE VIDEOS? Well then, give powerlog_device_volume a try. 100% is a full volume, and 0 is no volume or “muted”. For some reason I cannot get the “MUTED” column to populate when the device is clearly muted. 🤷🏻♀️
Image may be NSFW. Clik here to view.
The powerlog_mobilebackup module keeps track of backup activity, in this case iCloud backups.
Image may be NSFW. Clik here to view.
Finally, we have the powerlog_torch_state, which keeps track of when the device flashlight is turned on and off. I still think the torch sounds odd, but I guess the rest of the non-US based worlds calls it that. 🤷🏻♀️
Today is all about the CurrentPowerlog.PLSQL database. This database keeps track of many ways that data is transferred either by cellular, Wi-Fi, or Bluetooth methods. These modules can help determine where the data is going, which app is pulling down the most data, or simply keeping an eye on which apps are sending the most notifications.
Telephony Activity
Starting with telephony artifact we can review the cellular registration using the powerlog_device_telephony_registration module. This outputs the cellular provider and the level of service provided.
Image may be NSFW. Clik here to view.
The powerlog_device_telephony_activity module will keep track of telephony activity on the device. In the screenshot below, each time the CALL STATUS shows ringing, I was receiving a phone call (that I ignored), but where it says ACTIVE, I made a phone call.
Image may be NSFW. Clik here to view.
Another module that shows call usage, is the powerlog_incallservice module.. Like the example above this shows me ignoring three calls (callForegrounded, callBackgrounded) and a call made (callStart, callStop).
Image may be NSFW. Clik here to view.
Network Usage
Mobile devices have network interfaces that track where the data is going. The powerlog_network_usage module keeps track of the incoming and outgoing bytes for these interfaces.
Image may be NSFW. Clik here to view.
If you want a bit more detail on which apps or services are using your precious cellular data, take a look at the output of the powerlog_process_data_usage module. This can make it easy to see which app is burning through your mobile data. (Mine is always Twitter).
Image may be NSFW. Clik here to view.
The powerlog_push_message_received module will show push notification activity for various network-based services. In the screenshot below are the notifications for Slack, Twitter, iMessage, etc.)
Image may be NSFW. Clik here to view.
Bluetooth Activity
Many Apple technologies rely on Bluetooth technology to function. Determine what state Bluetooth was in is logged. Using the powerlog_bluetooth_device_state module, we can see which state it was in.
Image may be NSFW. Clik here to view.
AirDrop is one of the technologies that uses Bluetooth (also Wi-Fi), the AirDrop state is recorded and can be extracted by the powerlog_airdrop module.
Image may be NSFW. Clik here to view.
Continuity [https://www.apple.com/macos/continuity/] is a technology to move data back and forth between devices. AirDrop makes use of this technology. This activity can be extracted by the powerlog_ids_messages module.
Today we’ll be analyzing the knowledgeC.db and CurrentPowerlog.PLSQL database for various connections. The first thing you may want to know in an investigation is – was the device plugged in or not? This can be gained from a few places.
The knowledgeC.db database tracks this information and can be parsed out by using the knowledge_device_pluggedin module. This will keep track of the plugged in and unplugged states of the device and for how long each of those events were as calculated out in the ‘Usage in Seconds’ column.
Image may be NSFW. Clik here to view.
Similar data is captured in the CurrentPowerlog.PLSQL database. The powerlog_lightnining_connector_status module extracts the same events, however I have seen in my own data some slight oddities, like the plug in/unplug events every minute or so – almost like the cable was loose (it wasn’t). Take that observation for what it’s worth, at least we can corroborate with other data!
Image may be NSFW. Clik here to view.
Another option is the powerlog_accessory_connection module. This one also appears to be more accurate but I’m not entirely sure what all “accessories” would be covered. My own data shows connections to power cables, this would include my CarPlay connection.
Image may be NSFW. Clik here to view.
Speaking of CarPlay, we can extract that connection information using the knowledge_device_carplay_connected module. This output only has the initial connection, not the disconnect event.
Image may be NSFW. Clik here to view.
Instead of physical connections, we may also be aware of wireless connections like Bluetooth. We can use the knowledge_audio_bluetooth_connected module to extract this information from the KnowledgeC.db database. This output contains the Bluetooth MAC address and name of the device. I’m obviously rocking out using my AirPods like a good Mac Fan Girl. 🤘🎶
Image may be NSFW. Clik here to view.
Next on the Bluetooth list is the Apple Watch. The knowledge.db database also keeps track if the device is near the iPhone to which it is paired. The knowledge_device_watch_nearby module will show if I walked away from my iPhone for a certain period of time.
Image may be NSFW. Clik here to view.
In the Powerlog, the paired Apple Watch information is stored. It not really in a log format but could be useful information. I have yet to determine the significance of the timestamp, it is not the initial pairing of the device. This can be extracted using the powerlog_paired_device_config module.
Image may be NSFW. Clik here to view.
Finally let’s look at Wi-Fi connections. The Powerlog is keeping track of each SSID that my phone has connected to, but the name is a bit odd, I’m still researching why it is using this naming scheme, ideas are welcome. The “SSID” is alphanumeric and always same length. The powerlog_wifi_properties module will extract this data.
The interface of the device can produce some useful artifacts. Starting with screen orientation. Perhaps you want to know if the user was watching a video for a period of time. In conjunction with other artifacts that I’ve already details like app usage the knowledge_device_orientation module will show if the screen was in landscape or portrait mode.
Image may be NSFW. Clik here to view.
The knowledge_device_is_backlit module will let you know if the display was backlit or not, this is different than if the device was locked or not – perhaps the user was just checking their messages without unlocking the device.
Image may be NSFW. Clik here to view.
Moving to the Powerlog, we can use the powerlog_device_screen module to see what “screen” the device was on. I’ve researched this one a bit and on my iPhone7 on iOS 11. These are the “screens” I was able to determine.
Homescreen(s) = 2
Widgets = 19
Control Center = 5
Lock Screen = 9
Pin Unlock Screen = 15
Blank Screen = 0
App Switcher = 4
Spotlight Search = 18
Lock Screen Camera = 11
Lock Screen Widgets = 17
Image may be NSFW. Clik here to view.
Perhaps the how light or dark the environment is can help you in an investigation. The Powerlog stores the screen brightness. The lower the brightness, theoretically the darker the environment is where the device is, especially if the auto adjust feature is on. The powerlog_display_brightness module can output this data.
Image may be NSFW. Clik here to view.
The next two modules powerlog_springboard_aggregate_bulletins and powerlog_springboard_aggregate_notifications] are some modules that I’d like to research more. I believe these are the notifications that are presented to the user for each application. However, I don’t know yet what the differences between a bulletin and a notification yet.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
I saved one of my favorite topics for (nearly) last. There is no question that location can play a major role in many investigations.
iOS location data as changed drastically with iOS 11 from previous iOS versions. I published research on these locations in the past and parsing scripts.
It is my goal to update these scripts with this new research soon(ish).
Powerlog Metadata
The CurrentPowerlog.PLSQL contains some useful metadata associated with the primary locations data I’ll discuss a bit later in this article.
The powerlog_location_tech_status module contains a log of how location was determined. Was the location determined by Wi-Fi or GPS technologies? This information can contribute to how accurate the location data may be.
Image may be NSFW. Clik here to view.
The powerlog_location_client_status module appears to keep track of which applications and services are requesting location data. Some app examples below include Waze, Weather Underground, The Weather Channel, and the AUDI app. The services can be seen in the second screenshot (the data contained in this table was too long for only one!).
The type of location is also recorded along with accuracy figures. I’ve seen the following types.
Location
Significant (Likely has something to do Significant Locations)
Fence (Geofencing?)
Visit
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
Finally, we have a small log of providing time zone context to the data. The powerlog_timezone module will extract this information.
Image may be NSFW. Clik here to view.
Significant Locations & Routined Databases
As I’ve mentioned above, the storage of the routined process locations and Significant Locations has changed dramatically in iOS11 from previous versions.
These databases are stored in the following path and are only accessible in full file system dumps.
The first database, Cache.sqlite, contains an extremely detailed history of coordinates where the device was. In my own data I had over 40,000 (!) data points. This data is stored for just over a week. This can provide a very accurate map of where I was during that last week.
The routined_cache_zrtcllocationmo module can extract these coordinates along with a timestamp, altitude, course, speed (meters/second), and vertical/horizontal accuracy figures.
Image may be NSFW. Clik here to view.
Also kept for about a week is data extracted with the routined_cache_zrthintmo module. It has fewer data points, but the timestamp and coordinates appear to be accurate.
Image may be NSFW. Clik here to view.
Cloud.sqlite - Significant Locations - Visits
The next few modules all use basically the same query but are keyed off of different timestamps. The example shown is of the first module.
Again, this screenshot was split into two because of the amount of data provided by this table. Each significant location visit contains various timestamps (visit entry/exit, visit creation/expiration, learned place creation/expiration). Each visit has coordinates along with a Place ID (an identifier for a specific location), data points collected for that place, uncertainty and confidence figures, and device logging information.
In the second screenshot there are two odd looking columns, Place Name BLOB and Place Geo BLOB. Each of these columns is storing BLOB data in hex format. I chose this format as it is easy (relatively) to copy/paste into a hex editor for viewing. Examples below.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
The first column “Place Name BLOB” contains a smaller amount of binary data (than the Place Geo BLOB), and as you can see you can fairly easily determine where I was at this time – Dulles Airport (I’m a frequent visitor there as you can imagine.) You get address, city, state, business name information in this blob.
Image may be NSFW. Clik here to view.
The second column “Place Geo BLOB” contains much more binary data, but you can still pick out some similarities in the strings.
Image may be NSFW. Clik here to view.
So here is the kicker – for YEARS I just accepted these BLOBS, tried to parse them and was unsuccessful but didn’t care too much as I could always see the contents of them. While putting this article together I finally discovered their format – it’s a Christmas miracle!
I do lots of mobile work, that includes Android devices for a good portion of the time (Android, eww – I know, but it provides a paycheck. 😉) When I see random BLOBs in anything Android related my first inclination is to say it’s a Protobuf – a very Googly format. 90% of the time I’m right, I can usually spot them pretty easily. For some reason while looking at them now, my usual protobuf triggers just slapped me in the face so I gave the protoc a try (see the usage below.)
protoc --decode_raw < binary_BLOB
It worked! I finally have a parsed data structure, granted some of the protobuf pieces I still need to determine but its certainly further than I’ve gotten before. Below is the protobuf output for the “Place Name BLOB”. Many of the strings are obvious, however the highlighted section is the coordinates for Dulles Airport. These are 8-byte floats stored in big-endian as shown in the hex editor below.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
The “Place Geo BLOB” is quite a bit lengthier, too long in fact to create a decent screenshot of but still contains the string data and coordinates as expected.
Fun Fact – These protobuf data BLOBs are scattered throughout macOS and iOS systems, you can also see them in Maps data if you are looking for examples to play with. Those also appear to contain timestamps! I promise I’ll do a nice protobuf location blog in the near future. I love me some protobufs! (I’m weird, I know.)
Local.sqlite - Significant Locations - Locations of Interest
Ok back to Significant Location databases. There is one left, the Local.sqlite database. This contains similar data to what we’ve seen before. Timestamps, coordinates, confidence, uncertainty, data point count, and (protobuf!) BLOBS. As with the other modules, they query is basically the same but is using different timestamps to key off from. The example is from the first module. These screenshots are also from the same query, too long to post as a single screenshot.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
The last piece of location data I’m extracting from the Local.sqlite database is parking history. I connect my iPhone to my vehicle via CarPlay so I’m not sure if this is required to populate this data. The first module routined_local_vehicle_parked shows the last location of my parked car.
These modules should give you a pretty good idea where a certain user’s device was a given moment. It is worth mentioning the data does expire after a certain period of time, the sooner you have the data the better the data will be for you. Historically it appears to be pretty accurate but significant locations, but it doesn’t have every location. Dump that phone ASAP!
Santa can easily find where you live. Creepy Santa.
I did a blog article, especially about the knowledgeC.db about a day in the life of my iPhone and it went over really well. I’ve decided to do a similar story using all the data that I’ve parsed from my iPhone using APOLLO, quite a bit more data to handle. For my device, I had 1.6 million rows!
Image may be NSFW. Clik here to view.
Grab a holiday cocktail or a mug of eggnog and sit back and read the (quite boring) tale of my iPhone on September 16, 2018. This is the query I used for this day to filter it down from ~8800 rows.
Image may be NSFW. Clik here to view.
On this particular day I was out celebrating my good friend Brian Moran’s Birthday at his house in Maryland. Around Midnight I decided it was time to leave and connected my phone to my car using CarPlay. The Device Status here shows the plugged in and CarPlay connections.
Image may be NSFW. Clik here to view.
Next, I put in directions to “Home” in Apple Maps. I haven’t left yet, I’m still sitting in his driveway. You can see the SPEED is 0.0 in the Location output. Once I start to leave, you’d see that get populated.
Image may be NSFW. Clik here to view.
During the drive I’m listening to Apple Music, in the Application Activity entries you can open these in the cell browser (depends on your SQL browser) to get more information than is seen in the screenshot row – some entries are very lengthy. Its late at night, good time for some dance music!
Image may be NSFW. Clik here to view.
I barely leave his house for five minutes before I receive a text from him in the Messages application (💕you Brian! 😂). Again, clicking the row for more information can be helpful. You can see how often I chat with a contact, over what application, and various related timestamps.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
I message him back using Siri through CarPlay. The App Usage shows com.apple.assistant_service and com.apple.MobileSMS which is Siri dictation for the Messages application. Just after that you can partially see a Send Message Intent in Application Activity. The next Application Activity/Device Status is CarPlay switching back to my music.
Image may be NSFW. Clik here to view.
Apple Watch data is sometimes activated during a drive – here you can see me getting my steps in while I’m clearly driving. 🤷🏻♀️
Image may be NSFW. Clik here to view.
While my iPhone is connected to CarPlay, it is also charging. Note the BATTERY LEVEL increasing in the next two screenshots.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
I get close to home, so I turn off my Maps navigation. The Application Activity can be used to determine my navigation “to” and “from” locations. Redacted below.
Image may be NSFW. Clik here to view.
A few minutes later I’m home and parked, I disconnected my phone from my car.
Image may be NSFW. Clik here to view.
I unlock my phone and start checking my Messages. You can also see some population of Significant Locations here as well.
Image may be NSFW. Clik here to view.
I have an Orangetheory [https://www.orangetheoryfitness.com] class in the morning (later this morning, really), I better set an alarm. Also check to make sure I know what time the class is.
Image may be NSFW. Clik here to view.
I plug the phone in before going to sleep.
Image may be NSFW. Clik here to view.
Early in the morning, I want to know what time it is so I tap the screen to check. Still plenty of time to sleep!
Image may be NSFW. Clik here to view.
I’m awake and (somewhat) active - I unplug the phone.
Image may be NSFW. Clik here to view.
Of course, I need to check Twitter.
Image may be NSFW. Clik here to view.
…and some other apps…
Image may be NSFW. Clik here to view.
…and more apps, while drinking my coffee.
Image may be NSFW. Clik here to view.
Time to walk to the gym and start a workout. Once I select workout on my Apple Watch a couple of Health Workout Locations get populated with the coordinates of my gym. (Feel free to join me!)
Image may be NSFW. Clik here to view.
In the middle of my workout I feel like I’m dying. 😵
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
A bit later I check WhatsApp, good to see my heart rate go down a bit too!
Image may be NSFW. Clik here to view.
The afternoon is filled with research on my laptop at home. You’ll see plenty of location data of me going absolutely nowhere (other steps recorded around my condo) – however if you check my knowledgeC.db on my laptop things would be a bit more interesting!
Looks like I logged in somewhere else that asked me for my two-factor code. (I don’t even remember.)
Image may be NSFW. Clik here to view.
Check in my Fantasy Football team, not doing so awesome this year. 😬
Image may be NSFW. Clik here to view.
Getting to Sunday evening, I start determining what I have to do in the next couple days. What exercise classes did I sign up for, what do I have to do on the 18th?
Image may be NSFW. Clik here to view.
Finally, I set an alarm to make sure I get up on time for my workout.
Videos have been posted from Objective by the Sea from this past November. My talk ‘From Apple Seeds to Apple Pie’ a pattern of life talk about my APOLLO tools is here.
As always, my videos and presentations will always be available on the Resources page!
Two iOS databases that I’ve always found interesting (and probably should test more) are netusage.sqlite and DataUsage.sqlite. These two databases contain very similar information – one is available in a backup (and file system dumps) the other only in file system dumps. These databases are excellent at tracking application and process network usage.
These databases can provide answers to investigative questions such as:
What apps were being used?
What apps were used more than others?
Did the device communicate over cellular or wi-fi more often and when?
What apps were used that are no longer on the device?
I’ve created modules for these databases in APOLLO, but you can also use the SQL queries in a standalone environment. I’m still working on how best to represent the timestamp keys and may alter the APOLLO code to accept multiple timestamp keys. This will help some other modules I’ve been working on as well so keep an eye out for that. I also need to work on acceptance of multiple database names, thanks to DataUsage-watch.sqlite.
The first set of modules are netusage_zprocess and datausage_zprocess. These two use the same SQL query as it is the same table, just different databases. These query extracts the process and/or the application bundle id. This query will show two timestamps:
TIMESTAMP – I believe this is the most recent timestamp for the process/application.
PROCESS FIRST TIMESTAMP – This appears to be the first usage of the process/application.
The first example comes from netusage.sqlite, the second from DataUsage.sqlite. It is notable to show that more information is available potentially from DataUsage.sqlite. Since this database is backed up it has the potential to have very historical data. These examples come from my iOS 11.1.2 dump. NetUsage goes back to November 4,2017 when I first setup iOS 11 on the device. The DataUsage database on the same device goes all the way back to 2013! This was from my iPhoneX which certainly did not exist in 2013. I restore backups onto new devices. I also get many more records from the DataUsage database.
Image may be NSFW. Clik here to view.
netusage_zprocess
Image may be NSFW. Clik here to view.
datausage_zprocess
The next set of queries are netusage_zliveproces and datausage_zliveprocess. These modules technically have a copy of the ZPROCESS data so they may be redundant if you are running APOLLO. Again, this is the same query for each database. DataUsage will again have many more entries. The added value from the ZPROCESS queries is the added network data information, Wi-Fi In/Out and WWAN In/Out. I will assume this value is stored in bytes until I can test further.
The major difference that I can tell between the two databases (apart from number of records), is that the DataUsage database does not record Wi-Fi network data. I know for sure I was on Wi-Fi at some point in the last six years! (It shows in NetUsage – remember it is the same device. Check out my Twitter data, its almost horrifying! 🤭)
Image may be NSFW. Clik here to view.
netusage_zliveprocess
Image may be NSFW. Clik here to view.
datausage_zliveprocess
Finally, we have an additional query only for the netusage.sqlite database, netusage_zliverouteperf. This query extracts lots of information, some of which I have no idea what it is. The first step into determining this is creating the query! In addition to some timestamps that appear to be stored on a per-hour basis we have the type of network traffic (Cellular or Wi-Fi), bytes and packings coming and going, connection information.
Image may be NSFW. Clik here to view.
A second screenshot is required to show the rest of the extracted data. Some sort of cellular network identifier (any ideas?) or Wi-Fi (SSID/BSSID) are provided, with additional network-based information.
I started filling in the gaps to missing APOLLO modules. While doing this I realized there was some capability that was missing with the current script that had to be updated. As far as script updates go the following was done:
Support for multiple database name -Depending on the iOS version being used the database names may be different but the SQL query itself is the same. Instead of creating many redundant modules I now have it looking for the different database filenames.
Support for multiple queries on different iOS versions- You will now notice that all the modules have been updated with iOS version indicators and multiple SQL queries compatible for that version. Some going back as far as iOS 8! I put in as much legacy support as I had data for. I will likely not add much more unless it is by special request. I can’t imagine there is a whole lot of iOS 8 analysis going on out there, but you never know! I have kept it to major iOS release numbers and have tested with the data I have but it may have changed with a minor point release, if you find this to be true please feel free to let me know!
Module Timestamp Rearrangement and Module Cleanup– I’ve started to go through some of the modules and move the items around to make it easier to see what is going on with each record. I’ve mostly just moved the timestamps toward the end since most of them are shown in the Key column. I’ve also removed some superfluous columns and extraneous junk in the queries. I’m really only trying to extract the most relevant data.
A few notes on script usage change. The script flags have changed, with the added arguments of -p = platform (iOS support only for now), and -v = iOS Version. You may also notice the new ‘yolo’ option – this one will likely be error prone if you are not careful. Use this when you what to run it on any database from any platform. It can also be used with your own custom modules if you don’t have versioning in them.
Image may be NSFW. Clik here to view.
An example of the module changes is below. Notice the multiple databases listed. In this example, the same location data can be extracted from the cache_encryptedB.db or the cache_encrypted A.db databases depending on the iOS versions. The version information is listed in the “VERSIONS” key, while the specific queries have versions listed in the [SQL Query …] brackets, this is the version that the apollo.py script is following.
Image may be NSFW. Clik here to view.
The big updates were with the modules, lots of new support! I now have support for 129 different pattern-of-life items! Most of the support is for iOS, however if you run the queries themselves on similar macOS databases you will find that many of them will work. Better macOS support is coming, I promise.
Application Specific Usage:
Chat – SMS, iMessage, & FaceTime messages extracted from the sms.db database.
sms_chat
Call History – Extracted from CallHistory.storedata database.
call_history
Safari Browsing – Extracted from the History.db database.
safari_history
Apple Pay/Wallet - Extracted from iOS passes23.sqlite database.
Apple Pay Transactions - passes23_wallet_transactions
Wallet Passes - passes23_wallet_passes
Location :
locationd - The following modules extract location data from the [lock]cache_encryptedA.db & cache_encryptedB.db databases. This will include various cellular and Wi-Fi based location tables as listed in the module filename.
locationd – These modules extract motion data from the cache_encryptedC.db database. Not specific location data but will show device movement.
locationd_cacheencryptedC_motionstatehistory
locationd_cacheencryptedC_nataliehistory
locationd_cacheencryptedC_stepcounthistory
routined – Extracts location data from the cache_encryptedB.db database. If you have a keen eye you will notice the database name is the same as from ‘locationd’. Completely different database with different data stored in two different directories.
routined_cacheencryptedB_hint
routined_cacheencryptedB_location
Health Workouts – Using the healthdb_secure.sqlite database I’ve extracted much of the metadata from workouts. I’ve also determined some of the workout types (ie: HIIT, Rower, Run, Walk, etc), but have not enumerated all of them yet. Please let me know if you come across others – easier if you do this on your own data and can easily look it up. Same for weather conditions (Sunny, Rainy, etc.).
