I'm trying a few days to get the type of the CRC with the following hex stream (sniffed with wireshark):
The Hex data i sniffed:
0000001ec001075465737431323308557365726e616d650850617373776f7264d224
This should be the DATA in HEX:
0000001ec001075465737431323308557365726e616d650850617373776f7264
So the last 4 digits are the checksum, in this case d224
I used many code snippets (PHP, java), and some online checksum calcuation sites:
e.g.:
http://www.scadacore.com/field-applications/programming-calculators/online-checksum-calculator/
But I don't get the correct CRC value.
Thanks!
Update 1
Here are more hex streams with CRC included (the last 4 digits):
0000001dc001045465737409557365726e616d65310950617373776f726431cc96
0000001dc001045465737409557365726e616d65320950617373776f72643289d9
0000001dc001045465737409557365726e616d65330950617373776f726433b51c
0000001dc001045465737409557365726e616d65340950617373776f7264340347
0000001dc001045465737409557365726e616d65350950617373776f7264353f82
It appears to be the ARC CRC, polynomial 0x8005, reflected, zero initial value and no final xor, if I discard the initial 0000001d on each message, and take the CRC at the end to be put in the stream in little-endian order.
Related
I am trying to wrap my head around 1's complement checksum error detection as is used in UDP.
My understanding with simplified example for an UDP-like 1's complement checksum error checking algorithm operating on 8 bit words (I know UDP uses 16 bit words):
Sum all 8 bit words of data, carry the MSB rollover to the LSB.
Take 1's complement of this sum, set checksum, send datagram
Receiver adds with carry rollover all received 8 bit words of data in the incoming datagram, adds checksum.
If sum = 0xFF, no errors. Else, error occurred, throw away packet.
It is obvious that this algorithm can detect 1 bit errors and by extension any odd-numbered bit errors. If just one bit in an 8-bit data word is corrupted, the sum + checksum will never equal 0xFF. A plain and simple example would be A = 00000000, B = 00000001, then ~(A + B) = 11111110. If A(receiver) = 00000001, B(reciever) = 00000001, the sum + checksum would be 0x00 != 0xFF
My question is:
It's not too clear to me if this can detect 2 bit errors. My intuition says no, and a simple example is taking A = 00000001, B = 00000000, then sum + checksum would be 0xFF, but there are two total errors in A and B from sender to receiver. If the 2 bit error occurred in the same word, theres a chance it could be detected, but it doesn't seem guaranteed.
How robust is UDP error checking? Does it work for even numbers of bit errors?
Some even-bit changes can be detected, some can't.
Any error that changes the sum will be detected. So a 2-bit error that changes the sum will be detected, but a 2-bit error that does not change the sum will not be detected.
A 2-bit error in a single word (single byte in your simplified example) will change the value of that word, which will change the sum, and therefore will always be detected. Most 2-bit errors across different words will be detected, but a 2-bit error that changes the same bit in different directions (one 0->1, the other 1->0) in different words will not change the sum -- the change in value created by one of the changed bits will be cancelled out by the equal-but-opposite change in value created by the other changed bit -- and therefore that error will not be detected.
Because this checksum is simply an addition, it will also fail to detect the insertion or removal of words whose arithmetic value is zero (and since this is a one's complement computation, that means words whose content is all 0s or all 1s).
It will also fail to detect transpositions of words, (because a+b gives the same sum as b+a), or more generally it will fail to detect errors that add the same amount to one word as they subtract from the other (because a+b gives the same sum as (a+n)+(b-n), e.g. 3+3=4+2=5+1). You could consider the transposition and cancelling-error cases to be made up of multiple pairs of same-bit changes.
I am writing a computer program which utilizes input from some equipment which I seldom have availible in my office. In order to develop and test this program I am trying to use an Arduino board to simulate the communication from the actual equipment. To this effect I create datapackets on the Arduino and send them to my computeer over the serial port. The packets are formated as a header and a hexidecimal integer, representing some sensor data.
The header is supposed to contain a checksum (2's complement 256-modulo). I am however not sure how to calculate it. In the datasheet of the equipment (which communication I try to simulate), it is stated that I should first compute the sum all bytes in the packet, and then take the 256-modulo of the sum and perform a 8-bit two's complement on the result.
However, as I am a newbie to bits, bytes and serial communication, I do not understand the following:
1) Lets say that I want to send the value 5500 as two bytes (high byte and low byte). Then the high-byte is '15' and the low-byte is '7c' in hexidecimal encoding, which corresponds to 21 and 124 in decimal values. Do I then add the contributions 21 and 124 to the checksum before taking the 256-modulo, or do I have to do some bit-magic beforehand?
2) How do I perform a two's compliment?
Here is a code which should illustrate how I think. The idea is to send a packet with a header containing a byte which states the length of the packet, a byte which states the type of the packet, and a byte for the checksum. Then a two-byte integer value representing some sensor value is devided into a high-byte and a low-byte, and transmitted low-byte first.
int intVal;
byte Len = 5;
byte checksum;
byte Type = 2;
byte intValHi;
byte intValLo;
void setup(){
Serial.begin(9600);
}
void loop(){
intVal = 5500; //assume that this is a sensor value
intValHi = highByte(intVal);
intValLo = lowByte(intVal);
//how to calculate the checksum? I unsuccessfully tried the following
checksum = 0;
checksum = (Len+checksum+Type+intValHi+intValLo) % 256;
//send header
Serial.write(Len);
Serial.write(checksum);
Serial.write(Type);
//send sensor data
Serial.write(intValLo);
Serial.write(intValHi)
}
Thanks!
The first thing you should understand is that mod 256 is the same thing as looking at the bottom log(256) => 8 bits.
To understand this you have to first realize what the 'mod' operation does and how digits are represented in hardware.
Mod is the remainder after an old-school division (ie only with whole numbers).
eg 5%2 = 1
Digits in hardware are stored in 'bits' which can be interpreted as base 2 mathematics.
Thus if you want to take the mod operation of a power of 2 you don't actually have to do any math.
This is just like if you want to have the remainder of the power of 10, you just take the lower digits.
ie. 157 % 100 = 57.
This can be sped up by using the fact that bytes should overflow by themselves. This means that all you have to do to take %256 of a bunch of numbers is to add them to a single byte and the arduino will take care of the rest.
For twos compliment see this question:
What is “2's Complement”?
I am trying to figure out how the calculate the CRC for very simple SDLC frames.
Using an MLT I am capturing the stream and i see some simple frames being sent out like: 0x3073F9E3 and 0x3011EDE3
From my understanding the F9E3 and EDE3 are the 2 byte checksums of the 3073 and 3011 since that is all that was in that frame.
using numerous CRC calculators and calculations I have been able to get the first byte of the checksum, but not the last byte (the F9 and the ED).
Using this calculator (http://www.zorc.breitbandkatze.de/crc.html):
Select CRC-CCITT
Change Final XOR Value to: FFFF
Check Reverse Data Bytes and reverse CRC result before Final XOR
Then type the input: %30%11
Which will give the output B8ED so the last byte is the ED.
Any ideas?
You are getting the correct crc16's (F9 F8, ED B8). I don't know why your last byte is E3 in both cases. This is perhaps a clue that the packets are not being disassembled correctly.
Is there any checksum that results in 2 digit hexadecimal?
I can only find NMEA Checksum...
references:
http://nmeachecksum.eqth.net/
http://en.wikipedia.org/wiki/NMEA_0183
I have some data file that I want to perform reverse engineering to find the kind of checksum.
Thank you in advance,
Two hex digits is one byte. You're looking for a checksum which produces one byte.
Obviously, you've got a simple additive checksum (sum the bytes of the input), and an xor of the input bytes.
It could also be a longer checksum of which only 8 bits have been taken.
It could also be some kind of CRC-8; Wikipedia knows about five kinds of standardised CRC-8.
What is CRC? And how does it help in error detection?
CRC is a non-secure hash function designed to detect accidental changes to raw computer data, and is commonly used in digital networks and storage devices such as hard disk drives.
A CRC-enabled device calculates a short, fixed-length binary sequence, known as the CRC code, for each block of data and sends or stores them both together. When a block is read or received the device repeats the calculation; if the new CRC code does not match the one calculated earlier, then the block contains a data error and the device may take corrective action such as requesting the block be sent again.
Source: Wikipedia
CRC stands for Cyclic Redundancy Check.
it helps in error detection..
It consists of the following
b(x)-> transmitted code word
q(x)-> quotient
i(x)-> information polynomial
r(x)-> remainder polynomial
g(x)-> generated polynomial
step 1: x^(n-k) * i(x)
step 2: r(x) = (x^(n-k) * i(x))%g(x)
step 3: b(x) = (x^(n-k) * i(x)) XOR with r(x)
which results in a transmitted code word.
this b(x) is send to the reciever end from the sender and if u divide the
transmitted code word i.e. b(x) with g(x) and if the remainder
i.e. r(x) is equal to 0 at the reciever end then there is no error
otherwise there is an error in the transmitted code word during the
transmission from sender to reciever.
In this way it is helpful in error detection.
Cyclic Redundancy Check is a hash function that allows you to compute an unique value given some input which is guaranteed to be always the same for the same input. If the input changes somehow from the original, a different CRC checksum will be generated. So if you have an input and a checksum you could calculate a new checksum from the input and compare both checksums. If they are the same it means that the input hasn't changed.