Data in brief 29 (2020) 105149

Contents lists available at ScienceDirect

Data in brief
journal homepage: www.elsevier.com/locate/dib

Data Article

ReCAN e Dataset for reverse engineering ofController Area Networks
Mattia Zago b, *, 1, Stefano Longari a, 2, Andrea Tricarico a, 3,rez b, 5,Michele Carminati a, 4, Manuel Gil Pe
b
,6
rez
, Stefano Zanero a, 7Gregorio Martínez Peab

Dipartimento di Elettronica, Informazione e Bioingegneria, Politecnico di Milano, Milan, Italy
Department of Information Engineering and Communications, University of Murcia, Murcia, Spaina r t i c l e i n f o

a b s t r a c t

Article history:
Received 23 December 2019
Accepted 9 January 2020
Available online 22 January 2020

This article details the methodology and the approach used to
extract and decode the data obtained from the Controller Area
Network (CAN) buses in two personal vehicles and three commercial trucks for a total of 36 million data frames. The dataset iscomposed of two complementary parts, namely the raw data andthe decoded ones. Along with the description of the data, thisarticle also reports both hardware and software requirements toﬁrst extract the data from the vehicles and secondly decode thebinary data frames to obtain the actual sensors’ data. Finally, toenable analysis reproducibility and future researches, the codesnippets that have been described in pseudo-code will be publicly
available in a code repository. Motivated enough actors may
intercept, interact, and recognize the vehicle data with consumergrade technology, ultimately refuting, once-again, the security-

Keywords:
Automotive
Controller area network (CAN)
Reverse engineering
Dataset* Corresponding author.
E-mail addresses: mattia.zago@um.es (M. Zago), stefano.longari@polimi.it (S. Longari), andrea.tricarico@mail.polimi.it (A.
rez), gregorio@um.es (G. Martínez Perez),
Tricarico), michele.carminati@polimi.it (M. Carminati), mgilperez@um.es (M. Gil Pe
stefano.zanero@polimi.it (S. Zanero).
1
URL: https://webs.um.es/mattia.zago (Mattia Zago).
2
URL: https://www.deib.polimi.it/eng/people/details/904890 (Stefano Longari).
3
URL: https://www.researchgate.net/proﬁle/Andrea_Tricarico (Andrea Tricarico).
4
URL: https://www.deib.polimi.it/eng/people/details/642676 (Michele Carminati).
5rez).
URL: https://webs.um.es/mgilperez (Manuel Gil Pe
6rez).
URL: https://webs.um.es/gregorio (Gregorio Martínez Pe
7
URL: https://home.deib.polimi.it/zanero (Stefano Zanero).
https://doi.org/10.1016/j.dib.2020.105149
2352-3409/© 2020 The Author(s). Published by Elsevier Inc. This is an open access article under the CC BY license (http://
creativecommons.org/licenses/by/4.0/).

2

M. Zago et al. / Data in brief 29 (2020) 105149

through-obscurity paradigm used by the automotive manufacturer
as a primary defensive countermeasure.
© 2020 The Author(s). Published by Elsevier Inc. This is an open
access article under the CC BY license (http://creativecommons.
org/licenses/by/4.0/).

Speciﬁcation Table
Subject area
Speciﬁc area
Type of data
How data were acquired

Data format
Parameters for data collection

Description of data collection

Data source location
Data accessibility

Engineering, Computer Science
Automotive Engineering, Artiﬁcial Intelligence
CSV ﬁlesController Area Network (CAN) buses have been accessed using a standard CAN
connector and a CANtact board. The CAN Utils library, publicly available in the Linux
Kernel, has been used to intercept the network trafﬁc of the vehicle. Sensors data havebeen decoded using the state-of-the-art algorithm. The source code for each step of theanalysis is publicly available in the repository, as speciﬁed below.
Raw and Filtered
Cars: 500k baud rate, connected o the OBD-II port of each vehicle.
Trucks: 500k baud rate, connected both to the OBD-II port and to a second wire into asecond CAN bus.
Phase 1: Using consumer-grade hardware, we accessed the Controller Area Network(CAN) buses of ﬁve vehicles. CSV ﬁles contain the binary sequence for each CANline andidentiﬁer in the experiment time window.
Phase 2: Raw data have been decoded and interpreted with well-known and previously
validated algorithms to identify the sensors' variables. Decoded CSV ﬁles contain thesequence of values for each variable, identiﬁer, and CANline in the experiment time
window.
Dipartimento di Elettronica, Informazione e Bioingengeria, Politecnico di Milano, Milan,
Italy
Data repository: ReCAN Data - Reverse engineering of Controller Area Networks [1]Data identiﬁcation number: 10.17632/76knkx3fzv
Direct URL to data: https://data.mendeley.com/datasets/76knkx3fzv
Source code repository: ReCAN Source - Reverse engineering of Controller Area
Networks [2]Source code URL: https://github.com/Cyberdefence-Lab-Murcia/ReCAN

Value of the Data
 These data endeavor to fulﬁll the lack of large, continuous, and machine-learning-ready datasets for automotive analysis.
 The primary recipient for the data are the academic scientists that focus on machine-learning-driven researches. They
might greatly beneﬁt from these freshly generated and carefully reviewed data.
 The main usage of this data is twofold: i) the raw data can be used to train unsupervised automatic decoders while ii) the
decoded data can be used to power self-optimized intrusion detection systems.
 The Controller Area Network (CAN) streams are also decoded and interpreted, such preprocess might provide the scientiﬁc community with additional and improved data characterization.

1. Data description
This dataset aims to provide two types of data to the scientiﬁc community, namely, i) a curated
dataset of automotive raw data frames collected from multiple vehicles (raw.csv ﬁles in Fig. 1), and, ii)
the same data interpreted and decoded (unified.csv ﬁles in Fig. 1). Both aspects are necessary toprovide a common ground for any Machine Learning (ML) analyzer. The data will be available on

M. Zago et al. / Data in brief 29 (2020) 105149

3

Fig. 1. Data repository structure and data samples. (b) Sample of RAW data, obtained as described in Section 2.3 and indicated inFig. 1a as raw.csv. Note that the data column is truncated due to space concerns. (c) Sample of decoded data, obtained as describedin Section 2.4 and indicated in Fig. 1a as unified.csv

Mendeley Data [1]. Moreover, the source code used to extract, decode, and analyze the data is available
in a public repository [2]. Figs. 1a and 2 respectively present the structure and contents of the datarepository [1] and the code repository [2] and will be described in details in Section 1.1 and Section 1.2
respectively.
1.1. Data repository
The data repository is composed of a folder for each experiment, as will be described in Section 2
and summarised in Table 2. For each vehicle, both the raw and the decoded data are stored as CSV
ﬁles. Fig. 1a presents its structure.
The ﬁrst set of data, namely the raw dataset, consists of a list of data frames’ data ﬁeld augmented
with the timestamp (POSIX time), the CAN line identiﬁer, and the Engine Control Unit (ECU) identiﬁer(hexadecimal value). An excerpt of data is available in Fig. 1b (the binary sequences are truncated to
improve their readability).
The second set of data, namely the uniﬁed dataset, consists of the list of all variables with theirvalues for each CANline and ECU identiﬁer. In this case, instead of having the timestamps as POSIX
time, the values are expressed in a human-readable format (yyyy-MM-dd HH:mm:ss.S). Fig. 1c provides an excerpt of these uniﬁed data.
Since the analysis is heuristic-based and limited to a speciﬁc time window, it is possible that some
ECU identiﬁers exist in the raw data, but not in the decoded version. This situation happens whenever4

M. Zago et al. / Data in brief 29 (2020) 105149

Fig. 2. Code repository [2].

Table 1
Dataset composition according to vehicle type.
ID

VehicleType

Connector

FMS

C-1
C-2
T-1
T-2
T-3

Alfa Romeo Giulia Veloce
Opel Corsa
Mitsubishi Fuso Canter
ISUZU M55
Piaggio Porter Maxi

Car
Car
Commercial Truck
Commercial Truck
Commercial Truck

OBD-II
OBD-II
OBD-II
OBD-II, direct wire access
OBD-II

No
No
Yes
No
No

there is a combination of CANline and ECU identiﬁers that present constant values across all recorded
data frames. For example, by looking at the Opel Corsa data, it appears that the identiﬁers 0D1, 0F1,
139, 148, 17D, 182 (among others) are providing data frames that have constant values, thus they havebeen ignored by the heuristic described in Section 2.
Table 1 presents the vehicles included in the dataset, reporting the vehicle identiﬁer, the type, theconnector used and whether there was the Fleet Management Systems Interface (FMS) available.
Similarly, Table 2 reports for each vehicle the experiments that were performed with their time
windows and description. The table is also providing a summary regarding the number of ECU identiﬁers and data frames.

M. Zago et al. / Data in brief 29 (2020) 105149

5

Table 2
List of experiments per vehicle.
Vehicle

C-1
C-1
C-1
C-1
C-1
C-1
C-1
C-1
C-1
C-2
T-1
T-2
T-2
T-3
T-3
T-3
a

Test

#1
#2
#3
#4
#5
#6
#7
#8
#9
#1
#1
#1
#2
#1
#2
#3

Experiment time
Date

Start

End

2018-07-26
2018-07-26
2018-07-26
2018-07-26
2018-07-26
2018-07-26
2018-07-26
2019-02-01
2019-02-01
2019-10-02
2019-02-20
2019-11-08
2019-11-08
2019-11-08
2019-11-08
2019-11-08

15:15:58
15:46:13
15:49:10
15:50:29
16:10:57
16:20:20
16:53:17
16:31:01
15:18:55
08:54:16
16:04:06
14:51:57
14:34:33
11:48:56
11:16:55
12:57:48

15:35:20
15:48:32
15:49:23
16:10:54
16:20:16
16:30:59
17:10:31
16:40:58
16:30:36
09:22:40
16:35:04
15:07:43
14:43:20
12:14:58
11:23:42
13:42:52

IDs

FramesDescription

77
76
76
83
83
83
83
82
88
78
31, 47a
22
22
23
19
23

3,062,691
364,863
33,005
3,227,315
1,473,625
1,684,769
2,723,484
1,569,776
10,942,747
3,467,855
1,798,602a
498,721263,269
1,729,623
2,795,321
2,795,321

city and highway driving
city and highway driving
repeated brake tests
city and highway driving
city and highway driving
city and highway driving
city and highway driving
city and highway driving
city and highway driving
city and highway driving
city and highway driving
city driving
vehicle not moving
city driving
vehicle not moving test 1
vehicle not moving test 2

For this experiment, there are included both can0 and can1 lines.

1.2. Code repository
The code repository is composed of three main parts, as depicted in Fig. 2. Firstly, a compressed copyof the data is available in the data folder, effectively mirroring the contents of the data repository [1].
Secondly, in the repository root, there is the Jupyter Notebook (python scripts) used to extract, decode,
and analyze the data. Lastly, the graphics folder contains for each vehicle all the pictures generated by
the analysis that have been used by the human expert to provide feedback on the process. In Section 2,
we show examples of such charts and ﬁgures to support the dataset description.
Finally, Figures from 3 to 9 and Table 3 have been used as support to justify the methodology and theexperiments assumptions.
2. Experimental design, materials, and methods
The vehicle data can be accessed through a connection with the physical CAN network, which
nowadays is mainly provided by a standard SAE J1962 [3] On-Board Diagnostics (OBD) connector [4].
CAN communication is based on four different kinds of frames, Namely: Data frames carry data from a transmitting ECU. For example, a frame containing the steering
wheel angle.
 Remote frames are used to request the transmission of a data frame, using the ID to signal whichframe is needed. For example, A is the unit responsible for transmitting messages with ID 0x01,
another unit B can send a remote frame with ID 0x01 to request A to send a data frame. Usually,
these frames are not used, as data frames are typically sent at speciﬁc time intervals.
 Error frames are transmitted when bus errors occur, e.g., when badly formed frames aretransmitted.
 Overload frames signal a delay of the next data frame because the transmitting ECU is overloadedat the moment.
In the logs, the visible CAN trafﬁc is composed by data and remote frames (which are not often usedin standard CAN communication). In our case, remote frames were rarely detected and have been

6

M. Zago et al. / Data in brief 29 (2020) 105149

Table 3Main identiﬁers for each vehicle.

yObtained by FMS.
Manually identiﬁed.
**
These variables appear to be replicated multiple times in the data frame.
*

dropped in the ﬁnal version of the data. Error and overload frames serve only as control infrastructure
and are not usually relayed from the CAN controller to higher-layer applications such as the CAN-toUSB interface drivers. Since they do not carry information, they have been excluded from this analysis.
Data frames have a standard and well-deﬁned packet structure, as indicated by the ISO 15765-2
standard [5]. Fig. 3 presents a schematic view of the frame bytes where it is possible to notice both the
ID and the data ﬁelds. The internal structure and encoding of the data ﬁelds are proprietary, and adecoding manual is generally not available to the public. Nevertheless, in the case of commercial vehicles, like some of the trucks identiﬁed in the following paragraphs, the FMS cheat sheet has been
made available by a third party company that provides these services (as speciﬁed in the SAE J1939
standard [6]).
2.1. Experiments and data ﬁelds
The experimental evaluation has been conducted on ﬁve different vehicles, and more than 38
million frames have been collected to provide coverage and generality. Table 1 reports the complete listof vehicles with their type and the connector used to access the CAN lines. As shown in Table 1, there

Fig. 3. CAN data frame.

M. Zago et al. / Data in brief 29 (2020) 105149

7

Fig. 4. Architecture of the collection framework including both the vehicle and the direct human intervention.

are both consumer cars and commercial trucks. Table 2 reports the list of the experiments with theirtime windows and the number of data frames collected.
Although there are no speciﬁc differences between the two categories (they both operate within the(OBD)-II standard, [3], Chapter 2.2 Related Publications]), they do differ in terms of driveability andgeneral drivers’ behavior. Nevertheless, our analysis shows that standard sensors, such as speed andRevolutions per minute (RPM), have analog series properties.
Unfortunately, the conditions, the timing and the conﬁguration of each vehicle differs from theothers. However, as presented in Table 3 it was possible to identify some most important signals sent by
the vehicles, i.e., speed, RPM and wheels position.
Experiment EX-1-B with the vehicle Alfa Giulia (C-1) consists in a series of sudden and abrupt hardbraking with the purpose of activating the safety devices on the vehicle (such as the anti-lock braking
system (ABS) and the traction control system (TCS)).
2.2. Framework architecture
In Fig. 4 the architecture of the framework is illustrated. The process starts with a vehicle's test
drive, as described in Table 2. As described in detail in Section 2.3, the Data Collection module
consists in both hardware and software elements that act as a probe for extracting CAN frames. Thisdata is stored and published as raw data (see raw.csv in Fig. 1a).
The raw data is then preprocessed in order to calculate statistical features to help decode the framesby the Data Extraction module, as described in Section 2.4. The human expert can provide insights
and feedback regarding the decoding process, for example, by identifying errors or introducing moresophisticated heuristic to distinguish individual cases.
2.3. Data collection
The process of data collection consists of connecting a laptop to the CAN network(s) in order tointercept the trafﬁc during the experiments. In the following paragraphs, both the hardware andsoftware requirements will be listed. As mentioned above, the scope of the collection phase is to obtainthe content of the data frames, obtaining a raw data ﬁle for each vehicle.
2.3.1. Hardware requirements
CANs are generally accessible through the OBD-II connector (either type A or type B depending on
the manufacturer of the vehicle). However, as also presented in Table 1, some CAN lines may not bedirectly accessible from the connector. Thus a physical toolkit to connect to the wires is required. To be
precise, not all OBD-II connectors available for the consumers market provide raw access to the CAN

8

M. Zago et al. / Data in brief 29 (2020) 105149

lines. The totality of wireless devices and most of the wired devices that offer a OBD-II connector are
ELM327 microcontrollers that request diagnostic messages and translate the vehicle response, notproviding any CAN-to-USB interface.
An open-source hardware device speciﬁcally made to access the CAN-to-USB interface is represented by the CANtact device [7].
2.3.2. Software requirements
In terms of software requirements, the Linux kernel already provides the libraries CAN Utils [8],which sufﬁce to interact with the devices and the vehicle's CAN network. To be more precise, in orderto retrieve the CAN trafﬁc, it is necessary to bring up the network interface that provides connectivity.
This can be done through the command slcand [options] <tty> [CAN interface], with sometweaks regarding the CAN bitrate option values. Having a successful connection with the vehicle, theCAN trafﬁc can be retrieved with the command candump [options] <CAN interface>. We used theoption -t a to force the POSIX timestamp of the data to be absolute.
For example, the output of the candump command looks like:(1573208215.472159) can0 300 [8] 64 00 00 00 00 00 00 00.
However, the raw CSV ﬁles have a slightly different format. The conversion is done y converting eachbyte of the frame's data to binary and padding it with zeros to reach exactly 8 bits length.
2.4. Data extraction
Despite the lack of signal-semantic knowledge, as reported in Section 2.3, the data have been
analyzed to extrapolate characteristics that eventually led to a decoded interpretation of the sensors
data. As will be described in this section, by analyzing the data through multiple prisms, it was possible
to pinpoint common structures and, in general, the behavior of the data content. That is to say, the data
ﬁeld (see Fig. 3) has often a substructure of its own, often following a proprietary format. For example, asingle data frame may contain both the vehicle speed and the engine revolutions per minute as 32-bit
integers.
As suggested by Markovitz [9] and Marchetti [10], among others, it is possible to guess the internal
structure of the data ﬁeld by looking at the variability of the bits. Speciﬁcally, a sequence of one or more
bits always at zero may indicate a ﬁeld separator.
Leveraging the knowledge of the identiﬁers, each vehicle trace is separated in sub-traces, one foreach ID and CANline, i.e., each subtrace includes all (and only) the frames for a speciﬁc pair IDCANline, in the same order as they arrived. For each sub-trace, the ﬁrst operation that serves as
the backbone for the analysis is the extraction of the bitﬂip value for each bit in the sequence.
Following [10], we deﬁne the bitﬂip function as the ratio between the number of bit's value changes
and the number of received packages so far. That is to say, let us consider the ith bit of the nth packet,
then the bitﬂip is deﬁned as the number of ﬂips of ith bit divided by n. Within the scope of thisresearch, the bitﬂips are calculated only over the whole sequence of data frames. As described in Alg.
1, the algorithm provides both the sequence of bitﬂips for any given (sorted) list of data frames andtheir proportional value. As an example, the values range from 0 for constant bits (i.e., there are nochanges) to 1 for those bits that constantly changes the value (i.e., each bit is different from the one in
the previous data frame). Moreover, following [10] we deﬁne for any bitﬂip b the magnitude magðbÞ
as described in Equation (1):magðbÞ ¼

∞b0
blog10 ðbÞc otherwise(1)

Note that we do use the ﬂoor function instead of the ceiling one proposed in [10]. This operation do
not change the intended usage in the original algorithm, while permitting to easily separate thosebitﬂips that constantly changes (e.g., b½i ¼ 1 implies that for each frame the i-th bit is different from theprevious one). However, it is still unclear whether a more accurate function to replace the magnitude
may provide a better base for the variable-splitting heuristic.

M. Zago et al. / Data in brief 29 (2020) 105149

910

M. Zago et al. / Data in brief 29 (2020) 105149

Fig. 5 reports a few sample heatmap for the bitﬂips of the vehicle Opel Corsa (See Table 2). In theﬁgure, each row represents, in percentage, the number of bitﬂips for each one of the bits of thesequence (up to 64, depending on the identiﬁer). For each identiﬁer, the darker the cell, the higher thenumber of bitﬂips with respect to the number of frames received for that speciﬁc ID and CANline, i.e.,
indicated in Alg. 1 with the returned variable bfp. Empty cells indicate that the data frames received aresmaller than 64 bits (See Fig. 3). For each experiment (as reported in Table 2), a graphical representation of their bitﬂips (like the sample presented in Fig. 5) is available in the repository.
Having calculated the bitﬂips and their magnitudes for each packet, Alg. 2 extracts the data blocks(i.e., potential variables) from the binary sequence (s) and their corresponding bitﬂips (b). Each data
block obtained from the heuristic described in Alg. 2 may represent a variable.

Fig. 5. Sample bitﬂips heatmaps for vehicle Opel Corsa (See Table 2) with different level of information.

M. Zago et al. / Data in brief 29 (2020) 105149

11

Nevertheless, as reported by [4,9,10], among others, car manufacturers tend to implement naïve
protection strategies in the form of CRCs and counters. For example, a counter may be used to order thecorrect sequence of frames, while a CRC may be used to detect random transmission errors.
Finally, the third phase of the process consists of taking the calculated data blocks and attempt to
decode them according to their type. In the speciﬁc case of both CRCs and counters, their respective
data blocks are ignored. At this stage, each block falls in one of the following categories. Let s and e be
the start index and the end index of the block, respectively; S be the binary sequence, B the corresponding bitﬂips vector and M their magnitudes.

12

M. Zago et al. / Data in brief 29 (2020) 105149

 If s ¼ e the block is considered as binary.
 If there is a region ða; bÞ0s  a < b  e in S such that ci02,B½izB½i þ 1, the region ða; bÞ isconsidered a counter. The remaining parts, if any, are re-analyzed as separated blocks.
 If the average bitﬂip value is between 0.5 and ± its standard deviation, the block is considered a crc.
 If the length of the block is between 1 and 4 (1 < e  s  4) the block is considered a nibble.
 If the length of the block is between 4 and 8 (4 < e  s  8) the block is considered a byte.
 If the length of the block is between 8 and 16 (8 < e  s  16) the block is considered a halfword.
 Otherwise the block is considered a word.
The division between nibble, byte, halfword, and word is instrumental to the analysis. To
improve the comparability of the variables, they have been grouped according to their size (i.e., theirvalues ranges).
2.5. Data characterization
This section focuses on providing sample insights on the proposed datasets. Each ﬁgure, table, ormeasure proposed in this section is available in the source code repository.
The code repository, for each vehicle, contains both the source code and the generated statistics toverify these metrics. For example, Fig. 6 presents the distribution of the number of data frames per ECU
ID, captured for each vehicle, experiment, and, where available, CANline. To be more precise, thevertical axes represent the number of data frames captured, while on the horizontal axis, the ECU
identiﬁers that have been stripped of their names and sorted. In the ﬁgure, it is possible to notice that,independently from the vehicle, only a handful of IDs produces most of the data frames found in the
network trafﬁc. Fig. 7 presents these distributions as boxplots (on a logarithmic scale for visualization
purposes).
The differences between the number of frames per ID can be explained by looking at the interarrival
frames times per (ECU) identiﬁer. Fig. 8 presents an example of such analysis for each ID of the Alfa
Romeo Giulia (C-1, Exp-3).
2.6. Limitations
There are plain and noticeable limitations to the methods and algorithms used to decode the data.
The following paragraphs will address the main one to provide clariﬁcations.
First and foremost, OBD-II both refer to the physical connector (as speciﬁed by the SAE standard
J1962 [3], formally the J1962 diagnostic connector) but also to the whole standard, also including theelectric speciﬁcations and the communication protocol. In the context of this research, the data do not
use the OBD-II protocol to request sensors data. However, the OBD-II connector has been used as a way
to obtain direct access to the internal CAN networks.
2.6.1. Hardware limitations
To the best of our knowledge, not all the vehicles offer public and unrestricted access to all theinternal CAN networks through the OBD-II diagnostic connector, that is to say, apart from the aforementioned OBD-II querying protocol, the manufacturer is not required to provide direct access to theinternal networks. For example, as cited before in Table 1, in at least one scenario was necessary to havedirect physical access to the CAN network wires to be able to intercept the trafﬁc.
2.6.2. Sofware limitations
To the best of our knowledge, there are libraries and projects that offer the services of connecting,reading, and decoding vehicle data [11]. However, these libraries are based on the OBD-II querying

M. Zago et al. / Data in brief 29 (2020) 105149

13

Fig. 6. Number of data frames intercepted for each vehicle, CANline and experiment (Table 2), the series have been sorted andincludes only those IDs for which there is at least one data variable obtained from the data extraction algorithm, as speciﬁed in
Section 2.4.

protocol, which provides decoded data within a user-friendly interface. In contrast, the approach
inheres proposed aims to bypass this protocol by providing data frames traces collected directly fromthe CAN networks through the OBD-II port. To be precise, the OBD-II only provides a subset of theinformation, while the CAN provides access to all the communications in the vehicle. However, older
vehicles might not have access to the CAN network through this connector. Thus it will be required to
identify, peel, and connect directly to the network in order to use it.
Since the exact match between the data encoding and the names and values of the sensors is usually
proprietary, this research relies on the FMS datasheet, where and when available. Generally speaking,the FMSs are considered intellectual property and usually have a high market value. For example, in thecase of the Mitsubishi commercial truck (T-1), where the FMS has been made available by the owningcompany, it was possible to validate the output obtained from the heuristic algorithm of Section 2.4
with the information provided in the FMS. In this case, it appears to be clear that there are noticeable differences regarding the identiﬁed and decoded variables and the actual sensors data

14

M. Zago et al. / Data in brief 29 (2020) 105149

Fig. 7. Statistical information regarding the number of ECU identiﬁers for each vehicle and experiment. The bottom axis presents theunique count of ECU identiﬁers, while the top axis reports the boxplots that describe the distributions of data frames for eachvehicle, experiment and ECU identiﬁer. Note that for vehicle T-1 there are two CAN lines.

Fig. 8. Interarrival frames times for vehicle Alfa Romeo Giulia (C-1). Values are in logarithmic scale.

speciﬁcations. Consider both Table 3 and Fig. 9 as base for this validation process. FMS speciﬁcations
indicate that the speed, registered as a decimal number, is encoded with the ECU identiﬁer 18FEF100
using bits 16e23 for the integer part and 8e15 for the decimal part. Despite having correctly locatedthese two regions (see Fig. 9), the decode heuristic also identiﬁed 5 more variables, which might beused as support variables by the ECU. Correspondingly, the (RPM) data are encoded in the 32e39

Fig. 9. Bitﬂips magnitude heatmap for vehicle T-1, limited to the ECU identiﬁer that carries the information regarding the (RPM)
and speed sensors.

M. Zago et al. / Data in brief 29 (2020) 105149

15(integer part) and 24e31 (decimal part) regions of 0CF00400 ECU identiﬁer, while the algorithm also
identiﬁed multiple locations that can be considered as variables.
To the best of our knowledge, unless indicated by the FMS datasheet, there are no heuristics thatrecognizes two components of the same variable, such as the integer and the fractional parts.
Acknowledgments
This study was funded by a predoctoral grant from the Spanish National Cybersecurity Institute n Avanzada en(INCIBE) within the program “Ayudas para la Excelencia de los Equipos de Investigacio
Ciberseguridad” (“Grants for the Excellence of Advanced Cybersecurity Research Teams”), with code
INCIBEI-2015-27353; “Ayudas para estancias en el estranjero de alumnos de doctorado en las líneas de
n de Campus Mare Nostrum” (“Grants for stays abroad of Ph.D. students within the lines ofactuacio
action of Campus Mare Nostrum”); European Union's Marie Skłodowska-Curie grant agreement No
690972; European Union's Horizon 2020, under grant agreement No. 700326 (RAMSES project).
Conﬂict of Interest
The authors declare that they have no known competing ﬁnancial interests or personal relationships that could have appeared to inﬂuence the work reported in this paper.
Appendix A. Supplementary data
Supplementary data to this article can be found online at https://doi.org/10.1016/j.dib.2020.105149.
Referencesrez, G. Martínez Pe
rez, S. Zanero, ReCAN Data - Reverse Engineering[1] M. Zago, S. Longari, A. Tricarico, M. Carminati, M. Gil Pe
of Controller Area Networks, Mendeley Data [dataset], 2020, https://doi.org/10.17632/76knkx3fzv.
rez, G. Martínez Pe
rez, S. Zanero, ReCAN Source - Reverse Engi[2] M. Zago, S. Longari, A. Tricarico, M. Carminati, M. Gil Pe
neering of Controller Area Networks, 2019, https://doi.org/10.5281/zenodo.3625715. URL: https://github.com/
Cyberdefence-Lab-Murcia/ReCAN.
[3] SAE International Surface Vehicle Recommended Practice, SAE J1962: Diagnostic Connector, Jul. 2016, https://doi.org/10.
4271/J1962_201607.
[4] V.H. Le, J. den Hartog, N. Zannone, Security and privacy for innovative automotive applications: a survey, Comput.
Commun. 132 (October) (2018) 17e41, https://doi.org/10.1016/j.comcom.2018.09.010.
[5] International Organization for Standardization, Geneva, CH, ISO 15765-2: Road Vehicles e Diagnostic Communication overController Area Network (DoCAN) e Part 2: Transport Protocol and Network Layer Services, Apr. 2016.
[6] SAE International Surface Vehicle Recommended Practice, SAE J1939: Serial Control and Communications Heavy Duty
Vehicle Network - Top Level Document, Aug. 2018, https://doi.org/10.4271/J1939_201808.
[7] E. Evenchick, CANtact, Jan 2017. https://linklayer.github.io/cantact/.
[8] Linux Kernel, Can Utils. https://github.com/linux-can/can-utils, Feb 2018.
[9] M. Markovitz, A. Wool, Field classiﬁcation, modeling and anomaly detection in unknown CAN bus networks, Vehicular
Communications 9 (2017) 43e52, https://doi.org/10.1016/j.vehcom.2017.02.005.
[10] M. Marchetti, D. Stabili, READ: reverse engineering of automotive data frames, IEEE Trans. Inf. Forensics Secur. 14 (4)(2019) 1083e1097, https://doi.org/10.1109/TIFS.2018.2870826.
[11] J.M. Smith, Awesome Vehicle Security. https://github.com/jaredthecoder/awesome-vehicle-security, 2016.