XELTEK adapter cloning protection mechanism

Foreword

This story began with the fact that we somehow needed to read / write a FLASH memory chip like SPANSION S29GL512 in the TSOP56 package. Until this time, we have successfully operated the XELTEK SuperPro 500P programmer. But, unfortunately, the socket installed in it with 48 contacts did not allow this to be done even with the use of an adapter. It goes without saying that in the PC program for this programmer there was no support for such microcircuits.

It’s time to update, we decided, and purchased (do not count for advertising) a programmer of the same manufacturer of the SuperPro 6100 model, which uses interchangeable adapters with various sockets. We also separately purchased the necessary, as it seemed to us, adapter of the CX1011 model with the TSOP56 socket (an adapter with the ZIF48 socket was included with the programmer).


We agree in the future to call the programmer program simply software, because the “programmer program” does not sound very aesthetically pleasing.

After receiving all this, we assembled the designer from the programmer with the adapter and tried to start working with it.



But after the desired microcircuit was selected in the software, the programmer squeaked several times and the mysterious inscription “ERROR CODE: 1D” appeared on its display. Software also cursed the message that this adapter is not suitable for programming this chip. How so!? The adapter with the programmer got married successfully, the chip with the socket, too, but the evil manufacturer decided that this was not enough and the user, in addition to the new programmer, would definitely have to buy the “new” DX1011 adapter. For which, incidentally, on the manufacturer’s website they want about three hundred evergreens. Well, okay, in our case we bought it by mistake, although there was still no desire to acquire a “new” one. But after all, someone could save it from the old programmer, but someone might want to make it yourself.

In preparing this material, we did not set the goal of teaching the reader to use various programs and hardware devices that had to be used along this path. Therefore, we will not clog the article with a description of the intricacies of working with all this toolkit, leaving it behind the scenes. But if someone is interested in the details, we will be happy to comment on them.

Here it’s just right to bring the text of the disclaimer of liability, the meaning of which is that the author does not bear any responsibility for any use by you of the materials in this article. In other words, only you yourself will be responsible for your actions, which you may be encouraged to familiarize yourself with this material.

Exploratory survey

A review of the adapter made it possible to detect an octopus chip with the inscription AE801 on it, the documentation for which on the Internet, of course, was missing. This chip is clearly visible in the right corner in the photograph of the CX1011 adapter above.

Although some information about this chip was still found. On the XELTEK website in the FAQ sectionin response to the question: “What is the difference between SuperPro 6000 and 6100 programmers?” there is a curious phrase: “CX series adapters (for 6000 programmers) and DX (for 6100 programmers) are exactly the same except for the chip ID, which uses the advanced adapters in the DX series adapters protection. ”It became clear that this chip is a kind of ID chip, which is used by the programmer to identify the adapter installed in it. That's just about what kind of protection we are talking about: from whom or from what should the adapter be protected? Well of course from you and me!

This protection is similar to that which is now universally used in printer cartridges so that they are not refilled, but bought new ones. But here the situation is somewhat different. You get an expensive adapter on your money and hope that you will use it forever. There it was! The manufacturer prudently took care of this and, likening the Creator himself, decided to artificially limit the adapter to its mortal life. In confirmation of which, the following significant messages are found in the software:

- “Socket adapter end-of-life is near. Please prepare to replace with a new one. ”
-“ Adapter usage beyond its cycle life, please change. ”

How do you like this pearl: “The life of the adapter is coming to an end”? And especially the phrase "replace with a new one", so caressing the hearing of the sales department.

For some reason, on the XELTEK website on the page with adapters about their frailty - not a word! To paraphrase one well-known saying about the goat and button accordion, I just want to say: “What for the adapter is protected”?

But be that as it may, the need to still read / write the FLASH memory chip (which, I must say, we have already forgotten, carried away by everything else) and an irresistible desire to alleviate the fate of the unfortunate, doomed to inevitable death of the “patient” ”Adapter made us move on.

Preparation for treatment

We agree in the future to call the PC, on which the software for the programmer works, the host.

A USB interface is used to exchange data between the host and the programmer, and it has several USB channels (Pipes). On one of the USB channels, the host sends commands to the programmer, on the other sends data to it, on the next it receives data from the programmer.
It was necessary to identify the interface for exchanging data between the AE801 and the programmer itself. Then the manufacturer did not philosophize, using the good old UART with a speed of about 10,500 baud. The AE801 chip, which is essentially an eight-legged microcontroller, has legs 1 and 4 connected to ground, + 5V power is supplied to leg 8, leg 3 is used for bi-directional data transmission via UART, leg 7 is used as positive CS, and to leg 6, simultaneously with the appearance of a unit on leg 7, a clock frequency of 4 MHz is supplied. Of the eight-foot microcontrollers known to us, the ATMEL ATtiny25, 45, 85 series are best suited for this pinout. However, the SOIC8 case used for them is somewhat wider than necessary.

When studying the data exchange between the AE801 on the adapter and the programmer, one interesting thing was discovered: when choosing a chip in the software, even before the AE801 chip was selected on the adapter, some data packets appeared on its leg 3. It turned out that before the start of communication with the microcircuit from the adapter, the programmer communicates with someone else. Later it turned out that the same AE801 chip was installed in the programmer, sitting on the same bi-directional data bus as the AE801 from the adapter. And it serves the same purposes - protection against cloning, but now the programmer itself.

Further, the software on the host was modified to save the data exchange procedure between it and the programmer in a log file. From the received log it became completely clear that nothing was clear. The data exchange was somehow encrypted and noisy with garbage. Apparently this was the very “improvement of defense". But one thing became obvious - the adapter tells the programmer the name of his model directly in text form and his age, so that he can be sent on time for a well-deserved, according to XELTEK, rest. Everything else is trash.

Through further study, it turned out that the protection algorithm was written by a person very far from this topic. The so-called "advanced protection" does not hold water.
However, it was not possible to figure out the log in the forehead and it became obvious that now you have to move inside the programmer itself. Its electronic filling looks like a layer cake, in the form of many separate boards connected together by racks and connectors.


One of these boards (let's call it, by analogy with a PC, “motherboard”) contains an ATMEL AT91SAM9G20 ARM microcontroller, SDRAM, SPI FLASH with firmware, the same AE801 ID chip with a programmer model and its serial number, a USB controller chip and a number of other chips .


Another board is equipped with the XILINX chip, which, together with other boards with transistor assemblies, controls the legs of the chip on the adapter connected to the programmer during read / write procedures, etc.


All ARM microcontroller firmware is contained in an external SPI FLASH chip, which, of course, also does not contribute to the strengthening of protection. Typically, the bootloader is hidden in the internal memory of the microcontroller, inaccessible for reading, and firmware or updates placed outside are encrypted. But the developers from XELTEK decided to go the other way, confused with the proprietary AE801 chips, leaving the ARM firmware to be torn to pieces. What we, in fact, did next.

The idea was to disassemble the “usb” file of the programmer algorithm and then assemble the project in one of the ARM IDEs, so that through the JTAG, having the source in assembler, study the programmer's operation in terms of its communication with the AE801 chip.

On the motherboard, by the way, a place was provided for the JTAG connector. For ease of debugging, the JTAG connector was mounted on the side of the plastic housing of the programmer and connected to the motherboard with a flat cable.


The result is a kind of Development Kit.


Since we had a JTAG OLIMEX ARM-USB-OCD, preserved from some old project, the choice of ARM IDE fell on the IAR Embedded Workbench, because it supports debugging via the GDB server. However, setting up this very GDB server turned out to be a very tricky task. And it took some time to get the project assembled from the assembler source to start loading into the SDRAM of the programmer and have the opportunity to debug it.

After everything finally worked out from under the debugger, some of the most “interesting” methods of the algorithm were rewritten in C to make it easier to understand. Thus, we gradually managed to accumulate information that allowed us to understand the mechanism of the programmer, which is described below in a somewhat simplified form.

When the programmer's power is turned on, its built-in bootloader (conditionally zero) starts working in the ARM microcontroller, which loads another bootloader (call it first) from SPI FLASH into its internal RAM, remaps this RAM to address 0 and transfers control to the first bootloader. Starting work, the first bootloader configures the controller in the ARM-e SDRAM, thus connecting external RAM to the address 0x20000000 and rewrites another bootloader (let's call it second) from the same SPI FLASH and transfers control to it. The second bootloader configures the external USB controller chip to communicate with the host, displays a string on the LCD screen with the name of the programmer and firmware version, communicates with its own AE801 ID chip and, as a result, enters the command processing cycle from the host.

To work with each type of memory chip, its own firmware for the ARM microcontroller, called the algorithm, has been created. Algorithm files have the extension “usb” and are stored on the host in the directory “algoX” with the installed program. The “lib” directory contains firmware for the XILINX chip and files with the “wls” extension, which contain information about the correspondence of the desired algorithm to each chip supported by the programmer, the type of adapter required for this chip, as well as some additional parameters for each chip. For example, its supply voltage, programming voltage, etc.

After a chip is selected in the software, you need to make sure that the corresponding adapter is installed in the programmer. To do this, the host sends a command to the programmer - a request such as the adapter installed in it. The programmer requests the AE801 chip from the adapter for its type and sends a specially formed response back to the host. The software on the host compares the adapter type from the “wls” file with the adapter type from the response and, if they match, sends the next bootloader (let's call it third) to the programmer at 0x20020000 - the file “loader.bin” located in the bin directory. After transferring control to the third bootloader, the host with its help downloads the algorithm corresponding to this type of microcircuit at the address 0x20000000 (the “usb” file), the firmware for XILINX and, as a result, transfers control to the loaded algorithm. After some hardware settings, the algorithm, in turn, again falls into the cycle of processing commands from the host. An intermediate third loader is needed only so that the working algorithm is loaded every time at the same address 0x20000000.

When you select another chip in the software, the entire procedure described above is repeated, starting with a request by the host such as the adapter installed in the programmer.

After the algorithm loaded into the programmer enters the command processing cycle from the host, all further actions are activated only by these commands. In other words, the host becomes the master, and the programmer is the slave. The AE801 microcircuit from the adapter is slave with respect to the programmer and after the active high level is applied to its leg 7 (CS), and the 4 MHz clock leg 6 also goes into the command processing cycle from the programmer. Leg 3 of the AE801 chip is initially configured to receive commands from the programmer. After sending the next command, the programmer sets up the data line for reception, and the AE801, respectively, transfers its leg 3 for transmission and sends data to the programmer. Thus, data is exchanged between the AE801 in the adapter and the programmer.

Treatment

So, we directly approached the consideration of the protection mechanism of the DX series adapters.

As mentioned earlier, in order not to overload the article with unnecessary details, we will provide here only the quintessence of the path traveled - a description of the data exchange process between the programmer and the ID chip AE801.

The terminology used in this description:

• The term “leg” refers to the corresponding terminals of the AE801 chip.
• Byte count - starting from one.
• Each time, the programmer, having sent a certain number of bytes to the microcircuit, transfers the data line to receive, and the microcircuit, having received this data, switches leg 3 to transmission, etc. Therefore, the description of these switches and the mention of legs 3 will not be given.
• The narration is on behalf of the chip AE801.

1. If leg 7 has an inactive low level, leg 3 is set to enter and we are either in a reset or in a sleep state.

2. When the programmer sends active high level to the foot 7 (the 6 MHz clock frequency is applied to the foot 6), we must transfer 6 random bytes to the programmer.

It is known that to use the algorithm for generating random, or rather pseudorandom numbers from the standard library C, you must first call the srand () command, passing it a certain number as an input argument - a salt, using which each call to the rand () command will return the next value from defined by this number of pseudo-random sequence. In PC, time () is usually used as the source of entropy for srand (), but simple microcontrollers, as a rule, do not have a real-time clock, and this problem can be solved, for example, by saving a new value for srand () every time after reset in EEPROM. Most likely, this is exactly how it was implemented in the AE801. By and large, we generally do not need to generate random numbers, but the solution to this problem seemed interesting.

We implemented the prototype AE801 on a Microchip microcontroller (at that moment it was just at hand), which worked from its own internal generator at a frequency of 8 Mhz and with respect to it an external frequency of 4 MHz coming to pin 6 was acceptable (and, perhaps the only) source of entropy.

Leg 6 in the program was used as a digital input, and from it in the loop 16 bits were read, which were necessary for transmission to the srand () method.

3. We get 9 bytes from the programmer and confirm their receipt by sending the sixth byte received to the programmer.

4.We get 5 bytes from the programmer. The first of the five bytes received is sent to the programmer as is, and the remaining 4 bytes are encrypted using the RSA algorithm in 4 16-bit words and sends the received 8 bytes to the programmer. Moreover, for each of the words received after encryption, the high byte is sent first, and then the low byte. In conclusion, once again we send to the programmer the first of the received five bytes. Total 10 bytes.

As an encryption algorithm, RSA with very short keys 63, 847 and 2773 was used. Anyone who is interested can find information about this, for example, HERE .

In the algorithm firmware, a cycle of 2773 iterations is used to calculate RSA. But since the input number for encryption is a byte, and the output is a two-byte word, to simplify the RSA calculation, a table of 256 words was formed, which took an extra 512 bytes of program memory.


5. We get 1 byte from the programmer and store it as a marker. After that we send random 4 bytes to the programmer. The programmer, having received these 4 bytes, encrypts them in exactly the same way as in step 4 using the same RSA algorithm and sends us the resulting 8 bytes in the same order (first high, then low byte from each word). Having received these 8 bytes, we must check whether the programmer coped with the task and, in the case of a positive answer, we send him the marker received earlier.

6.We get 1 byte from the programmer and again remember it as a marker. Then we form, say, buf11 - 11 random bytes in the array and save it for subsequent actions. Then, in a cunning way, we send these 11 bytes to the programmer. The trick is that we have to send 88 bytes to the programmer into which the 11 formed by us will be packed, and the least significant bit of the marker is used to invert the transmitted 11 bytes. After sending 88 bytes to the programmer, we send the received marker to it.


7. We get 1 byte from the programmer and send an array of 133 bytes, consisting of four parts, into it.

The first part - 48 bytes with information about the type of adapter and its “age” was taken from the native adapter “DX0001”, in which the text “DX0001” was replaced by “DX1011”.


The second part is 16 random bytes.

The third part is 22 bytes, specially formed from 11 bytes stored earlier in buf11.


The fourth part is 47 random bytes.

8. After transmitting an array of 133 bytes, the microcircuit should either go to sleep until the next active high level appears on leg 7, or it will automatically go into a reset state, if leg 7 is a reset signal. And then everything is repeated, starting from paragraph 2.

Extract of the recovered patient

In the end, the CX1011 adapter was safely put on its feet and got a second life in the new programmer.

We hope that the material in this article will help readers safely revive other "old" adapters, and possibly make their own.