From Smashed Screens to Smashed Stacks: Attacking Mobile PhonesUsing Malicious Aftermarket Parts

Omer Shwartz, Guy Shitrit, Asaf Shabtai, Yossi Oren

Ben-Gurion UniversityBeer-Sheva, Israel

omershv@post.bgu.ac.il, shitritg@post.bgu.ac.il, shabtaia@bgu.ac.il, yos@bgu.ac.il

Abstract—In this preliminary study we present thefirst practical attack on a modern smartphone whichis mounted through a malicious aftermarket replace-ment part (specifically, a replacement touchscreen).Our attack exploits the lax security checks on thepackets traveling between the touchscreen’s embed-ded controller and the phone’s main CPU, and isable to achieve kernel-level code execution privilegeson modern Android phones protected by SELinux.This attack is memory independent and survives datawipes and factory resets. We evaluate two phonesfrom major vendors and present a proof-of-conceptattack in actual hardware on one phone and an em-ulation level attack on the other. Through a semi-automated source code review of 26 recent Androidphones from 8 different vendors, we believe that ourattack vector can be applied to many other phones,and that it is very difficult to protect against. Similarattacks should also be possible on other smart devicessuch as printers, cameras and cars, which similarlycontain user-replaceable sub-units.

1. Introduction

Consumer devices often have components which canbe replaced by the user or by third-party service centers.These components are generally called field-replaceableunits, or FRUs. Examples of devices with FRUs includeinterface cards for routers; touch screen, battery andsensor assemblies for mobile phones; ink cartridges forprinters; batteries for health sensors; and so on. Thesereplaceable units typically have their own microproces-sors and code spaces, and use a very strictly definedhardware or software API to communicate with thedevice’s main secure CPU, as shown in Figure 1. Mostsensors and hardware peripherals communicate oversimple interfaces such as I2C (Inter Integrated Chip) andSPI (Serial Peripheral Interface), these interfaces arevery lightweight and offer no embedded authenticationmechanisms or error detection capabilities [1].

Programs running on a smart device’s main CPUinterface with the FRUs using device drivers. These

User Device

Main Logic Board

Auxiliary Board

Main CPU

Aux. CPU

Internal Bus

Aux. Memory

Main Memory

Figure 1. A user device with a field-replaceable accessory board.

drivers often run in privileged mode with kernel-levelpermissions. In most cases, FRUs are manufactured bythird-party original equipment manufacturers (OEMs).Thus, the source code for FRU drivers is supplied bythe OEMs to the phone manufacturers, and the phonemanufacturers then proceed to integrate this code intotheir own source code, making minor adjustments toaccount for minute differences between phone modelssuch as memory locations, I/O bus identifiers, etc. As weshow in Section 3, these minor tweaks and modificationsmake the process of creating and deploying patches forthese drivers a very difficult endeavor.

In contrast to network or USB drivers, FRU driversare typically written under the assumption that an au-thentic, fully trusted hardware component is present onthe FRU side. As a result, very few integrity checks areperformed on the communication between the FRU’sembedded controller and the phone’s main CPU. Weaim to show that the assumption of a benign FRU is avery risky one to make.

In the remainder of this paper we focus our discus-sion on replacement touch screen assemblies. Accordingto a global survey carried out in 2015 by Motorola Mo-

bility, around 21% of global smartphone users currentlyhave a cracked or shattered phone screen [2]. Assuminga very conservative estimate of two billion smartphonesin the world, this means there are more than 400 millionphones worldwide with a cracked screen. For compari-son, the Mariposa botnet, which was the largest everrecorded, consisted of about 10 million computers [3].While some users replace their phone screens using au-thentic hardware at the original vendors’ laboratories,most touchscreen replacements are performed in third-party repair shops. These repair shops often use thecheapest possible screens and thus often provide, know-ingly or unknowingly, counterfeit or unbranded sub-units. As recently shown by UL [4], a large proportion ofpresumably authentic replacement hardware purchasedon third-party marketplaces such as Amazon or eBay iscounterfeit.

In our attack model, we assume that a user hasreplaced her phone’s touchscreen with a counterfeit, ma-licious component. Such component may include tam-pered firmware or an embedded malicious IC. Quitetrivially, this exposes the user to the risk of key-loggingor malicious impersonation. However, as we show in thispaper, this counterfeit component can also abuse theCPU-FRU communication bus and achieve kernel-levelcode execution privileges on the phone.

Our contributions are as follows: we show a proof-of-concept of a physical environment with stock firmwarebeing coerced into running code from an arbitrary mem-ory address; we also show an end-to-end attack in aphysical environment with modified software allowingan app to gain root privileges and disable securitymeasures; and we present an analysis highlighting thedifficulty in protecting today’s devices.

2. The Attack

The objective of our attack was to cause a stockphone running unmodified software to execute arbitrarycode by sending malicious inputs through its touch-screen interface. Our initial analysis used a high-endAndroid phone currently on sale by a major US vendor1.

2.1. Attack Setup

Our attack setup consists of two parts, a softwareassisted environment where a full end-to-end attack isshown and a pure physical setup where a preliminaryattack is achieved.

2.1.1. Software Assisted Environment. For thesoftware-assisted hardware proof-of-concept, we usednormal production configuration used in the stockfirmware present on the device, based on Android 6.0.1.

1. The phone’s vendor and model, as well as full details on thechain of compromises we used to attack it, will be disclosed afterthe conclusion of a responsible disclosure process.

Figure 2. Exposing the mobile phone’s touchscreen interface. Inset:wires soldered onto the touch controller communication connec-tion.

We then modified the kernel so that it includes over-loaded functions that replace the communication APIbetween the touchscreen driver and the touchscreen.These functions allow intercepting and injecting of pack-ets in the scope of the driver-touchscreen interface. Noother parts of the kernel were modified, allowing us tomimic a tampered touchscreen module with minimalkernel modifications. This setup was then tested bothin emulation and on the actual phone hardware.

2.1.2. Pure Physical setup. For the full hard-ware proof-of-concept, an identical phone running stockfirmware was disassembled, and the touchscreen con-troller communication bus was made accessible, asshown in Figure 2. A programmable microcontrollerwas then placed on the communication bus betweenthe touchscreen and the CPU, allowing custom-craftedresponses to be sent to the CPU.

2.2. Preliminary Results

Using our software-assisted hardware setup, we wereable to cause several driver software faults which in-troduced a critical vulnerability into the Android ker-nel. The vulnerability discovered was exploited usinga Return Oriented Programming (ROP) chain (Fig. 3)designed for the ARM64 architecture. This exploitationchain was used to cause a second vulnerability in a user-facing interface. The next step in the attack involvedlaunching an auxiliary user-mode app with no specialpermissions. This app was capable of continuing the at-tack by exploiting the new vulnerability via a system call

Figure 3. Depiction of the ROP chain resulting in modification ofkernel write-protected memory. Gadgets one, two, and three loadpredefined memory addresses and values from the stack and resultin a function call to mem_text_write_kernel_word(), a functionthat writes over protected kernel memory.

that is normally benign, with the end result of gainingroot privileges while disabling the SELinux protectionmechanism. Note that our attack model, which assumesa compromised touchscreen, explicitly allows the at-tacker to perform unauthenticated actions on behalf ofthe user.

Using our full hardware-based setup, it was possi-ble to send the custom crafted corrupted data duringthe boot process while injecting data that exploits twovulnerabilities within the device driver. This caused akernel thread to execute an arbitrary memory addressand crash.

3. Driver and Peripheral Diversity in theAndroid Mobile Phone Landscape

Since our attack used a combination of first-partyand OEM code, we were interested in testing the speci-ficity of these vulnerabilities to specific phone models. Inorder to investigate this question systematically, we pro-duced a driver-level inventory of several popular hand-sets, and observed the diversity of today’s peripherallandscape.

As a consequence of the open-source public licenseused for Android and for some of its subcomponents,phone vendors are required to release the source code forvarious Android phones they produce. We downloadedand reviewed the source code of 26 recent Androidphones from eight vendors and mapped the features anddrivers employed by the devices. This allowed us to ob-serve the diversity and uniqueness of the drivers used aswell as assess the difficulty in auditing and maintainingtheir security. For each phone, the most recent versionof the kernel source code was downloaded from themanufacturers website. The default configuration waslocated and loaded into a script based on kconfiglib.py[5] and the functional drivers were listed.

The actions above allowed us to determine the ven-dors of the drivers and compare drivers across phonesin the purpose of finding identical versions. As shown in

Phone model Touch-screen

NFC ChargerIC

Battery Wire-less

ChargerHTC Desire 626 Synt1,

Atmt1NXPn1 Sumc1 Maxb1 —

HTC One A9 Synt2 NXPn2 Sumc2 HTCb1 —HTC One M9+ Synt3

Maxt1NXPn3 Sumc3 HTCb2 —

Huawei Honor 5X Synt4 NXPn4 Huac1 TIb1 —Huawei Nexus 6P Synt5 *NXPn5 Quac1 Quab1 —Lenovo K3 Note Medt1 — Medc1 Medb1 —Lenovo K5 Note Medt2 Quan1 Sumc4 Medb2 —

Lenovo Vibe K4 Note Medt3 Medn1 Texc1 Medb3 —LG Nexus 4 E960 Synt6 Bron1 Intc1 TIb2 TIw1

LG Nexus 5 Synt7 Bron2 Sumc5 TIb3 TIw2LG G3 Atmt2 NXPn6 Sumc6 *TIb4,

Maxb2TIw3

LG G4 Synt8 NXPn7 Sumc7 Maxb3 —LG Nexus 5X Synt9 *NXPn5 Quac2 Quab2 —

Motorola Nexus 6 Atmt3 Bron3 Sumc8 TIb5,Maxb4

Motw1

Samsung Galaxy S5 Atmt4 NXPn8,Bron4

Sumc9 TIb6,Maxb5

—

Samsung Galaxy S6 *STMt1 Samn1 *Maxc1 *Maxb6 Texw4Samsung Galaxy S6 edge *STMt1 Samn2 *Maxc1 *Maxb6 Texw5

Samsung Galaxy S6 edge+ STMt2 Samn3 *Maxc1 *Maxb6 Texw6Samsung Galaxy S7 Samt1 NXPn9,

Samn4Maxc2 Maxb7 IDTw1

Samsung Galaxy S7 edge Samt2 NXPn10,Samn5

Maxc3 Maxb8 IDTw2

Sony Xperia Z2 Maxt2 NXPn11 Quac3 *TIb4,Maxb9

—

Sony Xperia M4 Aqua Synt10 NXPn12 Quac4 Sumb1 —Sony Xperia M5 Synt11 NXPn13 Medc2 Medb4 —Sony Xperia Z5 Synt12,

Atmt5NXPn14 Sumc10 TIb7 —

Sony Xperia E5 Medt4 Medn2 Medc3 Medb5 —Sony Xperia XA Medt5 Medn3 Qnoc1 Medb6 —

Table 1. Driver survey. Digits indicate unique version ofdriver. Drivers shared by multiple phones are marked by

*. Vendors: Mot: Motorola Mobility; Med: MediaTek;Bro: Broadcom; TI: Texas Instruments; Sam: Samsung;Qno: Qnovo; Hua: Huawei; Int: Intersil; Sum: Summit

Microelectronics; Qua: Qualcomm; Syn: Synaptics; STM:STMicroelectronics; Atm: Atmel; Max: Maxim Integrated.

Table 1 the output of our survey revealed a vast varianceof peripheral vendors across the inspected devices. Ofthe 89 different drivers we evaluated, only three wereused in two or more phone models, and only two wereused on three or more phone models. Most of the driverswere unique to their respective device and only a handfulof drivers identical among different devices were found.

4. Discussion

We showed how a malicious payload delivered by atouchscreen can let an unprivileged app obtain unlimitedaccess to system resources and information on a smart-phone. In this section we will discuss the ramificationsof such attacks and review both previously explored andunexplored defenses against threats of this kind.

4.1. Analysis of the Attack Surface

There are several unique advantages to this attackmethod, when compared to traditional malware. First,the attack can be carried out on a phone running a stockoperating system, and without having the user performany action. This makes it difficult to protect againstthe attack by corporate or carrier-level security policies,or by user education. Second, the attack is performedin a way that leaves no persistent memory footprints.Thus, it is impossible for the kernel or for any antivirussoftware to detect the malicious activity. Third, since the

attack is located outside the phone’s standard storage,it can survive phone factory resets, remote wipes, andfirmware updates.

Attacks based on malicious hardware can be dividedinto two different classes. First-order attacks interactwith the phone in the ways a standard user would, butwithout the user’s consent. In the case of a malicioustouchscreen, the malicious peripheral may log the user’stouch activity, or impersonate user touch events in orderto call a premium phone number or install malware.Second order attacks go beyond exchanging properly-formed data, and attempt to cause a malfunction inthe device driver and compromise the operating systemkernel. While the results shown here present a successfulsecond order attack, it is still interesting to investigatefirst order methods on their own, and especially interest-ing to investigate the combination of both first order andsecond order attack, in which simulated user interactionis used to enhance a kernel exploit.

The reality we discovered, where every phone modelcontains a unique driver/version combinations, paintsa problematic picture. With thousands of smartphonevarieties being used by customers all over the world,maintaining their security is a daunting task.

4.2. Possible Countermeasures

Devices today are being protected from maliciousUSB or Ethernet connections by means of encryption,blocking, authentication and active detection of suspi-cious traffic. Such methods can be modified and used onother protocols for communication with device peripher-als. Due to the dynamic evolvement of smartphones andsmartphone drivers, possible countermeasures should beas generic and adaptive as possible. Preventive coun-termeasures may include signature verification of theperipheral and related drivers, e.g. using certificates.Detective countermeasures can be in the form of anintrusion detection component that analyzes the com-munication between the replaceable units and drivers ina trusted manner and detects anomalies.

4.3. Related Work

Smartphones have been a growing target for mali-cious attacks in the past decade. Some of these attacksare caused by adversaries who abuse the permissionsthey are explicitly or implicitly given by the user. At-tackers can also use various software flaws to maliciouslyincrease their permission level, and thus increase theamount of damage they are capable of causing. Theseattacks usually result in money theft, exfiltration ofprivate data, aggressive advertising and fraud [6]. Toolsand methods for counteracting existing and upcomingmalware are being constantly developed and reviewed[7], [8], [6]. While there is a growing focus recently on onthe hardware aspect of smartphone security, most secu-

rity papers still consider the smartphone’s hardware asinviolate and are only examining malware-based attacks.

One well-known hardware interface for attacks isthe Universal Serial Bus (USB). USB is a widespreadstandard defining the physical interface and protocolsfor communication between electronic devices over mul-tiple profiles. The versatility of USB requires carefulimplementation and broad restrictions against abuseand attacks. Several vulnerabilities have been found inthe past that affect Android based phones and allowan attacker to use USB for gaining privileged accessto a vulnerable device [9]. Android security patches arereleased on a monthly basis. A review of 326 AndroidCVEs (Common Vulnerabilities and Exposures) patchedwithin the last 18 months shows that at least 22.7% (74items) take place in driver context [10].

The concept of exploiting and defending internalhardware interfaces has been discussed before in thecontext of industrial applications on common interfacessuch as I2C, and solutions have been suggested [11].Today’s reality of replaceable components exposes andcompromises those internal interfaces that were onceprotected by being a part of a non-serviceable system.

To the best of our knowledge, ours is the first at-tempt to attack portable devices by means of a labreplaceable malicious hardware component.

5. Conclusions and Future Work

The diversity that exists in the mobile phone pe-ripheral landscape, combined with the high potentialfor damage, both via first-order attacks and via second-order attacks, is a serious concern which has not beenaddressed sufficiently by the security community. Afterproving the feasibility of kernel exploitation throughhardware communication channels with replaceable pe-ripherals we intend to complete the demonstration witha pure hardware attack vector. A device will be designedthat when attached to a smartphone touchscreen con-troller is capable of committing an attack on the driverand exploiting a stock device kernel. Further analyseswill be performed on additional phone models and theirvulnerabilities assessed. It is our intention to also in-vestigate possible countermeasures for such attacks andcompile a set of conclusions and designs that will helpprotect both current and future devices. The rich setof countermeasures which already exists for securinguntrusted interfaces such as network and USB shouldalso be considered for addressing this problem domain.

References

[1] NXP, I2C-bus specification and user manual, Apr.2014. [Online]. Available: http://www.nxp.com/docu-ments/user_manual/UM10204.pdf

[2] Motorola Mobility, “Cracked screens and broken hearts - the2015 motorola global shattered screen survey.” [Online].Available: https://community.motorola.com/blog/cracked-screens-and-broken-hearts

[3] Industrial Control Systems Cyber Emergency Re-sponse Team, “Advisory (icsa-10-090-01) - mariposabotnet.” [Online]. Available: https://ics-cert.us-cert.gov/ad-visories/ICSA-10-090-01

[4] UL, “Counterfeit iphone adapters.” [Online]. Avail-able: http://library.ul.com/?document=counterfeit-iphone-adapters

[5] U. Magnusson, Kconfiglib - A flexible Python2/3 Kconfig parser and library. [Online]. Available:https://github.com/ulfalizer/Kconfiglib

[6] P. Faruki, A. Bharmal, V. Laxmi, V. Ganmoor, M. S. Gaur,M. Conti, and M. Rajarajan, “Android security: a survey ofissues, malware penetration, and defenses,” IEEE Commu-nications Surveys & Tutorials, vol. 17, no. 2, pp. 998–1022,2015.

[7] A. Arabo and B. Pranggono, “Mobile malware and smart de-vice security: Trends, challenges and solutions,” in 2013 19thInternational Conference on Control Systems and ComputerScience. IEEE, 2013, pp. 526–531.

[8] G. Suarez-Tangil, J. E. Tapiador, P. Peris-Lopez, and A. Rib-agorda, “Evolution, detection and analysis of malware forsmart devices,” IEEE Communications Surveys & Tutorials,vol. 16, no. 2, pp. 961–987, 2014.

[9] S. Angel, R. S. Wahby, M. Howald, J. B. Leners, M. Spilo,Z. Sun, A. J. Blumberg, and M. Walfish, “Defending againstmalicious peripherals with cinch,” in 25th USENIX SecuritySymposium (USENIX Security 16). USENIX Association.

[10] Google, Android Security Bulletin. [Online]. Available:https://source.android.com/security/bulletin

[11] J. Lázaro, A. Astarloa, A. Zuloaga, U. Bidarte,and J. Jiménez, “I2csec: A secure serial chip-to-chipcommunication protocol,” J. Syst. Archit., vol. 57,no. 2, pp. 206–213, Feb. 2011. [Online]. Available:http://dx.doi.org/10.1016/j.sysarc.2010.12.001