Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Unitree is a Chinese robot manufacturer specializing in advanced consumer and commercial robots. On Amazon, the human-like robot is 18K, and the dog-like robot is 4K. The post contains a lot of reverse-engineering information about the robot itself, but I was mostly concerned with the bugs; this was necessary to find a usable attack surface on the device. I'll fill in information about the device as needed.

The device has an AI chatbot. The file upload handler for this writes to a caller-choosen path with no check, leading to a simple directory traversal. The directory bashrunner simply runs shell scripts on behalf of our applications. By writing to the directory content_acquisition, a restart of the device will whitelist the file as valid and allow it to be executed in future runs. Initially, this required a hardwire connection to the Robot.

The next attack surface they reviewed was Bluetooth. The service 0xFFE2 is the generalized inbox for commands to be executed; this could be hit without pairing, but some of the commands are protected by an AES-GCM layer. For instance, the WiFi opcodes remain locked behind a valid incoming user.

Where does this AES key come from? An Api! How does the API authenticate you? Whether you have information that can be obtained over BLE! Using the decryption oracle, it will return the AES key, BLE MAC, and RSA-OAEP-encrypted data that only the cloud can decrypt. So, the credentials are just freely available. This can be used to unlock the WiFi opcodes.

One of the WiFi commands tries to generate a valid wpa_supplicant.conf configuration file. By using weirdly formatted data in the packet, it's possible to modify the configuration to force the Robot to join any WiFi network we choose. This requires a classic string-injection attack to change data that was not meant to be changed.

The next bug they found was a BSS buffer overflow caused by a large write to a static buffer in one of the BLE packet handlers. By overwriting a function pointer with system(), you can get command execution on the device pretty trivially. Although the system has PIE enabled, so they used the first bug to get the base address. It slightly feels like cheating to get the PIE address needed for RCE from another RCE bug?

Overall, a good set of bugs, and really cool reverse engineering! The article is a little long but reads like a love letter to their former self.