OBD-II and ELM327 (6), Reverse Engineering HUD Against Pi-WIRE
Purpose
With the aid of Pi-WIRE, drive car at 120km/hr in the basement parking lot, prove my superb driving skill
HUD Reverse Engineering
Once the setup completed, Pi-WIRE started to monitor. There are two CANBUS format in history. Old VOLVO car used 29-bit ID while newer cars used 11-bit ID
Now HUD showed speed at 180 at my desk!
Some Interesting Points as Reverse Engineering HUD
Reference
With the aid of Pi-WIRE, drive car at 120km/hr in the basement parking lot, prove my superb driving skill
To let HUD show something interesting, I shall figure out how it interacts with car. I guess HUD polling the car periodically. So I changed the configuration of MITM in article#4: replace ELM327 with HUD, observing how does HUD act with Pi-CAR. With Pi-WIRE, I can observe the command sent by HUD. In Pi-CAR, I can response arbitrary speed, and check whether HUD showed the desired speed reported by Pi-CAR
- Before
- ELM327 ---- Pi-WIRE ---- Pi-CAR
- After-1
- HUD ---- Pi-WIRE ---- Pi-CAR (report speed=120)
The experiment above proved that I understood the protocol between OBD2/ CAR. As I connect HUD to real car, the car probably running at speed=20. Now I can put a man-in-the-middle, "Pi-WIRE", and let Pi-WIRE increase speed by 1000. Then HUD can show something interesting
- After-2
- HUD(speed=120) ---- Pi-WIRE (report speed=20+100) ---- XC60 (speed=20)
HUD Reverse Engineering
Once the setup completed, Pi-WIRE started to monitor. There are two CANBUS format in history. Old VOLVO car used 29-bit ID while newer cars used 11-bit ID
At first, HUD queries SERVICE-01 PID-00 with both formats. Car responses the format that it supports, and HUD knows the format that car is using. In the screenshot below, HUD queried with CANID 7DF & 18DB33F1. These IDs are from ISO 15765-4 industrial standard. Volvo XC60 responded to 7DF and HUD knew the car is 11-bit format
HUD would query following items from car. They're typical information drawn on HUD. I let Pi-CAR response these queries, and checked whether HUD displays speed as expected
- 01 00, supported PID in 01-20, 4byte bitmap
- 01 05, Engine coolant
- 01 0C, Engine RPM
- 01 0D, Speed
- 01 10, MAF air flow rate
- 01 20, supported PID in 21-40, 4byte bitmap
- 01 40, supported PID in 41-60, 4byte bitmap
Now HUD showed speed at 180 at my desk!
Some Interesting Points as Reverse Engineering HUD
- HUD activation mechanism
- As engine starts, voltage over HUD will drop. With alternator starting to work, voltage rises
- I used DC power supply to simulate the voltage change, and apply to HUD. My HUD becomes active in voltage rising edge
- HUD close mechanism
- HUD display off when
- RPM returns zero (as engine turned off)
- CAN query didn't response for some time (I just unplugged the CAN bus wire)
- HUD low power sucks!
- OBD2 keeps powering! So the static power consumption is quite important. High leakage current will kill battery soon
- The HUD static power consumption is ~50mA
- XC60 uses 70Ah battery, it means HUD drains ~1% battery in 24 hour and 7% battery in a week
- The minimum acceptable battery discharge is 0.5Ah per week
- This means 3mA static current (3mA * 24hr * 7days = 504mAh = 0.5Ah)
- ELM327 Data Sheet
- ELM327 illustrated how to interact with car, this is a very good document. Especially P.27 ~ P.24, which showed how does car responded OBD2 request, and format
- ISO 15765 packet format
- WIKI OBD-II PID
- OBD2 PID list, the definition of CAN transaction
- ISO 15765-4 Document
- New version of the document requires $$, but the legacy version can be found
- REF1
- REF2
TODO
Do the experiment on the car !!
Comments
Post a Comment