EXAMENSARBETE INOM DATATEKNIK,

GRUNDNIVÅ, 15 HP
STOCKHOLM, SVERIGE 2021

Ethical Hacking of Android Auto in

the Context of Road Safety

ALEXANDER PALM

BENJAMIN GAFVELIN

KTH
SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP
© 2021 Alexander Palm and Benjamin Gafvelin
 Abstract | i

Abstract
With a more than ever increasing demand to interconnect smartphones
with infotainment systems, Android Auto has risen in popularity with
its services used in modern vehicles worldwide. However, as users
progressively connect their smartphones to in-vehicle infotainment systems,
the opportunity for malicious actors to endanger and access private
data of Android Auto users advances as well. The goal with this
thesis is to determine how secure Android Auto is for road use. The
main research question is to figure out if Android Auto is susceptible
to attacks that exploit certain vulnerabilities in the Android operating
system.The research question was answered by creating several proof-of-
concept attacks on Android Auto using an emulated infotainment system
with mobile devices. An investigation was also conducted regarding
the application’s communication channel between the mobile device and
infotainment display. Results of this thesis demonstrate that several
attacks are substantially severe to endanger drivers on the road. There
is a great risk of successful exploits when running Android Auto locally
on the phone without a connection to the infotainment system, and a
lesser risk when connected to the infotainment system. Intercepting
communication in the USB channel revealed an encryption algorithm
whose version has published exploits and can be cracked to potentially
exploit Android Auto.

Keywords
Android Auto Security; Infotainment System; Road Safety; Penetration
Testing; Malicious Apps; Android Security;
ii | Abstract
 Sammanfattning | iii

Sammanfattning
I takt med en evigt ökande efterfrågan på att sammankoppla smart-
telefoner med infotainmentsystem, har allt fler börjat använda Android
Auto i sina fordon världen över. En bieffekt av att allt fler sammankopplar
sina mobiler till infotainmentsystem, är att det leder till fler möjligheter
för illvilliga parter att stjäla privat data och sätta Android Auto-
användares liv i fara. Målet med denna avhandling är att fastställa hur
säkert Android Auto är i avseende till vägsäkerhet. Den huvudsakliga
forskningsfrågan är att lista ut om Android Auto kan attackeras av
attacker som utnyttjar sårbarheter i Android operativsystemet. Forsknings-
frågan besvarades genom att skapa flertal konceptattacker mot Android
Auto användandes av ett emulerat infotainmentsystem och mobiltelefoner.
En utredning utfördes även gällande applikationens kommunikationskanal
mellan telefonen och infotainmentskärmen. Resultatet från denna av-
handling demonstrerade att många attacker är tillräckligt allvarliga för
att äventyra trafikanternas säkerhet. Det finns en avsevärd risk för
framgångsrika attacker när Android Auto körs lokalt på telefonen utan
en USB koppling till infotainmentsystemet, och en liten risk när telefonen
är kopplad till infotainmentsystemet. Avlyssning och uppfångning av
kommunikationen i USB kanalen visade att en krypteringsalgoritm vars
version har existerande sårbarheter kan avkrypteras och utnyttjas för att
potentiellt attackera Android Auto.

Nyckelord
Android Auto Säkerhet; Infotainment-system; Vägsäkerhet; Penetrationstest;
Skadliga Appar; Android Säkerhet;
iv | Sammanfattning
 CONTENTS | v

Contents

1 Introduction 1
1.1 Similar Platforms and Competitors . . . . . . . . . . . . 3
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . 4
1.4 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Scope of Research . . . . . . . . . . . . . . . . . . . . . . 5
1.7 Contributions . . . . . . . . . . . . . . . . . . . . . . . . 5
1.8 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.9 Vulnerabilities in the USB Connection . . . . . . . . . . 6
1.10 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . 7

2 Method of research 9
2.1 Research Methodology . . . . . . . . . . . . . . . . . . . 9
2.1.1 Problem Identification and Motivation . . . . . . 9
2.1.2 Define the Objectives for a Solution . . . . . . . . 11
2.1.3 Design and Development . . . . . . . . . . . . . . 11
2.1.4 Demonstration . . . . . . . . . . . . . . . . . . . 11
2.1.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . 11
2.1.6 Communication and Contribution . . . . . . . . . 12
2.2 Ethical Approach . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Authorization . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Non-disclosure . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Confidentiality . . . . . . . . . . . . . . . . . . . 13
2.2.4 Boundaries . . . . . . . . . . . . . . . . . . . . . 13

3 Related Research 15
vi | Contents

4 Attacks and Attack Environment 17

4.1 Attack Environment . . . . . . . . . . . . . . . . . . . . 17
4.2 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1 Task Hijacking . . . . . . . . . . . . . . . . . . . 19
4.2.2 Intent Storm . . . . . . . . . . . . . . . . . . . . 20
4.2.3 SoundBlast . . . . . . . . . . . . . . . . . . . . . 21

5 Results 23
5.1 Task hijacking . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Intent Storm . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 SoundBlast . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Discussion 25
6.1 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1 Task Hijacking . . . . . . . . . . . . . . . . . . . 25
6.1.2 Intent Storm . . . . . . . . . . . . . . . . . . . . 26
6.1.3 SoundBlast . . . . . . . . . . . . . . . . . . . . . 27
6.1.4 CVSS 3.0 . . . . . . . . . . . . . . . . . . . . . . 28
6.2 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Research Methodology . . . . . . . . . . . . . . . . . . . 29

7 USB Investigation 31
7.1 Raw Packet Analysis . . . . . . . . . . . . . . . . . . . . 31
7.2 Android LogCat Analysis . . . . . . . . . . . . . . . . . . 32
7.3 TLS Decryption . . . . . . . . . . . . . . . . . . . . . . . 33

8 Future work 35

9 Conclusion 37

References 39

A CVSS3 Vector String 43

 List of acronyms and abbreviations | vii

List of acronyms and abbreviations

ADB Android Debug Bridge

CVSS Common Vulnerability Scoring System

DHU Desktop Head Unit

DOS Denial-of-Service

IHU Infotainment Head Unit

MitM Man-in-the-Middle

SDK Software Development Kit

viii | List of acronyms and abbreviations
 LISTINGS | ix

Listings

4.1 Detect when USB is plugged in . . . . . . . . . . . . . . 18

4.2 Detect when Android Auto is running . . . . . . . . . . . 18
4.3 Task Hijacking manifest.xml . . . . . . . . . . . . . . . . 19
4.4 Intent Storm . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5 SoundBlast . . . . . . . . . . . . . . . . . . . . . . . . . 21
x | LISTINGS
 Introduction | 1

Chapter 1

Introduction

Modern vehicles are increasingly manufactured with touchscreen-based

infotainment systems. They are primarily intended for GPS navigation,
playing music, making phone calls and sending text messages. Additionally,
the infotainment system provides an optional hands-free experience
through the use of voice control. With technological advancements
comes the desire to integrate several smartphone applications into the
car software. When talking about an Android powered infotainment
system, two different types of systems exist. Android Auto is a platform
that provides the opportunity to incorporate 3rd party apps into the
infotainment system. Through the use of a USB or Bluetooth connection
from an Android phone to the infotainment system Android Auto
projects the app’s content onto the car touchscreen. Android Automotive
is native to the vehicle’s operating system and is running directly inside
of the infotainment system independently from any external device1 .
Android apps can easily be converted to a version compatible with
Android Auto through simple manipulation of source files that regard
app build tools and app design2 . Viewing Android Auto compatible
apps show a large supply available on the market3 . Several 3rd party
media and messaging apps, such as Spotify, Audible, various radio and
1
“What is Android Automotive? Android Open Source Project,”Oct 2020. [Online].
Available: https://source.android.com/devices/automotive/start/what_automotive
Accessed 20201-04-16
2
Google, “Build media apps for cars,” 2021. [Online]. Available:
https://developer.android.com/training/cars/media Accessed 2021-04-17
3
Apps for Android Auto.”[Online]. Available:https://play.google.com/store/apps/
collection/promotion_3001303_android_auto_all?hl=en&gl=SE Accessed 2021-05-
07
2 | Introduction

podcast stations, Facebook Messenger and many more are ready to be

downloaded and projected to infotainment system displays worldwide.
Adding apps to the app store is a beneficial way of marketing the app and
ensuring users that the application is safer for download compared to an
external platform because of the mandatory review performed by experts
employed by the app store1 . However, due to the human factor in the in
the review stage, a slight security risk exists when analysing these apps.
Research regarding manual threat modeling explain that the analysis
process is prone to errors [1]. Consequently, bugs or exploits may remain
in the published app that when downloaded potentially can lead to data
breaches. Another issue with the review stage is how time-consuming
manual threat modeling can be [2]. The Android app store is the official
platform where Android applications are installed from. However, one
study from 2020 reveals that these downloads may not be entirely safe.
87% of all app installs are made from the app store, but 67% of apps with
malware also originate from the app store [3]. Additionally, the app store
is not the single platform where apps are downloaded from. Downloading
apps from external platforms that do not strive for user protection may
consequently lead to user security becoming highly compromised. Due to
the lack of research about Android Auto security it becomes a significant
topic to explore in order to ensure user and road safety. Malicious apps
may distract the driver, consequently endangering other drivers, cyclists
or pedestrians.
Android Auto requires extensive permissions in order to function
properly, which means that if it were to be compromised, then the
attacker would have almost full access to the device2 . To mention a few
permissions Android Auto has access to: location, system’s internal state,
the microphone, full access to the calendar, text messages, contacts,
call logs, Wi-Fi connection, the phone status & identity, access to find
all accounts on the device, enabling and disabling components of other
applications, modify system settings, prevent device from sleeping, etc.
All these permissions could be used to essentially accomplish a near full
takeover of the target device.
1
E. Kim, “Creating Better User Experiences on Google Play,” 2015.[Online].
Available: https://android-developers.googleblog.com/2015/03/creating-better-user-
experiences-on.html Accessed 2021-05-07
2
Google, “Android Auto Google play page,” 2021. [Online] Available:
https://play.google.com/store/apps/details?id=com.google.android.projection.gearhead
Accessed 2021-04-13.
 Introduction | 3

1.1 Similar Platforms and Competitors

In addition to Android Auto, there exists other entertainment system
platforms. Apple CarPlay is available for iOS devices on infotainment
systems that support CarPlay1 . Most cars that support CarPlay also
support Android Auto. MirrorLink is an alternative to OS specific
platforms2 . MirrorLink does not require a USB connection, but works
similarly to Android Auto and CarPlay in that the apps are powered
by the phone and not the infotainment system itself. MirrorLink is not
as widely supported as Android Auto and CarPlay when comparing the
supported vehicles list.

1.2 Motivation
Creating a complex ecosystem that is impenetrable and secure from all
types of attacks is a daunting task, and a project that is never complete.
Vulnerabilities and exploits are found over time, and it is impossible for
a group of developers at a company to find and patch them all, which
is why many of the large technology companies use bounty programs,
where independent hackers can submit vulnerabilities in exchange for a
payout [4]. Not all hackers are ethical. Unethical hackers that encounter
vulnerabilities and choose not to disclose the information to the company
leave the attack vector open for other malicious actors. In the case of
Android Auto, high security is of great significance since the application
is to be used when operating a motor vehicle. If a malicious actor is
able to distract, scare or annoy a driver, the driving performance may
be greatly reduced [5, 6] and could thus lead to a dangerous situation.
A study found that drivers that were annoyed by urgent sounds showed
a tendency to increase the throttle, and drivers that were shocked by a
sound tended to release the throttle [7]. This effect may harm the traffic
rhythm and endanger the road users.
Penetration testing systems and platforms that integrate with an
automotive interface is poorly researched, as most of the focus lies on
finding vulnerabilities directly in the automotive interface or the platform
connecting to it. However, research methods for evaluating automotive
1
“Carplay a way to connect a smart device to a vehicle.” [Online]. Available:
https://www.apple.com/ios/carplay/ Accessed 2021-04-14.
2
“Mirrorlink the most ingenious way to bring smartphone content to the dash.”
[Online]. Available: https://www.mirrorlink.com Accessed 2021-04-14
4 | Introduction

security by utilizing one system’s vulnerabilities to affect another system

are lacking.
Discovering that the systems are challenging to penetrate would
assure Android users to feel safe and comfortable with using Android
services. Android Auto requires a great amount of accepted permissions
in order to function. By knowing that malicious attackers struggle with
accessing private data and property, Android Auto and 3rd party apps
can continue developing and expanding their systems with the driver
safety intact.

1.3 Problem Statement

The research question that arises is, what vulnerabilities exist in
Android Auto and Android that potentially could put a driver in a
dangerous situation by an attacker?

1.4 Purpose
The purpose of the thesis is to test if Android Auto targeted attacks
are able to endanger a driver and access private data. The thesis aims
to bring light to possible attack vectors that are relatively unexplored
for Android Auto specific attacks in order for these vulnerabilities to be
closed or mitigated. With the acquired knowledge, Android and Android
Auto can be informed about the findings, which ultimately leads to an
improved development of their security. Consequently, users will become
more protected in terms of driver safety.
This paper will use a method for evaluating the impact of certain
exploitable vulnerabilities called Common Vulnerability Scoring System
(CVSS)1 and argue for its implications in the context of driving
experience.

1.5 Goals
The goal of this study is to conduct multiple penetration tests in order to
gather an adequate amount of data to establish if Android and Android
1
Common Vulnerability Scoring System Version 3.0 Calculator [Online] Available:
https://www.first.org/cvss/calculator/3.0
 Introduction | 5

Auto is sufficiently secure for road safety. To establish if Android and

Android Auto is sufficiently secure, the study will discuss the significance
of the consequences from successful and unsuccessful exploits.
Additionally a USB investigation will be conducted to discover if it
is possible to exploit Android Auto through the communication channel
between the mobile device and infotainment system.

1.6 Scope of Research

This thesis does not include pen-testing or analysis of the Android
Automotive operating system, Apple CarPlay or MirrorLink, as the
area of focus is the Android Auto platform. The experiments have not
been conducted on a physical Infotainment Head Unit (IHU) due to the
lack of resources, an emulator referred to as the Desktop Head Unit
(DHU) has been used as its replacement. The DHU will be treated
as if it were an IHU in order to present the implications of potential
exploits in the setting of the thesis. Results from the study may differ
compared to experiments with an IHU, and these differences are detailed
in the discussion section. The Android Auto application was not reverse
engineered, and no binary exploitations were performed on it.
The focus of the thesis is attacking Android Auto in a car setting, thus
general purpose attacks against the Android operating system or the car
firmware have not been considered. The exploits have been limited to
those that affect the device running Android Auto and consequently may
endanger and affect the driver security and experience.

1.7 Contributions
The findings from this study will contribute to the benefit of the Android
Auto- and road users, since navigation, media and telephony are widely
used in infotainment systems inside modern vehicles daily. Continued
development of 3rd party apps justifies the demand to pen-test and insure
that systems that are used on the road worldwide are safe. Discovering
and learning about possible exploits and their potential negative use cases
may lead to patches that eliminate the attack-vectors, thus creating a
safer environment on the road for all.
Research on the subject of Android Auto security is lacking, therefore
this report will help build a foundation and bring breadth to the topic.
6 | Introduction

The thesis provides a foundation for further research into the topic and
suggests attack vectors to investigate.

1.8 Attacks
In order to conduct research on potential exploits relevant to Android
Auto it is crucial to analyze the attack surface 3rd party apps have access
to. Since Android Auto functionality is separate from the car functions,
potential targets for malicious apps are other mobile applications and
the car’s infotainment system itself. The infotainment display could
potentially crash or change brightness, app data could be leaked and
the infotainment system volume could be tampered with. The report
will closer examine these attack vectors through various exploits.
One harmful exploit is Task hijacking that regards when a malicious
application takes over the execution from a legitimate application.
Instead of the phone opening a user’s authentic banking application,
a visually similar application could be opened instead, extracting user
credentials to a hacker’s server1 [8].
SoundBlast is an attack that targets the driver directly. The attack
involuntarily modifies the volume to max volume as media is played in
the background. This attack does not require any special permissions
and can easily be exploited by an application [9].
The purpose of an Intent Storm is to deplete the system resources,
rendering the Android system unusable until it ultimately crashes. It
is achieved by continually sending intents to reopen the application on
several threads. Since opening applications is resource intensive, this will
quickly use up all available resources [9].

1.9 Vulnerabilities in the USB Connection

In addition to purely software based attacks, the report will attempt to
discover if it is possible to use the USB connection that the device uses
to connect to the vehicle as an attack vector. All content shown on the
screen of the DHU/IHU is projected from the device, which means that
the data has to be transferred through the USB cable. This investigation
1
I. Markovic, “Android Task Injection aka "StrandHogg vulnerability",” 2019.
[Online]. Available: https://github.com/Ivan-Markovic/Android-Task-Injection
Accessed 2021-04-20.
 Introduction | 7

is significant since control of the flow of data between the device and the
DHU/IHU could be an attack vector with serious implications.

1.10 Thesis structure

The remainder of the report is structured in 8 subsequent chapters.

• Chapter 2 describes the method of research.

• Chapter 3 discusses the related research.

• Chapter 4 describes the attack environment and details the

penetration attacks utilized.

• Chapter 5 discusses the results obtained from the methods.

• Chapter 6 discusses the results.

• Chapter 7 presents the findings from the USB channel investigation.

• Chapter 8 mentions future work needed on this topic.

• Chapter 9 summarizes and concludes the findings of the study.

8 | Introduction
 Method of research | 9

Chapter 2

Method of research

This section describes the Research Methodology and concerns the

methodological process of identifying a problem and traversing through
necessary stages in order to accomplish a technical study to finally
contribute to the scientific field.

2.1 Research Methodology

This paper is written in accordance with the DSRM [10]. The outline
of the methodology and the way it was applied follows in the next
subsections and can be viewed in figure 2.1. Some of the material has
been presented in chapter 1 but it is repeated below for completeness.

2.1.1 Problem Identification and Motivation

As mentioned in 1.2, exploits leading to findings regarding Android Auto
in terms of execution, driver safety and data leaks make it possible
to draw conclusions about the state of Android Auto security. Apps
published on the app store are reviewed by alleged experts before
accepted1 . A problems with manual analysis of apps is that there is a
risk where malicious apps may proceed undetected and pass the control,
thus containing code that compromises user integrity. It is essential
to investigate if drivers are safe to use Android Auto due to the large
audience that actively use its services. Since the topic lacks sufficient
1
E. Kim, “Creating Better User Experiences on Google Play,” 2015.[Online].
Available: https://android-developers.googleblog.com/2015/03/creating-better-user-
experiences-on.html Accessed 2021-05-07
10 | Method of research

Figure 2.1 – The adaptation of the design science research methodology

used in this thesis. The work process was design & development centered
and is thus the only entry point that is highlighted at the bottom of the
figure.
 Method of research | 11

research about security and app exploits, it cannot be presumed that the
application is safe for users.

2.1.2 Define the Objectives for a Solution

As mentioned in 1.4, the objectives for a solution is to exploit an attack
vector to distract or in another way endanger the driver’s life by attacking
Android Auto. The goal is to write reproducible attacks that target
Android Auto in such a way that the attention of the driver is required.
Any successful attack has the potential to work on other applications as
well, which makes this research applicable to other investigations in the
application security sector.

2.1.3 Design and Development

Previous research projects on Android related system security were the
basis for the attacks in this thesis, since parts from these projects could
be modified and used to target Android Auto. The attacks were designed
to be executed on Android devices, since Android Auto solely runs on
Android. The literature provided the foundation of theoretical and
applied attacks that could be used as a foundation for crafting the
attacks. The severity of the attack is determined by how complex the
attack is and how easy it is to put into practice. The act of rating attacks
based on severity required assessment of the characteristics of the attack,
which were based on literature on vulnerability ratings.

2.1.4 Demonstration
After the exploits had been developed they were adapted to the attack
environment to experiment with the identified attack vectors. Distraction
related exploits were conducted to discover if they had any significance
on the device, which ultimately may affect the driver and road safety in
general. Additionally, an exploit was utilized to find a procedure that
enables the opportunity to extract sensitive user data through phishing.
Resources required for the demonstration have been listed in chapter 4.

2.1.5 Evaluation
The attacks were evaluated by first making sure that the attack was
successfully executed, and subsequently rated based on their complexity
12 | Method of research

and how easy they were to exploit. These scores have been generated
using the CVSS Version 3.0. Attack scores establish the severity of the
software vulnerabilities in relation to other vulnerabilities. Unsuccessful
attacks attain the severity score of zero and extremely severe attacks are
rated a score of 10.

2.1.6 Communication and Contribution

The process of using broad attacks and using them to target specific
applications can be applied to research related to any Android applications
security. The exploits provide an effective practice to validate if apps are
safe against discussed attack vectors. All the findings of this thesis were
reported to Google for evaluation.

2.2 Ethical Approach

Ethical hacking is about exploring and testing a system to determine
what vulnerabilities exist and to discover if malicious parties are able
to access sensitive information. The ethical hacking process commences
with obtaining the consent from the owner of a system or network by
agreeing upon the extent of the attacks. It has a systematic approach and
ultimately leads to the company being informed about the vulnerabilities,
thus leading to a fortified system where the attack vectors have been
eliminated. However, hacking a system without following a certain set of
rules is illegal and can lead to serious implications. Therefore, there are
several moral and ethical obligations that needs to be followed to conduct
ethical pen-testing [11]. These obligations include authorization, non-
disclosure, confidentiality and boundaries that will be described below.

2.2.1 Authorization
Always gain the authorization of a system owner before pen-testing.
Some vendors use bug bounty programs where they outline the rules
and the scope of allowed pen-testing, without requiring every pen-tester
to explicitly ask for permission. The bug bounty program that Google
runs also includes Android Auto and the Android operating system.
 Method of research | 13

2.2.2 Non-disclosure
Most pen-testers sign a non-disclosure agreement to ensure that no
confidential information is released before during or after the testing.
Android Auto runs by Google, whose bug bounty program states that
any research conducted on their products should be disclosed to Google
and the results should not be posted publicly until after their 90-day
disclosure deadline1 .

2.2.3 Confidentiality
Never release any confidential information about an individual, test or
company to any third-party. The tests conducted in this thesis will not
expose any personal information since all tests are run on emulators
or the authors’ personal mobile devices. At no point was the personal
information of other individuals or the intellectual property of Google at
risk of being disclosed, uncovered or shared.

2.2.4 Boundaries
Before pen-testing starts, it is important to know what is allowed and
what is not allowed. Overstepping these boundaries could either be
illegal or grounds for legal repercussions or other disciplinary action,
such as being banned from the platform and/or unable to continue with
the bug bounty program. The tests conducted in this thesis are within
the boundaries of the law and the guidelines provided by Google for their
bug bounty program.

1
“Application Security – Google.” [Online]. Available:
https://www.google.com/about/appsecurity/ Accessed 2021-05-18.
14 | Method of research
 Related Research | 15

Chapter 3

Related Research

The most recent security research in the automotive area focus on on-
board computers and systems and study their impact on the driving
experience. The research often disregards Android Auto related attacks,
since these attacks do not directly impact the vehicle itself.
Android Auto apps are sometimes used as attack vectors. In an
analysis of Android Auto apps found on the Google play store, 80% of the
downloaded and tested apps showed warnings after static analysis, some
25% of apps were vulnerable to JavaScript attacks. The authors of the
study also found that GPS data could be extracted without permissions
and that media could be auto played, in contrast to Google’s Android
Auto security standard [12].
In 2015 1.4 million vehicles were recalled by the manufacturer due to a
serious security vulnerability where it was possible to remotely hack into
the infotainment system. From here they could access the engine control
unit to send other commands to similar car components. The exploit
made it possible to affect the steering and brakes of the unmodified
vehicle [13].
One study brings up the serious safety risk with allowing untrusted
third-party code on Autonomous Vehicles. Several companies allow
uncertified code on their platforms for the means of testing and development.
However this poses a security threat. Followingly the study proposes an
enhanced design of the Appified AV platform called AVGUARD to allow
third-party developers to safely test their applications, thus mitigating
the security issue [14].
Research conducted at the University of California, Berkeley concluded
that less than a quarter of users paid attention to permissions granted
16 | Related Research

to applications on installation, and less than five percent comprehended

what permissions were granted. This means that a lot of users give
applications attack vectors without realizing it [15]. Another study at
Berkeley investigated close to 1000 applications for overprivilege and
found that around 300 were given more permissions than they used thus
not adhering to the principle of least privilege [16].
Researchers at Instituto de Telecomunicações made a proof of concept
of an attack that exploits a vulnerability in some vendors implementation
of the Android system. The exploit uses a USB connection to exploit
vendors implementation of serial AT commands to flash a compromised
boot sector to gain root privileges, then enable Android Debug Bridge
(ADB) to finally install surveillance software. The attack environment
could be set up in a normal looking charging station, and install the
surveillance software without the user ever knowing [17].
A collaborative study between CTS research center and Polytechnic
Institute of Beja investigated vulnerabilities on Android devices by
exploiting the ADB. The study found that by using a script on a
computer, private data could surreptitiously be extracted from devices.
For newer versions of Android, the user needed to accept the connection
before the data extraction could begin [18].
Research into the security of MirrorLink concluded that the protocol
used to communicate between the device and the infotainment system
is exploitable if certain settings are changed. The research provided a
proof-of-concept overflow attack that could be used to send messages to
vehicles CAN bus [19].
A group of Master students from Chalmers University tested the
Android Automotive operating system, and found that it was susceptible
to attacks where the OS could crash, freeze or dangerously distract the
driver. The students found several ways to extract private information
from the vehicle without using any permissions [9]. This thesis has taken
inspiration from this study by applying certain applicable attacks to
Android Auto.
 Attacks and Attack Environment | 17

Chapter 4

Attacks and Attack Environment

This chapter contains two parts. Part one regards the environment
setup for the exploits as the code environment and tools required for
the attacks. In the next section, the attacks’ objectives and production
methods are described in detail.

4.1 Attack Environment

The developed exploits were tested with a combination of emulators and
physical hardware. The code was written in Android Studio version
4.1.3 on Windows 10 and executed on Android Software Development
Kit (SDK) versions 21 to 30, Android versions 5 to 11. Tests were
made on an emulated mobile device and a physical Samsung Galaxy
S8, running Android version 9. The DHU emulator was retrieved from
Android Studio. After downloading Android Auto, the developer mode
was enabled in the application settings on the Samsung mobile device
(for both physical and emulated devices). The developer mode needs to
be activated to host a head unit server from the phone that uses the ADB
to enable communication between the mobile device and the DHU. The
head unit server was needed for both the physical- and emulated device
to connect to the DHU via ADB. The physical device was connected to
the computer running the DHU via USB through a USB 3.0 port.
To ensure that the attacks only target the device when the user is
driving, two checks were made. One check to see that the device was
connected to a USB cable (listing 4.1), and one check that ensured that
Android Auto was running by identifying the phone’s UI mode (listing
4.2). If the device was in the incorrect UI mode as the USB was plugged
18 | Attacks and Attack Environment

in, the device was only connected to a data transmitting device and
not running Android Auto. If the UI mode was correct without a USB
connection, the user had opened Android Auto but was not using the
DHU and possibly not driving. However, a delimitation with the attack
environment is that the USB connection could not differentiate between
being connected to the DHU or another computer since both transmit
data, (listing 4.1). Thus, the exploits could be launched in a scenario
where Android Auto is running and connected to a computer via USB.

Listing 4.1 – Detect when USB is plugged in

Intent intent =
getApplicationContext().registerReceiver(null, new
IntentFilter("android.hardware.usb.action.USB_STATE"));

/*
* Detects if the device is connected to
* a data transmitting device. Does not
* differentiate between DHU and computer.
*/
if(intent.getExtras().getBoolean("connected")){
//USB connected to data transmitter
}

Listing 4.2 – Detect when Android Auto is running

Context c = getApplicationContext();

UiModeManager uiModeManager = (UiModeManager)

c.getSystemService(Context.UI_MODE_SERVICE);

/*
* Can only tell if Android auto is running or not
* Not if it is connected to a DHU or IHU
*/
if (uiModeManager.getCurrentModeType() == Configuration
.UI_MODE_TYPE_CAR) {
//Android Auto is running
}
 Attacks and Attack Environment | 19

4.2 Attacks
In this section the exploits are described in technical detail, how they
function and the implemented approach to produce the exploits used in
this thesis.

4.2.1 Task Hijacking

Task hijacking revolves around making a malicious app take over the
execution from a legitimate application by changing the app stack
hierarchy and creating an affinity between the exploit and targeted
package function in an application. StrandHogg 1.01 was used as the basis
for this exploit and was achieved by manipulating the taskAffinity and
task-reparenting attributes in the Android manifest file (listing 4.3). The
purpose of these changes were to place the malicious activity at the root
of affiliated and targeted program’s execution stack. Resultingly, when
the legitimate app starts it is redirected to the malicious activity instead
of the real application. Often times task hijacking exploiters design the
malicious app very similar to the legitimate app in order to phish user
input. As a result unaware users unknowingly enter private data into
the hands of the hacker. The user would seemingly run a legitimate app
inside, and compatible with Android Auto, but on the phone a malicious
app would be launched as well. The intended outcome was to spoof the
apps used by Android Auto in order to hijack the execution and modify
the content projected on the display.

Listing 4.3 – Task Hijacking manifest.xml

<application ...>
<activity android:name=".MainActivity" ...>
...
</activity>
<activity android:name=".Attack1"
android:allowTaskReparenting="true"
...
android:taskAffinity="Vulnerable package name.
e.g. com.android.***.***"/>
</application>

1
https://promon.co/security-news/strandhogg/
20 | Attacks and Attack Environment

Figure 4.1 – Illustration of how the StrandHogg exploit causes a

legitimate app to be bypassed as the malicious application window
launches in the foreground

4.2.2 Intent Storm

Intent Storm is an attack that uses up the system resources in order
to induce a crash or freeze. The attack works by creating one
hundred threads in an app’s main activity, where each thread starts
the applications main activity as a new task, thus creating a hundred
new threads that perpetually open the application again (listing 4.4).
This Denial-of-Service (DOS) attack will use up all the system resources,
by utilizing the fact that creating, starting and running a new task
is resource intensive. The attack will ensure that all available system
resources are used to create and run the new instances of the application,
thus rendering the device unresponsive and in most cases unusable.
Although this attack runs on the phone, two checks (listing 4.1 &
4.2) transform this attack into a targeted attack against the driver’s and
passengers’ experience. To ensure that the exploit targets Android Auto
specifically and no other application, the execution only begins when a
USB is connected to the phone, and Android Auto is running. This is
done by using Android’s scheduleAtFixedRate with a task that checks
if the USB is connected and the phone is in UI_MODE_TYPE_CAR,
when that is true, run the exploit.
 Attacks and Attack Environment | 21

Listing 4.4 – Intent Storm

public class MainActivity extends AppCompatActivity {
...
public void intentStorm(){
Intent main = getIntent();
for(int i = 0; i < 100; i++){
new Thread(new Runnable() {
public void run(){
while(true){
startActivity(main);
}
}
}).start();
}
}

4.2.3 SoundBlast
SoundBlast is designed to distract a driver by unexpectedly altering the
volume playing on the infotainment system. The attack maximizes the
volume of the audio stream on the phone, which shocks the driver and
causes a distraction. By using Android’s built in Audio Manager, the
programmer can programmatically set the volume of the application
(listing 4.5). The desired outcome is a change in volume on the DHU as
the phone volume changes.

Listing 4.5 – SoundBlast

AudioManager am =
(AudioManager)getSystemService(Context.AUDIO_SERVICE);

am.setStreamVolume(STREAM_MUSIC,
am.getStreamMaxVolume(STREAM_MUSIC),0);
22 | Attacks and Attack Environment
 Results | 23

Chapter 5

Results

This section presents the results of the exploits. Each exploit’s result will
be presented in its subsequent sub-chapter.
Table 5.1 contains a structured breakdown of the name, severity and
category1 of the exploits. The CVSS values (calculated in A.1) displays
the severity of the exploit on a scale from 0 to 10, where 0 signifies a
harmless exploit and 10 means that the exploit is extremely severe.

Exploits
Name of exploit CVSS3 score Category
SoundBlast 3.3 Audio/distraction
IntentStorm 5.5 DOS/distraction
Task Hijacking 6.1 Phishing

Table 5.1 – The exploits, with CVSS value and category

5.1 Task hijacking

Experimenting with task hijacking on Android Auto showed both success
and failure when attempted depending on which Android version was
used the targeted mobile device. On SDK 30 or Android version 11
the exploit was unable to hijack the application. However, Android
versions 5-10 revealed a serious issue when launching Android Auto from
the mobile phone. After first starting the malicious app on the phone
1
The categories do not follow any particular categorization scheme, but have been
chosen to explain the intended danger/impact of the exploit. Other categories may
have been more appropriate, but it is not an important distinction in this context.
24 | Results

and later navigating elsewhere with the malicious app running in the
background, it was possible to hijack Android Auto’s execution on the
mobile device. Android Auto started in the background as the malicious
application became the task in focus. However, attempting this exploit
on the DHU emulator on PC did not show definitive results regardless
of the SDK- and Android version. Despite running the exploit and
afterwards launching Android Auto did not show any sign of a successful
task hijack.
A modified exploit that attacked applications used by Android Auto
in the DHU, for instance Google Maps and telephony was unsuccessful
as well. The exploit was ignored and the applications running inside of
Android Auto started naturally.

5.2 Intent Storm

Attempting the Intent Storm exploit as the user started Android Auto
revealed there is a big risk that a malicious app is able to cause Android
Auto and the car infotainment display to freeze and stop functioning.
The exploit was successful on all versions of Android that were tested
(see 4.1). The malicious application was running in the background,
waiting for the conditions (listings 4.1 & 4.2) to be true before launching.
As the exploit started, all mobile CPU resources were depleted, which
immediately caused the DHU to completely stop. After several minutes
the DHU crashed and the phone still suffered from unresponsiveness.

5.3 SoundBlast
The SoundBlast attack was automatically executed when the user had
started the malicious app and the conditions (listings 4.1 & 4.2) were
met. The exploit showed the same result on all versions of Android that
were tested (see 4.1). This exploit was partly unsuccessful because the
change in volume was not detected on the DHU but rather on the phone
itself. The volume could be set programmatically, which could executed
in a loop to force the volume to always be increased to the maximum.
The test was inconclusive as to whether or not the volume would change
on an IHU. It was not possible to verify the change of volume on the
DHU, since the emulator lacks volume controls and a volume indicator.
 Discussion | 25

Chapter 6

Discussion

This chapter will discuss the results of the exploits, the implications
of the thesis’ delimitations and the influence of the chosen research
methodology.

6.1 Attacks
In this section the results are discussed and evaluated in regards to their
success, issues and expansion possibilities. Additionally, weaknesses of
the exploits and potential countermeasures are considered.

6.1.1 Task Hijacking

Running the DHU requires a local Android Auto server to be hosted on
the phone. The StrandHogg 1.0 exploit was unsuccessful when attempted
on the DHU because the server hosted on the phone uses an entirely
new instance of Android Auto. The server also creates new instances of
the apps available on the mobile device (media, navigation, telephony
applications compatible with Android Auto). Therefore, task hijacking
Android Auto locally on the device was a success where a server was
not required. But the conducted experiments did not show that it
was possible to execute the exploit to sever the connection between the
Android Auto server and the DHU.
Having access to a physical IHU would potentially show a difference
of results, since a local server that does not manipulate and create
new instances of the device applications in Android Auto would not be
required. However, an IHU would unlikely open up opportunities to
26 | Discussion

target attacks on the apps inside Android Auto. The attempts to task
hijack Google Maps and the telephony service in Android Auto showed
unsuccessful results regardless if the phone was connected to the DHU or
not. Thus, it does not seem probable that access to an IHU would lead
to different results for this experiment.
Security researchers from Pennsylvania State University and Fire
Eye Incorporated showed how task hijacking could be accomplished and
proved that millions of apps were at risk [8]. This thesis has strengthened
their claim and shown that it is possible to task hijack Android Auto.
The exploit has a great weakness. When a malicious application with
the StrandHogg exploit is opened on the phone, two application windows
open. An innocent screen that represents a harmless application, and
a "hacked" screen that can be designed to mimic a legitimate app.
Opening the task manager on mobile after having started the StrandHogg
application made it apparent that the malicious application is functioning
out of the ordinary. Users that detect this anomaly can prevent the
exploit by uninstalling the malicious application.

6.1.2 Intent Storm

If a malicious phone application has been installed and is running in
the background, it has the potential to crash the device at any time.
The Intent Storm attack crafted to target the device when Android Auto
was running successfully made the device freeze when the conditions
were met. This type of DOS attack can be quite difficult to protect
against, since the application can appear completely legitimate until
certain criteria are met. To figure out what app caused the freeze could
potentially be a difficult task, since it is developed to only run if Android
Auto has launched and runs in the foreground.
An exploit causing the mobile device to freeze or crash as Android
Auto runs could endanger the driver. The driver would need to perform a
manual restart, enter the PIN code, relaunch Android Auto and navigate
to the GPS or media function that is desired. A study found that
operation of the infotainment system distracts the driver and leads to
an overall degraded driving performance [5].
The attack requires the malicious application to be running in the
background in order for the Intent Storm to be executed. A user that
frequently closes applications from the task menu is not likely to be
affected by this attack, while users who rarely close applications are at
 Discussion | 27

greater risk.
An issue with the attack is the possibility that users can invoke the
attack when not driving. On all Android versions less than 28, Android
Auto is visible in the application menu. A user with the app installed
could open the application and connect their device to a computer or
other data transmitting device which would invoke the attack, since all
its criteria are met.
To extend the attack, the application could ask for permissions to
the location data, which could make speed a criteria for launching the
attack. The application could also create a background service that could
run indefinitely, waiting for the criteria to be met before launching the
attack. The background service would continue to run, even if the original
application were to be closed.

6.1.3 SoundBlast
Changing the volume unexpectedly could be dangerous for the driver
[7]. If a driver is traveling at a high velocity, a sudden, unexpected
loud sound could cause the driver to twitch and potentially lose control
of the vehicle. Decreasing the volume without the driver’s permission
could also result in road rage and distractions where the driver needs to
manage the volume control, thus increasing the risk of a traffic accident.
Lowering the volume as the driver expects to hear Google Maps directions
for instance, could result in indecisive behavior from the driver thus
endangering multiple road users. The potential risk could be increased
if the application requests location data, and executes only if the vehicle
is traveling faster than a certain speed where the driver’s attention is
crucial.
The exploit was successful in changing the volume, but due to the
experimental setup it only changed the volume on the mobile phone.
The emulated display played sound through the computer’s audio system,
which naturally is isolated from the phone’s audio. Therefore, tests could
not verify if the volume on the DHU was affected. However, it is possible
that using the volume keys on the mobile device affects the volume on
an IHU. This would mean that the attack would work on an IHU, but
this claim is unverifiable without the required hardware.
Developing the exploit is very simple and only requires a few lines
of code and it has a few countermeasures. The application can without
privileges set the volume of the device, and repeatedly setting the volume
28 | Discussion

will ensure that the user cannot mute or lower the volume. No effective
countermeasure was found except terminating the connection to the
DHU, which could prove to be difficult while driving.

6.1.4 CVSS 3.0

CVSS 3.01 is a useful metric when assessing the impact of a vulnerability.
CVSS scores are sometimes used as a metric for prioritising security
patches and bug fixes, which is not recommended and should be used
with caution due to the approximate nature of the scoring system [20].
The scores calculated are sometimes debated, where different experts
disagree on the assigned score for certain vulnerabilities [21]. CVSS
scores are often uploaded to vulnerability databases along with their CVE
record, and the databases do generally stay consistent with their scoring
of the individual base metrics [22]. The vulnerabilities in this thesis
have been assigned CVSS scores but they have not been uploaded to any
vulnerability database, and have not been scored by a security expert.
This thesis has presented CVSS scores, that should not be regarded as
entirely reliable, but rather as an approximation of the risk that the
exploits can implicate.

6.2 Delimitations
The thesis was focused on security implications of vulnerabilities in a
vehicle setting. However, the vulnerabilities and exploits presented in
this thesis could also be used in other contexts. Task hijacking could be
used to steal usernames and passwords, read private messages or secretly
record the user by phishing legitimate applications. It could also be used
to request permissions to retrieve and manipulate otherwise inaccessible
data on the phone.
Since Android Automotive is part of the Android source code2 any
attack against Android that can be exploited in a vehicle setting could
also be exploited on Android Automotive. The Soundblast and Intent
Storm attacks were based on Android Automotive oriented attacks. Task
1
Common Vulnerability Scoring System Version 3.0 Calculator [Online] Available:
https://www.first.org/cvss/calculator/3.0
2
“What is Android Automotive? Android Open Source Project,”Oct 2020. [Online].
Available: https://source.android.com/devices/automotive/start/what_automotive
Accessed 20201-04-16
 Discussion | 29

hijacking, originally crafted for Android running on mobile devices, could

thus be used on Android Automotive where it would be harder to detect,
since Android Automotive does not have a task menu.

6.3 Research Methodology

The design science research methodology (DSRM) utilized had a significant
influence on the outcome of this thesis. The work was design- and
development centered, where design ideas were implemented and executed
iteratively until the exploits became successful. Due to the methodology,
a formal process model was provided that outlined the necessary stages
and principles for conducting design science research on information
systems. The methodology also provided an assisting structure for
presenting and evaluating the results, thus facilitating the research
process.
30 | Discussion
 USB Investigation | 31

Chapter 7

USB Investigation

One potential attack vector in exploiting Android Auto and the DHU
is through the USB cable used for communication. By intercepting the
channel, it may be possible to interact with the USB interface to block
or alter communication sent from the mobile device to the DHU. The
chapter investigates the USB communication in three sections. The first
looking at the raw packets, the second at Android Logs and the third at
TLS decryption. Finally, the section presents the results that potentially
can be used for exploiting Android Auto via USB.

Figure 7.1 – WRTE-block raw data

7.1 Raw Packet Analysis

A 3rd party program USBlyzer1 was utilized for investigating the raw
packets sent between the DHU and the mobile device. The program
revealed that several small data packets were sent regularly through the
USB connection. These packets only consisted of 24 bytes, whereof the
first four bytes formed the word WRTE (figure 7.1) or OKAY (figure
7.2), and the remaining 20 bytes were encrypted. WRTE and OKAY are
1
“USBlyzer” [Online]. Available: https://www.usblyzer.com/ Accessed 2021-05-12.
32 | USB Investigation

referenced in the ADB documentation1 .

This means that these keywords are part of the communication in
the Android debugging tools that forwards the messages between the
mobile device and the DHU. Analyzing the communication revealed a
pattern of these messages. The packet containing WRTE was sent before
transmitting a larger encrypted packet up to 5000 bytes in size (figure
7.3). When the recipient had received the packet, an acknowledging ACK
was returned using the OKAY keyword.

Figure 7.2 – OKAY-block raw data

7.2 Android LogCat Analysis

The USB investigation proceeded by analyzing messages in Android
LogCat to learn about the type of encryption used by Android Auto.
Wireshark2 was used to capture all the logs generated by the device when
opening the Android Auto application. By connecting the device to the
DHU and starting Wireshark in Android Logcat Main mode revealed that
Android Auto uses TLS 1.2 to communicate with the DHU. The logs
show that the CAR.GAL.SECURITY package successfully initializes
SSL context for protocol twice, before any logs from CAR.VIDEO are
made. The logs did not provide any details about keys used for
establishing an encrypted connection therefore trying to decrypt the
message by obtaining data from the logs is not possible. The logs only
indicate that an event has transpired or failed, without giving any details.
The first occurrence of the initialized SSL context is TLS 1.2 using
the provider AndroidOpenSSL and the second case is TLS 1.2 using
the provider GmsCore_OpenSSL. Further investigation show that the
1
“ADB Shell 0.3.2 Documentation.” [Online]. Available: https://adb-
shell.readthedocs.io/en/stable/adb_shell.adb_device_async.html/ Accessed 2021-
05-12.
2
“Wireshark·Go Deep.” [Online]. Available: https://www.wireshark.org/ Accessed
2021-05-12.
 USB Investigation | 33

GmsCore_OpenSSL encryption originates from the CAR source package

which in this case has the service_id 13. The associated logs with the
service_id 13 are all related to setting up, and projecting services related
to Android Auto.

Figure 7.3 – Encrypted-block raw data

7.3 TLS Decryption

There are a few attacks that are able to break and decrypt TLS 1.2. These
attacks are built on Man-in-the-Middle (MitM) attacks. For instance,
Zombie POODLE and GOLDENDOODLE are two attack that manages
to recover encrypted messages into plain text when exploited1 . Using
these discovered exploits to decrypt the raw data retrieved in section 7.1
could reveal critical information that opens up for continued research and
penetration-testing on Android Auto. Potentially it would be possible to
alter the raw data to modify projected data on the DHU or send malicious
commands to the devices. If the library used to encrypt the data is based
on OS version, any device running on an older version might be vulnerable
to known attacks [23]. However, due to the lack of time this assignment
will be left as future work for interested parties.
1
“NVD - CVE-2019-6593.” [Online]. Available: https://nvd.nist.gov/vuln/detail
/CVE-2019-6593 Accessed 2021-05-12
34 | USB Investigation
 Future work | 35

Chapter 8

Future work

One major suggestion for future work is obtaining a physical IHU in

order to attempt similar exploits to obtain concrete results that indicate
the state of Android Auto in a car setting. The StrangHogg 1.0 and
SoundBlast exploits executed in this thesis are of particular interest since
the results obtained applied to the emulated DHU. These tests could lead
to a different set of results from experiments with an IHU.
In addition to hijacking tasks, further research should be made
to investigate the possibility to hijacking services, since a lot of the
applications run in Android Auto are run as services instead of tasks. If it
was possible to hijack a service, it would be possible to show a malicious
application instead of Google Maps, the built-in messaging application
or the telephony application.
One attack vector that deserves more research is to decrypt the USB
communication between the DHU/IHU and the device, which potentially
could expose sensitive data that opens up for manipulation. The device
uses the Android Auto Projection Protocol to communicate with the
DHU/IHU, which means that research into potential vulnerabilities in
this protocol could lead to an effective attack vector.
36 | Future work
 Conclusion | 37

Chapter 9

Conclusion

This thesis has investigated the security of the Android Auto application
in regards to road safety. By attacking and exploiting vulnerabilities in
the Android operating system, attacks were crafted that directly target
the user when driving. In various situations the findings demonstrate
that Android Auto is not secure for road safety depending on how the
application is used. Running Android Auto locally on the phone without
connecting it to a DHU or IHU showed a greater risk of successful exploits
that compromise driver safety and user data. Task hijacking was able
to take over execution, Intent Storm managed to crash the mobile and
SoundBlast could change the volume without user input. However, the
results from running Android Auto on the DHU indicated user security.
Intent Storm managed to completely freeze and crash the DHU, which
may endanger a driver by making them lose attention on the road and
instead focus on restarting the unresponsive infotainment system. The
USB investigation revealed details about the encrypted communication
between the device and DHU. It is possible to use existing exploits to
decrypt the encrypted data, where modification of the content may lead
to different exploits that manipulate information on the infotainment
display that reduces Android Auto security.
The relevancy of the thesis is apparent since a driver’s life could be put
at risk. Task hijacking could show a malicious version of a maps software
and lead the user to another location than the user did not intend.
SoundBlast could cause the driver to make uncontrolled movements,
leading to a loss of control of the vehicle, or create a distraction which
makes the driver less attentive to their surroundings. The USB findings
set the foundation to investigate the possibility of attacks that could put
38 | Conclusion

the user’s data at risk. Inspiring future research to be conducted on the

subject means that more possible vulnerabilities get patched and road
safety increases.
 REFERENCES | 39

References

[1] H. Holm, M. Buschle, R. Lagerström, and M. Ekstedt, “Automatic

data collection for enterprise architecture models,” Software &
Systems Modeling, vol. 13, no. 2, pp. 825–841, 2014.

[2] P. Närman, P. Johnson, R. Lagerström, U. Franke, and M. Ekstedt,

“Data collection prioritization for system quality analysis,”
Electronic Notes in Theoretical Computer Science, vol. 233,
pp. 29–42, 2009. doi: https://doi.org/10.1016/j.entcs.2009.02.059
Proceedings of the International Workshop on Software Quality and
Maintainability (SQM 2008).

[3] P. Kotzias, J. Caballero, and L. Bilge, “How Did That Get In My

Phone? Unwanted App Distribution on Android Devices,” ArXiv,
vol. abs/2010.10088, 2020.

[4] A. Y. Ding, G. Limon De Jesus, and M. Janssen, “Ethical Hacking

for IoT Security: A First Look into Bug Bounty Programs and
Responsible Disclosure,” arXiv e-prints, Sep. 2019.

[5] T. Horberry, J. Anderson, M. A. Regan, T. J. Triggs, and J. Brown,

“Driver distraction: The effects of concurrent in-vehicle tasks, road
environment complexity and age on driving performance,” Accident
Analysis & Prevention, vol. 38, no. 1, pp. 185–191, 2006.

[6] A. L. Glaze and J. M. Ellis, “Pilot study of distracted drivers,”

Transportation Safety Training Center for Public Policy, 2003.

[7] E. E. Wiese and J. D. Lee, “Auditory alerts for in-vehicle information

systems: The effects of temporal conflict and sound parameters on
driver attitudes and performance,” Ergonomics, vol. 47, no. 9, pp.
965–986, 2004. doi: 10.1080/00140130410001686294
40 | REFERENCES

[8] C. Ren, Y. Zhang, H. Xue, T. Wei, and P. Liu, “Towards discovering

and understanding task hijacking in android,” in 24th USENIX
Security Symposium (USENIX Security 15). Washington, D.C.:
USENIX Association, Aug. 2015. ISBN 978-1-939133-11-3 pp. 945–
959.

[9] B. Eriksson, J. Groth, and A. Sabelfeld, “On the Road with Third-
Party Apps: Security Analysis of an In-Vehicle App Platform,”
Master’s thesis, Gothenburg, Sweden, 2019.

[10] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee,

“A Design Science Research Methodology for Information Systems
Research,” Journal of Management Information Systems, vol. 24,
no. 3, pp. 52–60, 2007.

[11] K. Graves, CEH: Certified Ethical Hacker Study Guide, 1st ed.
USA: SYBEX Inc., 2010. ISBN 1978-0-470-52520-3

[12] A. Mandal, A. Cortesi, P. Ferrara, F. Panarotto, and F. Spoto,

“Vulnerability analysis of android auto infotainment apps,”
Proceedings of the 15th ACM International Conference on
Computing Frontiers, 2018.

[13] Dr. C. Miller and C. Valasek, “Remote exploitation of an unaltered

passenger vehicle,” Black Hat USA, vol. 2015, no. S 91, 2015.

[14] Y. Jia, D. Zhao, Q. A. Chen, and Z. Mao, “Towards

Secure and Safe Appified Automated Vehicles,” 06 2017. doi:
10.1109/IVS.2017.7995800 pp. 705–711.

[15] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and

D. Wagner, “Android permissions: User attention, comprehension,
and behavior,” in Proceedings of the Eighth Symposium on
Usable Privacy and Security, ser. SOUPS ’12. New York,
NY, USA: Association for Computing Machinery, 2012. doi:
10.1145/2335356.2335360. ISBN 9781450315326

[16] A. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner, “Android

permissions demystified,” Proceedings of the ACM Conference on
Computer and Communications Security, pp. 627–638, 10 2011. doi:
10.1145/2046707.2046779
 REFERENCES | 41

[17] A. Pereira, M. E. Correia, and P. Brandão, “USB Connection

Vulnerabilities on Android Smartphones: Default and Vendors’
Customizations,” vol. 8735, 09 2014. doi: 10.1007/978-3-662-44885-
4_2

[18] J. Amarante and J. P. Barros, “Exploring usb connection

vulnerabilities on android devices - breaches using the android debug
bridge,” 01 2017. doi: 10.5220/0006475905720577 pp. 572–577.

[19] S. Mazloom, M. Rezaeirad, A. Hunter, and D. McCoy, “A

security analysis of an in vehicle infotainment and app platform,”
in Proceedings of the 10th USENIX Conference on Offensive
Technologies, ser. WOOT’16. USA: USENIX Association, 2016,
p. 232–243.

[20] R. Rieke, “Modelling and analysing network security policies in a

given vulnerability setting,” in International Workshop on Critical
Information Infrastructures Security. Springer, 2006, pp. 67–78.

[21] H. Holm and K. K. Afridi, “An expert-based investigation of

the common vulnerability scoring system,” Computers & Security,
vol. 53, pp. 18–30, 2015.

[22] P. Johnson, R. Lagerström, M. Ekstedt, and U. Franke,

“Can the common vulnerability scoring system be trusted?
a bayesian analysis,” IEEE Transactions on Dependable and
Secure Computing, vol. 15, no. 6, pp. 1002–1015, 2018. doi:
10.1109/TDSC.2016.2644614

[23] A. Razaghpanah, A. A. Niaki, N. Vallina-Rodriguez, S. Sundaresan,

J. Amann, and P. Gill, “Studying tls usage in android apps,”
in Proceedings of the 13th International Conference on emerging
Networking EXperiments and Technologies, 2017, pp. 350–362.
42 | REFERENCES
 Appendix A: CVSS3 Vector String | 43

Appendix A

CVSS3 Vector String

Table A.1 contains the CVSS3 vector strings that were used to calculate
the CVSS value of the exploits.

Exploits
Name Vector String
SoundBlast CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N/E:F
IntentStorm CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H/E:F
Task Hijacking CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:L/E:F

Table A.1 – The exploits, with their CVSS3 Vector String

TRITA-EECS-EX-2021:249

www.kth.se