dm-verity の概要を説明します。 私の限られた知識によると、関連するものはAndroidで動作します。デバイスや ROM によって状況が異なる場合があります。
DM-VERITY はどのように適用されますか?
dm-verity (検証済みのブートと AVB) および dm-crypt (FDE) は device-mapper のターゲットです Linux カーネルの機能。 dm-verity ブロックデバイスから読み取られる各ブロックの整合性を検証します。 init_first_stage により施行 fs_mgr_flags のとおり fstab で設定します。 system-as-root デバイス (A/B と non-A/B )、/system のマウント中に verity を強制するようにカーネルにパッチが適用されます および /vendor verify の場合 /avb フラグは fstab デバイス ツリー (dtb) にあります。
dm-crypt ブロックデバイスから/への読み取り/書き込み時にデータを透過的に復号化/暗号化します。 FBE は別のカーネル フレームワーク fscrypt に基づいています;しかし、どちらも vold によって管理されています (ネイティブ サービスとして実行) if fs_mgr_flags voldmanaged を含む .
FSTAB はどこにありますか?
fstab は伝統的に、起動時にマウントされるファイルシステムを指定するための Linux 上のファイルでした。 fs_mgr のコア コンポーネントです。 Android の機能。
Pre Oreo リリース fstab ramdisk にありました . Treble では /vendor に移動しました (または /system/vendor ) system の fstab エントリ と vendor (そして odm ) はデバイス ツリー Blob (dtb) に移動されます ）。カーネルは dtb fstab をエクスポートします /proc/device-tree/firmware/android のデバイス ツリー ディレクトリのエントリ .
一部の OEM は fstab も入れています odm で または nvdata
ソース: Android ストレージ デバイスの構成
DTB はどこにありますか?
デバイス ツリーは、カーネルが検出できないハードウェアを記述するためのデータ構造です。デバイス ツリー ソース (dts ) dtb に変換できます (DT のバイナリ blob) と dtc を使用してその逆 . DTB は、ブート時にブートローダーによって読み込まれ、カーネルに渡されます。これにより、ハードウェアが検出され、それに応じてデバイス ノードが作成されます。
DTB は次のいずれかです:
- カーネル
zImageに追加 またはImage.gzboot.imgで .gzipから分割できますsplit-appended-dtb (sadtb)を使用してアーカイブする . -
または
dtboで 一部の OEM と同じようにパーティション分割します。これは以下で確認できます:~# ls -l /dev/block/bootdevice/by-name/dtbo* ~# grep -C5 PARTNAME=dtbo /sys/dev/block/*/uevent | grep DEVNAME | sed 's/.*=//; s|^|/dev/block/&|' - または
boot.imgの末尾 第 2 段階の後、またはodmで パーティション (まれですが、一部の OEM ではそうです)。
また、デバイスが non-A/B の場合 、 dtb (boot.img より) および/または dtbo partition) も recovery.img に追加されます ヘッダー、カーネル、RAM ディスク、および第 2 段階の後の DTBO セクション。ただし、これは通常の起動には関係ありません。ただし、デバイスも system-as-root の場合 、Magisk を boot.img としてこのリカバリ パーティションにインストールする必要があります ramdisk を含まない .
DTB がカーネルに追加されていない場合、dtb(s) dtb.img に変換されます mkdtimg を使用 .同じツールで画像をダンプできます。
ソース: DTO の実装
DM-VERITY を無効にする方法
userdebug で ROM、dm-verity adb を使用して無効にすることができます .ブロックデバイス上の最後のファイルシステムブロックの後に書き込まれる verity メタデータブロックのマジックナンバー (system) を変更します。 または vendor ）。ここから引用：
このマジック ナンバーがないと、検証プロセスが停止します
AVBの場合、adb vbmeta header を変更します ハッシュツリー イメージの検証を無効にします。ここから引用：
AVB_VBMETA_IMAGE_FLAGS_HASHTREE_DISABLED の場合 最上位の vbmeta でフラグが設定されている場合、androidboot.veritymode 無効に設定されています
user で ro.debuggable をビルドします 0 です と adbd ルートとして実行されていません。 ALLOW_ADBD_DISABLE_VERITY のような他の違いもあります 、だから adb dm-verity を無効にしません .他のアプローチは verify を削除することです または avb fstab からのフラグ .ここから引用：
パーティションを確認するには...
...
関連するエントリの fstab で、verify を追加します。 fs_mgr に
同様に暗号化を解除するには forceencrypt= 、 forcefdeorfbe= または fileencryption= encryptable= に置き換える必要があります .ただし、暗号化は出荷時設定にリセットしないと削除できないため (FBE も?)、Preserve force encryption のチェックを外します。 Magis アプリでは何もしません。
一部の OEM は support_scfs も使用しています fs_mgr フラグと ro.config.dmverity=true dm-verity を持つデバイスのプロパティ
dm-verity を無効にするために使用できる、一部の OEM のブートローダーおよび adb 実装で発見されたエクスプロイトもいくつかあります。 影響を受けるデバイスで。ただし、このようなセキュリティ上の欠陥は通常、OEM からの更新によって時間の経過とともに修正されます。
オプション 1
Magisk をインストールする前に、構成ファイルでオプションを設定します。
~# echo 'KEEPVERITY=false' >/cache/.magisk
~# echo 'KEEPFORCEENCRYPT=true' >>/cache/.magisk
インストールされている場合、Preserve AVB v2.0/dm-verity のチェックを外した後 アプリでは、Magisk を再インストールする必要があります。ここから引用：
Magisk Manager で、「Uninstall> Restore Images」でイメージを復元し、Advanced Settings で「Preserve AVB 2.0/dm-verity」ボックスをオンにしてから、アプリ経由で Magisk を再インストールします。
オプション 2
いくつかの dm-verity を使用してください 無効化はこのように圧縮されます。
オプション 3
fstab の場所を特定します /system のエントリ と /vendor
ramdisk の場合 (プレトレブル):
ramdiskを抽出 、fstabを変更します そして再梱包。-
または
ramdiskにパッチを当てる 直接:~# magiskboot cpio ramdisk.cpio 'patch false true'
dtb の場合 :
- カーネルに追加する場合:
boot.imgを抽出- 追加された
dtb(s)を分割 - パッチ
dtb(s). dtb(s)を追加 カーネルへ- リパック
boot.img
dtboの場合 パーティションまたはboot.img第 2 段階の後、dtb.imgにパッチを当てます パーティションまたはboot.imgに書き戻します .
ブートまたはリカバリ イメージと RAM ディスクを解凍/再パックする方法
AIK または magiskboot を使用 .
dtb にパッチを当てる方法 ?
magiskboot を使用して直接パッチを当てる または手動で dtb を変換します dts へ 、編集 dts dm-verity を削除する任意のテキスト エディターで フラグ、および変換 dts dtb に戻る .
関連:
- Magisk の仕組み
- Android デバイスのパーティションとファイル システム