dd および dcfldd によるディスクイメージの取得 は何をしますか？
使用すべき状況
- 調査のために容疑者のドライブのフォレンジックコピーを作成する必要がある場合
- 分析前に揮発性ディスク証拠を保存するインシデント対応中
- 法執行機関や法的手続きにおいて、検証済みのビット単位のコピーが必要な場合
- ストレージデバイスに対して破壊的な分析を実行する前
- 物理ドライブ、USB デバイス、またはメモリーカードからイメージを取得する場合
前提条件
- Linux ベースのフォレンジックワークステーション (SIFT、Kali、または任意の Linux ディストリビューション)
dd(すべての Linux システムにプリインストール) またはdcfldd(拡張フォレンジック版)- ライトブロッカーハードウェア、またはソフトウェア書き込み保護が設定されていること
- ソースより大容量の保存先ドライブ
- フォレンジックワークステーションでの root/sudo 権限
- SHA-256 または MD5 ハッシュユーティリティ (
sha256sum、md5sum)
ワークフロー
ステップ 1: ターゲットデバイスの特定と書き込み保護の有効化
# 接続されているすべてのブロックデバイスを一覧表示し、ターゲットを特定する
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL
# デバイスの詳細を確認する
fdisk -l /dev/sdb
# ソフトウェア書き込み保護を有効にする (ハードウェアブロッカーがない場合)
blockdev --setro /dev/sdb
# 読み取り専用ステータスを確認する
blockdev --getro /dev/sdb
# 出力: 1 (読み取り専用が有効であることを意味する)
# または、永続的な書き込み保護のために udev ルールを使用する
echo 'SUBSYSTEM=="block", ATTRS{serial}=="WD-WCAV5H861234", ATTR{ro}="1"' > /etc/udev/rules.d/99-writeblock.rules
udevadm control --reload-rules
ステップ 2: 保存先の準備とソースの文書化
# 案件ディレクトリ構造を作成する
mkdir -p /cases/case-2024-001/{images,hashes,logs,notes}
# ソースドライブ情報を文書化する
hdparm -I /dev/sdb > /cases/case-2024-001/notes/source_drive_info.txt
# シリアル番号とモデルを記録する
smartctl -i /dev/sdb >> /cases/case-2024-001/notes/source_drive_info.txt
# ソースデバイスの事前ハッシュを取得する
sha256sum /dev/sdb | tee /cases/case-2024-001/hashes/source_hash_before.txt
ステップ 3: dd を使用したイメージの取得
# 進捗表示とエラー処理を伴う基本的な dd 取得
dd if=/dev/sdb of=/cases/case-2024-001/images/evidence.dd \
bs=4096 \
conv=noerror,sync \
status=progress 2>&1 | tee /cases/case-2024-001/logs/dd_acquisition.log
# 容量節約のための圧縮イメージ
dd if=/dev/sdb bs=4096 conv=noerror,sync status=progress | \
gzip -c > /cases/case-2024-001/images/evidence.dd.gz
# 特定のカウントを指定した部分取得
dd if=/dev/sdb of=/cases/case-2024-001/images/first_1gb.dd \
bs=1M count=1024 status=progress
ステップ 4: dcfldd を使用した取得 (推奨フォレンジック手法)
# dcfldd がインストールされていない場合にインストール
apt-get install dcfldd
# 内蔵ハッシュと分割出力を使用してイメージを取得する
dcfldd if=/dev/sdb \
of=/cases/case-2024-001/images/evidence.dd \
hash=sha256,md5 \
hashwindow=1G \
hashlog=/cases/case-2024-001/hashes/acquisition_hashes.txt \
bs=4096 \
conv=noerror,sync \
errlog=/cases/case-2024-001/logs/dcfldd_errors.log
# 大きなイメージを管理可能なセグメントに分割する
dcfldd if=/dev/sdb \
of=/cases/case-2024-001/images/evidence.dd \
hash=sha256 \
hashlog=/cases/case-2024-001/hashes/split_hashes.txt \
bs=4096 \
split=2G \
splitformat=aa
# 検証パスを伴う取得
dcfldd if=/dev/sdb \
of=/cases/case-2024-001/images/evidence.dd \
hash=sha256 \
hashlog=/cases/case-2024-001/hashes/verification.txt \
vf=/cases/case-2024-001/images/evidence.dd \
verifylog=/cases/case-2024-001/logs/verify.log
ステップ 5: イメージの整合性検証
# 取得したイメージのハッシュを計算する
sha256sum /cases/case-2024-001/images/evidence.dd | \
tee /cases/case-2024-001/hashes/image_hash.txt
# ソースハッシュとイメージハッシュを比較する
diff <(sha256sum /dev/sdb | awk '{print $1}') \
<(sha256sum /cases/case-2024-001/images/evidence.dd | awk '{print $1}')
# 分割イメージを使用する場合、各セグメントを検証する
sha256sum /cases/case-2024-001/images/evidence.dd.* | \
tee /cases/case-2024-001/hashes/split_image_hashes.txt
# ソースの再ハッシュ化により変更がないことを確認する
sha256sum /dev/sdb | tee /cases/case-2024-001/hashes/source_hash_after.txt
diff /cases/case-2024-001/hashes/source_hash_before.txt \
/cases/case-2024-001/hashes/source_hash_after.txt
ステップ 6: 取得プロセスの文書化
# 取得レポートを生成する
cat << 'EOF' > /cases/case-2024-001/notes/acquisition_report.txt
ディスクイメージ取得レポート
==============================
案件番号: 2024-001
日時: $(date -u +"%Y-%m-%d %H:%M:%S UTC")
検査担当者: [氏名]
ソースデバイス: /dev/sdb
モデル: [hdparm の出力から]
シリアル番号: [hdparm の出力から]
容量: [fdisk の出力から]
取得ツール: dcfldd v1.9.1
ブロックサイズ: 4096
ライトブロッカー: [ハードウェア/ソフトウェア モデル]
イメージファイル: evidence.dd
イメージハッシュ (SHA-256): [ハッシュファイルから]
ソースハッシュ (SHA-256): [ハッシュファイルから]
ハッシュ一致: はい/いいえ
取得中のエラー: [エラーログから]
EOF
# アーカイブ用にログを圧縮する
tar -czf /cases/case-2024-001/acquisition_package.tar.gz \
/cases/case-2024-001/hashes/ \
/cases/case-2024-001/logs/ \
/cases/case-2024-001/notes/
主要な概念
| 概念 | 説明 |
|---|---|
| ビット単位のコピー | 未割り当て領域やスラック領域を含む、ソースの正確な複製 |
| ライトブロッカー | 証拠メディアへの書き込みを防止するハードウェアまたはソフトウェア機構 |
| ハッシュ検証 | ソースとイメージを比較し、整合性を証明する暗号学的ハッシュ |
| ブロックサイズ (bs) | 速度に影響する転送チャンクサイズ。フォレンジックでは 4096 または 64K が一般的 |
| conv=noerror,sync | 読み取りエラーでも続行し、オフセットの整合性を維持するためにゼロ埋めする |
| 保管の連鎖 (Chain of Custody) | 証拠が改ざんされていないことを証明する文書化された経路 |
| 分割イメージング | 大きなイメージを小さなファイルに分割して保存・運搬する手法 |
| Raw/dd 形式 | メタデータコンテナのオーバーヘッドがないビット単位のイメージ形式 |
ツールとシステム
| ツール | 目的 |
|---|---|
| dd | 標準的な Unix ディスク複製ユーティリティ。raw イメージングに使用 |
| dcfldd | DoD Computer Forensics Laboratory による dd の拡張版。ハッシュ機能を搭載 |
| dc3dd | DoD Cyber Crime Center によるもう一つのフォレンジック dd 派生版 |
| sha256sum | 整合性検証のための SHA-256 ハッシュ計算 |
| blockdev | ブロックデバイスの読み取り専用モードを設定する Linux コマンド |
| hdparm | ドライブの識別とパラメータレポート |
| smartctl | ドライブの健全性と識別のための S.M.A.R.T. データ取得 |
| lsblk | ブロックデバイスの列挙と識別 |
一般的なシナリオ
シナリオ 1: 容疑者のノートパソコンのハードドライブを取得する
ドライブを Tableau T35u ハードウェアライトブロッカー経由で接続し、/dev/sdb として特定します。SHA-256 ハッシュを使用した dcfldd で取得し、DVD アーカイブ用に 4GB セグメントに分割します。ハッシュが一致することを確認し、ケースノートに文書化します。
シナリオ 2: 侵害されたワークステーションから USB フラッシュドライブをイメージングする
blockdev --setro でソフトウェア書き込み保護を使用します。MD5 と SHA-256 の二重ハッシュを含む dcfldd で取得します。イメージは単一ファイルで十分な小容量です。検証後、暗号化されたケースドライブに保存します。
シナリオ 3: ネットワーク経由のリモート取得
リモート取得には、netcat または ssh を介してパイプ処理した dd を使用します: ssh root@remote "dd if=/dev/sda bs=4096" | dd of=remote_image.dd bs=4096。両端で独立してハッシュを計算し、転送の整合性を検証します。
シナリオ 4: 障害が発生しているドライブからの取得
最初に ddrescue を使用して読み取り可能なセクタを復旧し、その後 conv=noerror,sync を指定した dd を使用してギャップをゼロで埋めます。エラーログにどのセクタが読み取り不能だったかを文書化します。
出力形式
取得サマリー:
ソース: /dev/sdb (500GB Western Digital WD5000AAKX)
保存先: /cases/case-2024-001/images/evidence.dd
ツール: dcfldd 1.9.1
ブロックサイズ: 4096 バイト
所要時間: 2h 15m 32s
コピーバイト数: 500,107,862,016
エラー: 0 不良セクタ
ソース SHA-256: a3f2b8c9d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1
イメージ SHA-256: a3f2b8c9d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1
検証: 成功 - ハッシュ一致