help cracking the checksum code.

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm working on a CAN bus and there is a particulate set of data that generates some type of checksum. I have looked at it far too long and can not nail this down.

 

Code explained

 

10 8E 2E 20 23 30 30 30 this is a header line 8e is the length 20,23,30,30,30 are the first 5 bytes. 
                the checksum code is the first 11 bytes. 30,30,30,30,30,30,34,38,32,25,23
21 30 30 30 34 38 32 35 the first byte of each line is a line number or sorts.
22 35 30 30 30 30 30 30  
23 30 30 30 30 20 16 4  
24 4 4F 2D 42 5 10 0  
25 24 0 2 40 0 0 0  
26 0 0 0 4F 2D 2 5  
27 10 0 24 0 2 40 0  
28 0 0 0 0 0 30 68  
29 0E 21 8C 0 8 61 95  
2A 33 48 7 C0 40 2 0  
2B 0 0 0 19 0 80 4  
2C 0 0 0 0 0 1 43  
2D 11 24 0 1 2 0 8  
2E 43 0E 96 0 0 38 4  
2F 25 0 2 51 8B 2 6  
20 B1 20 42 7 51 40 13  
21 4B B0 0 3A 0 3 80  
22 11 45 0F 0 0 0 0  
23 0A 80 0 0 84 0 0  
24 0 0 0        

 

 

Here is another example.  You will notice the 11 bytes are now changed

 

10 8E 2E 20 23 30 30 30                                                                                                                               
30 0 0            
21 30 30 30 34 32 30 34 changed checksum
22 35 30 30 30 30 30 30  
23 30 30 30 30 20 16 4  
24 4 4F 2D 42 4 10 0  
25 24 0 2 40 0 0 0  
26 0 0 0 4F 2D 2 4  
27 10 0 24 0 2 40 0  
28 0 0 0 0 0 30 68  
29 2E 21 8C 0 8 61 95 you can see here that 0e is now 2e
2A 33 48 7 C0 40 2 0  
2B 0 0 0 19 0 80 4  
2C 0 0 0 0 0 1 43  
2D 11 24 0 1 2 0 8  
2E 43 0E 96 0 0 38 4  
2F 25 0 2 51 8B 2 7 6 is now a 7
20 B1 20 42 7 51 40 13  
21 4B B0 0 3A 0 3 80  
22 11 45 0F 0 0 0 0  
23 0A 80 0 0 84 0 0  
24 0 0            

 

 

I do not have much data so this is becoming tricky. Here is one other set of data I was able to capture(see *'s for changed data). Can anyone make heads or tails of this I just can not get any calculations to mach up?

 

 

10 8E 2E 20 23 30 30 30
30 0 0          
21 30 30 30 32 37 37 35
22 33 30 30 30 30 30 30
23 30 30 30 30 20 16 4
24 4 4F 2D 42 4* 10 0
25 24 0 2 40 0 0 0
26 0 0 0 4F 2D 2 4*
27 10 0 24 0 2 40 0
28 0 0 0 0 0 30 68
29 0E 21 8C 0 8 61 95
2A 33 48 7 C0 40 2 0
2B 0 0 0 19 0 80 4
2C 0 0 0 0 0 1 43
2D 11 24 0 1 2 0 8
2E 43 0E 96 0 0 38 4
2F 25 0 2 51 8B 2 6
20 B1 20 42 7 51 40 13
21 4B B0 0 3A 0 3 80
22 11 45 0F 0 0 0 0
23 0A 80 0 0 84 0 0
24 0 0        

 

Last Edited: Wed. Apr 6, 2016 - 01:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't know about you but when I see a string of bytes in the 30 to 39 range my first thought is ASCII decimal string. Have you looked at this data in a binary editor that shows ASCII alongside?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very observant ;)

 

looking at the first

30 30 30 30 30 30 32 37 37 35 33

 0   0   0   0   0   0  2    7   7   5  3  ( assuming hex )

 

 

So far nothing stands out but I'm looking. Wondering if they are doing a simple additional string.

Last Edited: Wed. Apr 6, 2016 - 01:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Absolutely NOT correct, but what a coincidence...

 

sum of all (assuming decimal) 0   0   0   0   0   0  2    7   7   5 = 21 which if we sum 2 and 1 => 3

 

Couldn't be that simple surely?

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah I don't think that it but that is an interesting coincidence.

 

30303030 30 30 34 32 30 3435

  0  0   0  0  0  0   4   2    0   4  5

=10  but 1 and 0 != 5

 

Also on my last theory... I tried to add everything up, and only got 3708 no where near 277753 and no addition  would go up 20k for a few changed bits.

 

 

Last Edited: Wed. Apr 6, 2016 - 02:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In talking with a automobile engineer, he believes it is a seed and key security byte string for the 14229 (UDS) protocol. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After some more investigation it turns out this is not the security challenge and rather just an ascii number.  This number has to do with the data but still at a complete loss as to how it arrives at this number. Simply changing two bits makes it go up 10,000 so it has some level of bit logic I would think. The best as I can tell the data that requires a change starts on the first 24 line

  4 4f 3d 42 5 10 0                                                                                                                                                  

and ends on the second 24 line (bytes 27 to 141)

24 0 0 0                                                                                                                                        
     

I took one set with a header of 48255 and added up all of the bytes from 27 to 141 and got 3779

or

 a header of 27753 and added up all of the bytes from 27 to 141 and get 3777,

 

don't see a connection there. 

Last Edited: Fri. Apr 8, 2016 - 01:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oops

Last Edited: Fri. Apr 8, 2016 - 03:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:

Very observant ;)

 

looking at the first

30 30 30 30 30 30 32 37 37 35 33

 0   0   0   0   0   0  2    7   7   5  3  ( assuming hex )

 

 

So far nothing stands out but I'm looking. Wondering if they are doing a simple additional string.

Not sure why you'd assume hex, considering all the digits seem to be 0 - 9

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

maybe misunderstanding?

 

In hex you you get

30 30 30 30 30 30 32 37 37 35 33

 0   0   0   0   0   0  2    7   7   5  3 

 

is they were decimal you would get

30 30 30 30 30 30 32 37 37 35 33

30 = record seperator

32 = space

33 = !

35 = #

37 = %

 

To me it just seem logical that the data represented is hex. Though the real question is why have the output data in ASCII? ASCII is normally used for human readability no? It's clear that the 11 bytes hold some type of config to the data below but I don't see the need for ASCII in this case. And what makes things even more confusing is that the output ASCII is all numeric. So there would be no need for ASCII as you could represent 0-9 in both decimal and HEX just as well.

 

 

 

Last Edited: Mon. Apr 11, 2016 - 01:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The data are BINARY and can be interpreted in many ways.

Hex and Ascii are two different human-readable representations of binary data.

 

In your most recent post, you have offered two different interpretations of the Hex representation of the binary data.

Last Edited: Mon. Apr 11, 2016 - 05:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"30 30 30 30 30 30 32 37 37 35 33"
Call it what you want, there is simply no doubt that these are intended to be representative of the human readable string "00000027753"

 

SpiderKenny
@spiderelectron
www.spider-e.com

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

in my first example binary 110000  -> hex 0x30 -> asci value 48 = character '0'

in my second example binary 11110 -> Decimal 30-> asci value 30= record seperator

 

When I said assuming hex I simply meant that the source data must be hex as decimal would not make any sense. Though none of that has to do with my question, it was John_A_Brown's question or a flaw in my logic he was pointing out.

 

The question is why represent data in a packet as hex through out and the header in ASCII?

 

If I wanted to do a parity check on data, I would do my xor math and then display the result in Hex.

1011

1010

1111

0000

------

1110 xor parity This is how I would expect to see it. 0x00 0x0e (big endian)

 

This looks like what they are doing

1011

1010

1111

0000

------

1110 -> convert to asci 0x31 0x34 (big endian)

 

 

I'm just wondering what this would accomplish, granted I have no idea what is going on here and I'm just try to put the clues together. I'm pretty sure this header is not parity of any kind. Thus far I know that this header needs to change to reflect data changes. I'm just unable to figure out how to calculate the header.

 

 

Last Edited: Mon. Apr 11, 2016 - 07:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I misunderstood you. I thought youwere saying that it was an ASCII representation of a hexadecimal number. You were really saying that it is a hexadecimal representation of an ASCII representation of a decimal number. Ignore me. It'll be easier in the long run.

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ignore me. It'll be easier in the long run.

That would make a great tagline for someone I know who is not a 'Freak.

Ross McKenzie ValuSoft Melbourne Australia