大規模検査
同時に多数のドライブ検査を実現できる「スマートエディション」をご用意しております。
【ドライブ検査: 統計スキャン】FromHDDtoSSD 統計スキャン ドライブ検査 – 商用ライセンス版
概要：複数ドライブ同時検査に対応
スマートエディションは複数台のHDD/SSDを同時に検査したいパソコンショップ・修理サービス向けに提供されるバージョンです。
このエディションはダウンロード版ではなく専用USBメモリとしてご提供いたします。
検査対象PCに一切書き込まない安心設計
本製品に含まれるUSBメモリにはブロックチェーン構造を含む全データが内蔵されており外部への書き出しは一切なし。検査対象のパソコンに1バイトたりとも書き込むことなく安全に検査を実行できます。
主な特長：
- SSDの取り外し不要
- 対象PCにUSBを挿すだけで即検査
- 機密情報を保持したまま安心利用
- 書き込み禁止USB仕様で万全な情報漏洩対策
定期同期：常に最新版へ
USBメモリは通常「書き込み禁止モード」で動作しますがブロックチェーン同期が必要な場合のみ一時的に解除可能。
- オンライン環境で起動 → 最新の統計情報を同期
- 同期後、再び書き込み禁止モードへ戻して運用
この仕組みにより全端末で一貫した精度と安心運用が可能です。
スマートエディションの導入実績（一例）
- パソコン修理サービス現場での診断用途
- 自作PC/ショップブランドPCの品質管理
- HDD/SSDの大量スクリーニング検査
ブロックチェーン連携による利点
① 改ざん不可能な信頼性
L1ブロックチェーン技術により検査ログや統計データはすべて改ざん不可。信頼性の高い記録で、正確な予測・トラブル分析が可能です。
② コスト削減・効率化
従来の中央管理システムと比較してコストを抑えつつリアルタイム処理が可能。異常検知やトラブル時の対応もスピーディーに。
③ プライバシー＆セキュリティ
分散型ネットワーク上で暗号化された情報処理によりクライアントの情報も守りながら高度な検査を実現。L2 – 2048ビット 量子耐性により、安全な暗号で情報を守ります。
④ 分散型統計データの集約
地理的に分散された現場からでも偏りのないビッグデータ収集が可能。
ご採用例 [大規模検査 スマートエディション]
- パソコン修理サービス向け ドライブ検査
- ショップブランドパソコン検査
- HDD/SSD向け大規模検査
【ドライブ検査・データ復旧】ファイルシステムに触れてみる C言語の準備です
ファイルシステムに直接触れ、状態を解析し、必要に応じて修復する。
つまり、データ復旧作業を行うためには、ドライブ上の情報を低レイヤーで扱える仕組みが必要になります。
そのためには、セクタ単位で読み出したデータをメモリ上に展開し、その内容を直接解析できる言語が適しています。
そこで重要になるのが、C言語です。
C言語は、メモリ上のデータ構造を直接扱うことができ、バイナリデータ、構造体、ポインタ、ビット単位の処理などにも対応しやすい言語です。
今の時代であっても、ドライブやファイルシステムのような低レイヤー領域を扱う場合には、昔から使われてきたC言語の考え方が非常に重要になります。
ここで大切なのは、ドライブとファイルシステムの関係です。
ドライブは、あくまでセクタサイズを単位として情報を読み書きしているだけです。
ドライブ自身が、ファイル名やフォルダ構造、拡張子、MFT、FAT、ディレクトリ構造などを理解しているわけではありません。
ドライブから見れば、すべてはセクタ単位に分割されたデータです。
一方で、ファイルシステムは、そのセクタ上に記録された情報を解釈し、ファイル名、フォルダ構造、配置情報、属性情報、実データの位置などとして管理しています。
つまり、同じセクタの情報であっても、ドライブ側から見れば単なる読み書き対象であり、ファイルシステム側から見れば意味を持った管理構造になります。
この視点は、データ復旧において非常に重要です。
ファイルが見えない、フォルダ構造が壊れている、OSからアクセスできない。
そのような状態であっても、セクタ上にはまだ実データや管理情報が残っている場合があります。
だからこそ、ファイルシステムの論理構造だけを見るのではなく、セクタ単位でデータを読み取り、その中身を直接解析する必要があります。
C言語は、そのようなセクタ単位のデータ、メモリ上のバッファ、ファイルシステムの構造体を扱ううえで、非常に相性のよい言語です。
まずはC言語を使って、ドライブから読み出したバイナリデータをどのように扱うのか。
そして、その中からファイルシステムの情報をどのように読み解いていくのか。
そこから順に見ていきます。
【ドライブ検査・データ復旧】ファイルシステムに触れてみる セクタをメモリ空間として解釈する
ファイルシステムに直接触れるには、セクタから読み出した情報をメモリ上に展開し、その内容を解析していく必要があります。
つまり、ドライブから取得したセクタデータをバッファへ読み込み、そのメモリ領域に対して、構造体やポインタを使いながら解析していく流れになります。
ここで重要なのは、通常のアプリケーション開発で行うような、オブジェクトを実体化して各メンバを操作する手法とは少し考え方が異なる点です。
ファイルシステム解析では、先にメモリ上に生のバイナリデータがあります。
そのバイナリデータを、あとから構造体として解釈していきます。
つまり、構造体を作ってデータを入れるのではなく、すでに存在するメモリ上のデータを、構造体として読み解くという考え方になります。
このような処理でよく使われる考え方の一つに、可変長構造体があります。
可変長と聞くと、C++のvectorのような構造を思い浮かべるかもしれません。
しかし、ファイルシステム解析で扱う可変長構造体は、それとは性質が異なります。
vectorは、メモリ上で要素数を増減できる便利なコンテナです。
ただし、それはあくまでプログラム上のオブジェクトとして可変長に振る舞っているものです。
ファイルシステム上に記録されているデータ構造を、そのままvectorとして扱うことはできません。
もちろん、セクタデータを読み込むためのバッファとして、あらかじめresizeしたvectorを使うことはできます。
しかし、push_backやemplace_backのような操作で、ファイルシステム上の構造そのものを扱うわけではありません。
ファイルシステム解析で必要になるのは、メモリ上に展開されたバイナリデータを、そのまま構造体として解釈する考え方です。
では、C言語で可変長構造体をどのように表現するのでしょうか。
古くから使われてきた方法として、構造体の最後に、要素数1のunsigned char配列を置く手法があります。
たとえば、構造体の最後に次のようなメンバを置きます。
unsigned char data[1];
unsigned charは、純粋なバイト列を扱うための器として使えます。
このdata[1]は、単なる1バイトの配列というより、その先に続く可変長データの開始位置を示す目印として使われます。
重要なのは、この配列が構造体の最後に置かれている点です。
構造体の最後に可変長データの開始位置を置くことで、固定長のヘッダ部分を読み取ったあと、その直後に続くデータ領域を別の構造として解釈できるようになります。
たとえば、ヘッダ構造体の中にサイズ情報やオフセット情報が含まれている場合、その情報をもとに、ヘッダの後ろに続く属性データや可変長データを読み解いていきます。
このとき、ポインタを進めたり、再解釈キャストを行ったりして、メモリ上の別の位置を別の構造体として扱います。
つまり、ヘッダに可変長データの開始位置を示すメンバがある場合、その先に別の構造体や属性情報が連続して配置されている可能性があります。
そのため、サイズ情報やオフセット情報を確認しながら、次の構造へ進んでいく必要があります。
このような処理では、構造体全体のサイズにも注意が必要です。
最後にunsigned char data[1]を置く方式では、sizeofで取得される構造体サイズには、その1バイト分も含まれます。
そのため、固定長ヘッダ部分だけのサイズを求めたい場合は、その1バイト分を差し引くか、より安全にはoffsetofを使って可変長メンバの開始位置を求めます。
可変長部分の実際のサイズは、構造体内に記録されているサイズ情報や、ファイルシステム側の管理情報から判断します。
なぜ、このような構造が使われるのでしょうか。
それは、ドライブがセクタ単位でしか情報をやり取りしないためです。
ドライブは、ファイル名やフォルダ構造を理解しているわけではありません。
ただ、指定されたセクタのバイト列を読み書きしているだけです。
そのバイト列を、ファイルシステム側がヘッダ、属性、データ、管理情報として解釈しています。
つまり、セクタ上のデータは、メモリ上に展開された瞬間に、構造体として読み解く対象になります。
パソコンやスマートフォンが動作しているこの瞬間にも、内部ではこのようなバイナリ構造が読み書きされ、ファイルシステムが管理されています。
データ復旧では、その仕組みを逆方向から読み解きます。
セクタを読み出し、メモリに展開し、構造体として解釈する。
そして、壊れたファイルシステムの中から、まだ残っている管理情報や実データを探し出す。
この考え方こそが、ファイルシステム解析の基本になります。
【ドライブ検査・データ復旧】ファイルシステムに触れてみる ヘッダと、その中身
前回は、可変長構造体の概要について説明しました。
実際、ファイルシステムは、このような構造体の集合として考えることができます。
セクタ上に記録されたバイナリデータを読み出し、その一つ一つを構造体として解釈していく。
そして、その先に続く情報をたどることで、ファイル名、フォルダ構造、配置情報、実データの位置などが見えてきます。
つまり、ファイルシステム解析とは、セクタ上にある情報を、構造体として順番に読み解いていく作業でもあります。
そこで、まず重要になるのがヘッダの概念です。
可変長構造体では、多くの場合、先頭にヘッダと呼ばれる領域があります。
このヘッダには、その構造体が何を表しているのか、どれくらいのサイズなのか、次のデータがどこにあるのか、といった情報が格納されます。
つまり、ヘッダを読むことで、その先にどのようなデータが、どのような形式で配置されているのかを判断できるようになります。
ファイルシステムでも、この考え方は非常に重要です。
多くの管理構造は、まずヘッダから始まり、その中に含まれるサイズ情報、オフセット情報、種別情報などをもとに、次の構造へ進んでいきます。
ここで関係してくるのが、データの連続性です。
これはC言語に限らず、データ構造全般に共通する考え方です。
情報は、メモリ上に連続したバイト列として配置されます。
配列も、その基本は同じです。
配列は、同じ型のデータをメモリ上に連続して並べた構造です。
そのため、要素の型のサイズが分かれば、先頭アドレスから順番に各要素へアクセスできます。
たとえば、4バイトの要素で構成された配列であれば、次の要素は4バイト先にあります。
このように、型のサイズがスケーリングファクタとして働くことで、配列を順番にたどることができます。
一方、構造体は、異なる型のメンバを一つにまとめたものです。
整数、フラグ、サイズ情報、オフセット、バイト列など、異なる意味を持つデータを、ひとまとまりの構造として扱うことができます。
本来、構造体のサイズはコンパイル時に決まる固定長のものです。
しかし、前回説明したように、構造体の最後に可変長データの開始位置を持たせることで、固定長のヘッダと可変長のデータ部分を組み合わせて扱うことができます。
この仕組みによって、ファイルシステムのような柔軟なデータ構造を解析できるようになります。
さて、実際の解析では、まずヘッダを読み込みます。
ここで気になるのが、エンディアンです。
つまり、複数バイトで構成される数値が、どの順番で記録されているのか、という問題です。
構造体には、uint16_t、uint32_t、uint64_tのように、エンディアンの影響を受ける型が多く含まれます。
たとえば、NTFSのようなWindows系のファイルシステムでは、多くの数値がリトルエンディアンで記録されています。
これは、IntelやAMDのCPUで一般的なメモリ表現とも一致します。
そのため、Windows環境でNTFSのセクタを読み出し、メモリ上に展開した場合、リトルエンディアンの値をそのまま構造体として解釈しやすい場面があります。
ただし、ここで注意が必要です。
ディスク上のデータは、単にCPU上の構造体がそのまま書き込まれているとは限りません。
ファイルシステムには、それぞれ仕様として定められたオンディスク形式があります。
つまり、NTFSであればNTFSの形式として、どの位置にどの情報があり、どのエンディアンで記録されているのかが決まっています。
解析では、その仕様に合わせて、セクタ上のバイト列を読み解いていく必要があります。
とはいえ、リトルエンディアンで記録されたファイルシステムを、同じくリトルエンディアン環境のC言語で扱う場合は、構造体として解釈しやすい利点があります。
セクタを読み出し、メモリに展開し、ヘッダを構造体として確認する。
そこからサイズ、オフセット、種別、次のデータ位置を読み取り、さらに先の構造へ進んでいく。
この流れが、ファイルシステム解析の基本になります。
ヘッダを読むことは、単に先頭の数バイトを見ることではありません。
その先に続くデータ構造全体を理解するための入口を確認する作業です。
ファイルシステムに触れるということは、セクタ上のバイト列を、ヘッダから順に意味のある構造として読み解いていくことなのです。
【ドライブ検査・データ復旧】ファイルシステムに触れてみる 属性別の再解釈
ファイルシステムには、さまざまな属性があります。
たとえば、ファイル、フォルダ、データ本体、管理情報、インデックス情報などです。
これらの情報は、それぞれ異なる役割を持っており、ファイルシステム内では属性やフラグによって識別されます。
ここで重要になるのが、属性ごとの構造の違いです。
ファイルシステム上では、共通のヘッダを持ちながら、その先に続く内容は属性によって異なる構造になっていることがあります。
そのため、まずは共通部分を持つ構造体として読み取り、属性の種類やサイズ、オフセットなどを確認します。
そのうえで、属性に応じた別の構造体へ再解釈し、内容を読み解いていきます。
つまり、バッファ上のデータそのものは変わりません。
変わるのは、そのバイト列をどの構造体として解釈するか、という点です。
同じメモリ上のデータであっても、最初は共通ヘッダとして読み、次にファイル属性、フォルダ属性、データ属性、インデックス属性などとして再解釈していく。
このような流れで、ファイルシステムの情報を読み書きできるようになっています。
この仕組みによって、最小限の読み出しで多くの情報を効率よく処理できます。
セクタを読み出し、バッファに展開し、その内容を属性ごとに再解釈する。
この流れを適切に組み立てることで、無駄な読み込みを減らし、解析速度を高めることができます。
ただし、NTFSは構造が複雑なファイルシステムです。
MFT、属性、データラン、インデックス、セキュリティ情報など、多くの管理構造が組み合わさっています。
そのため、高機能で柔軟な一方、解析や処理は重くなりやすい傾向があります。
この点は、USBメモリやSDカードなどで、今でもFAT32やexFATが使われる理由の一つでもあります。
FAT32なども、セクタ上の情報を構造体として解釈しながら読み書きする点では同じです。
ドライブがセクタ単位で情報をやり取りする以上、この基本的な考え方は共通しています。
しかし、FAT32はNTFSと比べると構造が非常に単純です。
管理情報も比較的軽量で、処理の負担が少ないため、USBメモリや小容量メディアのような用途では扱いやすい構造になっています。
つまり、ファイルシステムごとに複雑さや機能は異なりますが、基本は同じです。
セクタを読み出し、メモリ上に展開し、ヘッダを確認する。
そして、属性やフラグに応じて構造体を切り替えながら、同じバイト列を再解釈していく。
この属性別の再解釈こそが、ファイルシステム解析における重要な考え方になります。
【ドライブ検査・データ復旧】ファイルシステムに触れてみる 読み込めないけれど書き込めるため、チェックディスクで損傷が拡大する場合
ここまで、ファイルシステムの構造や、不良セクタの性質について見てきました。
そこで重要になるのが、チェックディスクです。
チェックディスクが検査・修復の対象としているのは、当然ながらファイルシステムの管理領域です。
MFT、ディレクトリ情報、インデックス情報、配置情報など、ファイルシステムを構成する重要な領域に対して、整合性を確認し、必要に応じて修復処理を行います。
ここで、不良セクタの性質をもう一度考えてみます。
ドライブでは、書き込みよりも先に、読み込み側の不安定化が表面化することがあります。
つまり、「読み込めないけれど、書き込みはまだできる」という状態が起こり得ます。
この性質が、チェックディスクと組み合わさると、非常に厄介な状況になります。
チェックディスクを実行する。
ファイルシステムの管理領域を読み取ろうとする。
しかし、読み取り不能セクタや不安定な領域に当たり、正しく読み取れない。
すると、チェックディスクは、その部分に不整合や破損があると判断し、修復を試みます。
たとえば、元のフォルダ構造やファイル名との対応が取れなくなったデータを、found.000のような形で回収しようとする場合があります。
ここで重要なのは、その修復結果がメモリ上で作られるだけでは終わらないという点です。
チェックディスクは、修復結果をファイルシステムへ書き戻します。
もしこのとき、書き込み側まで完全に故障していれば、書き込み自体が成立せず、結果として元の管理情報が変化しない場合もあります。
しかし、実際には、読み込み側が壊れていても、書き込み側はまだ動作していることがあります。
その場合、読み取れなかったことを前提に作られた修復結果が、正常に書き込まれてしまいます。
つまり、元の管理情報が読み取れない状態で、チェックディスクが新しい整合性情報を書き込み、found.000などを含む修復後の構造へ置き換えてしまうことがあります。
これにより、ファイルシステムの損傷がさらに進み、データ復旧が難しくなる場合があります。
チェックディスクの弊害は、このようなドライブの性質から生じます。
本来、チェックディスクはファイルシステムを修復するための機能です。
しかし、壊れかけたドライブや、不良セクタが発生しているドライブに対して実行すると、読み取れない情報を破損と判断し、その結果を管理領域へ書き戻してしまうことがあります。
そのため、読み込み不能が発生しているドライブに対して、安易にチェックディスクを実行することは危険です。
特に、重要なデータが残っている場合は、まず書き込みを伴う修復操作を避け、現状のままデータを保全することが重要になります。
読み込めない。しかし、書き込めてしまう。
この状態こそが、チェックディスクによってファイルシステムの損傷が拡大する大きな原因の一つです。