G
G
GloooM2012-08-22 10:41:19
Microcontrollers
GloooM, 2012-08-22 10:41:19

Reverse the encryption protocol in a closed device. Is it possible to?

There is a system of two devices communicating via a digital bus, the first device controls the equipment, the second device allows or prohibits the first work based on the read RFID tags.

It is implemented in such a way that when the first device tries to turn it on, it sends some apparently random sequence of the form “43 50 47 9d e0 d1 21 8e” to the second device, which in turn converts it to “66 e8 f4 4f a0 d8 de 71” and work is allowed. Apparently the first device compares with the result known to him in advance. The transformation algorithm always gives the same output answers for the same requests, it does not change over time.
The RFID tags themselves read by the second device do not affect the encryption algorithm either, any read tag leads to encryption with one algorithm. But the algorithm changes every time the labels are trained, and apparently devices 1 and 2 exchange some key during this service procedure in order to work in pairs later.

The task is to emulate the behavior of the second device, i.e. to analyze the algorithm by which the transformations are made. From the initial data, you can get as many pairs of input-output values ​​as you like, and presumably there is a key from the learning process (I don’t know if it is also somehow encrypted or not).

By not cunning analysis, I managed to understand myself that out of 8 bytes, the last 2 in the response are simply the inverted last two bytes of the request and do not change from the encryption key. Accordingly, 6 bytes remain for analysis.

For the supposed key "30 95 ca 3b c8 98 5e 84" The
pairs look like this:
Input: 00 00 00 00 00 00
Output: 62 1e af 7c da 27

Input: 01 00 00 00 00
Output: dd 3e 53 d6 50 05

For the key "39 72 98 4e 69 4a 6b af"
In: 00 00 00 00 00 00
Out: 2d c2 cb 75 4e ec

In: 01 00 00 00 00 00
Out: 2d d1 32 2c e4 69

From observations, the first 4 bytes seem to be encrypted in a separate block, and their result is not affected by 5 and 6 bytes in the request. When changing 5 and 6 bytes in the request, only 5 and 6 bytes also change in the response, but when the first 4 in the request change, 5 and 6 also change in the response. In general, encryption of 5 and 6 bytes seems to depend on the results of encryption of the first four.

Is it even possible to determine the encryption algorithm by these parameters? Or is it a bad job if there is no access to the firmware? Maybe it's some well-known algorithm? The microcontroller in the second device that deals with encryption is PIC16.

Answer the question

In order to leave comments, you need to log in

4 answer(s)
H
hijaq, 2012-08-22
@hijaq

It's easier to remove the firmware from the peak and reverse it already.
ps Something very similar to the operation of a car alarm / immobilizer.

H
hijaq, 2012-08-22
@hijaq

Of course, it is locked, but as far as I know, this is not a big problem. In any case, 100% is removed from PIC16.

H
hijaq, 2012-08-22
@hijaq

I'm talking about the option of using specially trained people for this.

Z
zed91, 2012-08-22
@zed91

There is a head-on way: to collect as many answers as possible and look for patterns. Or, as already written, reverse engineer the firmware.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question