KTH ROYAL INSTITUTE

OF TECHNOLOGY

Degree Project in Computer Science and Engineering

Second cycle, 30 credits

Penetration Testing of an In-Vehicle

Infotainment System
PHILIP ANDERSSON

Stockholm, Sweden, 2022

Penetration Testing of an In-Vehicle
Infotainment System

PHILIP ANDERSSON

Degree Programme in Computer Science and Engineering

Date: July 5, 2022
Supervisors: Nikolaos Kakouros, Ismail Butun
Examiner: Benoit Baudry
School of Electrical Engineering and Computer Science
Swedish title: Penetrationstestning av ett Infotainmentsystem i Fordon
© 2022 Philip Andersson
 Abstract | i

Abstract
With the growing demand for smart and luxurious vehicles, the automotive
industry has moved toward developing technologies to enhance the in-vehicle
user experience. As a result, most vehicles today have a so-called In-Vehicle
Infotainment (IVI) system, or simply an infotainment system, which provides
a combination of information and entertainment in one system. IVI systems
are used to control, for instance, the audio, navigation, and air conditioning
in vehicles. Increasingly more IVI systems are also connected to the internet
which has enabled features such as web browsers and third-party apps on them.
This raises questions concerning the cybersecurity of IVI systems. As more
vehicles are connected to the internet, it increases the risk of vehicles getting
hacked. Previous research has shown that it is possible to take control of an
entire vehicle by hacking the IVI system.
In this thesis, penetration testing was conducted on an IVI system included
on a rig from Volvo Cars to find potential vulnerabilities in the system. To the
best of the author’s knowledge, this is the first paper describing penetration
tests performed on a greater attack surface of the Android Automotive
operating system used by the IVI system than previous research which only
focused on the attack surface of third-party apps. Moreover, threat modeling
was performed by employing the threat analysis and risk assessment part of
the ISO/SAE 21434: Road vehicles — Cybersecurity engineering. This has
not yet been done in the research area of security of IVI systems as far as the
author knows.
The results from the various penetration tests show that no major
vulnerabilities were discovered in the IVI system. However, several findings
were made in the thesis where the main one was that multiple content
providers, managing access to storage (e.g., relational databases) in Android,
were found to be exported by Android apps on the IVI system, and that some
of these were vulnerable to SQL injection. This vulnerability of some of the
content providers was exploited but did not lead to any collection of private
information. For future work, penetration testing of the cellular interface of
the IVI system is suggested.

Keywords
Cybersecurity, Penetration testing, In-Vehicle Infotainment system, Android
Automotive, ISO/SAE 21434
ii | Sammanfattning

Sammanfattning
Med en ökad efterfrågan för smarta och lyxiga fordon så har fordonsindustrin
behövt utveckla teknologier som förbättrar användarupplevelsen i fordon.
Ett resultat av detta är att de flesta fordon idag har ett så kallat infotain-
mentsystem vilket kombinerar information och underhållning i ett system.
Infotainmentsystem används till exempel för att styra ljudet, navigationen
och luftkonditioneringen i fordon. Fler infotainmentsystem börjar också
bli uppkopplade mot internet som möjliggör för användare att surfa på
internet och ladda ner tredjepartsappar. Detta väcker frågor beträffande
cybersäkerheten hos dessa. I takt med att fler fordon blir uppkopplade mot
internet så ökar det risken för att fordon blir hackade. Tidigare forskning har
visat att det är möjligt att ta kontroll över ett helt fordon genom att hacka
infotainmentsystemet.
I detta examensarbete har penetrationstestning utförts på ett infotain-
mentsystem som var inkluderad på en rigg från Volvo Personvagnar för att
hitta potentiella säkerhetsbrister i infotainmentsystemet. Till författarens bästa
vetskap är denna rapport den första som beskriver om penetrationstester
utförda på en större attackyta av operativsystemet Android Automotive
som används av infotainmentsystemet än tidigare forskning som bara har
fokuserat på tredjepartsappar som attackyta. Hotmodellering har också utförts
i examensarbetet enligt ett avsnitt kallad hotanalys och riskbedömning i
ISO/SAE 21434: Vägfordon — Process och metod för cybersäkerhet. Detta
har ännu inte gjorts inom forskningsområdet säkerhet för infotainmentsystem
så vitt författaren känner till.
Resultaten från de olika penetrationstesterna visar att inga allvarliga
säkerhetsbrister hittades i infotainmentsystemet. Dock gjordes flera upptäckter
under examensarbetet där den mest väsentliga var att ett flertal innehållsle-
verantörer, som hanterar åtkomst till lagring (t.ex. relationsdatabaser) i
Android, var exporterade från Android appar på infotainmentsystemet, och
att några av dem var sårbara till SQL-injektioner. Denna sårbarhet hos vissa
innehållsleverantörer utnyttjades men ledde inte till någon insamling av privat
information. Ett förslag för framtida arbeten är att utföra penetrationstestning
på det mobila gränssnittet hos infotainmentsystemet.

Nyckelord
Cybersäkerhet, Penetrationstestning, Infotainmentsystem i fordon, Android
Automotive, ISO/SAE 21434
 Acknowledgments | iii

Acknowledgments
First of all, from the bottom of my heart, I want to thank my parents. You have
always been there during my entire life, supporting me when I needed it the
most. Without you, I would not be where I am today. Thank you.

I would also like to thank my thesis supervisors, Nikolaos Kakouros and Ismail
Butun, for all of the help and invaluable feedback I received during the project.
I especially want to thank Nikolaos for managing the contact with Volvo Cars
and the suggestion regarding using the ISO/SAE 21434 TARA part in the
thesis, and Ismail, for all of the help I got when working in the NSE’s cyber
security lab on the rig.

Then, I would like to thank my main examiner, Benoit Baudry, for all of the
help throughout the project and the feedback on the report. I also would like
to thank my original examiner, Robert Lagerström, for setting up this project
and getting the rig from Volvo Cars to KTH.

Additionally, I would like to thank Porsev Aslan and Dana Ismail, who worked
in parallel on the rig from Volvo Cars with attack simulations and threat
modeling, for ideas on how to hack the IVI system and for showing me your
work which enabled me to understand the rig better.

Next, I would like to thank all of the people at Volvo Cars which have been
involved in this project and helped to answer the questions I had.

Finally, I would like to thank all of the nice people I have met and worked
with during my time at KTH.

Stockholm, July 2022

Philip Andersson
iv | Contents

Contents

1 Introduction 1
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Research Question . . . . . . . . . . . . . . . . . . . 3
1.1.2 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Research Method . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 6
2.1 Android Automotive . . . . . . . . . . . . . . . . . . . . . . 6
2.2 In-Vehicle Infotainment System Components . . . . . . . . . . 7
2.3 Electronic Control Units and In-Vehicle Networks . . . . . . . 8
2.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Protocol Stack . . . . . . . . . . . . . . . . . . . . . 9
2.4.2 Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Android Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 Manifest File . . . . . . . . . . . . . . . . . . . . . . 11
2.5.2 Activity . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.3 Content Providers . . . . . . . . . . . . . . . . . . . . 11
2.6 Structured Query Language . . . . . . . . . . . . . . . . . . . 12
2.6.1 SQL Injection . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Method 17
3.1 Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . 17
 Contents | v

3.1.1 Pre-engagement . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Information Gathering . . . . . . . . . . . . . . . . . 19
3.1.3 Threat Modeling . . . . . . . . . . . . . . . . . . . . 19
3.1.3.1 STRIDE . . . . . . . . . . . . . . . . . . . 20
3.1.4 Vulnerability Analysis . . . . . . . . . . . . . . . . . 20
3.1.5 Exploitation . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.6 Post Exploitation . . . . . . . . . . . . . . . . . . . . 21
3.1.7 Reporting . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 ISO/SAE 21434 — Threat Analysis and Risk Assessment . . . 21
3.3 Overview of Penetration Testing Stages . . . . . . . . . . . . 24

4 Target In-Vehicle Infotainment System 28

4.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.1 Infotainment Head Unit and Touchscreen . . . . . . . 28
4.1.2 Telematics and Connectivity Antenna Module . . . . . 30
4.1.3 Vehicle Gateway Module . . . . . . . . . . . . . . . . 30
4.2 Port Scanning and Enumeration . . . . . . . . . . . . . . . . 31
4.2.1 Network Ports . . . . . . . . . . . . . . . . . . . . . 31
4.2.2 Bluetooth Interface . . . . . . . . . . . . . . . . . . . 31

5 Threat Model 32
5.1 Asset Identification . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Impact Rating . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Threat Scenario Identification . . . . . . . . . . . . . . . . . 35
5.4 Attack Path Analysis . . . . . . . . . . . . . . . . . . . . . . 36
5.5 Attack Feasibility Rating . . . . . . . . . . . . . . . . . . . . 39
5.6 Risk Value Determination . . . . . . . . . . . . . . . . . . . . 40

6 Penetration Testing: Steps, Results & Discussion 42

6.1 Tools and Equipment . . . . . . . . . . . . . . . . . . . . . . 42
6.2 Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . 45
6.2.1 Privilege Escalation Paths on Infotainment Head Unit . 45
6.2.2 Static Analysis of Android Packages . . . . . . . . . . 46
6.2.3 Manual Analysis . . . . . . . . . . . . . . . . . . . . 47
6.2.4 Debugging Ports . . . . . . . . . . . . . . . . . . . . 47
6.3 Bluetooth Penetration Tests . . . . . . . . . . . . . . . . . . . 47
6.3.1 Denial-of-Service Attack . . . . . . . . . . . . . . . . 47
6.3.2 Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3.3 Address Sniffing . . . . . . . . . . . . . . . . . . . . 51
6.4 Penetration Testing Open Network Port . . . . . . . . . . . . 52
vi | Contents

6.5 Network Sniffing . . . . . . . . . . . . . . . . . . . . . . . . 54

6.6 Decompilation of Android Packages . . . . . . . . . . . . . . 55
6.7 Exploiting Activities and Content Providers . . . . . . . . . . 57

7 Discussion 63
7.1 Validity and Comparison of Results . . . . . . . . . . . . . . 63
7.2 Deviation from Weidman’s Methodology . . . . . . . . . . . 64
7.3 Sustainability and Ethics . . . . . . . . . . . . . . . . . . . . 66

8 Conclusion 68

9 Future Work 69

References 71
 List of Figures | vii

List of Figures

2.1 Typical components in an IVI system and how they are

connected. The connection between the TCU and the IHU is
different among IVI systems where some use one of the types
shown in the figure or none and instead communicate through
the IVNs. CAN-X denotes an arbitrary CAN link. . . . . . . . 8
2.2 Example of a Bluetooth protocol stack. . . . . . . . . . . . . . 10
2.3 Parts of a Bluetooth address. . . . . . . . . . . . . . . . . . . 10

3.1 Summary of penetration testing method used in the thesis. . . 18

3.2 ISO/SAE 21434 TARA steps employed in the thesis. . . . . . 22

4.1 Front of the rig. . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 A simple diagram of the target IVI system’s components and
how they were connected. . . . . . . . . . . . . . . . . . . . . 30

6.1 Ubertooth One. . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2 A sample MobSF scoreboard for one of the APKs from the IHU. 47
6.3 Accessible content URIs. . . . . . . . . . . . . . . . . . . . . 58
6.4 Content providers vulnerable to SQL injection. . . . . . . . . 59
6.5 Queried content URI for examination of the table fetched. . . . 60
6.6 The content provider manually tested for SQL injection
abusing the projection and selections fields in two separate
queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.7 SQL injection on the content provider results in all of the
tables in the database being shown. The image has been
cropped to improve the readability of the text in it. . . . . . . . 60
6.8 SQL injection on the content provider results in the contents
of a previously hidden and inaccessible table being shown. . . 61
viii | List of Tables

List of Tables

3.1 Safety impact rating criteria. . . . . . . . . . . . . . . . . . . 26

3.2 Attack feasibility rating criteria using the attack vector-based
approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1 Damage scenarios with associated assets and their cybersecu-

rity properties. Each damage scenario is assigned an ID. . . . 34
5.2 Safety and privacy impact ratings for each damage scenario. . 34
5.3 Threat scenarios and categories with associated damage
scenario. Each threat scenario is assigned an ID. . . . . . . . . 36
5.4 Attack paths of threat scenarios. Each attack path is assigned
an ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5 Attack feasibility rating for each attack path. . . . . . . . . . . 40
5.6 Risk values using the safety impact ratings. . . . . . . . . . . 41
5.7 Risk values using the privacy impact ratings. . . . . . . . . . . 41
 List of acronyms and abbreviations | ix

List of acronyms and abbreviations

ADB Android Debug Bridge

BLE Bluetooth Low Energy

Bluetooth Bluetooth Special Interest Group
SIG

CAN Controller Area Network

CVSS Common Vulnerability Scoring System

DHU Desktop Head Unit

DoIP Diagnostic communication over Internet Protocol
DoS Denial-of-Service

ECU Electronic Control Unit

GAS Google Automotive Services

HVAC Heating, Ventilation, and Air Conditioning

IEEE Institute of Electrical and Electronics Engineers

IHU Infotainment Head Unit
ISO International Organization for Standardization
IVI In-Vehicle Infotainment
IVN In-Vehicle Network

L2CAP Logical Link Control and Adaptation Protocol

LAP Lower Address Part
LMP Link Manager Protocol

MITM Man-In-The-Middle
MobSF Mobile Security Framework

NAP Non-significant Address Part

NDA Non-Disclosure Agreement

OEM Original Equipment Manufacturer

x | List of acronyms and abbreviations

OSINT Open Source Intelligence

OTA Over-the-Air
OUI Organizationally Unique Identifier

PCB Printed Circuit Board

RC Recommendation
RFCOMM Radio Frequency Communication
RQ Requirement

SAE Society of Automotive Engineers

SAP Significant Address Part
SDP Service Discovery Protocol
SQL Structured Query Language

TARA Threat Analysis and Risk Assessment

TCAM Telematics and Connectivity Antenna Module
TCU Telematic Control Unit
TLS Transport Layer Security

UAP Upper Address Part

URI Uniform Resource Identifier

VGM Vehicle Gateway Module

VHAL Vehicle Hardware Abstraction Layer

WLAN Wireless LAN

WP Work Product
 Introduction | 1

Chapter 1

Introduction

Increasingly more vehicles on the roads worldwide are connected to the

internet [1]. They are no longer just a means of transport but a computer
on wheels. Today’s vehicles have up to a hundred microprocessor-based
electronic control units (ECUs) and run ten to one hundred million lines of
code. Most modern vehicles come with an In-Vehicle Infotainment (IVI)
system, or simply an infotainment system, which provides a combination
of information and entertainment in one system. IVI systems controls, for
instance, the audio, navigation, and air conditioning in the vehicle. It is
common that IVI systems allow for connection with smartphones. In recent
years, there has also been an increase in IVI systems connected to the
internet [1]. This raises questions concerning the security of IVI systems as
the attack surface grows.
Penetration testing, also called ethical hacking, is a widely used method of
assessing the security of a system [2]. It simulates a real attack on a system by
searching for vulnerabilities that may be exploited. Contrary to a real attack
where the intention is to do damage, penetration testing includes reporting
found vulnerabilities to the owner and in the end improve the overall security
of the system.
In 2010, a group of security researchers showed that it was possible to
hack a vehicle by injecting messages into the Controller Area Network (CAN)
bus resulting in full control of the vehicle [3]. Since then there have been
several reports about attacks against vehicles, one of the most prominent being
when two security researchers Miller and Valasek successfully hacked a Jeep
Cherokee in 2015 [4]. They managed to remotely take over the vehicle and be
able to, for instance, disable the breaks, set the volume of the audio to the max,
and control the steering of the vehicle. This was possible due to a vulnerability
2 | Introduction

in the IVI system of the vehicle.

The articles by Eriksson et al. [5] and Palm & Gafvelin [6] also show that
IVI systems are vulnerable to attacks that may cause frustration and distract the
driver. Moreover, it was shown that private information such as the location
of the vehicle could be obtained from IVI systems.
In this thesis, penetration testing will be performed on a real-world physical
IVI system included on a rig from Volvo Cars. The objective is to investigate if
the IVI system has any vulnerabilities and if any of the potential vulnerabilities
can be exploited in a way that endangers the people in the vehicle on the road
or to obtain private information. The thesis will contribute to the research area
of automotive cybersecurity and ethical hacking. To the best of the author’s
knowledge, this will be the first paper to investigate a greater attack surface
of the Android Automotive operating system used by the IVI system than
previous research which only focused on the attack surface of third-party apps
in Android Automotive. Furthermore, all of the attacks will be conducted
on a physical IVI system running Android Automotive which is uncommon
in previous research where the OS mainly has been run on an infotainment
emulator. Moreover, the thesis will employ the threat modeling method of the
threat analysis and risk assessment (TARA) part of the ISO/SAE 21434: Road
vehicles — Cybersecurity engineering [7].

1.1 Problem Statement

All computer systems contain vulnerabilities because it is impossible to create
systems that are completely secure, and there will always be people that try
to hack systems by exploiting vulnerabilities and acting maliciously. IVI
systems are used in vehicles where safety is the top priority. Exploited
vulnerabilities in an IVI system could potentially result in an accident. Such
vulnerabilities would not only be dangerous for the people in the vehicle but
also for people in other vehicles, cyclists, and pedestrians on the road. Most
IVI systems also store private information and if such information is leaked
due to vulnerabilities in an IVI system, it could have a significant impact.
Therefore, it is important to evaluate the security of IVI systems which will
be done in this thesis by performing a penetration test on an IVI system from
Volvo Cars.
 Introduction | 3

1.1.1 Research Question

This thesis will investigate the following research question:

What vulnerabilities exist in an In-Vehicle Infotainment system from Volvo

Cars?

This thesis will also investigate the following two related sub-questions:

1. Can the system endanger the people in the vehicle and on the road?

2. Is it possible to obtain private information from the system?

To clarify what is meant by private information in sub-question 2, it is

information about the people in the vehicle, the vehicle itself, the system itself,
or Volvo Cars.

1.1.2 Hypothesis
Based on previous research, the hypothesis is that vulnerabilities exist in the
IVI system.

1.2 Purpose
The purpose of this thesis is to improve the overall security of the IVI system
and make it harder for a real hacker to attack the system. This will improve the
safety of the vehicle which benefits the people using it and people nearby, but
also Volvo Cars financially, as more people want to purchase a safer vehicle.
It will also strengthen the security against data breaches which can negatively
affect the people in the vehicle and Volvo Cars.
Academically, the purpose of this thesis is to further expand the research
area of automotive cybersecurity and ethical hacking of IVI systems.

1.3 Goals
One goal of this thesis project is to find potential vulnerabilities and let Volvo
Cars know about them so they can patch them. Another goal is to document
the method of threat modeling and how the penetration testing was carried out
on an IVI system.
4 | Introduction

1.4 Ethics
Ethics is a large part of penetration testing and this will be discussed further
in the thesis. Hacking a system without the owner’s permission is illegal,
which in Sweden is stated in the Swedish Criminal Code [8]. Therefore, it
is needed to first establish an agreement with Volvo Car before any sort of
penetration testing is conducted on their IVI system. The results and potential
vulnerabilities found during this project will be communicated to Volvo Cars
first through responsible disclosure so that they can patch the findings before
the thesis is published.

1.5 Research Method

The main method that will be used in the thesis is penetration testing, but
also a literature study focusing on two subjects. First, previous studies that
investigate the security of IVI systems including penetration tests made on IVI
systems. However, since this is a pretty narrow research area, the literature
study will also focus to some extent on previous studies on automotive
cybersecurity in general. The reason for doing this literature study is to survey
what has already been done in this area. Secondly, threat modeling which
is part of the penetration testing methodology since according to Lagerström
and Xiong [9], there is no common ground for threat modeling and numerous
definitions exist.
The penetration testing methodology used in this thesis will be based on
Georgia Weidman’s penetration testing methodology [2]. This methodology
will fully evaluate the security of the IVI system from Volvo Cars and in the
end, answer the research question. It is appropriate for this project because
of its nature where you need to test different ways of breaking and hacking
into the IVI system by finding and exploiting vulnerabilities. The TARA part
of ISO/SAE 21434 will be employed in the thesis and constitute the threat
modeling part of the penetration testing methodology instead of performing
traditional threat modeling where one definition is by Shostack [10].

1.6 Delimitations
One delimitation is that this thesis will not include patching of potential
vulnerabilities found in the IVI system. Another delimitation is that no In-
Vehicle Network (IVN) hacking will be performed in the thesis, for example,
 Introduction | 5

reverse engineer CAN messages and sending malicious packets to safety-

critical ECUs in a vehicle, which has previously been done in this research
area. Therefore, the following ports, available on the rig, will not be
penetration tested: OBD-II, FlexRay, LIN, and Body CAN. However, the
thesis will investigate if it is possible to access the IVNs from the IVI system.
During a large part of the project, there was an issue with the IVI system’s
internet connection. Towards the end of the project, this issue was solved
by setting the time and date on the IHU in the IVI system to the real values
which were mentioned as a possible solution during a meeting with Volvo
Cars. As a consequence, the cellular interface of the IVI system was not
penetration tested, and it was not considered in the threat modeling stage of
the thesis. Moreover, during the entire project, the IVI system did not have
any radio reception (AM/FM and DAB), and therefore, this attack surface was
not penetration tested and considered in the threat model.

1.7 Outline
This thesis consists of nine chapters and a section for references. In chapter 1,
this chapter, an introduction to the topic and the problem this thesis tries
to address are presented, and importantly the research question is stated.
Following in chapter 2 is the necessary background for the thesis and includes
related work. The method used in this thesis is then described in chapter 3.
In chapter 4, the target IVI system from Volvo Cars in focus of this thesis
is described. Chapter 5 shows how the threat modeling was performed by
employing the ISO/SAE 21434 TARA. In chapter 6, the steps, results, and
discussion of all of the penetration tests performed on the target IVI system are
described, and since each penetration test has a results section, no dedicated
chapter for the results exists in this thesis. Chapter 7 discuss the general results
of all penetration tests, the method chosen for this thesis, and the sustainability
and ethical aspects of the work. Chapter 8 outlines the main conclusions of this
thesis. Finally, in chapter 9, suggested work for future research is described.
6 | Background

Chapter 2

Background

This chapter will first describe the Android Automotive operating system and
IVI systems and their typical components. Then, ECUs and IVNs are briefly
described. Next, Bluetooth and technical information related to the technology
are described. Thereafter, this chapter will describe different components of
Android Apps and the technique of SQL injections. Finally, related work
on the security of IVI systems and automotive cybersecurity, in general, are
described, and the chapter ends with a summary.

2.1 Android Automotive

Android Automotive is an operating system that extends Android for vehicle
usage and runs natively on IVI systems [11]. It offers Google Automotive
Services (GAS) such as Google Maps, Google Assistant, and Google Play that
OEMs can choose to include. OEMs can customize the OS for their needs and
also develop their own apps for Android Automotive that come pre-installed
with the vehicle. Android Automotive should not be confused with Android
Auto which is a smartphone app that projects other apps such as navigation
onto an IVI system screen through USB. Google first announced Android
Automotive in March 2017 and Volvo Cars’ electric car brand Polestar was
the first to use Android Automotive [12]. The most critical part of Android
Automotive’s architecture is the Vehicle Hardware Abstraction Layer (VHAL),
as it is the interface between the OS and the IVN (described in section 2.3). It
is through the VHAL that Android Automotive can access and control vehicle
functions such as the HVAC and read data such as the speed and RPM [13,
14].
 Background | 7

2.2 In-Vehicle Infotainment System Compo-

nents
In-Vehicle Infotainment (IVI) systems consist of several different components.
Since there is no definition of an IVI system or no single architecture, a
typical IVI system is described here based on related work to help the reader
understand the terminology and all of the components of an IVI system.
Based on the papers [15, 16, 17, 4, 18] and the book [1], a typical IVI
system consists of the components described below. Figure 2.1 shows how the
different components are typically connected.
• Infotainment Head Unit (IHU): The IHU holds the functionality of the
radio, media, navigation, and sometimes climate controls. Furthermore,
it can also have a browser and third-party apps that can be downloaded
to it. An operating system such as Android Automotive is run on the
IHU. The IHU can sometimes have Bluetooth for playing media from
a smartphone and making phone calls, and it can act as a Wi-Fi access
point where the passengers can connect their smartphones for an internet
connection. It is common that the terms IVI and IHU, or sometimes
simply head unit, are used interchangeably.

• Touchscreen: The touchscreen is used to display the content and

navigate in the operating system used by the IHU.

• Central Gateway: There is often a central gateway between the

infotainment CAN and other IVNs (described in section 2.3). The main
purpose of the gateway is to connect different IVNs acting as a bridge
between them, but commonly also acting as a firewall that restricts
specific messages to be forwarded to other IVNs. For instance, without
the gateway, a user would not be able to control the HVAC from the IHU
if they are on different IVNs.

• Telematic Control Unit (TCU): The TCU provides an internet

connection to the IHU and the vehicle through a cellular network. It
also enables remote, mobility, and emergency services. An example
of remote service is Over-the-Air (OTA) updates. TCUs can also
have Bluetooth and act as a Wi-Fi access point inside a vehicle, and
sometimes replaces the utility of these if an IHU does not have these.

• Backend Server: The backend server communicates with the TCU in

vehicles through a cellular connection. It receives and handles data
8 | Background

such as mileage and failures of vehicles. The server can also be used
for distributing OTA updates to vehicles. Some manufacturers have an
app where users control some functions in their vehicles where the app
communicates with the vehicle through the backend server.

Figure 2.1: Typical components in an IVI system and how they are connected.
The connection between the TCU and the IHU is different among IVI systems
where some use one of the types shown in the figure or none and instead
communicate through the IVNs. CAN-X denotes an arbitrary CAN link.

2.3 Electronic Control Units and In-Vehicle

Networks
An electronic control unit (ECU) is an embedded system that is responsible
for one or more tasks of a vehicle [18]. For example, there is an ECU for the
brakes, steering, and doors. There are approximately 100 ECUs in a modern
vehicle on average.
ECUs need to communicate with each other, for example, opening a door
on a vehicle should be notified in the driver’s dashboard where an ECU
responsible for the doors needs to send a signal to the dashboard notifying the
driver a door was opened. This communication is performed over a so-called
In-Vehicle Network (IVN) where the most common one is called Controller
Area Network (CAN) bus. A modern vehicle contains multiple IVNs (e.g.,
 Background | 9

CAN, LIN, FlexRay) that have different speeds. More vehicles are also using
Ethernet which enables even higher speeds [18].

2.4 Bluetooth
Bluetooth, also known as IEEE 802.15, is a technology for short-range
wireless communication [19]. The Bluetooth Special Interest Group
(Bluetooth SIG) oversees the technology and publishes new Bluetooth
standards. Two types of Bluetooth exist called Bluetooth Classic and
Bluetooth Low Energy (BLE), both operating at the 2.4 GHz frequency band.
The main focus here is on Bluetooth Classic since this is used by the IHU
described in section 4.2.2.

2.4.1 Protocol Stack

Bluetooth is defined by multiple protocols in a layered architecture similar to
the TCP/IP model [19]. The Bluetooth protocol stack differs between different
implementations of the Bluetooth technology. In figure 2.2, an example of a
Bluetooth protocol stack is shown. The protocols relevant to this thesis are
described here. The Link Manager Protocol (LMP) is responsible for setting
up a link between Bluetooth devices. To determine the Bluetooth version,
the Link Manager version can be used since this usually corresponds to the
Bluetooth version. The Host Controller Interface (HCI) transports commands
and events between the host (above the dashed line in figure 2.2) and the
controller. One of the core protocols in Bluetooth is the Logical Link Control
and Adaptation Protocol (L2CAP) which provides an interface between the
upper-layer protocols and the Baseband layer. When Bluetooth devices want to
establish a connection, they needed to know what Bluetooth services are used
by the other devices. The Service Discovery Protocol (SDP) is used for this
which enables Bluetooth devices to query what Bluetooth services the others
are running. Another important protocol in the Bluetooth protocol stack is the
Radio Frequency Communication (RFCOMM) protocol that can be seen as a
virtual serial port, and it transforms serial signals into packets.

2.4.2 Address
The address of a Bluetooth interface is a unique 48-bit identifier. A Bluetooth
address is often shown in hexadecimal separated by colons, and it consists of
the three following parts: Non-significant Address Part (NAP), Upper Address
10 | Background

Figure 2.2: Example of a Bluetooth protocol stack.

Part (UAP), and Lower Address Part (LAP) [20]. These parts of a Bluetooth
address are shown in figure 2.3. The LAP is assigned by the vendor and the
UAP is used as a seed in Bluetooth specification algorithms. The NAP and
UAP parts together form the Organizationally Unique Identifier (OUI) that can
be used to determine the manufacturer of a Bluetooth device and is assigned
by the Institute of Electrical and Electronics Engineers (IEEE). There is also
a Significant Address Part (SAP) of a Bluetooth address formed by the UAP
and LAP together.

Figure 2.3: Parts of a Bluetooth address.

 Background | 11

2.5 Android Apps

2.5.1 Manifest File

All Android apps must have a manifest file that describes the information of
an app that is needed to build the app [21]. The manifest is also used to declare
the following: components of an app, permissions, and hardware and software
required by an app. The components of an app consist of activities, content
providers, and services. When an app requires special permissions to access
for example protected parts of the OS, this needs to be declared in the manifest.

2.5.2 Activity
An activity is a fundamental part of Android apps, a window where an app
draws its UI [22]. Usually, an activity covers the whole screen but can also
be only a part of the screen on top of another activity. An example of an
implementation of an activity is the Preference screen in an app.
Android apps can in the manifest file declare activities that it shares with
other apps on a device. This makes it possible for other apps to call an activity
of a specific app that is then displayed on the screen.

2.5.3 Content Providers

Content providers help apps to manage access and modification to stored
data [23]. An app itself can use them to access its data but they are intended to
be used by other apps on a device. Data are presented as one or more tables by
a content provider. Various data sources such as SQLite databases and image
files can be accessed using content providers.
Content providers use Uniform Resource Identifiers (URIs) to access a
table in a provider. A content URI consists of the full name of the content
provider and the name of the table to which it points.
When a content provider is queried, the URI needs to be specified. It is also
possible to specify the projection parameter which is an array of the columns
that the response should contain, and the selection parameter which specifies
the criteria for selecting rows.
12 | Background

2.6 Structured Query Language

Structured Query Language (SQL) is a widely used domain-specific language
and tool to manage relational databases which store data in the form of
tables [24]. SQL is mostly used to manage databases used by web applications
but also other applications such as mobile applications. Data in databases
can be accessed, modified, and deleted by SQL queries. The following
example is a simple SQL query that shows the syntax of SQL and some
of the main SQL statements: SELECT color, shape FROM object
WHERE color='blue'. This query fetches the columns called color and
shape where the value in the color column is equal to blue (row selection) from
a table called object in a database. SQL has many statements and operators
that can make queries complex. There are several implementations of SQL for
example MySQL, SQLite, and PostgreSQL which slightly differ in syntax.

2.6.1 SQL Injection

SQL injections abuse the syntax of SQL to insert arbitrary instructions. It
allows an attacker to interact with the database in a way that was not originally
intended. For example, an attacker could perform SQL injections to find other
tables in a database that contain sensitive information such as usernames and
passwords. SQL injection is possible when user input is part of a SQL query
that has not been correctly validated. Consider an application with a search
field where a user can enter a color and get a list of shapes with this color. The
application uses the same query as shown above except that there is a parameter
instead of the value blue which contains the user input entered in the search
field. An attacker could abuse this search field and enter the following SQL
code as text input: red'; DROP TABLE objects --. The whole query
would then look as follows: SELECT color, shape FROM object
WHERE color='red'; DROP TABLE objects --. This query now
consists of two SQL commands separated by the semicolon which is a special
SQL character for termination of command. The results of executing this
query would be that the objects table is removed from the database. The
additional two dashes, used in SQL for comments, at the end of the query
remove the single-quote character that would have been automatically put on
the right side of the color value by the application and makes it possible to
keep the syntax correct [24].
 Background | 13

2.7 Related Work

In 2021, Palm and Gafvelin [6] conducted a security and safety assessment
of third-party apps in Android Auto, using an infotainment emulator called
a Desktop Head Unit (DHU). The following three attacks were performed:
Task Hijacking, Intent Storm, and SoundBlast. The Task Hijacking attack
was unsuccessful when the smartphone was connected to the DHU, and
the SoundBlast attack was inconclusive since the DHU did not have any
volume controls. However, the Intent Storm attack was successful and caused
the DHU display to stop working. The USB communication between the
smartphone and the DHU was also investigated, and they discovered that the
communication channel used an encryption algorithm that had known exploits.
An article by Eriksson et al. [5] from 2019 assessed the security of third-
party apps in Android Automotive, where an IHU emulator and physical
testbeds from Volvo Cars were used. As in [6] similar SoundBlast and
Intent Storm attacks were performed, however, both attacks were successful.
They also performed a successful fork bomb attack by creating an app that
launched a new shell recursively resulting in the IHU emulator and testbeds
stop working. A permissionless exfiltration attack was also carried out where
they were able to record audio and send it to a remote server by forcing the
music player to load an URL and return a malformed music file without any
internet permission in the OS.
Moiz and Alalfi [25] in 2020 investigated the security of inter-component
communication used in Android. Their main focus was on Android
Automotive. Inter-component communication allows apps to communicate
with each other by using an object called intent. When an app wants to
broadcasts a message, intents are sent to all other apps in the OS. If an
app broadcasting does not specify that the permission of the receiving apps
needs to have equal permissions, it allows malicious apps to receive potential
sensitive information and send it to a remote server. Their experimental results
showed on a few hundred downloaded and decompiled apps from the Google
Play store that approximately half of them were vulnerable to this attack.
An article by Pese et al. [14] analyzed Android Automotive and its security
mechanisms. A high-level description of the OS is given, including the VHAL.
They describe the four permission levels used in Android Automotive called:
Normal, Dangerous, Signature, and signature|privileged. Third-party apps can
only use Normal and Dangerous permissions while pre-installed and OEM
apps have either Signature or signature|privileged permissions which allows
them to access the VHAL. They concluded that the permission model used in
14 | Background

Android Automotive needs improvement because it is too coarse-grained.

Miller and Valasek [4] in 2015 remotely hacked a Jeep Cherokee through
the IVI system. The attack enabled them to control vehicle functions such
as the steering and breaks but also the speaker volume. This resulted in 1.4
million vehicles getting recalled by the manufacturer. They were able to hack
the IVI system through Wi-Fi, Cellular, and USB. They first discovered an
open port on the Wi-Fi interface that they were able to connect to through
Telnet and that was used to communicate with one of the vehicle’s CAN
busses. Later, they found that the same port was open on the cellular interface.
In 2011, Checkoway et al. [26] performed the first threat model of the
external attack surface of vehicles. The following are some of the attack
vectors that were identified in the paper: USB, Bluetooth, Remote Keyless
Entry, and Cellular. A vulnerability analysis was then carried out and several
vulnerabilities were discovered, some giving full control of the vehicle. For
Bluetooth, they discovered it was vulnerable to buffer overflow due to the use
of strcpy in the code handling the Bluetooth functionality. Moreover, they
were able to brute force the PIN code used in the Bluetooth pairing process.
One article by Josephlal et al. [27] focused on finding Wi-Fi vulnerabilities
in an Android-based IVI system. The IVI system acted as a Wi-Fi client
connecting to an access point for an internet connection. Tools such as Nmap,
Nessus, and Metasploit were used. By using Nmap, they could determine the
IP address of the IVI system and find an open port on it. The Nessus tool was
then used to scan for vulnerabilities in the system and showed that the open port
made it possible for an adversary to obtain information about the system such
as its OS and version. A malicious Android Package (APK) file was created
using Metasploit and installed on the IVI system which opened a listening port.
Through this port on the Wi-Fi interface, they were able to compromise the IVI
system and steal information data such as photos and other files. Moreover, a
successful DoS attack on the Wi-Fi connection was achieved.
Yan et al. [17] in 2020 discovered 19 vulnerabilities in the IVI system used
in Mercedes-Benz E-Class models. The firmware of the TCU was obtained
and they found a debugging mode that had access to the CAN bus. They were
also able to obtain passwords and CA certificates for the car’s back-end server.
Dutch researcher at Computest [28] in 2018 investigated the security of a
shared IVI system used in a Volkswagen Golf and Audi A3 (having a later
version). Open ports on the Wi-Fi and cellular interfaces were found and
led them to find a vulnerability in one of the services that enabled arbitrary
code execution on the IVI system. However, they were not able to exploit
this vulnerability and send arbitrary CAN messages to control safety-critical
 Background | 15

components due to a gateway between the different CAN buses. They also
discovered that the USB port recognized some USB-to-Ethernet adapters used
as a debugging interface which also had the vulnerable service.
One research group that has hacked multiple cars and IVI systems is the
Tencent Keen Security Lab based in China. In 2016, they were the first to
report a remote attack compromising the CAN bus on a Tesla car [29]. Two
years later they found 14 vulnerabilities by analyzing the firmware acquired
from the IVI system used across several BMW models (e.g., BMW i3) [15].
They discovered that the IHU recognized USB-to-Ethernet adapters which
exposed many internal services. The USB port was also used to update the
IHU which they managed to exploit and obtain root privileges. Through
fuzzing the Bluetooth stack in the IHU and sending malformed packages, they
got the IHU to reboot when it was in pairing mode affecting the availability.
Remote control of the entire vehicle was also obtained by setting up a cellular
rogue base station and letting the vehicle connect to it. In 2021, the same
team investigated the security of the IVI system used in Mercedes-Benz cars
and discovered multiple vulnerabilities [16]. They found a hidden Wi-Fi
connection between the TCU and the IHU and were able to connect as TCU to
the IHU revealing TCP and UDP ports. There was one particular port assigned
to a protocol where they found several buffer overflow vulnerabilities that were
used to obtain a reverse shell. The IHU also had a web browser where a
JavaScript vulnerability was exploited to get a reverse shell.
There are two main books on the topic of hacking vehicles and IVI systems.
The first is The Car Hacker’s Handbook [30] by Craig Smith from 2016
which describes different embedded systems and bus protocols used in cars.
Furthermore, it covers various attack surfaces including an entire chapter on
attacking IVI systems. The second book is Hacking Connected Cars [1] by
Alissa Knight from 2020 which is more focused on remotely hacking cars. It
includes several examples of how to attack the IHU and TCU in an IVI system.
The first part of the book is also structured similar to Weidman’s penetration
testing methodology [2] which is the method used in this thesis.

2.8 Summary
This chapter has given the reader a foundation for this thesis. It started with
a description of Android Automotive which is used by the IVI system from
Volvo Cars. In order to understand the IVI system in focus and compare it
to other IVI systems, the typical components of IVI systems were described
in this chapter. Although ECUs and IVNs are not a major part of this thesis,
16 | Background

the reader needs to be familiar with these technologies. Some background on

Bluetooth, Android apps, and SQL injections were also described, needed for
the various penetration tests performed in the thesis. Lastly, this chapter ended
with quite an extensive literature review of previous research and books on the
security of Android Automotive, IVI systems, and vehicles in general.
 Method | 17

Chapter 3

Method

This chapter describes the research method of the thesis and how the project
was approached.

3.1 Penetration Testing

Penetration testing also called pen testing or ethical hacking is the method
of performing a simulated attack on a computer system or an electronic
device with the goal of finding exploitable security vulnerabilities [31]. A
person performing penetration testing is called a pentester. The purpose of
penetration testing is to improve the overall security of a system and find
vulnerabilities before a real attacker. There are many benefits of performing
penetration testing, for example, it reduces the risk of a system belonging to a
business being shut down by an attacker which would result in financial loss.
Commonly, automated tools such as Nmap, Nessus, and Metasploit are
used to both identify vulnerabilities and exploit them. Amongst these tools,
Nmap was used in this thesis. However, manual work is sometimes also needed
because these tools are known and therefore taken into account by the security
people responsible for a computer system.
There are three different types of penetration testing called black box,
grey box, and white box. In black box testing, the pentester has no or little
knowledge of a target system before starting which makes it the most difficult
type of penetration testing but also the most realistic. When the pentester has
partial information about the target, it is called grey box testing. Lastly, white
box testing is when the pentester is provided with all of the information about
the target system from the owner [31]. In this project, grey box pen testing
was performed since some information was given from Volvo Cars about the
18 | Method

different components of the IVI system and their software.

The method used in this thesis is based on Georgia Weidman’s penetration
testing methodology [2] which consists of seven stages to fully evaluate the
security of a computer system. These seven stages are described in the
following subsections. It is very similar to the penetration testing methodology
described in the Penetration Testing Execution Standard (PTES) [32].
Weidman’s methodology has previously been used in a thesis by Madeleine
Berner [33] which describes penetration testing performed on a smart garage
opener. Figure 3.1 summarizes the penetration testing method used in this
thesis.

Figure 3.1: Summary of penetration testing method used in the thesis.

 Method | 19

3.1.1 Pre-engagement
In this stage, the initial contact is made with the client that wants a system
to be penetration tested. It includes discussing and agreeing on the goals,
scope, and duration of the test. The scope should carefully state what will be
penetration tested in order to avoid situations where the pentester performs a
test that was not expected by the client. A non-disclosure agreement (NDA)
is usually signed in this stage by the pentester.

3.1.2 Information Gathering

This stage consists of collecting as much information as possible about the
target system. A pentester search after publicly available information such
as documentation of the system, which is known as open source intelligence
(OSINT) gathering. Contrary to OSINT where not a single packet is sent to
the target, scanning and enumeration techniques are performed in this stage to
identify for instance, what services and software the target system is running.
If the pentester has physical access to the system, it also includes performing a
physical examination and looking at available ports and antennas that could be
of interest as entry points. When this stage is completed, the pentester should
have a good idea of the system’s attack surface.

3.1.3 Threat Modeling

In the threat modeling stage, a pentester tries to think like a real attacker
and develops a plan to attack a computer system based on the information
gathered in the previous stage. Essentially, it is about identifying assets (i.e.
what to defend) and threats against these. According to Lagerström and
Xiong [9], there is no common ground for threat modeling and numerous
definitions exist. One of the most commonly used is the definition by
Shostack [10]. However, Shostack’s definition targets more traditional IT
systems and does not, for example, consider safety which is a major aspect
in the automotive field. Therefore, this thesis will employ the threat analysis
and risk assessment (TARA) part of the ISO/SAE 21434: Road vehicles —
Cybersecurity engineering [7] which is described in detail in section 3.2. This
will constitute the threat modeling of the thesis.
20 | Method

3.1.3.1 STRIDE

STRIDE is a widely used model in threat modeling to identify threats [9,

34]. This model will be used in the threat scenario identification step of the
ISO/SAE 21434 TARA part (see section 3.2) which mentions STRIDE as one
framework to use. The reason STRIDE is chosen out of the other frameworks
mentioned in the ISO/SAE 21434 TARA part is that it is easy to understand
and use. STRIDE is a mnemonic for the following six threat categories:
• Spoofing: Impersonating another user, process, or system component to
gain unauthorized access. Violates the property of authenticity.
• Tampering: Malicious altering of data/information on disk or in a
communication channel. Violates the property of integrity.
• Repudiation: Denying responsibility or action taken as a given user or
process. Violates the property of non-repudiation.
• Information Disclosure: Obtaining and releasing sensitive information
to unauthorized parties. Violates the property of confidentiality.
• Denial of Service: Making computer systems unavailable to its intended
users. Violates the property of availability.
• Elevation of Privilege: Increasing a user’s access rights to resources in a
system previously not accessible. Violates the property of authorization.

3.1.4 Vulnerability Analysis

Actively searching for vulnerabilities in a system is performed in this stage
by using automated tools and doing manual analysis. Vulnerability scanners,
which use vulnerability databases, are run against a target system. However,
performing manual analysis will improve the results of this stage when, for
example, the target has a new or uncommon service that is not covered by any
automated tool. The success of the next stage of exploitation is heavily based
on the quality of work done in this stage.

3.1.5 Exploitation
In this stage, the actual attack is made against a target system. A pentester
exploits vulnerabilities found in the previous stage, sometimes using an
existing tool. It is in this stage that the question is answered regarding if a
system is vulnerable.
 Method | 21

3.1.6 Post Exploitation

In this stage, a pentester is already inside a system and starts searching after
information in files for usernames and passwords, for instance. It is also in
this stage, that privilege escalation techniques are performed in an attempt to
fully compromise the machine. The exploited system might be connected to a
network not accessible from the outside that might be explored in this stage.

3.1.7 Reporting
The reporting stage consists of creating a report that explains what has been
done during the period of pen testing, it also includes findings and results of
the various tests. The report needs to be clear for the owner of the system to
be able to fix the vulnerabilities found during the pen test.
The findings and potential vulnerabilities discovered in this project will be
included in this thesis as responsible disclosure.

3.2 ISO/SAE 21434 — Threat Analysis and

Risk Assessment
The ISO/SAE 21434: Road vehicles — Cybersecurity engineering [7]
is a standard covering cybersecurity risk management and cybersecurity
processes throughout the lifecycle of road vehicles. It is the first standard on
cybersecurity in the automotive field, and it is a response to the automotive
cybersecurity issues and challenges that follow connected vehicles. The
standard was published in 2021 and developed by the joint working groups
of the International Organization for Standardization (ISO) and the Society of
Automotive Engineers (SAE) which is a professional organization mainly in
the transport industry.
This thesis will employ the threat analysis and risk assessment (TARA)
part (clause 15) of the ISO/SAE 21434 to perform threat modeling. It consists
of seven steps where only the first six are employed in the thesis. The seventh
step which is called risk treatment decision describes how to deal with the
risk calculated in the previous steps and will not be employed since it is not
relevant to the thesis. Each step in the TARA produces one or more so-
called work products (WPs) which are the results of fulfilling cybersecurity
requirements (RQs). Some of the steps also have recommendations (RCs).
There are mandatory prerequisites (inputs) for each step that consist of WPs
from previous steps.
22 | Method

Figure 3.2 shows the steps of the ISO/SAE 21434 TARA employed in the
thesis. Each arrow represents a WP from one step in the TARA which is a
prerequisite of another step.

Figure 3.2: ISO/SAE 21434 TARA steps employed in the thesis.

The following paragraphs describe each step of the TARA employed.

Due to copyright reasons, only the absolute minimum of the ISO/SAE
21434 TARA is described as required to understand the threat modeling part
(chapter 5) of the thesis. For a full explanation and the details of the ISO/SAE
21434 TARA, the reader is referred to the full standard [7].
The first step called asset identification has an item definition as a
prerequisite which is a WP from a previous clause in the ISO/SAE 21434. An
item is a component or set of components that function on the vehicle level, and
an item definition is an item and its functions, interactions, and interfaces. The
item definition in this thesis will be the IVI system and its functions described
in chapter 4. In this step, assets in an item and their cybersecurity properties
are identified. The CIA triad which stands for confidentiality, integrity, and
availability will be used as the cybersecurity properties. Damage scenarios,
 Method | 23

describing a scenario where a road user is harmed, are also identified which
compromise the cybersecurity properties of an asset.
The damage scenarios are then assessed in the second step called impact
rating based on what consequences they have for road users. The ISO/SAE
21434 uses four impact categories in which each damage scenario should be
assessed but only the categories of safety and privacy will be assessed since
the research question is related to these. The severity of the impact is assigned
one of the following labels (descending order of severity): severe, major,
moderate, and negligible. Table 3.1 will be used in the thesis for assessing
the safety impact rating of a damage scenario. This table which maps the
criteria for a safety impact to an impact rating label is based on the ISO 26262-
3:2018, section 6.4.3 [35], from which the ISO/SAE 21434 states the safety
impact ratings should be derived. The criteria in table 3.1 take into account
the severity of the damages and the controllability of the vehicle in a damage
scenario. Injuries to the driver, passengers, and people outside the vehicle
should all be considered when assessing the safety impact rating of a damage
scenario. Table F.4 on page 64 in the ISO/SAE 21434 will be used in the thesis
for assessing the privacy impact of a damage scenario.
The third step is threat scenario identification where threats against an
item’s assets are identified. A threat scenario describes a scenario where
the cybersecurity properties of an asset are compromised. The method of
identifying threat scenarios this thesis will use is according to STRIDE,
described in section 3.1.3.1. Each damage scenario is associated with one
or more threat scenarios.
In the fourth step called attack path analysis, attack paths are produced.
An attack path can be a list of steps that realize a threat scenario. However,
these can be imprecise since all of the details of an item are not yet known. In
this thesis, a top-down approach is used to produce the attack paths where
different ways of realizing the threat scenarios are analyzed, contrary to a
bottom-up approach where attack paths are produced based on vulnerabilities
already identified.
The attack paths are then assessed in the fifth step called attack feasibility
rating. The ISO/SAE 21434 has three RCs for methods of rating the attack
feasibility of an attack path where the attack vector-based approach was chosen
and will be used in this thesis. In this approach, the predominant attack vector
of an attack path determines the rating. Based on this approach and the RQs
in this step of the ISO/SAE 21434 TARA, table 3.2 was created which will be
used in the thesis for assessing the attack feasibility ratings of the attack paths.
The sixth and final step of the TARA is called risk value determination,
24 | Method

where a risk value of a threat scenario is obtained based on inputs to this step
which are the threat scenarios, impact ratings and attack feasibility ratings, as
shown in figure 3.2. Since the thesis will assess the impact rating for both
the safety and privacy category, two risk values are obtained for each threat
scenario. The risk values in this thesis are determined according to the risk
matrix in table H.8 on page 78 in the ISO/SAE 21434. The threat scenarios
with the highest risk values will motivate the tests in the penetration testing
stage of the project.

3.3 Overview of Penetration Testing Stages

An overview is provided here of the penetration testing stages in this thesis.
The penetration testing stages in this thesis are mainly based on the stages and
their order in Weidman’s methodology [2]. The difference between Weidman’s
methodology and the penetration testing methodology of this thesis is also
described here.
In the first stage, pre-engagement, a Non-Disclosure Agreement (NDA) is
signed with Volvo Cars. By signing this NDA, penetration testing is allowed
on their IVI system.
Following Weidman’s methodology, the information gathering stage is
carried out (described in chapter 4) where the information about the IVI
system from Volvo Cars is gathered from OSINT sources and port scanning is
performed using Nmap. Moreover, physical examination of the IVI system, as
well as Bluetooth enumeration, are performed in this thesis which is not any
work mentioned by Weidman. This information is needed to understand the
IVI system and successfully carry out the succeeding stages.
Threat modeling is subsequently performed (described in chapter 5)
according to the order of stages in Weidman’s methodology, and for this thesis,
the ISO/SAE 21434 TARA was chosen as the threat modeling method which
deviates from Weidman’s methodology. Threat modeling is a common step
when performing penetration testing but, to the best of the author’s knowledge,
this is the first study in the area of security of IVI systems that has performed
threat modeling by employing this standard. Performing threat modeling helps
identify serious threats against the IVI system and provides guidelines for the
actual penetration tests that will be carried out in a later stage.
Then, in the order of stages in Weidman’s methodology, a vulnerability
analysis is done (see chapter 6). None of the vulnerability scanners used
by Weidman are used in this thesis. Instead, other vulnerability scanners
and scripts, chosen by the author, have been used. However, manual
 Method | 25

vulnerability analysis which is suggested by Weidman is performed in this

thesis. Debugging ports on the PCBs of some of the components in the
IVI system are also searched for in this stage of the thesis which could
be a vulnerable entry point and is not any work mentioned by Weidman.
The vulnerabilities found in this stage are then attempted to be exploited in
penetration tests.
According to Weidman’s methodology, the exploitation and post exploita-
tion stages follow the vulnerability analysis stage. However, in this thesis,
these two stages are combined and constitute the penetration tests described
in chapter 6. Only existing tools are used in this thesis to perform penetration
tests, and these tools have been chosen by the author to be used and are not
any tools used by Weidman.
The last stage in Weidman’s methodology is reporting but in this thesis, the
reporting is carried out throughout this project by writing this thesis report.
26 | Method

Impact rating Criteria description

label
Severe Life-threatening and fatal injuries. Involves damage scenarios
where the vehicle is difficult to control or completely
uncontrollable. Also includes indirect difficult controllability.

Example situations:
– Front collision with another vehicle at a medium to high speed
where people in both vehicles are fatally injured due to brake
system malfunctioning.
– Pedestrian accident with life-threatening injuries due to steering
malfunctioning.
– Drive off a cliff due to the navigation showing a malicious left
turn resulting in life-threatening injuries for the people in the
vehicle (example of the controllability affected indirectly).

Major Severe injuries. The vehicle is normally controllable.

Example situations:
– Front collision with another vehicle at a low speed where people
in both vehicles are severely injured due to brake system
malfunctioning.
– Pedestrian accident with severe injuries due to steering
malfunctioning.

Moderate Light and moderate injuries. The vehicle is very controllable and
the driver can quickly fix problems in the vehicle.

Example situations:
– Driver shocked by music played at max volume and can quickly
turn it down but still keep good attention to the road. Driver get
light neck injuries by the shock.
– Injuries got when entering/exiting the vehicle.

Negligible The driver has full control of the vehicle and there are no injuries.

Table 3.1: Safety impact rating criteria.

 Method | 27

Attack feasibility Criteria description

rating
High Attack paths where an attack can be made from remote through a
network connection where the distance to the target is long.

Example of attack vectors:

– Cellular

Medium Attack paths where an attack can be made within a short range of
the target.

Example of attack vectors:

– Bluetooth
– Wi-Fi

Low Attack paths where an attacker has limited physical access to the
vehicle.

Example of attack vectors:

– USB port
– Install apps on IVI system
– SD card slot
– OBD-II port

Very low Attack paths where an attack has full physical access to the
vehicle and can disassemble components and access the IVNs.

Example of attack vectors:

– Ports on PCBs
– Direct access to CAN, Lin, and FlexRay

Table 3.2: Attack feasibility rating criteria using the attack vector-based
approach.
28 | Target In-Vehicle Infotainment System

Chapter 4

Target In-Vehicle Infotainment

System

This chapter describes the target system in detail, which is an IVI system
from Volvo Cars, and constitutes the information gathering stage described
in section 3.1.2. The information in this chapter was collected from OSINT
sources, physical examination, and enumeration. This information is needed
to understand the IVI system and later perform penetration tests on it. The
content of this chapter is the first original contribution of the thesis.

4.1 Components
The target IVI system was part of a rig from Volvo Cars which consisted of
multiple electronic components from a Volvo car. An image of the rig is shown
in figure 4.1. The following are the relevant IVI system components that were
available on the rig: touchscreen, IHU, Telematics and Connectivity Antenna
Module (TCAM), and Vehicle Gateway Module (VGM). A simple diagram
of how the IVI system’s components were connected is shown in figure 4.2.
Moreover, the following are the relevant ports available on the rig: USB, OBD-
II, FlexRay, LIN, and Body CAN.

4.1.1 Infotainment Head Unit and Touchscreen

The IHU was the main IVI component on the rig together with the touchscreen
that was used to navigate inside the Android Automotive operating system
running on the IHU. The OS used Android version 11 and kernel version 4.19.
Android Automotive on this IHU came with the following pre-installed apps:
 Target In-Vehicle Infotainment System | 29

Figure 4.1: Front of the rig.

Google Maps, Bluetooth Media Player, Radio, Phone, Google Assistant, Car
status, Google Play Store, and Owner’s Manual. The apps among these that
need further explanation are described here. In the Car status app, a user can
view information about the vehicle such as warnings. Google Assistant can
be used to, for instance, control the audio and navigation. On this IHU, the
Owner’s Manual app did not work and could not be used. Through the IHU a
user can also control the HVAC in the vehicle. Another feature of the IHU is
the possibility to have different profiles. One input to the IHU was the USB
port available on the rig.
By physical examination of the IHU, the following FCC ID was found
printed on the unit: LTQIHU4. An FCC ID is a unique identifier that most
computer hardware has and that can be useful to find information about the
hardware such as the manufacturer [36]. This FCC ID was searched on
30 | Target In-Vehicle Infotainment System

Figure 4.2: A simple diagram of the target IVI system’s components and how
they were connected.

https://fccid.io/ where multiple documents related to the IHU were

found. These included external images of the IHU showing the available types
of ports on the IHU. Internal images were also found showing the IHU having
two boards and a Bluetooth antenna. Several of the document were test reports
of the Bluetooth antenna stating the IHU uses Bluetooth 4.2. According to the
documents, the official name of the unit is VCC IHU 4.0 manufactured by
Aptiv Services Deutschland GmbH and is from 2019. The two boards inside
the IHU are called: HIGH DAB - Tuner board and HIGH DAB - Main board.
On the main board, there is an Intel Atom x5 A3940 microprocessor which is
part of the Atom A3900 series only sold to automotive customers [37].

4.1.2 Telematics and Connectivity Antenna Module

The Telematics and Connectivity Antenna Module (TCAM) on the rig is
equivalent to a TCU. The TCAM has the following functionalities: 2G,
3G, LTE, GNSS, Wi-Fi, and BLE [38]. It is manufactured by Continental
Automotive GmbH and has the following model number: TCAM1EU0.
The TCAM provides an LTE internet connection to the IHU. It is also used
by the IHU to connect to Wi-Fi networks.

4.1.3 Vehicle Gateway Module

The Vehicle Gateway Module (VGM), also called Vehicle Connectivity
Module, acts as a bridge between the IVNs on the rig [39]. Because the rig had
an OBD-II port which is used to access the CAN bus this was one of the IVNs
on the rig. There was also a port labeled FlexRay on the rig which meant that
FlexRay was another IVN present on the rig. At least one of these two IVNs
was believed to be used by the IVI system.
 Target In-Vehicle Infotainment System | 31

4.2 Port Scanning and Enumeration

4.2.1 Network Ports

A port scan was made on the IVI system to identify potential open network
ports. The system was first connected to a Wi-Fi network and then a laptop
with the tool Nmap (described in section 6.1) was connected to the same
network to scan the ports of the IVI system. The IP address of the IVI system
was found by looking at the client names and their corresponding IP addresses
in the Wireless LAN (WLAN). A full Nmap scan was subsequently performed
on the IVI system where only one port was found to be open which was port
13402. However, Nmap could not identify the service of this port.

4.2.2 Bluetooth Interface

The Bluetooth interface of the IHU was examined using a laptop running
Linux. Linux uses the BlueZ Bluetooth stack and comes with several BlueZ
tools [40]. In the IHU, the Bluetooth was first turned on and set to discoverable
mode. By performing scans on the laptop after available nearby available
devices it was determined that the IHU used Bluetooth Classic and not BLE.
During the scans, the IHU showed up as Volvo followed by a model name.
The laptop was then paired to the IHU which required user interaction on both
devices consisting of confirming a matching code.
A tool called hcitool was used on the Bluetooth MAC address of
the interface. It showed that the interface was using Bluetooth 4.2 which
confirmed the Bluetooth version since this was the same as stated in the
Bluetooth test documents described in section 4.1.1. Another tool used was
sdptool (described in section 6.1) to find available Bluetooth services on
the IHU and their names are shown in the following list:
– Audio Sink
– A/V Remote Control Target
– Advanced Audio Distribution
– A/V Remote Control
– PANU
– NAP
– Handsfree
– Message Notification Service
– PnP Information
– Generic Access Profile
32 | Threat Model

Chapter 5

Threat Model

This chapter shows how threat modeling was performed in the project. The
threat modeling stage of the penetration testing methodology (described in
section 3.1.3) is constituted by this chapter. The ISO/SAE 21434 TARA was
employed as described in section 3.2.

5.1 Asset Identification

Assets of the target IVI system were first identified as step one in the ISO/SAE
21434 TARA. One asset that was identified was the Bluetooth interface of
the IVI system and its data commutation. This Bluetooth interface enables the
driver to, for instance, connect his/her smartphone to the IHU and make hands-
free phone calls. It was considered an important asset since if the Bluetooth
communication becomes unavailable, a driver could not use the Bluetooth
services which reduces the attention to the road and could endanger people
on the road. In table 5.1, this constitute damage scenario 1.
Another asset that was identified was the IHU which potentially contains
private information. The IHU is the main component of the IVI system from
Volvo Cars and therefore it was considered an important asset. A damage
scenario related to this asset, that could have serious consequences, is the
disclosure of private information such as a home address, usernames, and
passwords found on the IHU without the consent of the people using it. In
table 5.1, this make up damage scenario 2.
Previous research as the articles [17] and [15] has obtained the firmware
of the IVI system which made it possible to reverse engineer it and find
vulnerabilities that were exploited. Therefore, the firmware of the target IVI
system’s components was also identified as an asset. Disclosure of the target
 Threat Model | 33

system’s firmware without the manufacturer’s consent is a damage scenario, as

shown by previous research. In table 5.1, this constitutes damage scenario 3.
Another asset that was identified was the Wi-Fi interface of the target IVI
system and the traffic going through it. Disclosure of information such as
usernames and passwords in the traffic after being captured without the consent
of the people in the vehicle could have serious consequences. Since the IVI
system is produced by Volvo Cars, the traffic could also contain confidential
information related to them. For this reason, this is a damage scenario that
could damage the users of the vehicles with this IVI system, and Volvo Cars.
In table 5.1, this make up damage scenario 4.

Asset Cybersecurity property Damage scenario ID

C I A
Data commu- – – X The driver cannot connect 1
nication: his/her smartphone to the
Bluetooth IHU through Bluetooth
and use for instance
hands-free and message
notification service. This
leads to reduced attention
to the road.
Private X – – Disclosure of private 2
information in information such as
the IHU current location, home
address, usernames, and
passwords obtained from
the IHU without the driver
and passengers’ consent.
Firmware of X – – Disclosure of the firmware 3
the IVI of the IVI system’s
system’s components without the
components manufacturer’s consent.
34 | Threat Model

IVI system’s X – – Disclosure of sensitive 4

network traffic: information such as
Wi-Fi usernames and passwords
obtained from the IVI
system’s network traffic
without the consent of the
people in the vehicle or
Volvo Cars.
Table 5.1: Damage scenarios with associated assets and their
cybersecurity properties. Each damage scenario is assigned
an ID.

5.2 Impact Rating

The second step of the ISO/SAE 21434 TARA was to rate the impact of each
damage scenario. Thus, the impact of each damage scenario in table 5.1
were rated in the categories safety and privacy. Table 5.2 shows the impact
ratings for each of the damage scenarios which were assessed based on the
safety criteria shown in table 3.1 and privacy criteria shown in table F.4 in the
ISO/SAE 21434. A motivation for each rating is given below.

Damage scenario Safety Privacy

1 Moderate Negligible
2 Negligible Major
3 Negligible Moderate
4 Negligible Major
Table 5.2: Safety and privacy impact ratings for each damage
scenario.

For damage scenario 1, the safety impact was assessed to be moderate since
the vehicle would still be very controllable if the Bluetooth interface of the IHU
would become unavailable. Furthermore, potential injuries of other people
around the vehicle would likely be light or moderate, as a consequence of the
reduced attention to the road, and maps to a safety impact rating of moderate.
The privacy impact of this damage scenario was assessed to be negligible since
no personal information is leaked when the Bluetooth interface is unavailable.
 Threat Model | 35

The safety impact for damage scenario 2 was assessed to be negligible, as

disclosure of private information in the IHU does not affect the safety of the
driver or passengers. However, damage scenario 2 affects the privacy of the
people in the vehicle with the target IVI system, and disclosure of for instance
passwords could lead to serious consequences. Therefore, the privacy impact
rating was set to major.
For damage scenario 3, the safety impact was assessed to be negligible
since disclosure of the firmware of the IVI system’s components is not related
to safety. The privacy impact rating was set to moderate, as disclosing the
firmware reveals information that Volvo Cars does not want to be public.
However, it is not as severe as the disclosure of passwords, for instance, which
lowers the impact rating for this damage scenario.
The safety impact rating for damage scenario 4 was set to negligible since
disclosure of sensitive information in the network traffic going through the Wi-
Fi interface of the IVI system is not related to safety. The privacy impact of
this damage scenario was assessed to be major, as disclosure of for instance
passwords could lead to serious consequences.

5.3 Threat Scenario Identification

In the third step of the TARA, threat scenarios were identified that compromise
the cybersecurity properties of the assets shown in table 5.1. Each asset
and its corresponding damage scenario is associated with one or more threat
scenarios.
One threat scenario was identified for damage scenario 1, shown in table
5.3 as threat scenario 1. DoS is the only threat category in STRIDE that
compromises the cybersecurity property of the Bluetooth data communication
asset which is availability.
For damage scenario 2, three threat scenarios was identified, shown in table
5.3 as threat scenario 2, 3, and 4. All of these threat scenarios describe threats
that are of the type information disclosure amongst the STRIDE categories, as
the asset, private information in the IHU, have the cybersecurity property of
confidentiality which is compromised when disclosed.
In table 5.3, threat scenario 5 was identified that compromised the
cybersecurity property of the asset, firmware of the IVI system’s components,
and this threat scenario is associated with damage scenario 3. Amongst the
threat categories in STRIDE, information disclosure is the only threat that
compromises the confidentiality property of the asset.
36 | Threat Model

One threat scenario was identified for damage scenario 4, shown in table
5.3 as threat scenario 6. Since the cybersecurity property of the asset, IVI
system’s Wi-Fi network traffic, is confidentiality the only threat category in
STRIDE is information disclosure.
Damage Threat Threat scenario ID
scenario
1 DoS Crash the Bluetooth interface used by the IHU 1
that results in the loss of availability of the
Bluetooth communication.
2 Information Compromise the operating system of the IHU 2
disclosure to access all information in it which leads to
the loss of confidentiality.
2 Information Extract private information from pre-installed 3
disclosure apps on the IHU. The compromised
cybersecurity property is confidentiality.
2 Information Exploit the open port on the IVI system with 4
disclosure port number 13402 to gain access to the
system and information on it which results in
the loss of confidentiality.
3 Information Extraction of the firmware of the IVI system’s 5
disclosure components which leads to the loss of
confidentiality.
4 Information Extract sensitive information from network 6
disclosure traffic captured from the IVI system. The
compromised cybersecurity property is
confidentiality.
Table 5.3: Threat scenarios and categories with associated
damage scenario. Each threat scenario is assigned an ID.

5.4 Attack Path Analysis

The fourth step of the TARA consisted of producing attack paths that realized
the treat scenarios in table 5.3. As described in section 3.2, a top-down
approach was chosen in the thesis to produce the attack paths in table 5.4.
Producing attack path 1, which realizes threat scenario 1, was straight-
forward since it describes an attack where flooding of Bluetooth packets is
performed. Attack path 2, which also realizes threat scenario 1, describes
 Threat Model | 37

where fuzzing is performed as a way to crash the Bluetooth interface, and the
idea behind this attack path came from [15] which has also performed fuzzing
on the Bluetooth interface of an IVI system.
Based on the knowledge that the IHU has a USB port and that Android
Automotive is the OS running on it, which potentially could mean that adb
(described in section 6.1) is available, attack path 3 was produced which
realizes threat scenario 2. Furthermore, to compromise the OS and get access
to all information in it, which was the goal of threat scenario 2, privilege
escalation is part of the attack path so that then an attacker can search for
sensitive information in all of the files on the IHU.
With the same reasoning regarding the availability of adb together with the
idea of exploiting pre-installed apps on the IHU, attack path 4 was produced
which realizes threat scenario 3. Previous research as [5] has focused on
exploiting third-party apps, this attack path describes an attack where pre-
installed apps on the IHU are exploited by targeting potentially exported
information from them.
Attack path 5, realizing threat scenario 4, describes an attack where the
attack vector is the Wi-Fi interface of the IVI system and the open network port
previously discovered, described in section 4.2. Before an attacker can access
the open port on the IVI system, the attacker needs to be on the same network
to which the IVI system is connected, and therefore, the idea of performing
an evil twin attack was thought of as a way for an attacker to access the open
port. Once an attacker has access, the attacker then tries to exploit the open
port number to potentially obtain a shell in the OS through Telnet, for instance
as previously tried in [4], to then search for sensitive information in the IVI
system and compromise the cybersecurity property of the asset.
To realize threat scenario 5, attack path 6 was produced. One way of
extracting the firmware from devices is to use debugging ports such as JTAG
and UART on PCBs [41], hence this attack path. The first step though is
to disassemble the different components of the target IVI system before an
attacker can access potential available debugging ports.
Attack path 7 was produced to realize threat scenario 6. To capture network
traffic going through the Wi-Fi interface of the IVI system, an attacker needs
to be at a medium to close distance from the target IVI system and have access
to the router to which the IVI system is connected. This is accomplished
by following the same steps 1-2 of attack path 5. Subsequently, an attacker
can start capturing traffic to then analyze it and search for potential sensitive
information in it which if found would compromise the cybersecurity property
of the asset.
38 | Threat Model

Threat Attack path ID

scenario
1 1
1. An attacker gets into the vicinity of the target Bluetooth
interface of the IHU.
2. Performs Bluetooth traffic sniffing to find the address
of the Bluetooth interface.
3. Performs an L2CAP layer flooding attack to crash the
Bluetooth interface.

1 2
1. An attacker performs steps 1-2 of attack path 1.
2. Uses a fuzzing tool to crash the Bluetooth interface.

2 3
1. An attacker locally gets access to the IHU and connects
to it through USB.
2. Uses adb potentially available in the IHU to obtain a
shell in the OS.
3. Performs privilege escalation techniques to compro-
mise the OS.
4. Searches for sensitive information.

3 4
1. An attacker locally gets access to the IHU and connects
to it through USB.
2. Creates a malicious app that can extract information
exported by the pre-installed apps on the IHU.
3. Installs the app on the IHU through adb potentially
available on the unit.
4. Uses the app to extract potential sensitive information
exported by the pre-installed apps on the IHU.
 Threat Model | 39

4 5
1. An attacker gets into the vicinity of the target Wi-Fi
interface of the IVI system.
2. Sets up an evil twin Wi-Fi network to potentially get
the IVI system to connect to it. This could be done in
a public space, for example, a gas station.
3. Tries to exploit the open port on the IVI system with
port number 13402 to potentially obtain a shell in the
OS.
4. Searches for sensitive information.

5 6
1. An attacker disassembles all of the components in the
IVI system to access the PCB(s) in them.
2. Searches for available debugging ports such as JTAG
and UART on the PCBs.
3. Connects to all available debugging ports.
4. Potentially extracts the firmware of the IVI system’s
components.

6 7
1. An attacker performs steps 1-2 of the attack path 5.
2. Starts capturing traffic on the Wi-Fi router.
3. Analyses the traffic captured to find potential sensitive
information.

Table 5.4: Attack paths of threat scenarios. Each attack path

is assigned an ID.

5.5 Attack Feasibility Rating

Following the fifth step of the TARA, the feasibility of each attack path shown
in table 5.4 was assessed according to the rating criteria described in table 3.2.
The attack feasibility rating for each attack path is shown in table 5.5, and a
motivation for each rating is given below.
40 | Threat Model

Attack path Attack feasibility rating (attack

vector-based approach)
1 Medium
2 Medium
3 Low
4 Low
5 Medium
6 Very low
7 Medium
Table 5.5: Attack feasibility rating for each attack path.

The feasibility of attack paths 1 and 2 was assessed to be medium since

the predominant attack vector in these attack paths was Bluetooth. The reason
that Bluetooth is the predominant attack vector in these attack paths is that this
determines the distance an attacker needs to be to the IVI system.
For attack paths 3 and 4, the feasibility of them was assessed to be low, as
the USB port of the IVI system was the predominant attack vector in them. An
attacker needs access to the USB port to carry out the rest of the steps in these
attack paths and therefore, the USB port is the predominant attack vector.
The predominant attack vector in attack paths 5 and 7 was the Wi-Fi since
this is a short-range wireless network which means that an attacker needs to
be within a short range of the IVI system. Therefore, the feasibility of these
attack paths was rated as medium.
To perform attack path 6 and disassemble the components of the IVI
system, an attacker needs to have full physical access to the vehicle and the
system. Hence, the attack feasibility rating of very low for this attack path.

5.6 Risk Value Determination

The last step of the TARA consisted of determining the risk value of each
threat scenario based on the rating of its impact and the attack feasibility of
the attack path realizing the threat scenario. Tables 5.6 and 5.7 shows the risk
value of each threat scenario which was determined using a risk matrix in the
ISO/SAE 21434, as described in section 3.2. The entries with a risk value
of 1 were omitted in the tables below, most of these exist because the impact
ratings were negligible in an impact category that was not relevant to a damage
scenario.
 Threat Model | 41

Damage Threat Attack path Risk value

scenario scenario
1 1 1 2
1 1 2 2
Table 5.6: Risk values using the safety impact ratings.

Damage Threat Attack path Risk value

scenario scenario
2 2 3 2
2 3 4 2
2 4 5 3
4 6 7 3
Table 5.7: Risk values using the privacy impact ratings.
42 | Penetration Testing: Steps, Results & Discussion

Chapter 6

Penetration Testing: Steps,

Results & Discussion

This chapter will first describe the tools and equipment used during the
project, and the work which was performed in the vulnerability analysis
stage (see section 3.1.4). Then, all of the penetration tests conducted on the
target IVI system are described, which correspond to the exploitation and
post exploitation stages (see sections 3.1.5 and 3.1.6). The steps, results,
and discussion of each penetration test will be described in this chapter.
Additionally, an introduction is provided for each penetration test, and a more
specific background is given for some of the penetration tests.

6.1 Tools and Equipment

Laptop and Smartphone

A laptop running the Linux distribution Ubuntu version 20.04 LTS was
used during the project. A Samsung Galaxy S8 smartphone was also used,
especially in Bluetooth-related penetration tests.

Nmap

Nmap which stands for Network Mapper is a common penetration testing tool
that is used to discover, manage and monitor networks [42]. It can be used
to find available hosts in a network and information about them such as their
hostnames and what OS they are running. A common task is to use Nmap for
finding open ports used by services on a host where it also tries to determine
the name and version of the services.
 Penetration Testing: Steps, Results & Discussion | 43

sdptool

sdptool is a Linux command that is used to perform SDP queries on

Bluetooth devices. When using the browse option, sdptool will present
all available services used by a specified Bluetooth device [43].

l2ping

l2ping is a Linux command that sends an L2CAP echo request to a given

Bluetooth MAC address and waits for a response [44]. Options to this
command include specifying the number of packets to send and the size of
these. There is also a flood option which reduces the time between packets
being sent to zero.

adb

The Android Debug Bridge (ADB) is a command-line tool that is used

to communicate with Android devices [45]. It offers functionalities such
as installing and debugging of apps and can provide a shell on a device.
Furthermore, it can also be used to list and pull packages from a device, take
screenshots on a device and move files to and from a device. adb is used on
a computer connected over USB to an Android device where the device must
have the USB debugging mode enabled.
adb is a program that consists of the three following components: client,
daemon, and server. The client is on the machine which sends adb commands
to the connected device. The server on the device manages the communication
with the client and forwards commands to the daemon which runs the
commands on the device.
On the IVI system from Volvo Cars, adb was only available for
development meaning that it was completely disabled for vehicles on the
market. However, with software updates in the future, it will be enabled.

MobSF

Mobile Security Framework (MobSF) is a mobile application security

assessment framework for Android, iOS, and Windows [46]. It can perform
static and dynamic analysis of for instance Android Packages (APKs) and find
potential vulnerabilities. After a package is analyzed, it gives a security score
between 0 and 100 where the latter represents the best level of security. MobSF
is a web application that is run on a local host.
44 | Penetration Testing: Steps, Results & Discussion

Ubertooth One

Ubertooth One is a hardware tool, part of Project Ubertooth which is open-

source [47]. The project also consists of the development of the firmware to
the Ubertooth One and the host code which is run on a machine connected
to the Ubertooth One via USB that controls it. The features of the Ubertooth
One are mainly for BLE devices but it also has some capabilities for Bluetooth
Classic devices. One feature of the Ubertooth One is that it can sniff Bluetooth
packets between connected devices. Another feature is that it can perform LAP
sniffing of Bluetooth devices in the vicinity. An image of the Ubertooth One
is shown in figure 6.1.

Figure 6.1: Ubertooth One.

Telnet

Telnet is a network application protocol that is used for remote terminal access
on another machine [48]. Telnet uses the default port number 23. The
connection between the client and server is not encrypted.

Wireshark

Wireshark is one of the most widely used network traffic analyzers available
that support over several hundred protocols [49]. It can be used to live capture
network traffic but also analyze already captured traffic. A user can filter
packets based on, for instance, the IP address or protocol.
 Penetration Testing: Steps, Results & Discussion | 45

tcpdump

tcpdump is a command-line packet analyzer and network traffic capture

tool [50]. There are multiple tcpdump filters that determine what traffic is
captured. One useful feature of tcpdump is that it can write the output to
a .pcap file which can be used to open the captured traffic in Wireshark, and
therefore tcpdump and Wireshark are often used together.

jadx

jadx is a decompiler of APKs that offers both a command-line interface and a

GUI to examine decompiled code [51]. APKs are decompiled into Java source
code but include errors since jadx cannot fully reconstruct the original source
code. One feature of the GUI is that it can jump to the declaration of classes,
methods, and variables.

Drozer

Drozer is a tool used to simulate a rogue application on an Android device.

The tool was developed by F-Secure Labs but stopped development in 2017.
Drozer is now open-source and maintained by MWR InfoSecurity. One feature
of Drozer is that it can exploit exported Activities and Content Providers from
other Android apps on a device.
Drozer is installed on a machine that communicates by using adb with
the so-called Drozer Agent which is an Android app that needs to be installed
on the target device. The Drozer Agent is used to open a port on the target
device and start a server. Then, a Drozer session can be started on the
attacking machine where various Drozer modules exist for tasks such as device
interaction (e.g., shell), scanning, and exploitation [52, 53].

6.2 Vulnerability Analysis

6.2.1 Privilege Escalation Paths on Infotainment Head

Unit
A privilege escalation script called LinPEAS (Linux Privilege Escalation
Awesome Script) [54] was executed in a shell provided by adb on the
IHU. LinPEAS searches after possible privilege escalation paths on Linux-
based machines and displays information about the machine. It goes through
multiple common privilege escalation techniques according to a checklist [55]
46 | Penetration Testing: Steps, Results & Discussion

written by the same creator of the script. If the script finds any technique that
potentially allows an elevation of privilege on a machine it is highlighted by
the script.
The script was first transferred to the IHU through adb and then executed.
No high probability privilege escalation techniques were found by the script.
However, the script indicated a few possible lower probability privilege
escalation techniques to examine, but all of these were false positives. Some
useful information about the IHU was obtained by using the script. It was
discovered the IHU had Netcat installed. The script also listed the network
interfaces of IHU where one was called modem_oem0 and was assigned an
IP address to a subnet only consisting of 2 hosts. It was believed that this
subnet was used for communication between the IHU and the TCAM.

6.2.2 Static Analysis of Android Packages

Multiple Android packages (APKs) were pulled from the IHU using adb. The
packages containing one of the following words in the package name were
mainly selected for static analysis: volvo, volvocars, vcc (volvocarscompany),
and aptiv. MobSF was used for performing the static analysis of the APKs.
The results from the static analysis by MobSF showed that multiple APKs
had several potential vulnerabilities. Some APKs had one or more Content
Providers exported making them accessible to any other app on an Android
device and were graded as high severity by MobSF. The majority of the APKs
exported Activities potentially making it possible for other apps to access an
Activity with sensitive information and bypass some sort of authentication
to access it. MobSF found that a small number of APKs could be backed up
making it possible to copy application data and was graded as medium severity.
The average MobSF security score for the APKs analyzed was 58.6. In figure
6.2, a sample MobSF scoreboard is shown for one of the APKs analyzed.
Another feature of MobSF is that it searches for secrets in APKs such as
passwords, URLs, API keys, and tokens. MobSF found multiple URLs in
the APKs but most of these were not interesting. However, the following
interesting URL was found: https://in-car.volvo.care/. When
using this URL in a browser, it returned an HTTP 404 Not Found error.
MobSF also found a few strings classified as hardcoded secrets in some of the
APKs, but all of these were false positives and did not contain any sensitive
information.
 Penetration Testing: Steps, Results & Discussion | 47

Figure 6.2: A sample MobSF scoreboard for one of the APKs from the IHU.

6.2.3 Manual Analysis

From the information gathering stage, it was discovered that the IHU
had an Intel Atom x5 A3940 microprocessor. Vulnerabilities related
to this microprocessor were searched for on the internet. One known
vulnerability was found with the following CVEID: CVE-2019-0154 [56].
This vulnerability affects a wider range of Intel processors and the Intel Atom
x5 A3940 is one of them. The vulnerability "may allow an authenticated user
to potentially enable denial of service via local access" [56] and has a Common
Vulnerability Scoring System (CVSS) v3 score of 5.5 (medium). The CVE-
2019-0154 is also confirmed by Intel [57].

6.2.4 Debugging Ports

Both the IHU and the TCAM were disassembled to examine the printed
circuit boards (PCBs) inside these. Debugging ports such as JTAG and UART
were searched after on the PCBs which could pose a risk of hardware-related
vulnerabilities, for example, firmware extraction [41]. But no debugging ports
were found.

6.3 Bluetooth Penetration Tests

6.3.1 Denial-of-Service Attack

Introduction

The IHU had a Bluetooth interface that was used to, for instance, play music
and make calls from a smartphone. The goal of this penetration test was
48 | Penetration Testing: Steps, Results & Discussion

to examine how well this Bluetooth interface withstood a Denial-of-Service

(DoS) attack and affected the availability of the Bluetooth features.
The motivation for performing this penetration test is threat scenario 1,
identified in the TARA (see section 5.3). Furthermore, the steps in attack path
1 (see table 5.4) are used as guidelines for this penetration test.

Background

A script called Bluetooth DOS-Attack Script [58] from GitHub was used in
this test. This script tries to make it impossible for new devices to connect to
the target and does not affect the already established connections. It does this
by using l2ping with the flood option and targets the L2CAP layer. When the
script is started, it takes the following three inputs: target Bluetooth address,
size of the packages, and the number of threads that will send packages to the
target at the same time. In the README of the GitHub repository, there is a
table showing the results of Bluetooth DoS attacks performed using the script
with different values on the package size and the number of threads.

Steps

To use this script, the target Bluetooth address was needed which was obtained
by reading on the IHU box where it was printed. This was also the same
Bluetooth address as stated in the “About” view in the settings of the IHU. The
script was executed on one laptop that performed the Bluetooth DoS attacks.
The table in the README was used as guidelines for setting the package size
and the number of threads. In all attempted DoS attacks, a package size of 600
was used since a greater value resulted in failed sends. The following values
on the number of threads were used: 10, 50, 100, 200, 500, and 1000. For
each time the script was run with different values, a smartphone was used that
tried to establish a Bluetooth connection to the IHU.

Results

In all attempted Bluetooth DoS attacks, the smartphone was able to establish a
connection to the IHU. This meant the IHU withstood all performed Bluetooth
DoS attacks. However, when the number of threads was increased from 10 to
100, the response time increased from 40 ms to 500 ms on average.
 Penetration Testing: Steps, Results & Discussion | 49

Discussion

Only one computer was used to perform the DoS attack against the Bluetooth
interface of the IHU which did affect the availability of the interface. Using
more computers simultaneously attacking the Bluetooth interface might have
resulted in the IHU not withstanding the attack and made the interface
unavailable for devices to connect to it.
It is important that the Bluetooth interface withstood the DoS attacks. A
driver that cannot connect his/her phone to the IHU over Bluetooth for making
hands-free phone calls then could choose to use one hand for holding the
phone and reduces the capacity of maneuvering the vehicle on the road if an
unexpected event would occur. Thus, if the IHU had not withstood the DoS
attack, it would have posed a greater risk, although quite a small increase, of
endangering the driver and other people on the road.
Amongst the steps in attack path 1, only step 2 was not executed in this
penetration test. This was because physical access to the IVI system was
available from which it was obtained. However, in reality, an attacker will
often not have this access and needs to perform step 2.

6.3.2 Fuzzing
Introduction

The attack vector for this penetration test was fuzzing. The goal was to
remotely fuzz the Bluetooth interface of the IHU to find out if the interface
crashed or in some other way failed.
The motivation for performing this penetration test is threat scenario 1.
Furthermore, the steps in attack path 2 are used as guidelines for this
penetration test.

Background

A fuzzer called Bluetooth Stash Smasher [59, 60] was used in this penetration
test. The Bluetooth Stack Smasher fuzzer targets the L2CAP layer by sending
malicious packets to it. After a malicious packet is sent, Bluetooth Stack
Smasher uses l2ping to check if a host is still responding to pings and if
not it returns that a potential crash was detected. Bluetooth Stack Smasher has
multiple different modes, in total 13, such as L2CAP full header fuzzing and
L2CAP random fuzzing, and there is an option to use all modes in a performed
fuzz test. Multiple options exist including setting the size of the packets and
50 | Penetration Testing: Steps, Results & Discussion

the max crash count before stopping. The target Bluetooth address needs to
be specified when starting the Bluetooth Stash Smasher.

Steps

The target Bluetooth address needed by Bluetooth Stash Smasher was already
known from another penetration test (see section 6.3.1). A max crash count
value of zero was chosen to not accept any crashes. The packet size used
was 10 bytes since this was the same value that the Bluetooth Stack Smasher
used in an example fuzz test. Furthermore, a packet size of 600 bytes was also
used to examine how the Bluetooth interface handled larger malicious packets,
potentially with a greater chance of a successful crash. The reason for using
just a packet size of 600 bytes and not a greater value was because otherwise
l2ping would return a message not sent which results in the Bluetooth Stack
Smasher believing a response was not sent from the target and that a crash
occurred. All available Bluetooth Stash Smasher modes were separately used,
i.e., each mode was used in separate fuzz tests instead of performing only one
fuzz test going through each mode which could be selected as an option, to
thoroughly fuzz test the L2CAP layer. Each fuzz test with one mode was run
for approximately half an hour because of time limitations.

Results

For fuzz tests with a packet size of 10 bytes, the Bluetooth Stack Smasher
reported multiple potential crashes except when using the L2CAP random
fuzzing mode which did not result in any reported crashes. However, the
reported crashes seemed to be false since it was possible to still connect
a smartphone over Bluetooth to the IHU and there was no sign on the
touchscreen connected to the IHU of anything erroneous. There was no
difference when using a packet size of 600 bytes. Overall, the Bluetooth
interface of the IHU was not affected by the fuzz tests performed by the
Bluetooth Stack Smasher.

Discussion

The validity of the results from this penetration test is poor because the
Bluetooth Stack Smasher did not seem to perform any good fuzz tests against
the L2CAP layer in the Bluetooth stack used by the IHU. The Bluetooth Stack
Smasher reported multiple crashes when there was no sign of any failure.
Hence, other fuzz testers were considered such as the Bluetooth RFCOMM
 Penetration Testing: Steps, Results & Discussion | 51

fuzzer [61] but not tried since those found were either based on the Bluetooth
Stack Smasher or did not perform remote Bluetooth fuzzing.
Regardless of the poor validity of the results, it is important that a
Bluetooth stack withstands fuzz tests. A Bluetooth stack that fails because of
malformed packets received could result in an IVI system rebooting which was
the case in [15]. A reboot of the IVI system affects its availability, although
only shortly but could, for example, make a driver miss a turn from not being
able to use the navigation which in turn could lead to the use of more fuel.

6.3.3 Address Sniffing

Introduction

Since some of the performed Bluetooth-related penetration tests required the

address to the Bluetooth interface of the IHU (see sections 6.3.1 and 6.3.2), it
was of interest to investigate if it was possible to find it without having physical
access to the IHU. Therefore, Bluetooth address sniffing was performed.

Background

The Ubertooth One tool was used in this penetration test to sniff the LAP.
Once the LAP of a Bluetooth address is found, Ubertooth One can also find
the UAP. This means that the Ubertooth One can find the SAP of a Bluetooth
address [47].

Steps

First, the Bluetooth on the IHU was turned on and a smartphone was
connected to it. The smartphone was used to generate some Bluetooth
traffic. Subsequently, the Ubertooth One was connected to a laptop via USB,
and passive LAP monitoring was started. Multiple monitoring tests were
performed to ensure that all traffic in the vicinity was captured. Then, the
LAPs in the captured traffic were analyzed and compared against the actual
LAP. After a successful match with the actual LAP, the Ubertooth One could
then be used to find the UAP. When the SAP (LAP and UAP) was found, it was
easy to figure out the complete Bluetooth address of the IHU since the NAP
is the same for all IHUs from Aptiv.
52 | Penetration Testing: Steps, Results & Discussion

Results

This pen test was successful since it was possible to discover the address to the
Bluetooth interface of the IHU by using the Ubertooth One tool. The SAP of
the Bluetooth address was obtained and together with the same NAP assigned
to all IHUs from Aptiv, the full Bluetooth address could be found without
physical access to the IHU.

Discussion

The results from this penetration test seem to be reliable since the Ubertooth
One was able to capture the LAP and UAP several times in different
monitoring tests. Alone, the results are insignificant and do not have any direct
consequences, however, an attacker being able to use the Ubertooth One to find
the address to the Bluetooth interface of the IHU is needed to perform attacks
such as those described in sections 6.3.1 and 6.3.2 where the address must be
known. In a realistic scenario, performing Bluetooth-related attacks where the
address is needed, finding the address is usually amongst the first steps of an
attack path, which the results show can be achieved by using the Ubertooth One
tool, given that the attacker is in the vicinity of the target Bluetooth interface.
Therefore, the Ubertooth One tool can be used when performing step 2 of
attack path 1.

6.4 Penetration Testing Open Network Port

Introduction
During the information gathering stage, it was discovered that the IVI system
had an open port with port number 13402 of which Nmap could not identify
the service (see section 4.2.1). The goal of this penetration test was to explore
this port and examine if it was possible to exploit it and gain access to the IVI
system.
The steps in attack path 5 (see table 5.4) are used as guidelines for this
penetration test.

Steps
The IVI system and a laptop were first connected to the same controlled Wi-Fi
network. The IP address of the IVI system was obtained in the same way as
described in section 4.2.1.
 Penetration Testing: Steps, Results & Discussion | 53

Previous research has found an open Telnet port on an IVI system that
was used to communicate with the CAN bus in the vehicle [4]. Telnet was
on port number 6667 on the IVI system they investigated. The default Telnet
port number is 23 but it is possible to configure this and use Telnet on other
port numbers. This would explain why Nmap could not identify the service
that used port number 13402 on the target IVI system. Therefore, Telnet was
tried on this port. The telnet command was executed on the laptop with
the IP address of the IVI system and port number 13402 which resulted in an
established connection. However, shortly after when trying to enter a Linux
command such as ls, the connection was closed by the IVI system. This
was tried multiple times with different Linux commands after an established
connection but the IVI system always closed the connection.
The network port number 13402 was then searched on the internet to learn
about other potential services using this port. However, no common service
using this port was found.

Results
A connection was established by connecting to the open port 13402 on the
IVI system with Telnet. However, shortly after trying to exploit it and passing
Linux commands, the IVI system closed this connection. Further analysis of
this open port did not lead to any findings of other common services using it.
Therefore, the open port 13402 on the IVI system was not exploited during the
project.

Discussion
The results which show that it was not possible to connect to the open port
using Telnet are reliable since this was thoroughly tested. However, there
is probably some known service that uses this open port that could not be
determined during this test. One far-fetched idea that was never tired was that
this port was used by a service called Diagnostic communication over Internet
Protocol (DoIP), a protocol for performing automotive diagnostics over IP,
since its common port number is 13400 which is close to the open port number
13402 [62].
In attack path 5, step 2 describes how an attacker could get on the same
network to which the IVI system is connected by setting up an evil twin Wi-Fi
network. This was not performed in this penetration test, as the main objective
was to exploit the open port discovered. Setting up an evil twin network is not
54 | Penetration Testing: Steps, Results & Discussion

related to the research question of finding vulnerabilities in the IVI system,

it just shows how an attacker could get to the point where the open port is
accessible. However, in reality, most attackers will not have physical access to
the IVI system and need to perform some steps to get on the same network as
the IVI system such as step 2 of attack path 5. Moreover, step 3 of attack path
5 was executed by using Telnet to exploit the open port but was unsuccessful.
As a result, step 4 of attack path 5 was never reached.

6.5 Network Sniffing

Introduction
It was of interest to examine the IVI system’s network traffic when connected
to a Wi-Fi network, potentially revealing sensitive information. Therefore, it
was decided to sniff this traffic.
The motivation for performing this penetration test is threat scenario 6,
identified in the TARA (see section 5.3). Furthermore, the steps in attack path
7 are used as guidelines for this penetration test.

Steps
The IVI system and a laptop were first connected to the same controlled Wi-Fi
network, and the IP address of the IVI system was obtained in the same way as
described in section 4.2.1. Then, using SSH the laptop was connected to the
router on this Wi-Fi network. Traffic going through the router including the
IVI system’s traffic was captured using tcpdump and saved to a .pcap file.
Wireshark was then used to analyze the traffic captured.
The IP address of the IVI system was used as a filter to only display the
IVI system’s traffic in Wireshark. Traffic going through the open port 13402
on the IVI system was first searched for by filtering on this port, but no traffic
could be observed.
Another filtering method was then tried that consisted of searching
for specific strings in packets containing the following strings: volvo,
volvocars, and vcc. Multiple packets containing the string volvocars were
found, all of them being DNS packets querying for the following hostname:
inet.connect.c3.volvocars.com. The response to these DNS queries contained
IP addresses to several Amazon CloudFront servers.
Then, packets containing application data were searched. Multiple packets
that were captured contained application data, however, encrypted by the
 Penetration Testing: Steps, Results & Discussion | 55

Transport Layer Security (TLS) protocol. So, no unencrypted data was found
in the captured traffic potentially containing sensitive information.

Results
No sensitive information was found by performing network sniffing and
analyzing the traffic captured. However, a hostname related to Volvo Cars
was discovered.

Discussion
The results show that no major sensitive information was found. But if more
traffic was captured for a longer period, the results might have been different,
and more significant sensitive information could have been found.
In this penetration test, the IVI system was physically accessible to connect
it to a controlled Wi-Fi network and then capture its network traffic. However,
in a realistic scenario, when an attacker wants to capture the IVI system’s
network traffic, the attacker can first perform an evil twin attack and set up
a fake Wi-Fi network to which a victim connects the IVI system. Another
realistic attack path would be to first perform a Man-in-the-Middle (MITM)
attack where an attacker gains access to a poorly secured Wi-Fi router in a
public area to which the IVI system is connected and then start to capture its
traffic. For example, the IVI system could be connected to a public Wi-Fi
network when the vehicle is being refueled.
The steps in attack path 7 correspond quite well with the steps which were
taken in this penetration test, except for the step of setting up an evil twin
Wi-Fi network (which has already been described as why it was not done).
Therefore, it can be said that the steps of attack path 7 serve well as guidelines
to realize threat scenario 6.

6.6 Decompilation of Android Packages

Introduction
MobSF found a few false positive secrets described in section 6.2.2. It was of
interest to further examine the already pulled APKs from the IHU for sensitive
information, that MobSF might have missed, and other resources included
such as images. To examine the APKs, they needed to be decompiled into
human-readable format.
56 | Penetration Testing: Steps, Results & Discussion

Steps
The jadx tool and its GUI were used to decompile the APKs and examine
them. First, the strings in the resource directory of the APKs were gone
through. Following the results from MobSF, there were no strings containing
any sensitive information such as passwords, API keys, or tokens. Some APKs
contained images in the resource directory but none of these showed anything
secret. Then, the following strings were used in text searches on all the files in
the APKs: username, password, API key, and token. The reason for doing this
was to find text containing these strings in other places such as comments and
code. There were multiple hits on the strings username and password but all of
these were included in method and variable names, and not any text together
with actual values.

Results
Using the jadx tool it was possible to decompile APKs from the IHU and
examine most of the content in them. But no sensitive information was found
in any of the decompiled APKs which was the goal of this pen test.

Discussion
The results show that no sensitive information was found in any of the APKs.
However, since not all of the available APKs were pulled from the IHU in
section 6.2.2 which were the same APKs examined in this penetration test,
there could be other APKs containing sensitive information. Moreover, there
could also have been sensitive information in the examined APKs which was
missed. Using another method of not just searching after specific strings in all
of the files in the APKs and instead, for instance, going through each file in
the APKs could have resulted in findings of sensitive information.
It is important that no APKs, regardless if they are installed on the IHU,
contain any sensitive information since APKs can easily be decompiled with
tools such as jadx and gone through. The consequences of finding sensitive
information in APKs could be serious, for example, finding an API key to an
API that costs to use could be used by an attacker to impose the creators of the
application to pay the cost.
 Penetration Testing: Steps, Results & Discussion | 57

6.7 Exploiting Activities and Content Providers

Introduction
In the vulnerability analysis stage, MobSF showed that multiple APKs pulled
from the IHU potentially contained vulnerabilities of exported Activities and
Content Providers, described in section 6.2.2. Therefore, the goal of this
penetration test was to exploit exported Activities and Content Providers of
apps on the IHU using the tool Drozer.
The steps in attack path 4 (see table 5.4) are used as guidelines for this
penetration test.

Background
The following list shows the most important Drozer modules [52] that were
used in this penetration test and a brief description of them:

(1) app.package.list - It shows all of the apps installed on the device

which are identified by their package name.

(2) app.activity.info - It shows all of the activities exported by an

app. The module also shows the permission to access an activity.

(3) app.activity.start - Starts an activity of another app from the

Drozer Agent.

(4) scanner.provider.finduris - Searches for content providers

that can be queried from the Drozer Agent.

(5) app.provider.query - Queries a content provider. It can be used

to perform SQL injections.

(6) scanner.provider.injection - Automatically searches after

content providers vulnerable to SQL injection.

Steps
A laptop and the IHU were first connected over USB and by using adb the
Drozer Agent was installed on the IHU. Subsequently, the Drozer Agent server
was started on the IHU to which the laptop was connected and a Drozer session
was created. The available Android apps on the IHU were then listed using
module (1) to obtain their names.
58 | Penetration Testing: Steps, Results & Discussion

Module (2) was used on most of the available apps on the IHU which
showed the activities exported by them. Since there were many apps on the
IHU where most of them had several exported activities, a selection had to be
made because of time limitations. Only apps that were believed to potentially
have some kind of authentication process such as a login screen were selected.
Some of the exported activities in the selected apps overlapped with results
from MobSF (see section 6.2.2). Using module (3), the selected exported
activities were called from the Drozer Agent app. When each exported activity
was called, the touchscreen went from showing the main activity in the Drozer
Agent app to the activity called in another app. However, no activity reached
by exploiting it being exported bypassed any authentication process and did
not contain any sensitive information.
The next step was to try and exploit exported content providers of apps
on the IHU. Module (4) was used which found multiple accessible content
providers and URIs which are shown in figure 6.3. Then, all of the URIs
found were queried using (5) to examine what data the tables they pointed to
contained. Most of the tables were empty, but a few tables contained some
information, however, not revealing any sensitive or useful information.

Figure 6.3: Accessible content URIs.

Module (6) was then used which found several content providers
vulnerable to SQL injection, and their URIs are shown in figure 6.4. Some
 Penetration Testing: Steps, Results & Discussion | 59

of the URIs pointed to the same table. Ultimately, there were only two tables
to which the URIs pointed. The following shows the simplest form of the URIs
that pointed to the two tables: content://carrier_information
and content://com.google.settings/partner. All of the steps
described in the next paragraph were done on both these URIs but will only
be explained for the former URI as an example.

Figure 6.4: Content providers vulnerable to SQL injection.

The content://carrier_information URI was queried using

module (5) as shown in figure 6.5 to examine the table to which it pointed.
Then, the content provider managing the access to this table was manually
tested for SQL injection by abusing the projection and selection fields passed
to it. A single-quote character was passed in the projection and selection
field in two separate queries as shown in figure 6.6. This showed that the
content provider was vulnerable to SQL injection, confirming the previous
results from using module (6). A verbose error message was shown for
both queries that revealed the entire queries that the content provider tried
to execute. The verbose error messages also showed that SQLite was the
database engine. It was now easy to exploit the content provider which
was done by abusing the projection field in a query. The following string
was crafted to be passed in the projection field based on the knowledge
that SQLite was the database engine: * FROM SQLITE_MASTER WHERE
type='table';--. When this string is used in the full query, all tables in
the database are shown. Using this string would result in the whole SQL query
processed by the database engine after receiving it from the vulnerable content
provider to look as follows: SELECT * FROM SQLITE_MASTER WHERE
type='table';--'FROM carrier_key. The two dashes in this query
make the engine interpret the part after the dashes as a comment. Figure 6.7
shows the results of using the crafted string in the projection field in a query to
60 | Penetration Testing: Steps, Results & Discussion

the content provider. The database queried was discovered to store two tables
of which one was the table already known and the second, a previously hidden
and inaccessible table named android_metadata. This table was queried
as shown in figure 6.8 but did not contain any sensitive information.

Figure 6.5: Queried content URI for examination of the table fetched.

Figure 6.6: The content provider manually tested for SQL injection abusing
the projection and selections fields in two separate queries.

Figure 6.7: SQL injection on the content provider results in all of the tables
in the database being shown. The image has been cropped to improve the
readability of the text in it.

The second content provider with the URI content://com.google.

settings/partner was exploited in the same way as shown above. The
database managed by this content provider contained three tables of which
one was the table to which the URI pointed. The two other hidden tables were
named android_metadata and sqlite_sequence where the former
table contained the same information as shown in figure 6.8, and the latter
table was empty.

Results
Many apps on the IHU were found to be exporting activities but none of
the activities selected to be called from the Drozer Agent bypassed any
 Penetration Testing: Steps, Results & Discussion | 61

Figure 6.8: SQL injection on the content provider results in the contents of a
previously hidden and inaccessible table being shown.

authentication. This meant that none of the selected exported activities posed
any threat.
Multiple exported content providers from apps on the IHU were also
found but none of the tables to which they pointed contained any sensitive
information. Moreover, two exported content provider was found to be
vulnerable to SQL injection which was exploited and resulted in the finding
of several hidden tables, however, not containing any sensitive information.

Discussion
As only some exported activities from other apps on IHU were selected
to be called from the Drozer Agent app with the goal of bypassing some
authentication process, the results cannot be fully validated. The results
showed that no activity reached in any of the apps posed any threat but since
not all of the activities were not tested there could be other exported activities
from apps on the IHU which are vulnerable to this attack.
A successful attack of exploiting exported activities could have serious
consequences depending on the activities reached. An activity that should only
be accessed after some authentication process results in an attacker getting
unauthorized access to parts of an app and potentially obtaining sensitive
information that could be leaked.
The results show that two exported content providers from apps on the
IHU were vulnerable to SQL injection, but that the exploitation of them did
not result in any further findings of sensitive information. Thus, the SQL
injection attacks were unsuccessful since no sensitive information was found.
However, the results are still important because they show that exploiting
content providers vulnerable to SQL injection is a possible attack vector
that could have serious consequences, for example, data breaches. When
developers create apps for the IHU, they need to know that exported content
providers could be exploited.
Exploiting activities and content providers exported by apps on the IHU
require that a malicious app is also installed on it. In this penetration test, the
Drozer tool was used and the Drozer Agent app was installed on the IHU to
62 | Penetration Testing: Steps, Results & Discussion

simulate a malicious app. Any app installed on the IHU could exploit the
activities and content providers found in this penetration test. The Drozer
Agent app could be installed on the IHU because of physical access to the
IHU and the possibility to use adb. However, in a realistic scenario, an
attacker could get a malicious app to exploit the activities and content providers
installed either through social engineering or physical access to the IHU and
the vehicle. The latter would correspond to step 3 of attack path 4.
When comparing the steps taken in this penetration test to steps described
in attack path 4, they are quite similar overall. However, step 4 of attack path 4
is quite unspecific since as shown in this penetration test, multiple steps were
required to be executed before, for instance, the content providers could be
exploited.
 Discussion | 63

Chapter 7

Discussion

This chapter will first discuss the validity of the results of this thesis and
compare them to previous research. Additionally, the limitations of this thesis
affecting the results are discussed. Then, the method chosen for this thesis is
discussed, including a TARA analysis comparison with the penetration testing.
Finally, sustainability and ethical aspects of the work done are discussed.

7.1 Validity and Comparison of Results

The results show that no major vulnerabilities were found during the project.
The question is then to what extent the thesis can answer the research questions
if no major vulnerabilities were found. It is impossible to search for all
vulnerabilities in the IVI system but a large attack surface of it has been
penetration tested which makes the thesis a basis for the evaluation of the level
of security that the IVI system from Volvo Cars has. If a smaller attack surface
would have been penetration tested, then each attack surface such as Bluetooth
could have been tested more resulting in more discovered vulnerabilities,
but one distinction of this thesis compared to previous research was that it
investigated a greater attack surface of Android Automotive.
As mentioned in the delimitation (see section 1.6), the IVI system did not
have an internet connection during a large part of the project. This affected
the penetration tests carried out during the project and the results of the thesis.
If the IVI system’s internet connection would have started working earlier,
a greater focus would have been placed on performing penetration tests that
are remote for example, penetration testing the cellular interface. Instead, the
penetration tests carried out during the project were local where close or direct
access to the IVI system was needed. From a real attacker’s point of view, a
64 | Discussion

remote attack is more valuable which means that it is more critical to perform
penetration tests that are remote. Thus, the results of the thesis could have
been strengthened if the internet connectivity issue would have been solved
earlier.
Compared to the security of other IVI systems evaluated in previous
research (described in section 2.7), the IVI system from Volvo Cars had a
high level of security. While previous research [4, 27, 28] found multiple open
network ports on the IVI systems which they were able to exploit, the target IVI
system from Volvo Cars only had one open port which was not exploited during
the project. Furthermore, the Bluetooth penetration tests in this thesis did not
affect the availability of the Bluetooth interface of the IHU in the IVI system
which was possible in [15] where they got their IHU to reboot by attacking the
Bluetooth interface. In article [17], they were able to obtain the firmware of
the TCU, and in this project, both the IHU and the TCAM were disassembled
to potentially find debugging ports and extract the firmware, but no ports were
found. Exported content providers from apps on the IHU were found to be
vulnerable to SQL injection which was exploited, though not resulting in any
findings of sensitive information. This corresponds with the results of article
[25] which showed that many Android apps are vulnerable to attacks where
inter-component communication, offered by content providers, is exploited.
One successful attack vector in [16] was the web browser, but since the IHU
in the IVI system from Volvo Cars did not have a pre-installed web browser, nor
amongst the downloadable apps from Google Play, Volvo Cars have removed
the possibility to attack their IVI system through a web browser which makes
it more secure.
Since no major vulnerabilities were found in the thesis, the hypothesis (see
section 1.1.2) is considered incorrect. However, further penetration testing of
the IVI system from Volvo Cars might change this and validate the hypothesis.

7.2 Deviation from Weidman’s Methodology

The method used in this thesis consisted of seven stages based on Georgia
Weidman’s penetration testing methodology. Weidman’s methodology
provided structure for the penetration testing carried out during the project. It
can be tempting to immediately start attacking the target system (the fifth stage
called exploitation in Weidman’s methodology) but Weidman’s methodology
helps to avoid this. To the best ability the seven stages were tried to be carried
out separately but this was harder for the following stages: vulnerability
analysis, exploitation, and post exploitation. The work performed in these
 Discussion | 65

stages is similar and that is the reason why they are all included in the
penetration testing chapter (6).
Amongst the seven stages, the threat modeling stage deviated the most
from Weidman’s methodology since the ISO/SAE 21434 TARA constituted
this stage. The main reason the ISO/SAE 21434 TARA was employed is
that it considers safety compared to other threat modeling methods, but also
because it is adapted for automotive cyber threats. Learning to perform TARA
according to the ISO/SAE 21434 took some time but once learned it provided
a well-thought-out way of identifying damage and threat scenarios and rating
their impact and feasibility. One drawback of the ISO/SAE 21434 TARA is
that it is manually carried out. This made it harder to keep track of all scenarios
and ratings. Other threat modeling methods have tools such as Microsoft
Threat Modeling Tool [63] which helps with this.
All of the penetration tests in this thesis were performed in attempts
to compromise the cybersecurity properties of all assets identified in the
TARA. However, none of the penetration tests compromised the cybersecurity
properties of the assets. For example, the Bluetooth DoS attack which was
performed in one penetration test did not affect the availability of the Bluetooth
interface, and the penetration testing on the open port of the IVI system to
obtain private information in the IHU was unsuccessful and did not result in
the compromise of the confidentiality property of the asset. Furthermore, the
two content providers which were found to be vulnerable to SQL injection and
then exploited in one penetration test did not result in any findings of sensitive
information and thus, this test did not compromise the confidentiality property
of the asset. Therefore, based on the results of all the penetration tests in this
thesis, the assets in the IVI system which were identified are secure.
Generally, the attack paths from the TARA were helpful when planning and
carrying out the penetration tests in the thesis. Note that discussions regarding
the similarity between steps described in the attack paths and the actual steps
taken in the penetration tests have already been described in chapter 6.
The risk values from the TARA (see tables 5.6 and 5.7) will now be
compared to actual risk based on the results of the penetration test in this
thesis. The threats with the highest risk values were the exploitation of the
open port on the IVI system (threat scenario 4) and the extraction of sensitive
information from the IVI system’s network traffic (threat scenario 6). Two
penetration tests (see sections 6.4 and 6.5) were performed which are related
to these threats. Both penetration tests were unsuccessful and did not realize
the threats. Therefore, the risk for these two threats is less than indicated by
the risk values.
66 | Discussion

A risk value of 2 was determined for attack paths 1 and 2 realizing threat
scenario 1. This scenario describes the threat of crashing the Bluetooth
interface of the IVI system to make it unavailable. Both fuzzing and DoS
attacks were performed in two penetration tests to realize the threat but neither
of them was successful. Therefore, the risk value for this threat scenario and
the two attack paths should be reduced to 1 which is the lowest risk value. It is
worth mentioning here again that this is based on the result of this thesis and
could change with other penetration tests trying to realize the same threat.
The threat of extracting private information from pre-installed apps on IHU
(threat scenario 3) was assessed to have a risk value of 2. The penetration test
related to this threat which consisted of the exploitation of content providers
did not result in any finding of any private information. Therefore, the risk
value for this threat should be reduced to 1 despite having found content
providers that were vulnerable to SQL injection.
Multiple assets, damage and threat scenarios were identified, and multiple
attack paths were produced, in the threat modeling stage (see chapter 5).
However, the threat model in this thesis should not be considered exhaustive.
More assets, damage and threat scenarios can be identified, and other attack
paths can be produced which realize the threat scenarios identified in this
thesis. It is impossible to cover all of them, and this thesis only included the
ones which were relevant to the penetration tests in this thesis. Moreover, some
attack surfaces such as the cellular interface were not considered in the threat
model because of the limitations stated in section 1.6.

7.3 Sustainability and Ethics

Sustainability is a wide concept broken down into three pillars: environmental,
economic, and social.
The environmental impact of the project is small. The shipping of the
rig from Volvo Cars in Gothenburg to KTH in Stockholm is believed to have
been the largest environmental impact of the project. Small consumption
of electricity was used during the project needed to power the rig and the
equipment but had no significant environmental impact. All hacking tools
used during the project such as the Ubertooth One were borrowed from the
NSE’s Cyber Security Lab [64] which reduces the environmental impact.
The IVI system which security has been evaluated in this thesis was found
to not have any serious vulnerabilities. To some degree, this gives credibility
to the IVI systems from Volvo Cars and their cars in general. One could argue
that this could economically benefit Volvo Cars which, from the results of this
 Discussion | 67

thesis, produces IVI systems with a high level of security that improves social
sustainability.
One aspect of social sustainability is related to people’s health and well-
being. Several hidden tables not indented to be accessed in databases were
found in the thesis by exploiting SQL vulnerable content providers exported
from apps on the IHU in the IVI system from Volvo Cars. Although no
sensitive information was found, this could raise awareness amongst Android
developers at Volvo Cars, and all Android developers, that adversaries can
exploit content providers and potentially find sensitive information. Malicious
use of such information could negatively affect the health and well-being of
individuals. Thus, one might argue that the results of this work could help to
improve social sustainability.
One ethical consideration is the law. As already stated in section 1.4, it
is according to the Swedish Criminal Code [8] illegal to hack a system in
Sweden without the owner’s permission. For this project, a non-disclosure
agreement (NDA) was signed with Volvo Cars in order to legally perform
penetration testing on their IVI system. Any vulnerabilities found during the
project needed to first be communicated to Volvo Cars for them to patch them
before this thesis was published. Therefore, although no major vulnerabilities
were found during the project, all of the vulnerabilities and findings were first
shared with Volvo Cars. This thesis has been approved by Volvo Cars for
publication. Since the scope of this NDA was the IVI system, no other services
were penetration tested. For example, the Volvo Cars app was not tested even
though it communicated with cars from Volvo.
68 | Conclusion

Chapter 8

Conclusion

The purpose of this thesis was to strengthen the security of an In-Vehicle

Infotainment system from Volvo Cars by identifying vulnerabilities in it and
to further expand the research areas of automotive cybersecurity and ethical
hacking. Various penetration tests were performed on the IVI system to
answer the research question of existing vulnerabilities in the system. The
results show that no major vulnerabilities were found in the IVI system that
could endanger people in a vehicle with this system or be exploited to obtain
private information from the system. However, several findings were made in
this thesis; a network port was discovered to be open on the IVI system but
was never exploited. Furthermore, multiple exported content providers from
pre-installed Android apps on the IHU in the IVI system were found to be
vulnerable to SQL injection but exploiting them did not reveal any sensitive
information.
The ISO/SAE 21434 TARA was employed in the thesis and constituted
the threat modeling. Except for this TARA being manually carried out, the
attack paths from the TARA were helpful when planning and carrying out the
penetration tests in this thesis. Most of the risk values for the threats from
the TARA were found to be incorrectly assessed when compared to the results
of the penetration test which showed a lower risk of the threats. Hopefully,
this way of performing threat modeling can guide future researchers in the
automotive cybersecurity field.
Although no major vulnerabilities were discovered in this thesis this does
not mean that there are no major vulnerabilities in the IVI system. Therefore,
more penetration testing is needed on the IVI system where future work
described in chapter 9 provides directions.
 Future Work | 69

Chapter 9

Future Work

The following describes suggestions for future work:

Penetration Testing

• Perform LTE hacking and penetration test the cellular interface of the
IVI system. For example, setting up a rogue base station could be
attempted to possibly get the IVI system to connect to it instead of a
legitimate base station. This would allow to capture the traffic going
through the cellular interface and analyze it. Furthermore, it could allow
for interception and modification of the transmission between the IVI
system and a potential backend server to in the end possibly gain control
of the IVI system. Moreover, jamming LTE signals could be performed
to affect the availability of the IVI system’s internet connection.

• Conduct penetration testing of the IVNs on the rig from Volvo Cars
which was not part of this thesis. Reverse engineer messages on one or
more of the available IVNs on the rig and then injecting messages into
these IVNs could be attempted to then try and control ECUs on the rig.
This is important to penetration test since an ECU that can be controlled
by an adversary could result in life-threatening injuries if performed on
a safety-critical ECU when a vehicle is used on the road. Although
there was no safety-critical ECU on the rig, the IVNs are likely to be
connected to safety-critical ECUs in the real vehicles from Volvo Cars.

• One attack surface of the IVI system that could be penetration tested is
the radio (AM/FM and DAB). Often radio stations send out some text
information in addition to audio such as the name of the station and the
title of the song playing, which is then displayed on the screen of an
70 | Future Work

IVI system. This data needs to be parsed where there might be some
vulnerability.

• The open network port on the IVI system, which was discovered but not
exploited in this thesis, could be further analyzed and penetration tested.

• More privilege escalation techniques could be performed to possibly

achieve elevated privileges on the IHU in the IVI system. This
would allow for obtaining more information available on the IHU and
performing unauthorized actions which could be used in an attack chain.

• The PCBs of the IVI system’s components could be further penetration

tested. For example, connecting to the pins of the chips available on the
PCBs could be tried in an attempt to exploit their firmware and take over
the components in the IVI system.

• Penetration testing of other IVI systems from other vehicle manufactur-

ers can also be performed. Since previous research has shown that entire
vehicles have been controlled by hacking the IVI system in them, it is
important to find potential vulnerabilities in other IVI systems currently
on the marker before adversaries, making vehicles safer to use.

Threat Modeling

• Model threats against the cellular interface and the radio of the IVI
system by employing the ISO/SAE 21434 TARA.

• Identify more assets, damage and threat scenarios, and produce

more attack paths according to the ISO/SAE 21434 TARA to better
understand the threats against the IVI system.

• Perform threat modeling of other IVI systems on the market by

employing the TARA part of ISO/SAE 21434. This will help to identify
the strengths and weaknesses of this standard, and could in the end lead
to an improved version of the ISO/SAE 21434.
 References | 71

References

[1] Alissa Knight. Hacking connected cars: tactics, techniques and proce-
dures. Indianapolis, Indiana: Wiley, 2020. 238 pp. isbn: 9781119491804.
[2] Georgia Weidman. Penetration testing: a hands-on introduction to
hacking. San Francisco: No Starch Press, 2014. 495 pp. isbn:
9781593275648.
[3] Karl Koscher et al. “Experimental Security Analysis of a Modern
Automobile”. In: 2010 IEEE Symposium on Security and Privacy. 2010
IEEE Symposium on Security and Privacy. ISSN: 2375-1207. May
2010, pp. 447–462. doi: 10.1109/SP.2010.34.
[4] Charlie Miller and Chris Valasek. “Remote exploitation of an unaltered
passenger vehicle”. In: Black Hat USA. Vol. 2015. Las Vegas, 2015.
[5] Benjamin Eriksson, Jonas Groth, and Andrei Sabelfeld. “On the
Road with Third-party Apps: Security Analysis of an In-vehicle App
Platform:” in: 5th International Conference on Vehicle Technology and
Intelligent Transport Systems. Heraklion, Crete, Greece: SCITEPRESS
- Science and Technology Publications, 2019, pp. 64–75. isbn:
9789897583742. doi: 10 . 5220 / 0007678200640075. url:
https : / / www . scitepress . org / DigitalLibrary /
Link.aspx?doi=10.5220/0007678200640075 (visited on
03/07/2022).
[6] Alexander Palm and Benjamin Gafvelin. “Ethical Hacking of Android
Auto in the Context of Road Safety”. Bachelor’s. KTH, School of
Electrical Engineering and Computer Science (EECS), 2021. url:
http://urn.kb.se/resolve?urn=urn:nbn:se:kth:
diva-299647 (visited on 03/07/2022).
[7] International Organization for Standardization and SAE International.
Road vehicles — Cybersecurity engineering (ISO/SAE 21434). Stan-
dard. Clause 15. Geneva, CH, Aug. 2021, p. 88.
72 | References

[8] Brottsbalk (1962:700). The Swedish Criminal Code. url: https://

www . riksdagen . se / sv / dokument - lagar / dokument /
svensk- forfattningssamling/brottsbalk- 1962700_
sfs-1962-700#K4P9c (visited on 03/07/2022).
[9] Wenjun Xiong and Robert Lagerström. “Threat modeling – A
systematic literature review”. In: Computers & Security 84 (July 2019),
pp. 53–69. issn: 01674048. doi: 10 . 1016 / j . cose . 2019 .
03 . 010. url: https : / / linkinghub . elsevier . com /
retrieve/pii/S0167404818307478 (visited on 03/07/2022).
[10] Adam Shostack. Threat modeling: designing for security. OCLC:
ocn855043351. Indianapolis, IN: Wiley, 2014. 590 pp. isbn: 9781118809990.
[11] What is Android Automotive? Android Open Source Project. url:
https://source.android.com/devices/automotive/
start/what_automotive (visited on 03/21/2022).
[12] Google opens Android Automotive to app developers. VentureBeat.
May 1, 2019. url: https://venturebeat.com/2019/05/
01 / google - opens - android - automotive - to - app -
developers/ (visited on 03/21/2022).
[13] Automotive. Android Open Source Project. url: https://source.
android.com/devices/automotive (visited on 03/21/2022).
[14] Mert Pese et al. “Security Analysis of Android Automotive”. In: WCX
SAE World Congress Experience. Apr. 14, 2020, pp. 2020–01–1295.
doi: 10 . 4271 / 2020 - 01 - 1295. url: https : / / www . sae .
org/content/2020-01-1295/ (visited on 03/08/2022).
[15] Tencent Keen Security Lab. Experimental Security Assessment of BMW
Cars: A Summary Report. 2018. url: https : / / keenlab .
tencent . com / en / whitepapers / Experimental _
Security_Assessment_of_BMW_Cars_by_KeenLab.pdf
(visited on 03/09/2022).
[16] Tencent Keen Security Lab. Mercedes-Benz MBUX Security Research
Report. 2021. url: https : / / keenlab . tencent . com /
en / 2021 / 05 / 12 / Tencent - Security - Keen - Lab -
Experimental - Security - Assessment - on - Mercedes -
Benz-Cars/ (visited on 03/09/2022).
 References | 73

[17] Minrui Yan, Jiahao Li, and Guy Harpak. “Security Research on
Mercedes-Benz: From Hardware to Car Control”. In: Black Hat USA.
2020. url: https : / / www . blackhat . com / us - 20 /
briefings / schedule / #security - research - on -
mercedes - benz - from - hardware - to - car - control -
20746 (visited on 03/09/2022).
[18] Sotirios Katsikeas. “vehicleLang: a probabilistic modeling and simula-
tion language for vehicular cyber attacks”. Master’s. 2018. 92 pp. url:
http://urn.kb.se/resolve?urn=urn:nbn:se:kth:
diva-232182 (visited on 03/25/2022).
[19] Cory Beard and William Stallings. Wireless communication networks
and systems. In collab. with Mohit Tahiliani. Global edition. Always
learning. Chapter 12. Boston Columbus Hoboken Indianapolis New
York San Francisco Amsterdam Cape Town Dubai London Madrid
Milan Munich Paris Montreal Toronto Delhi Mexico City São Paulo
Sydney Hong Kong Seoul Singapore Taipei Tokyo: Pearson, 2016.
605 pp. isbn: 9781292108711.
[20] What is Bluetooth Address (BD_ADDR). Bluetooth MAC Address
Changer for Windows. url: https : / / macaddresschanger .
com/what- is- bluetooth- address- BD_ ADDR (visited on
05/09/2022).
[21] App Manifest Overview. Android Developers. url: https : / /
developer . android . com / guide / topics / manifest /
manifest-intro (visited on 05/13/2022).
[22] Introduction to Activities. Android Developers. url: https : / /
developer . android . com / guide / components /
activities/intro-activities (visited on 05/13/2022).
[23] Content provider basics. Android Developers. url: https : / /
developer . android . com / guide / topics / providers /
content-provider-basics (visited on 05/14/2022).
[24] Ettore Galluccio, Edoardo Caselli, and Gabriele Lombari. SQL
injection strategies: practical techniques to secure old vulnerabilities
against modern attacks. OCLC: 1202027428. Chapters 1 & 2. 2020.
isbn: 9781839217135. url: https : / / search . ebscohost .
com / login . aspx ? direct = true & scope = site & db =
nlebk&db=nlabk&AN=2526559 (visited on 05/16/2022).
74 | References

[25] Abdul Moiz and Manar H. Alalfi. “An Approach for the Identification
of Information Leakage in Automotive Infotainment systems”. In: 2020
IEEE 20th International Working Conference on Source Code Analysis
and Manipulation (SCAM). Adelaide, Australia: IEEE, Sept. 2020,
pp. 110–114. isbn: 9781728192482. doi: 10.1109/SCAM51674.
2020 . 00017. url: https : / / ieeexplore . ieee . org /
document/9252027/ (visited on 03/08/2022).
[26] Stephen Checkoway et al. “Comprehensive Experimental Analyses of
Automotive Attack Surfaces”. In: USENIX Security. SEC’11. San
Francisco, CA: USENIX Association, 2011.
[27] Edwin Franco Myloth Josephlal and Sridhar Adepu. “Vulnerability
Analysis of an Automotive Infotainment System’s WIFI Capability”. In:
2019 IEEE 19th International Symposium on High Assurance Systems
Engineering (HASE). Hangzhou, China: IEEE, Jan. 2019, pp. 241–246.
isbn: 9781538685402. doi: 10.1109/HASE.2019.00044. url:
https://ieeexplore.ieee.org/document/8673049/
(visited on 03/09/2022).
[28] Computest. Research paper: The connected car - ways to get
unauthorized access and potential implications. Technical report. 2018.
[29] Ling Liu, Sen Nie, and Yuefeng Du. “Free-Fall: Hacking Tesla from
Wireless to CAN Bus”. In: Black Hat USA. Las Vegas: Tencent Keen
Security Lab, 2017. url: https : / / www . blackhat . com /
us - 17 / briefings / schedule / #free - fall - hacking -
tesla - from - wireless - to - can - bus - 6415 (visited on
03/09/2022).
[30] Craig Smith. The car hacker’s handbook: a guide for the penetra-
tion tester. San Francisco: No Starch Press, 2016. 278 pp. isbn:
9781593277031.
[31] Aileen G Bacudio et al. “An overview of penetration testing”. In:
International Journal of Network Security & Its Applications. Academy
& Industry Research Collaboration Center (AIRCC) 3.6 (Nov. 2011),
p. 19.
[32] The Penetration Testing Execution Standard (PTES). url: http://
www . pentest - standard . org / index . php / Main _ Page
(visited on 03/07/2022).
 References | 75

[33] Madeleine Berner. “Where’s My Car? Ethical Hacking of a Smart

Garage”. Master’s. Stockholm, Sweden: KTH Royal Institute of
Technology, 2020. 140 pp. url: http://urn.kb.se/resolve?
urn=urn:nbn:se:kth:diva-280298 (visited on 07/02/2022).
[34] Loren Kohnfelder and Praerit Garg. The threats to our products. 1999.
url: https : / / adam . shostack . org / microsoft / The -
Threats-To-Our-Products.docx.
[35] International Organization for Standardization. Road vehicles – Func-
tional safety – Part 3: Concept phase (ISO 26262-3, IDT). Standard.
2018, p. 38.
[36] What is FCC ID? Computer Hope. Oct. 4, 2017. url: https : / /
www.computerhope.com/jargon/f/fccid.htm (visited on
04/06/2022).
[37] Intel Atom Processor E3900 and A3900 Series Datasheet Addendum.
July 2019. url: https : / / www . intel . com / content /
dam / www / public / us / en / documents / datasheets /
atom - processor - e3900 - a3900 - series - datasheet -
addendum.pdf?asset=14689 (visited on 04/06/2022).
[38] Product Details. National Communication Authority. TCAM. url:
https : / / portal . nca . org . gh / search _ type _
approval_view_details.php?typeApproveDetailID=
2777 (visited on 04/06/2022).
[39] Control module vgm, exch. Volvo Car USA Parts & Accessories Online
Store. Vehicle Gateway Module. url: https : / / usparts .
volvocars . com / p / Volvo _ 2021 _ XC40 / TCAM -
TELEMATIC - and - VGM - VEHILCE - Gateway - Vehicle -
Connectivity - Module - VCM - HW - 32334584 - CONTROL -
MODULE - VGM - Control - Module - vgm -- Exchange /
102575015/36012972.html (visited on 04/23/2022).
[40] Bluetooth Management. Ubuntu. BlueZ. url: https://ubuntu.
com/core/docs/bluez (visited on 04/24/2022).
[41] Jasper van Woudenberg and Colin O’Flynn. The hardware hacking
handbook: breaking embedded security with hardware attacks. San
Francisco, CA: No Starch Press, 2022. 479 pp. isbn: 9781593278748.
[42] Chapter 15. Nmap Reference Guide | Nmap Network Scanning. url:
https://nmap.org/book/man.html#man-description
(visited on 05/07/2022).
76 | References

[43] sdptool(1) - Linux man page. url: https://linux.die.net/

man/1/sdptool (visited on 05/07/2022).
[44] l2ping(1) - Linux man page. url: https : / / linux . die . net /
man/1/l2ping (visited on 05/06/2022).
[45] Android Debug Bridge (adb). Android Developers. url: https://
developer.android.com/studio/command- line/adb
(visited on 05/07/2022).
[46] Getting Started. MobSF Documentation. url: https : / / mobsf .
github.io/docs/ (visited on 05/08/2022).
[47] Getting Started — Ubertooth documentation. Ubertooth. url: https:
//ubertooth.readthedocs.io/en/latest/getting_
started.html (visited on 05/09/2022).
[48] J Postel and J Reynolds. Telnet Protocol Specification. May 1983. url:
https : / / datatracker . ietf . org / doc / html / rfc854
(visited on 05/11/2022).
[49] About Wireshark. Wireshark. url: https://www.wireshark.
org/ (visited on 05/11/2022).
[50] Welcome! TCPDUMP & LIBPCAP. url: https : / / www .
tcpdump.org/ (visited on 05/11/2022).
[51] JADX. GitHub. url: https : / / github . com / skylot / jadx
(visited on 05/16/2022).
[52] Drozer User Guide. Mar. 23, 2015. url: https : / / labs . f -
secure.com/assets/BlogFiles/mwri- drozer- user-
guide-2015-03-23.pdf (visited on 05/12/2022).
[53] drozer. GitHub. url: https://github.com/fsecurelabs/
drozer/ (visited on 05/12/2022).
[54] Carlos Polop. LinPEAS - Linux Privilege Escalation Awesome Script.
GitHub. url: https://github.com/carlospolop/PEASS-
ng (visited on 05/07/2022).
[55] Carlos Polop. Checklist - Linux Privilege Escalation. HackTricks. url:
https : / / book . hacktricks . xyz / linux - hardening /
linux - privilege - escalation - checklist (visited on
05/07/2022).
[56] NVD - CVE-2019-0154. National Vulnerability Database. url: https:
//nvd.nist.gov/vuln/detail/CVE-2019-0154 (visited
on 05/07/2022).
 References | 77

[57] 2019.2 IPU – Intel® Processor Graphics Update Advisory. Intel.

INTEL-SA-00260. url: https://www.intel.com/content/
www / us / en / security - center / advisory / intel - sa -
00260.html (visited on 05/07/2022).
[58] jieggii. Bluetooth DOS-Attack Script. url: https://github.com/
crypt0b0y / BLUETOOTH - DOS - ATTACK - SCRIPT (visited on
05/06/2022).
[59] Pierre Betouin. Bluetooth Stash Smasher. Version 0.8. url: https:
//github.com/hllhll/BluetoothStackSmasher (visited
on 05/09/2022).
[60] Pierre Betouin. [Infratech - vulnérabilité] Nouvelle version 0.8 de
Bluetooth Stack Smasher. SecuObs.com. Feb. 15, 2006. url: http:
//www.secuobs.com/news/15022006-bss_0_8.shtml
(visited on 05/09/2022).
[61] Grace Lee. Bluetooth-RFCOMM-fuzzer. GitHub. Nov. 2016. url:
https://github.com/gracelee/Bluetooth- RFCOMM-
fuzzer (visited on 06/20/2022).
[62] Service Name and Transport Protocol Port Number Registry. IANA.
DoIP. url: https : / / www . iana . org / assignments /
service-names-port-numbers/service-names-port-
numbers.xhtml (visited on 05/19/2022).
[63] Threat Modeling. Microsoft. Microsoft Threat Modeling Tool. url:
https://www.microsoft.com/en-us/securityengineering/
sdl/threatmodeling (visited on 05/21/2022).
[64] Home. NSE Lab. NSE’s Cyber Security Lab. url: https://nse.
digital/ (visited on 05/21/2022).
TRITA-EECS-EX- 2022:550

www.kth.se