GPS reverse engineering WatchLock lock for personal use

The Israeli company Starcom Systems specializes in various kinds of GPS / GSM trackers and remote control systems based on them. In this case, I got a device developed in this company: an electronic lock with the functions of a WatchLock GPS tracker , which Starcom launches together with Mul-T-Lock.

The device combines the functions of a classic padlock with the functions of a GPS / GSM tracker and accordingly allows you to control such parameters as: opening / closing the lock, physical impact on the lock (using an accelerometer), the current location of the lock, etc. Transmission of event information via the GSM network. It is possible to use two options for communication, a GPRS channel and (or) SMS messages (in this case, communication via SMS does not really bother me, so let's focus on GPRS). Data is transmitted to the company’s server or to the proxy server installed at the dealer for a supported friendly service. For example, Wialon, or again on the company's server. A private user who has purchased a device for personal use will not be able to use it without paying for services of third-party companies, that for non-corporate users it can be unnecessarily or unnecessarily (or, as an option, high anonymity is required). I am one of those to whom the functionality of large monitoring servers is redundant, and the opportunity to play with a new device is motivational. So let's get started!


  • IDA DEMO 6.6 from Hex-Rays (debugger, disassembler, necessary to analyze the internal logic of the program);
  • Starcom configurator (for initial device setup and protocol analysis);
  • The official user guide from Starcom (because we need to understand how to work with the device).


The configurator program was made explicitly by developers for developers (which in our case will be a big plus for analysis), there are many debugging functions. The most important of them for us is the window for viewing traffic between the device and the program (traffic is shown as is, without processing).

There are two ways to connect the device to the program, start the local server in the program and force the lock (or simulator) to connect to it:

1) Via the GPRS channel, in this case, the correct settings of the parameters (IP address and port) should be indicated initially in the lock settings that is not possible in our case;
2) Communication via a data cable that comes complete with a lock.

Since I was sure that my server settings could not be there, I connected the device physically. The data cable is a regular USB-SERIAL adapter with TTL levels from FTDI (the default exchange rate is 115200 baud (8 bits, no parity, 1 stop bit), it is also possible to set the exchange speed to 57600 in the settings via the configurator) . Since the native cable for connecting the device to the computer is most likely not to be, it is possible to use any suitable USB-TTL adapter.

Information pinout

The device is connected and we can observe the traffic exchange between the device and the program. The approximate structure of the packages, the unchanged header and the constantly changing body of the package with the same length are immediately evident, which immediately tells us that traffic encryption is used (the presentation and the official user guide also tell us this). We will leave the header for later analysis, although it is already noticeable that it contains the start byte (0x24 is the symbol '$', all packets begin with it) and the serial number of the device (9A 02 00 00 - 666). How to find the encryption algorithm and key? Everything is logical here: if the configurator program can receive and display the contents of the package, it means that it decrypts it, so the algorithm and key must be found in the configurator program itself.

The program is written in Delphi, which means that in assembler there will be a lot of various kinds of calls in RTL and other garbage that will complicate the analysis of the program. How to find an encryption algorithm? I decided to go the simple way and look for it in the program code according to the known constants of popular algorithms. The method does not always work, but there is still a chance. As a result of enumeration, I found the constant 0x9E3779B9 , which means it is a TEA block cipher algorithm ! Next, it was necessary to understand (already analyzing the algorithm code) which specific implementation option for this algorithm is used. Turned out to be using XXTEA, but the algorithm was slightly modified so that, thinking that you guessed the implementation and checking in fact that the result did not fit, we went looking further.

Now we know that the XXTEA encryption algorithm is used., key 128 bits, block size 64 bits, 32 rounds. Now we have learned a little more about the structure of the package. The header + body of the packet is equal to 64 bits and one extra byte, which, apparently, is the checksum of the packet. Here again, it is necessary to use the disassembler and study in more detail the manipulations with the last byte of our package. The checksum calculation algorithm turned out to be XOR8. The maximum size of the header is 70 bytes, the maximum size of the packet body, including the checksum, is also 70 bytes. Thus, it turns out that the packet cannot be more than 140 bytes. This value was not chosen by chance, but, apparently, is necessary for the guaranteed sending of one packet in one SMS message. Now we have a complete picture of the structure of the package and we can visualize it with the following picture. I deliberately omit assembler listings,Owl drawing guide . but without proper and detailed descriptions of these listings, they do not make sense, and they pull on a separate article. As Stephen Hawking wrote: “every equation added to a book halves its sales revenue.”

The structure of the packet is clear, the encryption algorithm is known. We can either make a helper program and modify a well-known package, watch how it is displayed by the program, thereby understanding the values ​​of certain fields of the package, or analyze the behavior of the program when receiving the package in the debugger. Since the package does not understand immediately in one place of the program, but only if necessary, it was decided to make an assistant program that can communicate with both the device and the configurator program.


The picture is already one of the latest versions of the program, where I analyzed almost all the fields of the main packages, but it all started with a simple form for entering data and displaying the result. Detailed information about the values ​​of the fields of the packages and their structure, as well as all the source codes of the projects can be found in the repository on Bitbucket: Watchlock tools (projects can be collected in Pelles C ).

To work with the device, it is necessary to understand how the device communicates and identifies itself. I have identified two main types of packages - (see wl_protocol.pdffrom the repository) PING and TRACKING. The PING packet is sent by the device to the server immediately after the connection, the package is minimalistic and contains only key information, such as the serial number of the device, time of the device’s clock, type of the device’s hardware platform, firmware version, GPS coordinates and settings for the communication period. The TRACKING packet usually follows the PING packet and already contains more advanced information, such as the reason for communication, the status of the sensors, battery voltage, etc. In turn, during an established session, we can send requests to the device, thus, for example, changing the set time for the next connection, if necessary, request the device’s IMEI modem, read / write the basic settings of the device. Thus, with the connected device, we can do almost everything that is necessary,

Having done such a long way, we can already start implementing our server for receiving messages from the WatchLock device. The server is simple, only to test the general concept and, of course, does not even stand next to an official or third-party for specialized purposes. The server has a web interface for viewing the current status of connected clients and allows you to decode a specific set of parameters from them.

Test server

As a result, we got our data receiving server with blackjack and general concepts about the implementation of the exchange protocol in GPS trackers based on the WatchLock device. This article is also relevant for other Starcom devices, such as Helios (car tracker), Triton (cargo tracker) and others. As a further improvement, we can suggest porting the server program to Linux and linking it to Google Spreadsheet to save point information. As a platform for this server, you can use a router, thus obtaining a compact solution for personal needs.

All information is presented solely for personal use and, of course, does not claim to replace official or third-party data reception and processing servers.

* update 02/06/2015
After the article was published, Startcom removed the link to their device configuration program.

Also popular now: