Reverse Engineer an ultrasonic cartridge communication with the station to bypass remaining uses

Question

I Have an ultrasonic machine that has a cartridge with a set amount of uses. When that value gets to 0, the cartridge has to be disposed, and a new one bought. The thing is that with some maintenance before the cartridge runs out of uses, it's possible to prevent it from being damaged, and it's life can be extended (I don't know how true this is, I was just asked to believe).

So far, I was able to find that the cartridge uses an STC uC (100% impossible to read back), and that it's using UART at 19200bps. That's all I know, and I certainly can read the communication with the machine and the cartridge, so I think all the other things are OK. I was even able to replicate the cartridge with my computer, by re-sending recorded messages using docklight.

The thing now is that I can't figure out what is what on the communication. Here is a selected and filtered communication between both devices:

CART - FB 05 01 03 86 00 8E BF // 20100 uses left
MACH + FB 03 85 95 A8 BF // subtract 1 use
CART - FB 05 01 03 85 95 53 BF // 20099 uses left
MACH + FB 03 85 94 AF BF // subtract 1 use
CART - FB 05 01 03 85 94 54 BF // 20098 uses left
MACH + FB 03 85 93 BA BF // subtract 1 use
CART - FB 05 01 03 85 93 41 BF // 20097 uses left
MACH + FB 03 85 92 BD BF // subtract 1 use
CART - FB 05 01 03 85 92 46 BF // 20096 uses left
MACH + FB 03 85 91 B4 BF // subtract 1 use
CART - FB 05 01 03 85 91 4F BF // 20095 uses left
MACH + FB 03 85 90 B3 BF // subtract 1 use
CART - FB 05 01 03 85 90 48 BF // 20094 uses left
MACH + FB 03 85 8F EE BF // subtract 1 use
CART - FB 05 01 03 85 8F 15 BF // 20093 uses left
MACH + FB 03 85 8E E9 BF // subtract 1 use
CART - FB 05 01 03 85 8E 12 BF // 20092 uses left
MACH + FB 03 85 8D E0 BF // subtract 1 use
CART - FB 05 01 03 85 8D 1B BF // 20091 uses left
MACH + FB 03 85 8C E7 BF // subtract 1 use
CART - FB 05 01 03 85 8C 1C BF // 20090 uses left
MACH + FB 03 85 8B F2 BF // subtract 1 use
CART - FB 05 01 03 85 8B 09 BF // 20089 uses left
MACH + FB 03 85 8A F5 BF // subtract 1 use
CART - FB 05 01 03 85 8A 0E BF // 20088 uses left
MACH + FB 03 85 89 FC BF // subtract 1 use
CART - FB 05 01 03 85 89 07 BF // 20087 uses left
MACH + FB 03 85 88 FB BF // subtract 1 use
CART - FB 05 01 03 85 88 00 BF // 20086 uses left
MACH + FB 03 85 87 D6 BF // subtract 1 use
CART - FB 05 01 03 85 87 2D BF // 20085 uses left
MACH + FB 03 85 86 D1 BF // subtract 1 use
CART - FB 05 01 03 85 86 2A BF // 20084 uses left
MACH + FB 03 85 85 D8 BF // subtract 1 use
CART - FB 05 01 03 85 85 23 BF // 20083 uses left
MACH + FB 03 85 84 DF BF // subtract 1 use
CART - FB 05 01 03 85 84 24 BF // 20082 uses left
MACH + FB 03 85 83 CA BF // subtract 1 use
CART - FB 05 01 03 85 83 31 BF // 20081 uses left
MACH + FB 03 85 82 CD BF // subtract 1 use
CART - FB 05 01 03 85 82 36 BF // 20080 uses left

Some things to note:

• after the cartridge (CART) sends its byte stream (which I call "Identification" string), it stays on "idle", sending 00s every 750ms, waiting for the machine to talk to it.
• the ID string is only sent once, and only when the cartridge gets power, never again until power goes out. for the tests, I always turned the machine on, did one trigger (subtract one use) and turned it off.
• the machine reads the remaining uses of the cartridge by the ID string. It never verifies if the chip wrote the data to its internal eeprom or wherever it has to be written.
• there are some prior init messages that have nothing to do with what I want to do
• after the machine (MACH) sends its "Subtract" command, the cartridge responds with sort of an acknowledge, before the machine sends again the same command, and the cartridge responds again, before going into "idle" mode

So far, I think this is how things go:

for everything: FB opens the communication and BF closes it.

for the Identificacion string:

• 05 01 03 is probably some kind of identification string (I'm still in doubt about the 03), the machine is supposed to support different types of cartridges.
• the next two bytes are probably the uses number, but I cant figure out how to obtain an actual decimal number that is equal to the one I know (I can see it on the machine panel).
• I believe that the next bit is some kind of checksum, but I don't know which one.

for the Subtract command:

• 03, I don't really know. It can be part of the number of uses, but I'm not sure. I can't get the cartridge to go to 0.
• the next two bytes are, again, the number of uses left, or part of it.
• the next byte, again, could be a checksum, but don't know what.

That's where I'm currently sitting. I would like to know if there is some kind of program or website that could help me figure out if the supposedly "checksum" byte, is actually a checksum or not, and also figure out what operation is done to the number to convert it to those two or three bytes before the checksum

Answer 1

I think its pretty obvious it is my first time doing this.

Example: FB 05 01 03 86 00 8E BF

• FB: Opens comm
• 05 01 03: Cartridge model
• 86 00: The actual number. 86 = a, a = X/150, 00 = b, b = X%150, where X is the remaining uses. I was able to figure out this by resolving an ecuation system.
• 8E: CRC8 of the previous bytes except FB. I googled: 1 byte Checksum, it was the first result.
• BF: Closes comm

EDIT: Also figured out that by sending the supposedly "subtract" command, I'm able to rewrite the number of uses remaining. The structure is the next.

Example: FB 03 86 00 75 BF

• FB: Opens comm
• 03: Cartridge ID or number of bytes to be sent. Not sure yet
• 86 00: Remaining Uses (in this case, 20100)
• 75: CRC8 of the previous bytes except FB
• BF: Closes comm

Answer 2

Some general steps that might help you in your process are:

1. Taking the unit apart and looking up the datasheet for each IC from the ports to the CPU.
2. If the above doesn't work, try googling the unit to see if the protocol is documented somewhere or if someone has already reverse engineered it.
3. Attach a debugger to the process or use a scope that has decode options built into it, like the SDS1202X, to capture the serial data.
4. Play around with the baud rates until legitimate data packets are sent.
5. Use a program that virtualizes a COM port and displays the exchanged data to decode the functions.
6. Write a program to automate control.

Moreover, here are some websites you might find useful:

• Hackaday: a story about reverse engineering a wirelessly controlled adjustable bed. It involves a lot of technical details on how the process was carried out.
• Hackster.io: a story about bypassing the razor-and-blades business model of the Cat Genie automated litter box by reverse engineering its soap cartridge.

Additionally, some tools you might find helpful are:

• ChipWhisperer: a breakthrough in hobbyist use of power analysis and glitching attacks on embedded hardware. It has IDC and SMA sockets for connecting custom breakouts housing a chip you're probing.
• HackRF: a tool used for controlling a toy RC car by reverse engineering its wireless control protocol.
• RTL-SDR: a tool used for reverse engineering wirelessly controlled adjustable beds and garage door openers.