DaVinci Junior cartridge reset (Page 6 of 58)

I ran a variety of the numbers through an online CRC calculator just to check the lower bytes (as im not with my dev. tools atm) - and nothing seems to pop into mind. I tried CRC of the spool-length, big/little-endians, the lower bytes big/little-endians - no luck. 

However, its given (I think) that Page 21, 22 and 23 cannot -all- be CRC, as the upper 2 bytes does not change at all - its likely that we will see them change with a larger usage. The reason i never really suspected a CRC is that, the values change so little - Page 21 is in fact  0xE353 3354 in the first sample and  0xA42B 3354  in the second sample (note the 3354) - little change - indicating either only a 2byte CRC or a counter decreasing/a simple calculation.

Given page 21-23 are all lowered with usage (in this one sample), like page 20 is i would presume more samples would give a rough idea of what is happening.

Yearh, unfortuanetly it does not change much - if only it was page23 i had transcribed 0x7649B501 as 0x7649B4FE :-) then we would have some kind of match.

If someone else would have a go at the CRC/rot/whatever regular basics that would be swell :-)

Also tried looking for some AND/XOR or RoL/RoR routines;

Page 10: 0x86A0 = 1000 0110 1010 0000
Page 20: 0x39EC = 0011 1001 1110 1100
Page 21: 0x2BA4 = 0010 1011 1010 0100
Page 22: 0x45E4 = 0100 0101 1110 0100
Page 23: 0xB4FE = 1011 0100 1111 1110

Here is some photos from my teardown
there is hall sensor in the extruder motor that counts the filament.
If someone wants more photos, ill upload more

Do they use same motherboard on all models?
There is connection for heated bed thermistor,lasers,cameras and more

Removing the sensor will probably have an negative effect on how the software checks its own ability to print; I could be overestimating their coding-skills, but, if you have a sensor that checks for movement, and you do not use this check for anything, you shouldn't be coding at all :-)

Hi guys. Just get in to forum. I find that every layer printed printer sending amount of used filament to chip. Firmware counting filament every command G code E adding them together and after printing layer sending to filament chip. If job canceled sending amount from cancel  point. Sorry for my English

So if you unplug the power just before it's finished it won't count it?

Well, i think it could work...

I don't mean to derail progress so far, but I've been going about this in the opposite direction. I'm trying to find out how the 3W is generated - as well as how the NFC is written - from the side of XYZware.

I need somewhere to start so we don't duplicate progress. Simply removing functions that relate to filament counting and/or 3W generation will probably break the program when I attempt to recompile. However, if we study the logic of the application, we can probably duplicate this with our own software. Similar to XYZware Open Mod.

So far, I can confirm some things that have already been said in this thread:

CipherMode.ECB;
PaddingMode.PKCS7;

Base64 is still involved:

Convert.ToBase64String(inArray, 0, inArray.Length);

But curiously, this seems to change based on some attribute I haven't been able to link yet:

          if (str != "TagEJ256")
          {
            rijndaelManaged.Mode = CipherMode.CBC;
            rijndaelManaged.Padding = PaddingMode.PKCS7;
          }
          else
          {
            rijndaelManaged.Mode = CipherMode.ECB;
            rijndaelManaged.Padding = PaddingMode.None;

Funny enough, it also looks like they just doubled up their URL (instead of just once) in the key logic for this part:

byte[] rgbKey = !(str != "TagEJ256") ? Encoding.UTF8.GetBytes("@[email protected]") : Encoding.UTF8.GetBytes("@xyzprinting.com");

Again, a lot of this isn't new. Where should I be looking at to put the final pieces together?

I did see that! I was aware that you made the encoder/decoder and was validating what you found so far.

I still think it'd be particularly interesting to take all the DRM out of the XYZware app. That'd be a fun project & exercise just for the heck of it.

My ARM knowledge isn't quite there - so that's all yours.

As for the FW, did you check out some of the web calls in the code? There are a few in there that could lead somewhere. Also, I have to dig through my firewall, but I might be able to get a PCAP or at least the URL of the auto-update I had a few weeks back.

Just a thought; if the "remove some gcodes and the firmware do not write filament length to the NFC" works - then its surely just a matter of a firmware update from XYZware until that security hole is patched? I mean, they can get around that one pretty easily. Its not to be a downer, im just, well stating thoughts :-) Any thoughts on that ?

Workarounds for the "use the same NFC tag for multiple rolls" is gonna be a bit harder. They can't get around they shipped the NFC with that particular password. One way, is to detect "new" roll (entry password) and then set a new password rotating it ever now and then - changing the seed according to the public NFC information (which they change for every use). That means we do not just have to find one password, but a lot. Thats gonna be annoying.

Now, the obvious fix to that (for us), would just be to use a custom 0.5$ NFC tag with fresh filament info, for every self-made roll of filament. How they get around that one, would require some way of detecting if the NFC is real and official XYZware - that could be a tough on for them. Also, all it requires, is another cheap NFC, that they can't distinguish from the real thing, and boom - its game over.