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/22.214.171.124-17485/MD5SUMS . 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 "u126.96.36.199-10103+alex".
- I spent one month on this project, and it was a fun month.