Accessing the watch software

To figure out how the Xplora worked, the first thing we needed to do was gain access to its software.

Browsing through the menus on the watch revealed it was running Android Nougat, and that it had a Qualcomm Snapdragon Wear 2100 processor. As with any Android-based device, getting access as root is a good place to start. Root access would allow us to browse through the file system and look at the code it was running. With root, we would also be able set up a man-in-the-middle proxy and inspect its network traffic and communication.

Enabling root access on an Android device usually starts with modifying the file system. If we wanted to do this, a USB was going to be helpful. Though after a quick look at the USB cable that came with the Xplora, it was apparent we needed something different.

Some light soldering and two data lines later, we had a functioning USB cable.

Qualcomm chipsets have an “EDL” mode, short for ‘emergency download’. Basically, this is a feature that allows manufacturers to flash new firmware to a device. It also conveniently allows you to download everything that is stored in the device’s flash memory. Using EDL mode we could take a snapshot of the device’s storage, inspect its contents, and make the necessary modifications to gain root.

We found that holding both buttons on the side of the watch forced it into Android’s fastboot mode. From there you could issue the “fastboot oem edl” command to enter EDL mode. Alternatively, there are special USB cables that can be used to accomplish the same task. A quick Google search for “edl cable” returns a number of options.

We used a somewhat interesting piece of software called Miracle Box that allows you to upload and download data through Qualcomm’s EDL interface.

After reading the flash storage, Miracle Box saves each partition as an individual file. These partitions can be easily modified in Linux with the standard mount utilities. Editing the build.prop file in the system partition allowed us to enable the Android Debug Bridge (ADB). It was as simple as uncommenting a configuration option left in by the watch developers:

We uploaded the newly modified system partition, booted up the watch, and root!

Investigating the apps

The next step was to start looking through the apps installed on the watch. Listing all packages with the “pm list packages” command returned a total of 90 applications. As you would expect, most were related to the Android OS or Qualcomm.

However, 19 of the apps were authored by the original equipment manufacturer Qihoo 360, the earlier mentioned technology company based in China.

It was a bit surprising to us that none of applications on the watch appeared to be authored by Xplora themselves. After some light research we discovered a nearly identical watch for sale in China, sold directly by Qihoo 360.

The watch sold directly from Qihoo 360 is branded as the “360 Kids Guard”. Googling this term results in pages of articles on the product dating back as far as 2013, and the watch brand is also mentioned in past Securities and Exchange Commission (SEC) filings for Qihoo 360 Technology Co Ltd.

A browse through the Terms of Service for the Xplora App also makes several references to a company named “360 Kids Guard Co., Ltd.”, including them being a data processor:

This led us to the conclusion that while Xplora had developed their own backend server infrastructure and parental companion app, the majority of the watch itself was developed by Qihoo 360.

Qihoo 360

Qihoo 360 and the US government have a documented history, with accusations that include foreign espionage and imposing export sanctions.

In June 2020, Qihoo 360’s Chinese and UK business entities (Qihoo 360 Technology Company and Qihoo 360 Technology Co. Ltd. respectively) were added to an export sanctions list by the US Department of Commerce, thereby placing restrictions on the companies from using exported US technology in their products. As documented in the official records from the Office of the Federal Register, it’s not revealed exactly why they were placed on the list, but the official wording is “there is reasonable cause to believe that these entities pose a significant risk of becoming involved in activities—the procurement of commodities and technologies for military end-use in China—that are contrary to the national security interests of the United States.”

Meanwhile in March 2020, Qihoo 360 published findings accusing the CIA of an 11-year espionage campaign against several Chinese industries. The report cites evidence of the CIA hacking toolset "Vault 7" that was leaked in 2017.

A backdoor for covert surveillance?

After poking around a bit, we noticed a suspicious looking package APTly named “Persistent Connection Service”. The application starts automatically at boot and iterates through all applications installed on the watch. As it goes through each application, it creates a list of intents that it can call. The Qihoo 360 code calls these “rules”.

In Android, intents are a messaging framework that allow one application to talk with another. Think about when you click a link on your phone, but somehow it magically opens Facebook. That’s done through intents.

The code above is part of the iteration process that builds these rules, and conveniently prints out debug information to the Android system log as it runs.

Reviewing the Android log, we can see that the Qihoo contact application has several intents related to wiretapping – namely WIRETAP_INCOMING and WIRETAP_BY_CALL_BACK. These have been added as rules to a component of the persistent connection service called the “command dispatcher”.

In essence, this part of the code is searching through the device to determine a list of possible commands it can call.

Now of course a command called wiretap got our attention. Further digging revealed a collection of suspicious, surveillance related commands:

com.qihoo.kidwatch

• 134=com.qihoo.kidwatch.action.COMMAND_LOG_UPLOAD
• 165=com.qihoo.kidwatch.action.REMOTE_EXE_CMD

com.qihoo.contact

• 126=com.qihoo.watch.action.WIRETAP_INCOMING
• 317=com.qihoo.watch.action.WIRETAP_BY_CALL_BACK

com.qihoo.kids.camera.activity

• 320=com.qihoo.watch.action.REMOTE_SNAPSHOT

com.qihoo.kids.smartlocation

• 303=com.qihoo.kids.smartlocation.action.SEND_SMS_LOCATION

If we wanted to run these commands, the next step was to figure out how to activate the command dispatcher. The Android manifest states that the application listens for several broadcast intents that get sent to a “CoreBroadcastReceiver” class. This seemed like a good place to look.

At this point we knew that the persistent connection service was collecting a list of possible commands, and that the command dispatcher was presumably capable of receiving commands and forwarding them along to different applications. The “com.qihoo.kidwatch.action.sms.command” intent filter in the manifest hinted that the SMS application was capable of sending commands to this command dispatcher, and that’s where we looked next.

Sure enough, the Qihoo SMS application has a “dispatchCommand” method that receives encrypted SMS messages, and if successfully decrypted, forwards them along through a broadcast message to the command dispatcher.

To summarize, the command dispatcher iterates through applications and their intents, or commands. In order to call those commands, something needs to call the command dispatcher. The Qihoo SMS application can receive encrypted SMS messages that in turn call the command dispatcher.

Encrypted SMS > Command Dispatcher > Application commands (remote snapshot, for example).

Or in short – an encrypted SMS can be sent to the watch to trigger the surveillance functions.

Proof of concept - covert remote snapshot

Next was to put our findings to the test to find out if all this code actually worked. We decided to focus our efforts on the remote snapshot function. In order to do this, we needed a way to generate encrypted messages, and send them to our watch. We walked through the decompiled code to reverse engineer the syntax, and built our own command designed to trigger a remote snapshot from the camera application.

The SMS messages are RC4 encrypted with a four byte “hardcode” that’s stored in the NVRAM and set when the watch is manufactured. We were able to retrieve our own key by reviewing the Android system logs, and by using a Qualcomm tool called QPST to dump the NVRAM.

Sending the SMS triggered a picture to be taken on the watch, and it was immediately uploaded to Xplora’s server. There was zero indication on the watch that a photo was taken. The screen remained off the entire time.

Xplora now has a nice photo of our office ceiling sitting on their server.

Leveraging the backdoor

To utilize this backdoor somebody would need access to two pieces of information: (1) the device’s phone number, and (2) the factory programmed encryption key. Based on our observations we see a few plausible scenarios where somebody could get access to both.

Let’s start with the phone number, which is not particularly secret to begin with. Here are a few locations we believe it’s stored:

• Xplora has the phone number on their servers.
• We assume Qihoo has the phone numbers for the devices they sell directly, just like Xplora.
• The phone company will certainly have access to this. In most countries this information is shared with law enforcement.
• Depending on a few factors like your phone company and where you live, there’s a chance that your number has been published to public phone directories, such as the yellow pages, or similar.
• You can get the phone number if you have physical access to the watch.

One noteworthy point to make is that we did not see Qihoo directly collecting our device’s phone number. Though we don’t necessarily think this means that they can’t, or don’t. During our tests we observed the watch communicating directly with Qihoo owned servers in China. The domains included:

p.s.360.cn
sdk.s.360.cn

This mainly appeared to consist of diagnostic reports, though some of this data was encrypted, or otherwise obfuscated. There was a large amount of code related to this reporting functionality and we were unable to thoroughly review all of it. It was not entirely clear to us what all this code was doing.

Xplora’s backend server is also interesting to consider here. The communication between the watch and Xplora was performed in a very unique manner, which involved encrypted JSON objects. The watch performed this communication with code developed by Qihoo.

It is a reasonable assumption that the server-side component receiving this data also has elements developed by Qihoo 360, however this was not within the scope of our research.

The second part to this puzzle is the encryption key:

• Because the key is set during production, we can safely assume that Qihoo 360 has this key. This includes personnel at the factory where the watch was made.
• We also observed that Xplora had the key, as it was used to encrypt traffic between the watch and their servers.
• As we demonstrated earlier, if you have local access to the watch you can get the key.

In other terms, it isn’t exactly a limited group with access to these two puzzle pieces.

Final thoughts

There is no shortage of discussions that may be spawned from this type of finding, spanning IT security to ethics, geo-politics and beyond.

From an IT security perspective, the issue here is that this backdoor exists in the first place. This ability to issue wiretaps or take secret pictures over SMS is not a software vulnerability, a misconfiguration or an oversight in using outdated protocols. This is a functionality that has been created with intent.

What exactly is that intent?

To be continued…

Want to get in touch with mnemonic about these findings? Please reach out to [email protected].