ZENA FORENSICS

When dealing with mobile devices, you need to follow a procedure that includes various stages from identification to reporting. One of the key-point in this process is the  acquisition , where we extract a copy of the data stored in the mobile device.  While evaluating your acquisition method, you should always consider the old but gold rule of the  order of volatility  ( RFC 3227  - " When collecting evidence you should proceed from the volatile to the less volatile "). Our general goal is to obtain a physical dump of the internal memory, from the very first to the very last bit. On most modern smartphone devices, where file-based encryption (FBE) is in use, a full file system is typically our "best evidence".  These extraction methods often rely on vulnerabilities and exploits (either at the hardware or the software level) developed to overcome device security. We use various tools and techniques and sometimes also a physical approach. In some cases, es...

Sometimes you need something open ... This post briefly introduces the teleparser script, whose goal is to parse the Telegram cache4.db . Honestly speaking, I would have done something else, but the coding (better, decoding ) job was born with a real case few months ago. Suppose you have a truly important cache4.db, a file containing every non-deleted and synced chat of the suspect, together with his encrypted p2p chats. Suppose that all the major well known commercial solutions are unable to properly parse that database: or, if able, they provide slightly different results. Again, the db content represents a crucial evidence. On which tools' outputs, if any, would you rely on to report evidences ? That's a classical example where the digital investigator must be able to explain every single bit there ( theoretically, he should always be ). Point is, the cache4.db is not just a simple SQLite database, but it's a SQLite database containing a lot of binaries ...

When doing Mobile Forensics the first and usually the hardest step is to get access to user's data . It depends on the case type, but the so called physical  acquisition is the analyst object of desire. The reason is simple: iOS and Android native backups, respectively adb  and iTunes , contain a subset of user data, because they respect the various apps configurations where they can specify " you can't include me in backups ". Which leads to inconsistent situations like, for example, having WhatsApp data in iTunes backups and not having it in Android adb backups. Not considering WhatsApp, the majority of apps in iOS and Android do not allow their data to be included in backups . In the scenario where  device is unlocked or the lock  code is known (the only scenario considered in this post), the analyst could use the device itself to make the analysis of the installed applications. Anyone who did that at least once knows how uncomfortable is this a...