0

I'm currently analyzing the communication protocol between an ultrasonic cartridge and the machine it operates with. The cartridge is a consumable, and my goal is to virtually recharge it. From what I can tell, the communication uses UART at 9600 baud with 8N1 configuration.

The challenge I'm facing is that the data exchanged between the cartridge and the machine seems nonsensical, leading me to suspect that it's encrypted. I believe the transmitted bytes might include information such as the remaining shots, maximum shots, and cartridge type.

Unfortunately, the IC markings have been removed, so I can't identify the specific MCU being used. However, based on the context, it’s likely an ATTINY or an STC Micro 8-bit MCU. Replacing the MCU isn't an issue for me—I just need to decipher the communication protocol or determine an effective approach to reverse-engineering it.

So far, I've attempted a simple XOR analysis using CryptoChef but haven't found anything meaningful. Any guidance or suggestions on how to tackle this problem would be greatly appreciated.

The following is a sample from the communication, 1 "request" from the machine and 3 following broadcasts from the cartridge. Interesting bytes for this cartridge specifically could be:

Remaining pulses (17380 = 0x43E4), total pulses (0x4E20) and maybe used pulses (0x0A3C) From->To Machine->Cartridge 0xEE 0xB2 0xE2 0x49 0x4E 0xB8 0x81 0xB9 0xBC 0x6B 0xE6 0xC6 0x9B 0xDD Cartridge->Machine 0xEE 0xDB 0xBF 0xC4 0x76 0x37 0xA0 0xE3 0x2E 0x06 0xDD Cartridge->Machine 0xEE 0x6B 0x67 0x57 0x92 0xF7 0xA7 0x0F 0x07 0x04 0xDD Cartridge->Machine 0xEE 0xA8 0x57 0x13 0x1F 0x49 0x4C 0x4F 0x0F 0x1A 0xDD 

PD: I noticed that it always starts with 0xEE and ends with 0xDD and also: 0xDB and 0x6B seem related like 0x67 and 0x57 also seem related.

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.