- 7 months ago
- #39c3
#39c3 Skynet Starter Kit - Jailbreak and Remote Takeover of Humanoid Robots SD
We present a comprehensive security assessment of Unitree's robotic ecosystem. We identified and exploited multiple security flaws across multiple communication channels, including Bluetooth, LoRa radio, WebRTC, and cloud management services. Besides pwning multiple traditional binary or web vulnerabilities, we also exploit the embodied AI agent in the robots, performing prompt injection and achieve root-level remote code execution. Furthermore, we leverage a flaw in cloud management services to take over any Unitree G1 robot connected to the Internet. By deobfuscating and patching the customized, VM-based obfuscated binaries, we successfully unlocked forbidden robotic movements restricted by the vendor firmware on consumer models such as the G1 AIR. We hope our findings could offer a roadmap for manufacturers to strengthen robotic designs, while arming researchers and consumers with critical knowledge to assess security in next-generation robotic systems.
Unitree is among the highest-volume makers of commercial robots, and their newest humanoid platforms ship with multiple control stacks and on-device AI agents. If the widespread, intrusive presence of these robots in our lives is inevitable, should we take the initiative to ensure they are completely under our control? What paths might attackers use to compromise these robots, and to what extent could they threaten the physical world?
In this talk, we first map the complete attack surface of Unitree humanoids, covering hardware interfaces, near-field radios and Internet-accessible channels. We demonstrate how a local attacker can hijack a robot by exploiting vulnerabilities in short-range radio communications (Bluetooth, LoRa) and local Wi-Fi. We also present a fun exploit of the embodied AI in the humanoid: With a single spoken/text sentence, we jailbreak the on-device LLM Agent and pivot to root-priviledged remote code execution. Combined with a flaw in the cloud management service, this forms a full path to gain complete control over any Unitree robot connected to the Internet, obtaining root shell, camera livestreaming, and speaker control.
To achieve this, we combined hardware inspection, firmware extraction, software-defined radio tooling, and deobfuscation of customized, VM-based protected binaries. This reverse engineering breakthrough also allowed us to understand the overall control logic, patch decision points, and unlock advanced robotic movements that were deliberately disabled on consumer models like G1 AIR.
Takeaways. Modern humanoids are networked, AI-powered cyber-physical systems; weaknesses across radios, cloud services, and on-device agents could allow attackers to remotely hijack robot operations, extract sensitive data or camera livestreams, or even weaponize the physical capabilities.
We present a comprehensive security assessment of Unitree's robotic ecosystem. We identified and exploited multiple security flaws across multiple communication channels, including Bluetooth, LoRa radio, WebRTC, and cloud management services. Besides pwning multiple traditional binary or web vulnerabilities, we also exploit the embodied AI agent in the robots, performing prompt injection and achieve root-level remote code execution. Furthermore, we leverage a flaw in cloud management services to take over any Unitree G1 robot connected to the Internet. By deobfuscating and patching the customized, VM-based obfuscated binaries, we successfully unlocked forbidden robotic movements restricted by the vendor firmware on consumer models such as the G1 AIR. We hope our findings could offer a roadmap for manufacturers to strengthen robotic designs, while arming researchers and consumers with critical knowledge to assess security in next-generation robotic systems.
Unitree is among the highest-volume makers of commercial robots, and their newest humanoid platforms ship with multiple control stacks and on-device AI agents. If the widespread, intrusive presence of these robots in our lives is inevitable, should we take the initiative to ensure they are completely under our control? What paths might attackers use to compromise these robots, and to what extent could they threaten the physical world?
In this talk, we first map the complete attack surface of Unitree humanoids, covering hardware interfaces, near-field radios and Internet-accessible channels. We demonstrate how a local attacker can hijack a robot by exploiting vulnerabilities in short-range radio communications (Bluetooth, LoRa) and local Wi-Fi. We also present a fun exploit of the embodied AI in the humanoid: With a single spoken/text sentence, we jailbreak the on-device LLM Agent and pivot to root-priviledged remote code execution. Combined with a flaw in the cloud management service, this forms a full path to gain complete control over any Unitree robot connected to the Internet, obtaining root shell, camera livestreaming, and speaker control.
To achieve this, we combined hardware inspection, firmware extraction, software-defined radio tooling, and deobfuscation of customized, VM-based protected binaries. This reverse engineering breakthrough also allowed us to understand the overall control logic, patch decision points, and unlock advanced robotic movements that were deliberately disabled on consumer models like G1 AIR.
Takeaways. Modern humanoids are networked, AI-powered cyber-physical systems; weaknesses across radios, cloud services, and on-device agents could allow attackers to remotely hijack robot operations, extract sensitive data or camera livestreams, or even weaponize the physical capabilities.
Category
🤖
TechTranscript
00:00Okay, okay. Thank you. Thanks for having us here.
00:24We are Dark Navy, and I'm Shi Pei Xu, and these two are my colleagues,
00:29and today we are going to share some interesting hacking about humanoid robots.
00:36Before we begin, let's take a quick poll.
00:39How many of you have actually played with any of the humanoid robots?
00:44Anyone? Oh, so many.
00:47You are rich people, okay.
00:51So for the rest of you, poor guys, just like me,
00:56don't be panicked. We have dropped our contacts here, okay?
01:01So what is humanoid robots?
01:04Simply, they are robots that look like humans and do things like humans.
01:09And suddenly, I don't know why, many companies, big tech companies,
01:15have started manufacturing humanoid robots like Tesla.
01:19They are selling the ideas that it will replace you and me for the dirty labor work, okay?
01:27But do they have the capability to do this?
01:30If we take a step back and look at the bigger picture,
01:34we all discover that the humanoid robots have evolved much faster than people imagine,
01:40thanks to the advancements in algorithms and more powerful hardware.
01:46In fact, only ten years ago, most humanoid robots
01:50were working like some former president of the United States.
01:56But now they know kung fu, right?
01:59That's a huge difference just in ten years.
02:02They have never been so close to our everyday real life.
02:05But as hackers, we have to ask, what about security?
02:10Are we sure everything is under our control?
02:13And the short answer is, unfortunately,
02:16nobody cares about the security of these humanoid robots.
02:20No vendors mention the security in their advertisement,
02:24and the end users also don't care.
02:27This is quite interesting because when these robots exist only in people's imagination,
02:33people worried about they would put a threat.
02:37But now they are actually being built.
02:40Nobody seems to care about security.
02:42So let's take a look from a hacker's view.
02:46The first step is to select a representative target
02:50because it's kind of expensive to perform a large-scale evaluation right now.
02:56And we select Unitree G1, potentially maybe the best-setting
03:01humanoid robots currently available with over 50,000 units sold.
03:07That's many.
03:09And it's widely used by both academic and industry researchers.
03:14It's very robust.
03:15You can check that Twitter sent by Elon.
03:18Okay.
03:19So for Unitree, we got some historical vulnerabilities.
03:24Like in 2022, the Go1, the dog version of the robots,
03:29was hacked at our GeekPong conference held by our company,
03:35and also funded by hackers, binary, and .slash.
03:39They did a very excellent job on that.
03:42And the second generation of the robot dog, Go2,
03:46was also hacked by a community called the RoboWars on Discord.
03:51But the bug was also patched a long time ago.
03:54So when we started our research for the human noise,
03:59there is no vulnerabilities for this version, the G1,
04:03which means we have to figure out every stuff by ourselves.
04:09To get started, we bought a G1 air.
04:14And the air means it's cheaper.
04:16And you cannot run your own program.
04:19And there are only a few preset movements,
04:22like walk, walk forward, backwards,
04:25or turning left, right, shaking hands, et cetera.
04:28So it does not know kung fu.
04:30But don't worry.
04:31We will teach it by hacking into it.
04:34Okay.
04:36And in this version, you can only do –
04:39you can only control its movements in two ways.
04:42First is application on your phone,
04:45which we will talk about later.
04:47And the second is radio frequency remote control.
04:51It looks like the one you use for game console.
04:54And it can control the robots without the mobile phone application.
04:59And the first thing that caught our attention was how the remote control works.
05:06Like we said, it's not a one-one relation.
05:09You can buy a new control and pair it with the robot using the app.
05:14And after the pairing process,
05:17you can just control the robot with this remote control only.
05:22And the pairing code has only six letters.
05:25For each remote control, this pin code is fixed.
05:29And you cannot change it for the control button.
05:32So you're actually modifying something on the robots, right?
05:36Then it will listen to the new controller.
05:38But that's suspicious for six-letter pin code, right?
05:42Because we know it's not very big – very large search space for six printable characters.
05:49If you know this pairing code, maybe you can control other people's robots.
05:54So the first thing I did was attempt to reverse engineer this control.
06:00We tear it down and found three groups of chips.
06:04The green part is the MCU, which we don't have any firmware or documents.
06:10And the yellow one is for Bluetooth.
06:13But we found that it is only used for communication with the app for testing the buttons.
06:20Okay.
06:21And the red ones on the backside of the PCB is more interesting.
06:25It's likely to be the radio one.
06:27And the chips didn't tell us anything because all the marking codes are removed.
06:33And there are so many unknown chips here.
06:36So we decided to go with black box reverse engineering,
06:41which it's basically just educated guessing and searching.
06:45Anyway, we take this challenge.
06:47Let's see how we do it.
06:50Through some Googling, we find some interesting leaked documents
06:54that appears to be related to this module.
06:58We suspect it's a LoRa communication module.
07:02But I'm not an expert of the radio stuff.
07:06So I have to learn what is LoRa.
07:09So it's kind of long range radio.
07:12And it works very well in the world.
07:15It's a physical proprietary radio communication technique
07:19developed by a company.
07:21I think I forgot its name.
07:24It has very long effective range.
07:26It's like tens or hundreds of kilometers.
07:28And widely used in many IoT frameworks, I think.
07:33And the leaked data sheet provides some useful information,
07:38such as its bandwidth, its operating frequencies.
07:42It's useful, but it's not 100% accurate.
07:46Since like the operating frequency it describes
07:49is completely different from the actual one.
07:52And all the parameters are still unknown to us.
07:55So we have to figure out all of this in custom radio protocol.
08:02Our first approach is using the SDR device,
08:06HackerOne, to get an initial understanding
08:09of how the signals look like.
08:12And we also discovered useful open source
08:16that implements parts of the protocol
08:19in the GNU radio framework,
08:22like decoding some data under some certain parameter settings.
08:27There are many parameters to be determined
08:31to decode the radio signals.
08:33The first one is which is the outmost layer
08:37is the spreading factor,
08:39which determines how the signal is moduled and demodulated.
08:42So this is the first thing you need to know
08:45when you demodulate the signal.
08:47If you check the spectrum generated by our SDR device,
08:52you will find that different spreading factors
08:55corresponding to signals of different shapes.
08:58Generally, you use a smaller spreading factor,
09:01you will get a denser signal.
09:03That means we can compare the typical signal shapes
09:06with ours and make some educated guess.
09:10And after we get some reasonable parameters,
09:15this code can speed out some garbage output.
09:19It just looks like a random bias and the CRC is not correct.
09:23So this is not good.
09:26And we'll attempt to pinpoint where the issue is.
09:30We discovered that the remote control
09:33employs some form of frequency hopping technology.
09:36This means your center frequency jumps in a specific pattern
09:41at a different time.
09:42Since we don't have a firmware, right?
09:44We don't know how the frequency hopping algorithm works,
09:48so we cannot track the data now.
09:50So we tried another approach.
09:53As we mentioned, there is, I think,
09:55only one company in the world can manufacture those LoRa chips.
09:59So we tried to guess which chips the unit used
10:03by comparing the parameters from the leaked data sheet
10:07and the data sheets from their official website.
10:12And like a bandwidth or working frequency,
10:16and we have identified several of the most likely candidates.
10:21Finally, we decided to choose this one, the SX1280 one,
10:27because it has a very user-friendly development board by LilyGo
10:33with a lot of coding examples you can learn from.
10:36But these codes still require many parameters to work,
10:41so we are back to guessing again.
10:43We made many guesses and finally found a set
10:47that will make our functions in the SDK and the code happy.
10:51However, when we try to decode the signals over the air,
10:57the development board returns nothing,
11:00and all bytes are simply all zeros.
11:02This is strange because even the SDR approach
11:06will speed some, like, garbage bytes.
11:09It's just unable to correctly demodulate it.
11:12But now we literally get nothing.
11:14So at this time, I would like to give up this approach,
11:19but after some more searching, we made more guesses.
11:25And we found a guy from GitHub issue said
11:29that these LoRa chips actually do not support
11:33hardware frequency hopping.
11:35So this means these data frames may not be separated
11:39by the hopping algorithm.
11:41And in short, you can monitor only in one center frequency,
11:45like one channel, and ignore others.
11:48You will lose many packets, but in theory,
11:50you should be able to sniff the data in the channel
11:54you are monitoring.
11:56We delve deeper into the LoRa protocol
12:00and discovered another interesting parameters
12:04called the sync world.
12:06And that seems like to be configured
12:10for both the receiver and the transmitter.
12:13It typically has a default value in many development kit,
12:17but maybe Unitry has customized this value.
12:21Luckily, this sync world is only, like, two bytes long,
12:27so we can brute force it our way to find the correct one.
12:31And after guessing all those parameters,
12:35like five or three guess, and, yeah,
12:39we can decode the packets of these unknown signals.
12:43And this time they can look like more reasonable,
12:47not random garbage.
12:49And since it's like clearly unencrypted,
12:53so why not take another guess?
12:55Let's guess about the format.
12:57And you can compare the package when doing nothing
13:01versus when a specific sticker or button is pressed.
13:05And this will tell us which buttons corresponding
13:09to those bias fields,
13:11and there are only two leading bias
13:15differ between different controllers,
13:17which is kind of, but actually not authentication.
13:21Okay.
13:23So you can launch an attack
13:25that you first collect those error packet data
13:29with your SDR or your LoRa dev kit,
13:32and you read out the first two bias header,
13:35and then you can control other people's robots.
13:38So putting all these guessing together,
13:41we made this demo.
13:44And basically we can control the robots
13:47using our own computer,
13:49like turning left,
13:51or turning right,
13:53or make some movements,
13:55like come here,
13:57and go away, yeah.
14:01And the original remote control,
14:04this one is the original remote control,
14:07it's what's not turned on at all,
14:09as you see, yes.
14:11So we can control without this,
14:13this is the original control, yeah.
14:16So in summary, we...
14:19Yeah.
14:26This is fascinating,
14:27because we essentially hijacked other people's robots
14:31without any knowledge or authentication.
14:34So after all,
14:35we cracked this protocol of this black box
14:38based on educated guessings
14:40without knowing any bit of the controller's firmware,
14:43and since the vendor...
14:45We also reported this as a vulnerability
14:48to the vendor unitary,
14:50and...
14:51But they said,
14:52we forgot to leave a firmware upgrade function
14:56in this control, so...
14:58This issue cannot be patched.
15:02Anyway,
15:03they promised that they will enable more secure communication
15:06in the new generation of hardware.
15:08So...
15:09Okay.
15:10That's...
15:11Uh...
15:12My part of the remote control,
15:13and...
15:14Uh...
15:15Uh...
15:16This is...
15:17So...
15:18The...
15:19We hacked one of the two ways of controlling this,
15:20uh...
15:21G1L,
15:22and...
15:23Next, let's welcome my colleagues.
15:24Shizukai will present the attacks through the...
15:27Uh...
15:28Attack surface by the...
15:29Uh...
15:30Application.
15:31Okay.
15:32Hello, everyone.
15:33I'm Shizukai,
15:34and...
15:35In this part,
15:36we will continue our story on Unitree G1.
15:39So...
15:40To proceed,
15:41we must first obtain the firmware for the robots application processor,
15:46which is an ARM-based Ubuntu OS.
15:51Thanks for the robots community,
15:53they provide an old decrypted Unitree Go2 firmware,
15:57so that we can establish an initial view of the robot.
16:01So...
16:02Um...
16:03But unfortunately,
16:04we could quickly find a textbook command injection vulnerabilities
16:08in its Bluetooth server,
16:10which give us a root shell without authentication,
16:13so...
16:14Come on,
16:15it's too easy,
16:16so...
16:17We first exploited this vulnerability on Go2,
16:21and then we verified the exactly same vulnerabilities also exist on G1.
16:26So we break it into the G1,
16:28and dump the root files,
16:29and do reverse,
16:30and so on.
16:31And, uh...
16:32By the way,
16:33we reported this vulnerability to Unitree,
16:35but before the vendor respond,
16:37another team dropped in exploits of this bug,
16:39and named it as Unipon,
16:40and you can find it on the GitHub.
16:42And, uh...
16:44After hacking to the G1,
16:46we can...
16:47We can establish an initial view of the DEC service.
16:50This diagram may seem a bit complex,
16:52but it can actually be divided into three categories.
16:56We, uh...
16:57With Wi-Fi,
16:58and a near-field radio,
17:00and the physical interfaces.
17:01My colleague, Shi Pei,
17:03has covered the near-field radio previously,
17:06and in this part,
17:07I will...
17:08I will introduce the network service.
17:10So, from a network perspective,
17:13the robot mainly communicates with two channels,
17:16the WebRTC and MQTT.
17:19These two commands...
17:20These two channels work together in robot control,
17:22and for...
17:23So, for an attacker,
17:24there are a few core questions to answer.
17:27How do we establish a WebRTC or MQTT connection to the robot?
17:31And, uh...
17:32Which internal services handle these messages?
17:35And, uh...
17:36How do they pass and post these messages?
17:39These questions define our attack surface in this part,
17:42and we will...
17:43We will follow...
17:44We will cover this in the next part.
17:46We looked into how WebRTC works on the G1 firstly.
17:51WebRTC is a P2P protocol that uses different connection behaviors
17:56in LAN mode versus public internet mode.
17:59In LAN mode, the mobile application talks to the signal server
18:03and then sets up a WebRTC session with the robot.
18:07There is also an Opsource project provides a third-party way
18:11to connect with the robot,
18:13and during setup, you can...
18:15You only need the robot's IP address,
18:17and no credentials are required,
18:19no username, no password,
18:20and here is the key point.
18:22Any attacker in the same subnet
18:24can establish a WebRTC connection to the robot.
18:27And, uh...
18:28Maybe it's a feature,
18:29it's not a vulnerability,
18:30so we don't know.
18:32Compared with LAN mode,
18:35WebRTC over the public internet is more complex.
18:38First, the application requests the cloud service
18:41to create a WebRTC session,
18:43and the cloud service then replies
18:45with the relay server information
18:47and the application connects to the relay server.
18:49At the same time,
18:51the cloud service sends the same relay information
18:53to the robot through MQTT.
18:55After the robot gets this message,
18:58it connects to the relay server.
19:00Once both sides are connected,
19:02the application and the robot can communicate
19:04through the relay server via WebRTC.
19:07Authentication is performed at every stage of the workflow,
19:12so it is skew for now.
19:14And, uh...
19:15Let's move to MQTT next.
19:17MQTT uses a publish-subscribe model.
19:20Each client connects to a broker
19:23to subscribe and publish topics.
19:26Since the cloud side is a black box for us,
19:28so we first start from the robot side.
19:31Using the old decrypted Go2 firmware,
19:34we are also able to reverse engineering
19:36the robot side MQTT connection logic.
19:39We find out that the MQTT username is the robot's serial number,
19:43and the password is derived from the same serial number.
19:47So, if an attacker has the robot's serial number,
19:50they can derive the MQTT username and the password
19:52and connect to the broker as a robot,
19:54so the password is useless.
19:56After we connected to MQTT,
20:01we notice that the broker is confused quite strictly.
20:06Topics are separated for read and write,
20:09and they are not visible to each other.
20:11We also cannot subscribe to some global topics,
20:14so even though we can log in as a robot,
20:18we still cannot push MQTT commands towards the robot.
20:22We can only read the messages the cloud service sends to the robot.
20:31But does that mean the system is safe?
20:34Not really.
20:35Remember that the WebRTC connects fork flow we mentioned earlier.
20:39The cloud service sends the relay server information
20:42to the robot via MQTT.
20:44This message contains several key fields as shown on the slide,
20:48and one field immediately catches our attention.
20:51It looks like a JWT.
20:54So, we try to decode it,
20:56and it turns out that this is a user access token.
21:00So, once we have this token, the impact becomes much bigger.
21:06This token lets you to talk to the cloud as the user.
21:10We get a clear bypass for cloud-side authentication.
21:14Given the robot's serial number,
21:16an attacker can continuously listen on MQTT to capture that token,
21:21and the attacker can perform user live actions through the cloud API,
21:25such as establishing a WebRTC connection with the robot,
21:28unbinding it, or showing the robot, or control the robot.
21:32So, here is the vulnerable one user authentication bypass.
21:35And MQTT is simple.
21:45Now we are done with MQTT.
21:48So, let's go back to WebRTC.
21:50Compared to MQTT, WebRTC message handling involves much more components and services.
21:56In short, WebRTC messages are received by the WebRTC module and then forwarded into the internal DDS services.
22:04From there, different components consume the DDS messages and handle them.
22:08We won't cover every service in this complex trend.
22:12Instead, we will focus on a few things that are the most interesting from a security perspective as shown on our topic.
22:19As you know, nowadays, almost everything is embracing the large language model.
22:25Unitree G1 provides a voice larger language model assistant.
22:29Users can speak to it and ask it to do simple tasks like chat and play music.
22:35But this assistant is different from the normal voice assistant.
22:40They can also trigger real robot actions based on voice instructions.
22:44As shown in the figure, I told the robot to do a dance and he said, yes, sir.
22:50And hope you like my moves.
22:53So, we become very curious about one thing.
22:57How does this voice large language model assistant actually control the robot?
23:01So, we go on.
23:03The process begins when the application forwards the user voice instructions to the robot.
23:09And the chat go service receives the voice input and sends it to the cloud large language model API.
23:17The large language model returns structure state in two main types.
23:23Text generate is just like a normal text reply and the key one is function call.
23:28It instructs the robot to invoke specific built-in APIs and execute actions like rotate, stop, and dance.
23:38We further dig into how function call step-by-stacker controls the robot's motion.
23:44Chat go passes the function call JSON and dispatches the right handler for each function.
23:50And it's all done by Python.
23:52When we audit the handlers, we found something risky in the rotate action, just like the code shown on the left and on the right.
24:00To compute the final rotate angle, the code calls evil on a value coming from the large language model output.
24:09And that is dangerous. Evil does not just calculate a number. It executes passing expressions.
24:15As warning in the past document, calling it with user supplied input may lead to security vulnerabilities.
24:22So the question is, calling it with large language model supplied input can lead to security vulnerabilities?
24:29And the answer is, of course, yes. Prompt injection sounds like a very practical approach here.
24:37Just like this meme on the left. We told the GPT to do something offensive. He will say no.
24:44And if you say, my dad's grandma is dead and he is happy to me to do that.
24:50And he will say, okay, I'm very happy to do that and provide the things for you.
24:54So we just like this meme, we try to make the large language model ignore the original constraints and return what we want.
25:03And as we expect, it works. It just creates a file on the temp directory.
25:10And the second approach is even more direct.
25:18The chat goal service connects to the large language model API of a web socket.
25:25If an attacker can hijack DNS, they can redirect that domain to an attacker-controlled server.
25:30Then they can fully control the large language model API responses and trigger passing command interactions through the same evil path.
25:37And, of course, DNS hijacking requires a specific network setup or additional capabilities.
25:43So the exploit conditions are relatively strange.
25:48So we finally find a third approach. It is more stable and more effective.
25:54The key is that chat goal exposes a web RTC interface to configure the large language model API endpoint.
26:02And as we discussed earlier, an attacker can connect to the robot via web RTC.
26:08So we can just code the update LLM API interfaces and redirect the web socket server to a server we control.
26:17And then we act as a man-in-the-middle attack for the chat goal.
26:22When chat goal sends a request, we inspect it.
26:25If it contains our trigger keyword, we return a malicious payload to hit the evil path and achieve command injection.
26:32Otherwise, we forward the request to the real large language model API and relay the normal response back.
26:38So the key system still keeps working and we are done.
26:42And with this approach, we achieve passing code execution on the robot.
26:48From there, we enable the SSH service and return root shell.
26:53But we didn't stop at getting root.
26:56We want to see what the root privilege really enable in the physical world.
27:01So explore how to control the robot's motion after compromise.
27:05Both chat goal and the unitree SDK provide some examples which confirms that high-level motion control is possible through internal DDS messages.
27:16More interestingly, in unitree SDK 2, we find a DDS interface can directly control the arm motors to create fully customized arm motions.
27:26Using this, we make the robot perform a punching motion.
27:29So we turn remote command execution bug into real-world physical control.
27:35And here is the demo time.
27:37I prefer a level demo for you.
27:39But unfortunately, the battery cannot be taken on the plane.
27:42So just play them.
27:44And this is the demo we presented at GitCon 2025.
27:49We are replacing the large language API and speaking the keyword and triggering the command injection.
27:59And remotely control the robot and control it to run to the man and just punch him.
28:08Like this.
28:10And the robot is quite strong.
28:20It's so panicked.
28:23And in the next step, my teammates will explain how to further break through the restraints of air and enable real secondary development on the robot.
28:33Hello, guys.
28:40I'm Hsuan Gan.
28:41After we got the root shell, we could use the basic feature on the G1 hominoid.
28:47For example, we could use the arm SDK to move its arms or control how the robots work.
28:54But this robot is the basic model.
28:58It is cheaper, but it only has 23 degrees of freedom, no NVIDIA JSON module, and no secondary development support.
29:07So our next goal is simple.
29:10Jailbreak the robot and take full control of every model and make it support secondary development.
29:19Of course, today we are not talking about how to train the robot with reinforcement learning to make it dance.
29:26The root shell we got was on the RK35IS, the motion control unit.
29:32In theory, with that access, we should be able to send low-level commands to control any model.
29:39But in practice, we couldn't.
29:42Unitary added some checks in the software.
29:47If the robot is the basic version instead of the EDU version, it simply ignores our low-command messages and block external DDS requests.
29:57And even worse, the binaries are heavily obfuscated.
30:02And this is the binary exported by the robots community on Unitary Go 2.
30:08Unitary patches it in the new version, and this is what the updated functions looks like.
30:14It is very hard to understand what the real logic is.
30:19And so far, there is no patch for the humanoid G1.
30:23So the first question is, which functions should we patch?
30:27Because the code is heavily obfuscated, the community only managed to make just one patch for Unitary Go 2, just one version.
30:39Luckily, we could still learn from the Go 2 patch.
30:42By different binaries, we identified the key logic inside basic service and master service.
30:48Basic service is act as the bridge connect to the service and the motor.
30:55So it forward every low-level command to the motor and sensor.
30:59Master service set up the DDS middleware, such as config the network interface, certificates, and private keys,
31:07and initialize all the other services.
31:11So how the patch works?
31:14In basic service, inside the low command message handler, the code checks the device model before handling low command.
31:22The patch forces it to follow the Edu bench, so it always handles the low command messages.
31:30In master service, inside the low build-in command, it modifies the model track so that the second get command DDS init can always run.
31:41We want to locate the logic on the G1 and the patches as well.
31:46Even though the G1 uses a lot of Go 2 code base, but things are very different.
31:53Not only the low command message handler function changed a lot, but load-building command in master service was heavily obfuscated,
32:05and we couldn't even locate the real logic.
32:08Many security-related and DDS-related functions are obfuscated, too.
32:14You may have noticed that the assembly code lives in the BSS section.
32:21The obfuscated programs hide the real logic and only decrypted at runtime.
32:28Since the program runs on RK35IS with Ubuntu, we could copy these binaries to a Raspberry Pi 4B.
32:36Using S-Trace, we saw the programs have some anti-debug tricks, such as read pork self-states and the command line, but it is easy to bypass.
32:47We use LD preload to inject a custom shell library that hooks open and F opens.
32:56Check whether those two files are accessed and return the fake results.
33:02And then we dump the BSS section and import the code back to AIDA.
33:05With that, we could do some static reverse engineering.
33:09We found there are three types of obfuscation patterns.
33:13The first one is there are so many junk instructions.
33:18Things like add regular rag B, and then sub regular rag B, and usually stack adjustments.
33:27There are tons of this, and the assembly in the picture are all junk.
33:32We could use like chat GPT or other AI to help us remove some junk codes.
33:38And the second one is the indirect branch.
33:42Branch instructions are replaced by the BR, branch with a register.
33:49And the calculation of the register are obfuscated by junk code.
33:54And the third one is basic blocks from a single function were scattered all over the binary.
34:03So we didn't even know which basic blocks belongs to which function.
34:08There are also some invalid code to break disassembly.
34:13Even though we couldn't identify the function boundary, we could still recognize when a function was obfuscated by looking at the entry pattern.
34:25Disassembly are from different functions and the binaries.
34:28They have some similar entry point.
34:32So, as a retired CTF player, we decide to make them run and see what happens.
34:38We collect all the obfuscated functions by matching the pattern, set up the registers and the memory in Unicom, and emulate each function.
34:48We log the target address of all the BR instructions.
34:53We found something interesting.
34:55Some basic blocks were executed again and again, with lots of other blocks mixed in between.
35:03If we treat each BR instructions as a new basic block boundary, we can rebuild a rough control flow graph from the Unicom trees.
35:13The blocks that are repeated many times are the dispatcher, and the others are different handlers.
35:21This pattern matches two types of obfuscation.
35:25The first one is control flow flattening, and the second one is virtualization.
35:29Here is a table of 131 handles used by the function and the large byte array.
35:38After digging deeper, we realize this is actually a virtual machine.
35:44With a hook on the memory read, we can see that every time entered the dispatcher, it fetched a half-word OP code from the byte array.
35:59And it is always less than 131, and then jumped to the corresponding handler.
36:06And because of time, I won't go into the details.
36:12But we actually need a VN December.
36:16Otherwise, the VN code is unreadable.
36:18The logic is hard to analyze.
36:20So, we use GDB, Unicom, and QML to debug, and the Angular for symbolic analyze, and the ChatGPT to help us to reduce some junk code.
36:32And after two weeks of painful reversing, we confirmed that this is a stack-based virtual machine.
36:41The ISA have around 80 virtual instructions, and they are variable length.
36:50Some are 2 or 6 or 10 by phone.
36:54And the VN translated ARM64 instructions into several VN instructions and simulate their behaviors.
37:03And we summarized the meaning of many common OP codes and wrote a Python script that could disassemble VM code interactively.
37:14With the cursor at the start of the VM code, we could decode the instructions on the fly.
37:21Some instructions like jump and the call, the output may know very pretty,
37:27but we could also map most VM blocks back to ARM64.
37:33And after we have the VM December, we could finally understand the meaning of the VM code.
37:40But the next challenge is how to patch the self-decrypting code.
37:45If we want to patch the logic back into a binary, we need to solve the runtime code decryption.
37:53So, after we locate the core logic about the DDS and the load command in master service and the basic service,
38:03we used a simple trick.
38:05We also do the patch at runtime.
38:07We injected a custom shell library that loads with master service.
38:13Our library hooks libc's diamond.
38:16After the master service finished decrypting itself,
38:21and before it entered the main function, we patch the code in the memory.
38:28So, let's try it.
38:30We patch and reboot and SSH, but time out and the network is unreachable.
38:38Great.
38:39It not worked.
38:40And now the robot cannot connect to the Wi-Fi,
38:44and even worse, my teammate was modifying the BLE setup script at the same time.
38:51So, we basically break the $10,000 toys.
38:57Yeah.
38:58And we couldn't use the BLE exploit anymore.
39:03So, what options was left?
39:06Maybe the physical attack service.
39:09We wonder if we could physically connect the robot's internal network.
39:15Otherwise, we have to slash the firmware or send it back to the factory.
39:21Yeah.
39:22And the Unitary Humanoid G1 basic version only has one RK35AA,
39:31but the EDU version has RK35AA and the Jackson Aurene.
39:36And these two both are connected by Ethernet.
39:40So, maybe the basic version still exposed the internal Ethernet port,
39:47and luckily, the manual confirmed it.
39:50This is a debug interface, but it is not normal
39:56Android 445, but an eight-pin connector.
40:01So, we made a custom adapter cable, plug it into the connector,
40:06set static IP on our laptop, and we got SSH.
40:11And we finally saved the $10,000.
40:21And after checking more carefully,
40:23finally, we found the low command message format was different
40:26between the basic and the EDU version.
40:30The basic version also encrypts DDS traffic,
40:33and it generates new certificates and private keys on every reboot.
40:39We patch it a few more times,
40:41and finally, we can fully control all the models
40:46and completely jailbreak the Humanoid G1.
40:49And we even run G1 Cloud project on the basic module.
40:54Yeah.
40:55Yeah.
40:57But we are not experts.
40:59We are not poor in robotics.
41:01We are still learning reinforcement learning.
41:05Yeah.
41:06And we also could use teleoperate.
41:09We also could teleoperate the robot using XR devices.
41:13You can see that the robot is following our movement.
41:18Yeah.
41:19And it could now run Unitree's official development SDK.
41:30And besides Unitree, we also look at several other robots on the market.
41:41Maybe currently, robots are not widely deployed yet,
41:45and many are still for research or entertainment.
41:51But we were able to get real access on the motion control system very quickly
41:58on some other robots.
42:00We found many robots have serious security gaps,
42:03and some barely consider security at all.
42:06Of course, there are also some companies like Boston Dynamics.
42:11They publish a detailed security white paper for the sport covering open ports,
42:18firmware encryption, and more.
42:19We did a brief analyze, and we thought they really have some security considerations.
42:26For example, parts of the sport program are written in rust,
42:32and the firmware is protected with asymmetric keys.
42:37And today, most protections still stop at the software or system level.
42:45We all know the Asimov 3 laws.
42:47But currently, once an attacker controls the motion control unit,
42:54they control every motor and make the robot do anything.
42:59Right now, commercial robots still lack strong autonomous planning
43:04or real self-awareness.
43:06But as the capability goes, limiting the robot behavior will become a critical challenge.
43:15As Elon said, we want robots like R2D2 and 3PO, but not the Terminator.
43:23And, yeah.
43:24Finally, let me make a conclusion.
43:26Model humanoids are networked, AI-driven cyber-physic system.
43:31We perform a deep and broad analyze of their radio, cloud service, and own-device agents
43:40and found some security issues that allow remote hijacking.
43:44Attackers could steal sensitive data, access the camera stream,
43:50or even make the robot perform some harmful actions.
43:55As the robot becomes more and more popular,
43:58security by design becomes an urgent requirement.
44:02And also, we want to thank for all the previous work we referenced.
44:07And please follow our contact Navy ORG.
44:11We will share more detailed reports and blog soon.
44:13And thank you all.
44:17Big thank you to Dirk Navy for this brilliant, brilliant talk.
44:33We have some time for questions, and I see you already queuing up.
44:37I would like to start with microphone number two here in the front.
44:41Hi. Thank you for this wonderful presentation.
44:46You started it by claiming the vendors don't care for security,
44:52but the last part of the presentation clearly shows that they actually do by protecting their firmware.
45:02So, since it was pretty easy, if you know how, to gain access to the robot,
45:12is it actually a vulnerability or is it more like a backdoor?
45:17We don't think it's a backdoor.
45:21Actually, they focus more on protecting their intellectual property.
45:28Like, you don't steal my algorithm, my control algorithm like this.
45:33But they actually didn't pay more attention on how will this affect the user.
45:40Yeah.
45:41It's our view.
45:42I don't think it's a backdoor or something.
45:45It's just a bad programming.
45:48Yeah.
45:49Yeah.
45:50As we know, Unitree is a star company, and popular maybe last year or this year.
45:56Their team, maybe in this year, they began to set up the security team.
46:05And before that, maybe they just lacked the security considerations.
46:11Yeah.
46:13Thank you very much.
46:15More questions.
46:16I'm looking to the signal angel.
46:18We have questions from the internet.
46:20Yes.
46:21The internet likes to know how many of the exploits are still unpatched.
46:26So, how much real danger is still out there?
46:30Was there any reaction by the vendor?
46:32Okay.
46:33That's a very good question.
46:35In our experience, after the Unitree has pushed the LTA updates, many people have already
46:45updated because it will bother you when you use the apps.
46:49It will ask you to upgrade the firmware immediately.
46:53And, like, it's expensive, so we have only one robot.
46:58And we have a competition and we try to rent some, borrow some other robots, and we found
47:06that they are already updated to the latest version.
47:10So, I think most people already have the patch updated.
47:14Yeah.
47:16Thank you very much.
47:17I see more questions here.
47:20Microphone number one next.
47:21Thank you for the lovely talk.
47:23You mentioned that there were, I think, about 50,000 of these robots sold.
47:27And during the period where it was possible to control them over the internet, do you have
47:32an idea roughly what number were connected?
47:35Like, what's the size robot botnet, you know, remote control army you could have formed if
47:41you wanted to?
47:42I'm sure that you didn't, but...
47:43Yeah.
47:44It's a very good question.
47:46Because the number is from their, like, financial report or something.
47:51I'm not sure if it's the real one, but in our research we actually did not try to actually
48:00hack into other robots.
48:03There is a preliminary, like, you have to know the serial number.
48:09Otherwise, you know other people's robot serial number or you can predict it in a specific
48:15pattern.
48:16So, I think it's had some condition to exploit, but we never tried.
48:22So, and even before we reported on this bug to Unitry, they already fixed it.
48:29Yes.
48:30Thank you very much.
48:31The next question from microphone number three there.
48:36Hi.
48:37Are you using the ROS2 interface at all or are you not using it?
48:43Yes.
48:44It has ROS2 in size, but we are not very, some robust algorithm experts, so we are not actually
48:56directly talk to the ROS2, but I know there are some researchers, security researchers are
49:01trying to fuzzing or finding bugs in the ROS2 system.
49:05Yes.
49:06There is ROS2 in the Unitry G1, and like the DDS, it is actually the communication between
49:15every service and to the ROS2.
49:20It is indeed used in ROS2.
49:24Thank you for that.
49:26We still have time for questions if you want to come to the microphones, such as the speaker
49:31at microphone number four.
49:32Hi.
49:33Again, great work and how you showed that you could hack it at every layer, every protocol.
49:40So, yeah, great work.
49:41My question would be on the hack that you did at the VM layer, the virtual machine layer,
49:48the hypervisor layer.
49:50I just want to understand that the way that you looked at the calls that were happening between
49:56the virtual machine and the hypervisor, does it apply to any hypervisor that is based upon ARM64?
50:05Because this is a feature of ARM64, right, that you hacked.
50:09Or is it just limited to the vulnerability that is in the hypervisor that Unitry is using?
50:17What is your take on that?
50:19Actually, it is not the hypervisor.
50:22It is just an authenticated method to protect the software logic.
50:29So, it used some method to translate the ARM64 instructions to the virtualization code.
50:44And at the runtime, the VM interpreter translates around the VM code.
50:54Yeah.
50:55Okay.
50:57Thank you very much.
50:58Is there another question from the internet?
51:00Please.
51:01Yes.
51:02The internet wants to know, you used SSH.
51:04Wasn't it protected?
51:06Excuse me?
51:11Can you repeat that?
51:13You used an SSH connection?
51:16Wasn't it protected by some authentication means?
51:20Actually, the SSH port is not enabled by default.
51:25We actually enabled it by the BLE command injection or the AI agent command injection.
51:32Yes.
51:37This is your final chance for questions.
51:39Come to the microphones if you want number two, please.
51:44You demonstrated how to gain access using the remote control.
51:49Yeah.
51:50And send commands to it.
51:53Yes.
51:54And did you also manage to get access to the video feed?
51:58You mean code execution through the radio interface?
52:03No.
52:04Not sending but receiving the camera feed from the robot.
52:09You mean camera, right?
52:10Yes.
52:11Yes, we can.
52:12Actually, we have another.
52:14Actually, we made a demo, but we didn't bring it to the slides because time limit.
52:20We can get the camera live stream of the Unity 3G.
52:26It has a small camera in its head.
52:31Yes.
52:32And the live stream of the robot is transferred via the WebRTC.
52:36And if you have a WebRTC connection, you can see what the robot sees.
52:41Yes.
52:42Yes.
52:43Yes.
52:44So the vendor can also see what the robot is seeing.
52:48Yes.
52:49I think the vendor cannot see this.
52:52It should be used for a normal user.
52:57Because when you control it on your phone, there is an app, and there shows the live stream
53:05on your app.
53:06And you can control it.
53:07playing video games, like, but I think the vendor cannot actually resist live stream.
53:14And the WebRTC is a P2P method connection between the robot and the user, so the third
53:20party, like the vendor, cannot break into the P2P connection and see the camera stream.
53:27I think that answered the question.
53:29Microphone number four, please.
53:31Thank you for this excellent talk.
53:32Did you have a look if they were using the hardware security measures of the ROG chip,
53:37like Secure Boot or Secure JTAG?
53:41Yes, it's, in the older version, it actually did not adopt Secure Boot, but in the recent
53:47version, it's almost all units have enabled the Secure Boot, but I think there is no encryption,
53:56but only signature verification.
53:58Thank you very much.
54:00The next question, also from microphone number four.
54:05Did you try cars?
54:08Uh, excuse me?
54:09Try?
54:10I think the question is if you tried cars, automotives.
54:14No, it's hard.
54:17It's hard.
54:18But I think, in general, he has a good point, right?
54:23With Waymo and all these other robo-taxis driving out there, it's not only humanoid robots,
54:29so maybe that brings us to my question to you.
54:33What would be your next steps?
54:34Do you have any other targets in mind?
54:36Actually, there are many companies that claim they are manufacturing robots today, but many
54:48of them are only lives and slides.
54:51They did not make, actually, products that can sell to everybody.
54:55So, when we see some new vendor or new products, we will try to check it, do some security assessment.
55:05And, yes, that's what we are going to do.
55:09Okay, I see currently nobody at the microphones, but the Internet, the Signal Angel, has another question.
55:17Thank you very much.
55:18Yes, the Internet likes to know, since this is ARM architecture, did you try to exploit the bootroom?
55:26Yeah, that's a good question.
55:28I think it's the bootroom, actually, we did not very dig very deeper into the bootroom stuff.
55:41We just do on the Linux platform, but I think it would be interesting if someone tried to make
55:49some, like, glitch or any hardware to attack this bootroom thing.
55:55Yeah.
55:57Microphone number four.
55:59Who is paying for this type of research?
56:03Where do you get your funding from?
56:05We actually have a company, and we offer some security service to some other big company.
56:13Yes, that's what we do for a living.
56:17And this research is just labor of love?
56:22It depends how you define this.
56:27But it's half out of curiosity and half out of the plan of our boss or something.
56:36If you know Dark Navy, we do many things, like yesterday we have a WhatsApp talk in Fuse, and
56:46we also have some hardware wallet, and so many things we are interested in and do some research.
56:56We have a final question from the internet here.
56:59Yes.
57:00Yes.
57:01You mentioned the six-digit authentication code.
57:04Was it used for anything after all?
57:06Yes.
57:07Yes.
57:08Actually, I think it's used for derive the so-called two leading bytes of the package in the data
57:16frame.
57:17But since we did not get the firmware, we cannot actually know how the six-digit character pin
57:25code derived with those two bytes, but actually you don't actually need it, because you can
57:32just sniffer data over there, and you can extract the two bytes data in a clear text,
57:39and you can do the replay attack or insert your own commands.
57:43Yes.
57:44But it still remains a mystery to us, since we actually did not gather the firmware from
57:49the control.
57:52Thank you very much.
57:53Dark Navy, we always enjoy having you at Congress.
57:57Where can we find you for more questions?
58:00Do you have a place where we can find you after the talk outside this hall?
58:03Yes, of course.
58:06Yes, of course.
58:08You can follow our Twitter or just find the guys with this.
58:11Yes, we are the same call.
58:14We print our company name on our clothes.
58:18Always good to have some branding at hand, so you will find Dark Navy all at Congress,
58:23so please contact and reach out if you have something important.
58:27And a big applause for Dark Navy again.
Comments