Subaru Impreza WRX STI Forums: - View Single Post - Cobb Accessport Why I -HATE- Cobb AP's.
Thread: Cobb Accessport Why I -HATE- Cobb AP's.
View Single Post
Old 07-08-09, 04:35 PM  
Account Inactive
Fav Mod: Coming Soon
My Threads
Posts: 11
My Subaru Parts for sale

Join Date: Dec 2007
Trey@COBB is an unknown quantity at this point
Default Re: Why I -HATE- Cobb AP's.

I can lend a hand to answer some of the questions.

1) There is no date stamp of last flash stored in the Subaru ECU ROM. Any dates would have to come from the device initiating the flashing since there is not a time/date clock within the ECU. We now do more than Subarus and have seen other manufacturers utilize this feature. Mazda, with the influence they've had from Ford I imagine, does this very thing in their ROMs. There are others that also store the last x number of calibration IDs flashed. There are also some that increment a reflash counter. In those ECUs, we do bypass those functions in order to allow the user to truly revert their ECU back to exactly how it looked prior to us writing anything in there.

2) You can request the ECU's checksum and software version using standard OBD-II requests. This is how Subaru or others can check to see if data has changed. It's not so much based on VIN as it is the CALID (Calibration ID or version) and the CVN (Calibration Verification Number, aka checksum). The manufacturer will know that for a given CALID it should have a known CVN. If they don't match what is expected, then it's likely it has been tampered in some way.

3) We have the ability to erase and write to 100% of the addressable ROM space. When the AP is installed, we send our own custom boot loader that takes control over the ECU. Since this is our own program, we can do whatever we want while in this mode. We first read the entire ROM contents from start to finish and save them onto the AccessPORT. We then write the new data to the ECU, including the necessary checksum to allow the ECU to operate properly. We DO NOT disable the checksum by basically telling the ECU to checksum 0 bytes (as described in that article). We actually reverse engineered the checksum algorithm and perform that operation when we're writing new data to the ECU. Once installed, the CALID and CVN reported WILL NOT match Subaru's records. This is due to the fact that we change data within the ECU and thus the checksum changes. Could we make the ECU always report a "correct" checksum so a dealer wouldn't detect a modified ECU? Yes, we have the technical ability to do so. We choose not too because we don't feel it to be an ethical practice. Not to mention what sort of reaction Subaru may have against us should we do so.

When you uninstall the AP, it will write the exact same data read during the initial install process back to the ECU 100%. This includes the CALID and the CVN (checksum). So the part we "touch" we return to the state it was in prior to install.

4) Here's a juicy tidbit for some of you. When Subaru dealers reflash the ECU using the SSM-III, it WILL increment a reflash counter. To gain a little 'cred' with the programmers amongst us, here's how they do it. The counter is in the checksummed space of ROM, but the checksum always stays the same so that the CALID and CVN match known values regardless of it your ECU has been updated by Subaru 3 times or 10 times in the past. There is a 4 byte section in the ROM that a brand new ECU will have the values 00 00 FF FF. When the SSM-III does an ECU update, it will increment the counter by changing that 4-byte section to 00 01 FF FE. And yes, if your ECU has an incremented flash counter in it prior to installing the AP, we put that value back in exactly how it was prior to installing the AP. Even if you've reflashed your ECU 800 times using the AP but your flash counter from Subaru was 2, then we put "2" back in.

Hope this all makes sense,
Trey @ COBB
Trey@COBB is offline  
Likes 0 Dislikes 0