Automated Cross-Platform Reverse Engineering of

CAN Bus Commands From Mobile Apps

Haohuang Wen Qingchuan Zhao Qi Alfred Chen Zhiqiang Lin

The Ohio State University The Ohio State University University of California, Irvine The Ohio State University
[email protected] [email protected] [email protected] [email protected]

Abstract—In modern automobiles, CAN bus commands are blocks for in-vehicle fault diagnosis [56] [52], vehicle security
necessary for a wide range of applications such as diagnosis, testing [38] [27] [43] [32], security monitoring [47] [28],
security monitoring, and recently autonomous driving. However, and recently programmable vehicle control (e.g., autonomous
only a small portion of CAN bus commands is standardized, driving) [15].
and a vast majority of them is developed privately by car
manufacturers. Today, the most effective way of revealing the Although CAN bus commands are highly valuable, only a
proprietary CAN bus commands is to reverse engineer with small portion of them is standardized and the vast majority of
real cars, which unfortunately is time-consuming and costly. them is developed privately by car manufacturers. As a result,
In this paper, we propose a cost-effective (no real car needed) there are usually completely different CAN bus commands
and automatic (no human intervention required) system, C AN - across different car models [20]. Over the years, a significant
H UNTER, for reverse engineering of CAN bus commands using
just car companion mobile apps. To achieve high effectiveness,
amount of effort has been made to reverse engineer CAN
we design an efficient technique to uncover the syntactics of bus commands for different car models. Currently, the state-
CAN bus commands with backward slicing and dynamic forced of-the-art is to rely on dynamic testing with a real car by
execution, and a novel algorithm to uncover the semantics of CAN analyzing the repeated correlation patterns between specific
bus commands by leveraging code-level semantic clues. We have CAN messages and vehicle behavior. In particular, there are
implemented a prototype of C AN H UNTER for both Android and two ways to do so: (i) one is to manually trigger physical
iOS platforms, and tested it with all free car companion apps (236 actions in the car, e.g., stepping on the throttle, and then
in total) from both Google Play and Apple App Store. Among observes changes on the CAN bus [13] [4]; (ii) the other is
these apps, C AN H UNTER discovered 182, 619 unique CAN bus to generate and send arbitrary CAN messages to the CAN
commands with 86.1% of them revealed with semantics, covering bus, and then observe the triggered physical actions on the
360 car models from 21 car manufactures. We have also evaluated
their correctness (both syntactics and semantics) using public
vehicle [38] [39]. Unfortunately, these approaches not only
resources, cross-platform and cross-app validation, and also real- require a huge amount of hardware resources, e.g., real cars
car testing, with which over 70% of all the uncovered commands and testing equipment such as jack stands [38] and CLX000
are validated. We observe no inconsistency in cross-platform and CAN analyzers [4], but also are time-consuming and error-
cross-app validation. While there are 3 semantic inconsistency prone due to the significant manual efforts involved.
among 241 manually validated CAN bus commands from public
resources and real-car testing, we find that these three cases are However, recently we have witnessed a rapid growth of the
actually caused by mistakes from app developers. Internet of Things (IoT) in many application domains including
automobiles for various reasons such as convenience and
automation. Today, car manufacturers and 3rd-party developers
I. I NTRODUCTION
have produced a great number of mobile apps to connect
In modern automotive systems, nearly all vehicle con- with in-vehicle systems such as in-vehicle infotainment (IVI)
trol functions ranging from steering, acceleration, braking, and offer convenient app-based vehicle control or diagnosis.
to lighting are controlled by a variety of Electronic Control Interestingly, to achieve compatibility with existing in-vehicle
Units (ECUs) communicating over in-vehicle networks. In systems, these apps fundamentally still rely on the CAN bus
such networks, Controller Area Network (CAN) is the most commands to engage with the vehicles. That is, these apps
widely deployed communication protocol today [38]. Conse- must contain the logic to generate CAN bus commands either
quently, the knowledge of the syntactics (i.e., the structure, directly or indirectly (through translation or relay in a dongle
the format, and the concrete value) and semantics (i.e., the or cloud server) for each supported vehicle. As a result, such a
meaning and functionality) of its command messages, or newly-formed automotive mobile app ecosystem can create a
CAN bus commands, is crucial to many applications such as new direction for reverse engineering of CAN bus commands.
automation, diagnosis, and security. For instance, parsing and
To demonstrate this new approach, in this paper we present
constructing CAN bus commands are the most basic building
a cost-effective (no real car needed) and automatic (no hu-
man intervention required) system, C AN H UNTER, to reverse
engineer the CAN bus commands (targeting both syntactics
Network and Distributed Systems Security (NDSS) Symposium 2020 and semantics) from car companion apps. To achieve high
23-26 February 2020, San Diego, CA, USA
ISBN 1-891562-61-4 effectiveness, we have to address several technical challenges.
https://dx.doi.org/10.14722/ndss.2020.24231 First, to recover the syntactics, we need to locate and analyze
www.ndss-symposium.org the CAN bus command generation logic in car companion
apps. However, since there is neither standard guidance nor C AN H UNTER succeeds, and also the countermeasures against
unified programming interfaces for CAN bus command gen- our approach if necessary are also discussed in the paper.
eration, how to systematically locate this logic is non-trivial.
Moreover, even with such logic located, it is unclear how to Contributions. The main contributions of this paper are:
trigger the generation process without the required execution • Novel approach. We propose a novel, cost-effective, and
contexts such as real cars. To overcome these challenges, we automatic cross-platform reverse engineering approach for
use a technique known as backward slicing that starts from CAN bus commands through analyzing only the companion
the standardized low-level network programming interfaces to mobile apps, without using real cars.
locate the generation paths. Meanwhile, based on the insight
that these apps typically embed CAN bus commands with- • Effective techniques. We design a suite of new and effective
out requiring sophisticated external input, we adapt dynamic techniques that uncover CAN Bus command syntactics
forced execution techniques (e.g., [60] [36] [34]) to forcefully with backward slicing and dynamic forced execution, and
execute the CAN commands generation paths without real cars. infer the command semantics with a novel app code based
semantics recovery algorithm.
In addition to revealing the syntactics of CAN bus com- • Implementation and evaluation. We implemented C AN -
mands, C AN H UNTER also focuses on recovering the semantics H UNTER and evaluated it on 236 car companion apps,
to facilitate the practical usage of the commands. Prior efforts and discovered 182, 619 unique CAN bus commands in
on protocol semantics recovery rely on either the keywords in which 86.1% of them are recovered with semantics. We
the network traces (e.g., [57]) or the parameters and execution also validate the correctness of over 70% of the recovered
contexts of well-known APIs (e.g., [41] [25] [24]), and they CAN bus commands of their syntactics and semantics using
mostly focus on desktop applications or malware and cannot public resources, cross-platform and cross-app validations,
be directly applied in our targeted domain. Interestingly, we and real-car testing.
notice that CAN bus commands are often triggered by users
when using the mobile apps, and the UI-rich apps must provide Roadmap. The rest of this paper is organized as follows.
clues in their user interfaces (e.g., using an unlock door We provide the necessary background related to CAN bus
button to trigger unlock door CAN bus commands). Therefore, commands, automotive mobile apps, and the applications of
by leveraging the semantics clues in the app, we design an CAN bus commands in §II. Next, we present a running
app code based semantics recovery algorithm to reveal the example to illustrate the challenges and insights when reverse
semantics of the CAN bus commands. engineering the CAN bus commands from mobile apps in
§III. Then, we describe the detailed design of C AN H UNTER
We have implemented a prototype of C AN H UNTER and in §IV and implementation in §V. In §VI, we present the
applied it to test all of the free car companion apps we were detailed evaluation results of the reverse-engineered CAN bus
aware of from both the official iOS and Android app markets in commands, followed by the discussion on the root causes and
April 2019. In total, we have 236 apps: 114 for iOS and 122 for countermeasures in §VII. We review related works in §VIII,
Android. Among them, C AN H UNTER successfully uncovers and finally conclude in §IX.
182, 619 unique CAN bus commands, with 157, 296 of them
(86.1%) uncovered with semantics from 107 (45.3%) apps: II. BACKGROUND
104 third-party dongle apps and 3 official manufacturer apps.
These results cover over 360 popular car models from 21 car A. CAN and CAN Bus Command
manufactures. For the rest 129 (54.7%) apps, C AN H UNTER For a modern automobile, there are approximately
identified indirect vehicle control and monitoring related com- hundreds of Electronic Control Units (ECUs) responsible for
mands from 87 IVI apps and 22 dongle apps (note that these controlling various sub-systems such as steering, acceleration,
109 apps do not directly generate CAN bus commands and braking, doors, and windows. To coordinate these sophisticated
instead they rely on cloud servers or dongles to finally generate components, the CAN bus is designed for connecting the
the real CAN bus commands), and failed in 20 dongle apps ECUs and ensuring that the whole system works properly.
due to obfuscation. Messages that can be understood by all the components inside
the network are sent back and forth for communications,
To validate the correctness of these reverse-engineered which are called CAN bus messages. These messages are
CAN bus commands, we have exhaustively tried all possible formed with a specific standardized structure [33], which
methods we could access and afford, including checking is presented in Figure 1. Note that the identifier and the
with public resources (e.g., those from car hacking forums), command data in the data field altogether determine the
cross-platform and cross-app validations, and also real-car function of the message, which are commonly used to identify
testing. With these methods, we were able to successfully a CAN bus message. In this paper, we use the term CAN
validate over 70% of the uncovered commands. Specifically, bus command to represent both the syntactics (i.e., identifier
in cross-platform and cross-app validation, we observe no and format of a command data) and the semantics (i.e., the
inconsistency in command syntactics and semantics, which human understandable meaning) of a CAN bus message.
implies high effectiveness of C AN H UNTER. From public
resources and real-car testing, we discover only 3 (1.2% The syntactics of a CAN bus command is usually
among the 241 manually validated CAN bus commands) presented as hexadecimal values, including its identifier and
false positives in semantics recovery. However, these 3 data. The identifier can be either 11 or 29 bit referring to the
false positives are actually all caused by mistakes from app specific ECU that emits the command [33]. The command
developers instead of C AN H UNTER. The rationale of why data contains various length of bytes ranging from 0 to 8, each

2
 S R I D Data Field C A E
O Identifier T D L Byte Byte Byte Byte Byte Byte Byte Byte R C O
F R E C 0 1 2 3 4 5 6 7 C K F

Fig. 1: The structure of a CAN bus message.

(a) An IVI System (b) An OBD-II Dongle
of which stores the parameter of the command. The semantics
for CAN bus commands can be generally classified into two Fig. 2: An IVI system and an OBD-II dongle.
categories: (1) control, which operates physical components of
a vehicle such as unlocking doors and starting the engine, and of the vehicle [59]. A typical OBD-II dongle is shown in
(2) diagnosis, which queries the data of a vehicle such as speed Figure 2b. There are different types of dongles on the market.
and temperature. For each semantic meaning, there is a one-to- Some of them are compatible with different automobiles (e.g.,
one mapping to a CAN bus command. For instance, for Toyota dongles provided by auto-insurance companies), and only
Prius, the CAN bus command identifier “0x750” refers to provide diagnosis or monitoring functions based on a set
the main body and “0x7C4” is for the air conditioning. of standardized OBD diagnostic protocols. Other ones are
The specific syntactics and semantics of most of the CAN designed for specific types of automobiles, offering not only
bus commands are not standardized, and thus they are defined diagnosis capabilities but also remote control functionality.
privately by car manufacturers to represent various functions Similar to OBD-II dongles, dongle apps also have different
for different car models. This makes CAN bus commands types, with some designed for many different dongles such as
highly diversified, and even different car models of the same DashLink, EOBD-Facile, and AutoDoctor, and others only for
brand (e.g., Audi A3 and A4) can often have completely dif- specific dongles such as Carly, Carista, and FIXD.
ferent set of commands. For example, the command identifier
“0x3B7” represents engine for BMW E65 but window for C. Applications of CAN Bus Commands
BMW E84, according to the validated commands from a car
hacking forum [20]. CAN bus commands are essential to many applications
including but not limited to:
B. Automotive Mobile App Ecosystem • Remote control. CAN bus commands can be used by
mobile apps to offer remote vehicle control, which pro-
Today, there are many automotive related mobile apps vides great convenience for users to remotely operate their
available to consumers. We have investigated car companion vehicles such as locking doors and closing windows. For
apps on popular mobile app markets such as Google Play example, we find various car companion apps such as
Store and Apple App Store, and found that they all can be Carista, BimmerCode, and OSCC [17] that interact with
categorized into the following two types according to how they vehicles by sending remote control CAN bus commands.
connect to an automobile. • Vehicle diagnosis. CAN bus commands are also used for
vehicle diagnosis and inspection such as monitoring the
In-Vehicle Infotainment (IVI) apps. This kind of app is status of vehicles including reading parameters like fuel,
developed and authorized by the car makers (e.g., Audi, pressure, and speed. For instance, we have noticed that
and Toyota) and is only compatible with specific types of various apps and dongles are developed for this purpose,
cars. Typically, they offer remote control capabilities such as including those mentioned in §II-B.
unlocking doors and starting engines. To interact with the
• Security monitoring. CAN bus commands are
cars, these apps need to connect to the IVI system via either
also widely used in developing CAN bus firewalls
Bluetooth or cellular network. The IVI system itself, as shown
(e.g., [35] [48] [47] [44] [28]), to prevent malicious
in Figure 2a, is widely deployed in most of modern vehicles.
message from being injected into the CAN bus. Without
The outer interface of an IVI system offers touchscreen for
the knowledge of each specific CAN bus command, the
drivers to interact with the cars to play music, navigate and
security monitoring system would not work properly.
so on, while the other side of it connects to the inner network
of the vehicle. To perform remote control functions, IVI apps • Vehicle hacking. Since CAN bus commands are essential
typically send requests to a remote server on the Internet, e.g., for vehicle control and diagnosis, they can be leveraged to
a cloud server, and rely on the server to issue corresponding perform attacks on automobiles [44] [45] [46]. For instance,
commands to the vehicle. by injecting the corresponding CAN bus commands to an
IVI system, Miller and Valasek [46] demonstrated how to
OBD-II dongle apps. In addition to car manufactures, some shut down the engine of a Jeep Cherokee. Generally, for an
3rd-party service providers including many auto-insurance attacker with little knowledge about the CAN bus protocol,
companies also develop car companion apps to interact with she could interfere the control of a vehicle by sending
vehicles through the On Board Diagnostic (OBD-II) port. In random CAN bus messages. However, in order to achieve
general, these OBD-II dongle apps (short as dongle apps) desired attack consequences on a vehicle, such as shutting
connect to a dongle plugged into the vehicle, and these OBD- down the engine or unlocking doors, one must know the
II dongles work like wireless sensors connecting to the OBD- precise CAN bus commands of interest in advance.
II dongle apps via Bluetooth, Wi-Fi, or cellular network and • Autonomous driving. CAN bus commands are also crucial
at the same time, directly communicate with the inner CAN for the development of autonomous driving nowadays.

3
 Screen_Info_Diag.viewDidLoad()
We have examined the source code of the three notable ...
13 v4 = UIButton()
autonomous driving software: ApolloAuto [2], Autoware [7] 14 v4.setText(“Engine Controls”)
...
and Openpilot [16]. We noticed the only software interface 27 v4.addTarget(v4,”initECUs”)
that interacts with the vehicles is the corresponding CAN // register button trigger function

bus commands, such as braking, steering, acceleration, and MD_AllECUsToyota.initECUs()

checking tire pressure and fuel. Since CAN bus commands ...
4 v12.initWithRequestId(“0x7E0”,”Engine Controls”)
are diversified across vehicle models, ApolloAuto [2] only // v12.frageID = ”0x7E0”
...
supports Lincoln MKZ, and Autoware only supports a 13 v22 = BaseFahrzeug.initWithName(“Corolla VIII”)
14 v22.addECU(v12) // v22.ECU = v12
few models such as Toyota Prius. At this point, these ...
25 v25 = v24.createWorkableECUKategorie(v22)
state-of-the-art autonomous driving software platforms can
only support a very limited set of car models, which is WorkableModell.createWorkableECUKategorie(a3)
partly due to the lack of the knowledge of the CAN bus ...
12 v6 = a3
commands for other car models [21]. 13
...
v7 = v6.ECU.frageID // “0x7E0”

18 v8 = v7.substring(2,5) // “7E0”
19 v9 = NSString.stringWithForamt(“%@ 30 00 02”,v8)
// “7E0 30 00 02”
III. OVERVIEW ...
30 v10 = v9.dataUsingEncoding(4)
31 v11 = v10.bytes() Invoke
A. Running Example ...
42 v5.writeValue(v11,v14,1) // Targeted API that
To understand clearly the challenges we have to address, sends data to the vehicle

we present a running example from an iOS dongle app called

Fig. 3: A motivating running example illustrating the genera-
Carly f.Toyota to show exactly how a CAN bus command is
tion of a CAN Bus command in a dongle app.
generated and used. This example is illustrated in Figure 3
with a piece of decompiled code and also the UI component
of the app. In particular, the UI shows a button titled “Engine
Controls”, which guides users to check the status of the en- programming interfaces for developers to construct a CAN bus
gine control units of the vehicle. To achieve such functionality, command. Thus, each car companion app is actually highly
the app must send a specific CAN bus command to the vehicle customized in the construction logic due to different coding
and fetch data from it. When the button is clicked, the control practices. However, to perform our reverse engineering task,
flow goes to the triggering function where a constant string identifying the CAN bus command generation path at the car
“0x7E0” is initialized (line 4). Then, the string goes through companion apps code level is a necessary step. As a result,
a series of operations and a complete CAN bus command how to design a general and systematic solution for such
syntactics “7E0 30 00 02” is produced (line 19). Finally, identification is the first challenge.
the command is sent to the vehicle through a low-level API
writeValue (line 42). Automatic syntactics recovery. After identifying the genera-
This example helps us better understand how the syntactics tion path, the operations along the path need to be executed
and semantics of a CAN bus command can be inferred. Since in order to recover the corresponding CAN bus command
the CAN bus commands eventually will be captured by a syntactics. To perform such a task, a known challenge is
specific network API and sent to the vehicle, we can adopt a automatic preparation of the required execution context, e.g.,
known backward slicing algorithm that starts from these low- internal program states such as user account, and external input
level APIs and traces back to locate the commands. Then we such as those from user or network [42] [29]. Specific to
can follow the execution to recover the syntactics of the com- car companion apps, we find that all the ones we collected
mands. Interestingly, the semantics and the car model informa- (detailed in §VI) require successful network connections with
tion (if an app supports multiple cars) can also be inferred. In actual IVI systems or OBD-II dongles before their vehicle
this example, the string “Engine Controls” appears in the control functions can be accessed. In addition, even with
text of the UI button (line 14) as well as the argument of func- network connections, the majority of them is found to require
tion call initWithRequestId("0x7E0", "Engine user authentication or vehicle authentication, e.g., by providing
Control") (line 4). The constant string “Corolla VIII” a valid VIN number. Since many of these inputs are difficult
is also integrated as an argument of function initWithName to obtain without access to actual hardware such as real cars,
(line 13), associating the command with the car model the context preparation task for car companion apps become
Corolla. difficult to automate.

B. Technical Challenges Automatic semantics recovery. To complete the reverse

engineering process, in addition to the CAN bus command
While the motivating example in Figure 3 concretely syntactics, we also need to extract the associated semantics,
illustrates the potential of leveraging car companion apps for e.g., “Engine Controls” in Figure 3. In prior works
CAN bus command reverse engineering, how to systemically on protocol semantics recovery (e.g., [24] [25] [57] [38]),
perform such reverse engineering is still non-trivial. More dynamic network traces are needed in the recovery process.
specifically, we notice there are still three key technical chal- However, without real cars or dongles to generate network
lenges we have to address: traffic, these prior solutions cannot be applied directly to car
companion apps. Another possibility is to find out the seman-
Precise identification of the generation path. For car com- tics from the documentations of the vehicle control APIs used
panion apps, there is neither standard guidance nor unified in the generation path. However, no such unified programming

4
interfaces exist today for vehicle control behaviors in car we have to look for potential clues inside the app code for
companion apps. our semantics recovery. Encouragingly, we have identified a
few common patterns with semantic information inside the app
C. Key Insights code. In particular, we find that car companion apps typically
contain strings that are visible in the app UI to inform users
Fortunately, in this work we are able to identify the follow-
about the semantic meanings of the vehicle control functions.
ing insights to address each of the challenges described above:
For example, the CAN bus command generation path is associ-
ated with the UI element “Engine Controls” in Figure 3.
Backward program slicing. To identify CAN bus command
As such, we can recover the semantics of a given CAN bus
generation path, a key insight is that no matter how these
command by tracking the association of its generation logic in
commands are generated, a car companion app will always
the app code with the corresponding strings in the UI elements.
send out them to the vehicles through network interfaces, e.g.,
WiFi and Bluetooth, by design. Therefore, we can first locate In addition, we also find that functions in car companion
the standardized network APIs and then use a well-known apps often take both a string parameter and a CAN bus com-
program slicing algorithm to trace backward from these APIs mand together in the generation path. For example, at line 4
to find all the code-level operations related to the generation in Figure 3, where both “0x7E0” and “Engine Control”
of CAN bus commands. Such a backward slicing based are passed as parameters to function initWithRequestId.
technique has been widely in mobile app analysis including Thus, we can then use an association heuristic to infer the
our own prior works (e.g., [63] [64]). Another approach to semantic meanings of the generated CAN bus command from
solve this problem is using forward data flow analysis which this function. In the car companion apps we collected in §VI,
starts from UI components and traces to the network sinks. we find this type of argument association widely exist (about
However, the backward slicing approach is preferred for two 30% of the apps that have CAN bus commands), which very
reasons. First, the backward approach is more precise, since likely is implemented for logging and debugging purposes.
the forward approach explores more program paths including
those irrelevant to CAN bus commands generation. Second, the Based on these observations, we therefore design a app
backward approach can discover more CAN bus commands code based semantics recovery algorithm that analyzes such
that are not triggered by the UI. For example, as discussed semantics clues in car companion app code, e.g., from UI
in §VII, many commands we discovered are never used in elements and function argument associations, to automatically
the app (e.g., some dead code) and are possibly left there for recover semantics of a CAN bus command.
debugging during the app development.
D. Scope and Assumptions
Dynamic forced execution. As described earlier, it is indeed In this work, we focus on car companion apps from the
very difficult to prepare the proper execution context of car two mainstream mobile app platforms namely Android and
companion apps, e.g., network connections and user/vehicle iOS, from their corresponding official app market namely the
authentications. However, we find that the actual construction Google Play Store and the Apple App Store. We assume that
process of the CAN bus commands is usually independent these apps are not obfuscated, such that they can be disas-
from external input, after the checking logic of these opera- sembled and decompiled by the state-of-the-art analysis tools
tional contexts. One such an example is illustrated in Figure 3. such as IDA-Pro [14] and Soot [19]. The implementation of
This is very likely because CAN bus commands are hex strings C AN H UNTER also assumes car companion apps send out CAN
and car companion apps can hardly rely on end users to bus commands through Wi-Fi, Bluetooth, and Bluetooth Low
directly enter them, and instead they are embedded in the app Energy (BLE), and thus focuses only on the data transmission
code somewhere and rely on human beings to trigger them. APIs of these channels.
Such triggering operations would also not require sophisticated
input from users (typically through buttons, lists, and clicks) IV. D ESIGN
in mobile apps.
The workflow of C AN H UNTER is presented in Figure 4. At
Therefore, this creates a unique opportunity to a high level, C AN H UNTER is divided into three components:
adopt a widely explored technique called forced backward slicing (§IV-A), syntactics recovery (§IV-B), and
execution [60] [50] [36] [37] [34], which is designed semantics recovery (§IV-C). It first takes the binary code of
for brute-force executing certain part of a program without a mobile app as input, disassembles and decompiles it, and
providing concrete inputs or setting proper environment. produces the execution paths through backward slicing of the
While this technique normally has limited effectiveness since decompiled code. Then, it uses dynamic forced execution to
it does not consider the execution contexts (e.g., the heap run the apps with the execution path of interest, from which
has to be properly modeled, otherwise it will often lead to to uncover both the syntactics and semantics of CAN bus
crashes [50]), such limitation does not affect our problem commands. In this section, we present the detailed design of
due to the independence of CAN bus command generation each of these components.
on external input. Thus, by adapting this technique to our
problem context, we can achieve automatic and effective
A. Backward Slicing
syntactics recovery without any real car or dongle connection.
Since not all the code in a mobile app contributes to the
UI and function argument assisted semantics recovery. generation of CAN bus commands, we use backward slicing
Since we cannot directly use existing protocol semantic infer- to identify the code path of our interest such that our analysis
ence approaches with desktop programs (e.g., [24] [25] [57]), can be performed efficiently. Backward slicing needs to begin

5
 Static Analysis Dynamic Forced Execution

Semantics Recovery Syntactics

Execution Syntactics
Backward Slicing Function Argument
Path Recovery UI Correlation Semantics
Association
Apps

Fig. 4: Overview of C AN H UNTER.

Algorithm 1: Backward slicing detects whether i is a programmer-defined function. If so, the

Input : F : current block name, V : a set of target variables, G: the algorithm recursively jumps into it to slice that function and
CFG of F finally appends S with the returned slice (line 5-7). Otherwise,
Output: A node containing the block name and instructions i is either a standard library function call or a basic operation
1 Function recursiveSlice(F, V) (e.g., numeric operation or assignment), and the algorithm
2 S←∅
3 for each stmt i ∈ G do
detects if there is any externally defined variables (e.g., global
4 if i is a relevant statement of any variable in V then variables) in i. If so, it further backward slices the external
5 if i is a programmer-defined function then variable setter functions to find out the data definitions of
6 V 0 ← target variable set of function i these variables (line 9-13). Finally, it records statement i into
7 S ← recursiveSlice(i, V 0 ).S ∪ S S, and removes all target variables in i and adds all other
8 else
9 if i contains externally defined variables then local variables in i into the trace set V (line 14-16).
10 for each external variable setter function F’ After the algorithm traverses all the statements in G, some
do
11 V 0 ← target variable set of F’ of the target variables in V may flow into the previous block.
12 S← In this case, the algorithm continues to trace them in the
recursiveSlice(F 0 , V 0 ).S ∪ S callers to see how they are generated (a context-sensitive inter-
13 end procedural analysis). To achieve this, we first initialize a node
14 S ←i∪S
15 V ← V removes the target variables in i containing the current block information including the block
16 V ← V ∪ all local variables in i name and the program slice S (line 20), and properly set
17 end up another target variable set V 0 which indicates the target
18 end variable locations in each caller (line 22). Then a recursive call
end
19
20 node ← N ode(F, S)
of itself is invoked on each of the caller F 0 with V 0 (line 23).
21 for each caller F’ of F do Eventually, the algorithm produces a node which is marked by
22 V 0 ← set of target variables in the caller the block name F and its slice S (line 25), which has multiple
23 node.addChild(recursiveSlice(F 0 , V 0 )) children nodes returned from the recursive call of the callers
24 end F 0 . Ultimately, after an initial call on callers of the network
25 return Node(F, S)
API, the algorithm generates all the program slices on the CAN
bus command generation paths.
During the slicing, it is important to make sure the resulting
from some low-level interfaces. To identify these entry points, program slices do not miss any statements that generate the
we find that CAN bus commands are usually sent to vehicles data of our interest. We therefore consider both data depen-
from apps through wireless network such as Bluetooth and dence and control dependence in our slicing:
Wi-Fi which have fixed low-level network APIs. Therefore, • Data dependency. It is quite a standard procedure to
the backward slicing algorithm in our targeted domain first identify the data dependency, based on how data is used and
identifies these documented interfaces and initializes a set defined. With G of F , we backward iterate each statement
of target variables which carry the data to be sent (i.e., the starting from the statement of our interest: if a variable used
data-use). Then, it backward iterates the decompiled program belongs to V , or a variable in V gets defined, we add it to
statements (examples of such statements are shown in Figure 3) the target set and the statement into the slice S.
and produces the execution paths according to how the target
variables and their closures are generated (i.e., trace back to • Control dependency. As our objective is to identify all
the data-definition). possible entry points such that our forced execution can
exercise them, our algorithm considers control dependencies
The pesudocode of how C AN H UNTER generates the in order to conservatively include all the possible cases. This
backward slice S of a function block F with a given target process is also quite simple. Specifically, when encountering
variable set V is presented in algorithm 1. The set V is branches and loops, there are conditions which are relevant
path-sensitive where each control flow path maintains its own to the variables in set V . As such, we add the condition
copy of variable set and propagates it backward. Initially, the statement into the slice S, and all the variables in the loop
algorithm takes F , V and the control flow graph (CFG) G of or branch body are included in V as well.
F as input, and sets the slice S as empty (line 2). To begin
with, the algorithm backward iterates each statement i in G Execution path generation. The backward slicing generates
(line 3-19) and checks if i is a statement affecting the value a tree-based structure including the execution paths of CAN
of any variable in set V (line 4). If so, it is regarded as a bus commands. Each node of the tree represents a block
relevant statement. For these statements, the algorithm further and contains its program slices. The leaf nodes of the tree

6
represent the blocks where the algorithm terminates, which data and display it to the user. During backward slicing, the
means the target variables are initialized without introducing algorithm terminates when it reaches all the data definition
extra dependencies. We call the leaf node as execution point points. At this time, the semantics recovery algorithm con-
where the forced execution starts. The root node of the tree tinues to trace backward from the data definition to find the
refers to the target low-level network API. From each of the associated UI elements. Then, C AN H UNTER extracts the texts
leaf node to the root, there must be a path which generates a of these elements as the command semantics.
message that sends out through a network API. Therefore, we
traverse the whole tree from the leaf to the root recursively (II) Function argument association. The semantics of the
using depth-first traversal, and construct the execution paths CAN bus commands are also likely to be exposed by function
by joining the program slices of each node. calls with their arguments. For instance, as in the function
call initWithRequestId ("0x7E0", "Engine
B. Syntactics Recovery Controls") of Figure 3, the CAN command syntactics
“0x7E0” appears together with a constant string “Engine
The recovery of syntactics is to compute the concrete value Controls” (the semantics) as an argument. Interestingly, this
of CAN bus commands, which is achieved through forcefully technique is also useful for recovering car model information.
executing the instructions involved in the execution paths. Due to the diversity of CAN bus commands, we notice app
Since the instructions are independent of external inputs, they developers often integrate car model information as arguments
can be directly executed. Specifically, the execution starts from to help themselves distinguish the CAN bus commands from
the leaf nodes of the tree and finally ends in the root. Within different manufacturers. To infer the model information, we
each node representing specific blocks, the algorithm executes cross-compare the extracted arguments with a pre-built set of
each instruction based on the order they appear in the slice. The all vehicle models. Therefore, when executing a function call
forced execution is performed dynamically on a real mobile instruction, C AN H UNTER dynamically extracts the constant
device running a car companion app. Each invocation of the string arguments of the function calls associated with the
network sending APIs generates a CAN bus command through command to infer the semantics and model information.
our dynamic forced execution. We log this command and keep
its value (which implicitly captures the structure and format)
as its syntactics. V. I MPLEMENTATION

We have to note that our design is general and we may We have implemented C AN H UNTER1 for both Android
identify other non CAN bus commands. For instance, we and iOS platforms with 3, 000 and 2, 000 Lines of Code,
also observe some AT commands [54] that are sent from respectively. In this section, we describe the implementation
mobile apps to OBD-II dongles, and some privately defined details on how we identify the target APIs, perform both static
commands (e.g., human-readable strings or decimal numbers) analysis and dynamic forced execution, as well as how we
sent to IVI systems or remote clouds. Fortunately, as we have handle the native library issue.
described in §II, a CAN bus command always has a distinct
structure [33], which thus enables us to easily filter those that Target API identification. To start the backward slicing,
are inconsistent with the defined structure. we focus on two categories of low-level APIs defined by
Google’s and Apple’s official SDKs, which may take CAN bus
C. Semantics Recovery commands as parameters. Since car companion apps usually
interact with vehicles via wireless network, the first category
During the syntactics recovery of CAN bus commands is the BLE API (setValue in Android and writeValue
through forced execution, C AN H UNTER also infers their se- in iOS). These APIs are provided by the official frame-
mantics and also vehicle model information when available. work [6] [3] for developers to implement communication
As discussed in §III, there is no accurate way to uncover the between an app and the peripheral following the BLE stan-
semantics of the CAN bus commands, and thus we design a dard. Besides BLE, CAN bus commands can also be trans-
semantics recovery algorithm based on our empirical obser- mitted through Wi-Fi or Bluetooth Classic. Consequently,
vations: the semantic meaning of a CAN bus command often the second category of low-level APIs includes the socket
appears as a constant string in the app code, and these strings APIs such as write for both Android and iOS, and the
will not be recognized or used by either the OBD-II dongles HTTP APIs such as openConnection for Android, and
or the CAN inside the vehicles. The reason for developers to dataTaskWithRequest for iOS.
integrate these human-understandable semantics into the car
companion apps is to help users associate the CAN bus com- Backward slicing. The backward slicing of C AN H UNTER is
mands with the related functionalities. As such, our semantics implemented based on IDA-Pro [14] and IDAPython (for iOS)
recovery algorithm uses the following two heuristics: (i) the UI as well as Soot [19] (for Android), targeting decompiled Soot
component correlation and (ii) function argument association, IR or Objective-C code. As the two of the most popular static
to infer the semantics of CAN bus commands. analyzers for Android and iOS, they both provide rich APIs
for basic program analysis such as decompilation, building
(I) UI component correlation. Users often trigger car related call graph, and locating function callers, which allows us
operations with UI components such as buttons in the car to easily perform static backward slicing of the app code
companion apps. The texts of the UI components are helpful to trace the variables from the target APIs. In addition,
for guiding them to the specific operations. For instance, a they support programming language binding so we are able
button titled “Reading Speed” triggers a speed reading
command sent to the vehicle, and then the app will fetch the 1 The source code is available at https://github.com/OSUSecLab/CANHunter

7
 # Total # Diagnostic App (%) # IVI App (%)
to develop scripts based on Java and Python to automate
Android 122 74 (60.7%) 48 (39.3%)
the static analysis. Furthermore, we also implemented multi- iOS 114 72 (63.2%) 42 (36.8%)
threading to analyze various executables simultaneously, which Total
236 146 (61.9%) 90 (38.1%)
significantly accelerates the reverse engineering process. (Android ∪ iOS)
Overlapped apps
79 38 (48.1%) 41 (51.9%)
(Android ∩ iOS)
Dynamic forced execution. The implementation of forced
execution is based on Cycript [8] and Frida [12] which are TABLE I: Distribution of collected car companion apps.
dynamic code instrumentation toolkits compatible with various
platforms including Android and iOS. They provide JavaScript
interfaces that allow us to dynamically execute the instructions C AN H UNTER recognizes the native functions in Java byte
instead of implementing the execution process by ourselves. code and associates them with the related ones in the native
To achieve automatic execution, we use the Python binding code according to the function signatures. Afterwards,
to automatically load each instruction in the execution path C AN H UNTER constructs the function call graph of the
and generate a snippet that is injected into the running app native binaries and then associates the native functions with
to execute these instructions. The environment is set up by the app code, which thus establishes a complete call graph.
connecting our PC to an Android device or a jail-broken
iPhone through SSH and hooking the running app process. VI. E VALUATION
The dynamic forced execution may lead to abnormal A. Experiment Setup
behaviours and even crashes. Therefore, we added exception
handling rules to make sure it can automate without human Car companion app collection. To perform our evaluation,
intervention. When the app crashes or does not respond, we have crawled all of the free vehicle related apps we were
C AN H UNTER restarts the app and retries the instruction when aware of from both the official Apple App Store and Google
a timeout limit is reached. Our implement of the exception Play Store in April 2019. Specifically, we used a crawler to
handling is also based on Frida, which enables C AN H UNTER start from some known keywords (such as OBD-II, IVI, and
to automate the operations on the attached process without any vehicle mobile apps) and exhaustively collect apps from the
human intervention. relevant app pages. Then, we manually confirmed each crawled
app to make sure they are vehicle related (for instance, we can
Handling native libraries. It is common for developers to further filter those dongle manual apps that never interact with
integrate native libraries in their apps due to its convenience a vehicle, or general dongle terminal apps that just provide
for developing cross-platform apps. A typical example is the a terminal for expert users), and meanwhile classify them
.so library written in C/C++. In addition, since these libraries according to the types described in §II. In total, we eventually
are more difficult to reverse engineer, developers can hide collected 122 and 114 car companion apps from Android and
important code and data in them. However, with such native iOS platform respectively, including 146 dongle apps and 90
libraries used in apps, C AN H UNTER is not able to directly IVI apps. Table I shows the distribution of these apps. Note
construct a complete function call graph when tracing back to that there were also 71 paid apps on both app markets, but
the UI components to recover the semantics of the CAN bus we did not collect them due to our budget constraints.
commands. Therefore, we designed a solution which enabled
C AN H UNTER to successfully recover the semantics of over Experiment environment. We ran the static analysis with the
50% of all the commands. Specifically, we have to address two 236 tested apps on a 10.14 MacOS MacBook Pro with six
additional challenges when using disassemblers in IDA Pro to Intel Core i7 CPU and 16GB RAM as well as a Linux server
statically disassemble and analyze the native binaries in both running Ubuntu 16.04 equipped by twelve Intel Core i7-8700
Android and iOS platforms. CPUs and 32 GB RAM. The dynamic forced execution is
• Locating callers of virtual functions. In the native binaries, performed on a Google Nexus 4 with Android 7.0, as well as
the invocation of a virtual function is through referencing a jail-broken iPhone 6 with iOS 10.3.3.
the virtual function pointer in its virtual function table. To
achieve this, the assembly code first loads the address of B. Experiment Result
the virtual function table, and computes the virtual function
address by adding an offset value. Therefore, the caller of In total, C AN H UNTER discovered 182, 619 CAN bus com-
a virtual function cannot be directly inferred. To solve this mands2 from 107 out of the 236 apps we tested. Among them,
issue, C AN H UNTER starts by finding the virtual function 157, 296 commands (86.1%) are recovered with semantics.
table address based on the virtual function pointer, and Although not all the commands are recovered with semantics,
then it scans through all the references of the table address we would like to emphasize that the automatic syntactics
and checks which virtual function is called to eventually recovery provided by C AN H UNTER is already useful since it
locate the actual caller of the virtual function. can accelerate the reverse engineering process compared to
existing approaches that rely on manual efforts or fuzzing to
• Associating the native code with the app code. For iOS construct CAN bus commands in real car testing [13] [38].
apps, the native code is mixed with the Objective-C code Note that C AN H UNTER also discovered standardized CAN
so their association can be explicitly inferred in the same bus commands called OBD PIDs [53] which are for diagnostic
binary. However, for the Android apps, the Java byte code purposes and are ubiquitous in the diagnostic apps. Since these
and the libraries are separated, and the invocation of native
functions is through the Java Native Interface (JNI) from the 2 The reverse engineered commands are also available at https://github.com/
Native Development Kit (NDK) [1]. In this circumstance, OSUSecLab/CANHunter.

8
 Backward Slicing Forced Execution Semantics Recovery
App Name Size # Commands Car Model Semantics Slicing Execution By UI By Function
# Branches # Instr.
(MB) Recovered Recovered Cost (s) Cost (m) % Argument %
Dongle apps:
Carista 12 8 105,198 105,198 100% 100% 100% 100% 343 729 105,301 105,301 71 78 257,673 257,673 26% 26% 74% 74%
Carly for VAG 58 18 18,627 16,402 44% 66% 61% 56% 153 512 19,236 17,638 31 28 112,313 105,137 100% 10% 0 90%
Carly for BMW 67 38 14,377 16,427 100% 100% 100% 100% 125 502 15,132 18,898 27 29 97,354 113,494 100% 0 0 100%
Carly for Toyota 50 19 5,305 39 100% 99% 100% 100% 64 235 6,405 706 7 11 23,741 4,034 100% 100% 0 0
Carly for Renault 47 18 5,199 1,255 100% 96% 0 3.5% 50 197 5,284 1,384 8 15 30,189 5,557 0 100% 0 0
Carly for Mercedes 51 20 7,921 1,698 82% 79% 100% 100% 88 203 8,021 1,704 9 14 32,437 4,878 0 0 100% 100%
Carly for Porsche 46 18 1,963 278 100% 97% 0 0 17 155 2,122 384 1 4 4,234 1,521 0 0 0 0
BimmerCode 4 2 0 42 0 100% 0 100% 4 15 20 90 0 3 78 986 0 100% 0 0
BlueDriver 24 8 304 304 100% 100% 100% 100% 27 64 313 313 1 4 1,245 1,360 100% 100% 0 0
CarVantage 87 15 41 41 0 0 0 0 21 24 45 45 1 1 48 0 0 0 0 0
ANCEL 26 3.7 1 16 0 0 0 94% 14 11 41 34 1 1 101 292 0 60% 0 40%
CHIPOBD 10 3 0 29 0 0 0 76% 1 19 0 70 0 3 0 1,004 0 0 0 100%
Dr.OBD 4 2 0 2 0 0 0 100% 0 2 0 23 0 1 0 328 0 0 0 100%
inCarDoc 15 18 160 160 0 0 0 100% 39 50 251 251 1 7 2,555 2,273 100% 100% 0 0
iOBD2 57 5 5,007 218 0 57% 100% 100% 47 84 5,034 240 3 5 12,304 1,684 0 4% 0 96%
Kiwi OBD 7 4 220 6 0 0 100% 100% 23 20 227 227 1 1 252 260 100% 100% 0 0
MOSX 6 6 13 4 0 0 100% 0 9 9 71 25 1 1 280 127 100% 100% 0 0
OBDPlus 8 18 0 24 0 0 0 100% 0 22 0 92 0 1 0 558 0 0 0 100%
OBD Mate 34 4 1 11 0 0 0 100% 17 11 42 34 3 1 104 29 0 55% 0 45%
SekurTrack OBD 5 2 10 18 0 0 100% 100% 13 11 57 46 1 1 765 410 100% 100% 0 0
Spinn 26 6 0 32 0 0 0 32% 0 11 0 14 0 1 0 60 0 0 0 100%
Engie 28 11 144 68 0 0 100% 100% 40 30 98 15 1 1 1,540 170 100% 100% 0 0
Easy OBD 3 1 28 5 0 0 100% 82% 13 10 50 18 1 1 542 108 100% 100% 0 0
Savy Driver 65 21 15 0 0 0 0 0 22 1 227 1 1 0 1,040 2 0 0 0 0
DashLink 44 28 5 0 0 0 100% 0 107 1 9 4 2 0 2,361 11 60% 0 40% 0
Car Scanner 51 31 4 0 0 0 0 0 43 1 14 1 1 0 386 2 0 0 0 0
DashCommand 8 47 3 0 0 0 33% 0 8 1 112 4 1 0 195 11 100% 0 0 0
SekurLot 8 2 2 0 0 0 50% 0 4 0 52 0 1 0 121 0 100% 0 0 0
IVI apps:
HondaLink 49 8 0 52 0 100% 0 100% 14 19 108 83 0 2 2504 716 0 0 0 100%
HondaLink Aha 12 5 0 52 0 100% 0 100% 23 14 60 80 0 2 278 666 0 0 0 100%
Land Rover Comfort 21 3 0 19 0 100% 0 100% 18 11 183 98 1 1 1058 106 0 0 0 100%

TABLE II: Experiment results from C AN H UNTER for the car companion apps available on both Android and iOS platforms
(overlapped apps that have CAN bus commands). Numbers on the left are for for Android and on the right are for iOS.

commands are well-documented and have distinct features with false negatives of our system. In fact, the IVI apps do not
reserved identifiers, we are able to distinguish them from the directly generate CAN bus commands for the supported
non-standardized CAN bus commands. Overall, these docu- control functions on the app side, but rely on a third entity to
mented OBD PIDs take up approximately 15% of our results, interpret the requests to CAN bus commands. Particularly, a
while the rest 85% are customized CAN bus commands. majority of them is found to first send the control commands,
usually in the form of constant strings such as “UNLOCK” for
Among the 107 car companion apps that have CAN bus door unlocking, to a cloud server, and rely on the connection
commands recovered by C AN H UNTER, interestingly 49 of between the cloud server and the vehicle to control it. In this
them exist in both Android and iOS platforms (with the same paper, we call this type of commands interpreted commands.
app name). The distribution of the reverse-engineered CAN Among the 90 IVI apps, we found that 82 (91.1%) of them
bus commands from these car companion apps is presented adopt this design. For car companion apps with such a design,
in Table II, which summarizes the statistics of CAN bus it is impossible to recover CAN bus commands directly by
command syntactics and semantics recovered from each app, only analyzing the mobile apps without using the actual
as well as the detailed intermediate running statistics including cars or at least the actual IVI units. For the rest 8 IVI apps,
the cost of backward slicing, dynamic forced execution, and the C AN H UNTER did not detect any obvious interpreted string
total number of branches and instructions. For the remaining commands and instead detected the URLs for each particular
58 apps that are available on only one of the Android and type of commands in the cloud server which will eventually
iOS platforms, their results are presented in Table III. inject the CAN bus commands to the vehicles.
1) Result Characteristics by App Categories: Among
the 107 car companion apps that expose CAN bus commands, Dongle apps. Among the 146 dongle apps, C AN H UNTER was
only 3 of them are IVI apps while the other 104 are dongle able to discover CAN bus commands from 104 (71.2%) of
apps. There are some interesting findings on these apps them, which shows that it is much more common for dongle
described as follows: apps to directly construct CAN bus commands on the app
side than IVI apps. We also investigate the reasons for the
IVI apps. The 90 IVI apps in our experiment indeed remaining 42 dongle apps, and find that 22 of them also adopt
provide remote vehicle control functions, but we find that the design of interpreted commands for CAN bus command
C AN H UNTER produced CAN bus commands from only 3 of construction. Specifically, the OBD-II dongles compatible
them. For these three apps, we discover that their developers for these apps are specially designed to translate control
accidentally integrate the CAN bus commands into the apps, request strings from the dongle apps to CAN bus commands.
because these commands in fact can never be triggered and For the rest 20 apps, C AN H UNTER did not identify any
sent out from the app, though C AN H UNTER is able to find commands due to obfuscation (i.e., anti-analysis techniques)
them from the network APIs. We further investigated all that prevented our analysis from building a complete CFG in
other IVI apps and find that this is actually not due to the the backward slicing step.

9
 Backward Slicing Forced Execution Semantics Recovery
App Name Size (MB) #Commands Car Model Semantics Slicing Execution By UI By Function
# Branches # Instr.
Recovered Recovered Cost (s) Cost (m) % Argument %
Android apps:
Obd Harry Scan 5 141 0 100% 19.3 54 0.13 482 100% 0
WEG Motor Scan 12 105 0 100% 14.41 244 0.73 2,638 100% 0
Dr. Prius / Dr. Hybrid 2 31 0 100% 17.65 170 3.00 10,798 0 100%
AlfaOBD Demo 32 27 0 0 211.12 269 1.13 4,058 0 0
Zyme Pro 15 12 0 66.7% 20.51 56 0.06 227 100% 0
OBDmax 6 12 0 25% 20.4 199 0.17 596 100% 0
OBD2 Scaner 6 9 0 0 20.68 84 0.17 604 0 0
Vyncs 24 8 0 0 35.28 229 0.38 1,350 0 0
Torque Lite 6 8 0 100% 14.94 147 0.13 470 100% 0
StarLine 25 8 0 100% 34.51 141 1.55 5,587 100% 0
OBD ECU Access Tester 0.3 7 0 100% 0.9 14 0.02 69 100% 0
CarSys Scan 4 6 0 16.67% 25.86 67 0.04 161 100% 0
Obd Arny 3 5 0 0 15.65 60 0.1 367 0 0
OBD Boy 5 5 0 0 20.43 52 0.09 334 0 0
Best Top NH OBD II 2018 15 5 0 20% 8.1 35 0.06 231 100% 0
GPS7 CLIENTE2 7 4 0 0 5.56 28 0.05 162 0 0
Auto Agent 31 4 0 0 21.7 375 1.34 4,826 0 0
FAPlite Citroen/Peugeot OBD2 3 4 0 0 16.54 72 0.07 254 0 0
RYKA GPS Track 4 4 0 0 9.75 66 0.04 157 0 0
MotorData OBD Car Diagnostics 10 4 0 0 8.11 22 0.04 146 0 0
Clear And Go 4 4 0 0 20.33 35 0.06 233 0 0
OBD Driver Free 3 4 0 0 13.88 150 0.81 2,908 0 0
OBD II SYSTEM 15 4 0 0 8.75 26 0.03 119 0 0
OBDeleven PRO 25 4 0 0 25.41 75 0.11 405 0 0
OBD JScan 38 4 0 0 11.36 74 0.11 411 0 0
ChevroSys Scan Free 4 4 0 0 52.52 17 0.04 136 0 0
PHEV Watchdog 5 4 0 0 15.95 93 0.1 354 0 0
OBD Codes 4 4 0 0 8.32 65 0.05 175 0 0
Volvo Penta Easy Connect 37 4 100% 0 15.96 74 0.09 335 0 0
AutoNiveau 1 2 0 100% 4.64 7 0.11 386 0 100%
Bosch Mobile Scan 45 1 0 0 8.69 75 0.16 583 0 0
Piston 2 1 0 0 6.07 8 0.01 30 0 0
U-Scan 44 1 0 0 7.4 43 0.1 365 0 0
UltraGauge 4 1 0 0 5.11 45 0.18 651 0 0
Garage Pro 10 1 0 0 20.51 56 0.06 227 0 0
Fuel Economy for Torque Pro 6 1 0 0 20.74 118 0.47 1,709 0 0
iOS apps:
Carly for Partners 35 809 89% 100% 297.48 1,858 20.82 7,495 100% 0
Car2Mobile 2 2 0 100% 0.42 4 0.53 12 100% 0
DrivePro OBD 7 160 0 100% 17.33 245 3.28 1,020 0 100%
ForScan Viewer 2 512 100% 0 80.97 255 6.2 2,350 0 0
FourStroke 1 47 0 100% 2.35 16 2.58 993 100% 0
Gauged 2 25 0 100% 8.46 26 2.85 1,068 100% 0
Konnwei OBD 1 16 0 94% 8.32 43 1.4 533 0 100%
Leagend OBD 3 28 0 79% 14.71 116 4.11 1,580 0 100%
Mini OBD II 3 52 0 100% 11.72 50 0.82 312 100% 0
Smart Connect 4 16 0 63% 1.7 8 0.34 126 0 100%
Smart OBD 3 2 0 100% 29.72 36 1.15 440 100% 0
Zhinengpeijia 6 22 0 86% 19.45 218 5.63 2,194 0 100%
V 1 9 0 56% 10.7 39 0.85 333 0 100%
OBD Fusion 49 2 0 0 0.27 3 0.01 6 0 0
MaxiAp200 183 495 0 13% 675.78 8,972 24.78 74,589 0 100%
Diag-Asia 41 322 0 13% 228.15 4,325 9.20 30,374 0 100%
Diag-China 163 585 0 4% 609.73 7,522 20.91 64,815 0 100%
MaxiAp 6 49 0 8% 229.88 3,285 8.30 24,893 0 100%
Diag-Europe 194 788 0 14% 772.64 9,234 21.42 83,545 0 100%
Diag-VW 182 201 0 23% 470.02 7,132 20.45 65,438 0 100%
Auto Diag 119 42 0 24% 405.55 5,132 11.76 43,420 0 100%
Diag-USA 123 313 0 2% 417.32 5,756 13.65 48,576 0 100%

TABLE III: The experiment result for the remaining car companion apps in addition to those in Table II.

2) Result Characteristics by Car Models: Overall, C AN - examples for control semantics are locking doors, sounding
H UNTER recovered car model information of 161, 819 (88.6%) horns. Typical examples for diagnosis semantics are reading
CAN bus commands, covering over 360 car models from 21 parameters from the vehicle such as speed, temperature, volt-
car makers. The distribution of the commands over part of age, etc., which enable users to monitor the status of their cars.
the car makers and models are shown in Table IV. As shown,
the reverse engineered results cover most of the popular car 4) Additional Commands: Since the target APIs are low-
makers and models today such as Audi A4, Toyota Corolla, level network programming interfaces, the reverse engineering
Honda Civic, etc. capability of C AN H UNTER is not limited to CAN bus com-
mands but all communication data sent from car companion
3) Result Characteristics by Semantics: In total, C AN - apps to the vehicles or clouds. In particular, we find that
H UNTER successfully recovered the related semantics of in our results C AN H UNTER also discovered 41 unique AT
157, 296 (86.1%) commands. We manually interpreted and commands from the dongle apps and 267 interpreted com-
categorized them and found 3, 439 different kinds of semantics. mands from the IVI apps, which are presented in Table X
Among them, 1,309 command semantics are for vehicle con- and Table XI in Appendix. Note that these commands can be
trol while the remaining are for diagnosis. In Table V, we show easily distinguished from the CAN bus commands due to the
part of the semantics associated with the top number of recov- significant differences of the structure and format. Specifically,
ered commands along with their semantics categories. Typical AT commands are used for configuring the ELM interface of

10
 Car Maker # Commands Car Model
128,298 (70.3%) command semantics. To summarize, in cross-
Audi 51,517 A3, A4, A5, A6, A7, A8, Q3, Q5, Q7, S3, S4
Volkswagon 44,504 Cabrio, Corrado, Caddy, Gol, Golf, Jetta, platform and cross-app validation, we observe no inconsis-
Lupo, New Bettle, Passat, Polo, Santana, tency in command syntactics and semantics. From public
Transporter, Octavia, Kombi, Roomster resources and real-car testing, we discover no false positive
Skoda 11,009 Citigo, Fabia, Rapid, Superb, Yeti
Toyota 9,030 Auris, Avensis, Camry, Corolla, Prius, RAV4 in syntactics recovery and only 3 (1.2%) false positives in
BMW 8,963 Series 1, 3, 5, M5, X5 semantics recovery among the 241 manually validated CAN
Seat 8,277 Ibiza, Leon, Altea, Mii, Toledo, Arosa
Mercedes 7,247 Benz
bus commands. Though there are 3 false positives found in the
Lexus 6,087 CT200, ES350, GS350, GX460, RX450, IS460 semantic validation, we have confirmed that they are due to
Renault 5,025 Cilo, Megane2 programmer mistakes instead of the design or implementation
Porsche 2,326 987FL, 997, 996, Cayman
MINI 2,118 Clubman, Cooper of C AN H UNTER (detailed later).
Scion 570 FRS
Chevrolet 198 Lagunall Evaluation criteria and threats to validity. Since the com-
Subaru 159 Brz
Honda 104 Civic mands across car models are often quite different, we only
Bently 60 Arnage, Azure, Brooklands compare those of the same model. There are three means
Lincoln 52 Continental
Ford 26 Galaxy
to evaluate our results: (1) public resources, (2) cross-app
Lamborghini 20 Gallardo and cross-platform validation, and (3) real-car testing. The
syntactics is validated by comparing the hexadecimal values
TABLE IV: Distribution of reverse-engineered CAN Bus com- of the commands. As for the semantic validation, we compare
mands over part of car makers. the extracted semantics strings and thus manual validation is
also needed since the comparison is at natural language level.
Semantics # Commands Category
Engine speed 460 Diagnosis We have to note that our cross-app and cross-platform
Coolant temperature 281 Diagnosis validation assumes developers never make the same mistakes
Throttle angle 256 Diagnosis
Oil temperature 176 Diagnosis of the corresponding CAN bus commands in both apps or both
Engine load 134 Diagnosis platforms, though it is very unlikely that such mistakes could
Boost pressure actual value 133 Diagnosis
Motor temperature 123 Diagnosis
happen. Similarly, we assume the public available CAN bus
Battery voltage 119 Diagnosis commands are also truly validated.
Comfort function remote incl roof 77 Control
Comfort function key 73 Control (1) Public resources. While CAN bus commands are confiden-
Single door lock remote 60 Control
Blink on unlock key 42 Control tial, we find that some of them are still publicly available, e.g.,
Sound on remote lock volume 40 Control posted at car hacking forums, but scattered all over the Internet.
Blink on lock 37 Control We tried our best to search for the ground truths from online
Auto unlock when moving 27 Control
Marker lights when unlock 24 Control forums and documents (e.g., [18] [5] [9] [11] [16]), and picked
the commands that are validated by car hackers or researchers
TABLE V: Distribution of reverse-engineered CAN Bus com- through real-car testing. In addition, we also checked the
mands over part of command semantics. source code of 3 open-sourced self-driving car platforms:
ApolloAuto, Autoware, and Openpilot, which may also have
CAN bus commands. Among them, we find matched CAN bus
OBD-II dongles [10], which are sent through the Bluetooth commands from Openpilot, but not from the other two code
or socket interfaces to the dongles. The other type is the bases since their car models do not match with the ones in
interpreted commands from the IVI apps mentioned in §VI-B1. our results. Eventually, we collected 69 CAN bus commands
These commands are often interpreted into decimal values or in total across 4 car models that are present in our results:
human-understandable strings, and are either pushed to the Toyota Prius, Audi A3, Seat Ibiza I-Tech, and Honda Civic.
remote cloud server or to the vehicle.
Among these 69 CAN bus commands, 38 of them can
find matched syntactics with the commands uncovered in our
C. Correctness Evaluation experiment, which are listed in Table VI. As shown, for these
To evaluate the effectiveness of C AN H UNTER, we need to 38 commands, C AN H UNTER is able to recover the semantics
validate the correctness of the CAN bus commands recovered of 33 (86.84%) commands. Within these 33 commands, 30
from our experiments. However, due to the high difficulty (90.91%) have matched semantics, while the remaining 3 are
in obtaining the ground truth (i.e., the publicly known and false positives which are indicated by cross marks in the table.
validated CAN bus commands), performing a comprehensive For example, for command 0x324, the correct semantics
correctness validation is very challenging for two reasons. should be “Water Temperature”, but our tool recovered it as
First, it is almost impossible to solely use real cars to validate “ENG_TEMP”. We went back to check the app code, and found
all these commands since it is both inefficient and costly. that the semantics strings associated with these 3 CAN bus
Second, as introduced in §II, car manufactures and third-party commands are indeed correctly recovered by our tool based on
developers treat CAN bus commands confidential and never our semantics recovery algorithm. Thus, these false positives
post any of them in public documents. are actually not caused by the design or implementation of
C AN H UNTER, but very likely due to programmer mistakes.
Nevertheless, in this paper we tried our best to evaluate
the effectiveness from three sources: public resources, cross (2) Cross validation. Due to the limited number of publicly
validation, and real car tests. This allows us to successfully available ground truth, we also attempted to evaluate the
validate 130,011 (71.2%) command syntactics as well as correctness of our system by checking the uncovered CAN bus

11
 Car Semantics Semantics Android iOS Overlapped
Syntac. Matched App
Model (Ground Truth) (Our Result) # Syn. # Sem. # Syn. # Sem. # Syn. # Sem.
0x727 Transmission Transmission X ANCEL 1 0 16 15 1 0
0x750 Main Body MainBody X BlueDriver 304 304 304 304 304 304
0x780 Air Bag Airbag X Carista 105,198 105,198 105,198 105,198 105,198 105,198
0x781 Precrash preCrash X Carly for BMW 14,377 14,377 16,427 16,427 13,480 13,480
0x790 Distance Control Radar X Carly for Mercedes 7,921 6,528 1,698 1,698 1,393 1,393
0x791 Precrash2 preCrash 2 X Carly for Porsche 1,963 0 278 0 7 0
Toyota 0x7A1 Steering Assist Steering Assist X Carly for Renault 5,199 0 1,255 44 1,058 0
Prius 0x7A2 Park Assist APGS X Carly for Toyota 5,305 5,266 39 39 39 39
0x7B0 ABS Brake ABS X Carly for VAG 16,402 7,283 18,627 10,429 7,283 7,283
0x7C0 Instrument ComboMeter X CarVantage 41 41 41 41 41 41
0x7C4 Air Conditioner Air Conditioning X Engie 144 144 68 68 68 68
0x7D0 Navigation Navigation X inCarDoc 160 160 160 160 160 160
0x7E0 Engine Controls ECT X iOBD2 5,007 5,007 218 218 218 218
0x7E2 Hybrid System Cruise Control X Kiwi OBD 220 220 6 6 6 6
0x70C SteeringWheel Steering wheel X SekurTrackOBD 10 10 18 18 10 10
0x70A EPHVA14AU37
0x710 GatewLear TABLE VII: Statistics of overlapped CAN bus command pairs
0x712 SteerAssisMQB
0x713 Brake1UDSCondi ABS Brake X in cross-platform validation.
Audi 0x714 DashBoard Instrument X
A3 0x715 Airba
0x746 AirCondiFront Auto HVAC X # Overlapped
Car model App1 App2
0x773 MUStd4CPASE Android iOS
0x7E0 ECM Engine X
0x7E1 TCMDQ Transmission X
Audi A3 0 18 Carly for VAG Carly for Partners
0x711 ImmoUDS Immobilizer X Audi A4 52 52 Carista Carly for VAG
Seat 0x713 Brake1ESP ABS Brakes X Audi A6 22 22 Carista Carly for VAG
Ibiza 0x714 KombiUDS Instruments X Audi A8 0 26 Carista Carly for VAG
0x7E0 ECM Engine X Seat Leon 19 19 Carista Carly for VAG
0x158 Speed EAT TRANS SPEED X Skoda Fabia 0 24 Carista Carly for VAG
0x17C Engine RPM ENG STATUS X VW Caddy 0 12 Carista Carly for VAG
0x188 EAT CHANGE RESF VW Polo 52 52 Carista Carly for VAG
Honda 0x1A3 TM CHANGE RESF VW Jetta 0 46 Carista Carly for Partners
Civic 0x324 Water Tempreature ENG TEMP 7 VW Passat 0 42 Carista Carly for Partners
0x1A4 VSA STATUS VSA WARN STATUS ABS X
0x305 SEATBELT STATUS SRS EDR DELTA VMAX 7
VW Golf 0 168 Carista Carly for Partners
0x35E CAMERA MESSAGES FCM WARN STATUS 7 VW Touareg 0 50 Carista Carly for VAG
0x391 GEARBOX CVT ATF CHANGE RESF X VW Up 0 20 Carista Carly for VAG
VW Tiguan 8 0 Carista Carly for VAG
TABLE VI: Commands validated with public resources. Skoda Superb 0 20 Carista Carly for VAG
Porsche Cayenne 0 72 Carly for VAG Carly for Partners
Toyota Prius 39 39 Carly for Toyota Carista
Toyota Camry 18 0 Carly for Toyota Carista
Toyota Corolla 21 0 Carly for Toyota Carista
commands across different apps from the same or different Porsche 0 4 Carly for Porsche Carly for VAG
platforms. Since the CAN bus commands are independent Porsche 0 4 Carly for Porsche Carly for Partner
of the car companion apps, the command syntactics and BMW 550i 8 8 Carly for BMW Carista
semantics of the same car model should be consistent across TABLE VIII: Statistics of overlapped CAN bus command pairs
different apps, which thus makes it possible to perform in cross-app validation.
correctness evaluation. Although the cross validation does not
directly reflect the validness of the commands, it sufficiently
implies the effectiveness and generality of our system since
the results come from different mobile app implementations. comparison, we observed no inconsistency, which shows the
high effectiveness of our system.
Cross-platform validation. Among all car companion apps
that expose CAN bus commands, 31 of them are available Cross-app validation. In addition to cross-platform validation,
on both Android and iOS platforms. We compared the CAN we also perform same-platform cross-app validation. Specifi-
bus commands that C AN H UNTER uncovered from them, and cally, we check if there are overlapping command pairs of the
found that 129, 266 (70.8%) commands uncovered from 15 same car model from different apps within the same platform
of these apps have matched syntactics by cross comparing (either Android or iOS). Overall, as presented in Table VIII, we
the hexadecimal values. In Table VII, we show the names are able to find 745 CAN bus command pairs with matched
for these 15 apps, and the statistics for the total numbers of syntactics, which belong to 22 car models from 6 different
recovered syntactics and semantics from each platform as well apps. Among them, 98 (13.2%) pairs have both commands
as the number of matched syntactics and semantics. For the in the pairs recovered with semantics, and no inconsistent
remaining 16 apps, C AN H UNTER could not extract CAN bus semantics is observed between these pairs.
commands from either the Android one or the iOS one, which
thus prevents us from validating their results. For example, (3) Real-car testing. We also tested the uncovered CAN bus
C AN H UNTER found 123 CAN bus commands from the 3 IVI commands on the real automobiles that we can access. The
apps in iOS, but did not find any from their Android versions. two tested car models are Toyota RAV 4 2014 and Toyota
We manually checked these 3 apps and found that this is due to Corolla 2014 and the tested app is com.prizmos.Carista which
different implemented logic in the app code instead of analysis has the same set of CAN bus commands for Android and
inaccuracies in our system. We suspect that this is because iOS. We implemented a dynamic testing framework based
their Android and iOS versions are developed by separate on Frida and Python, which hooks the target APIs described
teams. Among the CAN bus command pairs with matched in §V and captures the CAN bus commands sent from the
syntactics, we then compare the 128, 200 pairs (99.2%) where app to the vehicle. In the experiment, we manually trig-
the semantics of both of the commands are recovered. In this gered all possible UI components that generate the CAN

12
 Command (RAV4) Command (Corolla) Semantics
750 ... 14 1A 26 750 ... 1A 65 02 Wireless door locking
VII. D ISCUSSIONS AND F UTURE W ORK
750 ... 14 92 26 750 ... 92 65 02 Blink turn signals
750 ... 14 9A 06 750 ... 9A 45 02 Panic Function on remote A. Root Cause and Countermeasure
750 ... 14 9A 25 750 ... 9A 61 02 Relock automatically
750 ... 9A 26 00 750 ... 65 02 20 Beep volume C AN H UNTER has discovered a large set of CAN bus
750 ... 14 9A 26 750 ... 8A 65 02 Beep when locking
750 ... 13 00 40 750 ... 98 65 02 Warn beep when sunroof open commands from mobile apps. The root cause is that CAN
750 ... 14 9A 66 750 ... 9A 25 02 Unlock via remote bus commands or their indirect mappings must exist in the
750 ... 11 00 60 750 ... 14 06 00 Unlock via physical key
750 ... 11 80 20 750 ... 11 C0 20 Unlock when shifting into gear
app in order to achieve the desired diagnosis or remote control
750 ... 11 80 40 750 ... 11 C0 60 Unlock when shifting into park functionalities. Interestingly, as shown in §VI-B1, the exposure
750 ... 11 80 70 750 ... 11 C0 70 Unlock when driver’s door open level of CAN bus commands differs greatly between dongle
750 ... 3B 15 00 750 ... 00 80 40 Daytime running light
750 ... 3B 12 10 750 ... 3B 12 10 Turn on interior lights apps and IVI apps. In particular, the developers of IVI apps
7C0 ... 3B A2 40 7C0 ... 3B A2 40 Display unit (MPG) tend to interpret CAN bus commands and thus do not directly
7C0 ... 3B 74 A0 7C0 ... 3B A7 C0 Seat belt warning (driver)
7C0 ... 3B A7 C0 7C0 ... 3B A7 C0 Seat belt warning (passenger) integrate them in the app code, while dongle app developers
7C0 ... 61 AE 40 7C0 ... 3B A1 28 Key in ignition sound tend to directly hardcode them.
7C0 ... 61 A7 C0 7C0 ... 3B AF 40 Lane-change signal auto flasher
7C0 ... 61 AB 00 7C0 ... 3B AB 00 ECU Drive indicator zone
7C0 ... 61 AE 40 7C0 ... 3B AE 00 Display odometer We suspect that the causes of the differences between IVI
7CC ... 00 00 00 7CC ... 3B 81 00 A/C power and dongle apps may be two folds. First, from the design
7CC ... 00 01 00 7CC ... 3B 82 00 Fan Speed
perspective, the IVI systems are far more sophisticated than
TABLE IX: Part of commands validated with real-car testing. OBD-II dongles. More specifically, IVI systems usually have
cellular network connections and operating systems, which can
enable more complicated capabilities such as interacting with a
third entity (i.e., the cloud). However, OBD-II dongles usually
bus commands, intercepted the commands, and compared the do not have cellular network and thus completely rely on the
testing results with the ones reported from C AN H UNTER. In input from nearby mobile apps connected through WiFi or
total, we obtained 88 commands from Toyota RAV4 and 84 Bluetooth. Second, IVI systems and the corresponding IVI
commands from Toyota Corolla, and all of them match the apps are typically well-engineered by car manufacturers who
command automatically discovered from C AN H UNTER, which are aware of the sensitivity and safety-criticalness of their
thus concretely demonstrates the effectiveness of our system. private CAN bus commands. On the contrary, the dongle apps
In addition, corresponding physical behaviors (e.g., disabling are usually developed by third-party developers who may not
wireless door locking) were observed on the vehicles, which be fully aware of the importance of CAN bus commands.
also shows the validness of these commands. Table IX presents Interestingly, we also find that a small portion of the CAN
a selected part of validated CAN bus commands (46 in total) bus commands are never used in some IVI and dongle apps,
from these two vehicles. since there is no UI correlation to let users trigger them. We
suspect they are only for debugging and testing purposes, and
thus should have been removed when the apps are released.
To prevent CAN bus commands from being reverse engi-
neered from companion mobile apps, there are two counter-
D. Performance Evaluation measures. First, developers can leverage interpreted commands
which can only be recognized by cloud or device firmware,
To evaluate the system efficiency, we executed C AN - as demonstrated in the IVI apps. When specific functions are
H UNTER on the 236 car companion apps in our dataset and triggered, the interpreted commands are sent to cloud or device
collected the running time and intermediate results. During which will translate them into valid CAN bus commands.
the experiments, we find that C AN H UNTER is reliable when Therefore, reverse engineer can only obtain these manufacture-
analyzing all the apps without any human intervention and specific commands instead of the CAN bus commands. Sec-
crashes. The detailed statistics are shown in Table II as well ond, anti-analysis techniques such as encryption and obfus-
as Table III and the performance results are broken down cation can be deployed to encrypt the hardcoded CAN bus
into three parts: backward slicing, dynamic forced execution, commands and obfuscate the program control flow, which
and semantics recovery. Overall, the backward slicing usually increases the difficulty of reverse engineering the mobile apps.
takes several minutes to complete while the dynamic forced
execution costs from several minutes to hours. We have broken B. Limitations and Future Work
down the contributions of UI and function arguments to the
semantics recovery results, which shows both of them are While C AN H UNTER has uncovered a significant number of
useful in the recovery process. There are some interesting CAN bus commands, it still has several limitations. First, due
findings when comparing the apps between the two platforms. to the limited ground truths and resources, we are only able
For instance, we can notice that the size of the apps tend to be to validate 70% of our results. Meanwhile, a majority of the
larger in iOS platform than that of Android (e.g., the largest validated commands comes from the cross validation and as a
app in iOS is 194M whereas the largest one in Android is result, the evaluation is possibly not 100% correct because the
only 45M). Second, since there are more commands to recover developers can also make mistakes. As mentioned in §VI-C
in iOS apps, their analysis time usually took longer. Finally, that we observe inconsistent semantics between our result and
it is interesting to notice that function argument association the public resources even though C AN H UNTER functioned
heuristics plays a more critical role for semantic recovery in correctly. The most reliable approach for validation is testing
iOS platform. the commands on real automobiles. In addition, false negative

13
may exist because C AN H UNTER only focuses on the CAN bus Protocol reverse engineering and semantics recovery. Re-
commands that sent from the low-level network APIs. verse engineering of CAN bus commands is a type of network
protocol reverse engineering, which is a well studied area
Second, as found in §VI, our current implementation of especially in desktop applications and malware. For example,
C AN H UNTER is not resilient to anti-analysis techniques such Polyglot [26], AutoFormat [40], Discoverer [30], Tupni [31],
as control flow obfuscation, which can fail our backward and ReFormat [58] use information from program executions
slicing. Note that obfuscation is not a specific limitation of and/or network traces to reverse engineer network protocols
our work, and it has long been a challenge for static program such as HTTP. Besides protocol syntactics, some previous
analysis and reverse engineering [34]. Nevertheless, there also work also studied the recovery of protocol semantics based on
exists some deobfuscation solutions (e.g., [23]), which we the communication traces [62]. Netzob [24], Dispatcher [25]
plan to explore and integrate into C AN H UNTER. and ProDecoder [57] combine dynamic program analysis and
Third, C AN H UNTER reported a great number of AT NLP techniques to extract semantics of protocols of interests.
commands and also interpreted commands during our Compared with previous works, we have a unique problem of
experiments (§VI-B4). Though not directly involved in the uncovering the CAN bus commands from highly interactive
CAN bus network, they can still affect the behavior of the mobile apps, and we solve this problem by using dynamic
vehicle by interacting with cloud or OBD-II dongle, especially forced execution to uncover the syntactics and code-level clues,
for the interpreted commands which are capable of unlocking e.g., UI and function argument associations, to uncover the
the vehicle and shutting down the engine. Therefore, a further semantics.
study of the security impact of these interpreted commands is
worth of exploration. Forced execution. Forced execution has been used to discover
potential security threats since it can execute programs ignor-
Finally, we have witnessed the bloom of the IoT industry ing regular constraints and external inputs. Recently, a number
recently, and there are a great number of IoT devices of forced execution tools were built including J-Force [37]
having companion mobile apps such as those in smart home for JavaScript applications, X-Force [50] and Limbo [60] for
systems [55] [22] [61]. In order for these mobile apps to binaries, and Dexism [34] and Forced-Path execution [36] for
communicate with the IoT devices, various IoT protocols are Android apps. In these tools, they brute-force execute the
designed. In particular, the car companion apps in this work program flows by ignoring conditions in order to cover all
can be considered a specific case of such IoT companion possible branches. C AN H UNTER is inspired by these works,
mobile apps, and CAN is a special type of IoT protocol and the and it adopts forced execution to our particular application
CAN bus commands are the protocol message data that deter- domain with a slicing-based forced execution, which executes
mines the function. Therefore, C AN H UNTER has the potential only the partial instructions involved for generating the CAN
to be extended to reverse engineer the syntactics and semantics bus commands.
of other IoT protocols. In addition, since C AN H UNTER adopts
dynamic forced execution, the analysis does not require real
device connections and thus has the great potential to enable IX. C ONCLUSION
large-scale IoT companion mobile app analysis. As such, We have presented C AN H UNTER, the first cost-effective
exploring the use of C AN H UNTER to IoT protocol analysis and automatic cross-platform reverse engineering system of
with companion mobile apps is our another future work. CAN bus commands through analyzing only the companion
mobile apps without using real cars. It features syntactic
VIII. R ELATED W ORK recovery of CAN bus commands using backward slicing and
dynamic forced execution, and semantic recovery using UI
CAN and vehicle security. CAN has been acting as an component correlation and function argument association. A
essential part of vehicle security research. Previous work has prototype of C AN H UNTER for both Android and iOS platforms
proposed many exploits to remotely control a vehicle as well has been developed, and applied to test 236 car companion
as reverse engineering the CAN protocol and commands. apps from both app markets. Evaluation results show that
For instance, Miller et al. [45], Checkoway et al. [27], and C AN H UNTER is able to uncover 182, 619 unique CAN bus
Mazloom et al. [43] studied various possible attack surfaces commands of 360 car models from 21 car makers, and recover
such as Bluetooth, Internet, and apps, which inspires our re- the semantics of 86.1% of them. Through public resources,
search. Reverse engineering of CAN bus commands is also an cross validation, as well as real car tests, we have validated the
important building block for subsequent attacks on in-vehicle syntactics and semantics of over 70% of the recovered CAN
systems. Previous work tried to observe the traffic inside the bus commands. No inconsistency is observed in cross-platform
automotive to obtain the CAN packets and replayed them back and cross-app validation, and only 3 false positives (which are
into the CAN to attack the vehicle (e.g., [46] [51] [44] [38]). caused by mistakes from app developers, not the limitation
Recently, there are also efforts on the defensive approaches from C AN H UNTER) are discovered in semantics recovery from
to protect the attacks on CAN such as anomaly detection public resources and real-car testing. The rationale behind
[28] [48] [49], forensics measures [35] and delayed data C AN H UNTER and also the countermeasure against our reverse
authentication [49]. Compared with our work, the previous engineering is also discussed in the paper.
reverse engineering works on CAN are not comprehensive
since each of them only focuses on one or two car models. ACKNOWLEDGMENT
Besides, our research is novel in that we approach the same
reverse engineering problem from a completely different angle We would like to thank our shepherd Manuel Egele and
by using the car companion apps emerged in recent years. also the anonymous reviewers for their helpful comments that

14
have significantly improved the paper. This research was sup- [25] Juan Caballero and Dawn Song. Automatic protocol reverse-
ported in part by National Science Foundation (NSF) Awards engineering: Message format extraction and field semantics inference.
1834215 and 1850533. Any opinions, findings, conclusions, or Computer Networks, 57(2):451–474, 2013.
recommendations expressed are those of the authors and not [26] Juan Caballero, Heng Yin, Zhenkai Liang, and Dawn Song. Polyglot:
Automatic extraction of protocol message format using dynamic binary
necessarily of the NSF. analysis. In Proceedings of the 14th ACM conference on Computer and
communications security, pages 317–329. ACM, 2007.
[27] Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Ander-
son, Hovav Shacham, Stefan Savage, Karl Koscher, Alexei Czeskis,
R EFERENCES Franziska Roesner, Tadayoshi Kohno, et al. Comprehensive Experi-
mental Analyses of Automotive Attack Surfaces. In USENIX Security
[1] Android ndk. https://developer.android.com/ndk/. Symposium, 2011.
[2] Apolloauto/apollo: An open autonomous driving platform. https:// [28] Kyong-Tak Cho and Kang G Shin. Fingerprinting Electronic Control
github.com/ApolloAuto/apollo. Units for Vehicle Intrusion Detection. In USENIX Security Symposium,
[3] Bluetooth low energy overview — android developers. https:// 2016.
developer.android.com/guide/topics/connectivity/bluetooth-le.
[29] Shauvik Roy Choudhary, Alessandra Gorla, and Alessandro Orso.
[4] Can bus sniffer - reverse engineering vehicle data (wireshark). Automated test input generation for android: Are we there yet? arXiv
https://www.csselectronics.com/screen/page/reverse-engineering-can- preprint arXiv:1503.07217, 2015.
bus-messages-with-wireshark/language/en.
[30] Weidong Cui, Jayanthkumar Kannan, and Helen J Wang. Discoverer:
[5] clear-mind ii: Fit3 hv(gp5)canł. http://clear-mind-mark2.blogspot.com/ Automatic protocol reverse engineering from network traces. In
2016/12/fit3-hvgp5can.html. USENIX Security Symposium, pages 1–14, 2007.
[6] Core bluetooth — apple developer documentation. https:// [31] Weidong Cui, Marcus Peinado, Karl Chen, Helen J Wang, and Luis
developer.apple.com/documentation/corebluetooth. Irun-Briz. Tupni: Automatic Reverse Engineering of Input Formats. In
[7] Cpfl/autoware: Open-source to self-driving. https://github.com/CPFL/ ACM conference on Computer and Communications Security (CCS),
Autoware. 2008.
[8] Cycript. http://www.cycript.org/. [32] Roderick Currie. Hacking the can bus: basic manipulation of a modern
[9] Detecting anomalies in controller area network for automo- automobile through can bus reverse engineering. SANS Institute, 2017.
biles. http://cesg.tamu.edu/wp-content/uploads/2012/01/VASISTHA- [33] Marco Di Natale, Haibo Zeng, Paolo Giusto, and Arkadeb Ghosal.
THESIS-2017.pdf. Understanding and using the controller area network communication
[10] Elm327 obd to rs232 interpreter. https://www.elmelectronics.com/wp- protocol: theory and practice. Springer Science & Business Media,
content/uploads/2016/07/ELM327DS.pdf. 2012.
[11] Explorative techniques and vulnerability assessment on automotive net- [34] Mohamed Elsabagh, Ryan Johnson, and Angelos Stavrou. Resilient and
works. https://www.politesi.polimi.it/bitstream/10589/141804/1/2018 scalable cloned app detection using forced execution and compression
07 Calin.pdf. trees. In 2018 IEEE Conference on Dependable and Secure Computing
[12] Frida a world-class dynamic instrumentation framework. https:// (DSC), pages 1–8. IEEE, 2018.
www.frida.re/. [35] Tobias Hoppe, Stefan Kiltz, and Jana Dittmann. Security threats to
[13] How to Hack a Car - A Quick Crash Course. https: automotive can networkspractical examples and selected short-term
//medium.freecodecamp.org/hacking-cars-a-guide-tutorial-on-how- countermeasures. Reliability Engineering & System Safety, 96(1):11–
to-hack-a-car-5eafcfbbb7ec. 25, 2011.
[14] Ida. https://www.hex-rays.com/products/ida/. [36] Ryan Johnson and Angelos Stavrou. Forced-path execution for android
applications on x86 platforms. In Software Security and Reliability-
[15] An introduction to the can bus: How to programmatically control a
Companion (SERE-C), 2013 IEEE 7th International Conference on,
car. https://news.voyage.auto/an-introduction-to-the-can-bus-how-to-
pages 188–197. IEEE, 2013.
programmatically-control-a-car-f1b18be4f377.
[37] Kyungtae Kim, I Luk Kim, Chung Hwan Kim, Yonghwi Kwon, Yunhui
[16] openpilot. https://github.com/commaai/openpilot.
Zheng, Xiangyu Zhang, and Dongyan Xu. J-force: Forced execution on
[17] Polysync/oscc: Open source car control. https://github.com/PolySync/ javascript. In Proceedings of the 26th international conference on World
oscc. Wide Web, pages 897–906. International World Wide Web Conferences
[18] Raspberry pi - virtual sensors for car computers. http: Steering Committee, 2017.
//www.grandprixforums.com/general-grand-prix-discussion/96047- [38] Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, Ta-
raspberry-pi-virtual-sensors-for-car-computers.html. dayoshi Kohno, Stephen Checkoway, Damon McCoy, Brian Kantor,
[19] Soot - a framework for analyzing and transforming java and android Danny Anderson, Hovav Shacham, et al. Experimental Security
applications. http://sable.github.io/soot/. Analysis of a Modern Automobile. In IEEE Symposium on Security
[20] Vehicle reverse engineering wiki. http://vehicle-reverse- and Privacy (S&P), 2010.
engineering.wikia.com. [39] Hyeryun Lee, Kyunghee Choi, Kihyun Chung, Jaein Kim, and Kangbin
[21] Why ford, lincoln, and lexus testers rule the self-driving roost. Yim. Fuzzing can packets into automobiles. In 2015 IEEE 29th
https://www.caranddriver.com/news/a15344273/why-ford-lincoln-and- International Conference on Advanced Information Networking and
lexus-testers-rule-the-self-driving-roost/. Applications, pages 817–821. IEEE, 2015.
[22] Amr Alanwar, Bharathan Balaji, Yuan Tian, Shuo Yang, and Mani [40] Zhiqiang Lin, Xuxian Jiang, Dongyan Xu, and Xiangyu Zhang. Au-
Srivastava. EchoSafe: Sonar-based Verifiable Interaction with Intelligent tomatic protocol format reverse engineering through context-aware
Digital Agents. In ACM Workshop on the Internet of Safe Things monitored execution. In Proceedings of the 15th Annual Network and
(SafeThings), 2017. Distributed System Security Symposium, San Diego, CA, February 2008.
[23] Richard Baumann, Mykolai Protsenko, and Tilo Müller. Anti-proguard: [41] Zhiqiang Lin, Xiangyu Zhang, and Dongyan Xu. Automatic reverse
Towards automated deobfuscation of android apps. In Proceedings of engineering of data structures from binary execution. In Proceedings of
the 4th Workshop on Security in Highly Connected IT Systems, pages the 17th Annual Network and Distributed System Security Symposium
7–12. ACM, 2017. (NDSS’10), San Diego, CA, February 2010.
[24] Georges Bossert, Frédéric Guihéry, and Guillaume Hiet. Towards [42] Aravind Machiry, Rohan Tahiliani, and Mayur Naik. Dynodroid: An
automated protocol reverse engineering using semantic information. In input generation system for android apps. In Proceedings of the 2013
Proceedings of the 9th ACM symposium on Information, computer and 9th Joint Meeting on Foundations of Software Engineering, pages 224–
communications security, pages 51–62. ACM, 2014. 234. ACM, 2013.

15
[43] Sahar Mazloom, Mohammad Rezaeirad, Aaron Hunter, and Damon services. In Annual Network and Distributed System Security sympo-
McCoy. A Security Analysis of an In-Vehicle Infotainment and App sium, February 2019 (NDSS 2019), 2019.
Platform. In Usenix Workshop on Offensive Technologies (WOOT), [63] Chaoshun Zuo, Zhiqiang Lin, and Yinqian Zhang. Why does your
2016. data leak? uncovering the data leakage in cloud from mobile apps. In
[44] Charlie Miller and Chris Valasek. Adventures in automotive networks 2019 IEEE Symposium on Security and Privacy (SP), pages 1296–1310.
and control units. Def Con, 21:260–264, 2013. IEEE, 2019.
[45] Charlie Miller and Chris Valasek. A survey of remote automotive attack [64] Chaoshun Zuo, Haohuang Wen, Zhiqiang Lin, and Yinqian Zhang.
surfaces. black hat USA, 2014:94, 2014. Automatic fingerprinting of vulnerable ble iot devices with static uuids
[46] Charlie Miller and Chris Valasek. Remote exploitation of an unaltered from mobile apps. In Proceedings of the 2019 ACM SIGSAC Conference
passenger vehicle. Black Hat USA, 2015:91, 2015. on Computer and Communications Security, pages 1469–1483, 2019.
[47] Michael Müter and Naim Asaj. Entropy-based Anomaly Detection for
In-vehicle Networks. In IEEE Intelligent Vehicles Symposium (IV), A PPENDIX
2011.
The interpreted commands reported from C AN H UNTER are presented in
[48] Michael Müter, André Groll, and Felix C Freiling. A structured Table XI which shows the distribution of the 267 interpreted commands with
approach to anomaly detection for in-vehicle networks. In Information the total 41 IVI apps that adopt this design combining all duplicated ones
Assurance and Security (IAS), 2010 Sixth International Conference on, for Android and iOS. The interpreted commands are often represented by
pages 92–98. IEEE, 2010. human understandable strings (e.g., UNLOCK, LOCK) and numbers (e.g., 2
[49] Dennis K Nilsson, Ulf E Larson, and Erland Jonsson. Efficient for unlock and 0 for flash light). In particular, we also distinguish different
in-vehicle delayed data authentication based on compound message implementations of the IVI apps. Some of them push the commands to the
authentication codes. In Vehicular Technology Conference, 2008. VTC cloud which forwards control messages to the automobile, while others directly
2008-Fall. IEEE 68th, pages 1–5. IEEE, 2008. send the interpreted commands to the vehicle via Wi-Fi or Bluetooth.
[50] Fei Peng, Zhui Deng, Xiangyu Zhang, Dongyan Xu, Zhiqiang Lin, and Table X shows the distribution of the AT commands with the 20 dongle
Zhendong Su. X-force: Force-executing binary programs for security apps that expose them. In the experiment, we only reserve one command for
applications. In USENIX Security Symposium, pages 829–844, 2014. each kind of syntax, and totally we have discovered 41 types of AT commands.
[51] Jason Staggs. How to hack your mini cooper: reverse engineering can Specifically, the AT commands are sent through Bluetooth or socket APIs for
messages on passenger automobiles. Institute for Information Security, configuring the ELM327 interface [10] of the OBD-II dongles. For instance,
2013. command AT AL is for restricting the number of data byte in a CAN bus
[52] Jittiwut Suwatthikul, Ross McMurran, and R Peter Jones. In-vehicle message to 7 [10].
Network Level Fault Diagnostics Using Fuzzy Inference Systems.
Applied Soft Computing, 11(4):3709–3719, 2011. App # Command The Detailed Commands
[53] Ashraf Tahat, Ahmad Said, Fouad Jaouni, and Waleed Qadamani. Carly f. BMW 24 ATE, ATH, AT FC SH...
Android-based universal vehicle diagnostic and tracking system. In Carly f. Toyota 23 ATE, ATH, AT PB A...
Carly f. MB 24 ATE, ATH, AT ST FA...
2012 IEEE 16th International Symposium on Consumer Electronics, Carly f. VAG 24 ATE, ATH, AT CEA...
pages 137–143. IEEE, 2012. Carly f. Partners 18 ATSH, ATMX, AT ST FF...
[54] Dave Jing Tian, Grant Hernandez, Joseph I Choi, Vanessa Frost, Christie Carly f. Renault 24 ATE, AT FC SD, AT PB...
Raules, Patrick Traynor, Hayawardh Vijayakumar, Lee Harrison, Amir Carly f. Porsche 24 ATE, AT FC SD, ATH...
Rahmati, Michael Grace, et al. Attention spanned: Comprehensive Carista 17 ATCEA, ATD, ATFSCH...
SekurTrack 5 ATED, ATE, ATA...
vulnerability analysis of {AT} commands within the android ecosystem. BlueDriver 18 ATE, ATA, ATL, ATSP...
In USENIX Security Symposium, pages 273–290, 2018. Dr.OBD 2 ATE, ATCH
[55] Yuan Tian, Nan Zhang, Yueh-Hsun Lin, XiaoFeng Wang, Blase Ur, StarLine 7 ATE, ATA, ATH, ATCH...
Xianzheng Guo, and Patrick Tague. Smartauth: User-Centered Autho- ezOBD 18 ATI, ATE, ATCRA, ATL...
rization for the Internet of Things. In USENIX Security Symposium, ANCEL 12 ATI, ATE, ATRA, ATCM...
ForScanViewer 35 ATCEA, ATCRA, ATSH...
2017.
FourStroke 10 ATZ, ATE, ATA, ATH...
[56] Jiande Wang, Yunshan Zhou, and Quan Li. Research on Fault Di- Gauged 17 ATED, ATD, ATP, ATZ...
agnostic System in CVT based on UDS. Advances in Mechanical iOBD2 20 ATE, AT ST, AT CA F...
Engineering, 7(1):128432, 2015. LeagendOBD 12 ATE, ATB, ATTR, ATQ...
Engie 8 ATE, ATSC, ATI, ATST...
[57] Yipeng Wang, Xiaochun Yun, M Zubair Shafiq, Liyan Wang, Alex X
Liu, Zhibin Zhang, Danfeng Yao, Yongzheng Zhang, and Li Guo. A TABLE X: AT commands extracted from dongle apps.
semantics aware approach to automated reverse engineering unknown
protocols. In Network Protocols (ICNP), 2012 20th IEEE International
Conference on, pages 1–10. IEEE, 2012.
[58] Zhi Wang, Xuxian Jiang, Weidong Cui, Xinyuan Wang, and Mike
Grace. ReFormat: Automatic Reverse Engineering of Encrypted Mes-
sages. In European Symposium on Research in Computer Security
(ESORICS), 2009.
[59] Haohuang Wen, Qi Alfred Chen, and Zhiqiang Lin. Plug-n-pwned:
Comprehensive vulnerability analysis of obd-ii dongles as a new over-
the-air attack surface in automotive iot. In 29th USENIX Security
Symposium (USENIX Security 20), 2020.
[60] Jeffrey Wilhelm and Tzi-cker Chiueh. A forced sampled execution
approach to kernel rootkit identification. In International Workshop
on Recent Advances in Intrusion Detection, pages 219–235. Springer,
2007.
[61] Nan Zhang, Xianghang Mi, Xuan Feng, XiaoFeng Wang, Yuan Tian,
and Feng Qian. Dangerous Skills: Understanding and Mitigating
Security Risks of Voice-Controlled Third-Party Functions on Virtual
Personal Assistant Systems. In IEEE Symposium on Security and
Privacy (IEEE S&P), 2019.
[62] Qingchuan Zhao, Chaoshun Zuo, Giancarlo Pellegrino, and Li Zhiqiang.
Geo-locating drivers: A study of sensitive data leakage in ride-hailing

16
App # Command Content Sent to Cloud Sent to vehicle
AcuraLink 9 HORN LIGHT, HORN ONLY, UNLOCK, LOCK, LOCATION ... X
Alpine 2 frontSpeakerPattern, rearSpeakerPattern X
Alpine Tunelt 3 RESUME, PHONE DIAL END, AUDIO FOCUS X
Audi MMI Connect 10 LOCK, UNLOCK, G STAT, FIND CAR, G DLIST... X
Carbin Control 15 Climate Control Temperature, Control Fan Speed... X
Car-Net 4 Unlock:2, Lock:3, Flash:0, Hornlight:1 X
Companion 2 UNLOCK, LOCK X
Mini Connected Classic 1 PlayListCommand:0x88 X
Nissan Connect Services 19 RemoteServiceDoorLock, RemoteServiceHornBlow... X
E20 Remote 12 UnlockCar, TurnOnCharging, ManageHVAC... X
Mini Connected 7 UNLOCK DOORS, FUEL STATE MAX, HONK HORN... X
Nissan Leaf 5 REMOTE DOOR UNLOCK, HORN LIGHT, LIGHT ONLY... X
Ford Play 3 VPlayState:1/2/3 X
Genesis 8 RemoteFlashLight, EditSpeed, RemoteStart... X
Infinity Connection 8 REMOTE DOOR LOCK, REMOTE STOP, LIGHT ONLY... X
Infinity InTouch Services 8 REMOTE DOOR LOCK, REMOTE STOP, LIGHT ONLY... X
Kia Hands-On 4 open. close, horn, alert X
Lexus Enform Remote 4 Unlock:1, Lock:0, Start:1, Stop:0 X
Mahindra Blue Sense 4 Audio: ED0D3EE, Climite:ED0EEE... X
Mercedes Me 4 Unlock:1, Lock:0, Start:2, Stop:3 X
Mazda Mobile Start 4 Lock, Unlock, Start, Stop, Horn X
MyBuick 6 Unlock:3, Lock:2, PanicAlarm:6, RemoteStart:4 X
MyCarKia 2 EngineStart, EngineStop X
My Ford Mobile 4 UNLOCK CMD, START CMD, CANCEL START CMD... X
MyHyundai 9 start:41, stop:42, lock:40, unlock:43... X
My Mittsubishi Connect 5 HORN REMOTE OPERATION, ENGINEOFF REMOTE... X
NissanConnectServices 8 REMOTE DOOR LOCK, REMOTE STOP, LIGHT ONLY... X
Porsche Car Connect 8 D DOORS LOCKING, D OPENINGS, DC MIRROR CLOSE... X
OnStar RemoteLink 9 lockDoor, unlockDoor, start, alert, diagnostics X
Lexus RES+ 4 start, stop, lock, unlock X
Hyundai SmartRemote 3 Volume, Channelist, Follow TV X
Ford Remote Access 3 unlock ford, start foed, lock ford X
Tesla 7 UNLOCK, HONK HORN, FLASH LIGHTS X
Uconnect 4 Unlock, Lock, Start, Stop X
UVOeco 9 Lock Doors, Stop Climate, Horn & Lights Activation... X
Volvo On Call 4 Unlock, Lock, Start, Stop X
Toyota Entune Remote Connect 4 Unlock:1, Lock:0, Start:1, Stop:0 X
Tesla Plus 17 remote start drive, sun roof control, trunk open... X
HondaLink 6 LOCK, UNLOCK, START, STOP, HORN ONLY, LIGHT ONLY X
HondaLink Aha 6 LOCK, UNLOCK, START, STOP, HORN ONLY, LIGHT ONLY X
Land Rover Comfort Controller 19 Fan:1024, LeftSeatBack: 1007 X

TABLE XI: Interpreted commands from IVI apps.

17