2

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

2 Answers 2

2

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
7
  • What does the machine/cartridge sends back if you replay a previous cartridge/machine message?
    – Yotamz
    Mar 13 at 9:34
  • @Yotamz The machine is capable of only sending 2 commands, 8F 7F (Wich is the init response message I didn't talk about), and the subtract command. The cartridge instead is capable of sending 3 commands, 7F 8F (the init), the Identification string, and AA 01 (ACK). I can succesfully emulate the machine/cartridge with dock light if that is your question
    – fpp
    Mar 14 at 12:50
  • If I understand correctly, you can emulate either side of the devices and communicate with the other (real) device, so you should be able to construct messages manually. If so, what happens if you send a "subtract to 20099" as in your second line of code? BTW, the second byte, right after FB seems to be the size in bytes of the data including checksum
    – Yotamz
    Mar 14 at 20:37
  • Well, since I posted the answer, I started to mess a little bit more, and it shouldn't be called a "subtract" command, instead, it should be "set remaining uses" :). The cartridge does no verification if the number is bigger or smaller than the one already stored. The limit seems to be 20100 uses tho. Giving it a bigger number just has no effect. And also, good suggestion about the first data byte, I wouldn't have figured it out. I still have to figure out what the 01 03 means, but maybe playing with other cartridge models will help
    – fpp
    Mar 15 at 22:50
  • 1
    So the answer is that sending FB 03 86 00 75 BF resets the counter to the max value. Please edit the answer above and add the solution you found, this is good information.
    – Yotamz
    Mar 17 at 8:18
-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.
1
  • Obviously a GenAI answer. The OP already extracted information from the device before posting the question, and also found and posted an answer.
    – Yotamz
    Mar 26 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.