Automatic Litterbox Central

My CG120 running CatGenius beta firmware dumps the contents of the chip (RFID tag) on the cartridge in the slot to CG120 serial port. The contents of a depleted cartridge looks like this typically (all values are in hexadecimal notation):

Code: Select all

Unique ID: D0 02 0D E4 3F 56 69 67
Block 00  FF FF FF FF
      ..  .. .. .. ..
Block 04  FF FF FF FF
Block 05  00 00 00 00
Block 06  00 00 00 00
Block 07  00 00 0B 09
Block 08  00 3C 00 01
Block 09  00 3C 00 01
Block 0A  00 3C 00 01
Block 0B  00 00 21 08
Block 0C  00 00 21 08
Block 0D  CB D8 2A 30
Block 0E  CB D8 2A 30
Block 0F  DE E0 21 08
Block 10  FF FF FF FF
      ..  .. .. .. ..
Block 7F  FF FF FF FF
Block FF  FF FF FF FF

This chip is bears the marks of a ST-Micro SRIX4K-A4S, as I mentioned in this topic: catgenie/topic2967.html Block 5 and 6 represent the values of the down-counters, here depleted down to 0.Values of FF are assumed to be empty and therefore not used.

When inserted, the original CG120 firmware read the unique ID first, followed by block 0D. Then both counters (block 05 and 06) are read. Next block 08 to 0C are read and finally block 0F is read. This leaves block 07 and 0E unread, even though they do contain some data. I find that a bit strange.

I have dumped a number of chips now and block 08, 09 and 0A are always duplicates, so are block 0B and 0C, just like block 0D en 0E. Except for block 0E, all duplicates are read which seems a bit odd. I do not see any evidence of the anti-cloning or other mechanisms used not documented in the non-NDA data sheets.

Now I have also dumped the contents of a brand-spanking-new cartridge. It has never been in a CG120 with original firmware, so we can consider this to be a virgin cartridge. The contents of the RFID tag are as follows:

Code: Select all

Unique ID: D0 02 0E 2B 1D 8D 0D A9
Block 00  FF FF FF FF
..... ..  .. .. .. ..
Block 04  FF FF FF FF
Block 05  00 00 00 78
Block 06  00 00 00 78
Block 07  00 00 16 09
Block 08  00 78 00 01
Block 09  00 78 00 01
Block 0A  00 78 00 01
Block 0B  00 00 10 04
Block 0C  00 00 10 04
Block 0D  E4 CD F6 A0
Block 0E  E4 CD F6 A0
Block 0F  F7 AC 10 04
Block 10  FF FF FF FF
..... ..  .. .. .. ..
Block 7F  FF FF FF FF
Block FF  FF FF FF FF

The counter values in block 05 and 06 show 78 hexadecimal, that's 120 decimal, for 120 washing cycles.

Another tag produces read errors on block 10 to 7F while dumping the contents. The contents that can be read are below:

Code: Select all

Unique ID: D0 02 1A 1E 15 82 4E D5
Block 00  FF FF FF FF
..... ..  .. .. .. ..
Block 04  FF FF FF FF
Block 05  00 00 00 78
Block 06  00 00 00 78
Block 07  00 00 2B 09
Block 08  00 78 00 01
Block 09  00 78 00 01
Block 0A  00 78 00 01
Block 0B  00 00 0F 04
Block 0C  00 00 0F 04
Block 0D  8A 3D 72 BD
Block 0E  8A 3D 72 BD
Block 0F  FA 3C 0F 04
Block FF  FF FF 7F FF

This most likely means that the RFID tag doesn't support these block, probably because it doesn't have them. So I have removed the label and the tag looks similar, but it doesn't bear any markings. Some research on the internet shows that there's also a SRI512 chip on the marked, with 512 bit storage. That is 64 bytes, or 16 'blocks', similar to the dump above. So it's safe to conclude that new CG120 cartridges carry a SRI512 RFID tag. This would confirm the earlier conclusion that the blocks with a value of FF if them (or at least block 10 to 7F) are not used by the original firmware.

Finally I have also dumped the contents of the Maintenance Cartridge, also in virgin condition. This one too seems to have a SRI512 RFID tag because of similar read errors. The contents are below:

Code: Select all

Unique ID: D0 02 1A 1E 15 82 2C 9C
Block 00  FF FF FF FF
..... ..  .. .. .. ..
Block 04  FF FF FF FF
Block 05  00 00 00 04
Block 06  00 00 00 04
Block 07  00 00 2B 09
Block 08  00 04 00 03
Block 09  00 04 00 03
Block 0A  00 04 00 03
Block 0B  00 00 82 00
Block 0C  00 00 82 00
Block 0D  4F BC 12 25
Block 0E  4F BC 12 25
Block 0F  FB AD 82 00
Block FF  FF FF 7F FF

What's also noticeable on the new tags are the contents of block FF, the system area: The byte designated are 'reserved' contains a value of 7F, where it had a value of FF as expected on the SRIX4K. When going through the documentation of ST-Micro (http://www.st.com/stonline/stappl/st/co ... NP139=1200), only to two part numbers offer 512 bytes of memory. The first is the SRI512 and second is the SRT512. The latter version specifies to have bit 15 of block FF set (as in 1). A value of 7F has that bit cleared (as in 0), confirming that we have to do with a SRI512.

All of this together confirms that the CatGenie firmware doesn't use the proprietary non-cloning mechanism because that feature is only available in the SRIX4K tag.

Isn't the simple solution to just gather some of the same model RFID tag, program with 120 cycles, and replace the chip on an expended cartridge? From what you are saying, there's no digital signature or other authentication methodology used by the CG in reading a cartridge.

ku4zs wrote:Isn't the simple solution to just gather some of the same model RFID tag, program with 120 cycles, and replace the chip on an expended cartridge? From what you are saying, there's no digital signature or other authentication methodology used by the CG in reading a cartridge.

That won't work. As you can see, most of the tag is unused. Block 05 and 06 hold the counters and block 07 to 0F hold what appears to be 'random data'. But it isn't random data at all. Some of that data is a cyphered representation of the tag's unique ID, an authentication code.

Now the trick is that we don't know how a tag's unique ID is cyphered into an authentication code. We don't even know what part, if not all, of the data in block 07 to 0F is this code. So if a cartridge with a new tag is inserted into the CG120 and it reads and cyphers the unique ID, the resulting authentication code will not be found in the tag and the box will not work (at best).

I have compared a number of tag's and I'm getting a pretty good impression on the function of the data in each block. But I need many more tags to be validate these impressions. So if you have any empty cartridges, please save them for me and some day we might be able to program our own!

Where do I send them hehe

cassioac wrote:Where do I send them hehe

Send him a PM...

Have you tried reading it out one of the same cartridges out after a few uses? I'm curious to see which values change as it seems like the second byte in block 8, 9 and A seems to be identical to the number of uses remaining at least until it is depleted. I would hazard a guess that at most block D and F are being used for authentication of the device ID with a logical argument for only one of them as they are read out at different times. Based on how short the authentication likely is it's probably not impossible to figure out.

Bob wrote:Have you tried reading it out one of the same cartridges out after a few uses? I'm curious to see which values change as it seems like the second byte in block 8, 9 and A seems to be identical to the number of uses remaining at least until it is depleted. I would hazard a guess that at most block D and F are being used for authentication of the device ID with a logical argument for only one of them as they are read out at different times. Based on how short the authentication likely is it's probably not impossible to figure out.

I have many more dumps, but I decided not to publish them because of a lack of interest.

The second byte (probably together with the first) byte of block 8, 9 and A represent the capacity of a cartridge, the number of washing cycles it had when it was full. This enables the software to show the cartridge level in a relative matter. Most cartridges are good for 120 (0x0078) cycles, but early cartidges that came with the box only did 60 (0x003C) cycles. The maintenanance cartridge only does 4 (0x0004) cycles.

The amount of fluid used by the washing program is probably hidden somewhere in the tag too, perhaps even multiple times for different stages of the program. The number of decrements for a full and and automatic cycle may be in there too, even though software may decrement only on down-counter on an automatic program alternatively.

I'm curious why so many data fields are duplicated. It makes me wonder if data storage in the chip is that unreliable, of if they just didn't trust it, of if it's just poor programming.

I think the key is either in the Block F or in Block E (with D as a backup). I have already made XOR tables and tried obvious checksumming algo's but none came close to a solution. It's just too easy to make things very hard

I love the idea of figuring out the contents of the cartridge chip. I'd be willing to help. Anything new going on since May?

Steve

It doesn't look like it...