3

I'm a newbie, so I'm asking for your help.

I have to decode dumped data from an appliance because I wanted to try understand the data.

The data are in this format and some information are known:

7E 00 20 10 75 00 00 00 07 5F C7 6F 4F 01 05 C8 .. .. .. (some other bytes that are the same for each packet)

7e = start framing (Does not change)

20 = length of packet (Does not change)

10 75 = packet type (Does not change)

00 00 00 07 = incremental number, when it reach 00 00 00 FF, the next is 00 00 01 00 when checksum is failed the appliance retries with same number.

5F C7 6F 4F hex timestamp (unix timestamp converted in hexadecimal)

01 ALTERNATING VALUE 01 or 21 (this value alternate on each received packet)

05 MISTERY BYTE, i'll explain later

C8 checksum calculated with the sum of incremental number plus hex timestamp, then mod 256 and subtracted with 0x03 when the alternating value is 21 or 0x23 when alternating value is set to 01. When the resulting value is negative you have to discard all FF FF and take the last byte.

The problem is the mistery byte.

At first glance seems to be:

When last byte of timestamp is greather than checksum, the mistery byte is: 06, else is 05. But sometimes this value is "07"

Here another example:

7E 00 20 10 75 00 00 00 08 5F C7 71 73 21 06 0F .. .. ..

checksum calculation method: 00 + 00 + 00 + 08 + 5F + C7 + 71 = 0x212 (decimal 530)

530 mod 256 = 18

decimal 18 to hex = 12

because the alternating value is 21, i have to subtract 0x3 -> 12 - 0x03 = checksum = 0F

now the last byte of checksum 73 is greather than 0F so the result of mistery byte seems correct to be 06

the problem comes when mistery field is sometimes 07. I think that this value is not merely a comparing with last byte of timestamp with checksum, but i missed something.

7E 00 20 10 75 00 00 00 87 5F C7 7B ED 21 07 12

7E 00 20 10 75 00 00 00 88 5F C7 7B FF 01 07 05

Here some other example that seems 06 alternate with 07:

7E 00 20 10 75 00 00 00 D0 5F C7 80 89 01 06 DC

7E 00 20 10 75 00 00 00 D1 5F C7 80 8F 21 07 03

7E 00 20 10 75 00 00 00 D2 5F C7 80 95 01 06 EA

7E 00 20 10 75 00 00 00 D3 5F C7 80 96 21 07 0C

7E 00 20 10 75 00 00 00 D4 5F C7 80 9B 01 06 F2

but soon there are 07 for a lot of rows

7E 00 20 10 75 00 00 00 D9 5F C7 80 A9 21 07 25

7E 00 20 10 75 00 00 00 DA 5F C7 80 AA 01 07 07

7E 00 20 10 75 00 00 00 DB 5F C7 80 AA 21 07 28

some examples with "05" mistery byte.

7E 00 20 10 75 00 00 01 09 5F C7 82 00 21 05 AF

7E 00 20 10 75 00 00 01 0A 5F C7 82 05 01 05 95

7E 00 20 10 75 00 00 01 0B 5F C7 82 26 21 05 D7

7E 00 20 10 75 00 00 01 0C 5F C7 82 2C 01 05 BE

Any clue of what this mistery byte is used for?

2

Looks like it's just addition for the checksum, so nice job on that.

The mystery byte is part of the checksum.

The accumulator is 2 bytes.

data = """0000AAAAAA7E00201075000000075FC76F4F0105C8
0000AAAAAA7E00201075000000875FC77BED210712
0000AAAAAA7E00201075000000885FC77BFF010705""".strip().split("\n")

import struct

for i,l in enumerate(data):
    xs = bytes.fromhex(l)
    body = xs[:-2]
    xsum = xs[-2:]

    v = 187
    for b in body:
        v+=b

    
    print("msg",i,"body",body.hex(),"checksum",xsum.hex(),"calcxsum",struct.pack(">H",v).hex())

Run:

$ python3 xsumtest.py 
msg 0 body 0000aaaaaa7e00201075000000075fc76f4f01 checksum 05c8 calcxsum 05c8
msg 1 body 0000aaaaaa7e00201075000000875fc77bed21 checksum 0712 calcxsum 0712
msg 2 body 0000aaaaaa7e00201075000000885fc77bff01 checksum 0705 calcxsum 0705
5
  • Thanks. I guessed part of the algorithm by myself, observing similitude with other checksum calculation method. Here the complete payloads pastebin.com/mkXc3Wkd (i can't execute your script, tried with python3.7.3 and i receive IndexError: list assignment index out of range) Dec 6 '20 at 18:39
  • Do you have more messages which have a different length? I think the mystery byte is part of a 2byte flag field. Dec 6 '20 at 20:11
  • Updated answer , it's a 2byte checksum with a 1byte stride with an initialization of 187. haha. Dec 6 '20 at 20:27
  • Thank you, very helpful! Dec 6 '20 at 23:27
  • If you have any more binary messages you'd be comfortable sharing, I'd appreciate it. I'm working on some research to automate these sorts of tasks. Dec 7 '20 at 0:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.