Rooting the Creality Halot One resin 3D printer

I have finally decided to enter the 3D printing bandwagon. Having room for more hardware have always been the main inhibiting factor for not having done it longer ago. But with a little tidying up of the available space the impossible eventually became a reality. At least that was my reasoning, and the selection of a small resin printer seemed like an interesting choice in that respect, at least in what concerns the space occupied by the device itself.

Overview of the 3D printing experience

I knew that I was going for a slightly more challenging process than the more popular FDM (Fused Deposition Modelling). Not so much for the modelling and printing itself, but for the post-processing patience that it requires. As people familiar with the resin 3D printing (also known as stereolithography - SLA) know it, the post-processing tends to be a rather boring and messy task that requires dealing with somewhat aggressive chemicals in relatively large quantities.

I found in the market a printer that appeared adequate as an entry level model for someone like me, who is just starting the hobby. The available space was a factor, and I didn't consider a small print area to be a significant shortcoming. As such I went for the Creality Halot One. 

It's a relatively recent printer from a manufacturer which in a few years became one of the most popular names in the consumer space. I learned that the printer itself was well built and reliable, only lacking more in terms of documentation and detailed guidance for users indenting to use this 3D printing process for the first time.

After experimenting with it and going through some initial failures, I learned a few things with experimentation and research. For example, I found that the printing required more conservative parameters than recommended by the resin manufacturer. Especially when printing with a room temperature below the specifications.

Rooting the device

Motivation

But printing process aside, one thing that annoyed me was the lack of good software, especially the slicer. The official slicer for this printer is called Halot Box, but with all honesty, is buggy and limited. I basically gave up using it, and instead chose to use a combination of Chitubox for the slicing, and uvTools for verifying errors and converting the file format to CXDLP (the file format accepted by the printer).

The disadvantage however lied in the fact that neither Chitubox nor uvTools could directly transfer the files to the printer via WiFi. On the other hand Halot One does not open already sliced files for later printing. This left just one option, namely to put the files in a USB stick and manually open these in the printer.

As it is usual, I tend to have some technical curiosity in uncovering aspects of devices, when there is a practical purpose in sight. I realized that when the printer is on and associated to a Wifi network, it listens for connections on the SSH port 22. I soon also learned that when Halot Box software wants to send a file to the printer, it establishes an HTTP connection to the port 18188 which it tries to upgrade to a WebSocket session, apparently used for sending the file itself. I could not find evidence that Halot Box uses the SSH port for any communication with the printer.

When connecting via SSH with the printer, the user is prompted for a password. I tried a few common passwords without success. That is when I tried connecting the printer to the PC via USB (the latter features both a device and host USB ports). I used the device USB port, and found that the printer would be recognized by the PC as an adb device called "Tina". Also by analysing the contents of a firmware file that I found online, I could see that it is based on a Linux distribution called TinaLinux, which according to the project is a fork from OpenWrt.

This firmware apparently has no relationship to Android, but the fact is that it had an adb daemon (Android Debug Bridge) associated to the USB device port. I could confirm this by running the "adb devices" command on the PC, and seeing the printer listed:

Also,  by running "adb shell" I would see a login prompt:

Apparently having reached another dead-end, I started doing some searching, and came across a page about a model of the Xiaomi vacuum cleaner that also used TinaLinux, and coincidentally also had this adb feature. In that page, the author verified that in spite of not being able to login (because a password was prompted), he could still run the "adb push" or "adb pull" commands to send and receive files from any location on the device filesystem. I tried the same, and voilá, I could access any file, including the /etc folder.

Replacing the root password

With that in mind, I extracted the /etc/shadow file (where the root password is hashed), and tried doing what at first sight I thought it would be a long shot: 

1. download the original shadow file:

$ adb pull /etc/shadow

2. compute the hash for a password I knew.

Looking at the contents of the file, we can distinguish the information that we need to provide:

$ cat shadow

root:$1$0WwY78Jz$3NBUJkh2owBmcHB8uQrDf.:19014:0:99999:7:::

daemon:*:0:0:99999:7:::

ftp:*:0:0:99999:7:::

network:*:0:0:99999:7:::

nobody:*:0:0:99999:7:::

ntp:x:0:0:99999:7:::

sshd:x:0:0:99999:7:::

Considering the first entry (the root user), we have:

$1$ - defines the hash algorithm. In this case 1 stands for the MD5 algorithm

0WwY78Jz - the salt. We may prefer to preserve this in the new password we will define. 

3NBUJkh2owBmcHB8uQrDf. - the hashed password. This is what we need to replace.

In order to compute the hash, I used the openssl tool. We basically need to tell it hash algorithm, the salt, and the password that we want to hash:

$ openssl passwd -1 -salt 0WwY78Jz  <password>

3. replace the password in a copy of the file:

$ cp shadow shadow_orig

$ vi shadow

4. upload it to the printer via the adb push command:

$ adb push shadow /etc/

After doing this, tried the abd shell command again, entered my password, and:

voilá!

I was in, and had a root shell on the device. I could see that it was a not very stripped down linux distribution, as it loaded things that apparently were not very useful for the device, such as a uvc_camera process.

It also had several mount points, and a /mnt/UDISK partition with abundant (6 GB) of available space:

Enabling SSH login

I then tried connecting via ssh, but in spite of now having the right password, it would refuse remote logins. This was however an easy fix: opened the file /etc/ssh/sshd_config, and added the two flags:

PermitRootLogin yes

PasswordAuthentication yes

Saved the file and restarted the printer. After this change, it would still refuse the login, but this time because the password was marked as expired. Ran the command below, via the adb shell:

# passwd

And after updating the password, I was now successfully logged in via ssh.

Where to put the files for printing

I could see that in order to be visible for printing (in the UI), the files had to be placed under  /mnt/UDISK/ (in which case these can be opened by a single press from the printer UI), or under the folder /mnt/UDISK/pcFilePath. In the latter case, the several files inside it become visible in the UI, whereas in /mnt/UDISK directory, only a single .cxdlp file will appear. Actually the printer software will make sure only a single .cxdlp file is present in /mnt/UDISK/ directory. When another file (from the USB pen or from the other directory) is selected, it is actually copied to /mnt/UDISK/, and any other .cxdlp files are deleted from that directory. 

By simply establishing an SFTP session with the printer, and placing the file to be printed in one of these directories, I could achieve the equivalent function as Halot Box, albeit in a different way.

Additional findings

Doing a bit more digging on the system, I could find a few more things. There is for example a camera related process that does not seem to have any purpose (unless there is a hidden camera in the device 😃):

 1549 root      2932 S    {S80camera} /bin/sh /etc/rc.common /etc/rc.d/S80camera boot

There seems to be just a single main process for the printer application (started by a shell script):

root@TinaLinux:/etc/init.d# ps l|grep -i print

S     0  1934  1588  2932   436 0:0   20:02 00:00:00 /bin/sh /usr/bin/PrinterUI/cxpm.sh

S     0  1939  1934  336m  116m 0:0   20:02 00:01:46 ./PrinterUI

Another aspect is the fact that because this printer supports OTA firmware updates (using the WiFi connection), on the other hand they don't provide the update files in their website.

By looking at the log found in /mnt/UDISK/cxpmRunning.log I could find some interesting things:

One is that it prints the URL of where the firmware update file can be found:

Debug:1970-01-01 00:00:12:strCurTranslateImagePath = ":/image/SimplifiedChinese/"
Debug:1970-01-01 00:00:12:jsonObject[machine_type]== "CL89"
Debug:1970-01-01 00:00:12:jsonObject[version]== "1.135.0"
Debug:1970-01-01 00:00:12:jsonObject[appid]== "cl_h7_firmware"
Debug:1970-01-01 00:00:12:jsonObject[releaseType]== "Beta"
Debug:1970-01-01 00:00:12:jsonObject[otasz]== "ota-sz"
Debug:1970-01-01 00:00:12:m_printPara.regionId is 0
Debug:1970-01-01 00:00:12:jsonObject[ota-url]== "https://file-cdn.creality.com"
Debug:1970-01-01 00:00:12:machineInfo.fullPathOtaUrl is "https://file-cdn.creality.com/ota-sz/cl_h7_firmware/beta/cl89/latest.json?t=12800"

By following that URL, we get a json response which includes the URL of an actual update file. For example this one points to the latest update file at the time (interesting that the firmware is marked as beta in many places - except the UI or wherever the user can normally look at):

https://file-cdn.creality.com/ota-sz/cl_h7_firmware/beta/cl89/cx7_v2.202.28_app_v2.202.28_beta.tar.gz

There are other details in this log file, such as what appears to be motor control commands (there is likely a separate microcontroller commanded via a serial port) for moving up and down:

Debug:1970-01-01 00:07:13:m_printPara.layerThickness: 0.050000
Debug:1970-01-01 00:07:13:clicked
Debug:1970-01-01 00:07:13:SerialPortPrintFile::run: SerialPortPrintFile Task has starting.......
Debug:1970-01-01 00:07:13:getMotorMoveUpCommand is  G0 Z170 F1 D1 S1 H2 
Debug:1970-01-01 00:07:13:the machine name is CL60
Debug:1970-01-01 00:07:13:getMotorMoveDownCommand is  G0 Z170 F1 D0 S1 H2 
Debug:1970-01-01 00:07:13:the machine name is CL60

Another log entry that caught my attention was this:

Debug:2022-01-07 19:20:59:____________modelName________: "/mnt/UDISK/boneco de neve.cxdlp"
Debug:2022-01-07 19:20:59:initialization____________________________________
Debug:2022-01-07 19:20:59:recv printId: {   "dProgress":   0,    "curSliceLayer":    0,   "state":     0,     "printId": "local_2022010719205908149442"}
Debug:2022-01-07 19:20:59:printFile exit_______________________________printFile exit
Debug:2022-01-07 19:20:59:send the printId  "local_2022010719205908149442" to creality cloud!
Debug:2022-01-07 19:20:59:property_payload: {"printStartTime": "1641583259"}

It appears to suggest that information about a print was being sent to Creality cloud. In this case the .cxdlp file created by me, which was going to be printed. If this means that the actual files to be printed are being sent to a cloud in China, I don't yet know, but is something that probably deserves some more investigation. I personally don't mind that my useless prints are shared with someone else, but I don't think that users in general would be happy to know that their files are silently being shared with some company in China..