CRC 計算 — CRC-8 / CRC-16 / CRC-32 / CRC-32C を一括算出

CRC 計算に使うバイト列には、通信データや内部プロトコルが含まれる

CRC の検証は、組み込みシステム・産業機器・通信プロトコルのデバッグで日常的に行われます。CRC を計算するために入力するデータは、Modbus RTU のフレーム (工場の機器制御コマンド)、ZIP / gzip / PNG ファイルの一部 (チェックサム確認のための内部バイト列)、イーサネットフレームやブルートゥースパケットのキャプチャデータなど、内部プロトコルや業務上の通信内容を含む場合があります。

特に産業用 Modbus では、デバイスアドレス・ファンクションコード・レジスタ値がペイロードに直接含まれます。これらはファクトリーオートメーションの制御ロジックそのものであり、外部に出すべき情報ではありません。HEX バイト列をオンラインの CRC 計算機に貼り付けることは、その制御コマンドを外部サーバーに送信することになります。

組み込みデバッグ中のデータがオンラインに出るリスク

CRC の計算結果がデータシートや参照実装と一致しないとき、デバッグで取得したバイト列をオンラインの CRC 計算機に貼り付けて確認することがあります。そのバイト列がシリアル通信のキャプチャであれば、デバイスの動作状態・設定値・センサーデータが含まれている可能性があります。プロプライエタリな通信プロトコルのフレームであれば、機器の内部仕様を示す情報になります。

CRC 計算は「チェックサムの検証」という目的で行われますが、その副産物として「計算したい実データ」が外部サービスに届いてしまいます。CRC 計算ツールはセキュリティツールではないため、入力データの取り扱いに関するポリシーが明示されていないサービスが多くあります。

多項式テーブルルックアップのみ: ブラウザ内完結

CRC 計算はルックアップテーブル (256 エントリの事前計算テーブル) を使った反復処理で実装されます。各アルゴリズム (CRC-8 / CRC-16 CCITT / CRC-16 Modbus / CRC-32 / CRC-32C) の多項式・初期値・反射設定・XOR-out 値はコードに埋め込まれており、ネットワークリクエストは一切不要です。入力は UTF-8 の TextEncoder.encode() または HEX パーサーでバイト配列に変換後、テーブルルックアップで処理します。

5 種類の CRC が同時に計算されますが、すべてブラウザのメモリ内でのみ処理されます。DevTools の Network タブを開いた状態でデータを入力・変更しても追加リクエストは発生しません。

データシートとの照合を安全に行う

機器のデータシートに記載された CRC 仕様と実装が一致しているかを確認するためのデバッグ作業は、ローカルツールで完結できます。本ツールは各 CRC のパラメータ (Poly / Init / RefIn / RefOut / XorOut) を表示するため、データシートとの突き合わせが容易です。Modbus や各種シリアルプロトコルの実フレームを HEX で入力して CRC 計算値を確認する際、そのフレームの内容は外部サーバーに届きません。

生成多項式・GF(2) と CRC の数学的基盤

CRC は数学的には GF(2) (2 元体、ガロア体) 上の多項式の剰余演算です。入力バイト列 0x48 0x69 (Hi) を bit 列 0100100001101001 に展開し、これを多項式 x^15 + x^11 + x^9 + ... + x^0 として扱います。これに x^N (N は CRC 幅) を掛けて生成多項式 G(x) で割り算した剰余が CRC 値になります。例えば CRC-32 (ISO-HDLC) の生成多項式は x^32 + x^26 + x^23 + ... + x^0 という 32 次の多項式で、0x04C11DB7 という HEX で表現されます。

GF(2) では足し算が XOR、掛け算が AND になるため、通常の整数演算とは挙動が異なります。割り算 (実装上は最上位ビットが立ったら G(x) を XOR してビットシフト) も XOR ベースの操作だけで実行できるため、ハードウェアではシフトレジスタ + XOR ゲートだけの少ない回路で実装でき、高速に動作します。ソフトウェア実装では 256 エントリのルックアップテーブル (各バイト値 0-255 に対する CRC 計算結果を事前計算した表) を使うことで、1 バイトずつ XOR + テーブル参照だけで処理できる「Sarwate アルゴリズム」が定番です。本ツールも全 CRC バリアントでこのテーブル方式を採用しています。

CRC バリアントの命名: なぜ「CRC-16」が複数あるのか

CRC は「CRC-N (N ビット幅)」という名前だけでは一意に定まりません — 同じ 16 ビット幅でも、生成多項式・初期値・入力反転・出力反転・最終 XOR 値の違いで全く別物になります。Catalogue of parametrised CRC algorithms (reveng.sourceforge.net) は 100 以上の CRC バリアントを 6 つのパラメータ (width, poly, init, refin, refout, xorout) でカタログ化しており、同じ多項式でも refin/refout が反対なら全く別の値が出ます。

本ツールが扱う 5 つのバリアントは: CRC-8 (poly 0x07, init 0x00、SMBus / 1-Wire で使用)、CRC-16/CCITT-FALSE (poly 0x1021, init 0xFFFF, refin/refout false、XMODEM などレガシーで多用)、CRC-16/Modbus (poly 0x8005, init 0xFFFF, refin/refout true、Modbus RTU)、CRC-32/ISO-HDLC (poly 0x04C11DB7, init 0xFFFFFFFF, refin/refout true, xorout 0xFFFFFFFF、ZIP / PNG / Ethernet / gzip)、CRC-32C/Castagnoli (poly 0x1EDC6F41, init 0xFFFFFFFF、SCTP / iSCSI / Btrfs)。CRC-32C は 2002 年に Castagnoli が衝突確率を最小化する多項式として発表したもので、Intel CPU の SSE4.2 命令 CRC32C でハードウェア実装されています。

機器のデータシートで「CRC-16 を使う」とだけ書かれていてビットが合わない場合、まず CCITT-FALSE と Modbus を両方試すのが定石です。本ツールは 5 つを同時計算するので、データシート側の仕様が曖昧でも視覚的に「どのバリアントの値と一致するか」を確認できます。フレームの内訳をビット単位で眺めたいときは binary-text で同じ HEX を 0/1 列に展開でき、改ざん検出ではなく暗号学的な完全性を求める場合は hash-generate で SHA-256 などの一方向ダイジェストに切り替えるのが正解です (CRC は誤り検出専用で衝突攻撃には弱いため)。