@Tom To reroute the commands we need to understand the routines in the firmware. We dont know which one is used for the chip. I didnt get my Pcikit3 yet, and it was not possible to make a backup of the firmware yet. So we cant fiddle with the firmware and write it back if something goes wrong. Oh Tim sorry. I think I get what you where saying. Intercept the commands Man in the middle attack.
If it never writes, the cartridge remains valid, just not matching the internal information. How the system responds is another matter. I have a dud chip. And 3D Systems replaced the cartridge. It simply doesn't recognize a blank chip as being installed.
Fully appreciate the need to interrogate the system's intent. I'm preparing for a hardware add-on with some logic. If we cannot hack the code, we could at least reroute the data. Very much looking forward to the disassembly of the firmware. And what I was getting at before about the "7 valid commands" - if we can monitor the line, it should have 1 of 7 sequences that could be interpreted into expected actions. If this command is not uniquely encrypted, it is access with a simple 8 bit word. With the reconstituting of the code, we will get a better view of what I/O is being exercised when. I have no quam with simply interrupting the device's intent. I did come across another annoying direction for the chip recognition routine. Apparently it knows when a new cartridge comes online and it forces the new cartridge install routing. Just another spider leg to look out for.
Couldnt we send a fake "Vup" signal to the printer so it thinks it has actually written the chip and it deletes the "pending write" serial from its internal list? in the end this is all about pulses, right?
Im also curious on the people that actually did the switch hack how do they solve the "memento" write of the 3% chip when they turn the printer back on???
What ive noticed is a HUGE difference of print quality between printing an item horizontal or vertical (x or y speaking, NOT z). Check this out, both prints at 200micron but one seems HIGH resolution, while they're the same file just positioned different (please note both items are really tiny, pics are with macro on): Also note the first pic, seems print head leaves a mark on them before finishing the print.... Definetly shitful gcode generator in these printers!
Hi everyone, i did find my logic analyser and sniffed on the cartridge. Maybe it can be useful for someone. File A is only the data which the Cube 3 is sending when no cartridge is present. File A+B is the communication when the cartridge is connected. The communication is only active when you click on "Cartridge Status" in the Printer Menu.
Oh i did find out something else. If you switch the connection on and off rapidly the cartridge status jumps to 99%. Will upload a youtube video.
The files just show a toggle going on. Marco/Polo? This may require a scope to see the voltage sags. This also means there is a different hook to this function. I suspect there is an voltage signal active all the time looking for a ground.
Oh, and the voltage sags will generate a binary data stream The data on the pins may be a sync signal.
I do have a oscilloscope from rigol, i could get you the stream. I also do have a smaller one the DSOQuad. Do you need it?
I think the issue with the switch has to be if you trigger the switch to the 0% one Cube tries to write but since its 0 already it refuses to write AND refuses to save the serial of the cart on its "pending overwritting chip" memory. Perhaps issuing 0% signals would be the way to go?
Sorry @eychei i was referring to a previous post where the switch hack was questioned in regards of the cube memorizing pending cart rewrites...
Oh ok, i didnt find that post. Another way of hacking the chip is by sidechannelattack. Here is a publication on hacking the chip we have: https://www.cs.bham.ac.uk/~oswalddf/publications/cardis_2015_sha1_paper.pdf I did read through the paper and think it would be possible to extract the private key with a Chipwhisperer. Actually I dont have the money to get one, maybe someone else has one on his bench? This was also tried for the Cartridges of a Stratasys Uprint, but was never published. I know the CEO of the company which is selling uprint filament cartridges and chips. He told me that it did cost him approximately 10.000€ to get the private key for the chips plus new pcb and manufacturing new chips. Is someone willing to pay 10.000€ or does have a chipwhisperer for me P.S. Can someone send me the full datasheet of the DS28E01 please.
Great find on the paper, eychei. Funny thing is, we don't need to disable or hack the chip itself. We just need to redirect the write function. I think you need to get to the other pins in order to get the code from the chip.
How much do the chipwhisperers go for? Re the switch thing, its the only explanation I can think of if people is using bulk filament over and over. The printer just does NOT store the failed cartidge write thinking the cart is empty already.... Given the principle of the switch hack is the printer does not check again the cartidge unique serial, i guess thats the way the hack is able to work. I'll check the other link now.
@bolsoncerrado Thx for the link. Where did we get the info that the serial of the chip is actually been stored somewhere? I know the Stratasys machines are doing this but I couldnt find any info on the Cube. Is this information really accurate? P.S. Chipwhisperer costs around 300$ and you have to get a USB-FPGA too for about 200$
@bolsoncerrado The link is not the full document i think. There are some references at page 3 to look at the "Full Document". Does anyone have access to a "Full" document? Or is this really the "Full" Document
****., BTW any1 considering a CubeX Duo or Triple? They look proportionally cheaper than the Cube3.... and u get almost twice the bed size and up to 3 extruders.... http://amzn.to/2j1RpdV
I have a dumb idea... what if we randomly pulled down the power on the line where no intelligent signal can get through after the initial handshake? We should be able to time "noise" to the signal after a certain interval. The datasheets are fairly specific for what is expected. There is an 8 bite limit to the initial data stream. We should be able to initiate an event after this packet is sent and responded to. The idea could work if the system only senses presence of the cart-chip and not the data stream. This can be done by testing the voltage on the pull-up resistor that controls this line.
If I am reading the datasheet correctly, the signal you captured in the vcd files are timing signals. "Tslot" should be the time between those pulses. What is reading the data is another good question. I do not understand handshaking for something this critical with timing. Do you know what the intervals were from the 0A 0B 0C 0D to 1A 0B 0C 0D to 0A 0B 0C 0D again? I suspect the leading numbers mean something like timestamp, but how to interpret?
Nice Idea. But how can we accomplish that? Another thing ysou mentioned was to just "filter out" the write commands. We would need a controller board which reads the data stream and echos it to the printer or the chip. Timing is important.
