-2

I'm new to reversing.

I need to analyse a packet which i think is checked by CRC.

The packet is the following: 1B1B1B1B0101010176058C0D1FAA62006200726500000101760101074553595133420B0901455359110393AC9601016317D00076058C0D1FAB6200620072650000070177010B0901455359110393AC9601726201650000CC5B7A77078181C78203FF01010101044553590177070100000000FF010101010F31455359313136303030393632320177070100010800FF0101621E52FC690000000001B466C00177070100020800FF0101621E52FC69000000000200B2000177070100010801FF0101621E520165000000950177070100010802FF0101621E520165000000890177070100020801FF0101621E520165000000CE0177070100020802FF0101621E520165000000820177070100010700FF0101621B52FE55000000000177070100600505FF01010101630100010101639EEC0076058C0D1FAC62006200726500000201710163CA5200001B1B1B1B1A011BFC

From what I figured out until now, The first part of this hex-string which contains the frame information and ethernet information is: 1B1B1B1B0101010176058C0D1

After that, it's all data that have been CRC'd.

is there any way I can reverse the CRC and read the Data????? How can i know what base is it?(16/32/64) (I have more packets like this one)

Thanks for the answers..!

pugilon
  • 87
  • 1
  • 2
  • 12

2 Answers2

0

A cyclic redundancy check (CRC) is a one way hash of input data. As it is a hash, and not an encryption nor encoding, there is no means to determine the original data, as there will be multiple valid inputs that give the same result.

Rowland Shaw
  • 37,700
  • 14
  • 97
  • 166
  • Ok, so if i manage to determine the CRC function and how it works, I can try and bruteforce all options, no? – pugilon Dec 10 '14 at 13:10
0

CRC's are used by appending them to the data. The original data is still there unaltered, so you can already "read the Data".

As for determining what CRC is used, you can use RevEng, but you will need to try guesses with different CRC locations and sizes, and you will need to use several examples of data.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Hi Mark, Thanks for your answer. The 2 octates at the end of every packet is suppose to be th CRC checksum, this changes from every packet to packet, and moreover, several other octates change in the same location within every packet. I assumed that these changing byte's are connected to the CRC and maybe balancing it's polynum. does this make sense? – pugilon Dec 14 '14 at 07:31