Reverse engineering GPS WatchLock lock for personal use

The Israeli company Starcom Systems specializes in various kinds of GPS / GSM trackers and remote monitoring systems based on them. In this case, the device developed by this company came to me: an electronic lock with the functions of a GPS tracker WatchLock , which Starcom launches together with the company 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 information about events via the GSM network. It is possible to use two options for communication, the GPRS channel and (or) SMS messages (in this case, the connection via SMS does not really bother me, so let’s stop at GPRS). Data transfer is carried out on the company's server or proxy server installed at the dealer on a supported friendly service. For example, Wialon, or again to the company's server. A private user who buys a device for personal needs will not be able to use it without paying for the services of third-party companies, which may be costly or unnecessary for non-corporate users (or, alternatively, high anonymity is necessary). I am one of those for whom the functionality of large monitoring servers is superfluous, and the opportunity to play around with the new device is motivational. So let's get started!

Tools

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

The configurator program was made explicitly by developers for developers (which in our case would be a big plus for analysis), there are a lot of debugging functions. The most important of them for us is the traffic viewing window between the device and the program (the traffic is shown as it 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 with it:

1) Via the GPRS channel, in this case, the correct settings of parameters (IP address and port) must be indicated in the lock settings initially, which is not possible in our case;
2) Communication through the data cable supplied with the lock.

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


The device is connected and we can observe the exchange of traffic between the device and the program. Immediately striking is the approximate structure of the packets, the unchanged header, and the constantly changing packet body at a constant length, which immediately tells us that the traffic is encrypted (this is what the presentation and the official user manual tell us). Parsing the header will be left for later, although it is already noticeable that it contains the starting byte (0x24 - 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 accept and display the contents of the package, then it also decrypts it, so the algorithm and the key must be searched for in the configurator program itself.

The program is written in Delphi, which means that the assembler will have a lot of different kinds of calls in RTL and other garbage, which will complicate the analysis of the program. How to find the encryption algorithm? I decided to go in a simple way and look for it in the program code using known constants of popular algorithms. The method does not always work, but still there is a chance. As a result of the search, I found the constant 0x9E3779B9 , which means it is a TEA block encryption algorithm! Further, it was necessary to understand (already analyzing the code of the algorithm) which particular embodiment of this algorithm is used. It turned out that XXTEA is being used, but the algorithm was slightly modified so that, thinking that you guessed the implementation and checking in practice that the result did not converge, they would go further.

Now we know that the XXTEA encryption algorithm is used, the key is 128 bits, the block size is 64 bits, 32 rounds. Now we know a bit more about the package structure. The header + packet body 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 to study in more detail the manipulations with the last byte of our packet. The checksum algorithm turned out to be XOR8. The maximum header size is 70 bytes, the maximum packet body size, including the checksum, is also 70 bytes. Thus it turns out that the package can not be more than 140 bytes. This value was not chosen randomly, but, apparently, necessary for the guaranteed sending of one package in one SMS message. Now we have a complete understanding of the package structure and can be visualized with the following image. I deliberately omit the assembler listings, which makes the story a bit like an owl drawing guide . but without proper and detailed descriptions of these listings, they do not make sense, and they are drawn to a separate article. As Stephen Hawking wrote: “every equation added to a book reduces sales revenue by half.”



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


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

To work with the device, it is necessary to understand how the device contacts and identifies itself. I have identified two main types of package - (see wl_protocol.pdf from the repository) PING and TRACKING. The PING package 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, the time of the device’s clock, the type of hardware platform of the device, the firmware version, GPS coordinates and settings for the connection timeout period. The TRACKING package usually follows the PING package and already contains more advanced information, such as the cause of the connection, the status of the sensors, the battery voltage, and so on. In turn, during the established session, we can send requests to the device, thus, for example, changing the set time of the next connection, if necessary, request the device's IMEI, read / write the basic settings of the device. Thus, with the connected device, we can do almost everything that is needed, but in our case, such extensive manipulations with the device will not have to be done.

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


As a result, we received our server for receiving data 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 (tracker for cargo) and others. As a further improvement, you can suggest porting the server program under Linux and make a bundle with Google Spreadsheet to save information about points. 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 the official or third-party servers receiving and processing data.

* update 02.02.2015
After the release of the article, Startcom removed the link to their device configuration program.