When a mission-critical piece of hardware suddenly stops working, the standard procedure is to contact support, run some diagnostics, and hope for a quick fix. But sometimes, the diagnostic tools provided by support open the door to something much more interesting.

Recently, my Revopoint MINI 3D scanner completely died. After days of back-and-forth with customer support, they sent me a Google Drive link containing a service utility designed for Windows, Mac, and Linux. They asked me to run a .bat file to extract logs from the device. What started as a routine troubleshooting session quickly turned into a deep dive into the scanner’s internal Linux system and hardware architecture.

Here is the story of how I gained full root SSH access to the Revopoint MINI, and what we found inside.

The Attack Vector: "Revotool"

The diagnostic archive contained an executable named Revotool. On Windows, it requires a dynamically linked library called 3dcamera.dll to function—without it, the tool is useless.

When I looked at the batch file support asked me to run, it became immediately obvious that Revotool was a powerful utility. Running the help command revealed three extremely dangerous capabilities:

pull [file path for pulled] [option,local path]
push [local file path want to push] [target path]
shell [shell cmd want to executed]

The shell command was the smoking gun. It allowed for arbitrary remote code execution on the scanner. However, there was a catch: the output of the shell command wasn't piped back to the terminal. To see the output of any command, you had to manually pipe it to a text file on the device and then pull that file back to your host machine.

Crafting the Payload

Rather than blindly running commands and pulling log files, I decided to establish a proper, persistent backdoor.

I wrote a custom shell script designed to handle the heavy lifting. The payload was simple but effective:

  1. Connect the scanner to my local Wi-Fi network as a standard client.
  2. Remount the root filesystem (/) with read-write permissions.
  3. Inject my SSH public key into /root/.ssh/authorized_keys.

Using Revotool, I pushed the shell script to the scanner using the push command, and then executed it via the shell command.

A few moments later, I fired up my terminal:

ssh root@<scanner-ip>

I was in. I had full root SSH access to the Revopoint MINI.

What Can You Do With Root?

Having root access completely unlocks the device. You have absolute control over the Linux operating system bridging the hardware and software layers.

As a quick proof-of-concept to verify my hardware control, I took over the scanner's RGB status LEDs directly via the sysfs interface:

# Turn off the red error LED
echo 0 > /sys/class/leds/led-red-err/brightness
# Maximize the green working LED
echo 255 > /sys/class/leds/led-green-working/brightness
# Maximize the blue booting LED
echo 255 > /sys/class/leds/led-blue-booting/brightness

Beyond playing with LEDs, root access allows for:

  • Custom Network Configuration: Integrating the scanner directly into enterprise networks or IoT setups.
  • Real-time Process Monitoring: Reverse engineering the proprietary scanning binaries and seeing exactly how point cloud data is processed.
  • Automated Scanning Pipelines: Triggering hardware scans programmatically without relying on the official desktop applications.
  • Hardware Debugging: Using built-in Linux tools (dmesg, i2c-tools, etc.) to diagnose raw sensor data.

The Root Cause: A Hardware Deconstruction

Despite having complete control over the OS, I was still looking at a broken scanner. Root access gave me a front-row seat to the failure via dmesg.

Opening up the scanner physically revealed a dual-board architecture. The main Linux environment runs on a Rockchip RV1126 SoC, which interfaces with a secondary co-processor, a Rockchip RK1608.

Looking through the kernel logs, the exact point of hardware failure became crystal clear:

rk1608 spi0.0: Request firmware preisp.rkl (version:rkceva4k2022121319370394) success!
rk1608 spi0.0: offset:ff0aa55,size:0,addr:12030200,wait_time:2
rk1608 spi0.0: timeout:c8,crc:0,flag:10,type:fe
rk1608 spi0.0: Read 0x12030200 is 0 != ff0aa55 timeout
rk1608 spi0.0: Download firmware failed!

During boot, the RV1126 attempts to push firmware (preisp.rkl) to the RK1608 over an SPI interface. For whatever reason, the RK1608 is returning 0 at memory address 0x12030200 when the system expects an acknowledgment value of ff0aa55. This timeout halts the entire initialization process, bricking the 3D capture functionality.

I don't believe the RK1608 chip is entirely dead. I probed the board with a multimeter and confirmed it is receiving 1.8V on its UART pins and 3.3V on its JTAG pins. I've attempted to connect directly to the chip via JTAG and UART to bypass the primary board, but I haven't had any luck—yet.

What's Next?

Interestingly, while doing background research, I discovered a forum post from a Revopoint employee publicly sharing the very tool I used, along with some other utilities and an SDK. Here is the Google Drive Link

If you are working with Revopoint hardware and want to achieve root access, I'd be happy to share the automation scripts I wrote. We are currently evaluating whether to open a dedicated GitHub repository documenting Revopoint scanner internals, firmware analysis, and these scripts.

I will be posting an update if I manage to establish a stable JTAG connection to the RK1608 and revive the scanner entirely. Stay tuned.