Reverse engineer checksum to allow direct control of litter robot

[mbafford]

Placeholder to encourage open discussion regarding reverse engineering the checksum.

Observations

• The robot sends a message counter on every status update. The server's response must be based on the robot's last sent counter value.
• The robot updates the expected counter value when a message is received, so multiple messages with the same counter will not be accepted.
• The litter robot acknowledges and accepts a message with AOK,serial,1,same_counter,new_checksum. _TODO: determine if new_checksum is consistent when message number is consistent._
• If the server gets delayed in sending messages and the robot sends an update, the counters can become out of sync, and the robot will reject the server's message using NOK,serial,1,bad_counter,new_checksum then NOK,serial,8,bad_counter,new_checksum - the two new_checksums are different.
• The server will happily send multiple messages with the same counter if you toggle multiple switches in the app quickly. At most one message will be accepted. In my observations, the robot gets overwhelmed and may not ACK (AOK) any of the messages, but the next status update does indicate the command was applied.
• During initial setup of the robot, the app scans a QR code that has a serial number for the device - this serial number is not the serial number / device ID being communicated in the UDP protocol, but is in the format LR3C###### - it's possible the serial number is part of the hash. You can obtain your serial number from the wifi add-on chip (maybe), the sticker that came with the add-on, or the app (under Settings -> Account Details).
• The checksum does not appear to be related to time - powering off the robot will, if all reported conditions are equal, result in the same checksum being generated. For the exact same message from the server (including the same message number), the same checksum is used and accepted by the robot.

Potential data-points influencing checksums

Based on 7 days of data, I did some simple analysis of checksums as generated by the robot. Surprisingly, most data-points do not impact the checksum - or they do in a way that multiple values can have the same impact (modulo math?) - for example, looking at checksums seen 11 times over a 7 day period, the CS codes and the message numbers could be entirely unique for each message with the same checksum.

This leads me to believe that the checksum is not based specifically on the message.

query results ofselect checksum, count(distinct model), count(distinct serial), ...:

checksum	rows	models	serials	hs	powers	states	waits	lights	sleeps	locks	cscodes	msgnums	checksums
000FAC40	11	1	1	1	1	4	1	1	1	1	10	11	1
15C253B9	11	1	1	1	1	3	1	1	1	2	10	11	1
2530E6EE	11	1	1	1	1	4	1	1	1	2	10	10	1
2AF661CE	11	1	1	1	1	2	1	1	1	1	11	11	1
52B4B7FF	11	1	1	1	1	3	1	1	1	1	9	11	1
52D2151A	11	1	1	1	1	5	1	1	1	1	9	11	1
52F5B77D	11	1	1	1	1	5	1	1	1	1	9	11	1
5332248C	11	1	1	1	1	3	1	1	1	1	10	10	1
5624720A	11	1	1	1	1	5	1	1	1	1	10	11	1
62F7C2FF	11	1	1	1	1	4	1	1	1	1	9	11	1
86523CFC	11	1	1	1	1	4	1	1	1	1	10	10	1
881DD751	11	1	1	1	1	2	1	1	1	1	8	10	1
8AA6299F	11	1	1	1	1	3	1	1	1	1	11	11	1
A2F5B766	11	1	1	1	1	5	1	1	1	1	9	11	1
B86B0DBD	11	1	1	1	1	2	1	1	1	1	8	9	1
C2F46FA6	11	1	1	1	1	5	1	1	1	1	10	11	1
E9DB4879	11	1	1	1	1	2	1	1	1	1	9	9	1
183B79F4	12	1	1	1	1	3	1	1	1	1	9	10	1
A2D716C4	12	1	1	1	1	4	1	1	1	1	10	12	1
D9D9673B	12	1	1	1	1	4	1	1	1	2	9	11	1
E83B79EF	12	1	1	1	1	2	1	1	1	1	10	11	1
F2F69224	12	1	1	1	1	5	1	1	1	1	10	12	1
36259ACB	13	1	1	1	1	5	1	1	1	1	10	13	1

[frollard]

Late to the party here...Frustrating that they don't expose more local (direct mqtt client) settings on the device when it's clearly capable. I'm tempted to set this up and spam the hell out of the api with no actual changes - just command it to turn the light on repeatedly to get the same status/command with a new nonce counter to compare against the checksum. With any luck it's something dumb like serial number * nonce mod some big prime. https://www.litter-robot.com/ca/litter-robot/parts/litter-robot-iii-connect-upgrade-kit.html Connect motherboard compared to https://www.litter-robot.com/ca/litter-robot/parts/litter-robot-3-open-air-main-circuit-board.html seems basically identical save adding an esp daughterboard. I wonder if they're just using it as a wifi bridge or if any work is being done on the actual esp. Probably a good serial debug test pad in the serial lines between those two...but above my budget to get one of each 😃

[mbafford]

I never did anything else with this project - just monitoring the communication was enough to provide the main value I wanted (notification when I needed to check in on the litter robot).

I've since upgraded to the Litter Robot 4 and the app and the robot itself have worked a lot better, so I never even tried intercepting the 4's traffic. I even have the Home Assistant integration setup and it works well. Ideally, I'd go back to a cloud-less approach like I used to have, but I'm pretty happy with it as-is.

But they could so-easily just provide an HTTP endpoint on the device, which I would definitely appreciate. Like you said, looks like they are just running an ESP daughterboard for the comms - at least on the 3.

Unfortunately, I didn't think to keep my upgrade board when I upgraded or I'd send it to you to poke at.