Aperture Controls

Cobb Accessport Reverse Engineering


Found on the Accessport filesystem

Here are some random notes that I feel didn't fit in the other sections or that I remembered later.
  • Taking a flash image from another Accessport (like a Subaru) and installing it into a different Accessport (like a Mitsubishi) doesn't work. There might be different keys burned into the chip for different models or something.

  • There is an $AP_STATE environment variable that determines if the Accessport is locked to a car or not. 0 is not locked. 1 is locked to a car. 2 is recovery mode.

  • The Accessport update files are kept (encrypted with Blowfish) at www.accessecu.com. For instance: http://www.accessecu.com//support/accessport/AP-MIT-002/ . The encrypted files have 6 extra bytes at the beginning which is a UInt32 and two nulls. I believe the UInt32 is bitwise AND'd with either 0xF0F0F0F0 or 0x0F0F0F0F and used to seed the P and S boxes as part of the BlowfishStream routine when loading the files.

  • The actual software that's loaded to the Accessport for the update is kept on the PC in a subdirectory of the AP Manager software. The files will have scrambled names like 3cgk921GJn8ph but get converted to actual names on the Accessport. (3cgk921GJn8ph is actually the screen_init script encrypted.)

  • When the Accessport is stuck in a firmware recovery mode, it shows its version as "u1.7.2.0-10103+alex".

  • I spent one month on this project, and it was a fun month.

Prev: Encryption