D IANE: Identifying Fuzzing Triggers in Apps toGenerate Under-constrained Inputs for IoT Devices
Nilo Redini∗ , Andrea Continella† , Dipanjan Das∗ , Giulio De Pasquale∗ , Noah Spahn∗ , Aravind Machiry‡ ,Antonio Bianchi‡ , Christopher Kruegel∗ , and Giovanni Vigna∗∗ UC Santa Barbara † University of Twente ‡ Purdue University{nredini, dipanjan, peperunas, ncs, chris, vigna}@cs.ucsb.edu
a.continella@utwente.nl, {amachiry, antoniob}@purdue.edu

Abstract—Internet of Things (IoT) devices have rooted themselvesin the everyday life of billions of people. Thus, researchers haveapplied automated bug finding techniques to improve their overall
security. However, due to the difficulties in extracting and emulating
custom firmware, black-box fuzzing is often the only viable analysis
option. Unfortunately, this solution mostly produces invalid inputs,
which are quickly discarded by the targeted IoT device and do not
penetrate its code. Another proposed approach is to leverage thecompanion app (i.e., the mobile app typically used to control an IoT
device) to generate well-structured fuzzing inputs. Unfortunately,
the existing solutions produce fuzzing inputs that are constrainedby app-side validation code, thus significantly limiting the range of
discovered vulnerabilities.
In this paper, we propose a novel approach that overcomes theselimitations. Our key observation is that there exist functions inside
the companion app that can be used to generate optimal (i.e., valid
yet under-constrained) fuzzing inputs. Such functions, which wecall fuzzing triggers, are executed before any data-transforming
functions (e.g., network serialization), but after the input validation
code. Consequently, they generate inputs that are not constrained byapp-side sanitization code, and, at the same time, are not discarded
by the analyzed IoT device due to their invalid format. We designand develop D IANE, a tool that combines static and dynamic analysis
to find fuzzing triggers in Android companion apps, and then uses
them to fuzz IoT devices automatically. We use D IANE to analyze 11
popular IoT devices, and identify 11 bugs, 9 of which are zero days.
Our results also show that without using fuzzing triggers, it is notpossible to generate bug-triggering inputs for many devices.

I. I NTRODUCTION
Internet of Things (IoT) devices have become part of theeveryday life of billions of people [53], [64]. Unfortunately, verymuch like their popularity, the number of vulnerabilities found inthese devices has increased as well. In both 2019 and 2018, security
researchers published more than 150 vulnerabilities affecting
IoT devices [5], [6], [7]. This represented an increment of 15%
compared to 2017, and an increase of 115% compared to 2016.
These vulnerabilities reside in the software (or firmware)
running on these IoT devices. As several studies have shown, thissoftware often contains implementation flaws, which attackers can
exploit to gain control of a device, and cause significant disruption
for end-users [17], [18], [27], [48], [59]. One prominent example
is the Mirai botnet [51], which infected hundreds of thousands of
IoT devices using a collection of vulnerabilities.
In recent years, researchers have developed novel techniques
to automatically find vulnerabilities in IoT devices by analyzing
their firmware [24], [31], [32], [70], [71], [84]. These approaches,

however, present several limitations. First, obtaining the firmware
running on an IoT device is difficult: Extracting the firmware froma device typically requires ad hoc solutions, and vendors hardly
make their software publicly available [70]. Second, unpacking
and analyzing a firmware sample is a challenging task: Firmware
samples may be available in a variety of formats, and may run onseveral different architectures, often undocumented. Furthermore,most IoT devices are shipped with disabled hardware debugging
capabilities [25], [55], [61], ruling out analyses based on dynamic
instrumentation.
For these reasons, security researchers typically have to use
black-box approaches when vetting the security of IoT devices.
However, the existing black-box approaches [2], [12], [14] require
knowledge about the data format accepted by the device underanalysis. Consequently, given the heterogeneity and lack of
documentation of the protocols adopted by IoT devices, theseapproaches are not readily applicable.
However, most IoT devices have companion apps [82], [88](i.e., mobile apps used to interact with the device), whichcontain the necessary mechanism to generate valid inputs forthe corresponding device. Based on this observation, Chen etal. [25] proposed a tool, IoTFuzzer, which fuzzes IoT devices
by leveraging their companion apps. IoTFuzzer analyzes thecompanion app and retrieves all the paths connecting the app’s
User Interface (UI) to either a network-related method or adata-encoding method. Then, IoTFuzzer fuzzes the parametersof the first function that handles user input along these paths, thus
generating valid fuzzing inputs for the IoT device.
While this approach yields better results than randomly fuzzing
the data directly sent to the IoT device over the network, inpractice, it consists in mutating variables immediately after they
are fetched from the UI, before the app performs any input
validation or data processing. Consequently, the effectivenessof IoTFuzzer suffers substantially when the app sanitizes theprovided input—our experiments (Section IV-E) demonstrate that
51% of IoT companion apps perform app-side input validation.
Indeed, recent research showed that mobile apps often perform
input validation to trigger different behaviors [86]. For thesereasons, IoTFuzzer’s approach cannot produce under-constrained(i.e., not affected by app-side sanitization) yet well-structured(i.e., accepted by the IoT device) fuzzing inputs, which can reachdeeper code locations, uncovering more vulnerabilities.

Our Approach. In this paper, we propose and implement anapproach that leverages the companion app to generate inputs forthe analyzed device. To overcome IoTFuzzer’s limitations, we
precisely determine (and fuzz) optimal code locations within thecompanion app, which produce valid yet under-constrained inputs
for the IoT device.
Our approach considers the app’s execution as a sequence offunctions that transform the data introduced by the user (e.g.,through the app’s UI) into network data. Our intuition is that thefirst functions within this sequence typically convert the user inputs
into internal data structures, generating data that is constrained byapp-side validation. In contrast, the last functions in this sequenceadequately encode the user data, serializing it on the network.
The novelty of our approach is to fuzz an IoT device by
invoking specific functions within its companion app. We call thesefunctions fuzzing triggers. When invoked, fuzzing triggers generate
inputs that are not constrained by app-side validation, and, at thesame time, are well-structured, so that they are not immediately
discarded by the fuzzed IoT device.
Our approach uses a novel combination of static and dynamic
analysis and performs two main steps: i) fuzzing triggers identification, and ii) fuzzing. To do this, first, we automatically retrieve
those functions within an app that send data to the IoT device.
Then, for each of these functions, we build an inter-procedural
backward slice, which we dynamically analyze to ultimately
identify fuzzing triggers. Finally, we use dynamic instrumentation
to repeatedly invoke these fuzzing triggers using different
arguments. This generates a stream of network data that fuzzes thefunctionality of the IoT device, to ultimately spot vulnerabilities.
We implemented our approach in a tool, called D IANE, andran it against a representative set of 11 popular IoT devices ofdifferent types and from different manufacturers. D IANE correctly
identified fuzzing triggers, and successfully identified 11 bugs, 9of which are previously unknown vulnerabilities. Additionally, we
compared D IANE with IoTFuzzer, showing that the identificationof fuzzing triggers is essential to generate under-constrained,crash-inducing inputs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// Android Java Codepublicint PTZ(String adminPwd, int x, int y, int z){//..
byte data[] = MsgPtzControlReq(x, y, z);if (!adminPwd.contains("&") && // Input!adminPwd.contains("'")){ // validation
SendMsg(adminPwd, camId, data);}}
public static native int SendMsg(String
adminPwd, String camId, byte[] data);// Java Native Interface
int
Java_SendMsg(char* pwd, char* cam_id, Msg* msg){
prepare_msg(pwd, cam_id, msg);
notify_msg(msg);}// JNI - Different thread
void sender() {Msg* msg = get_message()
send_to_device(msg);}

Fig. 1. Snippet of code that implements a sanity check on the admin

password, and uses the Java Native Interface to send messages to thedevice. The example is based on the Wansview app in our dataset.

In the spirit of open science, we make the datasets andthe code developed for this work publicly available:
https://github.com/ucsb-seclab/diane.
II. M OTIVATION

To motivate our approach and exemplify the challenges thatit addresses, consider the snippet of code in Figure 1. The app
utilizes the method PTZ (Line 2) to send position commands (i.e.,
spatial coordinates) to an IoT camera. To do this, PTZ invokes
the native function SendMsg (Line 7), which prepares the data
to be sent (Line 15), and stores it into a shared buffer (Line 16). In
parallel, another thread reads the data from the same buffer (Line20), and sends commands to the device (Line 21). Notice that theIoT camera requires a password to authenticate commands, andthe app performs a sanity check on the password string (Lines 5
and 6). This example shows two crucial challenges that have to
be faced when generating IoT inputs from the companion apps.
First, apps communicate with IoT devices using structured
In summary, we make the following contributions:
data,
encoded in either known protocols (e.g., HTTP), or custom• We propose an approach to identify fuzzing triggers, which
protocols
defined by the vendor. Messages that do not respect
are functions that, in the app’s control flow, are locatedtheexpectedformat are immediately discarded by the device, and,between the app-side validation logic and the data-encoding
consequently,
cannot trigger deep bugs in its code. In the example,
functions. When executed, the identified fuzzing triggers
the
app
uses
the
function prepare_msg (Line 15) to create a
produce valid yet under-constrained inputs, enabling effective
correctly structured message.
fuzzing of IoT devices.
Second, while it is crucial to generate correctly structured• We leverage our approach to implement D IANE, an
inputs, an effective approach has to avoid generating inputs that
automated black-box fuzzer for IoT devices.
are constrained by app-side validation code. In the example,• We evaluate our tool against 11 popular, real-world IoT
devices. In our experiments, we show that by identifying the function PTZ (Line 2) forbids the password to contain the
fuzzing triggers and using them to generate inputs for the characters & and '. However, the presence of these characters
analyzed devices, we can effectively discover vulnerabilities. may be crucial in generating crash-triggering fuzzing inputs.
The insight from the authors of IoTFuzzer is to leverage theSpecifically, we found 11 vulnerabilities in 5 different
companion app to generate fuzzing inputs in a format that thedevices, 9 of which were previously unknown.
• We show that, for a majority of IoT devices and companion
device can process. This means that the input values need to beapps, identifying and leveraging fuzzing triggers is essential mutated before the app “packages” and sends them to the device.
to generate bug-triggering inputs.
While this is true, our crucial insight is that the mutation indeed2

has to occur before the app packages the inputs, but also after the analysis does not start by considering UI-processing functions,app performs any input validation. Note that, with the expression but, on the contrary, uses a “bottom-up” approach. Specifically, we
app-side validation we refer to all types of constraints that the app start from identifying low-level functions that potentially generate
imposes on the data sent to an IoT device. These constraints might network traffic, and then we progressively move “upward” inbe imposed by typical sanitization checks (e.g., limiting the length the app call-graph (i.e., from low-level networking functions toof a string) or by parameters hard-coded in the generated request high-level UI-processing ones). This approach allows us to identify(e.g., hard-coded attributes in a JSON object).
functions that produce valid yet under-constrained inputs, skipping
Our work fills this gap: We identify strategic execution points all the sanitization checks performed by data-processing functions.
that produce inputs that are not affected by the constraints that the We then use these functions, which we call fuzzing triggers, toapp logic imposes. To achieve this goal, we analyze an IoT device efficiently fuzz the analyzed IoT device, while monitoring it forcompanion app, and focus on identifying effective fuzzing triggers: anomalous behaviors, which indicate when a bug is triggered.
We implement our approach in a tool named D IANE, depicted
Functions that, when used as entry points for fuzzing, maximize
the amount of unique code exercised on the device’s firmware, in Figure 2. D IANE works in two main phases: Fuzzing Trigger
thus potentially triggering security-relevant bugs. Consider, as Identification, and Fuzzing. In the Fuzzing Trigger Identification
an example, the app’s execution as a sequence of functions that phase, D IANE identifies optimal functions within the companion
receive data from the UI and send it over the network. On the one app, that, when invoked, generate under-constrained wellhand, if the fuzzed function is too close to the UI, the fuzzing is structured inputs for the analyzed device. Then, during the Fuzzing
ineffective due to app-side validation that might be present later phase, these functions are used to generate data that is sent to thein the execution. On the other hand, picking a function too close to analyzed device using a local network connection.
Our approach is independent of the network medium used by
the point where data is put onto the network might be ineffective.
In fact, some protocol-specific data transformations applied early the analyzed app. We apply it to apps communicating with theirin the execution would be skipped, causing the generated inputs to related IoT device both over WiFi and Bluetooth (Appendix B).
be dropped by the IoT device. In Figure 1, the function sendMsg D IANE fuzzes IoT devices that receive commands through a
local connection between the device and the companion app.
represents a fuzzing trigger.
Our approach identifies these fuzzing triggers automatically, Though some devices might receive commands from cloud-based
relying on a combination of dynamic and static analyses, without endpoints, research showed that the vast majority of them (95.56%)
the need for any a priori knowledge about neither the firmware also allow some form of local communication (e.g., during thenor the network protocol used by the analyzed IoT device. device setup phase) [17].
Additionally, previous work [25] relies on specific sources ofA. Fuzzing Trigger Identification
inputs (e.g., text boxes in the app’s UI) to bootstrap its analysis,
Intuitively, fuzzing triggers are functions that, in the app’s control
and does not mutate data generated from unspecified sources (e.g.,
flow,
are located in between the app-side validation logic and any
firmware updates through the companion app triggered by a timer).
data-transforming(e.g., message serialization) function occurring
Our bottom-up approach (explained in Section III) does not makebeforesendingdataover the network. Precisely, given an execution
any assumptions on input sources and is, therefore, more generic.
trace
from
a
sourceofinput (e.g., data received from the UI) to the
The example we discussed in this section is the simplified
function
sending
data
over
the network, a fuzzing trigger is definedversion of the code implemented in the Wansview app. We also1asafunctionthatdominates
all data-transforming functions andnote that app-side validation is prevalent in real-world apps, andpost-dominates
allinput-validating
functions. We consider the firstthat the challenges we described do not only apply to this example.
data-transforming function in the trace a valid fuzzing trigger, as it
III. A PPROACH
dominates every other data-transforming function (itself included).
Our bottom-up Fuzzing Trigger Identification algorithm is
While our goal is to find bugs in IoT devices, given the generalcomposedof four steps: i) sendMessage Candidates Identification,
unavailability of their firmware, we focus our analysis on theirii)
sendMessage
Validation, iii) Data-Transforming Function
companion apps. Our key intuition is to identify and use, within
Identification,
andiv)
Top-Chain Functions Collection. Algorithm 1these companion apps, those functions that optimally produce
lists
the
pseudo-codeof our approach.
inputs for the analyzed IoT devices. These optimal functions
Step
1:
sendMessage
Candidates Identification. We begin byeffectively produce inputs that are valid yet under-constrained.
identifying
thefunctions,in the companion app, that implement
Automatically identifying these functions is a challenging task
thenecessary
logic
to
send
messages to the IoT device. We callbecause the complexity of the companion apps, the usage of native
these
functionssendMessage
functions.
code, and the presence of multiple threads rule out approaches
Identifying
thesefunctionsin an automated and scalable way
based entirely on static analysis. Thus, we propose a novel analysis
isdifficult.
Companion
apps
might
rely on ad-hoc native functions
pipeline built on top of four different analyses: i) static call-graphdirectly
invoking
systemcalls
to implement sendMessage
analysis, ii) network traffic analysis, iii) static data-flow analysis,
functions.
Furthermore,we
foundthat these functions might be
and iv) dynamic analysis of the function arguments.
Our approach does not make any assumption on how the app’s
1 We refer to the dominance concept of the call graph theory, where a node d domiuser interface influences the data sent to the controlled IoT device, nates a node n if every path from the entry node to n must go through d. Also, we say
and it avoids app-side sanitization on the generated data. Our that a node p post-dominates n if every path from n to an exit node passes through p.

3

Dynamic Analysis
Companion
App

Static Analysis

Network Activity
Detection

IoT
DeviceUI Replay

Response
Monitoring
API Hooking
Candidate
sendMessage

CrashesHybrid Analysis

Clustering
Filtered
sendMessage

Validated
sendMessage

Data Transforming
FunctionFuzzing
Triggers

FuzzingsendMessage

Fig. 2. Using static analysis, D IANE first identifies candidate sendMessage functions. Then, it runs the companion app, replaying a recorded userinteraction, to validate the candidate sendMessage functions. Next, D IANE uses a hybrid analysis to identify data-transforming functions and, therefore,fuzzing triggers. Finally, D IANE fuzzes the validated triggers and identifies crashes by monitoring the device responses.

executed within separate threads, which makes it harder for any each candidate. The rationale is that functions that cause network
analyses (both static or dynamic) to precisely track data flows activity have a smaller mean and standard deviation, as they are lessbetween the app’s UI and sendMessage functions. However, affected by noise. Finally, among the sendMessage candidates, we
our key insight is that the companion app must contain “border” select those belonging to the cluster having the smallest mean of thefunctions, situated between the app core functionality and external elapsed times. Only the sendMessage functions within this clustercomponents (i.e., the Android framework or native libraries), will be considered in the subsequent steps of our analysis. This apwhich, when executed, eventually trigger a message to be sent to proach is represented by the function dynamicFilter in Algorithm 1.
the IoT device. Throughout the rest of the paper, we consider these Step 3: Data-Transforming Function Identification. Whileborder functions our sendMessage functions.
sendMessage functions are intuitively good triggers for performing
In our approach, we first identify candidate sendMessage fuzzing, apps may apply data-transformations in functions
functions by statically analyzing the companion app. We aim executed before a sendMessage function. A typical example of aat finding all the border methods that might implement the data-transforming function is represented by an encoding method
network interactions with the analyzed IoT device (function that takes as input a list of integers and serializes it to a sequence
getBorderMethods in Algorithm 1). Specifically, we collect all of bytes.
the methods that perform (at least) a call to native functions or a
As previously explained, fuzzing triggers are functions that, incall to methods in the Android framework that implement network the app’s control flow, are located before any data-transforming
I/O functionality (see Appendix A for more details).
function. Fuzzing a function located in between a data-transforming
Step 2: sendMessage Validation. We dynamically execute the app function and a sendMessage function would likely produce invalid
and leverage API hooking to validate the candidate sendMessage inputs that are discarded by the IoT device. Thus, to find fuzzing
functions. In order to establish whether a border function is a valid triggers, we first need to identify the data-transforming functions
sendMessage function we could, in theory, i) dynamically execute applied to the data being sent.
the function multiple times and check whether it generates network
This task presents different challenges. First, the data being
traffic each time, and ii) prevent the app from executing the function sent might be contained in a class field, which is referenced
and check whether or not network traffic is still generated. Unfortu- by the sendMessage function. This field might be theoreticallynately, we found that preventing a function to be executed, as well set anywhere in the app code, including within other threads.
as forcing the app to execute the same function multiple times, usu- Furthermore, for each field, we need to consider its parent classes,
ally causes the app itself to crash. To solve these issues, we adopt as the variable holding the message to be sent might be inheriteda different approach, based on timestamps and machine learning. by a different class.
First, we dynamically hook all the candidate functions and run
In our approach, we take into account these issues. We firstthe app. When we observe network activity, we register the last statically identify the possible variables that hold the data being
executed candidate sendMessage function. In particular, each time a sent by the considered sendMessage function, and the code
candidate sendMessage function is executed, we collect the elapsed locations where these variables might be set in the app (function
time between its execution and the observed network activity. Then, getArgAndObjLocs in Algorithm 1). To achieve this, we create
we leverage the K-mean algorithm to cluster the observed elapsed a set Sv containing tuples (v,cl), where v is a variable used by thetime measures. Specifically, we group our candidates into two sendMessage (i.e., sendMessage arguments or objects referenced
clusters (i.e., k =2). To do so, we compute each feature vector as within the sendMessage body), and cl is the code location where
the mean, standard deviation, and mode of the elapsed times of v is set.

4

Algorithm 1 Fuzzing Trigger Identification.

Then, we identify data-transforming functions. For each tuple(v,cl)∈Sv , we perform a static inter-procedural backward slicing(Line 6 in Algorithm 1) from cl up to any function retrieving values
from any UI objects. Then, we divide the computed program slices
in function scopes (getFunctionScopes at Line 7). Given a programslice, a function scope is defined as a subsequence instf of sequential instructions in the slice that belong to the same function f.
For each collected function scope, we perform a livenessanalysis [63]: We consider the variables (i.e., local variables andclass fields) referenced within the function scope, and we computethe set Lif of variables that are live at the beginning of the scope,and the set Lof of variables that are live at the end of the scope(Line 8). For example, if a function f is traversed by the slice, thevariables that are live at the beginning of the function scope instf
are f’s arguments and the class fields that are read before being
written in f. The variables that are live at the end of f’s scope are
the returned variable and the class fields that f creates or modifies.
To identify data-transforming functions, we leverage theobservation that these functions increase the entropy of the data
they consume, as explored by related work [25]. Therefore, wehook the functions we identified in a slice, we dynamically run
the app, and we calculate the Shannon entropy [49] of the dataassigned at runtime to each variable v contained in Lif and Lof(more details about how we calculate the entropy are provided inAppendix C). If v is a primitive variable (e.g., int), or a known
type (i.e., String, Integer, Float, and Double), weconvert the data it contains in its byte representation and calculate
the Shannon entropy of this list of bytes. Conversely, if v is a classfield, we retrieve its class definition and consider each field variable
vc of v whose type is either primitive or known. Then, we computethe entropy of each one of these vc variables, and add them to either
the Lif set or to the Lof set, depending on which live set v belongs.
Finally, we inspect every collected function scope and calculate
the quotient de between the maximum entropy registered among
all the variables in Lof and the minimum value of entropy
registered among all the variables in Lif (Line 11). If de is greaterthan a certain threshold Tf (set to 2.0 in our experiments, as
previous work suggested [80]), we consider the function f to bea data-transforming function (Line 12).
Step 4: Top-Chain Functions Collection. Data-transforming
functions are usually executed in precise sequences to adequately
prepare the data to be sent to an IoT device. For instance, acompanion app may encode some user data in base64, and thenencapsulate it in an HTTP request.
We call a sequence of data-transforming functions atransformation data chain, and we refer to the first function in thesequence with the term top-chain function. We say that a top-chain
function f affects a variable v if modifying the content of f’svariables eventually affects v’s value.
Of particular interest for us are the top-chain functions that affect
sendMessage variables. In fact, if we control the variables of these
top-chains, we can control the data sent to the analyzed IoT device.
In particular, this data is both valid (i.e., accepted by the IoT device)and not affected by unnecessary app-side input validation. As such,
top-chain functions that affect sendMessage variables represent the
optimal fuzzing triggers to stimulate the IoT device functionality.

1: procedure GET T OP C HAIN(sendMessage)
2:
topChain←{}3:
for (v,cl)∈getArgAndObjLocs(sendMessage) do
4:
to_hook ←{}5:
dtf ←[]
6:bsl ←getBackwardSlice(v,cl)
7:
for (f,instf )∈getFunctionScopes(bsl) do
8:(Lif ,Lof )←livenessAnalysis(instf )9:
to_hook ←to_hook∪{f,(Lif ,Lof )}10:
for {f,(ELif ,Elof )}∈getEntropies(to_hook) do11:de ←maxVarEntropy(Elof )/minVarEntropy(Elif )12:appendIfDataTransforming(dtf,de ,{f,Lif })13:trees←getDominatorTrees(dtf)
14:
candidates←dtf ∪{sendmessage}
15:
for fc ∈candidates do
16:
if not isDominated(fc ,trees) then17:
topChain←topChain∪{fc }18:
return topChain
19: procedure F UZZING T RIGGER I DENTIFICATION(CompanionApp)
20:
fuzzingT riggers←{}
21:
borderMethods←getBorderMethods(CompanionApp)
22:
for s∈dynamicFilter(borderMethods) do
23:
fuzzingT riggers←fuzzingT riggers∪getTopChain(s)24:
return fuzzingT riggers

To identify top-chain functions, we build the dominance tree2 ofeach data-transforming function detected at the previous step (Line13), and select those data-transforming functions that are not dominated by any other data-transforming function (Line 16). Finally,
we consider as fuzzing triggers the collected top-chain functions.
Note that, if no data-transforming function dominates asendMessage function, we consider the sendMessage as a fuzzing
trigger (Line 14, 15, and 16). This could happen when, for instance,
the companion app does not contain data-transforming functions.
Note finally that, in principle, app-side sanitization code might
be present in a function within a transformation data chain. We
discuss this in Section V.
Example. As a simple example, consider Figure 3, which represents one of the data chains we found on the August Smart Lockdevice. Assuming that we previously identified sendToDevice
as being a sendMessage function, we set { c} as the initial set ofvariables possibly holding data to be sent, and determine the code
locations where c is set. As c is a function argument, we retrieve
the sendMessage call site (Line 15), and bootstrap a backward
program slicing from the call site, up to the function unlock(Line 1). This is achieved by following the data-flow of the variable
e backward: sendToDevice uses the variable e, which is
the result of a call to the function encrypt. Then, we continue
the slice backward from the end of the function encrypt up to
its entry point, and back to the sendCommand function. Finally,
we reach the entry point of this function, and continue the slice
considering its caller (i.e., the function unlock).
Following the definition of function scopes above stated,
this backward slice contains the following function scopes: i)
sendCommand: Line 15; ii) encrypt: Lines from 6 to 9;iii) sendCommand: Lines 12 and 13; iv) unlock: Line 3;v) Command constructor (code not reported in this example);2 A graph where each node’s children are those nodes it immediately dominates.

5

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

provide D IANE with the option to fuzz also all the intermediate
data-transforming functions. Likewise, D IANE provides an option
to fuzz the sendMessage functions directly even when dominatedby top-chain functions. In Section IV-C, we empirically show thatfuzzing the sendMessage functions does not lead to the discoveryof new bugs, while it slows down the execution of our tool.

public boolean unlock() { // unlock request
Command cmd = new Command(OP.UNLOCK);
return sendCommand(cmd);}/* Encrypts and return its parameters */public byte[] encrypt (Command b){
byte[] enc;// ...
return enc;}

B. Fuzzing

public boolean sendCommand (Command cmd){// various checks on the command to sendbyte[] e = encrypt(cmd);
return sendToDevice(e);}/* send a message */public boolean sendToDevice(byte[] c) {/* ... */}After the first phase of our approach, we obtain a set of fuzzing
triggers, which are the inputs to our fuzzer.
Test Case Generation. For each fuzzing trigger, we generate a setof test cases by mutating the parameters of the identified fuzzing
triggers, which eventually modify the data sent by a sendMessage
Fig. 3. Example of a simple Transformation Data Chains found on the function. We fuzz the different fuzzing triggers one at the time,
August Smart Lock.
in a round-robin fashion. To mutate the values of their parameters,
we use the following strategies:
and vi) unlock: Lines 1 and 2. For brevity, in the following• String lengths: We change the length of strings in order
we only consider the relevant function scopes: ii) encrypt, iii)
to trigger buffer overflows and out-of-bound accesses. We
sendCommand, and vi) unlock. Their sets of live variables are:generate random strings with different lengths.
encrypt: Lif = {b}, Lof = {enc}; sendCommand: Lif =• Numerical values: We change the values of integer, double{cmd}, Lof ={cmd}; and unlock: Lif ={}, Lof ={cmd}.
or float values to cause integer overflows or out-of-boundOnce we identify the function scopes in the slice, we run the app
accesses. We generate very large values, negative values, andand compute the entropy of the data assigned to each of their live
the zero value.
variables. Then, we calculate the amount of entropy introduced• Empty values: We provide empty values, in the attempt toby each function scope and check whether its value exceeds acause misinterpretation, uninitialized variable vulnerabilities,
threshold Tf .
and null pointer dereferences.
The function unlock does not introduce any entropy, as the• Array lengths: We modify the content of arrays by removing
set Lif is empty. In the cases where the set Lif is empty, weor adding elements.
do not consider the function f as a candidate data-transforming
It is important to specify that we do not only fuzz primitive
function, since it does not take any input.
variables (e.g., int, float), but we also fuzz objects (asFor the function encrypt, the entropy of the data stored explained in Appendix B), by fuzzing their member variables.
in b is 5.94, whereas the entropy of the data returned in Identifying Crashes. As shown by a recent study [61], identifying
enc is 53.16. Since the entropy delta de is greater than our all crashes of network-based services of IoT devices without
threshold (de =53.16/5.94>2.0), we consider encrypt as a invasive physical access to the devices is challenging. At thedata-transforming function. Also, the function sendCommand same time, getting invasive physical access to IoT devices needs
introduces a low amount of entropy (de = 1.03), and, therefore, considerable engineering effort [9], since vendors usually prevent
it is not considered a data-transforming function. Finally, as the this type of access [10], [11].
function encrypt dominates the function sendToDevice,
For these reasons, while fuzzing a device, D IANE automaticallyencrypt is the only top-chain function, and it is used as the analyzes its responses to identify crashes. Specifically, D IANE
only fuzzing trigger.
first performs a normal run of the app and monitor how the device
UI Stimulation. Our approach executes the same app multiple responds during normal activity. Then, while fuzzing, D IANE
times, being consistent across the different runs. Thus, ideally, we monitors the network traffic between the app and the device again,
want the app to follow always the same execution paths. To achieve and considers an input to be potentially crash-inducing, if any one
this goal, we require the analyst to run the app once, while D IANE of the following conditions is satisfied.
records the generated UI inputs. Then, we automatically replay the• Connection dropped. If the device abruptly ends ansame inputs in the subsequent runs, by leveraging RERAN [40].
ongoing connection, we consider it as an indication that
We do not explicitly handle other sources non-determinism [29],something wrong happened to the device. Specifically, foras we found them to not significantly affect our approach.
TCP connections, we look for cases where the app sent a
Fuzzing Intermediate Data-Transforming Functions. In
FIN packet and received no response (FIN + ACK), andprinciple, transformation data chains might be arbitrary long. As
then sent a sequence of two or more SYN packets.
D IANE’s goal is to stimulate the core functionality of IoT devices,• HTTP Internal Server Error (500). Instances where the app
our approach ignores intermediate data-transforming functions
and the device communicate through HTTP, and the device re(i.e., data-transforming functions dominated by a top-chain
turns an Internal Server Error [1] (status code 500), are confunction) as they generate messages that would likely be discarded
sidered as a signal that the device has entered in a faulty state.
by the IoT device. However, as IoT devices might contain bugs
• Irregular network traffic size. If the amount of dataalso in the procedures used to decode a received message, we
exchanged between the app and the device overcomes a6

threshold Se , we save the current crash-inducing input. Our
intuition is that, when a device enters a faulty state (e.g., due
to a crash) it usually becomes temporarily unavailable for theapp, thus drastically reducing the amount of data exchanged.
In our experiments, we empirically verified that when theamount of exchanged data was less than 50% (compared to aregular run), something unusual happened to the device. For
this reason, we set Se to be 50%.
• Heartbeat Monitoring. While fuzzing a given device, we
continuously ping it and monitor its response time. We reportany crash-inducing inputs causing the response time to be
above a certain threshold Tp . In our experiments, we set Tp
to 10 seconds, as we empirically verified that the average
response time of an IoT device falls within 1 second undernormal conditions.

A. Dataset & Environment Setup

To evaluate D IANE, we used popular real-world IoT devices ofdifferent types and from different brands. Specifically, in October
2018 we searched for “smart home devices” on Amazon andobtained the list of the top 30 devices. Among these, we excluded 5
expensive devices (price higher than 200 USD), 1 device that does
not communicate directly with the companion app (the communication passes through a Cloud service), and other 13 devices because
they require other appliances (e.g., a smart ceiling fan controller).
Our dataset contains the remaining 11 devices, which arelisted in Table I. This dataset encompasses devices of different
types (cameras, smart sockets, bulbs, smart locks). Note that therespective companion apps of these devices are quite complex
as they contain, on average, over 9 thousand classes, 56 thousand
functions, and 766 thousand statements. The complexity of these
Finally, we use an additional Android smartphone, which we apps is in line with the complexity of the apps used by the related
refer to as the watchdog device, to monitor the status of the IoT work [79], which contains the largest dataset of validated IoT apps.
device from a neutral standpoint (i.e., we do not instrument the
We installed the IoT devices in our laboratory, we deployedcompanion app on this device). We run the companion app on the D IANE on an 8-core, 128GB RAM machine running Ubuntu
watchdog device and automatically replay the previously recorded 16.04, and we ran the Android companion apps on a Google Pixel
UI inputs to exercise the different IoT device functionality at regular and a Google Nexus 5X running Android 8.0. The smartphones,
intervals. A human analyst can then observe whether the functional- the IoT devices, and the machine running D IANE were connected
ity exercised by the watchdog device (e.g., pressing the light switch to the same subnet, allowing D IANE to capture the generated
UI button) causes the desired effect on the IoT device (e.g., turning network traffic. To configure each device, we manually performed
the light on) or not. If an undesired effect is detected, it means that its initial setup phase, such as registering an account on the device
Diane was able to bring the analyzed device into an invalid state.
and on the Android companion app.
B. Fuzzing Trigger Identification

IV. E XPERIMENTAL E VALUATION

Table II shows the results of each step of D IANE’s fuzzing triggers identification phase: For each IoT device, we report the protocols in use to communicate with the companion app, whether or not
1) Is D IANE able to find both previously-known and previouslythe app contains native code, if it sanitizes user inputs, the number
unknown vulnerabilities in IoT devices effectively?
of candidate sendMessage functions found by D IANE, the number
2) Is D IANE needed to find vulnerabilities in IoT devicesof validated sendMessage functions, and the number of fuzzing
effectively, or can existing (app-based or network-level)
triggers. For each intermediate result, we calculated the number offuzzers achieve similar results?
true positives and false positives, and investigated false negatives.
To answer the first research question, we first evaluated D IANE
Since there is no available ground truth, we validated our
precision in detecting fuzzing triggers (Section IV-B) and then we ability to identify sendMessage functions and fuzzing triggers byused it to fuzz 11 different IoT devices (Section IV-C). Our system manually reversing (both statically and dynamically) the Android
found 11 bugs in 5 devices, including 9 zero-day vulnerabilities, companion apps in our dataset. Specifically, an expert analyzed
running, in all cases, for less than 10 hours (Section IV-H).
each app for an average of five hours.
To answer the second research question, we first compared ourReverse engineering of real-world apps is known to be difficult.
tool with IoTFuzzer [25] by running it on the 11 analyzed devices Therefore, while we did our best to fully comprehend the(Section IV-D). Our experiment shows that D IANE outperformed dynamics of these apps, in a few cases we could not verify our
IoTFuzzer in 9 devices, and performs as well as IoTFuzzer for the results completely, as indicated in the following sections. We
remaining 2 devices. Then, we performed a larger-scale automated also acknowledge that this manual evaluation cannot completely
study (Section IV-E) to measure how often companion apps exclude the presence of false negatives.
perform app-side validation, which would limit the efficiency
To measured D IANE’s ability to find sendMessage functionsof approaches like IoTFuzzer. Our experiment revealed that precisely, we manually analyzed the sendMessage functions
51% of the analyzed apps contain, indeed, app-side sanitization. returned by the first two steps of our analysis. Specifically, weFinally, we compared D IANE with existing network-level fuzzers classified each function returned by the sendMessage candidates(Section IV-F), and showed that network-level fuzzers are unable identification step (Step 1 in Section III-A) and by the sendMessage
to find bugs in the analyzed devices.
function validation step (Step 2 in Section III-A) as either true
We conclude this section by presenting a detailed case study positive or false positive (TP and FP in the fifth and sixth columns
about two zero-day bugs D IANE found in one of the analyzed of Table II). To perform this classification, we hooked each of thesedevices (Section IV-G).
functions and manually exercised the IoT device’s functionality
In this section, we answer two research questions:

7

TABLE I

S UMMARY OF OUR DATASET OF I OT DEVICES (* ACCOUNT REQUIRED TO OPERATE THE DEVICE ).
Device
ID
1
2
3
4
5
6
7
8
9
10
11

Type

VendorModel

FirmwareVers.

Android App
Package Name

App
Vers.

OnlineAccount*

Setup Time
[Seconds]

CameraCameraSmart Socket
CameraCameraSmart Socket
Bulb
Smart Socket
CameraBulb
Smart Lock

Wansview
Insteon
TP-Link
FOSCAMFOSCAM
BelkiniDevices
iDevices
BelkinLIFX
August

720P X Series WiFi
HD Wifi Camera
HS110
FI9821P
FI9831P
Wemo Smart Socket
IDEV0002
IDEV0001
NetCamZ
August Smart Lock00.20.01
2.2.200
1.2.5
1.5.3.16
1.5.3.19
2.0.0
1.9.4
1.9.4
Unknown
2.76
1.12.6wansview.p2pwificam.clientcom.insteon.insteon3
com.tplink.kasa_android
com.foscam.foscam
com.foscam.foscam
com.belkin.wemoandroid
com.idevicesllc.connected
com.idevicesllc.connected
com.belkin.android.androidbelkinnetcam
com.lifx.lifx
com.august.luna

1.0.101.9.8
2.2.0.784
2.1.8
2.1.8
1.20
1.6.95
1.6.952.0.4
3.9.0
8.3.13

7
3
7
3
3
7
7
7
3
3
3

219
427
311
406
403
211
274
276
1,040
313
213

TABLE II

S UMMARY AND FEATURES OF OUR DATASET OF I OT COMPANION APPS . TP INDICATES A TRUE POSITIVE RESULT, FP A FALSE POSITIVERESULT, AND NC A RESULT WE WERE NOT ABLE TO CLASSIFY EITHER AS TRUE POSITIVE NOR FALSE POSITIVE . ? INDICATES THAT WE COULD
NOT VERIFY WHETHER AN APP APPLIED DATA SANITIZATION . T HE LAST THREE COLUMNS INDICATE THE COMPLEXITY OF THE APPS IN TERMS
OF NUMBER OF CLASSES , FUNCTIONS , AND STATEMENTS RESPECTIVELY.
Device
ID
1
2
3
4
5
6
7
8
9
10
11

Network
ProtocolNativeCode

SanityChecksNo. Candidate
sendMessage

No.
sendMessage

No. Fuzzing
Triggers

No.
Classes

No.
FunctionsNo.
Statements

UDP
HTTP
TCP + JSON
UDP
TCP
HTTP + SOAP
TCP
TCP
TCP
UDP
Bluetooth

3
3
7
3
3
3
3
3
3
3
3

3
3
?
3
3
7
3
3
?
?
3

4 (1 TP, 3 FP)
12 (8TP, 4FP)
6 (2 TP, 4 FP)
10 (2 TP, 7 FP, 1 NC)
10 (2 TP, 7 FP, 1 NC)
15 (3 TP, 12 FP)
8 (2 TP, 6 FP)
8 (2 TP, 6 FP)
6 (3 TP, 3 FP)
9 (1 TP, 8 FP)
9 (4 TP, 5 FP)

1 (1 TP)
9 (6 TP, 3 FP) ?
6 (2 TP, 4 FP)
2 (2 TP)2 (2 TP)
6 (2 TP, 4 FP)?
3 (2 TP, 1 FP)
3 (2 TP, 1 FP)
1 (1 TP)?
3 (1 TP, 2 FP)
9 (4 TP, 5 FP)

7 (6 TP, 1 FP)
6 (6 TP)3 (2 TP, 1 FP)
2 (2 TP) •2 (2 TP) •9 (8 TP, 1 FP)
4 (3 TP, 1 NC)
4(3 TP, 1 NC)
1 (1 TP)•016 (14 TP, 2 FP)

4,341
11,87016,461
6,859
6,859
4,169
8,418
8,418
6,010
5,646
22,406

31,84776,558
107,935
41,256
41,25630,46252,01352,01342,35833,267
108,507409,760
1,180,817
1,267,785
615,410615,410
378,733
813,444
813,444467,670
457,719
1,411,798

10/11

7/11

97 (30 TP, 65 FP, 2 NC)

45 (25 TP, 20 FP)

54 (47 TP, 5 FP, 2 NC)

101,457

617,472

8,431,990

Total• fuzzing triggers coincide with sendMessage functions.
TABLE IIIS UMMARY OF THE BUGS DETECTED BY D IANE , I OTF UZZER , AND BY EXISTING NETWORK FUZZERS (BED, S ULLEY, U F UZZ , AND BSS ). N O .
G ENERATED A LERTS INDICATES THE NUMBER OF UNIQUE fuzzing triggers FOR WHICH D IANE AUTOMATICALLY GENERATED AT LEAST ONE
ALERT. T IME INDICATES THE TIME REQUIRED TO FIND ALL THE REPORTED BUGS ( AND THE NUMBER OF FUZZING INPUT GENERATED TO FIND
THE BUGS ). N O . FUZZED FUNCTIONS INDICATES THE NUMBER OF FUNCTIONS IDENTIFIED BY I OTF UZZER FOR FUZZING .
D IANE
Device
ID
1
2
3
4
5
6
7
8
9
10
11

No. Generated
Alerts

No.
Bugs

1
3
1
1
1
4
3
3
0
1
0

1
7
1
0
0
1
0
0
0
0
†1

Zero-day3
3

3

IoTFuzzer

Other Fuzzers

Vuln.
Type

Time [hours](No. Generated Inputs)

No. Fuzzed
Functions

No.
Bugs

Time
[hours]BED

No. Bugs
SulleyuFuzz

bss

Unknown
Buff overflow
Unknown
N/A
N/A
Unknown
N/A
N/A
N/A
N/A
Unknown≤ 0.5 (60,750)≤ 0.5 (322)≤ 1.2 (7,344)
N/A
N/A≤ 10 (34,680)
N/A
N/A
N/A
N/A
2.2 (3,960)

•1
5
1
•1
•1
1
N/A
N/A
3
N/A
N/A

0
2
1
0
0
1
N/A
N/A
0
N/A
N/A

N/A
0.98
4
N/A
N/A
≤ 10
N/A
N/A
N/A
N/A
N/A

N/A
0
0
N/A
0
0
0
0
0
N/A
N/A

0
0
0
0
0
0
0
0
0
0
N/A

N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0

• We manually instrumented IoTFuzzer to identify a valid send function.

N/A
N/A
N/A
N/A
N/A
0
N/A
N/A
0
N/A
N/A

† Vulnerability discovered through the watchdog device.

through its companion app, while monitoring the network traffic. For Device IDs 2, 6, and 9 (indicated with ?), one might think that
We considered a candidate sendMessage function a true positive we lost some true positives during the validation step. However,
if: i) We registered network traffic when the companion app this was not the case. After manual verification (using both static
invoked the sendMessage function, and ii) the code and semantic and dynamic analyses), we discovered that the missing trueof the function indicated network functionality. If either of these positives were just wrappers of other validated true positives. We
two conditions were false, we considered the sendMessage also looked for false negatives, that is, sendMessage functions thatfunction a false positive. There were cases where the app was were not identified as such. To the best of our ability, we foundheavily obfuscated, and we could not establish if the considered no such false negatives.
sendMessage function was indeed sending data (NC in Table II).
Overall, though we registered some false positives (20 in total),
As shown in Table II, D IANE was able to remove 45 false we always identified correctly sendMessage functions (i.e., no
positive results during its sendMessage function validation step, . false negatives). We investigated the false positives and we found8

that they were due to border functions containing calls to native
methods, which were called within (or right before) the correct
sendMessage functions. As such, their execution times were close
to the actual sendMessage functions, causing our sendMessage validation step to label them as valid sendMessage functions. Also, it isimportant to say that false positive results do not affect the effectiveness of D IANE (i.e., the number of bugs found), rather its efficiency(i.e., the time spent to find those bugs). In fact, considering a nonsendMessage function as a sendMessage would only result in identifying additional, wrong fuzzing triggers that would not generate
any network traffic when fuzzed, thus not affecting the IoT device.
For each true positive sendMessage function, we verified thatD IANE correctly identified the top-chain functions (i.e., fuzzing
triggers). Fuzzing triggers for Device IDs 4, 5 and 9 (marked
with •) coincided with the sendMessage functions. This happens
in apps that either do not have data-transforming functions, orwhere the functions that transform the data also embed the sendfunctionality. Consequently, these functions are both sendMessage
and top-chain functions.
For three apps (Device IDs 3, 9 and 10), we could not trace thedata-flow from the identified sendMessage functions back up to
the UI elements. This was due to imprecisions of the employed
reverse engineering tools. Therefore, we could not establish
whether they performed app-side data sanitization.
We also investigated false positives and negatives in theidentified fuzzing triggers. Overall, our transformation data chain
identification algorithm generated 5 false positives. In 2 cases, ourbackward slicer could not find any callers of a given function, and,
therefore, our algorithm ended and considered the last detected
data-transforming function f a fuzzing trigger. After manualverification, we found that the correct fuzzing trigger, in both cases,
was a caller of function f. Although f is a valid data-transforming
function, D IANE cannot assure that it is a top-chain function, as
there might be another data-transforming function calling f that
dominates f. The remaining 3 false positives were due to the factthat these functions introduced an entropy higher than our threshold,though they were not data-transforming functions. However, we
maintained our threshold to 2 as this value is indicated as optimal
by related work [80]. As we explained before, these false positives
do not influence the effectiveness of D IANE, but only its efficiency.
Finally, we evaluated the false negatives generated by D IANE.
To the best of our ability, we did not encounter any false negative
while manually reversing the apps.

that stalls the device for an arbitrary amount of time. We reported
these bugs to the manufacturer, who confirmed our findings.
As for Device ID 1, after finding the candidate crash input, weverified it, through the app, by observing how the device behaved.
We noticed that, after sending the crafted input, the device did not
respond anymore, unless it was rebooted. Also, after fuzzing it for
24 hours the device entered a malfunctioning state, and we wereunable to correctly restore it, even after multiple factory resets. We
then purchased another camera of the same model, and the same
result was obtained after 24 hours. We are still investigating tofind whether some crash-inducing inputs we provided also cause
irreparable damage to the device.
When validating the crash reports for the Device ID 3, we
noticed that, after sending the crash-inducing input, the TCP
connection was dropped, and the device response time significantly
increased. We found that this bug, as well as the bug affecting theDevice ID 6, were known vulnerabilities [25].
For Device ID 11 (a popular smart door lock), we noticed thatafter around two hours of fuzzing the device became unreachable
for the watchdog device. Even more interestingly, the device thenstarted to make an intermittent noise, which we realized being“SOS” encoded in morse code3 . We then reset the door lock, andwe observed that it started to show erratic behavior. For example,
we noticed that it was not possible to control it through two
different Android phones anymore: If the lock status was shown
as “online” on one companion app, it would be “unreachable” onthe same companion app on another phone. We are still working
with the vendor to find the root cause of the problem.
We reported our findings to the appropriate manufacturers and,to the best of our knowledge, all bugs have been fixed.
D. D IANE vs. IoTFuzzer

To compare our approach to IoTFuzzer [25], we contacted theauthors and obtained their tool. We also attempted to purchase thesame devices used to evaluate IoTFuzzer, but we could only obtain
Device 3 and 6, as the remaining ones were only available in China.
IoTFuzzer required manual intervention to be adapted todifferent devices and companion apps. In particular, we had to i)limit the scope of the analysis (i.e., number of hooked functions)to a subset of Java packages present in the Android apps—to keep
the analysis tractable and avoid crashes—and ii) manually specify
any encryption functions present in the app. After this manual
configuration step, we were able to replicate the results presented
in the original paper for the devices we were able to obtain (Device
3 and Device 6). Additionally, IoTFuzzer is based on TaintDroid,
C. Vulnerability Finding
whose latest release supports up to Android 4.3 (2012). For thisFinally, we fuzzed the obtained fuzzing triggers, and verified reason, we were not able to analyze Device 10 and Device 11, as
the alerts produced by our tool. Table III shows the results of our their companion apps require newer Android SDK versions.
fuzzing. Note that, while D IANE can also use sendMessage funcOur results are reported in Table III. IoTFuzzer crashed Device
tions as entry points for fuzzing, it identified all the detected bugs 3 and 6 (the two devices used in the original paper) and Device
only when leveraging fuzzing triggers. We discuss the human effort 2, but failed to find any bugs for the other 8 devices.
required to verify the alerts produced by D IANE in Section IV-I.
For Device 2, IoTFuzzer identified 5 functions to fuzz. We
We validated our findings as follows. The seven bugs for Device manually analyzed these functions and found that three of them
ID 2 were confirmed by analyzing both the network traffic and were false positives, as they were used to save user information
the camera firmware. Through the analysis of the firmware, we
3 Audio recording: http://bit.ly/3oWcjgD
were able to verify our findings and craft a proof-of-work exploit

9

on the Android phone. To confirm our findings, we fuzzed thesefunctions and observed that none of them generated network traffic.
Then, we proceeded to fuzz the two remaining
HouseExtProperty
functions,
named
and
changeCameraUsernamePassword.
While
fuzzing
the HouseExtProperty function for an hour, we discoveredthat the generated messages were directed to the vendor’s
cloud, rather than the actual device, therefore not producing any
meaningful fuzzing input for the IoT device.

1
2
3
4
5
6
7
8
9

boolean changeCameraUsernamePassword(Camera
cam, String newUsr, String newPwd) {if(cam.checkCameraModel()) {if(cam.user.compareTo(newUsr) != 0)
cam.changeUsername(cam.user, newUsr);if(cam.pwd.compareTo(newPwd) != 0)
cam.changePassword(cam.user, newPwd);
}
//...
}

Fig. 4. Fuzzing function found by IoTFuzzer for the Insteon camera(Device ID 2). We report only the relevant code for space reasons.

The changeCameraUsernamePassword function is,
instead, used to change the credentials on the IoT device. We
fuzzed this function for 24 hours, and IoTFuzzer rediscovered 2of the 7 bugs that D IANE found on this device.
To understand better why IoTFuzzer missed some of the bugs wefound, we examined changeCameraUsernamePassword(shown in Figure 4). This function calls the functions
cam.changeUsername and cam.changePassword
to generate the requests to change the username and password,
respectively (the first argument of these functions represents thecurrent username of the camera). Also, the variable cam is aninternal structure that the app uses to store the details of the camera(e.g., the camera model), and its content is not directly influenced
by the data received from the app’s UI. On the other hand, both
newUsr and newPwd contain user data, which is passed throughthe app’s UI. As IoTFuzzer fuzzes only the function argumentsthat contain user data (when a function is invoked), it fuzzes thesecond and third function arguments, but it does not fuzz the first.

1
2
3
4
5
6
7

void
changeCredentials(String newUsr, String newPwd) {if(this.confirm_credentials()) {if(!this.get_user().equals(newUsr)&& !this.get_pwd().equals(newPwd))
this.changeUserAndPwd(newUser, newPwd);
//...
}
}

Fig. 5. Fuzzing function found by IoTFuzzer for the Foscam cameras

companion app (Device IDs 4 and 5).

For Device ID 9, IoTFuzzer identified 3 functions to fuzz.
However, we found these functions to be false positives, as they
were used to log user data on the smartphone.
For Devices IDs 1, 4, and 5 (marked with • in Table III)IoTFuzzer failed to identify any functions to fuzz. The reason isthat to find a function to fuzz, IoTFuzzer has to first find a data
flow between a UI element of the app and the Android’s socket
send function. However, in these devices the “send” functionality
is implemented in native code (i.e., these devices do not rely
Unfortunately, as we explain in detail in Section IV-G, thison the Android’s send function). As IoTFuzzer cannot identify
camera contains a bug that can be exploited if the request generated
send functions in native code, it failed to identify what UI eventsby the companion app contains a username whose length is larger
would eventually generate network traffic, and, therefore, it did
than a particular buffer size. However, by fuzzing the second
not generate any valid fuzzing inputs. D IANE overcomes thistwo arguments of changeCameraUsernamePassword
limitation by using dynamic analysis, and find the border functions
IoTFuzzer only mutate the second parameter ofthat generate network traffic, as explained in Section III-A.
cam.changeUsername and cam.changePassword—
To help IoTFuzzer and have a direct comparison with our
newUsr and newPwd respectively—and it does not mutate
tool,
we hard-coded the send functions found by D IANE intheir first parameter ( cam.user), which would lead to the
IoTFuzzer,
and re-ran the analysis for these devices. For Device
discovery of an additional bug. This case highlights a limitation
IDs
4
and
5,
IoTFuzzer identified one candidate function to fuzz,of IoTFuzzer’s approach, as it shows that assuming that all thewhich,
similarly
to Device ID 2, is used by the app to change thedata being sent to the device comes directly from the app’s UI
device’scredentials.
This function is depicted in Figure 5, and it
is ineffective to find bugs in an IoT device. On the other hand,
implementsacheck(through confirm_credentials) thatour bottom-up approach, which bootstraps its analysis from
asks
the
user
to
providetheir credentials in order to proceed. As
sendMessage functions (see Section III), is agnostic with respectchangeCredentialsaresult,fuzzing
did not produce any
to the sources of input, and, therefore, is more generic.
meaningful input to the camera, as the check would constantly
In addition, changeCameraUsernamePassword allows fail. Instead, D IANE identified as a fuzzing trigger the function
one to modify the credentials only for specific camera models (Line changeUserAndPwd, which is not affected by any checks, and2, cam.checkCameraModel). This means that IoTFuzzer effectively sends commands to the camera when fuzzed. Thesecannot effectively fuzz other camera models. By identifying a cases highlight another limitation of IoTFuzzer’s approach, as theyfuzzing trigger deeper in the control flow, D IANE, instead, bypasses show that fuzzing the first function in the app’s control flow that
this check and is effective independently from the device version. handles user-provided data is ineffective.
For Device IDs 7 and 8, IoTFuzzer caused the app to crash
For Device ID 1, IoTFuzzer identified a function called
immediately due to the number of hooked functions. We narrowed setUser, which sends the user’s login information to the device.
the analysis to only the package containing the code to interact In this case, this function is guarded by a check that forbids thewith the device, but the app would crash regardless. Thus, we user’s password to contain some special characters (e.g., “&”).
could not run IoTFuzzer on these devices.
We fuzzed this function for 24 hours and we did not register any

10anomaly in the device. Also in this case, D IANE selected a function
These results show how app-side sanitization code is common
deeper in the control flow of the app, after any client-side checks. in companion apps. Note that, this experiment is only an
This was necessary to successfully discover a (zero-day) bug.
approximation of our approach, which requires the physical
Overall, D IANE performed as well as IoTFuzzer only in two devices to be fully effective. Therefore, these results do not aim
cases (Device IDs 3 and 6), and it outperformed IoTFuzzer in all to evaluate our approach, rather they serve as an indication of thethe other cases—either because IoTFuzzer was unable to identify presence of input validation code in mobile apps. Our results are
any meaningful send functions, or because it did not produce any in line with a recently published study [86].
crash-inducting input.
Fuzzing Triggers. We also evaluated how prevalent fuzzingThis evaluation highlights the importance of carefully selecting triggers are in Android companion apps. As D IANE relies on
the right function to fuzz within the companion app, and that app- dynamic analysis to find fuzzing triggers, we replaced the parts
side sanitization checks hinder the efficacy of a fuzzing campaign. of our approach that leverage dynamic analysis with symbolicThis issue is exacerbated by the frequency in which app-side execution. We used the Java support provided by the angr [71]sanitization is present in companion apps. For instance (as shown in tool to symbolically execute the app’s functions in a slice (seeTable II), in our dataset we found that at least 7 out of 11 apps con- Algorithm 1), so to calculate the Shannon entropy. In particular,
tain sanity checks. We further measure this aspect in Section IV-E. we concretize the input of a function (i.e., its live variables)with known values, symbolically execute the function, and
E. App-side Sanitization and Fuzzing Triggers
observe the values in the output (i.e., its live variables when the
App-side Sanitization. To evaluate how common app-side function returns). Then, we replicate our approach explained insanitization code is in companion apps, we first manually Section III-A, and calculate the difference of entropy introduced
reverse-engineered the 11 companion apps of the IoT devices in by each function to identify the data-transforming functions.
our dataset. As shown in the Sanity Checks column of Table II,
We sampled 100 apps from the 2,081 aforementioned apps, ran
at least 7 out of 11 apps contain sanity checks.
our analysis, and manually verified the results. For 37 apps, ourAs an additional evaluation of this aspect, we performed a analysis found fuzzing triggers, and for the remaining 63, it did not.
large-scale study on the presence of app-side sanitization code in We investigated our results and found that our analysis correctlycompanion apps. For this experiment, we used 2,081 apps, which identified a fuzzing trigger for 25 of the 37 apps, and it produced
we gathered from related work [79]. This dataset is ideal for our false positives in the remaining 12 cases. These false positives were
evaluation as it specifically contains Android companion apps due to imprecisions in our inter-procedural backward slicer (i.e.,of IoT and smart home devices, which have been collected from our static analysis could not find the callers of a given function).
the Google Play Store and manually inspected by the authors of
On the other hand, in 63 apps our analysis did not find any
the related work. To the best of our knowledge, this is the largest fuzzing trigger because of imprecisions of the symbolic execution.
dataset of validated IoT companion apps. Since we did not have In fact, to keep the analysis tractable, we symbolically execute every
access to all the physical devices that these apps interact with, we function up to 10 minutes and follow up to 2 consecutive function
could not run D IANE against them, and, therefore, we implemented calls (we drop the collected symbolic constraints when a functiona fully-static automated approach, suitable for a large-scale study. call is not followed). As such, when the analysis fails to calculate
Specifically, given a companion app, we identified its the added entropy of a given function, we stop the analysis.
sendMessage functions by locating functions that contained I/OOverall, we found fuzzing triggers for 25% of the analyzed apps.
operations (as detailed in Appendix A). We were able to identify While this number sufficiently demonstrates that such sweet spots
sendMessage functions for 1,304 of the apps (~63%). For the are, indeed, present in many apps, we highlight that, in our analysis,remaining apps, we were not able to statically identify any network- this is a lower bound. In fact, our attempt to emulate our approach
related operations, as we could not find, for instance, a socket send using symbolic execution introduces imprecisions that would notoperation. Then, we performed an inter-procedural backward slice occur when using D IANE together with the real devices. Therefore,
from every argument of each identified sendMessage function, and we expect this number to be even higher in practice. This further
considered the instructions in each slice. Finally, we counted the emphasizes the need for a system that can identify fuzzing triggers
comparisons against constant data (e.g., using a string comparison that are located past client-side checks in the companion apps.
in a if statement) in these slices.
In this experiment, we found that 663 (~51%) companion apps F. D IANE vs. Network-Level Fuzzing
We also compared D IANE to well-known network fuzzers:
implement sanitization of the data being sent, and that, on average,
the variables handled by a sendMessage function are affected BED [2], Sulley [3], uFuzz [13] (UPnP endpoints), and bss [4]by 7 checks across the companion app. To validate these results, (Bluetooth fuzzer). Table III shows the results of the comparison.
we randomly selected 100 sendMessage functions and found Note that the labels N/A indicate that the corresponding network
85 to be true positives, 14 to be false positives (these functions fuzzer does not handle the network protocols employed by thewere sending messages to another Android thread), and for 1 of corresponding IoT device.
them we could not determine its functionality, as it was heavily
We configured BED and Sulley as indicated by previous
obfuscated. Also, we randomly sampled 30 functions that we work [25], and the remaining tools as suggested by their related
detected were applying input sanitization code, and found 29 to be web pages. We ran each tool for 24 hours. However, uFuzz
true positives: the companion app applied checks on the user data. finished its fuzzing cycle before the allocated time, and bss was

11

1
2
3
4
5
6

1
2
3
4
5
6

public static String httpRequest(String req, ...){// perform the requested HTTP request}/* Camera class */private Result sendCommand(String cmd, TreeMap t){

int key_strcpy(char *dst, char *URI, char *key){
int len = 0;
char* val = get_ptr_val(URI, key, &len);
strncpy(dst, val, len);return 0 ;}String fmt = "http://%s/CGIProxy.fcgi?cmd=%s:%s";
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Fig. 7. Simplified snippet of code from Insteon firmware.

toSend = String.format(fmt,CAMERA_ENDPOINT, cmd);
Iterator it = t.keySet().iterator();
while(it.hasNext()) {String key = (String)it.next();
String val = (String)t.get(key);
toSend+= "&" + key + "=" + this.encodeUrlParam(val);}
String encUser = this.encodeUrl(this.user);
String encPwd = this.encodeUrl(this.passwd);
fmt = "&usr=%s&pwd=%s"
toSend += String.format(fmt, encUser, encPwd);
HttpUtil.httpRequest(toSend,"GET",null,10,10);}
public booleanchangePassword(String user, String newPwd) {TreeMap t = new TreeMap();t.put("usrName", user);t.put("newPwd", newPwd);
res = this.sendCommand("changePwd", t).resCode;return res != ResCode.SUCCESS ? false : true;}
boolean changeCameraUsernamePassword(Camera
cam, String newUsr, String newPwd) { /*...*/ }Fig. 6. Snippet of code for the Insteon Camera app.

not able to generate input for Device ID 11, as the device does not
accept connections outside the companion app.
Overall, no bugs were found by any of these network fuzzing
tools. The reason why no network fuzzers triggered any crash isthat these fuzzers are general-purpose [83], [68], and they fail totrigger deeper code paths in the devices’ firmware. For instance,
BED only fuzzes HTTP headers without considering the syntax
or the semantics of HTTP payloads.
G. Case Study: Insteon HD Wifi Camera

TreeMap, and it eventually calls httpRequest (Line 1) to send
the request to the device.
For this particular device, we could gather the firmware runningon the camera (by sniffing the wireless network during the initial
firmware update). Figure 7 shows a simplified version of thefirmware function used to copy the values of parameters from agiven URI. This function acts as an unsafe strcpy: it takes as
input a destination buffer (allocated by the caller function) andcopies the value of a pair “key:value” present in a given URI.
This function is called 789 times within the Insteon firmware,and, to the best of our knowledge, for 9 of them, we can triggera buffer overflow. In particular, when a user wants to change thecamera password, the firmware allocates two buffers on the stack,and it uses this function to copy the username and new password
values from the URI into the allocated buffers (of 88 and 64 bytes
respectively). As a result, if we provide two values for username
and password large enough, we can trigger two buffer overflows.
By looking at the code in Figure 6 and Figure 4, we can seethat fuzzing the function encodeUrl (Lines 12,14, and 15 inFigure 6) allows us to i) skip any app-side validation (Line 2 inFigure 4), and ii) trigger both bugs discovered by IoTFuzzer (asshown in Section IV-D) and two additional bugs due to a longusername and password.
D IANE identified 9 different sendMessage functions (6 true
positives), and 6 fuzzing triggers (6 true positives) for the Insteon
Camera companion app. Among these, D IANE automatically identified the function httpRequest as a sendMessage function,and the function encodeUrl as a fuzzing trigger. When D IANE
fuzzed encodeUrl, D IANE immediately generated an alert.
Finally, note that the sendCommand represents another valid
fuzzing trigger for httpRequest, as it modifies the command
being sent. Indeed, D IANE correctly identified sendCommand
as a further fuzzing trigger.

In this section, we present a case study regarding two bugs thatD IANE found in the Insteon Camera (Device ID 2). Note that,these bugs have been fixed in the latest version of the firmware
running on the Insteon camera.
Among the functionality offered by the app, a user
can change their credentials (username and password). H. Runtime Performance
Figure 6 depicts a simplified version of the app’s code that
We assessed the runtime performance of our tool by measuringaccomplishes this task (we omit the code of the function the execution time required by the fuzzing triggers identification
changeCameraUsernamePassword as it is already phase. In our experiments, we setup D IANE to run the fuzzing
shown in Figure 4). In particular, when the user wants phase for 24 hours. First, we measured the entire execution time
to change their password, the companion app invokes the required, on average, for D IANE to analyze an app and identifyfunction changeCameraUsernamePassword (Line 29). As fuzzing triggers. D IANE analyzes a given app in slightly less than
explained in Section IV-D, this function first checks that the camera 150 minutes on average. Figure 8 shows the average and standard
belongs to a certain camera family, and if so, the app invokes deviation of the execution time required for each phase of our
the function changePassword (Line 21). This function analysis process. As shown in Figure 8, the execution time ofcreates a TreeMap structure containing couples “key:values,” D IANE has a high standard deviation. This is due to the following
which will be placed in the request generated by the app. Then, implementation detail: Frida, which we leverage to hook Android
changePassword invokes the sendCommand function APIs and methods at runtime, sometimes fails, causing the running(Line 5), which is a helper function used to send commands app to crash. This requires automatically restarting the hooking
to the camera. This function prepares the request by using the procedure, randomly slowing down D IANE.

12Exec. Time (min)V. L IMITATIONS AND F UTURE WORK

While we addressed the major challenges for performing
black-box fuzzing of IoT devices, our overall approach and theimplementation of D IANE still have some limitations.
100
We currently cannot bypass app-side sanity checks when they0
are implemented in native code, in a data-transforming function
or directly in a sendMessage function. Though we acknowledge
that such checks could be present in any of these classes of code,
Fig. 8. Average and standard deviation of the execution time of thewe manually verified that none of the apps in our dataset containphases that D IANE performs (S = Setup, SM = sendMessage functions
sanity checks in any of these categories. In fact, as shown by
Identification, FT = Fuzzing Trigger Identification).
previous work [16], native code is typically not used to implement
the main application’s logic, but it is used, instead, in library helper
functions Also, note that, differently from previous work, thisI. Quantifying Required Human Effort
does not mean that D IANE cannot handle native code at all. In
We evaluated the human effort required to use D IANE. In general, fact, even if the sendMessage function is implemented natively,
D IANE scales linearly with the number of analyzed devices, as D IANE can identify it and fuzz its fuzzing triggers. However, if
it requires the analyst to perform the same steps for each new sanity checks are present in any of the aforementioned classes ofanalyzed device. D IANE requires human intervention to setup a code, the fuzzing is less effective.
As any approach based on dynamic analysis, D IANE suffers
new IoT device. During this phase, an analyst has to install the IoT
fromlimited code coverage, i.e., it cannot identify fuzzing triggers
device, which involves installing the companion app, configuringthatarenot executed by the app. To mitigate this limitation,
the device, and, in some cases, registering an online account. In adwemanually
stimulate the apps to trigger most of the available
dition, during this phase, D IANE requires the analyst to run the appfunctionality,and
we perform our analysis on real smartphones.
and test the basic functionality of the IoT device, so that our tool canThecurrent
implementationof D IANE cannot fuzz nested Java
record the generated UI interactions (see Section III). We measured
objects.
We
plantoaddress
thisin future work.
the time we spent to setup each device, as reported in Table I. On
D IANE could be enhanced to automatically discover semantic
average, we spent 6 minutes and 12 seconds to setup a new IoT
device, of which 41 seconds were spent to interact with the device. vulnerabilities (e.g., a smart lock unlocks a door instead of locking
Note that, an analyst has to take these steps only once per device. it). Currently, this feature is semi-automatic as it requires theanalyst to check and interact with the watchdog device.
Human effort is also required if the analyst desires to monitor thestate of the watchdog device during fuzzing (recall Section III-B).
VI. R ELATED WORKThe watchdog device is optional and useful if the analyst wants
IoT devices are plagued with vulnerabilities [59], [48], [27],to detect semantic issues. In this case, the analyst has to check [18]. Consequently, different automated vulnerability detection
whether the functionality automatically exercised by the watchdog tools [31], [32], [70], [71] have been proposed, relying on static
device results in an undesired effect in the IoT device due to our analysis techniques. Unfortunately, the applicability of these tools
fuzzer triggering a vulnerability (e.g., unauthenticated requests is limited since they require the device firmware.
suddenly open a door lock). The frequency of these manual
Dynamic analysis, and in particular fuzzing [60], is a popularchecks depends on the analyst, as they might want to monitor the alternative technique that mitigates the problems of static analysis
watchdog device at regular intervals for the whole duration of the at the cost of missing potential bugs. American Fuzzy Lop
fuzzing campaign, or only at the end of it. In our fuzzing campaign (AFL) [85], along with its several improved versions [19], [20],we checked the watchdog device approximately every two hours. [56], [35], [67], is the most popular coverage-guided fuzzing tool.
In our experiments, we needed the watchdog device only to detect
However, coverage-guided fuzzing is hard to perform on real
the issue for Device ID 11, as explained in Section IV-C. The other devices, as it requires to keep track of the code locations reached
10 bugs were automatically detected by D IANE by monitoring the while fuzzing the analyzed firmware. It is possible to perform
network traffic, as explained in Section III-B.
this tracking using hardware debugging capabilities [72], but,
When a bug is detected, D IANE generates an alert. In this case, unfortunately, they are usually disabled in consumer devices [55],an analyst may want to manually reproduce and verify the bug [61], [25]. Other approaches have proposed to fuzz IoT devices
triggering the alert. D IANE allows this manual verification, since by emulating the corresponding firmware [87], [73], [43], [24],it produces as output the input triggering the detected bug. With [42]. Unfortunately, a faithful emulation of a firmware image isthis information in hand, the analyst can use D IANE to send the a hard problem, and these approaches have scalability issues.
crashing input to the analyzed IoT device. Then, the analyst can
Input generation is one fundamental capability underpinning
manually check the device functionality to assess if it misbehaves any fuzzing technique. Taint tracking [44], [36], [26], symbolic
after receiving the crashing input (e.g., the device reboots or does execution [22], [38], [39], [23], [74], [62] and static analysis [57],not reply to further requests). In our evaluation, we needed about [69] have been commonly used to handle the problem of input
6 minutes, on average, to follow this procedure and verify each generation. Unfortunately, all of these techniques require toalert produced by D IANE.
instrument the analyzed firmware code.
FT

SM

S

Al
l

200

13

Grammar-based fuzzing techniques [66], [77] side-step the prob- Dalvik [34] or the ART [75] runtime. However, it is not trivial tolem of input generation by requiring a model of the inputs [41], [46], extend these techniques to apps containing native code.
[37], [54], [33] accepted by the program under test. Consequently,
Ispoglou et al.[47] proposed FuzzGen, a tool to automaticallytechniques based on static analysis [30] and dynamic analysis [58], generate fuzzing harnesses for libraries. Unfortunately, this[28], [45] have been developed to create models of valid inputs ac- approach is not directly applicable to our usage scenario. In
cepted by the analyzed software. However, these approaches are not particular, FuzzGen requires the code of the library it generates thesuitable to fuzz IoT devices, as user requests are usually encrypted harness for. Therefore, it cannot be applied to IoT devices, sinceby the companion app, and devices might rely on ad-hoc grammars. their code is typically unavailable. FuzzGen’s approach could be
D IANE solves the problem of input generation by using network used to generate fuzzing harnesses for the libraries used by the
traffic and hybrid analysis of the app controlling the target IoT companion apps. However, this approach would not be effective
device. Recently, Chen et al. proposed IoTFuzzer [25]. IoTFuzzer in generating inputs targeting the analyzed IoT device. In fact,
analyzes the IoT device’s APK, and automatically finds paths in companion apps, the logic to prepare and send well-structured
where user-generated input is handled. Then, for each of them, messages to the controlled IoT device is usually implemented in
it fuzzes the arguments of the first function handling such data. the core of the companion app itself, rather than in its libraries.
While IoTFuzzer shares some similarities with our approach,For known protocols, network-based approaches like BED [2],it suffers from a number of drawbacks, which we discussed in Katyusha [12], WSFuzzer [14] could be used to perform fuzzing.
detail in Section II. Wang et al. [79] leverage an IoT device’s However, extending them to custom data formats used by IoT
companion app to detect the characteristics of the device (e.g., devices is non-trivial given the heterogeneity of these devices.
a smart plug), and infer its vulnerabilities by relying on a set of Furthermore, these tools cannot handle challenge-response
known vulnerabilities affecting similar devices. However, their sequences [21], heavily limiting their fuzzing effectiveness.
approach does not find unknown vulnerabilities.
Finally, Junior et al. [50] assessed the security of the
RPFuzzer [81] finds vulnerabilities in router protocols. However, communication channels between IoT devices and their companion
its techniques are customized to find routing-related issues, and apps, identifying several flaws (e.g., lack of authentication).
are not applicable to generic IoT devices.
VII. C ONCLUSIONS
Peng et al. [67] recently proposed T-Fuzz, an approach for input
In this paper, we studied the effectiveness of IoT device fuzzers.
generation that first transforms the target program to skip checks on
input values, and then fuzzes the transformed program. T-Fuzz goal On the one hand, randomly fuzzing network packets sent to theis to increase code coverage by bypassing input validation – T-Fuzz devices requires knowledge about the data format accepted by a deflips the if-conditions guarding those branches where the fuzzer vice, which is seldom available when devices use custom firmware.
gets stuck. However, T-Fuzz is not suitable for our scenario, since it On the other hand, approaches that leverage the UI of the companrequires access to the hardly available firmware of the IoT device. ion mobile app to produce syntactically correct messages are inefT-Fuzz could be used to fuzz the companion app. However, our fective because of the constraints that the app-side code imposes.
Conversely, we proposed a novel approach that sits in the sweet
goal is not to increase our coverage of the companion app, but toidentify fuzzing triggers and use them to fuzz the code running spot between network-level fuzzing and UI-level fuzzing. Ourin the analyzed IoT device. In fact, T-Fuzz flips if-conditions approach aims at identifying fuzzing triggers, which are portions
without considering whether they are part of sanitization functions of code in the IoT companion apps that are executed after input
or data-transforming functions. As such, T-Fuzz would inevitably validation and right before any data-transforming function, and thatmodify parts of the companion app’s code that are essential in maximize the fuzzing outcome. We implemented our approach inproducing valid inputs for the IoT device. Therefore, applying a tool, called D IANE, and evaluated it on 11 real-world IoT devices
the T-Fuzz approach on a companion app will not increase the of different brands. D IANE outperforms the current state-of-the-art
effectiveness of the fuzzing of the controlled IoT device. For approach, and it can successfully detect critical bugs (9 zero-days)
this reason, we need an approach like D IANE, which is able to that cannot be triggered by existing fuzzers.
selectively determine the checks to be bypassed.
ACKNOWLEDGEMENTS
Similarly, Wang et al. [78] proposed TaintScope, a directed
checksum-aware fuzzing approach that bypasses sanity checks to
We would like to thank our reviewers for their valuablepenetrate deeper in the analyzed program. As such, TaintScope comments and inputs to improve our paper. This material is based
prevents generated test cases from being prematurely dropped upon work supported by AFRL under Award No. FA8750-19by integrity checks on the targeted program. However, this tool C-0003, and by ONR under Awards No. N00014-17-1-2011 andis applicable only when the firmware of the device is available. N00014-17-1-2897. Research was also sponsored by DARPA
When the firmware is available, other dynamic analysis tools under agreement number HR001118C0060. The U.S. Government
like AVATAR [84], SURROGATES [52], FIRM-AFL [87], and is authorized to reproduce and distribute reprints for Governmental
FirmaDyne [24] could be used to improve the effectiveness of purposes notwithstanding any copyright notation thereon. The
vulnerability identification. On the other hand, we performed our views and conclusions contained herein are those of the authors
evaluation on real devices, without the need for firmware.
and should not be interpreted as necessarily representing theData-flow tracking tools could be helpful to identify our fuzzing official policies or endorsements, either expressed or implied, oftriggers. Dynamic analysis tools track interactions within the DARPA, the U.S. Government, or the other sponsors.

14

R EFERENCES[1] “500
internal
servererror,”
https://developer.mozilla.org/enUS/docs/Web/HTTP/Status/500.
[2] “bed - A network protocol fuzzer,” https://tools.kali.org/vulnerabilityanalysis/bed.
[3] “boofuzz: Network Protocol Fuzzing for Humans, successor to the venerable
Sulley fuzzing framework,” https://github.com/jtpereyda/boofuzz.
[4] “BSS (Bluetooth Stack Smasher) Fuzzer,” https://securiteam.com/tools/
5NP0220HPE/.
[5] “CVE Database for Iot Vulns1,” https://cve.mitre.org/cgi-bin/cvekey.cgi?
keyword=router.
[6] “CVE Database for Iot Vulns2,” https://cve.mitre.org/cgi-bin/cvekey.cgi?
keyword=belkin.
[7] “CVE Database for Iot Vulns3,” https://cve.mitre.org/cgi-bin/cvekey.cgi?
keyword=smart-home.
[8] “Frida: Dynamic instrumentation toolkit for developers, reverse-engineers,and security researchers.” https://frida.re/docs/android/.
[9] “Jtag debugging,” https://blog.attify.com/hack-iot-device/.
[10] “Jtag fuse and protection using a trusted execution environment,”
http://www.freepatentsonline.com/9021585.html.
[11] “Jtag fuse flow,” https://e2e.ti.com/support/microcontrollers/msp430/f/166/
t/18936?JTAG-FUSE-BLOW.
[12] “Katyusha rest and soap fuzzer,” https://github.com/lpredova/Katyusha.
[13] “UFuzz, or Universal Plug and Fuzz, is an automatic UPnP fuzzing tool.”
https://github.com/phikshun/ufuzz.
[14] “Web services fuzzing tool for http and soap,” https://sourceforge.net/projects/
wsfuzzer/files/.
[15] “Debugging Bluetooth With An Android App,” https://blog.bluetooth.com/
debugging-bluetooth-with-an-android-app, 2016.
[16] V. Afonso, A. Bianchi, Y. Fratantonio, A. Doupé, M. Polino, P. de Geus,
C. Kruegel, and G. Vigna, “Going native: Using a large-scale analysis ofandroid apps to create a practical native-code sandboxing policy,” in The
Network and Distributed System Security Symposium, 2016, pp. 1–15.
[17] O. Alrawi, C. Lever, M. Antonakakis, and F. Monrose, “Sok: Security
evaluation of home-based iot deployments,” in Proceedings of the IEEE
Symposium on Security and Privacy, 2019.
[18] Ben Herzberg, Dima Bekerman, Igal Zeifman, “Breaking Down Mirai: An
IoT DDoS Botnet Analysis,” https://www.incapsula.com/blog/malwareanalysis-mirai-ddos-botnet.html.
[19] M. Böhme, V.-T. Pham, M.-D. Nguyen, and A. Roychoudhury, “Directed
greybox fuzzing,” in Proceedings of the 2017 ACM SIGSAC Conference on
Computer and Communications Security. ACM, 2017, pp. 2329–2344.
[20] M. Böhme, V.-T. Pham, and A. Roychoudhury, “Coverage-based greybox
fuzzing as markov chain,” in Proceedings of the 2016 ACM Conference
on Computer and Communications Security, ser. CCS ’16. New
York, NY, USA: ACM, 2016, pp. 1032–1043. [Online]. Available:
http://doi.acm.org/10.1145/2976749.2978428[21] R. M. Bolle, J. H. Connell, and N. K. Ratha, “System and method for livenessauthentication using an augmented challenge/response scheme,” Feb. 1 2005,
uS Patent 6,851,051.
[22] C. Cadar, V. Ganesh, P. M. Pawlowski, D. L. Dill, and D. R. Engler, “Exe:Automatically generating inputs of death,” in Proceedings of the 2006
ACM Conference on Computer and Communications Security, ser. CCS’06. New York, NY, USA: ACM, 2006, pp. 322–335. [Online]. Available:
http://doi.acm.org/10.1145/1180405.1180445[23] G. Campana, “Fuzzgrind: un outil de fuzzing automatique,” Actes du, pp.
213–229, 2009.
[24] D. D. Chen, M. Woo, D. Brumley, and M. Egele, “Towards automateddynamic analysis for linux-based embedded firmware.” in NDSS, 2016.
[25] J. Chen, W. Diao, Q. Zhao, C. Zuo, Z. Lin, X. Wang, W. C. Lau, M. Sun,
R. Yang, and K. Zhang, “Iotfuzzer: Discovering memory corruptions in iot
through app-based fuzzing,” in Proc. of the ISOC Network and Distributed
System Security Symposium (NDSS), 2018.
[26] P. Chen and H. Chen, “Angora: Efficient fuzzing by principled search,” arXiv
preprint arXiv:1803.01307, 2018.
[27] Chris Brook, “TRAVEL ROUTERS, NAS DEVICES AMONG EASILY
HACKED IOT DEVICES,” https://threatpost.com/travel-routers-nas-devicesamong-easily-hacked-iot-devices/124877/.
[28] P. M. Comparetti, G. Wondracek, C. Kruegel, and E. Kirda, “Prospex:
Protocol specification extraction,” in Proceedings of the 2009 IEEE
Symposium on Security and Privacy, ser. SP ’09. Washington, DC,
USA: IEEE Computer Society, 2009, pp. 110–125. [Online]. Available:
http://dx.doi.org/10.1109/SP.2009.14

15[29] A. Continella, Y. Fratantonio, M. Lindorfer, A. Puccetti, A. Zand, C. Kruegel,and G. Vigna, “Obfuscation-resilient privacy leak detection for mobile apps
through differential analysis,” in Proceedings of the ISOC Network and Distributed System Security Symposium (NDSS), San Diego, CA, February 2017.
[30] J. Corina, A. Machiry, C. Salls, Y. Shoshitaishvili, S. Hao, C. Kruegel, and
G. Vigna, “Difuze: Interface aware fuzzing for kernel drivers,” in Proceedingsof the 2017 ACM SIGSAC Conference on Computer and Communications
Security. ACM, 2017, pp. 2123–2138.
[31] A. Costin, J. Zaddach, A. Francillon, D. Balzarotti, and S. Antipolis, “Alarge-scale analysis of the security of embedded firmwares.” in USENIX
Security Symposium, 2014, pp. 95–110.
[32] D. Davidson, B. Moench, T. Ristenpart, and S. Jha, “Fie on firmware: Finding
vulnerabilities in embedded systems using symbolic execution,” in USENIX
Security Symposium, 2013, pp. 463–478.
[33] K. Dewey, J. Roesch, and B. Hardekopf, “Fuzzing the rust typechecker usingclp (t),” in Proceedings of the 2015 IEEE/ACM International Conference
on Automated Software Engineering, ser. ASE ’15. Washington, DC,
USA: IEEE Computer Society, 2015, pp. 482–493. [Online]. Available:
http://dx.doi.org/10.1109/ASE.2015.65[34] W. Enck, P. Gilbert, S. Han, V. Tendulkar, B.-G. Chun, L. P. Cox, J. Jung,
P. McDaniel, and A. N. Sheth, “Taintdroid: an information-flow tracking
system for realtime privacy monitoring on smartphones,” ACM Transactions
on Computer Systems (TOCS), vol. 32, no. 2, p. 5, 2014.
[35] S. Gan, C. Zhang, X. Qin, X. Tu, K. Li, Z. Pei, and Z. Chen, “Collafl: Pathsensitive fuzzing,” in 2018 IEEE Symposium on Security and Privacy (SP).
IEEE, 2018, pp. 679–696.
[36] V. Ganesh, T. Leek, and M. Rinard, “Taint-based directed whitebox fuzzing,”
in Proceedings of the 2009 International Conference on Software Engineering,ser. ICSE ’09. Washington, DC, USA: IEEE Computer Society, 2009, pp.
474–484. [Online]. Available: http://dx.doi.org/10.1109/ICSE.2009.5070546[37] P. Godefroid, A. Kiezun, and M. Y. Levin, “Grammar-based whitebox
fuzzing,” in Proceedings of the 2008 ACM SIGPLAN Conference on
Programming Language Design and Implementation, ser. PLDI ’08.
New York, NY, USA: ACM, 2008, pp. 206–215. [Online]. Available:
http://doi.acm.org/10.1145/1375581.1375607[38] P. Godefroid, N. Klarlund, and K. Sen, “Dart: Directed automatedrandom testing,” in Proceedings of the 2005 ACM SIGPLAN Conference
on Programming Language Design and Implementation, ser. PLDI ’05.
New York, NY, USA: ACM, 2005, pp. 213–223. [Online]. Available:
http://doi.acm.org/10.1145/1065010.1065036[39] P. Godefroid, M. Y. Levin, D. A. Molnar et al., “Automated whitebox fuzz
testing.” in Proceedings of the 2008 Symposium on Network and Distributed
System Security, ser. NDSS ’08, San Diego, CA, USA, 2008.
[40] L. Gomez, I. Neamtiu, T. Azim, and T. Millstein, “Reran: Timing-and touchsensitive record and replay for android,” in Proceedings of the 2013 International Conference on Software Engineering. IEEE Press, 2013, pp. 72–81.
[41] G. Grieco, M. Ceresa, and P. Buiras, “Quickfuzz: An automatic randomfuzzer for common file formats,” in Proceedings of the 2016 International
Symposium on Haskell, ser. Haskell ’16. New York, NY, USA: ACM, 2016,
pp. 13–20. [Online]. Available: http://doi.acm.org/10.1145/2976002.2976017[42] Z. Gui, H. Shu, and J. Yang, “Firmnano: Toward iot firmware fuzzing throughaugmented virtual execution,” in 2020 IEEE 11th International Conference
on Software Engineering and Service Science (ICSESS), 2020, pp. 290–294.
[43] E. Gustafson, M. Muench, C. Spensky, N. Redini, A. Machiry,
Y. Fratantonio, D. Balzarotti, A. Francillon, Y. R. Choe, C. Kruegel,and G. Vigna, “Toward the analysis of embedded firmware throughautomated re-hosting,” in 22nd International Symposium on Researchin Attacks, Intrusions and Defenses (RAID 2019). Chaoyang District,
Beijing: USENIX Association, Sep. 2019, pp. 135–150. [Online]. Available:
https://www.usenix.org/conference/raid2019/presentation/gustafson[44] I. Haller, A. Slowinska, M. Neugschwandtner, and H. Bos, “Dowser: a guided
fuzzer to find buffer overflow vulnerabilities,” in Proceedings of the 2013
USENIX Security Symposium, ser. SEC ’13, Washington, DC, USA, 2013,
pp. 49–64.
[45] H. Han and S. K. Cha, “Imf: Inferred model-based fuzzer,” in Proceedingsof the 2017 ACM SIGSAC Conference on Computer and Communications
Security. ACM, 2017, pp. 2345–2358.
[46] C. Holler, K. Herzig, and A. Zeller, “Fuzzing with code fragments.” inProceedings of the 2012 USENIX Security Symposium, ser. SEC ’12,
Bellevue, WA, USA, 2012, pp. 445–458.
[47] K. Ispoglou, D. Austin, V. Mohan, and M. Payer, “Fuzzgen: Automaticfuzzer generation,” in 29th USENIX Security Symposium (USENIX Security
20). Boston, MA: USENIX Association, Aug. 2020. [Online]. Available:
https://www.usenix.org/conference/usenixsecurity20/presentation/ispoglou

[48] James Lyne, “Uncovering IoT Vulnerabilities in a CCTV
Camera,”https://www.rsaconference.com/videos/demo-uncoveringiot-vulnerabilities-in-a-cctv-camera.
[49] L. Jost, “Entropy and diversity,” Oikos, vol. 113, no. 2, pp. 363–375, 2006.
[50] D. M. Junior, L. Melo, H. Lu, M. d’Amorim, and A. Prakash, “Beware of theapp! on the vulnerability surface of smart devices through their companion
apps,” arXiv preprint arXiv:1901.10062, 2019.
[51] C. Kolias, G. Kambourakis, A. Stavrou, and J. Voas, “Ddos in the iot: Mirai
and other botnets,” Computer, vol. 50, no. 7, pp. 80–84, 2017.
[52] K. Koscher, T. Kohno, and D. Molnar, “Surrogates: Enabling near-real-time
dynamic analyses of embedded systems.” in WOOT, 2015.
[53] D. Kumar, K. Shen, B. Case, D. Garg, G. Alperovich, D. Kuznetsov, R. Gupta,
and Z. Durumeric, “All things considered: An analysis of iot devices on home
networks,” in 28th {USENIX} Security Symposium ({USENIX} Security 19),2019, pp. 1169–1185.
[54] V. Le, C. Sun, and Z. Su, “Finding deep compiler bugs via guided stochastic
program mutation,” in Proceedings of the 2015 ACM SIGPLAN International
Conference on Object-Oriented Programming, Systems, Languages, andApplications, ser. OOPSLA ’15. New York, NY, USA: ACM, 2015, pp.
386–399. [Online]. Available: http://doi.acm.org/10.1145/2814270.2814319[55] K. Lee, Y. Lee, H. Lee, and K. Yim, “A brief review on jtag security,” in 2016
10th International Conference on Innovative Mobile and Internet Services
in Ubiquitous Computing (IMIS), July 2016, pp. 486–490.
[56] C. Lemieux and K. Sen, “Fairfuzz: Targeting rare branches to rapidly
increase greybox fuzz testing coverage,” CoRR, vol. abs/1709.07101, 2017.
[Online]. Available: http://arxiv.org/abs/1709.07101[57] Y. Li, B. Chen, M. Chandramohan, S.-W. Lin, Y. Liu, and A. Tiu, “Steelix:
Program-state based binary fuzzing,” in Proceedings of the 2017 11th Joint
Meeting on Foundations of Software Engineering, ser. ESEC/FSE 2017.
New York, NY, USA: ACM, 2017, pp. 627–637. [Online]. Available:
http://doi.acm.org/10.1145/3106237.3106295[58] Z. Lin, X. Zhang, and D. Xu, “Automatic reverse engineering of data
structures from binary execution,” in Proceedings of the 2010 Annual
Information Security Symposium, ser. CERIAS ’10. West Lafayette,
IN: CERIAS - Purdue University, 2010, pp. 5:1–5:1. [Online]. Available:
http://dl.acm.org/citation.cfm?id=2788959.2788964[59] Lucian Constantin, “Hackers found 47 new vulnerabilities in 23 IoT devices
at DEFCON,” https://www.csoonline.com/article/3119765/security/hackersfound-47-new-vulnerabilities-in-23-iot-devices-at-def-con.html.
[60] B. P. Miller, L. Fredriksen, and B. So, “An empirical study of the reliabilityof unix utilities,” Commun. ACM, vol. 33, no. 12, pp. 32–44, Dec. 1990.
[Online]. Available: http://doi.acm.org/10.1145/96267.96279[61] M. Muench, J. Stijohann, F. Kargl, A. Francillon, and D. Balzarotti, “Whatyou corrupt is not what you crash: Challenges in fuzzing embedded devices,”in NDSS 2018, Network and Distributed Systems Security Symposium, 18-21
February 2018, San Diego, CA, USA, San Diego, UNITED STATES, 02
2018. [Online]. Available: http://www.eurecom.fr/publication/5417[62] M. Neugschwandtner, P. Milani Comparetti, I. Haller, and H. Bos, “Theborg: Nanoprobing binaries for buffer overreads,” in Proceedings of the2015 ACM Conference on Data and Application Security and Privacy, ser.
CODASPY ’15. New York, NY, USA: ACM, 2015, pp. 87–97. [Online].
Available: http://doi.acm.org/10.1145/2699026.2699098[63] F. Nielson, H. Riis Nielson, and C. Hankin, Principles of Program Analysis,
01 1999.
[64] A. Nordrum, “The internet of fewer things [news],” IEEE Spectrum, vol. 53,
no. 10, pp. 12–13, 2016.
[65] J. Palsberg and M. I. Schwartzbach, Object-oriented type inference. ACM,
1991, vol. 26, no. 11.
[66] Peach, “The peach fuzzer,” 2017, http://www.peachfuzzer.com/.
[67] H. Peng, Y. Shoshitaishvili, and M. Payer, “T-fuzz: fuzzing by programtransformation,” in Proceedings of the IEEE Symposium on Security andPrivacy (S&P), 2018.
[68] P. Pokorny and M. Royal, “Dumb fuzzing in practice,” 2012.
[69] S. Rawat, V. Jain, A. Kumar, L. Cojocar, C. Giuffrida, and H. Bos, “Vuzzer:
Application-aware evolutionary fuzzing,” in Proceedings of the Network andDistributed System Security Symposium (NDSS), 2017.
[70] N. Redini, A. Machiry, R. Wang, C. Spensky, A. Continella, Y. Shoshitaishvili,
C. Kruegel, and G. Vigna, “Karonte: Detecting insecure multi-binaryinteractions in embedded firmware,” in Proceedings of the IEEE Symposium
on Security and Privacy (S&P), May 2020.
[71] Y. Shoshitaishvili, R. Wang, C. Hauser, C. Kruegel, and G. Vigna, “Firmaliceautomatic detection of authentication bypass vulnerabilities in binary
firmware.” in NDSS, 2015.

16[72] M. Smith, M. Helmi, and J. Miller, “Comparison of approaches to use existingarchitectural features in embedded processors to achieve hardware-assisted
test insertion,” Proceedings Work-in-Progress Session, 2010.
[73] P. Srivastava, H. Peng, J. Li, H. Okhravi, H. Shrobe, and M. Payer, “FirmFuzz:
Automated IoT Firmware Introspection and Analysis,” in Proc. ACM CCS
Workshop on IoT Security and Privacy (IoT S&P), 2019.
[74] N. Stephens, J. Grosen, C. Salls, A. Dutcher, R. Wang, J. Corbetta,
Y. Shoshitaishvili, C. Kruegel, and G. Vigna, “Driller: Augmenting Fuzzing
Through Selective Symbolic Execution,” in Proceedings of the 2016 Network
and Distributed System Security Symposium, ser. NDSS ’16, San Diego, CA,
USA, 2016.
[75] M. Sun, T. Wei, and J. Lui, “Taintart: A practical multi-level information-flow
tracking system for android runtime,” in Proceedings of the 2016 ACM
SIGSAC Conference on Computer and Communications Security. ACM,
2016, pp. 331–342.
[76] R. Vallée-Rai, E. Gagnon, L. Hendren, P. Lam, P. Pominville, and V. Sundaresan, “Optimizing java bytecode using the soot framework: Is it feasible?” in International conference on compiler construction. Springer, 2000, pp. 18–34.
[77] J. Wang, B. Chen, L. Wei, and Y. Liu, “Skyfire: Data-driven seed generation
for fuzzing,” in 2017 IEEE Symposium on Security and Privacy (SP), May
2017, pp. 579–594.
[78] T. Wang, T. Wei, G. Gu, and W. Zou, “Taintscope: A checksum-aware
directed fuzzing tool for automatic software vulnerability detection,” inProceedings of the 2010 IEEE Symposium on Security and Privacy, ser. SP’10. San Jose, CA, USA: IEEE, 2010, pp. 497–512.
[79] X. Wang, Y. Sun, S. Nanda, and X. Wang, “Looking from the mirror:
Evaluating iot device security through mobile companion apps,” in 28th
USENIX Security Symposium (USENIX Security 19). Santa Clara, CA:
USENIX Association, Aug. 2019, pp. 1151–1167. [Online]. Available: https://www.usenix.org/conference/usenixsecurity19/presentation/wang-xueqiang[80] Z. Wang, X. Jiang, W. Cui, X. Wang, and M. Grace, “Reformat: Automatic
reverse engineering of encrypted messages,” in Computer Security –ESORICS 2009, M. Backes and P. Ning, Eds. Berlin, Heidelberg: Springer
Berlin Heidelberg, 2009, pp. 200–215.
[81] Z. Wang, Y. Zhang, and Q. Liu, “Rpfuzzer: A framework for discovering
router protocols vulnerabilities based on fuzzing.” KSII Transactions on
Internet & Information Systems, vol. 7, no. 8, 2013.
[82] H. Wen, Q. Zhao, Q. A. Chen, and Z. Lin, “Automated Cross-Platform Reverse
Engineering of CAN Bus Commands From Mobile Apps,” in Proceedings ofthe ISOC Network and Distributed System Security Symposium (NDSS), 2020.
[83] T. Wilson, “Evaluation of fuzzing as a test method for an embedded system,”
2018.
[84] J. Zaddach, L. Bruno, A. Francillon, and D. Balzarotti, “Avatar: A framework
to support dynamic security analysis of embedded systems’ firmwares.” in
NDSS, 2014.
[85] M. Zalewski., “American fuzzy lop,” 2017, http://lcamtuf.coredump.cx/afl/
technical_details.txt.
[86] Q. Zhao, C. Zuo, D.-G. Brendan, G. Pellegrino, and Z. Lin, “Automatic
uncovering of hidden behaviors from input validation in mobile apps,” 2020.
[87] Y. Zheng, A. Davanian, H. Yin, C. Song, H. Zhu, and L. Sun, “Firm-afl: Highthroughput greybox fuzzing of iot firmware via augmented process emulation,”in 28th USENIX Security Symposium (USENIX Security 19). Santa Clara,
CA: USENIX Association, Aug. 2019, pp. 1099–1114. [Online]. Available:
https://www.usenix.org/conference/usenixsecurity19/presentation/zheng[88] W. Zhou, Y. Jia, Y. Yao, L. Zhu, L. Guan, Y. Mao, P. Liu, and Y. Zhang,“Discovering and understanding the security hazards in the interactions
between iot devices, mobile apps, and clouds on smart home platforms,”
in 28th USENIX Security Symposium (USENIX Security 19). Santa Clara,
CA: USENIX Association, Aug. 2019, pp. 1133–1150. [Online]. Available:
https://www.usenix.org/conference/usenixsecurity19/presentation/zhou

A PPENDIX
In this appendix, we provide technical details about D IANE’sdifferent components. We implemented D IANE in about 4,500
lines of Python code, following the high-level architecture depicted
in Figure 2. D IANE is implemented on top of pysoot 4 , whichleverages Soot [76] to translate the companion app’s bytecode
into an intermediate representation. D IANE currently only handles
Android applications.
4 https://github.com/angr/pysoot/A. Static Analysis

C. Hybrid Analysis

To find the initial set of sendMessage candidates within Fuzzing Trigger Identification Details. To implement the fuzzing
a companion app, we analyze its internal representation. In triggers algorithm described in Section III-A, we implemented aparticular, we select all those functions that either contain calls static inter-function backward slicer on top of pysoot. Theoretically,(Soot intermediate-representation invoke instructions) to native the backward slice of a given variable might traverse an arbitrary
methods (having the native attribute) or calls to methods in the number of functions. Therefore, to keep our analysis tractable, ourAndroid framework known to implement network I/O operations backward slicer algorithm adopts a conservative approach.
(e.g., java.net.*, javax.net.*, or android.net.*).
Specifically, when calculating the backward slice of a variable
By applying these rules, we obtain a list of functions that, when v, our backward slicer traverses up to N consecutive function calls
invoked, potentially send network messages to the IoT device.
(we set N to five in our experiments), and it over-approximates data
dependencies when a function call is not followed. For instance, if
B. Dynamic Analysis
a function call takes v as one of its arguments, and the function call
APK Instrumentation. To hook methods of the APK under is not followed, we assume that v is data-dependent on all the otheranalysis and to fuzz them, we use Frida [8]. More precisely, each arguments. Although this approach might lead our static analysis
method is hooked and dynamically modified to include additional phase to produce false positives, it does not affect the performancecode. This injected additional code is used to enable fuzzing of of our tool, since, as explained in Section III-A, we use dynamic
the method arguments and of the used class fields and to extract analysis to validate the results produced by static analysis.
To build the data-transforming function dominator trees, as
information necessary for our analysis, such as the timestamp
explained in Section III-A, we first need to build the companion
when the method is invoked and the contents of its parameters.
Network Interception. D IANE intercepts the network traffic app call graph. To achieve this, we perform intra-procedural typegenerated by the companion app at runtime. D IANE supports the inference [65] to determine the possible dynamic types of the object
interception of traffic sent using both the WiFi and Bluetooth on which a method is called. When this fails, we over-approximate
interfaces. Note that our approach is independent of the specific the possible targets as all the subclasses of its static type.
network medium and only requires to passively observe the Entropy Calculation Details. To find data-transforming functions,communication channel without accessing the content of the D IANE needs to calculate the entropy of each variable v withinexchanged data. For traffic transmitted over WiFi, D IANE leverages the live sets Lif and Lof of a function scope f. To achievea router and the tool tcpdump to capture the packets sent from this, if v is a primitive variable (e.g., int), or a known typethe smartphone to the IoT device, filtering the IP addresses. Traffic (i.e., String, Integer, Float, and Double), we convert
transmitted using the Bluetooth interface is instead captured using the data it contains in its byte representation and calculate thethe Bluetooth HCI snoop Android debugging functionality [15]. Shannon entropy of this sequence of bytes. Note that the entropy
Unless otherwise specified, we use the term network activity to is computed on the entire sequence of bytes, rather than the single
bytes considered separately.
refer both to WiFi and Bluetooth network traffic.
Conversely, if v is a class object, we use pysoot to retrieve its
Fuzzing Objects. D IANE fuzzes both primitive variables (e.g.,
int, float) and class instances. To do this we use pysoot to class definition, and we consider each field variable vc whose
retrieve the class definition of the considered class instances, and type is either primitive or known. For all these field variables, we
we fuzz each field whose type is either primitive or known (e.g., compute their entropy as specified above, and we add them to the
Lif set or to the Lof set, based on to which live set v belongs.
java.lang.String).

17