XELTEK Adapter Cloning Protection Mechanism

Foreword

This story began with the fact that we somehow needed to read / write a FLASH memory chip of the SPANSION S29GL512 type in the TSOP56 package. Until that time, we had successfully exploited the XELTEK SuperPro 500P programmer. But, unfortunately, the socket with 48 contacts installed in it did not allow this to be done even with the use of an adapter. Of course, there was no support for such chips in the program on the PC for this programmer.

It's time to upgrade, we decided, and purchased (do not consider advertising) a programmer from the same manufacturer of the model SuperPro 6100, which uses interchangeable adapters with different sockets. Also separately purchased was the necessary, as it seemed to us then, adapter of the CX1011 model with a TSOP56 socket (an adapter with a ZIF48 socket was included with the programmer).


Let us further agree to call the programmer program simply a software, because the “programmer program” does not sound very aesthetic.
')
After receiving all this, we collected a constructor from the programmer with an adapter and tried to start working with it.



But after the required chip was selected in the software, the programmer squeaked several times and the mysterious inscription “ERROR CODE: 1D” was displayed 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 happily, the chip with the socket too, but the malicious manufacturer decided that this is not enough and the user, in addition to the new programmer, must also purchase the “new” adapter DX1011. For which, by the way, 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, and someone might want to make it yourself. So for this particular audience this article.

In preparing this material, we did not set out to teach the reader to use various programs and hardware devices that had to be used along the way. Therefore, we will not clutter the article with a description of the subtleties of working with all these tools, 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 cite the text of the disclaimer about liability, the meaning of which is that the author is not responsible for any use you make of the materials in this article. In other words, only you yourself will be responsible for your actions, to which you may be encouraged to become familiar with this material.

Exploratory survey

An overview of the adapter made it possible to detect on it an octopus microcircuit labeled AE801, of which there was, of course, no documentation on the Internet. This microcircuit is clearly visible in the right corner in the photo of the CX1011 adapter above.

Although some information about this chip is still found. The XELTEK website in the FAQ section answers the question: “What is the difference between the SuperPro 6000 and 6100 programmers?” There is a curious phrase: “The CX series adapters (for 6000 programmers) and DX (for 6100 programmers) are absolutely the same, except for the ID chip, which in adapters of the DX series uses advanced protection. ”It became clear that this chip is a kind of ID chip that the programmer uses to identify the adapter installed in it. That's just what kind of protection is it: from whom or from what does the adapter need to be protected? Well, of course from us with you!

This protection is similar to the one that is now commonly used in printer cartridges so that they are not refilled and bought new ones. But here the situation is somewhat different. You get an expensive adapter for your money and hope that you will use it forever. Not here it was! The manufacturer of this prudently took care of and, having become like the Creator himself, decided to artificially limit the adapter to the period of his mortal life. In confirmation of this, 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: “Adapter life expires”? And especially the phrase "replace with a new one", so caressing the ear of the sales department.

For some reason, on the XELTEK website on the page with adapters about their perishability - not a word! Paraphrasing one famous saying about a goat and a button accordion, I just want to say: “What about protection adapter?”

But be that as it may, the need to still read / write a FLASH memory chip (which, I must say, we have forgotten, carried away by everything else) and an irresistible desire to by all means alleviate the plight of the unfortunate The adapter made us move on.

Preparation for treatment

We will further agree to call the PC on which the software for the programmer is running as the host.

For data exchange between the host and the programmer uses a USB interface, and in it several USB channels (Pipes). The host sends commands to the programmer via one of the USB channels, sends data to it via the other, and receives data from the programmer through the next.
It was necessary to identify the interface for data exchange between the AE801 and the programmer itself. Here 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, legs 1 and 4 are connected to ground, + 5V is powered to foot 8, foot 3 is used for bidirectional data transfer via UART, foot 7 is used as positive CS, and to foot 6, simultaneously with the appearance of the unit on the leg 7, the clock frequency is 4 MHz. Of the eight legs that we know of microcontrollers, ATMEL of ATtiny25, 45, 85 series is best suited for this pinout. However, the SOIC8 package 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 is selected on the adapter, some data packets appear on its leg 3. It turned out that there is even before the start of communication with the chip from the adapter, the programmer communicates with someone else. Later it turned out that the programmer itself has the same AE801 chip, sitting on the same bi-directional data bus as the AE801 from the adapter. And it serves the same purpose - protection from 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 to a log file. From the received log it became absolutely clear that nothing is clear. The data exchange was somehow encrypted and noisy with garbage. Apparently that was precisely the “improvement of protection”. But one thing became obvious - the adapter informs the programmer of the name of its model, directly in text form, and its age, so that it can be sent in a timely manner to a well-deserved, in the opinion of XELTEK, rest. Everything else is rubbish.

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


One of these boards (let's call it, by analogy with a PC, “motherboard”) contains an ARM microcontroller ATMEL AT91SAM9G20, 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 XILINX microcircuit is installed on one motherboard, which, together with the other motherboards with transistor assemblies, controls the legs of the microcircuit on the adapter connected to the programmer during read / write procedures, etc.


The entire ARM microcontroller firmware is contained in the external SPI FLASH chip, which, of course, also does not contribute to the increased protection. Usually, the bootloader is hidden in the internal memory of the microcontroller, which is inaccessible for reading, and the firmware or updates placed outside are encrypted. But the developers of XELTEK decided to go the other way, confusing themselves with proprietary AE801 chips, leaving the ARM firmware to be torn apart. What we actually do next.

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

On the motherboard, a place for the JTAG connector was provided by the way. For easy 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 was a kind of Development Kit.


Since we had 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 through the GDB server. However, setting up this very GDB server turned out to be a very intricate task. And it was necessary to spend some time to get the project assembled from the assembler source code into the SDRAM programmer and 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 to C to make them easier to understand. Thus, gradually managed to accumulate information, which allowed to understand the mechanism of the programmer, which is described below in a somewhat simplified form.

When the programmer is powered on, its built-in bootloader (conditionally zero) starts up in the ARM microcontroller, loads another bootloader from SPI FLASH (let's call it first) into its internal RAM, remaps this RAM to address 0 and transfers control to the first bootloader. Having started work, the first loader sets up the controller in ARM-e SDRAM, thus connecting the external RAM at 0x20000000 and rewrites another bootloader (let's call it second) from the same SPI FLASH and transfers control to it. The second loader configures the external USB controller chip to communicate with the host, displays the screen with the name of the programmer and the firmware version on the LCD, communicates with its own ID chip AE801 and eventually enters the command processing loop from the host.

To work with each type of memory chips created its own firmware for ARM microcontroller, called the algorithm. Algorithm files have the “usb” extension and are stored on the host in the “algoX” directory with the installed program. The “lib” directory contains firmware for the XILINX chip and files with the “wls” extension, which contain information on the correspondence of the required 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 choosing a chip in the software, you need to make sure that the corresponding adapter is installed in the programmer. For this, the host sends a command to the programmer — a request of the type of adapter installed in it. The programmer asks the AE801 chip from the adapter for its type and sends the generated response in a special way 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 the third) to the programmer at 0x20020000 - the “loader.bin” file located in the “bin” directory. After transferring control to the third loader, the host with its help loads the algorithm (usb file) corresponding to this type of chip to the address 0x20000000, the firmware for XILINX and eventually transfers control to the loaded algorithm. After some adjustments of the hardware, the algorithm, in turn, again falls into the loop of processing commands from the host. The intermediate third loader is needed only so that the working algorithm is loaded each 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 from the host for the type of adapter installed in the programmer.

After the algorithm loaded into the programmer enters the loop of processing commands from the host, all further actions are activated only by these commands. In other words, the host becomes the master, and the programmer the slave. The AE801 microcircuit from the adapter is slave with respect to the programmer and, after feeding on its leg 7 (CS), an active high level, and for the leg 6 clock frequency 4 MHz 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, its leg 3 for transmission and sends the data to the programmer. Thus, data is exchanged between the AE801 in the adapter and the programmer. Data is exchanged between the internal AE801 on the motherboard and the programmer in exactly the same way.

Treatment

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

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

Terminology used in this description:

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

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

2. When the programmer gives active high level to leg 7 (leg 6 of 4 MHz is supplied to leg 6), we have to transfer 6 random bytes to the programmer.

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

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

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

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

4. We receive from the programmer 5 bytes. The first of five received bytes is sent to the programmer as is, and the remaining 4th ones are encrypted using the RSA algorithm in 4th 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. Finally, we send the first five received bytes to the programmer again. Total 10 bytes.

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

In the firmware of the algorithm, the 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 calculation of RSA, a table of 256 words was formed, which took an extra 512 bytes of program memory.


5. We get from the programmer 1 byte and remember it as a marker. After that we send random 4th bytes to the programmer. The programmer, having received these 4 bytes, in the same way as we in paragraph 4 encrypts them using the same RSA algorithm and sends us the resulting 8 bytes in the same order (first the highest, then the low byte from each word). Having received these 8 bytes, we have to check whether the programmer has coped with the task and, if the answer is positive, we send him the previously received marker.

6. We receive from the programmer 1 byte and again we remember it as a marker. Then we form in the array, say, buf11 - 11 random bytes and save it for subsequent actions. Then, in a sly 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 low 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 receive from the programmer 1 byte and send to it an array of 133 bytes, consisting of four parts.

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 the previously saved buf11 11 bytes.


The fourth part - 47 random bytes.

8. After transmitting an array of 133 bytes, the microchip should either go to sleep until the next active high level appears on pin 7, or it automatically switches to the reset state, in case pin 7 is a reset signal. And then everything repeats, starting with paragraph 2.

Extract recovered patient

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

Hopefully, the material in this article will help readers safely revitalize other “old” adapters, and perhaps make their own.