Support active cameras after BL

[309040521]

Can you please add support for the Samsung device's active cameras functionality after BootLoader?
I greatly appreciate it. I can assist with testing and provide logs.

My device model: Samsung Z Fold3 5G
ROM:
AP_F9260ZCU4GWH5_F9260ZCU4GWH5_MQB69290723_REV00_user_low_ship_MULTI_CERT_meta_OS13.tar
CSC_CHC_F9260CHC4GWH5_MQB69290723_REV00_user_low_ship_MULTI_CERT.tar

可否增加支持Zfold设备BootLoader之后可正常打开摄像头的功能,非常感谢,我可以协助测试及日志提供.

[salvogiangri]

Please send your /vendor/lib64/hw/camera.qcom.so lib so I can check it out.

[309040521]

Thank you very much for your response. Please use the following link to download this file. Thanks again!
https://www.mediafire.com/file/jibpjjwbfpsuyej/camera.qcom.so/file

[309040521]

I can provide remote access for you to investigate.if you don't mind

[309040521]

If there's anything else you need to know, please let me know. I'm more than willing to provide assistance.

Here are the steps:
1.Unlock the bootloader.
2.Flash the ROM and Magisk.v26.3.apk
3.Install:
Patch-Enhancer-v0.4.zip
LSPosed-v1.9.1-6990-zygisk-release.zip
KnoxPatch-v0.6.1.apk
4.After restarting the phone and opening the camera, the buttons within the app work as expected, but the camera screen remains black. The issue persists whether switching between the front and rear cameras. Approximately 30 seconds after the app is opened, an error occurs, and the error message states: 'An error has occurred.

[salvogiangri]

I've already dealt with such an issue in my Galaxy A52s 5G as it has a check in the camera HAL that prevents it to work when the bootloader is unlocked (tho this is limited to devices with a rear SLSI camera sensor). Looks like it is the same in your device:

Give a try to some Magisk/KSU modules that spoof the bootloader unlock prop(s): USNF, MagiskHide Props Config

[309040521]

I have already changed 'ro.boot.verifiedbootstat' to GREEN, but the camera screen remains black.
The modification steps were as follows:
1.Installed and activated 'safetynet-fix-v2.4.0-MOD_2.0.zip' and 'MagiskHidePropsConf-v6.1.2.zip' in Magisk.
2.Installed Termux and rebooted the phone.
3.Opened Termux and used 'su' permissions to execute 'props.'
4.Checked that 'ro.boot.verifiedbootstat' is green.
5.The camera screen is still black.

[salvogiangri]

I have already changed 'ro.boot.verifiedbootstat' to GREEN, but the camera screen remains black. The modification steps were as follows: 1.Installed and activated 'safetynet-fix-v2.4.0-MOD_2.0.zip' and 'MagiskHidePropsConf-v6.1.2.zip' in Magisk. 2.Installed Termux and rebooted the phone. 3.Opened Termux and used 'su' permissions to execute 'props.' 4.Checked that 'ro.boot.verifiedbootstat' is green. 5.The camera screen is still black.

Could be the same as here where safetynet-fix spoofs the bootloader props too late at boot and won't apply to the camera HAL: https://github.com/Displax/safetynet-fix/blob/67d1d1b86e145a8ddcd2f023ac878dc6d23ee3db/magisk/service.sh#L27-L46
Try spoofing your device props with MagiskHide Props Config and see if the issue persists.

[309040521]

I've tried, but it's still not working. Could you please help me check if I made a mistake in any of these steps? Thank you!

1.Open Termux and execute 'su' for permissions.
2.Type '4' for 'edit MagiskHide props.'
3.Type '1' for 'ro.boot.verifiedbootstate.'
4.It shows 'currently set to green by this module.

[309040521]

I've come across a strange situation; when I check the system, 'ro.boot.verifiedbootstat' actually indicates 'green'

[309040521]

[salvogiangri]

I've come across a strange situation; when I check the system, 'ro.boot.verifiedbootstat' actually indicates 'green'

As I said in #53 (comment) the issue is due to the prop being spoofed too late at boot by the USNF module. We can try hex patching the lib and eventually integrate the fix in the Enhancer module.

[309040521]

We don't have any experience in this area(try hex patching the lib). Could you please guide us on how to get started?
Thank you very much!

[salvogiangri]

We don't have any experience in this area(try hex patching the lib). Could you please guide us on how to get started?

Thank you very much!

On A52s case we replace the bootloader prop in the lib with another one so that the camera lib reads that instead (or SELinux blocks it so it fallsback to the default value). https://github.com/LineageOS/android_device_samsung_a52sxq/blob/999b94dc151b00467c4c287e2b42828200b6e0e2/extract-files.sh#L12
The same can be tested in your device, I'm not at home right now so I can't send you the patched libs to be tested.

[309040521]

We don't have any experience in this area(try hex patching the lib). Could you please guide us on how to get started?
Thank you very much!

On A52s case we replace the bootloader prop in the lib with another one so that the camera lib reads that instead (or SELinux blocks it so it fallsback to the default value). https://github.com/LineageOS/android_device_samsung_a52sxq/blob/999b94dc151b00467c4c287e2b42828200b6e0e2/extract-files.sh#L12 The same can be tested in your device, I'm not at home right now so I can't send you the patched libs to be tested.

So, do I need to modify the source code of the 'camera.qcom.so' file to replace the parameters it originally checks?

[salvogiangri]

So, do I need to modify the source code of the 'camera.qcom.so' file to replace the parameters it originally checks?

camera.qcom.so is a compiled binary without any available source code, so the only way is by patching the lib manually. I sent you the code we use on A52s to rename the prop it uses to check the bootloader lock status.
In our device case, the lib checks for ro.boot.flash.locked which result is either "0" (unlocked) or "1", when patched it will either read the new prop (ro.camera.notify_nfc, which value is always 1) or SELinux will block the lib's property_get call, which will return the default value set in the code (luckily 1 in our case).
Your device's HAL on the other hand reads ro.boot.verifiedbootstate which result is instead a string, the values of this prop are either "green" (locked) and "orange" (unlocked). I'm still not sure how the check works so I still have to know if renaming the prop just like we do in A52s is enough to bypass the check. To do this backup the original lib and run this in any shell with root permissions:

sed -i 's/ro.boot.verifiedbootstate/ro.bla.blablablablablabla/g' /vendor/lib64/camera.qcom.so

When patching, the length of the new string must be equal to the one of the old string or smaller (by replacing the missing characters with \x00).

[309040521]

Hello, sir. Modifying these two files seems quite challenging for me. I've come up with another approach, and I'd like to ask for your assessment of its feasibility.
Since my 'ro.boot.verifiedbootstat' is currently set to 'GREEN,' could I potentially uninstall the camera app and then reinstall it to make the app read the updated parameters?
backup.zip
camera.qcom.so=/vendor/lib/hw/camera.qcom.so
camera.qcom.so64=/vendor/lib64/hw/camera.qcom.so

[salvogiangri]

Hello, sir. Modifying these two files seems quite challenging for me. I've come up with another approach, and I'd like to ask for your assessment of its feasibility. Since my 'ro.boot.verifiedbootstat' is currently set to 'GREEN,' could I potentially uninstall the camera app and then reinstall it to make the app read the updated parameters? backup.zip camera.qcom.so=/vendor/lib/hw/camera.qcom.so camera.qcom.so64=/vendor/lib64/hw/camera.qcom.so

Uninstalling the camera app does no effect as this code is in the camera HAL, so this applies globally in the system independently of the app you're using. I've applied the patch in #53 (comment) myself here, give a try to these libs and let me know if it works.

backup-patch.zip

[309040521]

Hello, sir. Modifying these two files seems quite challenging for me. I've come up with another approach, and I'd like to ask for your assessment of its feasibility. Since my 'ro.boot.verifiedbootstat' is currently set to 'GREEN,' could I potentially uninstall the camera app and then reinstall it to make the app read the updated parameters? backup.zip camera.qcom.so=/vendor/lib/hw/camera.qcom.so camera.qcom.so64=/vendor/lib64/hw/camera.qcom.so

Uninstalling the camera app does no effect as this code is in the camera HAL, so this applies globally in the system independently of the app you're using. I've applied the patch in #53 (comment) myself here, give a try to these libs and let me know if it works.

backup-patch.zip

After replacing it, I still can't open the camera. It remains the same even after restarting the phone.
Additionally, I've noticed that before the replacement, when I opened the camera, there was a green dot in the top left corner (indicating the camera was in use). However, after the replacement, this notification dot no longer appears.

[salvogiangri]

After replacing it, I still can't open the camera. It remains the same even after restarting the phone. Additionally, I've noticed that before the replacement, when I opened the camera, there was a green dot in the top left corner (indicating the camera was in use). However, after the replacement, this notification dot no longer appears.

Check if you did replace the file correctly (it's not 0 bytes), also make sure the file permissions/secontext is correct.

[309040521]

Could you please help me check if I made any mistakes in the replacement steps? Thank you!

[salvogiangri]

Could you please help me check if I made any mistakes in the replacement steps? Thank you!

Run ls -lZ on the placed lib files.

[309040521]

[salvogiangri]

Wrong permission/secontexts are set for your libs. Fix them using these cmds:

chmod 644 /vendor/lib/hw/camera.qcom.so
chmod 644 /vendor/lib64/hw/camera.qcom.so
chcon u:object_r:vendor_file:s0 /vendor/lib/hw/camera.qcom.so
chcon u:object_r:vendor_file:s0 /vendor/lib64/hw/camera.qcom.so

[309040521]

I executed the commands you provided, and after restarting the phone, a green indicator dot appeared in the top right corner when I opened the camera. However, the camera screen itself is still black.

Today is our country's annual Mid-Autumn Festival, and I would like to extend my heartfelt greetings to you. I wish you good health and a happy family. Once again, thank you for your guidance over these past few days. Thank you.

[salvogiangri]

I executed the commands you provided, and after restarting the phone, a green indicator dot appeared in the top right corner when I opened the camera. However, the camera screen itself is still black.

Mind sharing some logs so I can see if there's any specific error in the background? I'm currently adding the necessary code to integrate the fix in the Enhancer module (37c77b6), but it still needs to handle devices with the ro.boot.verifiedbootstate prop check. Wanna make sure the prop rename patch works well on those devices.

Today is our country's annual Mid-Autumn Festival, and I would like to extend my heartfelt greetings to you. I wish you good health and a happy family. Once again, thank you for your guidance over these past few days. Thank you.

It's always a pleasure! I willingly reciprocate your good wishes.

[309040521]

I executed the commands you provided, and after restarting the phone, a green indicator dot appeared in the top right corner when I opened the camera. However, the camera screen itself is still black.

Mind sharing some logs so I can see if there's any specific error in the background? I'm currently adding the necessary code to integrate the fix in the Enhancer module (37c77b6), but it still needs to handle devices with the ro.boot.verifiedbootstate prop check. Wanna make sure the prop rename patch works well on those devices.

Today is our country's annual Mid-Autumn Festival, and I would like to extend my heartfelt greetings to you. I wish you good health and a happy family. Once again, thank you for your guidance over these past few days. Thank you.

It's always a pleasure! I willingly reciprocate your good wishes.

It's my honor to help advance this matter. Please instruct me on how to obtain the logs you need.

[salvogiangri]

It's my honor to help advance this matter. Please instruct me on how to obtain the logs you need.

Download adb (platform-tools) and use logcat to obtain logs. Start the command (eg. adb logcat > logs), trigger the bug then interrupt the command (CTRL+C).

[309040521]

Please find the attached log files for troubleshooting. Thank you.
logs.zip

[309040521]

So, do I need to modify the source code of the 'camera.qcom.so' file to replace the parameters it originally checks?

camera.qcom.so is a compiled binary without any available source code, so the only way is by patching the lib manually. I sent you the code we use on A52s to rename the prop it uses to check the bootloader lock status. In our device case, the lib checks for ro.boot.flash.locked which result is either "0" (unlocked) or "1", when patched it will either read the new prop (ro.camera.notify_nfc, which value is always 1) or SELinux will block the lib's property_get call, which will return the default value set in the code (luckily 1 in our case). Your device's HAL on the other hand reads ro.boot.verifiedbootstate which result is instead a string, the values of this prop are either "green" (locked) and "orange" (unlocked). I'm still not sure how the check works so I still have to know if renaming the prop just like we do in A52s is enough to bypass the check. To do this backup the original lib and run this in any shell with root permissions:

sed -i 's/ro.boot.verifiedbootstate/ro.bla.blablablablablabla/g' /vendor/lib64/camera.qcom.so

When patching, the length of the new string must be equal to the one of the old string or smaller (by replacing the missing characters with \x00).

Hello, BOSS. Just as you previously fixed the case, you replaced the 'ro.boot.flash.locked' keyword in the Galaxy A52s 5G device's .so file to achieve the fix.

May I kindly inquire how you determined that your device's .so file was fetching the 'ro.boot.flash.locked' keyword?

I attempted to modify the 'customize.sh' file, but encountered a failure upon application.
customize.zip

[salvogiangri]

May I kindly inquire how you determined that your device's .so file was fetching the 'ro.boot.flash.locked' keyword?

This was actually found by @DavidArsene, but you can clearly see how the check happens if you disassemble the lib:

I attempted to modify the 'customize.sh' file, but encountered a failure upon application. customize.zip

ro.boot.product.vendor.sku is one byte longer than ro.boot.verifiedbootstate, your new prop must have the same exact length as the old one (or shorter by replacing the missing chars with \x00). You also forgot to apply 77bcca8.

[309040521]

In reference to the discussion in commit 77bcca8, I changed 's/ro.boot.verifiedbootstate/ro.com.android.mobiledata/g' to ensure that 'ro.boot.verifiedbootstate' and 'ro.com.android.mobiledata' have the same length, and 'green' matches 'false' in length. However, the test results still show a black screen.log_customize.sh.zip

Is it possible that there are additional conditional checks within 'camera.qcom.so' that we haven't identified yet? Could you please provide guidance on how to discover them, or even a general area to look into? I'm willing to try them one by one. Thank you!

[309040521]

第3个方向试了,不行

提交给 ChatGPT 看看？

据我了解,ChatGPT还不支持修改2进制文件.

[309040521]

Hello, sir. With my very limited reverse engineering skills, I've only found the following section of code related to 'bootstate':

Within this snippet, I believe that the code highlighted in red is critical for determining whether the phone's bootloader is unlocked.
Could you please confirm if my understanding is correct? If there are any mistakes, I'd greatly appreciate your guidance. Thank you very much!

[309040521]

I took the initiative to modify your 'customize.sh' based on the ideas mentioned above, but when I open the camera, it crashes. Did I miss something in my changes?
customize.zip

[fakeboboliu]

I took the initiative to modify your 'customize.sh' based on the ideas mentioned above, but when I open the camera, it crashes. Did I miss something in my changes? customize.zip

You are trying to replace pseudo code a binary.
Tthe v385 you focus on is just a flag whether ro.boot.verifiedbootstate is orange, which can be ignored if you replaced property name properly.

[309040521]

I took the initiative to modify your 'customize.sh' based on the ideas mentioned above, but when I open the camera, it crashes. Did I miss something in my changes? customize.zip

You are trying to replace pseudo code a binary. Tthe v385 you focus on is just a flag whether ro.boot.verifiedbootstate is orange, which can be ignored if you replaced property name properly.

As the content in #53 (comment), we've correctly replaced the property name, but the camera is still showing a black screen.
It appears that there is another check mechanism in place. Could you please guide me on how to locate it?

[fakeboboliu]

Could you please guide me on how to locate it?

I have no idea, but you can try to read logcat for more information about what CamX thinking.

[309040521]

Log.zip
After comparing these two logs, I suspect that there's another monitoring mechanism in 'camxhal3module.cpp.' However, it's strange because the error message clearly mentions this file in the logs, but I can't seem to locate it on the phone.
20231013.log => unlocked bootloader and root
nullroot1005_2.log => locked bootloader and unroot

[309040521]

Dear ALL,
Could you please help me see if there's any possibility in the following two directions?
1、Continue attempting to modify the 'camera.qcom.so' file to bypass the BL check of the camera application.
Based on the modifications made in the last month, I have reason to suspect that Samsung has added BL checks not only in 'camera.qcom.so'. Another detection mechanism may be in 'camxhal3module.cpp', but I can't find this file at phone.
2、Try flashing the European version of the F926B firmware.
There are forum posts on the XDA indicating that in the European F926B version, the camera can be used. However, my phone is the Hong Kong version:F9260, and after BL unlocking, it disables the camera. But I'm not sure if this could potentially damage the hardware. I'd like to ask for your advice on this.

@blackmesa123, do you think this issue is beyond the scope of the KnoxPatch application? If so, I'll close this case. Thank you for your guidance and assistance during this time!

[salvogiangri]

1、Continue attempting to modify the 'camera.qcom.so' file to bypass the BL check of the camera application. Based on the modifications made in the last month, I have reason to suspect that Samsung has added BL checks not only in 'camera.qcom.so'. Another detection mechanism may be in 'camxhal3module.cpp', but I can't find this file at phone.

I'm pretty sure you saw this in the logs:

10-13 14:23:13.893  1313  1313 I CamX    : [CORE_CFG][HAL    ] camxhal3module.cpp:506 HAL3Module() ***************************************************
10-13 14:23:13.893  1313  1313 I CamX    : [CORE_CFG][HAL    ] camxhal3module.cpp:507 HAL3Module() SHA1:     
10-13 14:23:13.893  1313  1313 I CamX    : [CORE_CFG][HAL    ] camxhal3module.cpp:508 HAL3Module() COMMITID: 
10-13 14:23:13.895  1313  1313 I CamX    : [CORE_CFG][HAL    ] camxhal3module.cpp:509 HAL3Module() BUILD TS: 8/11/2023 14:28:25
10-13 14:23:13.895  1313  1313 I CamX    : [CORE_CFG][HAL    ] camxhal3module.cpp:510 HAL3Module() ***************************************************

You can't find this file simply because it doesn't exists. The original file is part of the source code of the camera.qcom.so binary, and is mentioned (along side with the line of code) as extra debug info for developers, but as I already explained the camera HAL code is private and only Qualcomm/Samsung owns it.

2、Try flashing the European version of the F926B firmware. There are forum posts on the XDA indicating that in the European F926B version, the camera can be used. However, my phone is the Hong Kong version:F9260, and after BL unlocking, it disables the camera. But I'm not sure if this could potentially damage the hardware. I'd like to ask for your advice on this.

I've already sent you the F926B camera files in #53 (comment), those are the only different files/binaries that differ from the international firmware and the Korean one. You could also try flashing the F926B super.img firmware and see if camera works fine rather than manually replacing the camera files just in case.

@blackmesa123, do you think this issue is beyond the scope of the KnoxPatch application? If so, I'll close this case. Thank you for your guidance and assistance during this time!

camera-fix branch already has the camera fix patch for A52s (ro.boot.flash.locked case) implemented in the Enhancer Magisk module, as soon as someone figures out a way to patch your device's camera HAL as well (since you reported replacing the prop isn't enough) I'll be happy to include the complete fix in the next release.

[fakeboboliu]

Another detection mechanism may be in 'camxhal3module.cpp', but I can't find this file at phone.·

camxhal3module.cpp is one of the source files of camera.qcom.so, you can continue to inspect camera.qcom.so.

Try flashing the European version of the F926B firmware.

According to XDA thread, you may not get the camera back to work even using F926B firmware.

nullroot1005_2.log => locked bootloader and unroot

BTW, where's nullroot1005_2.log? I'm trying to compare them but you didn't published it.

All in all, thanks for your support of Samsung, buy a Pixel fold next time.

[309040521]

BTW, where's nullroot1005_2.log? I'm trying to compare them but you didn't published it.

I'm sorry, I missed the upload. Please see #53 (comment)

[salvogiangri]

看作者提交的新 Actions，似乎已经解决了摄像头黑屏的问题。

#53 (comment):

camera-fix branch already has the camera fix patch for A52s (ro.boot.flash.locked case) implemented in the Enhancer Magisk module, as soon as someone figures out a way to patch your device's camera HAL as well (since you reported replacing the prop isn't enough) I'll be happy to include the complete fix in the next release.

[CANNONGH]

It says "camera-fix branch already has the camera fix patch for A52s (ro.boot.flash.locked case) implemented in the Enhancer Magisk module" but on my F946N The camera is disabled.
Has this issue been resolved yet?

[Heisenbeg]

It says "camera-fix branch already has the camera fix patch for A52s (ro.boot.flash.locked case) implemented in the Enhancer Magisk module" but on my F946N The camera is disabled. Has this issue been resolved yet?

I also want to know if it can be solved. By the way, does SM-946N support call recording?

[LittlenineLst]

Disable by ABL due to a policy of HDM . can be unlocked by token MODE_AVOID_HDM_OEM_UNLOCK_POLICY

[309040521]

Disable by ABL due to a policy of HDM . can be unlocked by token MODE_AVOID_HDM_OEM_UNLOCK_POLICY

Could you please provide me with more details or guidance on how to proceed? Thank you.

[Tavar3z]

I have a s22 sm-s901 and this method works for it, I receive the warning "camera error" only on the rear camera

[AnkioTomas]

Is there any update ?
I have tried the Magisk module of the camera-fix branch, but it has no effect.
If possible, I can provide debugging logs or other necessary assistance for your work.

[AnkioTomas]

I found some errors with camera-fix:

• On some 64-bit machines, there is no /vendor/lib/hw/camera.qcom.so; instead, they have it in /vendor/lib64/hw/camera.qcom.so.
• Based on my decompilation, camera.qcom.so does not check ro.boot.flash.locked, but rather checks ro.boot.verifiedbootstate.

I successfully replaced ro.boot.verifiedbootstate using the above approach, and now it shows the default value 0 instead of orange in the output, but it doesn't seem to work.

[AnkioTomas]

I think I have probably found the location where the camera failed, but this function is too long........

[mirh]

So.. just saying, but did you notice that there is some reference source code available?

CSLHwEnumerateAndAddCSLHwDevice calls CSLHwInternalFDIoctl before throwing the enumerate fail.
And I would guess that if entity.name is an empty character/space and entity.id is -2³¹+100 (100 being also suspicously the length of errnoStr) then the problem resides further up.
Like, I don't know, are the permissions in /dev/media fine?

[AnkioTomas]

Thank you for your reminder @mirh , But I couldn't find any Camx source code to refer to

Based on my investigation, I believe it may be due to a failed ioctl call, but since there is no log output here, I cannot determine if the ioctl call failed during execution. The ioctl call occurred during the kernel phase, perhaps I should analyze the kernel logs?

Later tonight, I will try to analyze the kernel logs to troubleshoot the issue.

[AnkioTomas]

Unfortunately, based on my extensive review of XDA discussion materials and my own research findings.
The activation and deactivation of the camera module seem to be controlled by the kernel, which is clearly not something that a Magisk module can handle.
I have given up on further research. If anyone is willing to continue studying, we can continue to discuss.

Some of my reference materials:

• Source code leaked from camera module
• XDA's Discussion