Wednesday 21 August 2019

iOS 12 - Delivered Notifications and a new way to parse them

In iOS 12, Apple went with a different way of storing a user's notifications than I was previously used to. In the past, it wasn't that difficult to track a user's notifications that were still hanging around on the device. It's not impossible right now, but boy is it painful. At least until a friend helped to make it easier for us.

Location: 
First off, you'll need a full file-system style image of an iOS device to dive into these. You'll find the notifications under the path: 
\private\var\mobile\Library\UserNotifications\

Inside this folder, each application that generates notification is then listed by its BundleID as seen here: 

Inside each folder, there may or may not be several property list files listed out by different categories. The files that tend to contain the most relevant data in my experience are the DeliveredNotifications.plist file, the AttachmentList.plist file and the Attachments folder. 



Okay. Time for the bad news. These property list files are NSKeyedArchiver style plist files. Yuck. If you've never dealt with these plist files before I recommend checking out Sarah Edward's blog about them here: https://www.mac4n6.com/blog/2016/1/1/manual-analysis-of-nskeyedarchiver-formatted-plist-files-a-review-of-the-new-os-x-1011-recent-items?rq=nskeyed. I'll wait.

Super annoying, right?! Anyway, I'm going to slightly cheat here. The awesome developers over at Magnet Forensics cooked up a tool that allows me to flatten these property list files into something a little bit more manageable. They're still pretty terrible to deal with though so I'll try to keep this at a several thousand foot view instead of getting deep into the weeds.

I'm going to start with the Delivered Notifications file. In this case, I'll be looking at the one for the Skype for Business app because it's chat data that I had laying around in my phone. To start, each DeliveredNotifications.plist contains a set of keys that will talk about the notification can do on the device. This will include information such as if the the notification should ignore DnD, if it should play a sound, if it should ignore the ringer switch, display on CarPlay, and some date/time information including when the notification was generated.


I'm going to focus on two keys listed about. Keys [3] and [19] which reference the AppNotificationMessage and the AppNotificationCreationDate. Once you can map out each notification within the file, we can start to find the data about the notification. 


In the screenshot above, you can see some information such as key [263] which is the actual message display text. In this case, it's a message from someone who wants me to call them. The key [272] references a time which after some manual validation showed that this is when the notification was delivered to the phone. 


Each notification is going to look at little different potentially but follow the same pattern that is laid out in the plist. 

Moving to a different app, let's look at AttachmentList.plist and the Attachments folder. In this example from my Amazon app on my phone, you can see some attachments that are listed out for the notifications. I'm starting with the DeliveredNotifications.plist again for this app. 


In the upper screenshot you can see the delivered notification text and a timestamp. Below you'll get a listing to the attachment that's part of the notification.


The AttachmentList.plist also lists out all of the attachments you can find in the Attachments folder. Not entirely sure why they're listed again, but they're there. 

Inside the attachment folder, we can use that file:/// path to find the actual file involved. 


After showing some of this to Alexis Brignoni (https://abrignoni.blogspot.com) he was able to come up with a great parser that can pull out some really relevant information from these data points into a great Triage report. I'll let him cover the ins and outs of how its used but I'll show some of the info we were able to pull out here. 

In the two examples attached we have the Instagram app's notifications and some Gmail notification data. 


Here you can see a user tagged me in a post. Instagram is letting me know that I've been mentioned. This notification includes the person who tagged me, lets me know it was a "mentioned_comment," has time/date values, and even the linked path to the attachment of the photo that was posted to the service online and locally on my device. 

Next for Gmail: 

In this one, a user "badmanbarrow1080@gmail.com" received an email about other Google Maps features they shouldn't be missing out on. Thanks for the info Google!

Alexis' tool allows us to strip out a lot of the data from these Plist files quickly and even hide some of the extra rows. You can check out his blog post on it here: https://abrignoni.blogspot.com/2019/08/ios-12-notifications-triage-parser.html and go grab the tool from his Github here: https://github.com/abrignoni/iOS-Notifications-Parser

Future Research: 
The more I did into this the more I find there's some data that we're missing here. Not all services seem to be populating into this area. For example, I had a notification from an iMessage sitting on the screen which doesn't show up anywhere. There are also some PendingNotification.plist files that I haven't found much on yet but I'm hoping can lead us to some other notifications. 

Hopefully this info is helpful to someone out there, and a big thanks to Alexis for running with this and being way more programmatically inclined than I am to work us all up a tool to use!

No comments:

Post a Comment