crc32 password, command correctly
#1
Hello!
How to make a command correctly.
I understand the crc32 password, there is data in hex-format DATA={0x01 0x02 0x03 0x04} and known to this data CRC32={ 0x05 0x06 0x07 0x08}.
I am trying to do this:
hashcat --force -m 11500 -i --increment-min = 1 --increment-max = 8 -a 3 05060708: 01020304 ?H?H?H?H?H?H?H?H


But the result is not correct, how can I make the command correctly?

Thank you for your help.
Reply
#2
(03-26-2021, 11:59 AM)ingol Wrote: Hello!

How to make a command correctly.

I understand the crc32 password, there is data in hex-format DATA={0x01 0x02 0x03 0x04} and known to this data CRC32={ 0x05 0x06 0x07 0x08}.

I am trying to do this:

hashcat --force -m 11500 -i --increment-min = 1 --increment-max = 8 -a 3 05060708: 01020304 ?H?H?H?H?H?H?H?H



But the result is not correct, how can I make the command correctly?



Thank you for your help.


crc32 of string "test" = d87f7e0c

hashcat -a 3 -m 11500 d87f7e0c:00000000 ?l?l?l?l
resulting in hahscat cracking
d87f7e0c:00000000:test

if you have plain crc32 and no salt in your crc32 use 00000000, you dont need to attack with ?h unless you are looking for passes with control chars or similar in it, so basic ?a would do the job, dont known what kind of passes / strings you are attacking
Reply
#3
I have only the sniffer capture data, they are all in hex-format, since it is correct for me to make this command ?

This is an exchange of data between devices with a checksum (CRC32), I need to understand how it is calculated
I have already tested all available online calculators CRC32 - no result.
Reply
#4
(03-26-2021, 12:54 PM)ingol Wrote: I have only the sniffer capture data, they are all in hex-format, since it is correct for me to make this command ?

This is an exchange of data between devices with a checksum (CRC32), I need to understand how it is calculated
I have already tested all available online calculators CRC32 - no result.

well i think no, unless you have a "known" message and its processed data from your sniffing data

given your infos the crc is maybe only for the communicating devices to verify, that the transmitted data is correct, the crc part of the transmission can be anything crc(data) mixed with an "unknown" salt the two devices made up earlier

device a sends paket [data:crc], the kind of data transmitted can be anyting (what for a device)

device b recieves paket with[data:crc] and checks whether crc(data) + unkwon salt? equals crc, if yes -> packet recieved with no errors, if not -> either the data part or the crc part of the message was corrupted on transmission, anyhow the paket is invalid and will be be dropped/requested again due to the invalid data

so if you not really know what data these devices sending/recieving and how this communication works, is the data encrypted? is the data/crc salted? what kind of "plain" data do you expect to get? dont think that anyone can help
Reply
#5
(03-26-2021, 03:00 PM)Snoopy Wrote:
(03-26-2021, 12:54 PM)ingol Wrote: I have only the sniffer capture data, they are all in hex-format, since it is correct for me to make this command ?

This is an exchange of data between devices with a checksum (CRC32), I need to understand how it is calculated
I have already tested all available online calculators CRC32 - no result.

well i think no, unless you have a "known" message and its processed data from your sniffing data

given your infos the crc is maybe only for the communicating devices to verify, that the transmitted data is correct, the crc part of the transmission can be anything crc(data) mixed with an "unknown" salt the two devices made up earlier

device a sends paket [data:crc], the kind of data transmitted can be anyting (what for a device)

device b recieves paket with[data:crc] and checks whether crc(data) + unkwon salt? equals crc, if yes -> packet recieved with no errors, if not -> either the data part or the crc part of the message was corrupted on transmission, anyhow the paket is invalid and will be be dropped/requested again due to the invalid data

so if you not really know what data these devices sending/recieving and how this communication works, is the data encrypted? is the data/crc salted? what kind of "plain" data do you expect to get? dont think that anyone can help

Yes, you described everything correctly, I understand what CRC32 is used for.
In my case, I hope for your help.
The data is NOT encrypted, they are known - this is a pulse counter (1,2,3,4 ......). It is normally visible. I need to understand how CRC32 is calculated.
Reply
#6
can you provide some of the data for known counter? something like

counter-stat:data-transmitted:crc
0001:????:crc
0002:????:crc
0003:????:crc
Reply
#7
full limit is always = 20100 pulse
sniff data in this format  {xDATA0 xDATA1 xDATA2 xDATA3 xCRC0 xCRC1 xCRC2 xCRC3}
this current  count  pulse = {xDATA0 xDATA1}
20100 = {xDATA0 xDATA1} + {xDATA2 xDATA3}

counter = 0 from 20100          sniff data = {0x00 0x00 0x4E 0x84 0xBC 0x75 0x79 0x21}
counter = 1 from 20100          sniff data = {0x00 0x01 0x4E 0x83 0x57 0x96 0x8B 0xA3}

counter = 20096 from 20100    sniff data = {0x4E 0x80 0x00 0x04 0x8A 0x53 0x92 0xF4}
counter = 20097 from 20100    sniff data = {0x4E 0x81 0x00 0x03 0x61 0xB0 0x60 0x76}
counter = 20098 from 20100    sniff data = {0x4E 0x82 0x00 0x02 0xB8 0x0E 0xD4 0xA9}
counter = 20099 from 20100    sniff data = {0x4E 0x83 0x00 0x01 0x24 0x79 0x35 0x10}
counter = 20100 from 20100    sniff data = {0x4E 0x84 0x00 0x00 0x01 0xC1 0x38 0x38}
Reply
#8
do the crc remain the same per run over time or do they change for same counter stat?
Reply
#9
(03-29-2021, 05:56 PM)Snoopy Wrote: do the crc remain the same per run over time or do they change for same counter stat?

CRC remains unchanged at all times
Reply
#10
(03-29-2021, 06:09 PM)ingol Wrote:
(03-29-2021, 05:56 PM)Snoopy Wrote: do the crc remain the same per run over time or do they change for same counter stat?

CRC remains unchanged at all times

damn my answer vanished, okay short

tried 4 billions salts with your plain counter-data and searched for matching your crc result

got different salts for each plain, so it is not a fixed salt, im also not convinced, that it is really crc32, could be also adler 32, or crc16  or crc8 (to much possibilities)

would be a nice "try this" for my trainees, could you provide a full counter cirlce dump as csv, txt? maybe with a full dataset it would be possible to see a pattern, but with just 7 datas from you it is just wild guessing, can you provdide some more detailed information about the devices which are communicating?

but with holiday dont expect any answer soon (jus playing around)
Reply