Skip to content

CRC 순환 중복 검사 계산기

16진수나 텍스트에서 CRC-8·CRC-16·CRC-32 변형 63개를 계산하는 온라인 도구. 맞지 않는 체크섬을 역조회 칸에 넣으면 MODBUS 등 어느 변형인지 알려 줍니다.

트래킹 없음 브라우저 실행 무료
모든 계산은 브라우저 안에서 로컬로 처리됩니다. 붙여넣은 데이터는 이 기기를 벗어나지 않습니다.
예시 입력

63개 변형 전체

모든 행이 입력에 맞춰 즉시 다시 계산됩니다.
변형 결과 다항식 초기값 입력/출력 반전 최종 XOR
CRC-8
CRC-8/AUTOSAR 0x2F 0xFF false / false 0xFF
CRC-8/BLUETOOTH 0xA7 0x00 true / true 0x00
CRC-8/CDMA2000 0x9B 0xFF false / false 0x00
CRC-8/DARC 0x39 0x00 true / true 0x00
CRC-8/DVB-S2 0xD5 0x00 false / false 0x00
CRC-8/GSM-A 0x1D 0x00 false / false 0x00
CRC-8/GSM-B 0x49 0x00 false / false 0xFF
CRC-8/HITAG 0x1D 0xFF false / false 0x00
CRC-8/I-432-1 CRC-8/ITU 0x07 0x00 false / false 0x55
CRC-8/I-CODE 0x1D 0xFD false / false 0x00
CRC-8/LTE 0x9B 0x00 false / false 0x00
CRC-8/MAXIM-DOW CRC-8/MAXIM · DOW-CRC 0x31 0x00 true / true 0x00
CRC-8/MIFARE-MAD 0x1D 0xC7 false / false 0x00
CRC-8/NRSC-5 0x31 0xFF false / false 0x00
CRC-8/OPENSAFETY 0x2F 0x00 false / false 0x00
CRC-8/ROHC 0x07 0xFF true / true 0x00
CRC-8/SAE-J1850 CRC-8/J1850 0x1D 0xFF false / false 0xFF
CRC-8/SMBUS CRC-8 0x07 0x00 false / false 0x00
CRC-8/TECH-3250 CRC-8/AES · CRC-8/EBU 0x1D 0xFF true / true 0x00
CRC-8/WCDMA 0x9B 0x00 true / true 0x00
CRC-16
CRC-16/ARC CRC-16 · CRC-16/IBM · CRC-16/LHA 0x8005 0x0000 true / true 0x0000
CRC-16/CDMA2000 0xC867 0xFFFF false / false 0x0000
CRC-16/CMS 0x8005 0xFFFF false / false 0x0000
CRC-16/DDS-110 0x8005 0x800D false / false 0x0000
CRC-16/DECT-R R-CRC-16 0x0589 0x0000 false / false 0x0001
CRC-16/DECT-X X-CRC-16 0x0589 0x0000 false / false 0x0000
CRC-16/DNP 0x3D65 0x0000 true / true 0xFFFF
CRC-16/EN-13757 0x3D65 0x0000 false / false 0xFFFF
CRC-16/GENIBUS CRC-16/DARC · CRC-16/EPC · CRC-16/EPC-C1G2 · CRC-16/I-CODE 0x1021 0xFFFF false / false 0xFFFF
CRC-16/GSM 0x1021 0x0000 false / false 0xFFFF
CRC-16/IBM-3740 CRC-16/CCITT-FALSE · CRC-16/AUTOSAR 0x1021 0xFFFF false / false 0x0000
CRC-16/IBM-SDLC CRC-16/X-25 · CRC-16/X25 · CRC-16/ISO-HDLC · CRC-B · X-25 0x1021 0xFFFF true / true 0xFFFF
CRC-16/ISO-IEC-14443-3-A CRC-A 0x1021 0xC6C6 true / true 0x0000
CRC-16/KERMIT CRC-16/CCITT · CRC-16/CCITT-TRUE · CRC-16/V-41-LSB · CRC-CCITT 0x1021 0x0000 true / true 0x0000
CRC-16/LJ1200 0x6F63 0x0000 false / false 0x0000
CRC-16/M17 0x5935 0xFFFF false / false 0x0000
CRC-16/MAXIM-DOW CRC-16/MAXIM 0x8005 0x0000 true / true 0xFFFF
CRC-16/MCRF4XX 0x1021 0xFFFF true / true 0x0000
CRC-16/MODBUS 0x8005 0xFFFF true / true 0x0000
CRC-16/NRSC-5 0x080B 0xFFFF true / true 0x0000
CRC-16/OPENSAFETY-A 0x5935 0x0000 false / false 0x0000
CRC-16/OPENSAFETY-B 0x755B 0x0000 false / false 0x0000
CRC-16/PROFIBUS CRC-16/IEC-61158-2 0x1DCF 0xFFFF false / false 0xFFFF
CRC-16/RIELLO 0x1021 0xB2AA true / true 0x0000
CRC-16/SPI-FUJITSU CRC-16/AUG-CCITT 0x1021 0x1D0F false / false 0x0000
CRC-16/T10-DIF 0x8BB7 0x0000 false / false 0x0000
CRC-16/TELEDISK 0xA097 0x0000 false / false 0x0000
CRC-16/TMS37157 0x1021 0x89EC true / true 0x0000
CRC-16/UMTS CRC-16/BUYPASS · CRC-16/VERIFONE 0x8005 0x0000 false / false 0x0000
CRC-16/USB 0x8005 0xFFFF true / true 0xFFFF
CRC-16/XMODEM CRC-16/ACORN · CRC-16/LTE · CRC-16/V-41-MSB · ZMODEM 0x1021 0x0000 false / false 0x0000
CRC-32
CRC-32/AIXM CRC-32Q 0x814141AB 0x00000000 false / false 0x00000000
CRC-32/AUTOSAR 0xF4ACFB13 0xFFFFFFFF true / true 0xFFFFFFFF
CRC-32/BASE91-D CRC-32D 0xA833982B 0xFFFFFFFF true / true 0xFFFFFFFF
CRC-32/BZIP2 CRC-32/AAL5 · CRC-32/DECT-B · B-CRC-32 0x04C11DB7 0xFFFFFFFF false / false 0xFFFFFFFF
CRC-32/CD-ROM-EDC 0x8001801B 0x00000000 true / true 0x00000000
CRC-32/CKSUM CRC-32/POSIX 0x04C11DB7 0x00000000 false / false 0xFFFFFFFF
CRC-32/ISCSI CRC-32C · CRC-32/BASE91-C · CRC-32/CASTAGNOLI · CRC-32/INTERLAKEN 0x1EDC6F41 0xFFFFFFFF true / true 0xFFFFFFFF
CRC-32/ISO-HDLC CRC-32 · CRC-32/ADCCP · CRC-32/V-42 · CRC-32/XZ · PKZIP 0x04C11DB7 0xFFFFFFFF true / true 0xFFFFFFFF
CRC-32/JAMCRC 0x04C11DB7 0xFFFFFFFF true / true 0x00000000
CRC-32/MEF 0x741B8CD7 0xFFFFFFFF true / true 0x00000000
CRC-32/MPEG-2 0x04C11DB7 0xFFFFFFFF false / false 0x00000000
CRC-32/XFER 0x000000AF 0x00000000 false / false 0x00000000
사용자 지정 파라미터

장비 문서의 다항식이 위 표에 없을 때 사용하십시오.

결과
63개 변형의 파라미터 집합 전체를 공개된 카탈로그 자체 검증 값과 대조해 테스트 스위트에서 단언하며, CRC-32/ISO-HDLC는 Node 내장 zlib.crc32를 독립 기준으로 삼아 교차 검증합니다. — Go Tools 팀 · Sep 6, 2026

Go Tools 엔지니어링 팀이 제작하고 검증했습니다.

빠른 답변

"123456789"의 CRC-32

0xCBF43926 CRC-32/ISO-HDLC 기준 0xCBF43926이며, ZIP과 PNG, 이더넷, gzip이 쓰는 변형입니다.

"123456789"의 CRC-16/MODBUS

0x4B37 0x4B37입니다. poly 0x8005, init 0xFFFF, 입력과 출력 모두 반전, 최종 XOR 없음.

"123456789"의 CRC-16/CCITT-FALSE

0x29B1 0x29B1입니다. 카탈로그의 정식 명칭은 CRC-16/IBM-3740이며 poly 0x1021, init 0xFFFF, 반전 없음입니다.

CRC 변형은 모두 몇 개입니까?

63 이 계산기는 카탈로그에 수록된 63개 변형을 다룹니다. 폭 8이 20개, 폭 16이 31개, 폭 32가 12개입니다.

CRC란 무엇입니까?

순환 중복 검사는 데이터 블록을 아주 긴 이진 다항식의 계수로 보고, 모듈로 2 연산으로 고정된 생성 다항식으로 나눈 다음 나머지를 남깁니다. 그 나머지가 체크섬입니다. 이 방식이 널리 쓰이는 이유는 두 가지입니다. 나눗셈이 시프트와 XOR로 환원되어 하드웨어에서 비용이 거의 들지 않고, 대수가 통계적 기대가 아니라 확정적인 보장을 주기 때문입니다. 잘 고른 16비트 다항식은 모든 단일 비트 오류, 쓸 만한 블록 길이 안의 모든 이중 비트 오류, 홀수 개의 모든 비트 반전, 그리고 연속된 16비트 이하의 모든 버스트 오류를 검출합니다.

실무에서 CRC를 혼란스럽게 하는 것은 다항식이 여섯 개 파라미터 중 하나일 뿐이라는 사실입니다. 두 구현이 다항식에서 완전히 일치하고도 결과가 하나도 맞지 않을 수 있습니다. 레지스터의 초기값이 다르고, 입력 바이트와 출력 레지스터의 비트 순서를 뒤집는지가 다르며, 마지막에 XOR로 넣는 상수가 다르기 때문입니다. CRC 변형이란 다항식 하나가 아니라 이 파라미터 집합 전체를 가리킵니다. 'CRC-16' 같은 이름이 홀로 떨어지면 사실상 아무것도 지목하지 못하는 이유이자, 이 페이지가 결과마다 다항식과 초기값, 두 개의 반전 플래그, 최종 XOR를 나란히 보여 주고 비트 폭을 그룹 제목으로 삼는 이유입니다.

표가 보여 주지 못하는 단서가 하나 있습니다. 16비트 다항식이 홀수 개의 비트 반전을 모두 검출하는 것은 x+1이 그 다항식을 나누어떨어뜨릴 때뿐입니다. 가장 마주치기 쉬운 두 가지인 0x1021과 0x8005는 이 조건을 만족하지만 모든 다항식이 그런 것은 아닙니다. CRC-16/T10-DIF와 CRC-16/PROFIBUS가 그 예외에 속합니다.

// CRC-16/MODBUS: poly=0x8005, init=0xFFFF, refin/refout=true, xorout=0x0000
// Written in the reflected form, so the polynomial appears bit-reversed as 0xA001.
function crc16Modbus(bytes) {
  let crc = 0xffff;
  for (const byte of bytes) {
    crc ^= byte;
    for (let i = 0; i < 8; i++) {
      crc = crc & 1 ? (crc >>> 1) ^ 0xa001 : crc >>> 1;
    }
  }
  return crc;
}

crc16Modbus([0x01, 0x03, 0x00, 0x00, 0x00, 0x0a]); // 0xCDC5
// On the wire Modbus RTU sends the low byte first: ... 0x0A 0xC5 0xCD

이 계산기가 하는 일

63개 변형을 한 번에

CRC-8과 CRC-16, CRC-32가 입력과 동시에 함께 다시 계산됩니다. 무언가를 보려고 드롭다운에서 먼저 하나를 찍어 볼 필요가 없습니다.

역조회

받은 체크섬을 입력하면 그 값을 산출하는 변형이 강조되므로, 알 수 없는 알고리즘을 알아내는 데 스무 번이 아니라 한 번이면 됩니다.

정식 명칭과 설명서 명칭 병기

모든 행에 RevEng 카탈로그 명칭과 현장에서 실제로 쓰이는 별칭을 함께 적었습니다. CCITT-FALSE, CRC-16/IBM, CRC-32C, X-25 등입니다.

파라미터 전체 표

다항식과 초기값, 두 반전 플래그, 최종 XOR가 결과 옆에 함께 놓이므로 사양서와 대조해 일치를 확인할 수 있습니다.

사용자 지정 파라미터

어떤 카탈로그에도 오르지 못한 다항식을 위해 폭과 다항식, 초기값, 반전, 최종 XOR를 모두 직접 수정할 수 있습니다.

완전한 오프라인 실행

계산은 브라우저 안에서 일어납니다. 운영 프레임과 펌웨어 이미지는 이 기기를 벗어나지 않습니다.

실제 계산 예시

카탈로그 자체 검증 값

123456789
CRC-32/ISO-HDLC = 0xCBF43926, CRC-16/MODBUS = 0x4B37, CRC-8/SMBUS = 0xF4

RevEng 카탈로그에 수록된 모든 CRC 변형은 ASCII 문자열 123456789에 대한 결과를 함께 공개합니다. 그래서 이 입력이 표준 자체 검증 값이 됩니다. 어떤 라이브러리가 여기 표와 다른 값을 내놓는다면 틀린 쪽은 라이브러리입니다.

Modbus RTU 요청 프레임

01 03 00 00 00 0A
CRC-16/MODBUS = 0xCDC5

1번 슬레이브에서 보유 레지스터를 읽는 요청입니다. Modbus RTU는 CRC의 하위 바이트를 먼저 붙이므로 이 프레임은 회선에 01 03 00 00 00 0A C5 CD로 실려 나갑니다. 체크섬이 맞지 않는다는 사례의 상당수가 바로 이 순서 뒤바뀜에서 나옵니다.

같은 바이트, 네 가지 CRC-16 결과

DEADBEEF
MODBUS = 0xC19B, CCITT-FALSE = 0x4097, XMODEM = 0xC457, KERMIT = 0x1915

16진수 모드로 읽으므로 문자열의 여덟 글자가 아니라 4바이트입니다. 가장 잘 알려진 CRC-16 변형 네 개가 이 4바이트에 대해 완전히 다른 값을 내놓습니다. 고장이 난 것이 아닙니다. 이들은 초기값과 반전, 최종 XOR가 다를 뿐이며 정확성의 문제가 아닙니다.

장비 응답값으로 변형 역조회

123456789, 기댓값 0x29B1
CRC-16/IBM-3740 (설명서에는 CRC-16/CCITT-FALSE로 적혀 있을 수 있습니다)

이 계산기가 겨냥하는 상황이 바로 이것입니다. 데이터와 다른 사람이 계산한 체크섬은 손에 있는데 변형 이름만 모르는 경우, 그 값을 재현하는 파라미터 집합을 거꾸로 찾는 것입니다.

CRC 계산기 사용법

  1. 1

    텍스트와 16진수 중 선택

    프로토콜 프레임은 거의 언제나 16진수입니다. 123456789 같은 자체 검증 값처럼 문자열 그 자체의 체크섬을 구할 때만 텍스트 모드를 쓰십시오.

  2. 2

    데이터 붙여넣기

    16진수 모드에서는 구분 기호를 무시하므로 01 03 00 00 00 0A, 0x01 0x03, 010300 00000A가 모두 인식됩니다.

  3. 3

    필요한 변형 찾기

    표는 폭 기준으로 묶여 있습니다. 정식 명칭은 RevEng 카탈로그에서 가져왔고, 그 아래에 장비 설명서에 실릴 가능성이 높은 별칭을 함께 적었습니다.

  4. 4

    거꾸로 찾기

    이미 체크섬이 있고 어떤 변형인지 알고 싶다면 기댓값 칸에 입력한 뒤 강조된 행을 읽으십시오.

체크섬이 맞지 않는 이유

바이트가 아니라 "01 03"이라는 텍스트를 계산

텍스트 모드에 그대로 두면 계산기는 16진수 덤프가 나타내는 바이트가 아니라 그 문자열의 ASCII 문자를 계산합니다. 16진수 모드로 전환하십시오. 모드 전환 아래의 바이트 수가 지금 어느 쪽으로 읽혔는지 알려 줍니다.

✗ 오류
Text mode, input "01 03" -> 5 bytes: 30 31 20 30 33
✓ 정상
Hex mode, input "01 03" -> 2 bytes: 01 03

바이트가 뒤바뀐 체크섬과 비교

Modbus RTU는 CRC의 하위 바이트를 먼저 전송합니다. C5 CD로 끝나는 프레임의 체크섬은 0xC5CD가 아니라 0xCDC5입니다.

✗ 오류
expected 0xC5CD  (bytes read in transmission order)
✓ 정상
expected 0xCDC5  (bytes reassembled low-byte-first)

체크섬 필드를 자기 계산에 포함

CRC는 자기 앞의 바이트를 덮습니다. 꼬리까지 포함해 프레임 전체를 다시 넣으면 체크섬이 아니라 잔여값이 나옵니다.

✗ 오류
01 03 00 00 00 0A C5 CD    <- trailer included
✓ 정상
01 03 00 00 00 0A          <- payload only

"CRC-16"이 알고리즘을 지정한다고 가정

카탈로그에 수록된 16비트 폭 변형은 31개입니다. 나머지 다섯 개 파라미터가 없으면 이 이름은 아무것도 좁혀 주지 못합니다.

✗ 오류
spec says: "trailer is a CRC-16"
✓ 정상
spec says: "CRC-16/MODBUS, poly 0x8005, init 0xFFFF, refin/refout true"

이럴 때 필요합니다

Modbus 링크 문제 해결
PLC가 프레임을 거부할 때 CRC가 틀린 것인지 단순히 바이트가 뒤바뀐 것인지 가려야 합니다. CRC-16/MODBUS를 계산해 두 순서를 모두 비교해 보십시오.
문서 없는 프로토콜 식별
체크섬처럼 보이는 2바이트 꼬리가 붙은 트래픽을 캡처했습니다. 페이로드와 그 꼬리를 역조회에 넣고 어느 변형이 그 값을 자기 것이라고 주장하는지 보십시오.
툴체인 사이의 펌웨어 이식
벤더 라이브러리와 직접 작성한 구현이 서로 다른 값을 냅니다. 둘 다 카탈로그 자체 검증 값과 대조해 보면 어느 쪽이 어긋났는지 드러납니다.
사양서 작성과 검토
프로토콜 문서에 'CRC-16'이라고만 적으면 상호 운용 결함을 예약해 두는 셈입니다. 파라미터 표는 알고리즘을 실제로 고정하는 여섯 개 값을 제공합니다.
저장된 데이터 검증
파일 시스템과 아카이브 형식, 플래시 이미지에는 CRC-32 필드가 들어 있습니다. 한 번 다시 계산해 보면 그 블록이 온전한지 알 수 있습니다.

CRC의 동작 원리

다항식 표기법
표의 다항식은 일반(최상위 비트 우선) 형태로 적혀 있습니다. 0x8005는 x^16 + x^15 + x^2 + 1을 뜻합니다. 반전 구현은 같은 다항식을 0xA001로 적는 경우가 많고, Koopman 표기는 또 다르게 자릿수를 옮깁니다. 다항식 하나에 표기가 셋이라는 점이 이식 실패의 흔한 원인입니다.
초기값
레지스터를 0x0000이 아니라 0xFFFF에서 시작하면 체크섬이 앞쪽의 0 바이트에 민감해집니다. 초기값이 0이면 메시지 앞에 0을 덧붙여도 CRC가 그대로인데, 프레임 기반 프로토콜이 반드시 잡아내야 하는 손상이 바로 그것입니다.
반전
refin은 각 입력 바이트 안의 비트 순서를 뒤집고, refout은 최종 레지스터의 비트 순서를 뒤집습니다. 하드웨어는 최상위 비트부터 밀어 넣고 바이트 단위 소프트웨어는 최하위 비트부터가 더 싸다고 보는데, 반전 파라미터 형태가 이 둘을 조정해 맞춥니다.
최종 XOR
xorout은 마지막에 적용되며, 반대편 끝의 init과 같은 것이 아닙니다. 메시지 뒤에 붙은 0 바이트는 어느 쪽이든 검출됩니다. 0이 아닌 xorout이 바꾸는 것은 수신 측이 메시지와 체크섬을 이어 붙여 CRC를 돌렸을 때 나오는 잔차입니다. xorout이 0이면 그 잔차 자체가 0이므로, CRC 필드 뒤에 붙은 0은 그대로 통과합니다. 또한 전부 0인 메시지가 0이 아닌 체크섬을 내도록 합니다.
자체 검증 값
카탈로그에 수록된 모든 변형은 ASCII 문자열 123456789에 대한 결과를 공개합니다. 그 입력을 넣었을 때 이 페이지에 나타나는 63개 값이 바로 공개된 그 상수들이며, 이 페이지의 엔진도 그것으로 시험합니다.

결과를 일치시키려면

알고리즘 이름이 아니라 파라미터를 적을 것
사양서에는 'poly 0x1021, init 0xFFFF, refin false, refout false, xorout 0x0000'처럼 적으십시오. 'CRC-16/CCITT'는 적어도 세 가지 서로 다른 것을 가리켜 왔습니다.
바이트 순서는 따로 확인할 것
체크섬이 바이트 교환 한 번이면 맞아떨어지는 상황이라면 알고리즘은 맞고 프레이밍이 틀린 것입니다. 이 둘은 서로 다른 결함으로 다루십시오.
자체 검증 값으로 먼저 검사할 것
데이터를 파헤치기 전에 여러분의 구현이 123456789에 대해 카탈로그 값을 돌려주는지부터 확인하십시오. 알고리즘이 깨진 것인지 입력이 잘못된 것인지 몇 초 만에 갈라 줍니다.
무엇이 포함되는지 명확히 할 것
불일치의 대부분은 시작 표시나 주소, 길이 필드를 넣거나 빼면서 생깁니다. CRC가 정확히 어느 바이트를 덮는지 정하고 문서에 적어 두십시오.
MAC이 필요한 자리에 CRC를 쓰지 말 것
CRC는 선형이라 위조가 손쉽습니다. 공격자가 데이터를 고칠 가능성이 있다면 HMAC을 쓰십시오.

자주 묻는 질문

장비가 돌려주는 CRC가 이 계산기와 다른 이유는 무엇입니까?
거의 언제나 서로 다른 두 변형을 비교하고 있기 때문입니다. CRC-16 하나만 해도 카탈로그에 수록된 파라미터 집합이 31개이며, MODBUS와 CCITT-FALSE, XMODEM, KERMIT은 똑같은 바이트에서 서로 무관한 네 개의 숫자를 내놓습니다. 장비가 준 값을 기댓값 칸에 넣으십시오. 그 값을 재현하는 변형이 있으면 해당 행이 강조되고 답이 나옵니다. 아무것도 일치하지 않는다면 계산 대상 데이터가 생각하던 그 데이터가 아닙니다. 바이트 순서를 확인하고, 프레임의 시작·끝 표시가 계산에 포함되었는지도 확인하십시오.
Modbus는 어떤 CRC-16을 사용합니까?
CRC-16/MODBUS입니다. 다항식 0x8005, 초기값 0xFFFF, 입력과 출력 모두 반전, 최종 XOR 없음. 자주 혼동을 부르는 것은 알고리즘이 아니라 전송 순서입니다. Modbus RTU는 CRC의 하위 바이트를 먼저 보내므로 CRC가 0xCDC5인 프레임은 끝에 C5 CD 두 바이트를 싣습니다. 프레임 하나를 처음부터 풀어 쓴 예시는 CRC-16 변형 정리를 참고하십시오.
CRC-16/CCITT와 CRC-16/CCITT-FALSE는 무엇이 다릅니까?
이름만 헷갈리게 닮았을 뿐 서로 다른 알고리즘이며, RevEng 카탈로그가 둘 다 이름을 고친 이유가 여기에 있습니다. 흔히 CCITT-FALSE라고 부르는 것은 CRC-16/IBM-3740입니다. 초기값 0xFFFF, 반전 없음. 그냥 CCITT라고 할 때 보통 가리키는 것은 CRC-16/KERMIT입니다. 초기값 0x0000, 입력과 출력 모두 반전. 이 계산기는 정식 명칭과 장비 설명서에 실릴 가능성이 높은 이름을 함께 보여 줍니다.
CRC로 파일이 변조되었는지 확인할 수 있습니까?
없습니다. CRC는 잡음 있는 채널에서 우발적으로 생기는 손상을 잡아내려고 설계된 오류 검출 부호이며, 선형이기 때문에 누구든 메시지를 고친 뒤 CRC가 계속 맞도록 조정할 수 있습니다. 의도를 가진 공격자에 맞서 무결성을 지키려면 SHA-256 같은 암호학적 해시나 HMAC 같은 인증 구조를 쓰십시오. CRC는 설계 목적에는 매우 뛰어나지만 보안성은 전혀 제공하지 않습니다.
refin과 refout은 실제로 무엇을 합니까?
refin은 각 입력 바이트를 레지스터에 넣기 전에 그 안의 비트 순서를 뒤집고, refout은 최종 레지스터의 비트 순서를 뒤집습니다. 이 둘이 존재하는 이유는 하드웨어 시프트 레지스터와 소프트웨어 테이블 구현이 비트를 반대 방향으로 밀어 넣기 때문이며, 반전 형태를 두면 양쪽이 같은 값에 도달할 수 있습니다. 이것은 바이트 순서와 다릅니다. 반전은 한 바이트 안의 비트에 작용하고, 엔디언은 바이트 자체의 앞뒤를 정합니다.
체크섬만 있고 원본 데이터가 없습니다. 이 도구로 거꾸로 알아낼 수 있습니까?
할 수 없고, 어떤 도구도 할 수 없습니다. CRC는 길이에 상관없이 메시지를 8비트나 16비트, 32비트로 압축하므로 서로 다른 무수한 메시지가 같은 값을 공유합니다. 노력을 더 들인다고 되는 문제가 아닙니다. 이 페이지의 역조회는 그보다 좁은 질문에 답합니다. 데이터 누군가 그 데이터로 계산한 체크섬이 함께 있을 때, 둘을 잇는 파라미터 집합이 무엇이냐는 질문입니다. 장비 응답은 잡았지만 그 뒤의 페이로드를 잡지 못했다면 페이로드부터 확보하십시오. 변형을 식별하는 것이 아니라 비트 폭 사이에서 고르는 문제라면 CRC-16 변형 정리를 참고하십시오.
장비 설명서에는 변형이 하나뿐인데 왜 63개를 모두 보여 줍니까?
정작 쓸모 있는 질문은 'CRC를 계산하라'가 아니라 '지금 손에 든 이 값을 산출한 변형이 어느 것인가'인 경우가 많기 때문입니다. 변형을 먼저 고르라고 요구하는 도구는 사용자가 이미 답을 안다고 전제합니다. 모든 변형을 한 번에 늘어놓으면 식별이 조회 한 번으로 끝나고, 옆에 붙은 파라미터 열 덕분에 이름만 믿는 대신 사양서와 대조해 일치를 확인할 수 있습니다.
입력한 데이터가 어딘가로 전송됩니까?
아닙니다. 계산 전체가 이 페이지의 표를 그린 것과 같은 엔진으로 브라우저 안에서 처리됩니다. 업로드도, API 호출도, 로그 기록도 없습니다. 네트워크를 끊어도 도구는 그대로 동작하는데, CRC의 입력이 실제 운영 프레임이나 펌웨어 이미지인 경우가 많다는 점을 생각하면 중요한 부분입니다.

AES 복호화 도구 — OpenSSL·CryptoJS 호환

보안 도구

온라인 AES 복호화 — GCM/CBC/CTR, 암호 문구 또는 원시 키, OpenSSL·CryptoJS "U2FsdGVkX1" 형식 자동 인식. 브라우저에서만 실행되며 키는 유출되지 않습니다.

AES 암호화 도구 — GCM, CBC, CTR 모드

보안 도구

무료 온라인 AES 암호화 도구 — AES-128/192/256, GCM/CBC/CTR, 암호 문구(PBKDF2) 또는 원시 키. 브라우저에서만 실행되고 서버 업로드는 없습니다.

Bcrypt 해시 생성 및 검증 도구

보안 도구

온라인으로 bcrypt 비밀번호 해시를 생성·검증하세요 — 조절 가능한 비용 인자, $2b$/$2a$/$2y$ 접두사 지원. 100% 브라우저에서 실행, 비밀번호는 업로드되지 않습니다.

HMAC 생성기 및 서명 검증 도구

보안 도구

무료 온라인 HMAC 생성·검증 도구. Text/Hex/Base64 키로 HMAC-SHA256/SHA1/SHA384/SHA512를 Hex/Base64/Base64URL로 출력. 100% 브라우저 실행, 키 유출 없음.

JWT 디코더 (JWT Decoder)

보안 도구

무료 JWT 디코더로 JWT 토큰을 온라인에서 즉시 디코딩. 헤더, 페이로드, 서명, 만료, 클레임 확인. 100% 브라우저 기반 — 토큰이 기기를 떠나지 않음. 가입·추적 없음.

JWT 인코더 (JWT Encoder)

보안 도구

무료 온라인 JWT 생성기·인코더. 헤더와 페이로드를 구성하고 HS256, RS256, ES256으로 즉시 서명. 100% 브라우저 기반 — 비밀 키와 개인 키가 기기를 떠나지 않음.