scripts

APOLLO v1.4 - Now with 'Gather' Function from iOS/macOS and updates to iOS14 and macOS 11 modules

in , , , ,

I’ve been working hard on a big update to improve core functionality of APOLLO to include methods to gather up the database files needed so they can be extracted from using the APOLLO modules.

New APOLLO Functions:

  • ‘gather_macos’ - Automagically finds and collects database files on macOS using modules.

    • Any directory, mounted volume, etc.

    • Ability to ignore certain directories

  • ‘gather_ios’ - Automagically finds and collects database files on jailbroken iOS devices using modules.

    • IP and Port Required

    • Ability to ignore certain directories

  • ‘extract’ - Nearly the same as before, rips through all the databases and extracts data via the SQL queries in the modules.

    • Improved CSV output

    • New JSON output within SQLite database

I’ve also updated many modules for iOS 14 and macOS 11. I’ve got more updates planned, however I still need to tweak, research, and test before I release.

You can see the new workings of the tool in my OSDFCon presentation - “Go for Launch: Getting Started with Practical APOLLO Analysis”

And for pure fun(!) a bonus Halloween themed presentation with “Getting Spooky with Apollo” that I did for a Fortego F-Con Lightning Talk. 👻🎃

Extensive knowledgeC APOLLO Updates!

in , , , , ,

While helping some investigators out I realized that my some of my APOLLO knowledgeC modules needed a bit of updating. Naturally I thought it would be quick, but it turned into quite an extensive update. I’ve included lots of brand-new modules as well as updates to ones that I’ve had before. 

Most of the updates to the older ones provided better backwards compatibility with older versions of macOS and iOS as well as adding additional contextual items to some of the queries from ZSTRUCTUREDMETADATA. Regression testing was performed on iOS 11, 12, and 13 and macOS 10.13, 10.14, and 10.15. Of course, please let me know if you run into a knowledgeC “stream” that I’ve not created a module for, or any issues that you might come across. 

I’ve highlighted a few modules below using my iOS 13.5 device. However, they may also apply to macOS and older iOS versions as well – review the modules for more documentation.

New Modules:

  • knowledge_activity_level_feedback.txt

  • knowledge_airplay_prediction.txt

  • knowledge_calendar_event_title.txt

  • knowledge_charging_smart_topoff_checkpoint.txt

  • knowledge_dasd_battery_temperature.txt

  • knowledge_device_locked_imputed.txt

  • knowledge_discoverability_usage.txt

  • knowledge_event_tombstone.txt

  • knowledge_inferred_microlocation_visit.txt

  • knowledge_knowledge_sync_addition_window.txt

  • knowledge_photos_edit_all.txt

  • knowledge_photos_deletes_all.txt

  • knowledge_photos_deletes_recent.txt

  • knowledge_photos_engagement.txt

  • knowledge_photos_share_airdrop.txt

  • knowledge_photos_share_all.txt

  • knowledge_photos_share_extension.txt

  • knowledge_segment_monitor.txt

  • knowledge_siri_activites.txt

  • knowledge_siri_flow_activity.txt

  • knowledge_sync_addition_window.txt

  • knowledge_sync_deletion_bookmark.txt

  • knowledge_user_first_backlight_after_wakeup.txt

The knowledge_app_activity_passbook.txt module was added to conveniently look for Apple Wallet (com.apple.Passbook) activity. Shown below I’m switching between my Apple Cash card and my Apple Card (yes, I got one for “research”).

The knowledge_photos_deletes_all.txt module appears to keep track of when I deleted a photo from the Photos app. This output is fairly vague. However, it could be useful in evidence destruction cases. The output of this one is similar to the other knowledge_photos_* modules.

Want to know if a thing was AirDrop’ed, copied, searched for, or otherwise interacted with from the iOS ShareSheet? The knowledge_sharesheet_feedback.txt module will help with that! Shown below, this module is keeping track of:

  • Photo Markups (com.apple.MarkupUI.Markup.MarkupPhotoExtension) via Camera App (com.apple.camera)

  • File Copies (com.apple.UIKit.activity.CopyToPasteboard) in Photos (com.apple.mobileslideshow)

  • Sending a photo in Messages (com.apple.MobileSMS) via Photos app (com.apple.mobileslideshow)

  • Finding text in a webpage (com.apple.mobilesafari.activity.findOnPage) in Safari (com.apple.mobilesafari)

  • Airdrop Activity (com.apple.UIKit.activity.AirDrop) 

Some modules are fairly self-explanatory. The knowledge_system_airplane_mode.txt modules keeps track of whether Airplane Mode on the device is enabled or not.

The next two are associated with the iOS low power mode functionality. The first, knowledge_device_battery_saver.txt which shows that I’ve activated Low Power Mode via the Control Center and while knowledge_device_low_power_mode.txt shows that it was turned on about two seconds after.

Click for larger view.

Updated Modules:

  • knowledge_activity_level.txt

  • knowledge_app_activity.txt

  • knowledge_app_activity_calendar.txt

  • knowledge_app_activity_clock.txt

  • knowledge_app_activity_mail.txt

  • knowledge_app_activity_maps.txt

  • knowledge_app_activity_notes.txt

  • knowledge_app_activity_photos.txt

  • knowledge_app_activity_safari.txt

  • knowledge_app_activity_weather.txt

  • knowledge_app_install.txt

  • knowledge_app_intents.txt

  • knowledge_app_location_activity.txt

  • knowledge_audio_bluetooth_connected.txt

  • knowledge_audio_output_route.txt

  • knowledge_device_batterylevel.txt

  • knowledge_device_inferred_motion.txt

  • knowledge_device_is_backlit.txt

  • knowledge_device_locked.txt

  • knowledge_device_pluggedin.txt

  • knowledge_discoverability_signals.txt

  • knowledge_notification_usage.txt

  • knowledge_paired_device_nearby.txt

  • knowledge_portrait_entity.txt

  • knowledge_portrait_topic.txt

  • knowledge_app_relevantshortcuts.txt

  • knowledge_safari_browsing.txt

  • knowledge_settings_doNotDisturb.txt

  • knowledge_siri.txt

  • knowledge_standby_timer.txt

  • knowledge_widgets_viewed.txt

The module knowledge_app_inFocus.txt has added extensions context. The extensions below show a location sign-in alert (com.apple.AuthKitUI.AKLocationSignInAlert) via the Springboard (com.apple.springboard), access to the Camera (com.apple.camera) via Messages (com.apple.MobileSMS), and access to Photos (com.apple.mobileslideshow) via Messages. All the while, playing around with the Unc0ver Jailbreak (science.xnu.undecimus).

New with knowledge_app_webusage.txt are the “Digital Health” columns. These will show website visits and associated URLs on various apps (not just Safari or Chrome!). 

In this example I was using Twitter (via Safari) on a device with the macOS hardware UUID (or iOS UDID) in Device ID column - let’s say my laptop. On my iPhone, I was also on Twitter but this time the iOS application (com.atebits.Tweetie2) ordering a new t-shirt from Jailbreak Brewery. 

Additions to knowledge_audio_media_nowplaying.txt include:

  • Is AirPlay Video

  • Playing – Values likely for Stopped, Playing, Paused – I will test those and update those in a future update.

  • Duration

  • Elapsed

  • Identifier

  • Media Type – Audio, Music, Video, Podcast

  • Output Device IDs (Binary plist in hex)

This is only a small slice of knowledgeC examples (and a very small part of APOLLO) so I hope this gives you some incentive to give it a try!

Providing Context to iOS App Usage with knowledgeC.db and APOLLO

in , ,

With the APOLLO v1.0 update, I updated many of the Application Activity modules used with the knowledgeC.db database. I mentioned in this article that these were updated to provide more context to specific user application activities. 

One column in particular that was added to all the App Activity modules is Z_DKAPPLICATIONACTIVITYMETADATAKEY__USERACTIVITYREQUIREDSTRING from the ZSTRUCTUREDMETADATA table. I will refer to this as “User Activity Required String” as that is what I’ve named it in the APOLLO modules. 

I will start with some of the application activity parsers for the native iOS apps. The first one, Maps, is particularly difficult but holds some really interesting and useful data.

Maps - knowledge_app_activity_maps

Many of the ‘User Activity Required String’ BLOBs for Maps looks more or less like the following (some are smaller, some larger.) Many investigators will recognize the base64. Whenever you are looking at an Apple device and see base64, you will want to decode it – there is usually great data in there!

You may also notice some readable text at the top of these BLOBs such as in this one. This can help provide quick context, so you can tell if you need to take the time to decode it. This example shows I searched for “Mike Serio’s Po-boys in New Orleans” while at BSidesNoLA this past October. (They were delicious.)

v1.0/com.apple.Maps/t='Mike%20Serio%27s%20Po-boys%20in%20New%20Orleans'&u=

….and others including searches, dropped pins, and directions.

v1.0/com.apple.Maps/t='Show%20DoubleTree%20by%20Hilton%20Hotel%20New%20Orleans'&u=
v1.0/com.apple.Maps/t='Dropped%20Pin%20on%20Nebovidsk%C3%A1%20459%2F3,%20Prague'&u=
v1.0/com.apple.Maps/t='Get%20directions%20to%20The%20Hotel%20at%20Arundel%20Preserve'&u=
v1.0/com.apple.Maps/t='The%20Remedy%20Room%0ADirection%20from%20My%20Location'&u=

I extracted just the base64 string (between the two $ signs) and decoded it on the command line with base64 and then piped it to xxd so I could see what it was. The string ‘BZh11AY&SY’ tells me we are working with a bzip archive file. 

This BLOB has four extra bytes at the beginning that we need to remove before we are able to interpret the bzip archive. We can use ‘tail -c +5’ to easily remove these so we get the bzip header right at the beginning.

Next we will pipe this to bzcat to see what is in this archive, again using xxd last so I can see what it might be. bzcat will extract the contents of a bzip archive to standard out.

Would you look at that, we have a protobuf! I’m not surprised to see this data format; it shows up everywhere! We can parse protobufs with protoc. I will let the reader have fun determining what all is in this protobuf. Might I recommend starting with my article on Apple protobufs.

There we have it, the hoops we have to jump through to get the actual maps data. Thanks Apple, keeping it fun! Here is a quick and dirty recap of my decoding process:

Take the SQLite BLOB ➡️ Extract & Decode base64 ➡️ Remove first 4 bytes using tail ➡️ Unarchive bzip with bzcat ➡️ Decode protobuf with protoc

echo "<base64>” | base64 -D | tail -c +5 | bzcat | protoc --decode_raw

Fortunately, while fun, not all of these apps have crazy base64-bzip-protobuf blobs. Mail, Notes, Safari, Photos, Clock, Weather, and Calendar are relatively easy to visually parse and can provide context to what specifically is happening with the application. Some examples below.

Mail - knowledge_app_activity_mail

Shows access to different email accounts and boxes.

Notes - knowledge_app_activity_notes 

Shows which notes are being edited. This one shows my note detailing what I need for my last vacation.

Safari - knowledge_app_activity_safari

Shows specific Safari browsing data - I’m looking at fancy hotels for my trip!

Photos - knowledge_app_activity_photos

Which photo albums am I viewing, certainly not the one with all my cat pictures. 🤫

Clock - knowledge_app_activity_clock

Did I just cancel my early morning alarm or am I timing how long this meeting is going?

Weather - knowledge_app_activity_weather

Weather may be particularly interesting as it as geo location coordinates embedded. However, they might be someplace I am or am looking to go! You may want to correlate with location data extracted with APOLLO.

Calendar - knowledge_app_activity_calendar

I might be checking meetings or checking how long until the next Objective by the Sea conference is. You should go, it’s in Maui!

maps_requiredstring_calendar.png

3rd Party Apps - knowledge_app_activity

Now we go to the generic App Activity module to review some activities from 3rd party applications. I won’t create modules for every 3rd party application because there are so many. Some applications will have data in knowledgeC.db, some will not.

First up we have my favorite time sink, Twitter. I can see access to specific tweets as well as whichever profile pages you are Twitterstalking.

Dropbox shows access to documents with the Dropbox application.

Venmo shows me paying my debts. The User Activity Required Strings shows interesting information about the contact like their Venmo ID, how many friends they have, friend status, and their Venmo join date. 

And finally, Waze shows me going “Home”.

There is some fantastic and useful information in these activities if you dive into them! 

iOS Location Mapping with APOLLO – Part 2: Cellular and Wi-Fi Data (locationd)

in , ,

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.)

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.

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.

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!

iOS Location Mapping with APOLLO - I Know Where You Were Today, Yesterday, Last Month, and Years Ago!

in , ,

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.

This one is from is from the routined_cloud_visit_inbound_start module. The earliest coordinate is from a few months prior from my trip to Amsterdam to teach FOR518 - Mac and iOS Forensic Analysis and Incident Response.

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. 

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!

Last but not least is the massive amount of data points from the routined_cache_zrtcllocatiomo 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 downtown Portland from the airport is there! (This is the module that produces many, many datapoints. It took patience with Google Earth to even get this screenshot, this is your warning.)

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.