Android Kit Kat 4.4 OS には多くの変更が導入されており、OS の全体的な変更を誰でも実行することがますます困難になっています。 SELinux や dm-verity カーネルなどのイニシアチブは、ブートやファイルのストレージの検証に使用されています。

これらは、ファイル レベルで表面化するのを待つのではなく、デバイス内で行われた変更をブロック レベル自体で検出するのにも役立ちます。 dm-verity は基本的に、デバイスのファイル システムの変更を実行するルート ソフトウェアの防止に役立ちます。 検出は非常に早期に行われます。

それは実際にどのように機能しますか？

デバイスの各ブロックにリンクされた SHA-256 ハッシュは、dm-verity で機能します。 ブロックはストレージの単なる物理アドレスであり、ほとんどのフラッシュ デバイスではサイズが 4KB を超えません。 ページ上に形成される多くのハッシュのツリーのうち、ファイル システム全体が信頼されるためには、信頼する必要があるのは「最上位」のハッシュのみです。 いずれかのブロックが変更されると、ハッシュ シーケンスが壊れ、チェーンの向きも失われます。

ブート パーティション内には、OEM が外部で検証することが期待される公開キーもあり、これはブートローダーを通じて、または CPU 機能のいずれかを使用して行われます。 この公開キーは、ファイル システム上の署名の有効性を確認するために使用されます。

検証時間を短縮するために、ブロックはアクセスされたときにのみ検証され、検証プロセスは読み取り操作と並行して実行されます。 これは、ストレージ アクセス時の遅延をなくすために行われます。 システムパーティション内でファイルが変更されるなど、検証に変更があった場合、「読み取りエラー」と呼ばれるエラーが発生します。

どのアプリケーションがデータにアクセスしているかに基づいて、システムは、それがデバイスの健康にあまりにも危険なものでない限り、データの継続を許可します。 同時にシステム上、お申込みをお断りさせていただく可能性もございます。

現在十分な抑止力が整備されている

上記のことから、Android Kit Kat 4.4 を実行しているデバイスの root 化や変更は、以前のように簡単な作業ではなくなっていることがわかります。 Google によるこれらの対策は、毎回 100% 成功するとは限りませんが、十分な抑止力として機能し、OEM は以前のようにカスタム カーネルを許可することが困難になるでしょう。

デバイス カーネル内に変更を加えることができる場合にのみ、この安全保護をバイパスできます。 その後、dm-verity を無効にし、キーを使用して認証を行ったり、システム変更を独自に実行したりできます。 ロックされたブートローダーを備えたキャリア ブランドのデバイスを購入したユーザーは、デバイスがブリックされるのを防ぐために、この警告に注意することをお勧めします。