業界トップクラスのデータ復旧率！最新の設備とベテランエンジニアが大切なデータを復旧・復元します。
業界トップクラスのデータ復旧率！最新の設備とベテランエンジニアが大切なデータを復旧・復元します。
久々のブログ記事となってしまいました。忙しくてなかなか更新できず…。
本記事でご紹介する復旧事例は、I・O DATA製NASドライブ「Lan Disk HDL-TA」シリーズです。
HDD1本内蔵モデルの「HDL-TA1」「HDL-TA2」「HDL-TA3」「HDL-TA4」、HDD2本内蔵モデルの「HDL2-TA2」「HDL2-TA4」「HDL2-TA6」「HDL2-TA8」の8種類あるようです。
さて、このシリーズのNASですが「じぶんフォルダー」という機能がありますが、当該機能の使用にかかわらず、データ用パーティション（+システム用パーティション）が暗号化されています。
そのため、故障していたHDDからデータを抽出できたとしても、復号しない限りは保存されていたファイル復旧できません。
（https://www.iodata.jp/lib/manual/pdf2/hdl-ta_b-manu202553.pdf より引用。 こちらのページからこのpdfをダウンロードできます。）
このNASのマニュアルを読むと、早々に「本製品はデータ復旧サービスを使えません」と記載されています。
しかし、諦める必要はありません。記事にしているぐらいなので、復号する方法はちゃんとあります！
（というか I・O DATA さんも当然知っていますよね…?）
暗号化されていると何が難しいのでしょうか？
暗号化されていてもクローンドライブを作成して、元の筐体に装填すればよいではないか？と思われるかもしれませんが、問題点があるのです。（とはいえその方法でうまくいくときもあります。）
– NAS起動による復号は軽微なエラーでないと困難
オリジナルのHDDの状態が悪くエラーが多数発生した場合、欠損の多いクローンドライブとなってしまいます。クローンドライブは正常でも抽出したデータに欠損が多いと、NASのシステム（Linux）がフォルダー構造等を正常に認識できません。その場合NASとして機能しないので、ネットワークを介したアクセスはできず、復号されたファイルを取り出せません。また、欠損部分によっては、データどころかNASのシステム自体を起動できない可能性もあります。
– 論理障害が発生していた場合対応できない
HDDが故障していなくともデータ構造が壊れていてフォルダー構造を正常に読み取れない場合、先ほどと同様にNASとして機能しないので、クローンドライブを筐体に装填する方法では復号されたファイルを取り出せません。また、現存するファイルにしかアクセスできないため（ブロックデバイスとして扱えないため）、削除データの復元もできません。
– NAS筐体の基板が故障した場合、基板の単純な交換では対応できない
実は復号のための鍵が筐体の基板にあるので、基板交換してしまうと暗号化されたパーティションを正常に復号できず、NASのシステムはフォルダー構造を認識できません。そのため、筐体の基板が故障している場合、それを修理する必要があります。
なお、弊社ではオリジナルの基板が故障していても問題なく復号できますが、オリジナルの基板を廃棄したり紛失したりしてしまった場合は復号できません。
上記のような状態からでも復旧するためには、やはり、データ用パーティションを直接復号できる方が有利なのです。
ステータスランプが緑で点滅しアクセス不可。他社への復旧依頼でHDDは故障していないが暗号化されているため、復旧できないと診断された。
5日間程度
正常なファイルを230GB程度復旧（ファイル数は360,000件程度）
ただし、フォルダー構造は不完全
本件のモデルHDL2-TA2では、1TBのHDDが2本内蔵されていました。
まずはそれぞれのドライブのクローンを作成します。
他社様の診断ではHDDは故障していないということですが、原本のHDDを改変しないようにするためと、万が一の故障に備えて原本での作業を避けるためです。
また、本当にエラー等が発生しないかチェックも兼ねています。
では作成したクローンドライブの中身をみてみると…
どういう訳か、Ext4というファイルシステム（＝記録形式）でフォーマットされている様です。どうしてこうなった…?
通常は次の図のようにファイルシステムは何も認識されません。暗号化されているためです。復号すると、XFSというファイルシステムになりますので、Ext4は全く関係がありません…。
関係の無い形式でフォーマットされているので、このHDDをNASの筐体に入れて起動したとしても、ファイルにアクセスできないというのは明らかです。
しかし、作成したクローンのデータは暗号化されていますので、そのデータを解析してもファイルを復旧することなどできません。
本来は暗号化されているデータ用パーティションを復号すればXFSというファイルシステムが出てくるところですが、データ構造が破損していることを覚悟して強制的に復号します。
その後、復号されたデータをスキャンしてファイルを取り出すしかありません。
復号キーを抽出すれば復号処理自体はLinuxでできるのですが、データの解析が必要なので、復旧用ツールを使って復号しました。
次の図は復号前の状態で、赤枠に囲まれたパーテイションがターゲットのデータ用パーティションです。
先ほどのパーティションを復号すると、単に「Storage partition」と出てきます。これはファイルシステムを認識できていないためです。
本来であればXFSというファイルシステムが認識されるのですが、Ext4にフォーマットされた後に無理矢理復号をかけているので、パーティションの先頭部分は無意味な値の羅列になってしまいます。
復号をかけたパーティションを解析した結果、次の図の右側のようなフォルダーが出てきました。
関係のないファイルシステム（Ext4）にフォーマットされた後に復号をかけているので、先頭部分はランダムデータが書き込まれており、正規のデータ構造が失われた状態です。
しかし、残りの部分は幸いにも上書きされていなかったので、完全ではないにしろ、復号後はパーティションをサルベージできる程度にはなったということです。
お客様のデータですので下図ではフォルダー名を消していますが、共有フォルダーのルート直下と思われる内容であり（「disk1」フォルダーの中身）、お客様が必要としているフォルダーが含まれていました。
また、一本のドライブからきちんとデータを取り出せたので、RAIDの構成もミラーリングであることが分かりました。
もしストライピングであったら、各ドライブのデータ用パーティションをそれぞれ強制的に復号して、RAIDを再構築する必要がありました。
本件では、データ用パーティションの先頭が上書きされてしまっていたので完全な復旧結果とはなりませんでしたが、お客さまには十分ご満足いただける結果となり、無事納品することができました。
今回のようなケースは、ドライブを直接復号する方法を知らなければ、何も復旧できなかったことでしょう。
仕事の種なので、全部書くなんてことはしませんが…（以下は少々技術チックな内容です）
NASのOSとしてLinuxが使用されていますが、Linuxでブロックデバイスの暗号化の定番と言えばdevice-mapperのcryptで、コマンドでいうとcryptsetupがしばしば使われます。
LinuxのいちディストリビューションであるArchLinuxのWikiにはいろいろと書いてあります。
この例の最後にはinitramfsに復号用のキーを埋め込む方法が紹介されていますが、警告部分に ”Use an embedded keyfile only if you have some form of authentication mechanism beforehand that protects the keyfile sufficiently. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.” と書かれています。
復号用のキーファイルが埋め込まれているだけでその鍵自体がなんらかの方法で保護されていないと、勝手に復号されるので暗号化の意味ないよ、という警告です。
しかしながら、NASのデフォルトの機能はネットワーク越しに接続したらファイルにアクセスできるというもので、ネットワーク経由で復号のための認証を行う訳でもなく、ドングルが挿されている訳でもない状態で、起動時に自動で復号される必要があります（そういった方式でも復号できるように設定することは可能ですが、必須という訳ではありません）。先ほどの警告の内容どおりに勝手に復号してくれないと逆に困るのです。
そういう訳でinitramfsの中に復号キーを埋め込んだり、あるいは、暗号化されていない領域に復号キ―を蔵置したりする必要があります。
また、復号キーがどこかにあるだけではダメで、その復号キーを使って復号するための何らかの仕組みが必要です。
それなら、暗号化されていないどこかに復号するためのスクリプトがあったりするのではないかと考えるのは自然な発想ではないでしょうか？
ということで暗号化されていない部分を漁ってみると、本当にそのようなスクリプトが存在して、その内容を見てみると…
「lkdata」というファイルが復号キーとして使用されている様です。
このファイルがどこから来ているのか辿れば、32byte = 256bit の復号キ―を入手することができます。
ちなみに、「lksystem」というのは暗号化されているシステムパーティション用の復号キーです。
NASの起動時に前述のスクリプトのcryptsetup部分が実際にコールされているのかは分かりませんが、復号に関する確度の高い情報であることは間違いないです。
(lksystemの方は、initrd.imgを展開したときに出てくるinitスクリプトによってシステム用パーティションの復号に使用されていることは確認できました。)
実は個人的にArchLinuxを使用していた時期があり、そのときに、
– ブート用パーティションを切ってその中にinitramfsやルートファイルシステムのLUKSヘッダーおよび復号キーを蔵置
– このブート用パーティションを暗号化（LUKSヘッダー付き）
– initramfsに復号処理を担うフック（スクリプト）を埋め込み
– ルートファイルシステムのパーティションも暗号化（LUKSヘッダーレス）
ということをして、GRUBでパスワード入力→ブート用パーティション復号→ブート用パーティション内のinitramfs展開→initramfsに埋め込みのフックがLUKSヘッダーと復号キーを使用してルートファイルシステム復号→ルートファイルシステムをマウント、という動作になるように弄ったりしていました。
どことなく似ている気がします。こういう経験がデータ復旧に活きたのかもしれません。
スクラッチラボでは、LanDisk HDL-TAシリーズのデータ復旧にも対応しております。（重度物理障害扱いとさせて頂いております。）
お困りの際は是非スクラッチラボへご相談ください！！
