I'm reverse engeneering the communication between an ultrasonic machine and its cartridge.
I've succesfully documented the communicacion of other machines, knowing all the information its exchanged between the two devices, but this case seems to be a little bit more sophisticated.
The machine, when a new cartridge is plugged in, sends an "INIT" command, that is there to tell the cartridge that can send its information to be identified. In theory, the response has to be the same for the machine to be able to identify the cartridge (ex.: ID, mn, etc), but looking at multiple "INIT" commands (from plugging and unplugging the cartridge), nor the machine's "INIT" command or the cartridge's response, seem to repeat once in 420 retries (i only found one repetition).
I have no experience and no knoweldge on how can that be possible, but ClaudeAI figured out it has to be a pseudorandom number generator (pRNG), with a seed that its known by both, the machine and the cartridge. I can't get that seed, because there is no way that I can read the program that is running on the machine/cartridge (it's a hardware impossibility by design), nor its memory.
I also have some proofs that the communication uses a pRNG, thanks to this github project, which gave me these results:
when using what the machine sent to the cartridge in all the 420 init commands. I have no idea on how to interpret all those numbers (I only had a basic probability and statistics course), but the "Non-Random" results makes me think its a pRNG.
The question now is: Is it possible to get the seed of whatever pRNG it's being used?
From reading a little bit, it's possible, but it's "computationally infeasible". What gives me hope on getting the seed, is that the microcontroller used in the cartridge (STC15W204S), is a pretty basic one, with only 4KB of ROM and 256B of SRAM, with a single 8052 CPU running at (max) 35MHz.
What tools could I use to try to get the seed from all I can see in the communication logs?
Here are the cartridge and machine communication logs. I've removed the "repetitive" bytes, such as "open communication", "communication over" and "remaining bytes". The machine always is the one who starts the communication.
