The TC66C
Reverse engineering the TC66C USB-C Meter
This is an interesting little USB-C meter, which I quite like. It has a very similar feel and operation to the meter I modified previously (TC64).
This meter does support bi-directional measurement, so no modifiations were required to be able to use the meter at the device end of the cable. This unit will also act as a trigger unit which is really handy for devices that lack USB-PD functionality (Looking at you TS80, grumble, grumble).
It features two switches to control if it draws its own power from the USB-C or the extra USB-micro, and also control for the USB-PD identification resistors.
Make sure to have the PD switch off, if the device you are measuring the power inline with already knows about USB-PD.
Reverse engineering
Now, I dont want to include in here a full review of this meter, as many others have already done so. Instead, I want to focus on my only grip with the meter… The App.
The provided Android application is terrible, its doesnt overly do much, and mostly just shows you a remote copy of the screen at best. It also misses samples sometimes, and only exports to excel documents, which is also frustrating. The updates are pushed by an apk update from “somewhere” rather than using the play store properly.
The app experience isn’t what I would call amazing, and I’m sure with work it could be improved.
However, the beauty of them serving the apk from their own server, is that it was trivial to grap the apk file and run it through a converter to a .jar file.
Decompiling the APK provides rough java source code for the application. I wont detail much about this process here, as there are much better guides out there.
Suffice to say, that its not overly hard to gather the AES keys being used in the application.
Details
The main chipset is a small ARM micro, a GD103 I believe. However, its of low relivence here.
The BLE protocol this device uses is not documented anywhere I can find online, so all of this is based on my reverse engineering work.
It exposes one characteristic that can be written to, to control the device.
The commands that are sent are in plain ascii, with not encryption. So these can be easily captured and figured out.
By observing the messages that are sent by the app, the following strings have been found:
- “brotat\n\r” –> Rotates the device screen
- “blastp\n\r” –> Goes back one screen
- “bnextp\n\r” –> Goes forward one screen
- “bgetva\n\r” –> Asks for measurements to be sent
There are no ACK’s for these messages, except that sending the latter (getva), which results in the device sending a series of notifications that contain the measured data.
The general operation is mostly just send the request as often as possible and wait for the data to come back
Recieving data
Recieving data from this unit is a little harder. The data is sent in blocks of 192 bytes, which start with a known constant. However, all of this data is AES encrypted. Thankfully the key can be recovered by the fact that they released an Android app for this unit.
The AES is running in ECB mode, which is nice and simple :grin: The key is noted in the python code, which was extracted from the application. It did hold me up a bit because Java smali uses signed bytes.
Python code
I’m releasing some fairly minimal python code that will interact with the unit, and capture the live readings and show them on the terminal. This is presented more as a proof of concept, its not polished code (yet)
Jump over to Github to see the latest code
Future
In the future I would love to have the time to sit down and make a significantly better android app for this little meter. I probably will eventually, but its not high on the priority list yet. Feel free to drop me a line if you would be interested in this :)