次のコピー防止機能を簡単に解読できますか?[閉まっている]


11

ARMデバイス(Raspberry Pi)でLinuxカーネルをブートするブート可能なSDカードである作業をコピー保護しようとしています。私はこのアプローチを使用しています:

  1. このアプローチでは、initrdを使用して、暗号化されたルートファイルシステムをマウントします。
  2. initrdは、SDカードのCIDに従ってファイルシステムのパスワードを生成します。(ハッシュ関数が使用され、md5またはsha1についてはまだ決定していません)。Initrdは、生成されたパスワードを使用してファイルシステムをマウントしようとします。
  3. 最も興味深い/疑わしい部分は次のとおりです。initrd自体はカスタムC関数を使用して暗号化され、基本的に各バイトはカスタムメイドの擬似ランダムジェネレーターを使用してXORされます。カーネルは、同じ暗号化機能を持つように修正され、暗号化解除機能として機能します。
  4. システム自体が取り外されているため、キーボードや外部ストレージを使用する方法はありません。単一のアプリがフルスクリーンで実行されます。

そのため、ブートローダーがカーネルとinitrdをロードした後、カーネルはinitrdを復号化し、そのinitスクリプトを実行します。これにより、パスワードが生成され、ルートファイルシステムがマウントされます。

私の質問は、この設定を破る(ルートファイルシステムを解読し、任意のSDカードから起動する)ことはどれほど簡単でしょうか?最も弱い部分は何ですか?カーネルを逆コンパイルして、それらのカスタム暗号化関数を見つけるのはどれくらい簡単ですか?

編集:ここにいくつかの修正がありますので、明らかなことで時間を無駄にしないでください:

  1. ルートデバイスはLUKS(aes256)で暗号化され、キーはSDカードのCIDとソルトを使用するHMAC機能によって生成されます。
  2. initramfs暗号化の擬似ランダムアルゴリズムは、実際にはRC4になります。カスタム関数を使用してキーのみが生成されます。しかし、他の方法はないようです)。
  3. SDカードエミュレーターを使用すると、誰かがこのシステムのコピーを作成できることを理解していますが、これは非常に難しく、誰もこれを行うことができないためです(また、誰もエミュレーターに対処したくないでしょう)

カーネルとinitrdはどこに保存されていますか?
user1686

すべて1枚のSDカードに保存されます。両方とも別々のファイルにあります。通常どおり/ bootに保存されます。
dimovnike

回答:


7

(ルートファイルシステムを復号化し、SDカードからブートするように)このセットアップを破るのはどれくらい簡単でしょうか?

セットアップを「破る」ことの難しさは、ファイルシステム自体の署名/暗号化に使用する方法のエントロピーのビット数に依存します(これにより、ブルートフォースに使用できる一意の組み合わせの合計数が決まります)パスワード)。

最も弱い部分は何ですか?

疑いもなく、事前定義されたCIDをパスワードとして使用するとともに、カスタムの擬似乱数生成機能を使用します。

SDカードのCIDは読み取り専用であると想定されていますが、この日と時代に非準拠のフラッシュメモリデバイスを見つけることは珍しくありません。 一部の人々は、特定のSDカードでCID を上書きする能力さえ実証しています。これにより、パスワードのブルートフォースが容易になります。特に、自分のクローンを作成した後にSDカードをエミュレートしている場合(これは他に検討したいことです)。

最後に、あらゆる種類の疑似乱数ジェネレーターを使用すると、それがランダムではないという理由から、いくつかの固有の欠陥が既にあります。これは、疑似乱数と呼ばれる理由があります。事前に作成された暗号化されたブートローダー(どちらもRaspberry Piで動作するTrueCryptやLUKSなど)を使用し、手動でカーネルを変更する必要はありません。

カーネルを逆コンパイルして、それらのカスタム暗号化関数を見つけるのはどれくらい簡単ですか?

何も逆コンパイルすることは非常に困難です。逆に、コンパイルされたアプリケーションの逆アセンブリは簡単な場合が多く、リバースエンジニアリングアセンブリを別の高レベル言語に戻すのを支援するために使用できる多くのツールがあります。攻撃者がコンパイルされたカーネルにさえアクセスできる場合、コードが意図的に難読化されていない限り、疑似乱数ジェネレーターのようなものを分析することはおそらく簡単です。


TL、DR:暗号化とセキュリティに関しては、車輪を再発明しないで、試行錯誤を繰り返してください。既に利用可能ないくつかのフルディスク暗号化オプションがあり、Raspberry Piで正常に機能することが実証されています。SDカードのCIDを一種の「パスワード」として使用することは避けます-変更できない場合でも、この値を偽装する方法があります。

コピー保護は、CPRMとしてSDカードの仕様にすでに含まれています。


答えてくれてありがとう。私はCPRMについて知っていますが、その仕様はNDAで閉じられており、(私がグーグルで調べたものから)多額の費用がかかります。LUKSとTruecryptに関しては、これらはブート時に手動で入力されたキーを必要とします。TrueCryptブートローダーを変更して、hmac関数を使用してCIDからキーを生成する場合、これよりも優れているでしょうか?また、SDカードエミュレーターで実行できることも理解していますが、それは私にとっては問題ありません。これは、海賊にとっての難易度の便利なグレードです。(キーは、デバイスに自己完結されるように私はここに理解していれば何も100%の保護はありません)
dimovnike

@ user2021201それは確かに私があなたを導こうとしていたものでした。おそらく、ソースからTruecryptブートローダーを変更するのはかなり簡単でしょが、ブートローダーからCIDを取得するのがどれほど難しいかはわかりません(SDカードの仕様を照会するためのオペレーティングシステムがロードされていないためです) )。ただし、管理できた場合は、おそらくニーズに合った十分なソリューションになります。
ブレークスルー

1

熟練した人なら、これをクラックするのに苦労することはないでしょう。エミュレータでSDカードをブートし、RAMからキーを読み取るのは比較的簡単です。その後、コピー保護なしのバージョンをPirate Bay(など)に投稿します。

または、エミュレータを使用して、実行中のエミュレートされたシステムにシェルコードを注入します。次に、実行中のシステムを使用して、復号化されたrootfsをコピーします(またはdmsetup table --showkeysなどを使用してキーを読み取ります)。

クイック検索でRaspberry Piエミュレーターの存在が判明したため、作業の一部は既に完了しています。

別の問題、特にこれがあります:

カーネルは、同じ暗号化機能を持つように修正され、暗号化解除機能として機能します。

これを配布する人は誰でも、GPLの条件の下でカーネルソースコードを入手する権利があります。そのため、逆アセンブルする必要はなく、単にdiff追加の関数を見つけるために使用できます。

(たとえば、チェックカーネルとストックカーネルのように、分解によって見つけるのはそれほど難しいことではありません)

私はRaspberry Piのブートコードに完全には精通していませんが、組み込みの暗号キーでブートローダーを再フラッシュできれば(それはカーネルに渡されます)、少なくともSDカードにはないので、 dエミュレータで起動する試みを阻止します。


はい、ライセンスの問題を認識しています。カーネルをそのままにして、FreeBSDカーネルに切り替える方法を探していますが、現時点では技術的な問題のみを議論します。ブートローダーのアイデアは非常に興味深いものですが、これを実装する方法を見つけることができませんでした。明らかにそのような方法はありません。
dimovnike
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.