With my previous printer collection (Anycubic i3 Mega, Dremel 3D45, Omni3D Omni200), there was always something which could be improved. Rather than spending time to modify a printer, I was looking this time for something which could provide good results just out of the box and still work fine under linux. This is why I decided to buy the Flashforge Creator 3 Pro.

Unfortunately, I had to lower my expectations quite soon: Despite the fact that the printer was mechanically well built, its firmware was of lesser quality. After experimenting a lot and using different slicing software, I never was able to control the left extruder cooling fan. Since I did not see something wrong with the hardware (including Mosfet Q7 which controls the left cooling fan), I began to realize this was probably a bug in the printer's firmware.

The gcode command did not allow independent left/right fan control with the M106/M107 command: The printer just did not accept the index parameter (T). Instead always the right fan was controlled.

Flashforge support was reluctant to do anything. But since more people on the internet had the same experience ¹⁾, I realized my only option was to reverse engineer the software and patch it in order to get a working printer.

All in all, the experience was quite educational. Things like getting console access, finding relevant files, understanding ELF files, the linking process, Ghidra, Arm assembly, patching and much much more. I could imagine there are people out there who plan to undertake something similar or are maybe just curious to see how this was done. So if you are interested please read further.

I will go into detail over the system and linux based software and explain how to debug, create binary files from assembly files and ultimately patch firmware by overwriting it.

Instructions about how to get root access, can be found on the internet.²⁾. You may also see following page to see what I used.

There are several great tools for reverse engineering. I highly recommend Ghidra. It is an open-source disassembler and can do a few things which make it so much easier to understand what is going on. It is able to create from the raw binary ELF file an abstract kind of C code. It automatically adds labels to variables and memory locations, is able to create function graphs which shows the flow of the code and much more.

It is important to understand the structure of ELF files. Questions I was confronted with was, rather how relocation happens upon linking process at startup, where in the file is it possible to put these patches and what can be done, if there is no space available (if the patch is larger than the original code.).

There are many great webpages and books available on this topic.³⁾.

Information about assembly, linker and linker scripts was very valuable as well⁴⁾.

Then, after understanding enough about the system, I was finally able to create a fix for the M106 and M107 commands. This was done by reusing the existing implementations of the M104 and M108 commands, adapting them for M106 and M107. Because the gcode functions in the main application work more or less like a proxy, forwarding incoming gcode commands to the motion controller, the essential change consisted of letting pointers in the M104 and M108 functions point to other memory locations where the characters 'M106' and 'M107' were present.
Then all what was basically necessary was to overwrite the existing M106 and M107 functions.
Because the new M106 function was larger than the original, it could not be placed at the original memory location. There all my studying about ELF files paid out well, because I discovered that due to memory alignment considerations at the end of the .text segment, there was just enough space to place the new M106 function. The new M107 function also was larger, but I was able to put that at the original M106/M107 memory location.

Let's begin with a hardware analysis of the system.

The linux based system (created with buildroot) consists of two separate processors:

• Allwinner V3s with ARM Cortex A7 CPU, with integrated 64MB DDR2 RAM as main processor. (Click here to see Allwinner V3s Kernel/system boot messages.)
• Nation N32G455 with a 32-bit ARM Cortex-M4 core as motion controller. (Click here to see serial communication between main cpu and motion controller.)

The main role of the Allwinner cpu, apart from providing a graphical user interface, is to prepare gcode commands from internal saved files and/or commands sent over the network to the printer and forward them to the motion controller. In the other direction, the motion controller sends data, like temperature information to the main cpu. This can be seen with connecting a serial cable to the corresponding RX/TX pins (J25) on the main board.

Please click on this link for more information about installing dropbear to get ssh working.

The main application can be started in debug mode. This will reveal many interesting messages on the terminal.

The latest official firmware from Flashforge (Oktober 2024) is version 1.4.0.

You can flash the spi flash memory (datasheet) via the main cpu using the sunxi-fel tool. One example can be found here.