Feeler: Open Source OBC Firmware

[Korath]

I definitely want to use wireless TPM sensors, and I've been looking at the designs to see how easy it would be to rip out the RF/microcontroller board(s).

That development kit looks great, but I'm leaning more towards reverse engineering the RF module and using a separate microcontroller to feed it through to a breakout for the I2C on our OpenOBCs. My analog inputs are reserved for oil pressure and coolant temperature, but I want to add support for additional sensor inputs.

[daandaman]

Dibs on the second board. Im willing to support your development financially!

[vollosso]

It would be easier and cheaper id think to build your own tpms that is made specifically to run through the existing channels. How much accuracy do you really need? Check each tire once every 20s? It would be very easy and you could maybe add a thermoresistor and check temp just for refrence.

[daandaman]

Cant you build one for us? :P will suck dicks.

[Korath]

Once I get my hands on an aftermarket retrofit kit, I'll dissect it and see what I can learn from it.

[FastFreddie]

Which systems are you considering?

[Korath]

I really like the Orange Electronics kit, but I've been reading about the crappy support from the OEM.

[chikinhed]

Has anyone successfully connected an additional sensor (temp or other) to the open obc and have it up and running correctly yet?

Sent from my GTX3582R

[MParallel]

Has anyone successfully connected an additional sensor (temp or other) to the open obc and have it up and running correctly yet?

Sent from my GTX3582R

That I'd like to know as well. I really want an oil temp gauge, something my M3 doesn't have because of teh SMG gear indicator. BMW should have made a simple button so you could switch between SMG display and (digitial) oil temp display. But they didn't even fit the temp sensor on SMG cars.

[daandaman]

It hasnt been done yet but that doesnt mean it cant be done, in fact Im convinced the OpenOBC will do its job perfectly well.

[MParallel]

It hasnt been done yet but that doesnt mean it cant be done, in fact Im convinced the OpenOBC will do its job perfectly well.

Well the analog inputs are already on the board as I understand, so it's waiting for the first person to hook em up.

[vollosso]

Rf senders and recievers are cheap hell amost free. Board mount pressure sensors are cheap as hell. And you could use a really cheap microcontroller. Maybe 80$ a set. The question being can a rf transmitter transmit through an aluminum wheel?

[Korath]

There are recommended frequencies for use to transmit through aluminum. It's just a matter of specifying the power of the transmitter and strapping down a big enough battery to last.

[FastFreddie]

There are open source arduino/AVR and Microchip solutions that might integrate better in the arduino-powered openOBC than an off the shelf unit, which might use a proprietary signal.

http://www.microchip.com/Development...artNO=APGRD003

You also may be able to program it without additional hardware:

That reminds me of my trying to figure out how my 2000 Buick knew how to warn me when I had a low tire. Turns out they don't use pressure measurements at all. Rather as each wheel brake assembly already has a speed pick-up sensor to support the anti-lock brake function they just use that same sensor to read each wheel rotation speed and then compare all four wheel speeds to see how close they are, and if one (or more?) is too much different then the others then it issues the check tire pressure warning. I thought that was pretty cleaver to come up with an additional monitoring function without needing any extra hardware, just added software.

Consider using an XBee as a transmitter or this set of RX linkers:

https://www.sparkfun.com/products/10534 - RF Link Transmitter (434MHz) from SparkFun for about 4$
https://www.sparkfun.com/products/10532 - RF Link Receiver (434MHz) from SparkFun for about 5$

http://www.ebay.com/itm/315Mhz-WL-RF...item5653fc8b80
Ebay Just $1.50 a pair!

http://m.youtube.com/watch?v=DWG00Y2RGsU

[FastFreddie]

There are recommended frequencies for use to transmit through aluminum. It's just a matter of specifying the power of the transmitter and strapping down a big enough battery to last.

I think the frequency used by TPMS is less a function of punch through ability on aluminum wheels but because the FTCC only allows certain wireless frequencies to be used by commercial or consumer products. You could probably use 72mhz, but the antenna would be huge. In a rotating tire that isn't ideal. You could also use 900mhz probably, but the 315/434mhz does have better penetration through interference caused by metal in a vehicle. 1.2ghz and 2.4ghz are also available, but more suited to longer range systems.

[Driiven]

Not sure if this would help you guys at all but a guy from italy worked out an ebay tpms kit to be usb compatible some 5-6 years back. He worked it to the point where it was plug and play with a car pc as seen here. http://www.youtube.com/watch?v=3pj6fauTpDE

board for sale here http://www.carpc.si/shop/hardware

and the creators original thread http://www.mp3car.com/portal-media-c...interface.html he posted source code for all his work in another thread on there

also link for the tpms kit he started from http://www.the3rdeye.com.my/tirepressure.html

[Korath]

I like that microchip, but I was leaning towards reverse engineering an existing kit for the sake of end-user simplicity. I'm already a big arduino fan, so my plan was to grab the stem-based pressure sensors with integrated batteries, pull down their signal with an arduino-based RF system, and route it into the OpenOBC.

Bingo. The 434 Mhz is the standard for most TPMS kits already installed in cars, as well as aftermarket kits. If I went with XBee or Zigbee, it would be a 2.4 ghz system which may eat up batteries. I like the lower frequency system due to the longer battery life.

[daandaman]

@korath; I really like the integration in a car pc like available above, actually it is working wonderfully. But if you manage to make the openobc show tire pressure and temperatures trough one of the boards digital ports (so not the limited few IO's we have available to for instance switch things on and off or receive a high/low signal, and as you said the analog ones for sensors, of which we dont have much), I'd happily buy it from you. Especially if you can integrate another couple of analog inputs!!

[daandaman]

Edited

[Driiven]

this is what I was getting at... The guy posted the source code for the software so from what I gather the reverse engineering is done for you already contingent on the fact that we use the same tpms kit as he did. I'm sure it would be easier to build off of his work than it would be to start from scratch with a new kit no?

[Korath]

Truthfully, I'm doing this from scratch for myself as a fun project. I'll take a look at his code and what he did though.

[FastFreddie]

Truthfully, I'm doing this from scratch for myself as a fun project. I'll take a look at his code and what he did though.

In that case I suggest you start doing some homework
http://www.winlab.rutgers.edu/~Grute.../xu_tpms10.pdf

Communication protocols. The communications protocols used between sensors and TPM ECUs are
proprietary. From supplier websites and marketing materials, however, one learns that TPMS data transmission
commonly uses the 315 MHz or 433 MHz HF bands (UHF) and ASK (Amplitude Shift Keying)
or FSK (Frequency Shift Keying) modulation schemes. Each tire pressure sensor carries an identier (ID).
Before the TPMS ECU can accept data reported by tire pressure sensors, IDs of the sensor and the position
of the wheel that it is mounted on have to be entered to the TPMS ECU either manually in most cars or
automatically in some high-end cars. This is typically done during tire installation. Afterwards, the ID of
the sensor becomes the key information that assists the ECU in determining the origin of the data packet and
ltering out packets transmitted by other vehicles.
To prolong the battery life, tire pressure sensors are designed to sleep most of the time and wake up in
two scenarios: (1) when the car starts to travel at high speeds (over 40 km/h), the sensors are required to
monitor tire pressures; (2) during diagnosis and the initial sensor ID binding phases, the sensors are required
to transmit their IDs or other information to facilitate the procedures. Thus, the tire pressure sensors will
wake up in response to two triggering mechanisms: a speed higher than 40 km/h detected by an on-board
accelerometer or an RF activation signal.
The RF activation signals operates at 125 kHz in the low frequency (LF) radio frequency (RF) band and
can only wake up sensors within a short range, due to the generally poor characteristics of RF antennas at
that low frequency. According to manuals from different tire sensor manufacturers, the activation signal can
be either a tone or a modulated signal. In either case, the LF receiver on the tire sensor lters the incoming
activation signal and wakes up the sensor only when a matching signal is recognized. Activation signals are
mainly used by car dealers to install and diagnose tire sensors, and are manufacturer-specic.

Difculty of reverse engineering. Many potential attackers are unlikely to have access to insider information
and must therefore reconstruct the protocols, both to be able to extract IDs to track vehicles and
to spoof messages. The level of information necessary differs among attacks, replays for example
might only require knowledge of the frequency band but more sophisticated spoong requires protocol
details. For spoong attacks we also consider whether there are available off-the-shelf radios that
can generate and transmit packets at the required frequency.

3 Reverse Engineering TPMS Communication Protocols
As the rst step to analyze the security and privacy risks, a thorough comprehension of the protocols for
specic sensor systems is necessary. To elaborate, one needs to know the modulation schemes, encoding
schemes, and message formats, in addition to the activation and reporting methodologies to properly decode
or spoof sensor messages. Apart from access to an insider, this information would most likely require
reverse-engineering by an adversary. To convey the level of difculty of this process for in-car sensor
protocols, we provide a brief walk-through of our approach below, and we begin by presenting relevant
hardware.
Tire pressure sensor equipment. We selected two representative tire pressure sensors that employ
different modulation schemes. Both sensors are used in automobiles with high market share in the US. To
prevent misuse of the information here, we refer to these sensors simply as tire pressure sensor A (TPS-A)
and tire pressure sensor B (TPS-B). To help our process, we also acquired a TPMS trigger tool, which is
available for a few hundred dollars. Such tools are handheld devices that can activate and decode information
from a variety of tire sensors implementations. These tools are commonly used by car technicians and
mechanics for troubleshooting. For our experiments, we used a TPMS trigger tool from ATEQ [8] (ATEQ
VT55).
Raw signal sniffer. Reverse engineering the TPMS protocols requires the capture and analysis of raw
signal data. We selected GNU Radio [2] in conjunction with the Universal Software Radio Peripheral
(USRP) [1]. GNU Radio is an open source, free software toolkit that provides a library of signal processing
blocks that run on a host processing platform. Algorithms implemented using GNU Radio can receive data
directly from the USRP, which is the hardware that provides RF access via an assortment of daughterboards.
They include the TVRX daughterboards capable of receiving RF in the range of 50 Mhz to 870 MHz and
LFRX daughterboards able to receive between DC to 30 Mhz RF band. For convenience, we also initially
used an Agilent 89600 Vector Signal Analyzer for data capture, but such equipment is not necessary. The
pressure sensor modules, trigger tool, and software radio platform are shown in Figure 2.
3.1 Reverse Engineering Walk Through
While our public domain search resulted in only high-level knowledge about TPM communication protocol
specics, anticipating sensor activity in the 315/433 MHz bands did provide us with a starting point for our
reverse engineering analysis.
We began by collecting a few transmissions from each TPS-A or TPS-B sensor. The VSA was used
to narrow down the frequency bandwidth necessary for capturing the full transmission and to estimate the
6
rough sample rate to avoid aliasing. We placed sensors close to the VSA receiving antenna while using
ATEQ VT55 to trigger the transmission. Although initial data collections were obtained using the VSA,
the research team switched to using the USRP to illustrate that our ndings (and subsequently our attacks)
can be achieved with low-cost hardware. An added benet of using the USRP for the data collections is
that it was capable of providing synchronized collects for the LF and HF frequency bands — thus allowing
us to extract important timing information between the activation signals and the sensor responses. To
perform these collects, the TVRX and LFRX daughterboards were used to provide access to the proper
radio frequencies.
Once sensor bursts from TPS-A and TPS-B were collected, we began our signal analysis in Matlab to
understand the modulation and encoding schemes, and then moved on to recover bits from the signal. The
nal step was to map out the message format.
Determine coarse physical layer characteristics. The rst phase of characterizing the sensors involved
measuring burst widths, bandwidth, and other physical layer properties. We noted that burst widths were
on the order of 15 ms. During this initial analysis, we noted that each sensor transmitted multiple bursts in
response to their respective activation signals. TPS-A used 4 bursts, while TPS-B responded with 5 bursts.
Individual bursts in the series were determined to be exact copies of each other, thus each burst encapsulates
a complete sensor report.
Identify the modulation scheme. Analysis of the baseband waveforms revealed two distinct modulation
schemes for the sensors. TPS-A employed amplitude shift keying (ASK), while TPS-B employed a
hybrid modulation scheme — simultaneous usage of ASK and frequency shift keying (FSK). We speculate
that the hybrid scheme is used for two reasons: (1) to maximize operability with TPM readers and (2) to
mitigate the effects of an adverse channel during normal operation. Figure 3 illustrates the differences between
the sensors' transmission in both the time and frequency domains. The modulation schemes are also
observable in these plots.
Resolve the encoding scheme. Despite the different modulation schemes, it was immediately apparent
that both sensors were utilizing Manchester encoding (after distinct preamble sequences). The baud rate
is directly observable under Manchester encoding and was on the order of 5 kBd. The next step was to
determine the bit mappings from the Manchester encoded signal. In order to accomplish this goal, we
leveraged knowledge of a known bit sequence in each message. We knew the sensor ID because it was
printed on each sensor and assumed that this bit sequence must be contained in the message. We found that
applying differential Manchester decoding generated a bit sequence containing the sensor ID.
Reconstructing the message format. While both sensors had used the same encoding scheme, the
packet format differs among sensor brands. The next step was to determine the message mappings for the
rest of the bits. To understand the size and meaning of each biteld, we manipulated sensor transmissions by
varying a single parameter and observed which bits changed in the message. For instance, we adjusted the
temperature using hot guns and refrigerators, or adjusted the pressure. By simultaneously using the ATEQ
VT55, we were also able to observe the exact transmitted values and correlate them with our decoded bits.
Using this approach, we managed to determine the majority of message elds and their meanings for both
TPS-A and TPS-B. These included temperature, pressure, and sensor ID, as illustrated in Figure 4. We also
identied the use of a CRC checksum and determined the CRC polynomials through a brute force search.
At this point, we did not yet understand the meaning of a few bits in the message. We were later able
to reconstruct these by generating messages with our software radio, changing these bits, and observing the
output of the TPMS tool or a real car. It turned out that these were parameters like battery status, over which
we had no direct control on the sensor module. More details on message spoong are presented in Section 5.
7
Figure 3: A comparison of FFT and signal strength time series between TSP-A and TSP-B sensors.
preamble Sensor ID Pressure Temperature Flags Checksum
Figure 4: An illustration of a packet format. Note the size is not proportional to real packet elds.

3.2 Lessons Learned
The aforementioned reverse-engineering can be accomplished with a reasonable background in communications
and computer engineering. It took a few days for a PhD-level engineer experienced with prior
protocols and reverse engineering to build an initial system. It took several weeks for an MS-level students
with no prior experience in reverse engineering and GNU Radio programming to understand and reproduce
the attack. The equipment used (the VTEQ VT55 and USRP attached with TVRX) is openly available and
costs $1500 at current market prices.
Perhaps one of the most difcult issues involved baud rate estimation. Since Manchester encoding was
being used, our initial baud rate estimates involved averaging the gaps between the transition edges of the
signal. However, the jitter (most likely associated with the local oscillators of the sensors) makes it almost
impossible to estimate a baud rate accurate enough for simple software-based decoder to work correctly. To
address this problem, we modied our decoders to be self-adjustable to compensate for the estimation errors
throughout the burst.
The results of reverse engineering reveal the following observations. Firstly, it is evident that encryption
has not been used—which makes the system vulnerable to various attacks. Secondly, each message contains
a 28-bit or 32-bit sensor ID and the IDs do not change throughout the sensors' lifetimes. Given that there are
254.4 million registered passenger vehicles in United States [31], a 28-bit Sensor ID is enough to uniquely
identify each registered car. Even in the future when the number of cars may exceed 256 million, the unique
combination of four IDs each associated with one of the four car tires sufces for tracking purpose.

There are several images/figures in the above paper
Additionally, this person made a great video on how to do it even more cheaply...


Personally, I would love it if we could hack this, and I would totally buy 4 sensors and an OBD daughter card if we could make it work together.:buttock Even if the local shop will charge me more to mount/balance my tires because of the presence of TPMS sensors.
I can just see my OBC flashing "Check Tires", although I'm still thinking how it might more cleverly let me know which tire is actually having issue.

There is also an Opensource TPMS project on C
https://code.google.com/p/sunswift/s...ate%253Dclosed

Incidentally, it would definitely be a digital signal, not analog.

[Korath]

Thanks Freddie! This will go well with all the research I'm sifting through right now. I'm going to plan it out, price out my options, decide which one is most feasible, and use my M3 as the guinea pig.

Designing the error message and the tire check interface is the last thing I'm thinking about, although I'd like the warning to say Check Tires with the actual Tire Pressure Menu option list out the pressures and battery life of the front tires, and then a second menu to list out the pressures and battery life of the rear tires.

[M3C]

So if the tire pressure warning will be operational via OBC it will only display the warning message to check the tire pressure without being capable to indicate which particular tire?
If it can be somehow recognized by the main unit which of the 4 sensors is sending the warning message and in addition to tire pressure warning message on OBC screen to display 2 letters: FL (front left), FR, RL, RR (rear right), would this require 4 different frequencies (1 for each sensor)?

[vollosso]

So if the tire pressure warning will be operational via OBC it will only display the warning message to check the tire pressure without being capable to indicate which particular tire?
If it can be somehow recognized by the main unit which of the 4 sensors is sending the warning message and in addition to tire pressure warning message on OBC screen to display 2 letters: FL (front left), FR, RL, RR (rear right), would this require 4 different frequencies (1 for each sensor)?

No you just use a identifier or serial number for each sensor and you can display each.