Processing of an Android device with a solution running on a Windows computer can at times be difficult. Not because of windows, but because of the many different types of Android device profiles available. At last count there were over 12,000 different types of Android profiles from smart phones to tablets to IoT. This can obviously create problems when connecting this device to a solution running on a Windows platform if the particular driver for that device is unavailable. Just Google “<device name> + driver” right? This typically will yield a plethora of results where 99% are either fake or a link to an advertiser. But first, why does an examiner need a driver anyway?
For any communication to occur a driver must be installed whether it be a keyboard, mouse and in this context, a mobile device. Simply, a driver is a piece of software that acts as the middle man – converting communication from a device to a format whereas the Windows OS will understand and move on to the targeted application. Think of it as a translation service. As mentioned, this is a simple explanation for one type of driver, but makes the point – Android ADB drivers are needed for an application to communication via the Windows system to the attached Android device.
An Android device must have ADB available when conducting a logical or physical collection (Of course JTAG and ChipOff are exceptions). Some may say ADB is not needed for a physical collection via USB because the device is locked and the examiner could not switch ADB on. So, since they could not enable ADB it therefore was not enabled and subsequently the data was still extracted. This is type of conjecture is generally false because solutions that utilize a bypass method for Androids are using custom ROMs or images that will enable root and thus ADB = ON. This allows for installation of vulnerabilities to obtain access to the device’s file system that is typically unavailable due to device permissions. So, again ADB is needed to access the device and as such a driver will be needed.
Instead of spending hours looking for a driver, an examiner should install the Universal ADB driver from Koush. This Universal ADB driver is hosted on the Github repository. There is not a need to download the source code and compile the application because an already compiled Windows installer can be located at the bottom of the page. This Universal ADB driver is updated continuously by Koush and has been used in many of my examinations when ADB drivers could not be found elsewhere. Koush is also the developer of the ClockworkMod that many mobile forensic solutions physical collection techniques are based upon and a frequent contributor to the Android community. This Universal driver is a package that contains the vendor (VID) and product IDs (PID) that have been rolled into a single driver and once installed are registered within the Windows system. When the examiner plugs in a device, ADB will now be recognized when previously Windows was unable to find a suitable driver. With ADB now available the device can be collected with the tool of choice.
Enjoy and Good Luck!
