DBPOWER ELM327 Wi-Fi Interface (OBD II) "review"

Last night the control engine light came on. 11PM, -3°C, 50km from home. Great - not. Drive home? Get towed?

So this adapter confirmed to me:

P0141 - O2 sensor heater circuit bank 1 sensor 2

= not critical = I could drive home without damaging the engine or catalytic converter

Last time I dealt with the exhaust system because of some lose/noisy part(s) I noticed that the connector of the 2nd O2 sensor (that just controls if output of catalytic converter is fine) did not latch (came off again by moderate pulling). So, most probably this is caused just by a bad connection easily fixed if there is a ramp, sunshine and +10°C instead of night and -3°C somewhere on the road.

Resetting the error flag to see if this was a one-time event did work as well.

So I can't recommend enough to get one of those adapters (better go for the Bluetooth version because of random Wifi connection problems with this specific adapter) to put in your cars toolbox.

I use an dumbphone, not a smartphone for all my mobile phone tasks and never really used Android before. Well, because I already waste enough time on the interwebs...

Long story short, I was given an already rooted ZTE blade Gen1, upgraded it to the last official Cyanogenmod version, put the Torque apk on there (appstore requires google account, I don't want one) and intalled it. Torque connects and detects the wifi obd adapter once set up. Time to connect it to my ECU...

Completely new to Android, the first things figured out so far are:

• To get into different modes (recovery,  fastboot, TPT, ...) hold down key combinations on power up (as seen on some IBM Thinkpads)
• It is possible to tinker with the phone by adb (android debug, included in SDK/IDE download)
• There is a bootloader plus recovery, os, user data and cache partition
• Most custom ROMs (OS images) don't contain Google Apps (appstore etc) out of licence reasons. It is necessary to get "GApps" seperately and install it on top of the ROM.
• For different phones/manufacturers the way to get an own recovery (e.g. Clockworkmod) is different (e.g. you have to unlock the bootloader first (calc unlock code from IMEI etc), or just boot from an SD-card with "special" boot files on it
  
  • For ZTE blade, depending on the Gen(eration), which can be found out by the "Blade Checker" app, a "TPT" (total phone transfer) is necessary. A TPT consists of a bunch of files that overwrite almost everything (repartitions the flash, writes bootloader, recovery, baseband (?) and sometimes android/os partition). For ZTE blade, different TPTs are available, for different Gen(erations), different flash layouts and different recoverys. 
• Flashing Android/Google Apps is more or less the same with Clockworkmod:
  
  • wipe
  • install Android from zip (zip put on SD card)
  • install Gapps from zip (zip put on SD card)
  • restart

The following link sums up the procedure pretty well: http://community.giffgaff.com/t5/Tips-Advice/Want-to-root-your-Orange-San-Francisco-ZTE-Blade-Gen-1/td-p/3196075

Files for the phone: http://www.mediafire.com/?k0u19ssphidvo

http://www.amphoras.co.uk/downloads/blade-tpts

Files I used:

Gen1-to-Gen2-TPT-v7.zip size:16.02mb md5:c10cd48bbfb8e2c16384ebb49e06eb5c partitions: 2mb cache, 160mb system, 294mb data

latest Cyanogenmod nightly: http://download.cyanogenmod.com/?device=blade

GApps: http://goo.im/gapps/gapps-gb-20110828-signed.zip

• get cheap "CP2102 breakout board" for sub-2eur
• cut the 5V power trace on the bottom and solder the 3V3 jumper link
• crack open the enclosure of OBD2 Wifi toy
• remove wifi module from main pcb
• solder 2.5mm to 2mm adapter header from junk bin parts (or just use some wires)
• connect the two: GND to GND, POWER to POWER(3V3!!!) TX to TX and RX to RX  (yes, they swapped the signal names on CP2102 breakout board silk screen)
• connect CP2102 breakout board to usb port and fire up putty
• connect with 38400 baud
• send the following ...

+++ 
 cmd> setet 4 
 Ok 
 cmd> setwp ***************** 
 Ok 
 cmd> setssid Bordnetz 
 Ok 
 cmd> wificonfig 
 SSID  : Bordnetz 
 Network Type: AP(2) 
 Encrypt Type: WPA2-AES(4) 
 PassPhrase  : ***************** 
 Ap's channel: 1 
 Dhcp Client : enable 
 Ok 
 cmd> saveconfig 
 Saving Configuration to FLASH 
 Ok 
 cmd> reboot 
 device will reboot... 
 Ok 
 cmd> 

• UNPLUG and REPLUG the usb dongle so wifi module does HARD RESET
• restart your laptop or at least the wireless drivers/interface to forget "known ssid" list (else it tries to connect WITHOUT encryption, which will fail
• connect to wireless network, input passphrase, done

and *tadaa*

Cell 06 - Address: 00:0E:C6:00:3B:1B
   Channel:1
   Frequency:2.412 GHz (Channel 1)
   Quality=48/70  Signal level=-62 dBm  
   Encryption key:on
   ESSID:"Bordnetz"
   Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 9 Mb/s
   18 Mb/s; 36 Mb/s; 54 Mb/s
   Bit Rates:6 Mb/s; 12 Mb/s; 24 Mb/s; 48 Mb/s
   Mode:Master
   Extra:tsf=00000000366ff4f2
   Extra: Last beacon: 344ms ago
   IE: IEEE 802.11i/WPA2 Version 1
   Group Cipher : CCMP
   Pairwise Ciphers (1) : CCMP
   Authentication Suites (1) : PSK

As found out in the previous log, the wifi module is an XLW-210D from xlwtech, running on an AX220xx compatible chip from Asix.

Rabbit hole 3 (dead end):

It is possible to get access to the source code of the reference design with the right google queries and some guessing shockingly easy (why do they include the "blabla not for public relase" note only INSIDE the source code and not in the archive file name?)... as this data is not meant to be freely accessible on the web, I won't provide it here and won't provide tips how to find it. There is no "magic" in there, as the regular function of the device is just obvious, and neither the "AppSrv" nor the demoplug source is included.

Back to Rabbit hole 1:

If AppSrv is enabled, the device spits out to 114.215.182.213:8001 every 500ms:

> 11 00 <OWN MAC ADDR>

Obviously, it wants to call home. Lets answer that call by just echoing back:

> 11 00 <OWN MAC ADDR>
< 11 00 <OWN MAC ADDR>
> 11 00 <OWN MAC ADDR>
< 11 00 <OWN MAC ADDR>
...

This does not work, the device does not react. Lets assume the first two bytes are a command, last 6 ones are parameter. As embedded devs usually don't grab numbers from a RNG for enums etc. but use simple patterns... lets try:

> 11 00 <OWN MAC ADDR>
< 12 00 00 00 00 00 00 00
...silence....

Is it dead, jim? No! Exactly 60 seconds later, the device asks for AppSrv, this time with other content:

> 11 01 <OWN MAC ADDR>
< 12 00 00 00 00 00 00 00
> 11 01 <OWN MAC ADDR>
< 12 00 00 00 00 00 00 00
...

It is not happy with 0x12 anymore. Maybe it wants more?

> 11 00 <OWN MAC ADDR>
< 12 00 00 00 00 00 00 00
...60 seconds silence...
> 11 01 <OWN MAC ADDR>
< 12 01 00 00 00 00 00 00
...60 seconds silence...
> 11 02 <OWN MAC ADDR>
< 12 02 00 00 00 00 00 00
...60 seconds silence...
> 11 03 <OWN MAC ADDR>
< 12 03 00 00 00 00 00 00
... and so on.

Yay, AppSrv fake online :D

Another thing found out: If the payload is shorter than 8 bytes, the message is ignored. At least for the \x12 command the last 6 bytes just seem to be there for alignment and without any particular function.

Btw the source of the UDP packets is not checked by the device, as long as I sniff the data with libpcap and issue a simple

printf "\x12\x??\x00\x00\x00\x00\x00\x00" | nc -u 192.168.0.9 8001

the device is happy.

Uart communication does not seem to interfere with "AppSrv" actions in this state.

To this point, it was easy to figure out the protocol, just because there is direct feedback (read: changed or no response) from the device which "asked" for the right answer. Now the connection is there but I don't know what to ask the device for.

As the AppSrv thing is meant to be a remote-control service from smartphone/anywhere (google translator told me), there must be a command that lets us

a) write data to UART

b) read (poll) data from UART (or enable data transmission)

As this is a chip on my desk, I am sure they shipped it with the complete function and did not stop the implementation after handshaking, even if the AppSrv is offline right now...

We're in :) and the first thing to do is to rename the wifi to "Bordnetz" (German for "vehicle electrical system", but netz = network and "Bord" like in "on-board", I just like this kind of jokes):

cmd> version
mac: 000ec6003b1b
ver: 1.02.23
id : 14041601
Ok
cmd> help
Usage: quit
Usage: version
Usage: setdef
Usage: saveconfig
Usage: reboot
Usage: setssid <Maximum 31 characters>
Usage: setnt <0 = sta, 1 = adhoc, 2 = ap>
Usage: setet <Encryption Type>
       <Encryption Type> 0: No Security    4: WPA2-AES
                         1: WEP-WEP64      5: WPA1-TKIP
                         2: WEP-WEP128     6: WPA1-AES
                         3: WPA2-TKIP      7: AUTO
Usage: setwp <WPA Passphrase, 8 ~ 63 characters>
Usage: setch <channel index>
       <channel index>
       0: Auto 1:  1   2:  2   3:  3   4:  4   5:  5   6:  6
       7:  7   8:  8   9:  9  10: 10  11: 11
Usage: wificonfig
Usage: setwifi <status>
       <status>: 0: disable wifi     1: enable wifi
Usage: serialport <baud rate> <data bits> <parity> <stop bits> <flow ctrl>
       <baud rate>: 0: 115200     5: 4800
                    1: 57600      6: 2400
                    2: 38400      7: 1200
                    3: 19200      8: 300
                    4: 9600       9: 110
       <data bits>: 0: 5    1: 6     2: 7   3: 8
       <parity>:    0: Odd  1: Even  2: None
       <stop bits>: 0: 1    1: 1.5   2: 2
       <flow ctrl>: 0: Xon/Xoff   1: Hardware    2: None
Usage: ipconfig
Usage: setip <ip addr>
Usage: setmask <netmask>
Usage: setgateway <ip addr>
Usage: setdns <ip addr>
Usage: setmode <mode>
       <mode>: 0: SERVER     1: CLIENT
Usage: connectype <type>
       <type>:  0: TCP     1: UDP
       <type>: 10: TCP Srv + Tcp Cli
Usage: setsrvport <port>
Usage: setdstport <port>
Usage: setdsthn <Host name/IP>
Usage: connstatus
Usage: setdhcpcli <status>
       <status>: 0: disable     1: enable
Usage: setdhcpsrv <status>
       <status>: 0: disable     1: enable
Usage: dhcpsrv <start addr> <end addr> <netmask> <gateway> <lease>
Usage: show counter
Usage: transmitsize <size>
       <size>: size in byte (0~4096), default 1024
Usage: transmittime <time>
       <time>: time in ms (0~1000), default 50
Usage: smartconfig
Usage: setat <flag>
  <flag> =1, at cmd enabled, =0, at cmd disabled
Usage: setxap <flag>
  <flag> =1, XAP is enabled, =0, XAP is disabled
Usage: setio <pin> <dir> <value>
<dir>: 0 = input, 1 = output
       setio 1 0    :set p1 dir to input
       setio 1 1    :set p1 dir to output
       setio 1 1 0  :set p1 output to low
Usage: getio <pin>
       getio 1      :get p1 status
Usage: appsrv <flag>
  <flag> =1, appsrv enabled, =0, appsrv disabled
Usage: demoplug <flag>
  <flag> =1, enable plug demo, =0, disable plug demo
Ok
cmd> getio 0
invalid pin
Error
cmd> getio 1
Error
cmd> getio 2
pin=2, value=1, tick=0
Ok
cmd> getio 3
Error
cmd> getio 4
invalid pin
Error
cmd> getio 5
invalid pin
Error
cmd> gerio 6
Unknown command gerio
cmd> getio 6
invalid pin
Error
cmd> connstatus
Wifi Status  : Disconnected.
Socket Status: Disconnected.
Ok
cmd> ipconfig
Static Ip:
Current IP     : 192.168.0.10
Current IP Mask: 255.255.255.0
Current Gateway: 192.168.0.10
Ok
cmd> show counter
Uart   Rx = 248
Uart   Tx = 6215
Socket Rx = 0
Socket Tx = 0
Ok
cmd> demoplug
plug demo is disabled.
Ok
cmd> appsrv
appsrv is disabled.
Ok
cmd> ssid
Unknown command ssid
cmd> reboot
device will reboot...
Ok
cmd> 
cmd> quit


cmd> 
cmd> wificonfig
SSID        : WiFi_OBDII
Network Type: AP(2)
Encrypt Type: None(0)
PassPhrase  : 12345678
Ap's channel: 1
Dhcp Client : enable
Ok
cmd> ipconfig
Static Ip:
Current IP     : 192.168.0.10
Current IP Mask: 255.255.255.0
Current Gateway: 192.168.0.10
Ok
cmd> cmd> 
cmd> set   setssid Bordnetz
Ok
cmd> cmd> wificonfig
SSID        : Bordnetz
Network Type: AP(2)
Encrypt Type: None(0)
PassPhrase  : 12345678
Ap's channel: 1
Dhcp Client : enable
Ok
cmd> saveconfig
Saving Configuration to FLASH
Ok
cmd> reboot
device will reboot...
Ok
cmd> 
cmd> setwifi 1
Ok
cmd> ipconfig
Static Ip:
Current IP     : 192.168.0.10
Current IP Mask: 255.255.255.0
Current Gateway: 192.168.0.10
Ok
cmd> cmd> 
cmd> ipconfig
Static Ip:
Current IP     : 192.168.0.10
Current IP Mask: 255.255.255.0
Current Gateway: 192.168.0.10
Ok
cmd> wlanconfig
Unknown command wlanconfig
cmd> wificonfig
SSID        : Bordnetz
Network Type: AP(2)
Encrypt Type: None(0)
PassPhrase  : 12345678
Ap's channel: 1
Dhcp Client : enable
Ok
cmd> quit

Lets have a look at these...

cmd> demoplug
plug demo is disabled.
Ok
cmd> appsrv
appsrv is disabled.
Ok

Rabbit hole 1: 

appsrv opens up port 8001 on udp and the "connstatus" command now shows "AppSrv Staus: Offline."

The device now sends UDP packets to IP 114.215.182.213 (owned by Aliyun Computing Co., LTD) at ~500ms interval from and to port 8001, with a payload of:

0x [11 00] [00 0e c6 00 3b 1b]

backdoor?

The last bytes are the mac adress of the device (00 0e c6 00 3b 1b). 1100 (dez. 4352) must be a header like "hey there AppSrv!", This IP responds to PING requests! yay!

Btw. If you increase or decrease the IP adress, you see that this IP range is used by all sorts of services (just use http to check), reachring from "hello world" to strange chinese images.

A quick port scan reveals: http://114.215.182.213:8000/ ha! 

The error messages reveal: The code is from the following book: PHP for the Web: Visual QuickStart Guide (link to pdf removed, as ebook seems to be payware/copyrited)

and the login data is the same as in the example! yay!

if ( (strtolower($_POST[‘email’]) = = ‘me@example.com’) && ($_POST[‘password’] = = ‘testpass’) ) { // Correct! 

The page now forwards to http://appsrv.xlwtech.com/login.php which does not exist (anymore), but http://www.xlwtech.com/ exists, bingo!

Seang Well Company Limited.

http://www.xlwtech.com/shownew.aspx?id=103 AppServer! The wifi module is an "XLW-210D module" . Detailed info on config i/f here: http://www.xlwtech.com/upload/2012/8/20120827153114994.pdf

http://www.xlwtech.com/en/showwifi.aspx?id=33

That is a deep rabbit hole!

Rabbit hole 2:

If demoplug is enabled, the device floods ARP requests for 192.168.0.10, which is set as gateway in its config. As it does not answer this request for itself it keeps flooding...  unfortunately, the "setgateway" command reports "OK" but does not change anything... But the IP command works, the device is now 192.168.0.9. This means we can re-configure ourself to be 192.168.0.10 and bingo, it will throw even more data towards us.

The ability of setting device parameters over uart is great! This enables "failsafe" network configuration without lock-out/bricking (hopefully...). It is awesome what can be found in such a tiny tiny circuit board.

The chip with removed label may be an AX220XX compatible device, as its MAC is from this manufactuer. It offers a web interface, but only delivers an empty index.htm on port 80. Port 35000 bridges to the PIC microcontroller. Do not send "+++ return" command over tcp to port 35000, because this leads to message ping-pong between the two controllers.

trying the ethernet vector:

Open ports are:

80, tcp, http (empty index.htm, else http404)

67, udp, dhcps

49153, udp, ???

35000, tcp, uart bridge

For AX220XX there are different reference designs availabe, e.g. over here: http://www.uconnect.com.tw/WMS.html http://www.uconnect.com.tw/files/WiFi_to_serial_command_set_V1.pdf

The AXR2W config tool is availabe in the WA-232B-toolbox.zip over here: http://www.usconverters.com/index.php?main_page=product_info&cPath=70&products_id=404 (requires msports.dll to run under wine), but the chip does not respond. The magic "discovery" string this tool uses is ASIXXISA[0x0e] and is sent over UDP to port 25122.

replaying that magic packet with:

printf "ASIXXISA\x0e" I nc -u 192.168.0.10 49153 -p 25125

did not work...

btw: leaving out the "-u" switch and just running the command on the tcp uart port leads to direct uart/CAM access from shellscripts...

As a summary, It looks like they locked down the chip to prevent mods from the ethernet side, but it still got an exposed uart and it is possible to dump the flash chip contents.

This pdf contains a list of commands the AX220XX accepts over UART, including the "+++" command. As my "unknown" chip reacts to the "+++" command, it is likely that the other commands work, too and -in fact- it is an AX220XX compatible chip.

I won't link to leaked documents from the manufactuer over here, as you can do your own google search. If you try "bootloader" or similar terms together with the chip name, you'll find some pdfs and source code on chinese document sharing platforms ;)

Btw. the whole device consumes 120mA at 12V (1.44 watts), the drop of 12 down to 3,3 V at this current wastes ~1 watt, which makes the linear regulators quite hot. Power safe mode of ELM327 saves about 10mA... as the OBD2-port is connected to the car battery regardless of the ignition switch state, I can only warn to leave these adapters connected while the engine is not running for longer periods of time.

Things to try now:

- wlan is unencrypted, so kismet will show anything the device sends out during startup

- uart access with usb-ttl-uart adaptor

btw. just ordered a cheap 3.50Eur "usb car adaptor" which runs on a step-down converter to replace the lm7805 on the main board, keep the device cool and make it live longer.

• Pin 1: if scope (10meg) is connected, no boot. reset? near GND
• Pin 2: GND, obviously
• Pin 3: TX on 38400 baud, 3V3 level, internal pullup
• Pin 4: RX, 5V level from board (if module not present), PIC sends startup message here
• Pin 5: 3V3, to module (not 5V!)
• Pin 6: 2V8, from module (not present if board not present)
• Pin 7: identical to LED status (low if LED is on, high if LED is off), low if board not present
• Pin 8: jumps to high and stays there
• Pin 9: data line, defaults to high, short data bursts during startup (=flash read)

Pin 1-7 are 2mm pin header.

To get access to the UART (and power the module), a normal 3V3 or 5V ftdi cable is suficcient. Make sure to use 3V3 to power the module.

The device consists of a red main board and a green wifi addon board:

The three electrolytic caps are all 16V rated and on "car +", +5V and +3V3 rails. The chip near the conenctor is a Microchip can controller, the chip on the left is a Microchip pic 18F, which does the CAN-UART translation in the same way as the "original" ELM327 would do. UART is exposed on the pin header in the center to go to the wifi board. The unpopulated parts on the top edge of the board (SO8 IC U11, diode D4, and inductor L1) form a step-down buck converter... but they populated the lm7805 - d'oh!

Not much on the bottom layer: 7805 and 3V3 linear (!!!) regulators and a footprint for a bluetooth module (not populated):

Can transceiver: MCP2551I

PIC microcontroller: PIC18F25K80, supported by PicKit3

The solder job is ok, except solder balls all over the place:

The Wifi-module consists of just one big SoC (part name removed :( ), passive differential-to-single-ended convertion circuit and a TX/RX switch for RF stuff. Footprints for PI filter is present, but not used.

On the bottom layer, a 4Mbit SPI flash holds the software (interface pins exposed :) ), a quatz drives the clock and a LDO (?) does additional local voltage regulation. A pad to mount an U.FL  connector (or similar) is present, but would need a resistor on the top side to be moved one pad.

SPI 4MBit flash: 25L4006E

Wifi SoC: unknown type, 60pins (T)QFP package

TX/RX switch (right to antenna, left/bottom are TX/RX paths)

Next step is to clean up the red main board and remove the loose solder balls,  then power it up using a lab PSU and begin probing/hacking