Secure Folder will fail to create with FBE (Android 11 and lower) #26
Comments
|
I've decided to analyze the keymaster TA to get a better look at how this check works and how is it triggered. I'm also comparing the different keymaster TA iterations from the various OS of my device to see if anything relevant can be seen. The following TA blobs were checked:
Searching for "tz_check_trust_boot_status" is enough for it to show up. It is referenced in two functions:
Surprisingly this check has been completely removed in the Android 13 TA, so we basically can ignore it.
The function itself is pretty easy to understand: it will retrieve the warranty bit and trustboot status using
Seems like the check is in place only if the current key params contains a specific tag with value "0x700007d0". A rapid search in system frameworks shows a result in the KeymasterDefs class: |
|
The following hook should completely avoid triggering loadSystem(object : YukiBaseHooker() {
private val KM_TAG_KNOX_OBJECT_PROTECTION_REQUIRED = 1879050192
override fun onHook() {
findClass("android.security.keymaster.KeymasterArguments").hook {
injectMember {
method {
name = "addBoolean"
param(IntType)
}
beforeHook {
val tag: Int = args(0).int()
if (tag == KM_TAG_KNOX_OBJECT_PROTECTION_REQUIRED) {
resultNull()
}
}
}
}
}
})However, it still won't work since the tag is added anyway. By looking again in the logs, we can see vold prints some interesting debug info: Things become more clear once we check what's happening under the hood:
Looks like vold manually adds the KNOX_OBJECT_PROTECTION_REQUIRED tag if |
|
I decided to test if patching vold to ensure the KNOX_OBJECT_PROTECTION tag doesn't gets passed to the key params does fix the key generation. Since I'm unable to test on my Galaxy A52s 5G (I can't downgrade to Android 11 due to an higher RP rev value), I'm gonna use a Galaxy A71 with firmware build A715FXXU8BVA2. Using Binja I'm able to find the check in place here as well:
Let's patch vold to NOP the call to the
Surprisingly enough, Secure Folder works normally:
|
Sorry this is a noob question - I could see you NOP the call to sub_6fe84 with E7170094 -> 1F2003D5, but may I ask what was the reasoning behind NOP-ing the cbz x0 instruction at 0x69f00? (400000B4 -> 1F2003D5) |
I've used Binja to automatically patch the binary, I'm not an expert in assembly/pseudocode unfortunately |
|
Ah - thank you! Sorry this has come across as a really stupid question but may I ask - if it might be possible - to patch the binary using the free/web version of binary ninja? I think if it's just a NOP patch to the bl instruction we might be able to automate it inside a shell script within a recovery zip. |
Binary Ninja is a paid software and iirc there's no free/web version of it. Another disassembler like Ghidra should work the same if it supports aarch64 binaries.
That's the idea, but the issue is I haven't been able to find a common patch that works for all the devices. Maybe the vold/libepm inside the Enhancer works as well with FBE enabled? I could modify the Enhancer zip to extract those fix files when flashing in recovery mode. |
The patch for this vold binary is (offset 0x000718F0):
|
|
Sorry just realised I had mixed up the vold files I got from #23 and the stock ones, but good news! I loaded the new vold binary from stock G9700ZCU4DTL2/Android 10 and something similar was present. And after replacing this patched vold binary in /system/bin/vold in TWRP, secure folder now works correctly on S10 (Android 10) with FBE enabled. No changes were needed for the library files (libepm.so). Thank you!! @blackmesa123 |
So we do now know patching vold is the way to fix Secure Folder on A10/11 FBE-enabled devices. My plan is to integrate this fix either in a separate zip or even better on the Enhancer zip, but since Magisk modules aren't able to replace vold due to the nature of the system service, the fix has to be implemented via a recovery flash:
Again, the main issue is that I haven't figured out yet a patch that works with all the possible vold binaries for both Android 10/11, probably adding multiple hex patches in the script and apply only the one that matches the bin running in the device, patching the function related to adding tags in the key arguments might not be the best idea since it either requires diff patches for each vold bin or might break stuff since I saw it's also used elsewhere in vold. |
|
@KikMyaz could you test if this alternative hex patch works (by starting from scratch)? From |
|
If you confirm it works, there are two way to hex patch the vold bin:
# Android 10
magiskboot hexpatch "$SYSTEM_DIR/bin/vold" 7A0F0094 1F2003D5
# Android 11
magiskboot hexpatch "$SYSTEM_DIR/bin/vold" E7170094 1F2003D5
# Android 10
magiskboot hexpatch "$SYSTEM_DIR/bin/vold" 09FA80520900AE72 090080520900AE72
# Android 11
magiskboot hexpatch "$SYSTEM_DIR/bin/vold" 08FA805200E4006F 0800805200E4006FThe first one is the best imho, but we need to confirm it works for all the devices. |
|
The patch that modifies the tag looks our best bet compared to the branch one (assuming it works), comparing a few vold binaries I was able to find four hexpatches that should make the script work for all the support Android 10/11 devices: if grep -q 'Knox protection required' $SYSTEM_DIR/bin/vold; then
magiskboot hexpatch "$SYSTEM_DIR/bin/vold" 00E4006FEA861A11 00E4006FEABE0451
magiskboot hexpatch "$SYSTEM_DIR/bin/vold" 08FA805200E4006F 0800805200E4006F
magiskboot hexpatch "$SYSTEM_DIR/bin/vold" 08FA80520800AE72 080080520800AE72
magiskboot hexpatch "$SYSTEM_DIR/bin/vold" 09FA80520900AE72 090080520900AE72
fiEDIT: I've tested this new set of patches and they seem to work great on my A71. |
Okay... to test this I kinda wanted to back up the entire device before I flash anything :/ Now this is a little tricky since FBE is in effect and I still want to keep my data (and those in secure folder too). I have twrp but it cannot decrypt /data so I'm not entirely sure how to get that partition backed up... and even if I do a raw image of that partition I don't know which partitions have the keys (presumably I also need to restore the partitions that store the keys later on? also idk but last time when I restored a raw unencrypted userdata.img it somehow broke lockscreen passcode and I had to rebuild that database) Do you know any way of backing up the entire device/internal EMMC to the effect of QPST/EDL but not using EDL? Or any way to back up an FBE device with secure folder data? |
Also I am not sure "7A0F0094" is correct here. I got the vold files mixed up but basically for S10 on Android 10 the instruction I needed to NOP in the end was "71EEFF97" instead of "7A0F0094" (which I don't think was present in my stock vold binary). |
Got them from #26 (comment), but at this point the best way to patch vold is with the new hex patches I posted previously at #26 (comment). |
I don't know if backing up the raw userdata partition works out of the box, since by restoring it you'd need the encryption keys to be validated by keymaster, you'd also need to backup the metadata partition for the metadata keys. Your best bet is to use a recovery that has support for decryption, which isn't really hard to implement (here's how I did implement it in my device: Mesa-Labs-Archive/android_device_samsung_a52sxq@3b391f5) |
|
I managed to implement a "recovery-mode" flashing in the Enhancer script, issue is it will fail to flash on recoveries without crypto support as it requires Magisk specific files in https://github.com/BlackMesa123/KnoxPatch/actions/runs/5754241674 |
Yeah that was my fault 😬 I'm sorry I got the files mixed up - this vold.zip was the correct (and patched) vold binary from that firmware. I don't have the stock one handy at the moment but it's basically a matter of flipping the NOP, 1F2003D5 @ address 0x75dcc back to 71EEFF97. |
I decided to use the tag hex patch rather than NOP the call to the branch as I saw it's very difficult to patch that out as the address/patch changes from bin to bin. The tag patch worked fine on my A71 and I've identified only four different patches comparing various Android 10/11 vold binaries. |
|
Closing this issue since the fix has been added in Enhancer v0.4. An alternative version of the Enhancer zip is also now available for custom recoveries without crypto support. |
Deprecated since Android 12, when provided with this tag the KeyMaster TA will check for the current trustboot/warranty bit status and refuse any operation if one of these isn't valid (salvogiangri/KnoxPatch#26 (comment)). Due to leftover code, we can apply this tag to bypass the KM_TAG_EXPORTABLE check in the TA. Note that EC and RSA generated keys aren't supported. Signed-off-by: BlackMesa123 <[email protected]>
Secure Folder bases part of its implementation over the AOSP multi user API's. For this reason, devices with FBE in place will require a user key generated by the keymaster TA, more info here (qualcomm.com) and here (docs.samsungknox.com).
Devices with a legacy One UI version (One UI 3.x, and also 2.x as saw in #23) will refuse to generate the required user key due to additional device integrity checks implemented directly in the SKeyMaster TA.
We can ensure this is the case by following the entire creation process via system logs. The following logs were captured on a Galaxy A52s 5G running its latest Android 11 based firmware (A528BXXS1AUL3).
First off, the Secure Folder app triggers the container creation:
UserManagerService.checkIntegrity()is called to verify whether or not the device can generate a SAK via keymaster, this check is already hooked in the module via KnoxDARHooks. Nothing wrong happens if this is patched:UserManagerService.checkDRK()is called:Once both checks passes, UserManagerService will begin to generate the user key:
Vold will now call keymaster to handle the key generation:
Keymaster TA starts to generate the key, but it will fail on purpose due to the device having a blown warranty bit and non-trusted boot status (custom binary installed):
...it's a disaster:
The system will reports back the container creation failed:
The text was updated successfully, but these errors were encountered: