You are not logged in. Please login or register.
SoliForum - 3D Printing Community → XYZ Printing Hacks & Mods → XYZ Printing Da Vinci Jr (w) / Da Vinci Mini (w) Hacking
Your reading my mind, Mr Clown. It is a 32megaBIT part, so if they pack up up tight, that's a lot of tag storage
Daniel456, any chance of putting in a clean eprom, load a filament and do a print and then dump and post the data? Real curious on how they store it.
By chance would you be able to easily tell how many tag ID's are stored in there?
I'm sure someone with enough free time on theire hands could look in to it, but why?
I did read the eeprom on the new printer before I started it up the first time, and the eeprom was totally empty, and I also tried an empty eeprom in the old printer and that worked out fine.
So it is possible for someone to start the printer with one tag with 100m, read the eeprom, start the printer again with 99m on the tag and read it again so find out where the data is stored, but again, what´s the point of that?
It´s easier to just reset the eeprom 
The eeprom is 4MByte and it does not take many bytes to keep track of the tags, all that needs to be saved is the tag ID and the number of meters left on the spool, and if this number increases the printer knows the tag has been altered (you can swap tags between printers and the printer don´t mind if the number of meters has decreased, I checked on my two Mini W´s)
Of course the eeprom stores some more data like wifi-settings and bed leveling calibration, but that´s not many bytes either.
Your reading my mind, Mr Clown. It is a 32megaBIT part, so if they pack up up tight, that's a lot of tag storage
Daniel456, any chance of putting in a clean eprom, load a filament and do a print and then dump and post the data? Real curious on how they store it.
If I get some time over tomorrow I could do that, although we have a two year old child and we are all sick right now, and we are expecting our second child any day now (expected date of birth by the end of next week.), so I can´t promise anything.
But if I end up in the workshop tomorrow and I´m waiting for something (I'm probably going to etch a couple of PCB´s and that takes about 10-15 mins) I will try to take a few reads off the eeprom.
No problem
Congratulations on the impending birth of your child.
I just started to think of something.
Is there any slicer or other software out there that can print on a Mini W via USB yet?
If so, does this software have the ability to change the calibration settings?
If that´s possible, that software could probably be reverse engineered and changed to write other sectors of the eeprom somehow, and thus might be able to reset the tag-info in the eeprom.
So someone with more software knowledge than me might be able to write a tag-id-reseting-program?
No problem
Congratulations on the impending birth of your child.
Thanks you.
I just started to think of something.
Is there any slicer or other software out there that can print on a Mini W via USB yet?
If so, does this software have the ability to change the calibration settings?
If that´s possible, that software could probably be reverse engineered and changed to write other sectors of the eeprom somehow, and thus might be able to reset the tag-info in the eeprom.
So someone with more software knowledge than me might be able to write a tag-id-reseting-program?
What I was looking for was how many Tag Id's can be store in the eprom. If we knew what that number was then we would know how many UID's need to be used in a printer before they can use the original one again. Not looking for any of the data being stored, just how many Tag Id's. I hop this makes some since.
My question about printing on the Mini W via USB is, does it have to be a Mini. Could you do the same thing with a JR? I believe they use the same software/slicer.
Daniel456 wrote:I just started to think of something.
Is there any slicer or other software out there that can print on a Mini W via USB yet?
If so, does this software have the ability to change the calibration settings?
If that´s possible, that software could probably be reverse engineered and changed to write other sectors of the eeprom somehow, and thus might be able to reset the tag-info in the eeprom.
So someone with more software knowledge than me might be able to write a tag-id-reseting-program?
What I was looking for was how many Tag Id's can be store in the eprom. If we knew what that number was then we would know how many UID's need to be used in a printer before they can use the original one again. Not looking for any of the data being stored, just how many Tag Id's. I hop this makes some since.
Ok, I can supply the data from a eeprom that you can look at, and if you can inject a bunch of tags in to it to try to fill it up, I can try and see what happens when I try to print with a tag that should make the 1st tag be deleted, if that´s your thought?
But even if that would work, either with real tags or spoofed tag-ID´s, what good does that information do?, do you want people to be able to use theire old real tags again by filling up the eeprom with fake tags?
Bozotclown1970 wrote:Daniel456 wrote:I just started to think of something.
Is there any slicer or other software out there that can print on a Mini W via USB yet?
If so, does this software have the ability to change the calibration settings?
If that´s possible, that software could probably be reverse engineered and changed to write other sectors of the eeprom somehow, and thus might be able to reset the tag-info in the eeprom.
So someone with more software knowledge than me might be able to write a tag-id-reseting-program?
What I was looking for was how many Tag Id's can be store in the eprom. If we knew what that number was then we would know how many UID's need to be used in a printer before they can use the original one again. Not looking for any of the data being stored, just how many Tag Id's. I hop this makes some since.
Ok, I can supply the data from a eeprom that you can look at, and if you can inject a bunch of tags in to it to try to fill it up, I can try and see what happens when I try to print with a tag that should make the 1st tag be deleted, if that´s your thought?
But even if that would work, either with real tags or spoofed tag-ID´s, what good does that information do?, do you want people to be able to use theire old real tags again by filling up the eeprom with fake tags?
No, I would not expect to do anything, but provide that information to people so they would know how many tags they would need for a full rotation.
I did update my last post. Thank you very much for your patience.
Is there anyone that wants to have a little chat with me and take me under their wing so to speak? Bit new, programmer, and having a mini w that is basically trash atm. Done som decompiling of XYZWare, found some protocol stuff (might hack together a python script to do some positioning and cleaning stuff without xyzware). A ton of stuff in XYZ-ware is GPL'd or lgpl'd stuff, which is, uhm, illegal considering the license of xyzware and lack of sources and attribution, but i don't think they will respond to my mails to them asking for a legal contact with them 
.
Mostly what I want now is to take a stab at the firmware of the thing. But, it seems like the upload-firmware functionality is seperate and deletes itself after an update. Anyway, just a friendly wave. I'll be going and reading like.. this whole thread tonight, and get up to speed.
Is there anyone that wants to have a little chat with me and take me under their wing so to speak? Bit new, programmer, and having a mini w that is basically trash atm. Done som decompiling of XYZWare, found some protocol stuff (might hack together a python script to do some positioning and cleaning stuff without xyzware). A ton of stuff in XYZ-ware is GPL'd or lgpl'd stuff, which is, uhm, illegal considering the license of xyzware and lack of sources and attribution, but i don't think they will respond to my mails to them asking for a legal contact with them
Mostly what I want now is to take a stab at the firmware of the thing. But, it seems like the upload-firmware functionality is seperate and deletes itself after an update. Anyway, just a friendly wave. I'll be going and reading like.. this whole thread tonight, and get up to speed.
Well, you are going to have a lot of reading to do. I have been following these threads for some time now and from what I have read the firmware itself is encrypted. I am not that knowledgeable in hacking stuff so I am at a loos and can only help out where I can.
I am in the process of trying to take what Daniel456 has posted and see if I can successfully read/write the eerpom in my printer. I am not as interested in writing back to it as retrieving the information on it.
Just dug around a fair bit to verify something. I am sure that it's old news, but.. they seem to have taken repetier-host and just disabled viewing all the functionality. That, plus statically linked to a whole slew of open source software against the licenses. Yay XYZ, just.. yay.
There is a TON of references, and all the buttons that are disabled have identical names to the one in the repetier software. Nefefel. Bastards. Just.. disabling a fricking donate button, and taking credit for other peoples work, and then relicensing everything? Scum.
You knew they were crooks when you found out about the TAG. at least I did.
Oh yes, but I just figured that they were the ordinary moneygrabbing shit. Taking advantage of the low price market ye ol' ink printer style.
Anyway, this makes me.. a little bit excited. Almost want to released a changed version of xyzware with the ads removed and ID checking removed, and hope that they send me a cease and desist . "Oh hey, you sent me this.. cease and desist letter.. for software you don't own? How does that work again?".
Could get expensive. But satisfying. Decompiling away .
Somehow this 'makes me think' that there will be rats in the firmware as well.
You know a lot of people have been asking if there is a port for the Mini to ramps. If you happen to come across the pin information you may want to make not of that for those people.
Taking apart what *looks* to be the firmware uploader right now. Just looking at the ascii strings though. Looks like they, *again*, statically linked the executable to perl + put the standard libraries in there for good measure 
.
I made a dumb, and fiddled with the slicer instead xD.
Bit interesting though:
my %cli_options = ();
{
my %options = (
#'help' => sub { usage() },
'verxyz' => sub { print "$XYZ::VERSION\n"; exit 0 },
'dbgxyz' => \$opt{debug},
#'debug' => \$XYZ::debug,
#'gui' => \$opt{gui},
'oxyz|outputxyz=s' => \$opt{output},
'savexyz=s' => \$opt{save},
'loadxyz=s@' => \$opt{load},
'savexyz64=s' => \$opt{save64},
'loadxyz64=s@' => \$opt{load64},
#'autosave=s' => \$opt{autosave},
#'ignore-nonexistent-config' => \$opt{ignore_nonexistent_config},
#'no-plater' => \$opt{no_plater},
#'gui-mode=s' => \$opt{gui_mode},
#'datadir=s' => \$opt{datadir},
#'export-svg' => \$opt{export_svg},
'merge|m' => \$opt{merge},
);
foreach my $opt_key (keys %{$XYZ::Config::Options}) {
my $cli = $XYZ::Config::Options->{$opt_key}->{cli} or next;
# allow both the dash-separated option name and the full opt_key
$options{ "$opt_key|$cli" } = \$cli_options{$opt_key};
}
GetOptions(%options); #or usage(1);
}
Some of those prints a config to a file. Then you can read it. Mostly though, its just rubbish default values?
Does anyone have a clue where the firmware uploader is? O_o
OK, so, think i found a 'debrick mode'. If you hold down the only button on the da vinci w, and then turn on the power and wait, eventually the button will become purple and the buzzer will keep buzzing forever oh god why. I cut the path on the logic board, because, shite.
Anyway. If you open the da vinci program, it reports that everything is fine, BUT, the firmware version is 1.0.1, so it wants to update. You can then do that, and it resets, but every single time you update it says that the version is 1.0.1 and wants to update.. etc.
OK, so, think i found a 'debrick mode'. If you hold down the only button on the da vinci w, and then turn on the power and wait, eventually the button will become purple and the buzzer will keep buzzing forever oh god why. I cut the path on the logic board, because, shite.
Anyway. If you open the da vinci program, it reports that everything is fine, BUT, the firmware version is 1.0.1, so it wants to update. You can then do that, and it resets, but every single time you update it says that the version is 1.0.1 and wants to update.. etc.
There is a button the the mini w? , I didn't know that.
How did you brick your printer?
magnusjjj wrote:OK, so, think i found a 'debrick mode'. If you hold down the only button on the da vinci w, and then turn on the power and wait, eventually the button will become purple and the buzzer will keep buzzing forever oh god why. I cut the path on the logic board, because, shite.
Anyway. If you open the da vinci program, it reports that everything is fine, BUT, the firmware version is 1.0.1, so it wants to update. You can then do that, and it resets, but every single time you update it says that the version is 1.0.1 and wants to update.. etc.
There is a button the the mini w?
How did you brick your printer?
The 'status' led is a button . You can mostly use it to say 'I am done' when your printer is finished. That's about it. Oh, and entering the super duper annoying debrick mode, if its meant for that.
I didn't brick my printer.. not yet xD. Mostly trying to figure out how to work with the firmware a bit.
Looking at the serial protocol right now. Would it be useful if I wrote some sort of reference for it / Parser? Looks like its 'meant' to be obfuscated, but the sourcecode of xyzware is pretty clear on what most of it does.
It also seems to be a block cipher, if its not something simpler, with ecb. Reason for why I think that, and I am not a security analyst, is that there are several blocks in the firmware files that are just the same pattern './á£,Ä.ìP.«)¾»…ë./á£,Ä.ìP.«)¾»…ë./á£,Ä.ìP.«)¾»…ë./á£,Ä.ìP.«)¾»…ë', each 16 bytes, which according to an infosec thing I watched while nearly sleeping once a couple of years back hint on that fact. './á£,Ä.ìP.«)¾»…ë' might be a section that is just 0 or FF repeated again and again.
It also seems to be a block cipher, if its not something simpler, with ecb. Reason for why I think that, and I am not a security analyst, is that there are several blocks in the firmware files that are just the same pattern './á£,Ä.ìP.«)¾»…ë./á£,Ä.ìP.«)¾»…ë./á£,Ä.ìP.«)¾»…ë./á£,Ä.ìP.«)¾»…ë', each 16 bytes, which according to an infosec thing I watched while nearly sleeping once a couple of years back hint on that fact. './á£,Ä.ìP.«)¾»…ë' might be a section that is just 0 or FF repeated again and again.
Look at threedub- py in gitlab by anthem. It has the serial protocol there. Needs some error recovery, but it works.
Maybe start a complete new thread on this subject. It looks like it will be a good one.
Oh man, thanks for the link. Looks cool.
OH GOD. I just found some seriously harebrained encryption keys. Not sure if they did the same dumb shit with the firmware encryption but.. god. Gonna try hacking together something with python. Not sure how safe it is to write here :').
(I am on skype, magnusjjj, also Tuxie#8691 on discord)
Two encryption routines so far: DES:
Des.new('12345678', DES.MODE_CFB, str.encode('87654321'))
aes:
aeskun = AES.new('@xyzprinting.com', AES.MODE_CBC, b'\x00'*16)
Those are just used in random parts of the xyzware program though. For at least the registration with xyzprinting. Not used on the firmware, BUT, i could just have screwed up .
Edit: There is also one used for the gcode, which zips it up, then encodes it with aes, @[email protected] with ecb if its a 3w file and not profile, otherwise as above.
Edit2: There is a whole section that recovers a private key from their api servers, but that seems to be related only to drm'd 3d prints, and anyway you need a specific file id.
Also, a key used in one location is 1234567890123456
SoliForum - 3D Printing Community → XYZ Printing Hacks & Mods → XYZ Printing Da Vinci Jr (w) / Da Vinci Mini (w) Hacking
Powered by PunBB, supported by Informer Technologies, Inc.
