Why Chipsets rather than Devices?

Why do we specify support for chipsets instead of devices?

We are sometimes asked why we mention support for chipsets rather than specific mobile devices. We thought it would be helpful to have a more detailed explanation of the reasons.

Background

A mobile device “chipset” is the set of electronic components on the integrated circuit board that manages the data flow between the processor, memory and peripherals. It is usually constructed as a complete system on a chip.

A chipset combines a memory chip with software embedded during manufacture called a ROM (read only memory). ROM is the non-volatile memory retained when the power is removed, embedded on the chipset and can’t easily be changed.

The boot chain of mobile devices generally consists of a central processor which contains, and initially boots from, read only memory. Followed by later stage boot loaders and the operating system contained in flash memory. For each stage in the boot chain of a mobile device there may be opportunities for loading code or reading out flash memory contents directly.

A bootloader is the software code executed before the operating system runs, designed to put the system in a state in which it can perform its primary function. Boot loaders package the instructions to boot up an operating system kernel and most of them also have their own debugging or modification environment. This usually requires hardware initialization coupled with the correct image to load from flash. Because of its key role, the bootloader is usually installed in a part of the Flash that is protected from accidental erasure or corruption. Bootloaders are however, replaceable and cheaper to replace compared to ROMs.

The mobile operating system (OS) is the software which acts as the primary platform on which other application programs are executed.

The boot sequence generally begins with the ROM. The ROM then passes control to the Flash memory which contains a sequence of boot loaders. The first stage bootloader is always attached to the Chipset. The total number of bootloaders is variable, but all bootloaders have to run to activate the operating system. Security issues at each stage will determine which level may present the greatest opportunity for access to the device and eventual data recovery. But it is prudent to look at the chipset or operating system in order to gain the advantage of covering multiple mobile devices.

Rationale

To save on component costs many vendors have implemented similar chipsets across a wider range of modern devices in an effort to speed up development and offer lower prices to customers.

Asian chipsets manufacturers like MediaTek and Spreadtrum etc. have been particularly successful and that means many vendors now have similar chipsets embedded in their devices. For example both Nokia and Motorola now buy MTK chipsets, so there is an obvious advantage in having a forensic solution cutting across both vendors. Thus tackling chipsets rather than just devices opens up greater opportunities for device support in XRY.

Our research and development teams have discovered that many of these chipsets, whilst capable of secure modes, generally don’t have them implemented. For those chipsets which are accessible, our engineers naturally take advantage of the opportunity.

Where security measures are implemented, the bootloader level is the second stage of research to seek access to a group of devices. XRY communicates with the bootloader or firmware installed on the device to ascertain its status. Some manufacturers have a built in debug functionality which allows us to read out the memory by sending code to the bootloader.

The Operating System level is the third line of attack. This is in most cases the most difficult option as more complex security systems are likely to be active compared to both the chipset and bootloader levels. Conversely gaining access into this level will of course give a much wider range on support for devices. A good example is the Android Generic profile in XRY which can be used on most Androids irrespective of the version, chipset and manufacturer.

Conclusion

The three levels of attack produce solutions which in some cases may overlap. In a nutshell, all three solutions are dependent on each other and the famous “It depends” answer is still applicable.

MSAB documents support for chipsets when our engineers find opportunities at that level which cut across most devices.If a chipset is supported irrespective of the Phone vendor and operating system, XRY can usually extract the data.