Security analysis toolkit for proprietary car protocols: CANalyzat0r

While car man­u­fac­tur­ers steadily re­fine and ad­vance ve­hi­cle sys­tems, re­quire­ments of the un­der­ly­ing net­works in­crease even fur­ther. Striv­ing for smart cars, a fast-grow­ing amount of com­po­nents are in­ter­con­nected within a sin­gle car. This re­sults in spe­cial­ized and often pro­pri­etary car pro­to­cols built based on stan­dard­ized tech­nol­ogy. Most of these pro­to­cols are based on bus pro­to­cols: All net­work nodes within such a bus net­work are con­nected using a sin­gle shared data link. This tech­nol­ogy pro­vides a fea­si­ble way of real time com­mu­ni­ca­tion be­tween sev­eral se­cu­rity and com­fort sys­tems. How­ever, often no or in­suf­fi­cient au­then­ti­ca­tion and en­cryp­tion or other se­cu­rity mech­a­nismscan be found in today’s car sys­tems. As de­scribed pre­vi­ously, most of the in­ter­changed data struc­tures on a car net­work bus, in­clud­ing as­so­ci­ated sys­tems, are pro­pri­etary. For this rea­son, there’s a need for open source, ex­ten­si­ble, easy to use and pub­licly avail­able soft­ware to an­a­lyze the se­cu­rity state of such net­works and pro­to­cols.

CAN bus

Start­ing from mid-1980, the CAN bus is being im­ple­mented into ve­hi­cles. Still to this day, many com­po­nents and pro­pri­etary pro­to­cols rely on the CAN bus. While an­a­lyz­ing today’s car pro­to­cols, we fo­cused on this tech­nol­ogy – how­ever, there exist mul­ti­ple ad­di­tional tech­nolo­gies like FlexRay and au­to­mo­tive Eth­er­net which will most likely gain an in­creased rel­e­vance and also need to be an­a­lyzed in the fu­ture.

CAN net­work pack­ets are de­fined by the as­so­ci­ated packet for­mat, which looks as fol­lows [1]:

• Ar­bi­tra­tion ID: De­scribes the mean­ing of the data seg­ments
• Con­trol: Flags to man­age packet trans­port
• Data: Pay­load of the packet with up to eight bytes of data
• CRC: Check­sum

A gen­eral goal of an­a­lyz­ing car pro­to­cols is to re­verse en­gi­neer the CAN ma­trix. This data struc­ture maps CAN ar­bi­tra­tion IDs and cor­re­spond­ing pay­loads to spe­cific ac­tions. An ex­am­ple for this is the iden­ti­fi­ca­tion of a CAN packet which con­trols the ac­cel­er­a­tion of a ve­hi­cle.

De­pend­ing on in­tended goals, the CAN bus can be ac­cessed in two ways:

1. OBD-II in­ter­face: Since 2004, this di­ag­nos­tic in­ter­face is manda­tory for each car in the Eu­ro­pean Union. Most of the time, this port can be ac­cessed from the dri­ver’s seat. In­bound pack­ets can and most likely will be fil­tered by the di­ag­nos­tic gate­way, so fuzzing from this in­ter­face can be of lim­ited suc­cess rate.
2. In­ter­act­ing with bus wires: It’s pos­si­ble to di­rectly splice analy­sis hard­ware into a CAN bus. This way, fil­ter­ing can be cir­cum­vented and oth­er­wise iso­lated bus seg­ments can be an­a­lyzed.

In­tro­duc­ing the CAN­a­lyza­t0r

This Python soft­ware pro­ject is built from scratch with new ideas for analy­sis mech­a­nisms. It’s re­leased on GitHub and bun­dles many fea­tures of other CAN tools in one place. Also, it’s GUI based and or­ga­nized with one tab per spe­cific analy­sis task:

Most of the ex­ist­ing open source CAN analy­sis soft­ware makes use of Sock­et­CAN. This con­sists of a bun­dle of ker­nel mod­ules that ab­stract CAN com­mu­ni­ca­tion in such a way that CAN in­ter­faces can be used sim­i­larly to con­ven­tional net­work in­ter­faces on the Linux op­er­at­ing sys­tem. So does CAN­a­lyza­t0r, in­clud­ing many ad­di­tional fea­tures:

• Man­age in­ter­face con­fig­u­ra­tion (au­to­mat­i­cally load ker­nel mod­ules, man­age phys­i­cal and vir­tual Sock­et­CAN de­vices)
• Multi in­ter­face sup­port: Sniff while send­ing data on a sep­a­rate Sock­et­CAN in­ter­face
• Man­age your work in pro­jects. You can also im­port and ex­port them in human read­able/ed­itable JSON for­mat and track data using a ver­sion con­trol sys­tem.
• Trans­par­ent log­ging
• Graph­i­cal sniff­ing
• Man­age find­ings, dumps and known pack­ets per pro­ject
• Easy copy and paste be­tween CAN­a­lyza­t0r mod­ules. Also, it’s pos­si­ble to paste text based Sock­et­CAN files di­rectly into the GUI to im­port ex­ist­ing packet dumps
• Threaded Send­ing, Fuzzing and Sniff­ing
• Ig­nore pack­ets when sniff­ing - Au­to­mat­i­cally fil­ter unique pack­ets by ID or data and ID
• Com­pare dumps
• Al­lows set­ting up com­plex se­tups using only one win­dow
• Clean or­ga­ni­za­tion in tabs for each analy­sis task
• Ad­vanced packet fil­ter­ing using an in­ter­ac­tive packet re­play ap­proach
• Search for ac­tion spe­cific pack­ets using back­ground noise fil­ter­ing
• SQLite sup­port
• PDF and HTML code doc­u­men­ta­tion

CAN­a­lyza­t0r is mod­u­lar and ex­ten­si­ble – using the pro­vided doc­u­men­ta­tion it’s pos­si­ble to im­ple­ment new fea­tures which in­te­grate into the ex­ist­ing GUI and work flow.

Usage Ex­am­ples

Si­mul­ta­ne­ous sniff­ing and fuzzing

In order to an­a­lyze func­tion­al­i­ties of pro­pri­etary car com­po­nents, fuzzing mostly acts as a start­ing point. Using this ap­proach, CAN nodes can be ex­am­ined to un­cover po­ten­tial se­cu­rity risks. The CAN­a­lyza­t0r can be used to quickly setup an ef­fi­cient fuzzing en­vi­ron­ment:

1. Con­nect the CAN­a­lyza­t0r to the CAN node via Sock­et­CAN and the de­sired bit rate.
2. In the fuzzer tab, choose the de­sired op­tions: For ex­am­ple, it’s pos­si­ble to de­fine a fuzzing mask and a de­sired packet length range which will be ap­plied to all ran­domly gen­er­ated CAN pack­ets:

Re­sult­ing pay­load	Pay­load mask	Length min­i­mum	Length max­i­mum
12 AA 34 56 BB 13	XX AA XX XX BB 13 XX XX	0	6
-	XX AA XX XX BB 13 XX XX	0	6
12 AA 34 88	XX AA XX XX BB 13 37 DD	2	4

Also, CAN Ar­bi­tra­tion IDs can be fixed while pay­loads re­main vari­able. Here’s an ex­am­ple:

Re­sult­ing CAN ID	ID mask	Fuzzing mode
BA4	XAX	User de­fined
832	XXX	User de­fined
563	-	11 bit IDs

While ran­dom pack­ets are being gen­er­ated and sent over the CAN bus, it’s pos­si­ble to use the snif­fer tab to trace an­swer pack­ets. Sniffed packet dumps can be saved, re­played or fil­tered in fur­ther steps.

Semi-au­to­mated packet fil­ter­ing

To ex­ploit and check for packet re­play vul­ner­a­bil­i­ties, it’s often nec­es­sary to cap­ture packet dumps while ex­e­cut­ing a cer­tain task on a car, for ex­am­ple un­lock­ing the doors using the re­mote con­trol. Once such a packet dump that causes a CAN node to ex­e­cute the de­sired task has been cap­tured, it’s mostly de­sired to min­i­mize such a set of pack­ets. To gain the de­sired ef­fect on a car’s com­po­nent, it’s not re­quired to re­play thou­sands of pack­ets every time. In fact, de­sired ac­tions can usu­ally be per­formed using only a few par­tic­u­lar CAN pack­ets.

For this task, the fil­ter­ing tab of the CAN­a­lyza­t0r can be used:

1. Cap­ture “noise” pack­ets: While the de­sired ac­tion is not being ex­e­cuted by the CAN com­po­nent, pack­ets that pass the bus will be cap­tured. These pack­ets will be use­ful in fur­ther analy­sis steps.
2. Record an ar­bi­trary amount of packet sets while ex­e­cut­ing the task once per packet set.
3. Fil­ter­ing: First, all pre­vi­ously cap­tured noise pack­ets will be re­moved from each packet set. After that, only pack­ets which occur in every packet set will be shown. This re­sult­ing set of pack­ets causes the CAN node to per­form the de­sired task while being heav­ily min­i­mized.

Packet search using a bi­nary tree search

Large packet dumps often are the re­sult of fuzzing at­tempts. To as­sist in fil­ter­ing rel­e­vant pack­ets, the searcher tab of the de­scribed toolkit can be used:

1. Load the de­sired packet dump by using ei­ther copy-and-paste mech­a­nisms of the CAN­a­lyza­t0r tabs, text based packet dumps or data­base queries.
2. After con­nect­ing the CAN­a­lyza­t0r to the tar­get ve­hi­cle, start the search­ing process.
3. The loaded packet set will be split into small chunks, which are re­played one after an­other. After one chunk has been re­played, the tool asks the user whether the de­sired ac­tion has been ex­e­cuted by the car. On suc­cess, the pre­vi­ously re­played packet set acts as the new base data set and the search­ing process restarts from the be­gin­ning.
4. If no chunk gen­er­ates the de­sired out­put, ran­dom­iza­tion will be used. This re­sults in shuf­fled packet chunks which will be used for fur­ther re­tries. Using this ap­proach, ac­tions which re­quire mul­ti­ple pack­ets to be sent can be iden­ti­fied.

Data­base man­age­ment

Once packet dumps for spe­cific re­sults have been iden­ti­fied, they can be saved to the SQLite based data­base with an as­so­ci­ated de­scrip­tion. This al­lows a cen­tral­ized find­ing man­age­ment. Using the JSON based data­base im­port and ex­port func­tion­al­ity, data­base states can be ver­sion con­trolled. It’s also pos­si­ble to work on mul­ti­ple CAN­a­lyza­t0r pro­jects si­mul­ta­ne­ously by cre­at­ing sep­a­rate pro­jects.

Easy setup using docker

To get started quickly, the pro­vided docker image can be used. No de­pen­den­cies have to be pre­sent on the host sys­tem and the CAN­a­lyza­t0r is up and ready using only a few com­mands. Please refer to the docker folder within the CAN­a­lyza­t0r repos­i­tory for ad­di­tional in­for­ma­tion.

Github Project