Remote Code Execution Discovered in XTool AnyScan App: Risks to Phones and Vehicles

Introduction

Update (2025): The security issues identified in the XTool AnyScan mobile application have now been assigned official CVEs: CVE-2025-63432, CVE-2025-63433, CVE-2025-63434, and CVE-2025-63435. These CVEs formalize and validate the vulnerabilities discovered by the NowSecure research team, underscoring the seriousness of the remote code execution (RCE) risks posed to mobile devices and connected vehicles.

NowSecure researchers have identified an Android mobile app whose developers violated Google Play security guidelines, bypassing recommended update procedures exposing physical systems to remote control.

Several flaws in the automotive diagnostics app Xtooltech AnyScan were uncovered, including a vulnerable in-app update system, dangerous permissions and insecure network communications and cryptographic practices. These issues not only lead to remote code execution (RCE) on user devices, but also put vehicles at risk. Until the developer fixes these vulnerabilities, users have no real protection other than uninstalling the AnyScan app.

When Cars Become Computers

Automobiles have evolved into computers with wheels. Modern vehicles contain numerous sensors, actuators, motors and solenoids connected via wires snaked into a complex network of controllers all working together. Each year, vehicle manufacturers become more dependent on electronic systems and, as a result, the rate of cyberattacks against vehicles has dramatically increased.

The OBD-II port provides common and convenient access for mechanics using it in conjunction with scan tools to communicate with car computers while performing maintenance. OBD-II products have been developed to conduct a wide array of capabilities; from engine tuners promising to boost performance, to dongles promising to boost fuel economy, from antitheft and tracking, to bolt-on self-driving.

With the proliferation of mobile apps and the sheer number of OBD-II related products, it was only a matter of time until somebody combined mobile apps and OBD-II scanners into a single product. The Chinese company Xtooltech sells a variety of products in the automotive diagnostic space. Its xTool A30M device plugs into a vehicle’s OBD-II port and wirelessly communicates with a mobile device over Bluetooth (as opposed to needing a receiver).

Xtooltech AnyScan mobile app users can send commands to and receive data from the vehicle’s computer via the diagnostic device. While the ability to remotely send a command, such as honking a horn, may be harmless, some commands control vital engine and safety mechanisms like unlocking doors, rolling down windows and controlling the accelerator.

The unique capabilities of Xtool scanners present an interesting attack surface. Not only can a vulnerable mobile app lead to device compromise, but it also presents an opportunity to pivot to the vehicle itself. In this blog, we will explore how improper TLS validation can lead to persistent remote code execution on both mobile devices and vehicles.

Improper TLS validation can lead to persistent remote code execution on both mobile devices and vehicles.

We notified Xtooltech of the vulnerability on June 10, 2025 and they confirmed receipt on June 11. Initial analysis was performed on AnyScan version 4.40.11. As of press time, the latest version of 4.40.40 is still vulnerable.

The Path to Remote Code Execution

The xTool AnyScan app is deployed with very limited features and relies on official “plugins” to perform its core functions. For example, if the user wants to bleed their brake system, they need to install the brake bleeding plugin. If the user wants to diagnose their Ford vehicle, they need to download the Ford plugin. AnyScan ensures that its plugins are up-to-date by reaching out to a remote update server every time the app launches. 

While this is a convenient way to ensure that the user has access to the most up-to-date software, there are many implementation issues that allow a bad actor to conduct a variety of malicious attacks. These vulnerabilities can be chained together to achieve persistent full-remote code execution on the mobile device. Once the attacker executes code within the AnyScan app, they can send commands to the vehicle that the xTool dongle is plugged into.

Reverse Engineering the App

When exploring the AnyScan app, the first thing that stuck out to us was the ability to download plugins from within the app itself. This behavior violates Google’s developer guidelines, so it is surprising that the app contains this functionality in the first place. This practice is discouraged because it allows a developer to push new functionality to the app without passing through the typical Play Store code review process. As this blog post demonstrates, the consequences of improperly rolling your own update mechanism can be bad. If an attacker can compromise the update channel, then they can run their own code on devices running the app.

Exploring the Update Feature

On a fresh install of the app, the user is prompted to install over 100 updates. If none of these updates are installed, the app will not connect to a vehicle, so the user must use the remote-download feature to achieve basic functionality.

These updates are retrieved from xTool by sending a GET request to https://apigw.xtoolconnect.com/uhdsvc/UpgradeService.asmx/GetUpdateListEx. While HTTPS requests are encrypted, they can only be considered secure if the implementation is done properly. In this case, AnyScan uses an insecure TrustManager implementation which allows all HTTPS certificates to be considered valid.

By default, Android provided TrustManagers validate that a TLS certificate is valid and issued by a trusted CA; however developers may choose to override the original functionality and replace it with their own implementation. Here, we can see that the com.xtool.diagnostic.fwcom.net.OKHttpDownload.buildTrustManagers() method overrides the original Android implementation and leaves the new override method completely empty.

This means that any verification typically performed by the TrustManager will be completely bypassed. This allows an attacker to proxy network traffic with a self-signed TLS certificate and modify the contents of individual network packets.

Using this knowledge, we can inspect the request and response responsible for gathering update metadata.

Looking at the data contained in the packets, the response body consists of an XML file containing Base64 encoded text which decodes to encrypted data.

Exploiting Hardcoded Cryptographic Material

In order to make sense of the encrypted content, the encryption algorithm and mode, key, and initialization vector (IV) all need to be uncovered. After some digging, all those items were found in the com.xtool.dcloud.RemoteServiceProxy class.

This discovery raises two major concerns:

1. The app is using an insecure DES 56-bit encryption algorithm.
2. The key and IV are the same value and hardcoded directly in the app.

The use of DES ciphers has been discouraged since the late 90’s, in favor of more secure AES ciphers which are more resistant to brute force attacks. In addition, cryptographic material should never be hardcoded, as it trivializes the decryption of sensitive data.

Because we now have all the material needed to decrypt the XML contents, we can reveal the update metadata.

Understanding the Installation Process

Now that we understand how updates are fetched over the network, we need to figure out what happens once the application downloads an update. First, a genuine update can be downloaded without authentication (yet another vulnerability) by sending a GET request to a URL created by combining the FilePath field with the FileName field found in the update metadata. The request returns a zip file containing the following structure:

When AnyScan downloads an update, it unzips the file, then blindly copies that contents to a central location (…another vulnerability) for later use. While the update metadata contains an MD5 signature, it doesn’t appear that any validation is performed locally or remotely.

Creating the Exploit

The meat and potatoes for each plugin is a shared object, named libscan.so (on 64-bit devices, libscan_x64.so is used). When a user selects a vehicle to scan, AnyScan looks for the libscan.so binary that corresponds to the desired manufacturer and loads it into memory using the dlopen family of functions.

Crafting a Malicious Native Executable

For a proof of concept, we kept the code short and sweet – it sends a message to the system logs and exits. By using the C constructor attribute, our payload is executed automatically when the libscan.so library is loaded by the app. Once the payload was crafted, it was compiled and renamed to libscan_x64.so.

Bundling the Malicious Update Payload

AnyScan plugins contain a handful of other files inside the zip besides the shared library, so we took a bit of a shortcut by stuffing our compiled code into an existing plugin. In addition, we modified a file inside the zip containing metadata strings to make our plugin a bit more identifiable and then zipped the whole thing up.

With our “malicious” plugin built, we could work on getting the app to load it. In order to make the app aware of our malicious update, we needed to craft an update metadata JSON that would be accepted by the app when it reaches out for new updates.

We modified the existing update metadata JSON to contain a link to a server hosting our malicious update (more on that later). Then, using the hardcoded password and IV uncovered in the app, we DES encrypted the update metadata and stuffed it in the original XML file.

Next, we set up a network proxy with mitmproxy that captures all traffic coming from our Android device. We accomplished this with iptables rules on the Android device. Out in the real world, this can be performed without user consent through various means, such as a man-in-the-middle attack via a malicious hotspot, VPN, or TOR exit node. This attack can also be conducted by modifying settings on a router to direct all traffic through an attacker-controlled tunnel (this is easily performed on public routers utilizing default credentials).

Then, we wrote a mitmproxy plugin that intercepts all requests to the GetUpdateListEx endpoint and responds with our malicious update metadata.

Now that the proxy can redirect requests from the app, we need a way to actually serve the update to the user. This can easily be done by setting up a simple Python webserver in the same directory as the payload. With the server running, the payload is accessible to any system that reaches out to our IP address.

With the network ready for the attack, we launched the app and were immediately presented with available updates. This means that the proxy successfully redirected the update request and the app decrypted the injected metadata.

When the user chooses to download the update, the app then reaches out to our server hosting the malicious plugin, downloads it, and extracts it to the filesystem on the device.

Once downloaded, the user is presented with a scanner for a new PWNED vehicle. In a real attack, this update would be disguised as a legitimate car manufacturer, so the user would have no suspicion of malicious activity.

We can confirm the exploit is successful by selecting the malicious scanner and observing logcat. Upon pressing the PWNED button, logcat reports that the app successfully copies our libscan_x64.so library and calls dlopen() on it without validating its authenticity, which causes our custom log to be displayed.

Impact

The app doesn’t provide much functionality unless users are installing and using plugins, so almost all users will download updates provided by this vulnerable feature at some point. This makes it a very powerful attack vector because it weaponizes a feature that most users are familiar with and are expected to use regularly. With the update code being unvalidated, the attacker has the ability to run whatever code they want on the device when the plugin is run. Plugins are stored in the app’s local filesystem, so the exploit persists across reboots. In addition, malicious code can be injected alongside the legitimate plugin functionality, so the user isn’t informed of any strange behavior. 

The attacker’s code executes within AnyScan’s application context, which allows an attacker to utilize all of the permissions that the app has been granted. AnyScan requests a wide variety of permissions including many that Android considers to be dangerous permissions, so various sensitive components (such as the camera, bluetooth, GPS and filesystem access) may be utilized for malicious purposes such as installing spyware, adware or cryptocurrency miners.

Not only does this attack allow for code execution on the mobile device, xTool scanners facilitate bi-directional communication between the vehicle and the user, which permits attacker-controlled code to interact with the vehicle via the OBD-II port. Malicious commands can cause a wide variety of unwanted behavior of varying severity, including keyfob reprogramming and tampering with critical vehicle systems.

OBD-II access allows attackers to send malicious CAN bus commands to the vehicle. These commands have been used to gain complete remote control of a vehicle, which can lead to vehicle theft or serious injury to passengers.

While this vulnerability can have severe consequences, it does not necessarily do so on its own. In the last few years, some vehicle manufacturers have increased their security of internal systems; however, many still have not. This vulnerability serves as an attack vector which allows malicious actors to run exploits on the user’s device and connected vehicles. With multiple reports of car hacking on the rise, vulnerabilities allowing initial access are extremely valuable to attackers and should be patched immediately.

Call to Action

For end users of the AnyScan app, the lack of certificate validation while downloading plugins means that there is not a truly secure way to use the app. Users can minimize their exposure by only using the app while connected to private, trusted networks with a secure password. There is no way to determine if the app has already been compromised via this insecure update mechanism. The only secure option is to uninstall the app until this vulnerable feature has been addressed. If the app must be used, we recommend uninstalling the app completely (to remove previously installed plugins), then reinstalling it and only using the update feature when absolutely necessary on a trusted network.

For developers, there are two primary takeaways from this example. First, the practice of rolling your own update mechanism is a risky decision. The Google developer guidelines advise against it for good reason. A single mistake in the implementation leaves the door open for attackers to take control of the app. Second, breaking TLS certificate validation is never a good idea. If a TLS validation bypass is used to make the development cycle easier, all bypasses should be removed for production builds without exception.

Conclusion

As far as mobile attacks go, normally the user’s device is the end of the line. The attacker’s goal is to get code onto the device and get data off. In the case of the Xtooltech device and AnyScan, the mobile app lets you use your phone to remotely communicate with your vehicle across a diagnostic port. This is a unique case where an attacker gets a persistent presence on the mobile device and can then pivot to start covertly sending malicious commands to vehicles.

Allowing a user to download app features from inside the app itself is a dangerous technique that violates Play Store policy. In addition, there are many vulnerabilities that exist in Xtool’s implementation of this feature. While all vulnerabilities should all be addressed, the biggest vulnerability that needs immediate fixing is the failure to validate TLS certificates, because it allows for persistent remote code execution on the mobile device and connected vehicles.

The list of what all can be accomplished over the OBD-II port varies greatly depending on the make and model of the vehicle, as well as how the vehicle was configured by the manufacturer. While sophisticated attacks may require a complex chain of exploits tailored to a vehicle’s make and model, this vulnerability can be used as the initial foothold which allows attackers to run an exploit against the car’s computer itself, leading to further access. With the dramatically increasing rate of cyberattacks against vehicles, any vulnerabilities which provide initial access for attacker-controlled code to be run, need to be taken very seriously.

CVE Assignment and Disclosure Details

Following responsible disclosure to the vendor, the vulnerabilities uncovered by the NowSecure research team in the XTool AnyScan mobile application have been officially assigned a series of CVE identifiers, confirming the severity of the RCE risks to mobile devices and connected vehicles.

The following CVEs are associated with the vulnerabilities documented in this research:

• CVE-2025-63432
• CVE-2025-63433
• CVE-2025-63434
• CVE-2025-63435

These identifiers are now published through the CVE Program and supporting references. Security teams and impacted users can review the official records for technical details, impact information and remediation status.

Reference links

• Deep dive into OBD2 scanner vulnerabilities: https://www.usenix.org/system/files/sec20summer_wen_prepub.pdf
• Risks posed by OBD2 connected vehicles: https://insights.sei.cmu.edu/documents/472/2016_019_001_453877.pdf