Comparing HyperFFF and “traditional” G-Code for Raise3D machines I noticed that the only difference seems to be the M99123 command at the beginning of the file (identical for different STL-models):
M99123 /RKIIyAfrgVn63QgWjcMv3w/DQafsD84EnC8915R6MD0Ipw/VGrHawCYdCJaNwKoDQafsD84EnC8915R6MD/RKIIyAfrgVn63QgWjcMv3w/DQafsD84EnC8915R6MD0Ipw/VGrHawCYdCJaNwKoDQafsD84EnC8915R6M/RKIIyAfrgVn63QgWjcMv3w/DQafsD84EnC8915R6MD0Ipw/VGrHawCYdCJaNwKoDQafsD84EnC8915R6M/RKIIyAfrgVn63QgWjcMv3w/DQafsD84EnC8915R6MD0Ipw/VGrHawCYdCJaNwKoDQafsD84EnC8915R6MD0Ipw/VGrHawCYdCJaNwKoDQafsD84EnC8915R6MD0Ipw/DQafsD84EnC8915R6MD0IpD0Ipw/VGrHawCYdCJaNwKoDQafsD84EnC8915R6MD0Ipw/DQafsD84EnC8915R6MD0IpD0Ipw/VGrHawCYdCJaNwKoDQafsD84EnC8915R6MD0Ipw/DQafsD84EnC8915R6MD0Ip0Ipw/VGrHawCYdCJaNwKoDQafsD84EnC8915R6MD0Ipw/DQafsD84EnC8915R6MD0Ipw
Any clue how this G-code command works and what is written there?
Breaking news: first cloud based malware installed through “insecure gcode” causes 3D printer to 3d print legs and attempt to rise up against owner/operator
Implementing a G-code that allows abitary code execution sounds like a pretty dumb idea especially since these are “industrial” printers.
But I have to say it kind of looks like some sort of binary blob. What is interesting is that the section “DQafsD84EnC8915R6MD0IpD0Ipw/” is repeating.
Prefacing this, I have no idea, can’t find any information either, I’m just speculating for what it’s worth.
.What’s kinda interesting is someone posted an identical one to the prusa forums like 2 years ago, no responses unfortunately.I’m willing to guess it’s data, I’d wondered if it was unique per user but if you both have encountered it… don’t think that’s the case. I’m going to assume it’s sending a blob, vaguely reminds me of image thumbnails in gcode, but those are clear that’s what they are, maybe it’s some executable code that changes printer parameters or how the subsequent gcode is processed by the controller to support the HyperFFF mode.
Don’t love it personally, but I’m willing to assume they’re doing this way to obfuscate what’s happening because its proprietary rather than anything malicious. I don’t really have the tools or knowledge to really try to examine it further however, hopefully someone with that skillset is interested enough.
Edit: is this a cloud first printer? Also totally possible it’s just telling the printer to download something remotely to support that HyperFFF mode, again, can’t really tell, could be worth seeing what’s happening network wise.
Preview images are in a separate .data file.
is this a cloud-first printer? Also totally possible it’s just telling the printer to download something remotely to support that HyperFFF mode
The printer isn’t connected to the internet and the hyperFFF works. The HyperFFF upgrade requires a firmware update and a key file that is specific to the machine/serial number. GCode isn’t machine-specific.
The underlying software/“firmware” is Klipper.
What’s kinda interesting is someone posted an identical one to the prusa forums like 2 years ago
IdeaMaker is so different meaning it is a good idea to streamline it to Bambu or Prusaslicer. Hardware-wise the Raise is great but sadly this whole slicer situation makes them difficult to integrate/use in a mixed fleet as you need HyperFFF for these machines.
I hope Raise changes their mind and officially supports Prusa or OrcaSlicer soon as they are probably sitting on a sinking ship. Especially now with the Bambu H2D.
Yeah, didn’t think it was an image, just images in gcode are encoded.
I did find their github with a klipper config, but yeah, unsurprisingly it’s not there. You could see if it has documentation through the klipper console? I’m betting it’s not going to be in your klipper config unfortunately. Definitely leaning toward it being the portion that has the firmware validate the key and then set things up.
I might have the klipper source unzipped from the update file (7 zip noticed that there is more data). Where do I need to check/look for this M99123 implementation?
The update file itself starts with: “RAISE - MXC - PACKAGE…” MXC might stand for STM MXcube as Rais uses an STM32 MCU. Scrolling through the file it looks like it also contains some sort of files for YOCTO-Linux for an NXP chip which might be related to the display.
Also does Klipper still use Python 2.7 and other EOL packages that are 15 years old by now?
Looking at the key-file: It is a gzip which contains a USTAR which contains some sort of, I suppose, key: “RAISE - MXC - KEY _ 'C[…]”
I was looking through, generally custom macros are in the config folder, unsure if they’ve implemented it differently, here’s the Raise3D repo I found earlier, klipper has some code in c for the microcontroller stuff AFAIK with klippy in python, I’ve not personally dove into the code, just config and macro stuff largely.
Actually digging through a bit, there’s some gcodes in /klippy/gcode.py in the above repo I don’t see in the Mainline Klipper equivalent, like M9999, it might be a start, klippy lives on the host machine.
This is the base folder of the unzipped update.
differencing: WCH CH341 driver eve: AI chatbot scripts: boring scripts and a binary blob (.elf file: fdm_virtual_device)
Regarding the M9999:
else if(strcmp((const char *)rec_cmd[ptr].cmd,"M9999") == 0 ) { ansifo->main_cmd = SET_AUTO_TEMP_CMD; return SET_AUTO_TEMP_CMD; }For M99123 there is only one reference: https://github.com/Raise3D/Klipper-Raise3D-Pro3-Series/blob/97416850a18466eea04865f2c92503501841681c/klipper/klippy/extras/virtual_sdcard.py#L535