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

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)

    Reference
    • 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

    Popular posts from this blog

    OBD-II and ELM327 (1)

    OBD-II and ELM327 (3), try to decode CAN package recorded by ELM327

    OBD-II and ELM327 (2), the underlying interface of ELM327