Introduction
Once upon a time TI had this somewhat quirky software called the BQ Evaluation Software. It can help “evaluate” and configure their gas gauge line of ICs (bq20z,bq34z series and others). In fact, their software development support is so bad, you basically are stuck using their software components for any testing/manufacturing/development.
Now since their software has the ability to manage multiple chips, it has configuration files. Most of the configuration files are boring, but the ones of interest are the .encr files. These files define the dataflash layout of the respective chips. Dataflash is the configuration of the ICs (or basically EEPROM) and there is alot of settings(100+). There are also hidden dataflash settings they didn’t want to release publically but also affect the chip.
But the main problem is I had a need to create a GUI with all the dataflash configuration options and TI already did that work so why repeat it? I could have asked TI’s tools team about access to their data but with previous experience they don’t care about the customer because “it works for them and everybody else” is their automated response to problems.
Thoughts
Originally I just wanted to use their bCfgReader.dll by generating libs and headers manually which is trivial. But then they decided to protect agaisn’t that. It appeared to require the use of two functions SetMagic1 and SetMagic2 to properly “handshake” an application exe to the DLL in order to allow usage of the read functions. Otherwise a flag would stay set that would prevent decryption. I don’t see an valid reason otherwise for the two functions to exist other than the “authentication”. I did think they were simply for seeding an algorithm before I found out their encryption was just XOR ciphers.
So I took the brute force approach, this took a little bit of time late at night poking their compiled DLL in a dissembler.
After breaking it open and seeing their encrypted data. I just have to say their data format is AMAZINGLY bad. They combined CSV with XML and also added amazing <Comment> tags to…put comments…instead of the standard <!– —> block. The CSV could have also been easily been described as XML. Otherwise the entire file could have also been described as just pure CSV because the XML is extremely shallow in depth.
Format
The TIENCR format always starts with a 13 byte header.
Bytes 0 to 5 (format header) - TIENCR
Byte 6 - 0x01
Byte 7 - Key Length XOR Byte
Bytes 8 to 12 - Misc. header data that is usually empty
Byte 13 - Must be XORed with Byte 7 to get the proper key length
After the header comes the key used for decrypting the data. Bytes 14 to 14+keylength - Key used for decrypting data
The key in its “raw” form is actually ciphered slightly. Starting from the last byte of the key, it must be XORed with the byte before it in the key recursively to retrieve the original key byte. The only byte that stays the same is the first byte of the key because you can’t XOR it with anything once you get to it.
After the key comes the file’s data. Each character of the data is encrypted. The encryption on the data is also an XOR cipher but slightly different. The cipher on the data is done by taking the first data byte and XORing with the first key byte. Second data byte with the second key byte, and so on. This repeats until you the last byte of the key is reached. After xoring the last byte, the next data byte is XORed with the first key byte and the sequence repeats.
tiencr
tiencr is the resulting tool to decrypt and encrypt between the format. It will accept any file that is encrypted in this form and decrypt it.
Code avaliable here: https://github.com/marekr/tiencr https://github.com/marekr/tiencr
Binary avaliable here: https://github.com/marekr/tiencr/releases