Android DDMS Vulnerability

Android DDMS Vulnerability

A suggested in-memory patch solution to the DDMS vulnerability is reported in this article:

https://securityledger.com/2013/07/security-start-up-university-team-on-android-patch-app/

The article states "The flaw is located in an Android component known as the Dalvik Debug Monitor Service (or DDMS), the virtual machine that runs software on Android devices. The vulnerability affects almost all Android devices in use, could allow a malicious actor to modify a legitimate, signed Android application without affecting the application’s cryptographic signature. That would prevent Android from noticing the changes when the application is installed."

So to prevent any new threat occuring ReKey can help you do this. However, what is the solution where threat already existed on the Android phone prior to the in-memory patch being installed? Are there any known affects (exploits that add or alter data or cause call events etc)? Could those 'affects' impact on the weight given to evidence extracted and harvested from a particular smart phone?

How relevant is the above to device examination?   Computer forensic examiners spend hours and days sifting through data and studing how a program installs, executes and stores activity generated by use of a program. Smart phones are now highly complex radio communication and electronic devices running a multitude of internal operating programs, user access programs fashioned to the device, interfaces to connect to other devcies and, all importantly, programs to communicate using radio transmission/receiver technologies GSM, W/CDMA, LTE, Wi-Fi, Bluetooth/IRDA, RFID/NFC.

In the early days of mobile phone examination the SIM Card was the focus of attention as little occurred by way of the handset itself. Evolved feature handsets have transformed mobile phones to smart phones and processes of acquiring data have largely become mechanical with plug-in tools pumping out data in production line fashion. Invariably examiners cannot rely simply one one tool but require a toolbag of tools. These tools in themselves are still not enough as the art and skill of interpretation as to the cause and effect and meaning of data are not present in the tools. Sure, tools may show e.g. a (static/active) graph of internet activity of a smart phone once data has been harvested from it but does the tool confirm whether the smart phone automated that process or whether it involved human intervention to cause the intenet activity?

Evolved, too, has the (U)SIM. Which means understanding of what is actually stored on it and applications that run from it, the (U)SIM, cannot be ignored when it comes to automated processes and human intervention.

Image - SIM Toolkits (STKs): Proactive SIM enables and allows a SIM to issue commands and action responses and thus may be susceptable to generating events in a manner and form that needs to be understood (see: GSM11.14).

The DDMS vulnerability reminds us that over-reliance on a tool simply to extract and harvest data and then present the data in a eye-pleasing format is not enough. Understanding the program/s and apps on a smart phone and in a USIM, its genuineness and originality, how data and records are caused to be generated and the interpretation of the records and data is now where we are at. Production line (bang it on, bang it out) recordings of only call activity, phonebooks, texts, IM messages, graphics, internet etc is fast becoming an incomplete methodology for smart phone and USIM examination.