just out of interest I bought one of these to play with
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...Read more »
+++ 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>
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 18.104.22.168: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...Read more »
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-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