문제

마지막에 16 비트 체크섬이있는 패킷이 있다고 가정 해 봅시다. 어떤 체크섬 알고리즘이 사용되는지 추측하고 싶습니다.

시작을 위해 덤프 데이터에서 패킷의 페이로드의 한 바이트 변경이 체크섬을 완전히 변경한다는 것을 알 수 있습니다. 따라서 간단한 xor 또는 합계가 아니라고 가정 할 수 있습니다.

그런 다음 시도했습니다 CRC16의 몇 가지 변형, 그러나 많은 운이 없습니다.

이 질문은 암호화에 대해 더 편향되어있을 수 있지만, 이것이 어떤 CRC인지 알아 내기 위해 이해하기 쉬운 통계 도구에 정말로 관심이 있습니다. 나는 심지어 돌아갈 수도 있습니다 다른 CRC 알고리즘 그리기 다른 모든 것이 실패하면.

Backgroud Story : 나는 어떤 종류의 체크섬이있는 직렬 RFID 프로토콜을 가지고 있습니다. 문제없이 메시지를 재생하고 결과를 해석 할 수 있지만 (체크섬 검사없이) 장치가 바닥에 떨어지므로 수정 된 패킷을 보낼 수 없습니다.

기존 소프트웨어를 사용하여 RFID 칩의 페이로드를 변경할 수 있습니다. 그러나 고유 한 일련 번호는 불변이므로 가능한 모든 조합을 확인할 수 없습니다. 어쨌든 나는 하나씩 증가하는 값 덤프를 생성 할 수 있지만이 문제에 철저한 검색을 적용 할 수는 없습니다.

데이터가있는 파일을 덤프합니다 질문 자체가 충분하지 않으면 사용할 수 있습니다 :-)

참조 문서가 필요하십니까? CRC 오류 감지 알고리즘에 대한 통증없는 안내서 여기서 질문을 한 후 찾은 훌륭한 참조입니다.

결국, CCITT보다 받아 들여진 대답에 매우 유용한 힌트를받은 후, 나는이 CRC 계산기를 사용했습니다, 및 xored는 0xffff를 얻기 위해 알려진 체크섬이있는 체크섬을 생성하여 최종 XOR이 CCITT의 0x0000의 0xffff intread라는 결론을 내 렸습니다.

도움이 되었습니까?

해결책

CRC에 대해 고려해야 할 여러 가지 변수가 있습니다.

Polynomial
No of bits (16 or 32)
Normal (LSB first) or Reverse (MSB first)
Initial value
How the final value is manipulated (e.g. subtracted from 0xffff), or is a constant value

일반적인 CRC :

LRC:    Polynomial=0x81; 8 bits; Normal; Initial=0; Final=as calculated
CRC16:  Polynomial=0xa001; 16 bits; Normal; Initial=0; Final=as calculated
CCITT:  Polynomial=0x1021; 16 bits; reverse; Initial=0xffff; Final=0x1d0f
Xmodem: Polynomial=0x1021; 16 bits; reverse; Initial=0; Final=0x1d0f
CRC32:  Polynomial=0xebd88320; 32 bits; Normal; Initial=0xffffffff; Final=inverted value
ZIP32:  Polynomial=0x04c11db7; 32 bits; Normal; Initial=0xffffffff; Final=as calculated

가장 먼저해야 할 일은 마지막 바이트를 변경하여 일부 샘플을 얻는 것입니다. 이렇게하면 CRC의 바이트 수를 파악하는 데 도움이됩니다.

이것은 "수제"알고리즘입니까? 이 경우 시간이 걸릴 수 있습니다. 그렇지 않으면 표준 알고리즘을 사용해보십시오.

마지막 바이트의 MSB 또는 LSB를 변경하고 이것이 CRC를 어떻게 변화시키는 지 확인하십시오. 이것은 방향을 표시 할 것입니다.

더 어려워지기 위해 CRC를 조작하여 통신 매체 (프로토콜)에 영향을 미치지 않도록 구현이 있습니다.

RFID에 대한 귀하의 의견에서 CRC가 커뮤니케이션 관련임을 의미합니다. CCITT는 일부 시스템에서도 사용되지만 일반적으로 CRC16은 통신에 사용됩니다.

반면에 이것이 UHF RFID 태그라면 5 비트 1과 16 비트의 CRC 구성표가 몇 개 있습니다. 이들은 ISO 표준 및 IPX 데이터 시트에 문서화되어 있습니다.

IPX:  Polynomial=0x8005; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6B: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6C: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
    Data must be padded with zeroes to make a multiple of 8 bits
ISO CRC5: Polynomial=custom; 5 bits; Reverse; Initial=0x9; Final=shifted left by 3 bits
    Data must be padded with zeroes to make a multiple of 8 bits
EPC class 1: Polynomial=custom 0x1021; 16 bits; Reverse; Initial=0xffff; Final=post processing of 16 zero bits

여기에 당신의 대답이 있습니다 !!!!

로그를 통해 일한 CRC는 CCITT입니다. 첫 번째 바이트 0xD6은 CRC에서 제외됩니다.

다른 팁

가능한 모든 체크섬 알고리즘을 시도하고 어떤 결과가 동일한 결과를 생성하는지 확인해야합니다. 그러나 체크섬에 포함 된 콘텐츠에 대한 보장은 없습니다. 예를 들어, 일부 알고리즘은 흰색 공간을 건너 뛰고 결과가 다릅니다.

나는 왜 누군가가 왜 그것을 알고 싶어하는지 알지 못한다.

CRC가 아닐 수도 있고 Reed-Solomon과 같은 코드를 수정하는 오류 일 수 있습니다.

ECC 코드는 종종 처리하려는 오류율에 따라 보호 된 원래 데이터의 크기의 상당 부분입니다. 메시지의 크기가 약 16 바이트 이상인 경우 2 바이트의 ECC만으로는 충분하지 않습니다. 따라서 메시지가 크면 CRC의 종류가 맞습니다.

나는 여기서 비슷한 문제를 해결하려고 노력하고 있으며 47 개의 다른 알고리즘으로 파일을 가져 와서 체크섬을 실행하고 결과를 보여줄 깔끔한 웹 사이트를 찾았습니다. 체크섬을 계산하는 데 사용 된 알고리즘이 이러한 알고리즘 중 하나 인 경우 간단한 텍스트 검색으로 생성 된 체크섬 목록 중 하나를 찾을 수 있습니다.

웹 사이트는입니다 https://defuse.ca/checksums.htm

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top