![]() Some applications use simple, flat text fields, whereas some others use base64 to encode other binary structures (YouTube as an example encodes a further protocol buffer in these fields). A good number of applications that we’ve encountered make use of JSON (Tumblr and Facebook come to mind) which makes processing the records nice and structured. ![]() Up until this point, the data structures we encounter will be consistent regardless of the application they relate to, but the contents of the keys and values within 0x3A objects will be specific to the particular application that they relate to. In that object we should find, amongst other items, a string entry with tag number 0x2A which gives the name of the package that the message is associated with, and one or more objects with tag number 0x3A which will each contain a string key and value – the message being sent from the server to the client application. The main data of interest lives within the first object we encounter with tag 0x12. But the format has enough context about the data stored inside, so by using an appropriate viewer we are able to reveal the structure of the data. Protocol buffers are generated by custom serialisation code so they aren’t really meant to be read by other applications. The value of the record will be a protocol buffer ( ): an object serialisation format which originated at Google, so it’s no great surprise to see it here. Not that this matters for forensic recovery: if we have a viewer or software library ( ) which can view the deleted records, we can go back and pick up the deleted keys from back when they were live. As the name of the database suggests: this database is a queue of messages waiting to be delivered and in most cases the message will be delivered pretty rapidly – emptying the queue as it does. As you can see in the screenshot above, when we lay the records out sequentially, a record with a key arrives into the database and then is immediately deleted – as it gets forwarded to the appropriate app. In LevelDB, records are arranged as a log of changes to keys. This artefact is indeed a LevelDB ( ) data store, which is contained within this folder. The final acronym is “ldb” which, if you have followed along with my recent posts, you may already have guessed, is short for “LevelDB”. This isn’t messaging as in chat – although it can certainly be used in the development of chat apps – rather it is messaging between a server and an app (possibly running in the background). One of those APIs is “fcm”, which stands for Firebase Cloud Messaging ( for more details). From a user’s perspective, this is the bundle of Google apps that is included with the official version of Android used by Google and its partners (which includes most major hardware manufacturers) for developers though, GMS also provides a bunch of APIs (Application Programming Interface) to make developing apps easier in a number of areas. First the “gms” in the package name: “GMS” here is Google Mobile Services ( ). You can find the artefact in question on the data partition under: /data/data//files/fcm_queued_messages.ldb.īefore we get into the bits and bytes, we should take a moment to expand some acronyms in the path above. In this blog I’ll attempt to set out what this artefact is, why it exists in the first place, and how the data is structured. Amongst other apps, we’ve seen this “conduit” being used by Facebook, Tumblr and YouTube to name just a few. As the data travels along this path, it can leave traces behind that can give us a great second opportunity to recover said data. On Android, a great deal of app data being sent from the cloud may be arriving at each app through a shared conduit: FCM Queued Messages.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |