Assessing the Security of GPS Theft Recovery Systems: A Laboratory Analysis of Spireon MM18 (Kahu/LoJack)
December 1, 2021

Assessing the Security of GPS Theft Recovery Systems: A Laboratory Analysis of Spireon MM18 (Kahu/LoJack)

1. Executive summary

GPS theft recovery systems rely on a connected device installed in the vehicle. This device communicates its location at regular intervals, allowing the owner of the car to be notified via a smartphone application of the vehicle’s current location, or whenever specific events occur such as geofence entry or exit, low battery, or speed limit violations. It can also be used by vehicle dealers to track and protect their vehicle inventory.

In early 2021, spurred by the alarming increase in auto theft in the U.S., Kudelski IoT Security Labs performed several analyses of vehicle theft recovery systems to understand their security maturity level.   Creating a device that is secure protects both the continued functionality of the device (tamper protection) as well as the privacy of the device’s owner (data protection). To achieve this, it is critical to ensure that both the right physical and cybersecurity protections are implemented to safeguard the entire lifecycle of the product.

To create this level of protection, a number of different features need to be carefully implemented and then tested by a third-party security lab in order to prove they reach the required level of security.  If the necessary technology is not implemented - or if it is implemented incorrectly - not only can the manufacturer suffer significant harm to their business, but they can also undermine consumer confidence in theft recovery solutions as a category in general. It is therefore in the interest of the entire value chain that manufacturers invest enough time and effort into the security of their products, calling on experts to help where required.

One of the major theft recovery players in the United States is Spireon, who offers multiple services for both consumers and car dealers through its Kahu solution. Note that this solution has recently been rebranded “LoJack” after Spireon acquired the name from CalAmp.

This document aims to provide insights into the device security analysis process as well as a technical overview of the security issues discovered on the model (MM18), commonly installed in consumer vehicles.

Note: Our findings were presented to Spireon using the commonly accepted responsible disclosure methodology meant to give companies ample opportunity to respond to and patch security vulnerabilities. We presented our findings to Spireon with the intention of helping them strengthen their product and thereby also the entire theft recovery ecosystem.  This report is being published publicly after the expiration of the responsible disclosure period.


2. Summary of findings

The following is the summary of our findings following thorough analysis of the MM18 device at our IoT Security Labs in Switzerland.

  • There is no physical or hardware security present to prevent tampering with the device
  • The device’s position can be easily ascertained once the MSISDN of the SIM card is known
  • Other MSISDNs (“Mobile Station International Subscriber Directory Number”, the technical term for the mobile phone number) were easily discovered by probing contiguous phone numbers with simple text commands
  • There is no authentication or encryption used to prevent malicious changes to firmware
  • The device can be made to report a false position to its owner or law enforcement

For a video summary of these findings, please click

3. Detailed findings

3.1   Hardware analysis

The device is composed of a single printed circuit board surrounded by a two-part plastic case clipped together. A 16-pin connector is exposed, however only four wires are used.

The Spireon MM18 Device (branded Kahu or LoJack)

When starting such an analysis, it is highly recommended to seek available online resources regarding the device, such as user manuals, mobile applications, update packages, applications, or even certifications.

In the United States, the regulatory requirements for such devices are set by the Federal Communications Commission (FCC). The identification number is usually written on a label applied to the device indicating that the device has been certified, in this case O9YWCM. Among the available documents, the Internal Photos and User Manual often provide a good level of detail to get started. Sometimes it is also possible to retrieve more information by looking at information provided by the company itself since the technology is often reused across multiple models for costs savings.

In the present analysis, it was relatively trivial to find the installation guide for a similar device dubbed TALON, and part of the Gold Star solution by Spireon, which describes the wiring diagram for both the Power Supply and Starter Disable Relay.

Logical Diagram of Spireon MM18 Device (branded Kahu or LoJack)

Since the device needs an external power supply, it is shipped with a specific On-Board Diagnostics (OBD-II) adapter granting access to the power supply pins available on the bus. However, the power can also be directly wired to the fuse box or any location where 12V is available. Some devices may also contain a small battery to maintain power in case of low voltage or temporary power outage.

Two more wires are connected to the device to detect car ignition and control the starter disable relay, which can prevent the car from being started.

Once the general behavior of the device was known, we began a more detailed investigation of the device. No specialized equipment was required to open and examine the device, we were able to open the device by releasing its plastic clasps. No anti-tamper measures were discovered when doing this.

On the upper side of the PCB, it is possible to clearly identify the ceramic GPS Antenna, SIM card, and the slot for the optional backup battery. Some pins can already be identified by looking at the markings next to the pin holes and test pads.

Upper Side of Spireon MM18 PCB

The other side of the PCB holds the main components of the device as well as a USB connector which is not exposed outside the enclosure. Some more markings can also be observed which provides more information about the device.

As we can see above, the heart of the system is composed of two main chipsets:

  • STM32G030K8 (LQFP32)

This microcontroller from STMicroelectronics is powered by an ARM Cortex-M0+ processor with 8 Kbytes of RAM. It has an internal flash memory of 64Kbytes and supports multiple communication interfaces such as serial, I2C and SPI. The microcontroller only supports programming via Serial Wire Debug (SWD), which has already been detailed in an earlier blog post. More information can be found in the datasheet.

  • Quectel BG96

The BG96 is an LTE Cat M1/Cat NB1/EGPRS module offering maximum data rates of 375kbps. Under the shield it is possible to identify two Radio Frequency (RF) Power Amplifiers, a NAND Flash of 1 Gb including a 512Mb LPDDR2 memory, a Qualcomm power module, and a modem chipset powered by an ARM Cortex A7. The module is able to provide its location using the Global Navigation Satellite Systems (GNSS) but also to communicate over Global System for Mobile Communications (GSM) using Short Message Service (SMS) or over the Internet through the LTE Cat M1/Cat NB1/EGPRS cellular connectivity.

An archive containing all resources for this module is available from the vendor website.

3.2 Firmware analysis

3.2.1 Part One

The markings (IO/CLK/RST) near the unpopulated connector suggested the presence of an SWD port which may be used to program the STM32. Before attempting to interact with it, a continuity check was performed to validate this hypothesis, resulting in the following mapping.

Interaction with the interface can be achieved by using any probe supporting the SWD protocol. In the present case, the 2-wire mode of the Hydrabus can be used to query the IDCODE.

> 2-wire

Device: twowire1

   GPIO resistor: floating

   Frequency: 1000000Hz

   Bit order: MSB first

twowire1> show pins

CLK: PB3

IO: PB4

twowire1> idcode

0x0bc11477

Since the Readout Protection (RDP) has not been enabled, it is also possible to dump the whole firmware with the OpenOCD software:

Open On-Chip Debugger 0.10.0+dev-01489-g06c7a53f1-dirty (2020-11-12-11:03)

Info : Buspirate SWD mode enabled

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : Buspirate SWD Interface ready!

Info : This adapter doesn't support configurable speed

Info : SWD DPIDR 0x0bc11477

Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints

Info : starting gdb server for stm32g0x.cpu on 3333

Info : Listening on port 3333 for gdb connections

Info : accepting 'telnet' connection on tcp/4444

Info : SWD DPIDR 0x0bc11477

Connecting to the telnet port 4444 allows to dump the firmware of the STM32 and analyze it.

$ nc 127.0.0.1 4444

> dump_image stm32g0.bin 0x08000000 0x10000

The reverse-engineering of the firmware is left as an exercise to the reader.

3.2.2 Part Two

After downloading the documentation and tools from Quectel for the BG96 (here), three different interfaces are available on the USB port and recognized by the computer, respectively the AT interface for modem configuration and communication, the DM interface for diagnostics and the NMEA interface for GPS data.

Access to the memory content of the module can be achieved through the DM port with the EFS Explorer utility provided in the archive.

The whole application running on the module resides in the datatx folder, where the most interesting files were the following:

  • oem_app_path.ini: defines the application path and upgrade path (points to custom.bin)
  • custom.bin: the application running on the module
  • queue.bin: temporary storage for pending messages
  • devdef.cfg: device definitions in AT command format (only suffix in the file)

Among the above files, the latest seemed to contain proprietary AT commands suffix:

+XIP="208.92.128.156",9090

+XMIP="208.92.128.86",6666

+XUIP="",69

+XLPORT=8090

...

However, any attempt to send these commands on the standard AT interface resulted in an error.

After spending some additional time on the FCC website, those commands could be found in the O9YJH01 user manual, which provides more information about the inner workings of the device. As stated in the document, these commands need to be sent on a dedicated serial interface which was found on the 16-pin connector.

The reverse-engineering of the application is left as an exercise for the reader.

3.3 Local command execution

Since the serial interface voltage is 1.8V, the adequate USB to TTL serial cable needs to be used to interact with it. Upon startup, many debug messages are printed as well as the device version:

quectel_task_entry

quectel_task_entry(txm_module_object_allocate): 0

quectel_task_entry(tx_thread_create): 0

prologue done

<snipped>

WILDCAT

00:00:00

                 v

               _,'\             _.-''``-...___..--';)

              /o \'.      __..-' ,      ,--...--'''

             <\    .`--'''       `     /'

              `-';'               ;   ; ;

        __...--''     ___...--_..'  .;.'

       (,__....----'''       (,..--''

<snipped>

PROD:  WILDCAT

IMEI:  <redacted>

IMSI:  <redacted>

ICCID: <redacted>

MDL:   3015R01

BIN:   BG96MAR04A04M1G

APP:   3.8.7

IO:    2.2.5

CFG:   4713* M-KH-VZN

IP:    208.92.128.1569090

LPORT: 8090

SIM:   Ready

If the command AT is sent to the device, it will answer with an OK message followed by its IMEI and the input command (except for the AT command):

AT

OK, 86<redacted>63,<cmd>

In case the device receives a wrong command, it will simply answer with ERROR followed by the faulty command. If multiple wrong commands are received by the device, it will switch to locked state, meaning that it will not accept any further commands.

AT BLOCKED (SHUTDOWN)

ERROR, 86<redacted>63,<cmd>

The aforementioned manual states that the device can be “queried, updated and configured either through a serial connection, an over the air IP connection, or through SMS messaging”, so we investigated to find out if a similar mechanism was available remotely.

3.4 MSISDN extraction

It is true that once physical access has been obtained, the SIM card can be easily replaced by another one. However, it is even more interesting to know the MSISDN of the stock SIM card because numbers tend to be allocated in a contiguous range by the provider, enabling the identification of targets at scale.

The MSISDN associated with the SIM card can be obtained either by inserting it into any mobile phone or simply by sending the AT+CNUM command over the AT interface available on the USB port (baud rate 115200):

AT+CNUM

+CNUM: ,"+1525<redacted>",145

OK

*Tip: By default, the terminal will not echo back the input, however this can be re-enabled by issuing the ATE command blindly beforehand.

**Bonus: When the device is connected to the computer, the AT interface will be seen as a modem interface which can be used to have free Internet around the globe since no restrictions were enabled.

3.5 Remote command execution

3.5.1.1 Target identification

Local testing demonstrated that if the command AT is sent to the device, it will answer with an OK message followed by its IMEI. Since the MSISDN has been recovered, it is possible to test if the same behavior applies when sending the command over SMS:

By probing ten surrounding numbers with the above methodology, it was possible to identify other potential targets, validating our previous assumptions about contiguous MSISDNs. Nothing could prevent an adversary from performing this attack at scale.

Since no filtering nor authentication are required, this communication channel can be used to execute any available commands remotely, allowing an adversary to either acquire the device location or configuration, tamper with the settings, and potentially trigger false alerts.

3.5.1.2 GPS tracking for fun!

One of the most interesting use cases resides in the fact that the location can be queried regularly through this communication channel, allowing an adversary to understand the habits of the car owner. This could give a huge advantage to a criminal wishing to rob the owner’s car or home, or simply give a convenient way to track people without their consent.

The figures below show the mapping of two successive GPS location requests sent to a random target device within a 5-minute interval.

Another use case allows an adversary to fake the position of the tracker by redirecting the reports sent by the device to a server under the control of the adversary. As a result, the adversary will perform a man-in-the-middle (MITM) attack with the ability to tamper with any data sent to the server.

Since the communication is performed over a UDP channel without any additional encryption nor validation of the destination server, the adversary need only relay or modify packets on-the-fly.

For instance, the GPS events packet was found to be transmitted in the following hex format:

The coordinates are computed by adding (or removing) 90 for the latitude and 180 for the longitude to the values received from the GPS and then multiply them by 1’000’000 to keep the decimals precision.

The following Python code demonstrates the conversion:

# Convert GPS data to hex

hex(int(2.2922926+180.0)*1000000))

0xADD8F44

# Revert hex to GPS data

(0xADD8F44/1000000)%180

2.2922920000000033

Since the time is retrieved from the GPS data, the calculation needs to consider the epoch which must be changed to August 9th, 1999. This date has been chosen before the GPS week rollover which occurred at midnight August 21st-22nd, 1999 to prevent any possible bugs.

The following Python code will convert the date back to the correct format:

from datetime import datetime

from datetime import timedelta

t = 0x28E0D64A

epoch = datetime(1999, 8, 9)

d = t // 3600 // 24

h = (t // 3600) % 24

m = (t // 60) % 60

s = t % 60

print(epoch + timedelta(days=d+1, hours=h, minutes=m, seconds=s))

2021-05-03 18:32:42

The above MITM attack is not limited to the events or alerts as firmware and application updates are also performed in a similar fashion over FTP.

3.6 Starter relay control

Lastly, as described in the wiring diagram, the device may be wired to a starter disable relay. This feature enables the device to prevent the car from being started.

This is a very attractive feature for a car dealer who can stop the car in case of payment default by the customer or even if the car has been stolen. However, if an adversary can change this setting remotely, then all cars with this relay mechanism may not start anymore, which could cause potential safety issues for the car owner and liability issues for the company who sold the solution.

Internal testing demonstrated that this attack is feasible, as the state of the relay could be driven remotely using the AT+XRLYcommand.


4. Conclusion

This analysis demonstrates that the Spireon MM18 device does not implement the correct protection at a hardware level, and that the solution was not created with security in mind since neither authentication nor encryption have been used to impede attackers in any way.  This, in turn, allows attackers to gain a level of access to the device and its data, putting customers at risk that the solution will reveal their location or even prevent their car from starting. Ultimately, this enables attackers to tamper with the device settings or totally replace the application to their needs. Well-established methods to prevent these attacks could have been implemented to prevent these risks but were not.

Autor: Karim S., Security Expert, Kudelski IoT Security Labs


5. Responsible disclosure timeline

The above issues have been responsibly disclosed to Spireon in June and July 2021 respectively. After extending the standard 90-days embargo period by one month upon request from Spireon, the findings of this analysis are now public.

June 18th, 2021 - Initial disclosure

July 8th, 2021 - Second disclosure

August 25th, 2021 - Call with Spireon

November 30th, 2021 - Publication

6. About Kudelski Group

The Kudelski Group is the world leader in the development and delivery of state-of-the-art technologies to secure the revenues of content owners and service providers for digital television and interactive applications across all network types. It is headquartered in Cheseaux sur-Lausanne, Switzerland, and Phoenix (AZ), USA. The Group’s solutions enable consumers to access content seamlessly over any device through a compelling viewing experience.

Leveraging on its long-standing expertise in securing digital content and fighting piracy, the Group is a global provider of cybersecurity solutions and services focused on protecting companies’ and organizations’ data and systems.

The company also develops and delivers Internet of Things security technology and services to help companies across all industries to protect their devices, their data, and their business models.

Public Access solutions are another activity sector of the Group. The world’s largest parking facilities, stadiums and mountain resorts use SKIDATA’s integrated people and vehicle management solutions.

The Group capitalizes on its Intellectual property patent portfolio through cross access to state-of-the-art technology patents and license agreements, demonstrating the relevance of the Group’s innovation and the key role it is playing in the industries in which it operates.

For more information, please visit www.nagra.com.


7. IoT Laboratories

Through more than 25 years of research and security analysis of digital systems, we have developed a wide range of evaluation techniques and capabilities in order to exceed the abilities of hackers. We now put these tools to use to give our clients the critical insights they need into the robustness of IoT security.  

Our heritage

The Kudelski IoT Labs history has its root in the permanent quest for excellence that has been the trademark of the Kudelski Group and NAGRA product line. Since the time of the NAGRA audio recorder, in the 1950s, the group products are always appreciated for their quality, robustness, and reliability. This has been achieved by world class engineering and quality management.

When the Kudelski Group entered the Pay TV market in 1989 it had to expand its quality management to security - and that was the inception of the Kudelski IoT Labs. The success of the Kudelski Group in Pay TV is rooted in the excellence of the security level it provides to content providers and operators. Pay TV has been hacked and under permanent attack since its beginnings. The billions of dollars the industry earns has pushed criminal organizations to invest millions of dollars into attacks in order to derive revenues by reselling and streaming hacked contents.

The Kudelski IoT Labs are always on the cutting edge to ensure that all R&D and products have been thoroughly tested and secure enough to withstand attacks over their lifetime. Such a feat is achieved by meaningful investment in research and lab capabilities. The Kudelski IoT Labs mostly rely on internally developed equipment that goes beyond off-the-shelf available equipment. The point of the game is not just to have a secure product at t-zero but all along the product lifetime - and that requires investing now in the high-end capabilities and attacks that will become mainstream over the product lifetime. The Kudelski IoT Labs have also been key in helping the Kudelski Group and its customers protect and defend their intellectual property, but also in assisting in criminal investigation. For a long time, the Kudelski IoT Labs have been a hidden gem whose service was available only to a few. Since 2014, this service has been available to industries and clients beyond just Pay TV. For more information, please visit www.kudleski-iot.com.