I think getting a chipkit would be easier then trying to emulate the code with qemu. But if you could get it working it would be awesome. We could run everything in the emulator and test the code before flashing. Maybe Geezer70 can help with the SPIs and ICs he can run the code on his development board already.
When you get the *.hex file loaded in MPLAB look at the C3_peripherals, all of the register assignments by address are listed. Are you familiar with how the PIC32 does I/O on its Ports? It is not at all like an Arduino or other dedicated I/O chips. I have 3DS firmware running on the WF32. However, because I have no HID to control it, it just sits fat dumb and happy waiting for a command. I haven't been hacking the SW lately, more into coding and decoding the G-Codes, which works quit well. Glad you guys are poking me. I needed inspiration to get back into whacking the SW. Especially with IDA. L8R G70
The main problem with the g-codes are that you can't control the filament cartridge. The steps of the extruder are counted. So g code is only helpfully for using simplify3d or other slicing software. The only problem i see with cubeprint is the support generation which can be done with another software like meshmixer. It will generate support as a second file and you can change the extruder for the support structure in cubeprint. Is it possible to connect the cartridge to your chip kit? I think we could hack the original software to write the cartridges like we want. How about changing the step counts to be negative for the extruder ?
Can someone plug in a USB Cable on the side of the Cube 3 and try to get into bootloader mode. There is a software in the Cube Print installation directory called HIDBOOTLOADER.EXE. If we can connect through that, firmware backup and flashing will be easier.
Another thing I did find out is that Port 30304 is open and used for file transfer. Protocol is BEEP. Just connect it with putty or other terminal program on Port 30304. Send the following command: {"header":{"msg_type":1,"msg_method":1,"version":1},"payload":{}} You can vary with the code and get other messages back, like extruder Temp and Cartridge status etc. I am using MobaXterm. To send the command copy paste the command from here hit Enter Key on your keyboard a "^M" command will show up, then press CTRL+ENTER to send the command. ^M is carriage return.
Thanls for sharing all hacking guys! Would u mind crossposting these to Cube3 too? We have some tech savy people there too perhaps we can join forces Also the wiki is set up and running in case you wanna share your findings re the mobo and such i plan to dissassemble a brand new unit and take hi res pics of it too, just for the rest of people inclined to hack it evenn more. Any of you running 3rd part y filament care to share pics of their cart setups? Any of you foiund out if the LCD is propietary or open market?
Connected w/Putty Raw port 30304 i get: {"header":{"msg_type":3,"msg_method":0,"version":1},"payload":{"error_code":101,"error_category":1,"error_msg":"Invalid header"}} ^@ refreshes the above I never used BEEP before interesting..... See what I mean? Gimme, GIMME, GIMME...Lol
eychei asked:"Is it possible to connect the cartridge to your chip kit? I haven't tried a direct connection to the Dallas Chip in the Cartridge. However, it uses SHA256 so without the response key I would only get garbage. Different conversation: I tried length ".01" in the header and trailer of the G-Code and seemed to not de-increment filament used. I'll try with larger print, if I can get thru it without a cartridge jam...POS
Actually i tried simplify3d with that option too. It seemed to me that the cartridge amount wasn't changing. But didn't try a longer print yet. What i meant with connecting the cartridge was that when you use the original firmware it should also write to the chip without us knowing the key. This is also used in software keygens. Just change the code that it splits out what you want.
@eychei I've tried getting into the Boot loader using the same method as used on the Cube 2. I'd have to Google it again but it was something like hold the power key down while pluging in the USB, then release the power key. Anyway didn't work. I'm going to try your find on the chipKit next. Are we having fun yet?
Actually i am having fun with this. But I do have work and other stuff going and my time will be very limited soon. I know everyone has the same thing going but we need to push forward. I did ask the stratahackers group for assistance. Maybe we have to mobilise our connections and friends more.
What you could try on the chip kit is the telnet port. This would be much easier if it works your firmware works
"What i meant with connecting the cartridge was that when you use the original firmware it should also write to the chip without us knowing the key." I understand what you meant. But, from what I've read about the key exchange the Chip is master and the printer is slave, Printer to chip here's my key chip to printer here's the key for encryption Printer to chip here's my new key Chip to Printer Ok we'll talk Printer to chip here's my encrypted data. I does this for every exchange of read, write or verify Don't hold me to the above it's been a couple of months since I was into it. I think I'll try a port monitor using an Adruino as a logic probe. I'm going quiet for awhile lots of things to try. Thanks for the good info and pokes. Email me to ring my bell.....
Oh, I see you are having fun! That's great! By the way, who can tell me, where are cartridge chip readers connected?, Also, what is connected to I2C bus and SPI 1 bus? Would be great for me to know.
When you get to be my age, this IS better than sex, literally... I know the I2Cs are used to communicate with the cartridge chips. Just don't know without a schematic. The I2Cs would have to be connected to a Dallas Chip like a DS2465. The chip on the cart is a DS28E15. Hope this helps. L8R, Over and Out....
Hello, can someone please verify which chip is on the cartridge. Is it a DS28E01-100 or is it an DS28E15. The original posted of this thread statet that is a DS28E01. Please can someone verify, maybe also take a picture of the chip. Thx
Glad I started reading that tech sheet on the chip. There may be a hole in the system worth noting below. If we can get the bias voltage up high enough, it can't write. What do you suppose the system will do in this case?
Hmmm. could be something. What does the datasheet say about Vpup and Vtl? There was a hack on the older cartridges, if i remember correctly, they used a diode to block the chip from writing.
I'm going at this similarly... but the Cube 3 is unique as a lot of Cube X and cube 2 hacks did not transfer. They are using something that pulls down the signal. If you make sure it never pulls below RPUP-V during a write command, it shouldn't be able to write. However, it does need to do a handshake. The second part of the equation is still to have the system forget what cartridges it saw.
You're correct. My bad, Fat fingers.... Pulled one off a Cube 3 cartridge to verify and read the print stamp on the back of the chip with a microscope. Absolutely a DS28E01.
Another note: we should be able to intercept these commands... Do you suppose this part of the data stream is also protected? If not, it is a quick 7-place lookup table for a very simple hardware attachment. Just pull the ground pin up to RPUP levels. Even simpler may be to reroute a command. I suspect MATCH ROM is the write command. Just replace MATCH ROM with SKIP ROM. And to make sure, also reroute the overdrive signals. https://datasheets.maximintegrated.com/en/ds/DS28E01-100.pdf
But if the system doesnt get the cartridge to write, the cartridge serial can stay in the system. It will never get write the cartridge to zero. What you say is only true if we decrease the filament counter and can reset the chip to "full". I just testet an led, didnt have anything else Didnt work, as expected. voltage drop is to high.
