Cobb Accessport Reverse Engineering
Sending USB commands to the Accessport
USB communication on the Accessport is handled by libap_comms::USBManagerClient::Listen. In order to be able to communicate with the Accessport over USB, you need to switch it to configuration 0x3 which will put the familiar "The Accessport is connected to your computer..." message on the screen. The AP has four USB endpoints: 0x81, 0x02, 0x82, 0x03. The first two are Control endpoints, and the last two are Bulk_Transfer endpoints. The Vendor ID is 0x1A84, and the Product ID is 0x0121. On Windows, the driver used is WinUSB.
Sniffing USB data with Wireshark
I made extensive use of Wireshark with the USBPcap add-on to record the USB traffic while doing various things with the Accessport such as creating/deleting files, upgrading the firmware, and initiating an OBD connection. In the image above, you can see the initial connection to an Accessport, and the first command sent is 0x04 - Get Version. The blue highlighted section at the bottom of the image is the data sent between the device and the software. The format seems to be as follows:
- Bytes 0 - 3 : Protocol version number (2)
- Byte 4 : ?
- Byte 5 : Option byte. Bits 3 and 4 are referenced in the library, and bit 3 has something to do with Blowfish encryption.
- Byte 6 : Command byte. Outlined below.
- Byte 7 : Data size
- Variable length : data
- Last 4 bytes : CRC32-JAMCRC on the whole packet, including the 4 byte space for CRC set to 0
The USBManagerClient::Listen function has a case statement with a list of command bytes the Accessport accepts.
- 0x03 - GetID
- 0x04 - GetVersion
- 0x05 - mounts the user filesystem, sends a response, then closes connection
- 0x06 - OnUpdateManifest - starts a firmware update
- 0x07 - PutFileSetupOut
- 0x08 - PutFileOut
- 0x09 - EndFileSetupOut
- 0x0A - EncFileOut
- 0x0B - GetFileSetupIN
- 0x0C - GetFileIN
- 0x0D - EncFileSetupIn
- 0x0E - EncFileIN
- 0x0F - RemoveFile
- 0x10 - RenameFile
- 0x11 - ListFiles
- 0x12 - GetMapData
- 0x13 through 0x17 - "Special jumps": there's a group of commands that are sent to a special section in the function
- 0x18 - Reboot
- 0x19 - Keepalive : This is continuously sent to the Accessport while it's busy doing something to see if it's completed the task
- 0x1A - OnRunTask : Executes a valid runtask. Outlined below.
- 0x1B through 0x1D - "Special jumps"
- 0x1E - does something and then sends a response
- 0x1F - ListCapabilities
- 0x20 - GetFileSetupIN : this seems to start a section of new commands written for the new version of the Accessport (v3)
- 0x21 - GetFileIN
- 0x22 - PutFileSetupOUT : writes to /user volume
- 0x23 - PutFileOUT : writes to /user volume
- 0x24 - RenameFile
- 0x25 - RemoveFile
- 0x26 - ListFiles
- 0x27 - "Special jump"
- 0x28 - List User Info
- 0x29 - Start direct dongle talk
- 0x2A - "Special jump" Compute hash on encoded file : used during firmware upgrade
- 0x2B - "Special jump" Send computed hash result : used during firmware upgrade
- 0x2C - "Special jump" Load encoded file
- 0x2D - "Special jump"
- 0x2E - Hardware Type
- 0x2F - OBD Passthrough mode : There is an "OBD Terminal" routine somewhere that allows you to send commands to the PIC? device I suppose. The command list I found is here.
The 0x1A OnRunTask function accepts parameters that run code off the ap-app filesystem. The valid tasks are:
- tunerflash $1 $2 : $2 is either "ecu" or "tcm" which determines $change_cmd in the executed line:
execute "$change_cmd \"$1\""
diagnostic_file $1 : $1 is either "create" or "delete"
I tried to do a command injection on the tunerflash $1 argument, but to no avail. I did manage to make the Accessport crash in various way, though.
Files I Generated