Problems encrypting ABS_S cartridge

[Bald888Eagle]

I have a DS2433 EEPROM that I read the data from. When i run the decryption, I get:

Exception: invalid content checksum: should have 0x239e but have 0x29d3

Running parse_binary.py Traceback (most recent call last): File "./bin/parse_binary.py", line 124, in print("Material type: " + material_id_to_name[material_type] + " ("+str(material_type)+")") IndexError: cannot fit 'long' into an index-sized integer

I'm thinking this is irrelevant, as I'm going to completely overrwrite the data when stratasys-cli.py generates a new binary file with fresh data, so it doesn't matter what the old data was, and in theory I can start with a blank EEPROM.

So I forge ahead and supply the binary generation script with all of the parameters it needs to create a new binary file.

Material argument is ABS_S, material = "ABS_S" New Serial Number argument is F300000152D34D23

./stratasys-cli.py eeprom --output-file new_eeprom.bin --machine-type prodigy --eeprom-uid F300000152D34D23 --serial-number 38418508.0 --material-name ABS_S --manufacturing-lot EMPTY --manufacturing-date "2008-09-26 12:11:08" --use-date "2008-09-26 12:11:08" --initial-material 56.3 --current-material 56.3 --key-fragment 55aa55a73dae7dbe --version 1 --signature STRATASYS -o ./decrypted/canister.bin

And here's what I see to be my problem:

Running parse_binary.py Canister S/N: 595333825064730214718688711587204337155914865061188961283062879622117309308131205276049080320 Traceback (most recent call last): File "./bin/parse_binary.py", line 124, in print("Material type: " + material_id_to_name[material_type] + " ("+str(material_type)+")") IndexError: cannot fit 'long' into an index-sized integer

This is using the newest set of scripts, and I get the same problems using the old set, with a modified materials.py script to exclude the duplicate ABS_S and ABS_SS definitions.

[bvanheu]

I cannot reproduce the problem, what i've done:

1/ Get the latest revision from the repository 2/ Running your exact command:

./stratasys-cli.py eeprom --output-file new_eeprom.bin --machine-type prodigy --eeprom-uid F300000152D34D23 --serial-number 38418508.0 --material-name ABS_S --manufacturing-lot EMPTY --manufacturing-date "2008-09-26 12:11:08" --use-date "2008-09-26 12:11:08" --initial-material 56.3 --current-material 56.3 --key-fragment 55aa55a73dae7dbe --version 1 --signature STRATASYS

I get a valid file: "new_eeprom.bin"

What version of Python are you running? It only works on python 2.7 for now.

$ python2 --version
Python 2.7.7

[Bald888Eagle]

I know this is frustrating. I'm running Debian Wheezy, and Python 2.7.3. It's especially confusing and frustrating because I had the whole thing working when I wrote several regular material cartridges.

How do you know the new_eeprom.bin you are generating is valid? Are you using the stratasys parse_binary.py?

[bvanheu]

Thanks, i'll have a look tomorrow with your setup on a virtual machine.

I know it's valid because i can decrypt it using stratasys-cli ;)

Please don't use "parse_binary.py" since it's deprecated and i won't fix it. You should use "stratasys-cli.py" to generate your cartridge.

[Bald888Eagle]

Thanks so much, Benjamin. I wasn't aware of the deprecation - good to know.

Running ./stratasys-cli.py eeprom -t prodigy -e 6E000000A9EF9B23 -i ./tempData/eepromdump.bin -r, I get: Traceback (most recent call last): File "./stratasys-cli.py", line 229, in app.run() File "./stratasys-cli.py", line 47, in run args.func(args) File "./stratasys-cli.py", line 125, in command_eeprom self._eeprom_info(args) File "./stratasys-cli.py", line 168, in _eeprom_info cartridge = m.decode(machine_number, args.eeprom_uid, cartridge_crypted) File "/home/standard/Stratasys/_NewVersion/stratasys/manager.py", line 74, in decode cartridge = self.unpack(cartridge_packed) File "/home/standard/Stratasys/_NewVersion/stratasys/manager.py", line 130, in unpack raise Exception("invalid content checksum: should have " + hex(struct.unpack("<H", str(cartridge_packed[0x40:0x42]))[0]) + " but have " + hex(self.checksum.checksum(cartridge_packed[0x00:0x40]))) Exception: invalid content checksum: should have 0x239e but have 0x29d3

Am I supposed to get the whole traceback from that, or is the intent of the code to only provide the Exception message?

Also, it looks like I need to fix the casting: Running stratasys-cli.py Traceback (most recent call last): File "./stratasys-cli.py", line 229, in app.run() File "./stratasys-cli.py", line 47, in run args.func(args) File "./stratasys-cli.py", line 125, in command_eeprom self._eeprom_info(args) File "./stratasys-cli.py", line 168, in _eeprom_info cartridge = m.decode(machine_number, args.eeprom_uid, cartridge_crypted) File "/home/standard/Stratasys/_NewVersion/stratasys/manager.py", line 74, in decode cartridge = self.unpack(cartridge_packed) File "/home/standard/Stratasys/_NewVersion/stratasys/manager.py", line 137, in unpack serial_number = struct.unpack_from("<d", cartridge_packed, 0x0)[0] TypeError: unpack_from() argument 1 must be string or read-only buffer, not bytearray

I'll work on this as well, and see what I can come up with.

[Bald888Eagle]

OK, I spent some time refamiliarizing myself with the struct command, and just made sure everything from line 137-177 in manager.py had str(cartridge_packed), and the final output of stratasys-cli.py indeed looks valid.

However, when I look at the hex dump of that file, the ends of the first two lines are normally identical, since they are the block-encrypted results of the same exact date data. When I switch from ABS_S to ABS, this problem disappears, and the block-encrypted data becomes identical.

I'm guessing that there's something slightly off with the broken DES-CBC encryption of the data (which maybe shifts the data by a byte) and gives rise to the machine not being able to read the EEPROM. I'm not sure why stratasys-cli.py CAN read it as valid, but there it is. (nor do I understand why the parse_binary.py is now all busticated, but I guess that's all but academically moot)

Is anyone else seeing this change in their Hex data, or having their machine reject the new ABS_S cartridge? (ABS gives 0 - 0x0, and ABS_S gives 15 - 0xf)