Aperture Controls

Cobb Accessport Reverse Engineering

Encryption


Finding a Blowfish encryption key with Ghidra

The Accessport uses a couple different encryption algorithms in places, and the same algorithms are used in the TunerPro software. This fact actually helped me since back in 2016 I was reverse engineering the TunerPro software and found out that the application itself was encrypted. There's a loader that decrypts the application in memory and then loads it. (I actually used Ollydbg to just extract the decrypted application from memory and worked on that in the long run.) The reason this is relevant is because I used a miscapitalized letter to figure out the original source code for the encryption routine using Google.

In most computer programs, any text you see will be stored in a form where you can read it if you open the software in a hex editor (I use HxD). In the encrypted TunerPro loader routine, I saw the string "Data not multiple of Block Size". Normally, you wouldn't capitalize "Block Size". So I Googled around for that string and found https://www.codeproject.com/Articles/1380/A-C-Implementation-of-the-Rijndael-Encryption-Decr. When I compiled this code and compared the generated assembly code, it matched up almost exactly. So now I had a starting point to fill in function declarations in the disassembler and work my way back through the code. This code is also used on the Accessport. The demo software from CodeProject is here. Back then the algorithm was called Rijndael after the authors, but these days it's called AES or Advanced Encryption Standard.

But this isn't the only algorithm used on the Accessport. There is also a Blowfish implementation. Ghidra was nice enough to extract the names of the tables used in the Blowfish implementation, so I compared that against the source code of various implementations I found online. It looks to me like the source code for the implementation used (at least part of it) on the Accessport is straight from the Blowfish author's website: https://www.schneier.com/academic/blowfish/download/.

There are other algorithms in the Accessport (TEAEncrypter, Base64Encrypter) but I either never saw them called in the functions I worked on, or they are never used.

Where are the keys?

Logically, if something is encrypted and the device doesn't communicate with something then the keys must be on the device itself. When you pull a backup off the Accessport, the ROM file (with _enc in the filename) comes over USB already encrypted so we know the key is in there somewhere. Since we have the source code (probably) to both of these ciphers, we can see which parameter is the key and work our way back. Plus AES only takes keys in three sizes (16, 24, or 32 bytes), so we can look through any string or byte array references that are of those sizes. Here are a couple I've found. (They might not render correctly in a web page. They should all be 32 bytes long.)

  • libap_comms - ('RYq{&@VRiFvX> b(6_a^5e^MsMvQUH - used by getPacket
  • rom_encrypter - _xEUm'WfDs~3etCw]ATu8D!0Y%5p+4
  • libUtil - T's!.'cRpV(\BfSS:/<\.HOJ6\>6<U@8
  • gui - /DsS4C1ZxeWVOs2k/DsS4C1ZxeWVOs2k
The firmware itself is encrypted with an AES-128 cipher in CBC mode. The key will most likely be burned into the ROM of the chip itself.

While looking through the Accessport updating code, I noticed there's a subclass of the Blowfish implementation that takes the normal block cipher nature of Blowfish and makes it a stream cipher. This apparently makes it "BlowfishCTR" mode.

This is where I left off my work.

Prev: USB Communication Next: Miscellaneous