Note 9 S Richtiges Recovery (FBEv1 oder v2) für Arrow-v13.0-miatoll-OFFICIAL-20230108-VANILLA.zip

[linuxnutzer]

Ich würde gerne auf einem Redmi Note 9S (Curtana), zur Zeit Havoc mit Android 11 bzw. einem 9Pro (Joyeuse), zur Zeit ArrowOS mit Android 12 ein Android 13 installieren:

Arrow-v13.0-miatoll-OFFICIAL-20230108-VANILLA.zip

Daten brauchen keine erhalten bleiben, alles wird gelöscht werden.

Liest man bei Xiaomi Redmi Note 9S/Pro/Pro Max / POCO M2 Pro (miatoll) build releases | OrangeFox Recovery Downloads dann findet man bei Xiaomi Redmi Note 9S/Pro/Pro Max / POCO M2 Pro (miatoll) build releases | OrangeFox Recovery Downloads zB

* This is an FBEv1 Android 12 (and higher) release. Do NOT use with Android 11 or earlier. Do NOT use with FBEv2 ROMs (there is a separate release for FBEv2).
* Make a FULL backup of your data and internal storage BEFORE flashing.
* After restoring backups that include encrypted data, and booting to Android, you should reboot the ROM once or twice, using the power button.
* Report any problem in the "OrangeFox Recovery Support" chat on Telegram. You should make a FULL report, and you MUST include the recovery log.

Wie soll ich denn herausfinden, was Arrow-v13.0-miatoll-OFFICIAL-20230108-VANILLA für ein ROM ist? FBEv1 oder FBEv2

FBEv1 or FBEv2 ?

Version 2 encryption policies use a more secure and flexible key derivation function. The default is v2 if the device launched on Android 11 or higher (as determined by ro.product.first_api_level), or v1 if the device launched on Android 10 or lower.

Die genannten Miatoll-Handys erschienen mit Android 10, nur ist das wirklich eine Hardware-Sache bei der Verschlüsselung oder bezieht sich das auf die FBE-Version beim Erscheinen?

Es gibt da auch noch [RECOVERY][UNOFFICIAL][TWRP-3.7 Android 11,12.x,13,MIUI] TWRP for MIATOLL devices [17/10/2022] also TWRP 3.7 womit sich auch die Frage stellt, welches FBE man flasht?

TWRP wäre mir lieber, aber eigentlich ist es egal welches Recovery ich verwende. Manche ROMS wie zB Awaken bestehen auf TWRP.

 

[chrs267]

@linuxnutzer Das hier ist von Google und wann genau v1 oder v2 genutzt wird:

The flags parameter, new in Android 11, is a list of flags separated by the + character. The following flags are supported:

• The v1 flag selects version 1 encryption policies; the v2 flag selects version 2 encryption policies. Version 2 encryption policies use a more secure and flexible key derivation function. The default is v2 if the device launched on Android 11 or higher (as determined by ro.product.first_api_level), or v1 if the device launched on Android 10 or lower.

v2 = Android 11,12 und 13
v1 = bis einschließlich A10

Hast du eine ROM mit A11,12 oder 13, brauchst du v2.

Es muss sich nach der zu installierenden ROM richten, denn sonst gäbe es pro Modell nicht unterschiedliche Ausführungen als v1 und v2. Wäre es abhängig von der Android Version, die als Stock ROM mit dem Gerät ausgeliefert wurde, gäbe es ja nur eine passende Option.

 

[linuxnutzer]

Es muss sich nach der zu installierenden ROM richten, denn sonst gäbe es pro Modell nicht unterschiedliche Ausführungen

ok, das ist mal ein Argument, denn das Recovery ist ja Modell spezifisch, aber ...

Vorerst mal diese Abfragen unter Android 12 beim Joyeuse:

$ sudo adb shell
joyeuse:/ $ getprop | grep api_level                                      
[ro.product.first_api_level]: [29]

Codenames, Tags, and Build Numbers | Android Open Source Project

Android10

10

API-Level 29

127|joyeuse:/ $ getprop | grep encryption                                
[ro.crypto.uses_fs_ioc_add_encryption_key]: [true]

Das Handy hatte also anfangs Android 10, was zu erwarten war.

File-Based Encryption | Android Open Source Project

Hier lese ich raus, dass die Verschlüsselungsmöglichkeiten auch von der Hardware abhängig sind. Somit gibt es da schon eine Einschränkung, wenn auf sehr alten Handys ein Android 12 installiert wird. Mein RN5 Pro Whyred läuft zB unter Android 12, Awaken war problemlos zu installieren, geflasht wurde das Whyred mit Orange.

Ich kann mir daher vorstellen, dass man bei sehr alten Handys mit v2 Probleme bekommt. Mein Whyred (rollback protection) habe ich naiverweise mit Android 12 mit einem sehr alten Recovery geflasht.

Vgl. dazu auch Hardware-Wrapped Keys | Android Open Source Project

atest vts_kernel_encryption_test

oder

vts-tradefed run vts -m vts_kernel_encryption_test

läuft bei mir in der adb-shell nicht. Aber vielleicht mache ich was falsch.

/system/bin/sh: atest: inaccessible or not found
/system/bin/sh: vts-tradefed: inaccessible or not found

Meine Frage ist daher, hat das jemand in der Praxis mit einem RN9 miatoll ausprobiert? Ich habe keine Lust auf einen Brick. Welches Recovery also genau? Eingangs habe ich ja die genauen Bedingungen geschildert. Sorry, wenn ich nachhake.

Ist beim Recovery ein Unterschied ob man Android 13 von 11 aus flasht oder von 12?

 

[linuxnutzer]

Vielleicht verstehe ich das falsch:

File-Based Encryption | Android Open Source Project

Das v1 Flag wählt Verschlüsselungsrichtlinien der Version 1 aus; Das v2 Flag wählt Verschlüsselungsrichtlinien der Version 2 aus. Verschlüsselungsrichtlinien der Version 2 verwenden eine sicherere und flexiblere Schlüsselableitungsfunktion . Der Standardwert ist v2, wenn das Gerät auf Android 11 oder höher gestartet wurde (wie durch ro.product.first_api_level bestimmt), oder v1, wenn das Gerät auf Android 10 oder niedriger gestartet wurde.

Wenn ich den Artikel richtig verstehe geht es da um Kernel kompilieren und meine Frage bezieht sich auf das Flashen mit einem Recovery. Somit geht es da darum, was der Kernel unterstützt und nicht um das zu installierende Recovery. Wird mit v2 der Kernel erstellt, dann kann eine bessere Verschlüsselung genutzt werden, muss aber nicht?

Gefühlsmäßig ist es natürlich plaubsibel, dass man FBEv2 beim Flashen eines Android 12 oder 13 ROMs verwendet. Ich frage mich einfach, warum mein Whyred unter A12 sehr gut funktioniert als ich mit einem Recovery flashte, als noch niemand von v2 sprach. So wie ich es verstehe sind die alten Recoverys von der Logik alle v1, gab ja noch kein V2. Vielleicht sind die A12-ROMs einfach abwärtskompatibel, wenn eine file based encryption nicht in vollem Umfang möglich ist. Andererseits warum wird dann gewarnt, v1 und v2 nicht zu vertauschen.

Beiträge automatisch zusammengeführt: 09.01.2023

Ich schau mir jetzt das Whyred nochmal genauer an.

Installiert:

orangefox-whyred-stable_r11.1.zip
awaken-2.9-aero-whyred-official-vanilla-1209-20220714.zip

Scheint noch immer kein neueres OF für Whyred zu geben: Xiaomi Redmi Note 5 / 5 Pro (whyred) build releases | OrangeFox Recovery Downloads

Also nichts bzgl. FBEv2, eigentlich bräuchte ich das doch für Android 12, oder ist das ein Gedankenfehler?

In den Change Logs:

New Maintainer (@Sushrut1101)
Upgrade to R11.1 - See OrangeFox changelogs
Added Support for MIUI 12.x Android 11 Decryption
Updated the Magisk Addon to v21.4
Run OrangeFox on the Full Maximum Possible (2160x1080) Screen Resolution
Added More Partitions for Backup/Restore
Disabled the App Manager if the Installed ROM is based on Android 11 or Higher

Also ich lese da nichts bzgl. Android 12 Kompatibilität.

whyred:/ $ getprop | grep api_level
[ro.product.first_api_level]: [26]

Ausgeliefert wurde also mit Android 8.0

whyred:/ $ getprop | grep encryption
1|whyred:/ $

Da kommt also nichts zu encryption, woher die 1 kommt, keine Ahnung,

Versionsangaben:

1|whyred:/ $ getprop | grep version                                         
[build.version.extensions.r]: [1]
[build.version.extensions.s]: [1]
[gsm.version.baseband]: [660_GEN_PACK-1.209285.1.210383.1,660_GEN_PACK-1.209285.1.210383.1]
[gsm.version.ril-impl]: [Qualcomm RIL 1.0]
[ro.awaken.base.version]: [2.9]
[ro.awaken.build.version]: [2.9-Aero]
[ro.awaken.display.version]: [2.9-Aero-whyred-OFFICIAL-Vanilla-1209-20220714]
[ro.awaken.version]: [2.9-Aero-whyred-OFFICIAL-Vanilla-1209-20220714]
[ro.boot.hwversion]: [1.20.0]
[ro.bootimage.build.version.incremental]: [1657800563]
[ro.bootimage.build.version.release]: [12]
[ro.bootimage.build.version.release_or_codename]: [12]
[ro.bootimage.build.version.sdk]: [32]
[ro.build.version.all_codenames]: [REL]
[ro.build.version.base_os]: []
[ro.build.version.codename]: [REL]
[ro.build.version.incremental]: [1657800563]
[ro.build.version.min_supported_target_sdk]: [23]
[ro.build.version.preview_sdk]: [0]
[ro.build.version.preview_sdk_fingerprint]: [REL]
[ro.build.version.release]: [12]
[ro.build.version.release_or_codename]: [12]
[ro.build.version.sdk]: [32]
[ro.build.version.security_patch]: [2022-07-05]
[ro.kernel.version]: [4.4]
[ro.modversion]: [2.9-Aero-whyred-OFFICIAL-Vanilla-1209-20220714]
[ro.odm.build.version.incremental]: [1657800563]
[ro.opengles.version]: [196610]
[ro.property_service.version]: [2]
[ro.system.build.version.incremental]: [1657800563]
[ro.system.build.version.release]: [12]
[ro.system.build.version.release_or_codename]: [12]
[ro.system.build.version.sdk]: [32]
[ro.system_ext.build.version.incremental]: [1657800563]
[ro.system_ext.build.version.release]: [12]
[ro.system_ext.build.version.release_or_codename]: [12]
[ro.system_ext.build.version.sdk]: [32]
[ro.vendor.build.version.incremental]: [1657800563]
[ro.vendor.build.version.release]: [12]
[ro.vendor.build.version.release_or_codename]: [12]
[ro.vendor.build.version.sdk]: [32]
[ro.vendor_dlkm.build.version.incremental]: [1657800563]
[ro.vendor_dlkm.build.version.release]: [12]
[ro.vendor_dlkm.build.version.release_or_codename]: [12]
[ro.vendor_dlkm.build.version.sdk]: [32]
[ro.vndk.version]: [32]
whyred:/ $

Vielleicht einfach die Ausnahme von der Regel, dass das Whyred gut mit A12 funktioniert? BTW mit ArrowOS und A12 hatte das Whyred deutliche Probleme.

 

[chrs267]

läuft bei mir in der adb-shell nicht. Aber vielleicht mache ich was falsch.

Ja, du kompilierst damit u.a. deinen Kernel. Das ist Java und kein Shell-Befehl. Das sind Funktionen aus dem Sourecode (AOSP). Guckst du hier.

Du machst hier gerade aus einer Mücke einen Elefanten!

Android 11, 12 und 13 => v2
Android bis einschl. 10 => v1
​

Ich habe keine Lust auf einen Brick

Was soll denn einen Brick verursachen?? Es geht um die Verschlüsselung von /data.

Wenn ich den Artikel richtig verstehe geht es da um Kernel kompilieren und meine Frage bezieht sich auf das Flashen mit einem Recovery.

Du wirst doch sicherlich den Begriff "fstab" (filesystem table) kennen? Für die Partition /data werden dort die Rahmenbedingungen festgesetzt. Neue Option seit A11 ist, dort in der fstab den Wert v1 oder v2 einzutragen. Das war es.

Somit geht es da darum, was der Kernel unterstützt und nicht um das zu installierende Recovery.

Oje, da muss aber jemand noch vieles lernen... recovery.img = boot.img
Der Aufbau ist 1:1 gleich, nur nicht der Inhalt. Also haben beide einen eigenen Kernel.

Im Kernel muss als Konfiguration FSCRYPT_CONTEXT={1,2} eingetragen sein.

Andererseits warum wird dann gewarnt, v1 und v2 nicht zu vertauschen.

Keine Ahnung, warum plötzlich alle aus dem Häusschen sind deswegen. A11 ist 2,5 Jahre alt und bisher hat es keine Sau interessiert. Höre es heute auch zum ersten Mal.

Beiträge automatisch zusammengeführt: 09.01.2023

Da kommt also nichts zu encryption, woher die 1 kommt, keine Ahnung,

Tja, woher kommt wohl die 1? Vielleicht von...
Meaning of exit status 1 returned by linux command

Vielleicht einfach die Ausnahme von der Regel?

Lass uns das Ganze doch einfach mal zeitlich betrachten:
Du hast eine ROM mit API-Level 26 (Android 8). Release Date von Android 8 (26) war 21. August 2017, also vor knapp 6 Jahren. Hättest du damals den Devs bei Xiaomi was von Encryption Policy v2 erzählt, hätten die erst mal Fieber bei dir gemessen. Man hätte es nachholen können im Zuge der vielen OTA-Updates, aber das ist leider nicht möglich. Warum das so ist, steht in deinen Links bzgl. Encryption.

Beiträge automatisch zusammengeführt: 09.01.2023

v1 => Master Key 128-bit
v2 => Master Key 512-bit

Der Master Key ist, wie der Name sagt, der Hauptschlüssel, mit dem sich alle weiteren Keys (FBE Encryption = Dateiverschlüsselung => Vielzahl an Keys) bestimmen lassen. Dieser Master Key wird selber auch verschlüsselt gespeichert. Bisher mit 128-bit und jetzt mit 512-bit + neuer Methodik. Hinzu kommt, dass er nach wie vor mit der genutzten Displaysperre ein weiteres Mal verschlüsselt wird.
Folglich wird die Verwendung der falschen Recovery dazu führen, dass deine Daten nicht entschlüsselt werden können. Drama, Drama, Drama!! Flasht man halt die andere Version.

Mehr gibt es nicht dazu zu sagen! ​

Beiträge automatisch zusammengeführt: 09.01.2023

[v8,13/20] fscrypt: v2 encryption policy support - Patchwork

 

[linuxnutzer]

Ok. ich akzeptiere das mal so. Mit dem OF-Recovery hat das ROM nach 10 Minuten noch immer das animierte Boot-Logo gezeigt, aber letztlich konnte ich ein Android 13 zum Laufen bekommen, bin aber nicht glücklich damit. Vermutlich ist das kein v2-Problem. Mit TWRP war es mit Tricks zu schaffen.

 

[TheMissingLink]

Moin..zur Info
weitere Diskussionen zu Android 13 auf dem Note 9 Pro bitte im von @linuxnutzer eröffneten Thread hier Note 9 Pro - ArrowOS Android 13 läuft nicht sauber auf dem Note 9 Pro

 

[linuxnutzer]

Hier IMHO besser passend, ein Info fürs Archiv. Ich habe mittlerweile auch ein 9S Curtana geflasht. Es scheint so, dass das Problem das OF-Recovery ist. mit TWRP hatte ich keine Probleme, zumindest was das Flashen des Recoveries betrifft. Beide Male wurde ein zip-Recovery mit OF geflasht, also ohne USB-Kabel bzw. fastboot.