• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Question Unlocking bootloader will disable the camera?

Search This thread

exocetdj

Senior Member
Dec 2, 2011
6,698
4,231
Jah's making me crazy
It's binary, because upon compiling the kernel, the dts files are converted to dtb files for the kernel to read. Source files easily created by a person, converted to blob files easily read by machine. So trying to view the actual files from within won't work..

That's fine, as those two files were only to help speed up the process. But I do need to see the contents of you i2c folders still.

There's also potential to find it as a module under sys/module/.
But looking at the vendor_boot.img, I can't really see a module that's specific for the camera, but then again they are all named fairly uniquely.



Side note, yeah notepad++ doesn't like binary files, using something like sublime if you're on windows is better for development purposes. But then again we don't like binary files either lol
Great info dude. 👍 I have these folders on my device internal storage so will zip and upload for you
 
  • Like
Reactions: Acoustichayes

exocetdj

Senior Member
Dec 2, 2011
6,698
4,231
Jah's making me crazy
It's binary, because upon compiling the kernel, the dts files are converted to dtb files for the kernel to read. Source files easily created by a person, converted to blob files easily read by machine. So trying to view the actual files from within won't work..

That's fine, as those two files were only to help speed up the process. But I do need to see the contents of you i2c folders still.

There's also potential to find it as a module under sys/module/.
But looking at the vendor_boot.img, I can't really see a module that's specific for the camera, but then again they are all named fairly uniquely.



Side note, yeah notepad++ doesn't like binary files, using something like sublime if you're on windows is better for development purposes. But then again we don't like binary files either lol
Attached dude
 

Attachments

  • ic2.zip
    110.9 KB · Views: 11
Quality. Looking from my phone, I can see an entire folder for the main power module in each of the i2c folders. Which means that at least it isn't removed from the device tree. Once I get to my computer, I'll be able to check the files to see if status is set to disable for the power modules, as well as if the actual camera sensors are listed.

There is a chance that the power module is still active so at least the torch can be used
 

dec3169

Member
Dec 24, 2013
19
41
So I'm not an android developer (been using Linux for 29 years though) and I do not yet have this phone but am planning on it. Still using rooted Note 8.

Question - did any of you look at this from a different perspective - like what actions happen when you unlock the bootloader? If you can find the instructions that are executed when you "flip that switch" you can see the command that they are running to disable the cameras. I don't know if you can do strings searches for whatever the message is that is shown when you unlock the BL on the phone, but you should be able to download most of the software from / to your PC and search from there. Maybe they're are doing something like a linux module blacklist. I don't know where Android keeps the files like modules.conf (I'll search my rooted Note8 later) but that could be a possibility.

Are there tools in Android where you can closely monitor when new jobs start to maybe see what happens when the BL is unlocked? If so, then maybe you can upload 'strace' and repeat the process to see what is executed.

I figure for them to be able to change your phone on the fly that quickly, AND to put it back once the BL is locked (assuming no flashes) it has to be something like a command or a module. Since it also looks to see if anything was flashed I'm leaning towards a program, although if these things still run dm-verity then a command might not be necessary since flashes should be seen on boot.

If it's a command it could be a new one. Maybe if someone has the earlier Fold (rooted) they could do a "ls -latR /" and someone could do the same on the Fold 3 - then do a diff to see what new commands show up.

Then again - maybe I'm just too familiar with Linux and there are too many differences with Android. Hopefully this at least helps spur thought.
 
So I'm not an android developer (been using Linux for 29 years though) and I do not yet have this phone but am planning on it. Still using rooted Note 8.

Question - did any of you look at this from a different perspective - like what actions happen when you unlock the bootloader? If you can find the instructions that are executed when you "flip that switch" you can see the command that they are running to disable the cameras. I don't know if you can do strings searches for whatever the message is that is shown when you unlock the BL on the phone, but you should be able to download most of the software from / to your PC and search from there. Maybe they're are doing something like a linux module blacklist. I don't know where Android keeps the files like modules.conf (I'll search my rooted Note8 later) but that could be a possibility.

Are there tools in Android where you can closely monitor when new jobs start to maybe see what happens when the BL is unlocked? If so, then maybe you can upload 'strace' and repeat the process to see what is executed.

I figure for them to be able to change your phone on the fly that quickly, AND to put it back once the BL is locked (assuming no flashes) it has to be something like a command or a module. Since it also looks to see if anything was flashed I'm leaning towards a program, although if these things still run dm-verity then a command might not be necessary since flashes should be seen on boot.

If it's a command it could be a new one. Maybe if someone has the earlier Fold (rooted) they could do a "ls -latR /" and someone could do the same on the Fold 3 - then do a diff to see what new commands show up.

Then again - maybe I'm just too familiar with Linux and there are too many differences with Android. Hopefully this at least helps spur thought.
Sorry for the delay here. Business responsibilities came up that had to, and still have to take my attention. But my computer still has everything open searching. Looks like a war zone. (Pic below)

What I can say so far is that the code for this is more unique since there are a few changes since earlier versions of Android. Main points being there are actually 2 boot images. The Android stock boot image from Google that no longer gets changed by the vendor. The vendor makes a vendor_boot image that flashes over the stock boot image that contains all the updates for the device specific functions. However, the vendor boot image is the exact same size as the stock boot image which makes me think they just overwrite the whole boot image. As well as having the separate device tree blob image that gets flashed after the fact, and then the vbmeta image to not only verify the chain, but also runs inside android to keep things verified down to the kernel level. So we wouldn't be able to just alter the code while it's running as vbmeta would throw a fit.
So unfortunately it's not as easy as it would be on a standard Linux os..

I'm sorry it's been days without hearing back on updates as I've had prior obligations. And learning kernel has been mentally draining! Especially since so much has changed in the last few iterations of Android. But it's also rewarding in a sense.
 

Attachments

  • 20210923_112322.jpg
    20210923_112322.jpg
    1.8 MB · Views: 136

Talderon

Senior Member
So this is kind of ten fold as it's not just Samsung.
The article I linked below explains everything in detail, but I'll sum it up here. Not saying I agree that they should be locked down, just explaining.

1. Intellectual property - many manufacturers that spend a boat load of money on creating their software (Samsung being the biggest) don't want you to be able to just take it and reverse engineer it so as to copy it or give it to a competitor. Especially because the tech industry for phones is so intense these days.

2. Google/app Developers - Google makes partnerships with these manufacturers because Google ads is how Google makes money off Android, since Android soirce is given at no cost. If rooting was really simple, a large chunk of people would do it and then disable ads, making Google lose a lot of money.
- But also companies that develop apps want to make sure their apps are secure. Netflix had a big ordeal about it years ago because of multiple reasons I won't get into here.


3. Carriers - They develop partnerships with manufacturers based on security, as well as sales potential. Because it also means less Chance of people messing around on their network whether that be hacking tethering capabilities, snooping packets on the network, or changing carrier settings to attain things you either aren't paying for, or stopping them from collecting analytics.
There's a reason why most carriers offer free/almost free upgrades to mostly apple and Samsung phones, the security. To entice you to select a phone that keeps them in more control.


The article talks about more though
I can agree with your statements here. I don't condone (locking/crippling the devices) or like it, but it is what it is.

Anyone who thinks that any part of this is not true, just look at GCam.

Google made this camera app for their Pixel devices and yet, everyone wants a port of this for their non-pixel devices. Pretty much sums what was said up above. They do not release it for other devices because if gives them a bit of an edge for Camera Features, but when people take the time to rip it apart and modify it (without permission) for other devices, we're pretty much proving their point on locking things down to protect R&D dollars spent to make things.

Right to own and right to repair are different and I do not think they should be bundled under the same umbrella, but they overlap in may areas.

I support both movements. When you buy a device, it should belong to the owner, however, that means, in no way, that we have a right to their source code to mess with as we please. That is where Right to Repair is at, the device should be repairable, but 3rd parties that have the training and access to the parts. We should also be allowed to use and modify these devices how we please, as long as we are not violating the license agreements. Now, going from a Samsung ROM to an AOSP ROM should be allowed it if is open source and/or adheres to the license agreements of the applications being installed/used.

However, when we buy these devices, the applications on there are LICENSED for our use under the terms and agreements for each and every app. This gives us no rights to the source code of those apps to modify as we please.
 

jemfalor

Senior Member
I can agree with your statements here. I don't condone (locking/crippling the devices) or like it, but it is what it is.

Anyone who thinks that any part of this is not true, just look at GCam.

Google made this camera app for their Pixel devices and yet, everyone wants a port of this for their non-pixel devices. Pretty much sums what was said up above. They do not release it for other devices because if gives them a bit of an edge for Camera Features, but when people take the time to rip it apart and modify it (without permission) for other devices, we're pretty much proving their point on locking things down to protect R&D dollars spent to make things.

Right to own and right to repair are different and I do not think they should be bundled under the same umbrella, but they overlap in may areas.

I support both movements. When you buy a device, it should belong to the owner, however, that means, in no way, that we have a right to their source code to mess with as we please. That is where Right to Repair is at, the device should be repairable, but 3rd parties that have the training and access to the parts. We should also be allowed to use and modify these devices how we please, as long as we are not violating the license agreements. Now, going from a Samsung ROM to an AOSP ROM should be allowed it if is open source and/or adheres to the license agreements of the applications being installed/used.

However, when we buy these devices, the applications on there are LICENSED for our use under the terms and agreements for each and every app. This gives us no rights to the source code of those apps to modify as we please.
this sounds like a paradox. first locking and crippling cannot be condoned. second, modifying of source code cannot be condoned.

it's equivalent to say capital punishment cannot be condoned but still we would proceed with death penalty because the actions of the criminal cannot be condoned.

lol. regardless of anyone's opinion, there shouldn't be anyone objecting to what needs to be done. because regardless of any objection, what needs to be done has to be done.
 
  • Like
Reactions: JaboJG and Talderon

dec3169

Member
Dec 24, 2013
19
41
What I can say so far is that the code for this is more unique since there are a few changes since earlier versions of Android. Main points being there are actually 2 boot images. The Android stock boot image from Google that no longer gets changed by the vendor. The vendor makes a vendor_boot image that flashes over the stock boot image that contains all the updates for the device specific functions. However, the vendor boot image is the exact same size as the stock boot image which makes me think they just overwrite the whole boot image. As well as having the separate device tree blob image that gets flashed after the fact, and then the vbmeta image to not only verify the chain, but also runs inside android to keep things verified down to the kernel level. So we wouldn't be able to just alter the code while it's running as vbmeta would throw a fit.
So unfortunately it's not as easy as it would be on a standard Linux os..
I think the boot image copy thing is dm-verity (could be wrong on the name). The Note 8 took forever to get rooted because of that. You could root it with stuff like King Root, but the root would only last a few minutes - then the phone would reboot and when it came back root was gone. Caveat - that was on a snapdragon phone with a locked bootloader (like most have been on AT&T in the states for a while until now). I don't know if they got around that, because I waited to buy my note8 while they tried to figure out how to get perma-root. I finally gave up and bought an Exynos phone from S Korea with the unlocked bootloader. The ROMs all got rid of dm-verity.

If that is the answer, ROM devs should be able to make short order of the issue, assuming they can figure out how to trick the phone into turning the camera back on once the BL is unlocked and the extra image is eliminated or tweaked. From what I've heard so far unlocking the BL isn't like busting the Knox fuse so there has to be a way.

I just had to speed up adopting this phone. Something went wrong with either magisk or my work Outlook, and I got a call from one of my IT guys asking if I rooted my phone or if I was hacked. Outlook, Teams, Sharepoint, and a few others showed up in their logs with me coming in as root. I had been doing it for 2 years, along with VPN, and magisk always hid that until the other day. Now my new Fold Z3 comes late next week. Oh well. (and no - I didn't get into any trouble - they were relieved I hadn't been hacked)
 

MelodicMeth

Member
Apr 5, 2011
7
5
I'm sorry it's been days without hearing back on updates as I've had prior obligations. And learning kernel has been mentally draining! Especially since so much has changed in the last few iterations of Android. But it's also rewarding in a sense.
Bro, no worries. I'm just glad someone is taking the time to help out the community with this. Thanks for your efforts!
 

ilia1985

Senior Member
Oct 14, 2010
736
784
Al Ain
ASUS ROG Phone 5
If this is anything like example Sony does, then what probably happens is when you unlock you lose some part of drm and my guess is camera modules or blobs are stored on drm. This what Sony used to do and still does when unlocking you lose some camera functionality under pretense of proprietary. Recently redmagic 6 pulled same thing by placing fp modules on drm partition.
 
I take it the avenue offered in that tweet with "more soon" is fully shut now then? Big shame :(

At least 2 people who are ardent rooters have returned to stock as they need the cameras. :oops:

its one shame where sammy do this to us and another when hopes are raised without any context or proof of concept. 🤷‍♂️
I haven't heard back from him unfortunately. Idk how busy his Twitter is, but I'll try contacting him on here too.
But I get it, camera is such a big thing that you don't realize is important until you are without it.


I think the boot image copy thing is dm-verity (could be wrong on the name). The Note 8 took forever to get rooted because of that. You could root it with stuff like King Root, but the root would only last a few minutes - then the phone would reboot and when it came back root was gone. Caveat - that was on a snapdragon phone with a locked bootloader (like most have been on AT&T in the states for a while until now). I don't know if they got around that, because I waited to buy my note8 while they tried to figure out how to get perma-root. I finally gave up and bought an Exynos phone from S Korea with the unlocked bootloader. The ROMs all got rid of dm-verity.

If that is the answer, ROM devs should be able to make short order of the issue, assuming they can figure out how to trick the phone into turning the camera back on once the BL is unlocked and the extra image is eliminated or tweaked. From what I've heard so far unlocking the BL isn't like busting the Knox fuse so there has to be a way.

I just had to speed up adopting this phone. Something went wrong with either magisk or my work Outlook, and I got a call from one of my IT guys asking if I rooted my phone or if I was hacked. Outlook, Teams, Sharepoint, and a few others showed up in their logs with me coming in as root. I had been doing it for 2 years, along with VPN, and magisk always hid that until the other day. Now my new Fold Z3 comes late next week. Oh well. (and no - I didn't get into any trouble - they were relieved I hadn't been hacked)
Awkwardly, with Samsung, it's a dm-verity, a selinux, and a defex security situation. I know they have already found ways around defex and everything else in Android 11, ironically through a buffer overflow in the camera stack by making a script run twice (extremely short explanation there). But attaining root and disabling security isn't the issue at hand. Just finding where exactly they have it setup to disable the camera sensor. It's just the sensor that is disabled and not the camera power module, so it has to be switchable.


If this is anything like example Sony does, then what probably happens is when you unlock you lose some part of drm and my guess is camera modules or blobs are stored on drm. This what Sony used to do and still does when unlocking you lose some camera functionality under pretense of proprietary. Recently redmagic 6 pulled same thing by placing fp modules on drm partition.
I thought that too for a bit, but Sony had fixed the complete break of the camera in Android 11. You just lose some of their proprietary features for the camera.
It is possible though that Samsung is running proprietary code for the under screen camera, which could be part of the problem. Honestly though, I don't see that as a reason to intentionally disable 5 cameras just for a bootloader unlock when they could just say hey, you're going to get horrible under screen camera quality if you change things.
Idk, there's still a lot of that to explore because I'm sure that code is in the system and not in the camera app itself
 
  • Like
Reactions: Full House
I take it the avenue offered in that tweet with "more soon" is fully shut now then? Big shame :(

At least 2 people who are ardent rooters have returned to stock as they need the cameras. :oops:

its one shame where sammy do this to us and another when hopes are raised without any context or proof of concept. 🤷‍♂️
So I came across some things in looking at the android 10/11 revision pages..
First photo is the question, can you access your odm partition, and can you give me the contents of the odm folder?
Also the /etc folder? (not the odm/etc)
As this is now where board specific implementation of kernel modules is apparently created since Android 10. And since the camera runs on a HAL(AIDL), this should be where the camera calls are located
Screenshot_20210924-124524_Firefox Beta~(1).jpg


- HELPFUL HINDSIGHT INFO -
Also came upon these 2 pieces (second and third images) which show that Android gives specific control to turn on or off the camera sensors on a system level (Android 10) as well as control what types of apps can have access to cameras (priv-app, user-app, system, etc) (Android 11)

Can't believe we overlooked this stuff. That's what I get for being out of the game for a few years. But this is a really strong step forward!
 

Attachments

  • Screenshot_20210924-124744_Firefox Beta.jpg
    Screenshot_20210924-124744_Firefox Beta.jpg
    335.3 KB · Views: 90
  • Screenshot_20210924-125101_Firefox Beta.jpg
    Screenshot_20210924-125101_Firefox Beta.jpg
    191.8 KB · Views: 89
Last edited:

exocetdj

Senior Member
Dec 2, 2011
6,698
4,231
Jah's making me crazy
So I came across some things in looking at the android 10/11 revision pages..
First photo is the question, can you access your odm partition, and can you give me the contents of the odm folder?
Also the /etc folder? (not the odm/etc)
As this is now where board specific implementation of kernel modules is apparently created since Android 10. And since the camera runs on a HAL(AIDL), this should be where the camera calls are located
View attachment 5417853


- HELPFUL HINDSIGHT INFO -
Also came upon these 2 pieces (second and third images) which show that Android gives specific control to turn on or off the camera sensors on a system level (Android 10) as well as control what types of apps can have access to cameras (priv-app, user-app, system, etc) (Android 11)

Can't believe we overlooked this stuff. That's what I get for being out of the game for a few years. But this is a really strong step forward!
your doing an awesome job mate

/etc and /odm are below
 

Attachments

  • odm.zip
    403.8 KB · Views: 3
  • etc.zip
    11.8 MB · Views: 4

exocetdj

Senior Member
Dec 2, 2011
6,698
4,231
Jah's making me crazy
So I came across some things in looking at the android 10/11 revision pages..
First photo is the question, can you access your odm partition, and can you give me the contents of the odm folder?
Also the /etc folder? (not the odm/etc)
As this is now where board specific implementation of kernel modules is apparently created since Android 10. And since the camera runs on a HAL(AIDL), this should be where the camera calls are located
View attachment 5417853


- HELPFUL HINDSIGHT INFO -
Also came upon these 2 pieces (second and third images) which show that Android gives specific control to turn on or off the camera sensors on a system level (Android 10) as well as control what types of apps can have access to cameras (priv-app, user-app, system, etc) (Android 11)

Can't believe we overlooked this stuff. That's what I get for being out of the game for a few years. But this is a really strong step forward!
I will infuse you with beer if ya get this hahaha
 
  • Love
Reactions: Acoustichayes
your doing an awesome job mate

/etc and /odm are below
Well, your odm partition isn't much different than mine, and the device files in it are empty, seemingly saying they did not use the odm partition as suggested by Google. Leave it to Samsung to do everything differently.

@Ivan_Meler any news on the fix? Cheers man!

Would be reassuring to see a vid or a tester to show proof of fix
It would be quality to be filled in on it to be able to help is all I'm saying
 
  • Like
Reactions: exocetdj
Apologies that we haven't really been updating every step along the way the last few days! Joined a telegram group with other devs for fold 3 issues, which now is mostly about the camera, and just kind of been updating each other in the group.

But we did stumble upon 2 odd things today.
1 - the newest bootloader force closes the camera app and causes the phone to restart, where the original one just gives you an error message when you try to use the camera.
2 - when you do try to use the camera, the lens does try to focus, meaning that the drivers and libraries are all loaded up and working properly. And it takes a few seconds for the camera app to say the camera isn't working (because another thread is opened when calling for the camera to the isp to display what the camera sees which takes a moment.)

Both of those are kind of contradictory.
(the rest of this comment is purely my opinion and doesn't explicitly represent the opinions of the rest of the dev group)
The first implies that the actual bootloader impliments the lockout, whereas the second infers that it's software related.

I potentially think a couple options as to what might be going on.
1 - going with the simplest idea that should have been checked first, it could be as simple as SafetyNet Attestation built into the camera app that checks if the BL is unlocked right after starting the camera, which would explain the breif delay. So I'm going to check that tomorrow.
2 - using the camera contexts, you can shut down the isp after the phone has booted as there is a couple of Contexts in the kernel talking about it. Shutting down the isp itself would stop the camera from being able to process and display what the camera sees (explains why opening the app takes a few seconds of black screen to say it doesn't work)
3 - I know there was a 3, but my brain is fried as I'm about to go go bed so I'll edit-updates tomorrow when I am awake and back at my computer.

However, this doesn't exactly explain why the new bootloader causes a force close and then phone reboot unless Samsung either messed up code somewhere in the new BL, or did it intentionally to create more frustration. Nor does it say how.

We are all working very hard on this and working from different angles to try to cover as much ground as possible. Ivan said he had a possible fix, but he's been Mia for a week and no one has been able to get ahold of him so we can't rely on that right now!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 10
    Apologies that we haven't really been updating every step along the way the last few days! Joined a telegram group with other devs for fold 3 issues, which now is mostly about the camera, and just kind of been updating each other in the group.

    But we did stumble upon 2 odd things today.
    1 - the newest bootloader force closes the camera app and causes the phone to restart, where the original one just gives you an error message when you try to use the camera.
    2 - when you do try to use the camera, the lens does try to focus, meaning that the drivers and libraries are all loaded up and working properly. And it takes a few seconds for the camera app to say the camera isn't working (because another thread is opened when calling for the camera to the isp to display what the camera sees which takes a moment.)

    Both of those are kind of contradictory.
    (the rest of this comment is purely my opinion and doesn't explicitly represent the opinions of the rest of the dev group)
    The first implies that the actual bootloader impliments the lockout, whereas the second infers that it's software related.

    I potentially think a couple options as to what might be going on.
    1 - going with the simplest idea that should have been checked first, it could be as simple as SafetyNet Attestation built into the camera app that checks if the BL is unlocked right after starting the camera, which would explain the breif delay. So I'm going to check that tomorrow.
    2 - using the camera contexts, you can shut down the isp after the phone has booted as there is a couple of Contexts in the kernel talking about it. Shutting down the isp itself would stop the camera from being able to process and display what the camera sees (explains why opening the app takes a few seconds of black screen to say it doesn't work)
    3 - I know there was a 3, but my brain is fried as I'm about to go go bed so I'll edit-updates tomorrow when I am awake and back at my computer.

    However, this doesn't exactly explain why the new bootloader causes a force close and then phone reboot unless Samsung either messed up code somewhere in the new BL, or did it intentionally to create more frustration. Nor does it say how.

    We are all working very hard on this and working from different angles to try to cover as much ground as possible. Ivan said he had a possible fix, but he's been Mia for a week and no one has been able to get ahold of him so we can't rely on that right now!
    7
    Just to update since it's been a while.
    I have not been able to do a lot with this recently. The team has been working on it, but I have had numerous situations pull me away. Busy season for business since it's starting to get cold so I've been working nonstop. In the process of hiring more people so I can have more free time.

    Really debating doing a few things that I can't talk publicly about atm in order to get more Intel on the camera.
    I do apologize about the lackluster update because I know a lot of people are really looking forward to this
    5
    Not a dev, but always love reading the progress and information.
    Also, Sammy is sus, perhaps they kidnapped Ivan.
    That's why I like updating people on progress. I know there are those out there that enjoy learning and following along, as well as to help relieve stress lol.
    If they did kidnap him, maybe he can break free and just get the Samsung private keys so we can sign anything we need! Haha
    3
    I have prior obligations to take care of for the next few days so I will be scarce, but the group is still looking for potential fixes even though updates won't be posted here most likely.

    Jemfalor the input is appreciated. Unfortunately all things we've already looked into. At the moment the best we can do is attempt to find where the change is being executed.
    There is potential in the libcameraservice.so library, but that will take some time to crack. Until then, some focus is still on the techpack files in the kernel as those are technically proprietary for our device.

    I attempted to binwalk compare the old and new bootloader but that resulted in my ternimal literally scrolling new hexadecimal code for 3 minutes before I just closed it out lol.

    All we need is time..
    I'm thinking of looking into the so called params partition where odin and common criteria configuration are stored since bootloader relock is also controlled via odin process, we could find something in there
    3
    I think someone at Samsung knows how **** my rom is and doesn't want people using it 🤪😂😂😂😂😂😂😂😂😂😂😂
    Wholly agree. It's a universal effort. The more input there is, the quicker a solution can be found
    Rerooted and most likely staying that way now - give me a shout if you need anything
  • 20
    Did your phone arrive and did you unlock it?

    Yes, my Fold3 (F926B) arrived yesterday and I unlocked its bootloader this afternoon.

    I can confirm that all cameras stop working afterwards. This means that facial recognition also fails. Anything that uses any of the cameras will fail.

    I tried installing a third-party camera app, but this also failed. I took a logcat of the failure:

    Code:
    07-12 13:50:51.413  1384 31574 W ServiceManager: Permission failure: android.permission.CAMERA_OPEN_CLOSE_LISTENER from uid=10291 pid=8927
    07-12 13:50:51.413  1384 31574 D CameraService: CameraDeviceState for CameraManager
    07-12 13:50:51.413  8927  9780 I CameraManagerGlobal: Camera 0 facing CAMERA_FACING_BACK state now CAMERA_STATE_CLOSED for client net.sourceforge.opencamera API Level 1
    07-12 13:50:51.413  8927  9780 I CameraManagerGlobal: Camera 1 facing CAMERA_FACING_FRONT state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.413  8927  9780 I CameraManagerGlobal: Camera 2 facing CAMERA_FACING_BACK state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 20 facing CAMERA_FACING_BACK state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 21 facing CAMERA_FACING_BACK state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 23 facing CAMERA_FACING_BACK state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 3 facing CAMERA_FACING_FRONT state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 4 facing CAMERA_FACING_FRONT state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 52 facing CAMERA_FACING_BACK state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 71 facing CAMERA_FACING_FRONT state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 73 facing CAMERA_FACING_FRONT state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.414  8927  9780 I CameraManagerGlobal: Camera 91 facing CAMERA_FACING_FRONT state now CAMERA_STATE_CLOSED for client android.system API Level 2
    07-12 13:50:51.415  1384 31574 D CameraService: getNumberOfCameras E
    07-12 13:50:51.416  1384 31574 W ServiceManager: Permission failure: android.permission.SYSTEM_CAMERA from uid=10291 pid=8927
    07-12 13:50:51.416  1384 31574 D CameraService: getNumberOfCameras X: ok
    07-12 13:50:51.416  1384 31574 D CameraService: getNumberOfCameras E
    07-12 13:50:51.416  1384 31574 W ServiceManager: Permission failure: android.permission.SYSTEM_CAMERA from uid=10291 pid=8927
    07-12 13:50:51.416  1384 31574 D CameraService: getNumberOfCameras X: ok
    07-12 13:50:51.416  1384 31574 D CameraService: getCameraInfo E: 0

    At a glance, I'm confident that this can be fixed using Magisk (i.e. root), but I can't rule out the camera having been disabled in other ways, too. The situation may not be recoverable.

    After relocking the bootloader, the camera works again.

    It's really obnoxious of Samsung to do this, and I am in two minds now about keeping the device and working on a fix for the issue, or simply returning the unit in disgust. This is the kind of practice I expect from Apple, and I always tell Apple users to vote with their wallet when confronted with such anti-consumer practices.
    10
    Apologies that we haven't really been updating every step along the way the last few days! Joined a telegram group with other devs for fold 3 issues, which now is mostly about the camera, and just kind of been updating each other in the group.

    But we did stumble upon 2 odd things today.
    1 - the newest bootloader force closes the camera app and causes the phone to restart, where the original one just gives you an error message when you try to use the camera.
    2 - when you do try to use the camera, the lens does try to focus, meaning that the drivers and libraries are all loaded up and working properly. And it takes a few seconds for the camera app to say the camera isn't working (because another thread is opened when calling for the camera to the isp to display what the camera sees which takes a moment.)

    Both of those are kind of contradictory.
    (the rest of this comment is purely my opinion and doesn't explicitly represent the opinions of the rest of the dev group)
    The first implies that the actual bootloader impliments the lockout, whereas the second infers that it's software related.

    I potentially think a couple options as to what might be going on.
    1 - going with the simplest idea that should have been checked first, it could be as simple as SafetyNet Attestation built into the camera app that checks if the BL is unlocked right after starting the camera, which would explain the breif delay. So I'm going to check that tomorrow.
    2 - using the camera contexts, you can shut down the isp after the phone has booted as there is a couple of Contexts in the kernel talking about it. Shutting down the isp itself would stop the camera from being able to process and display what the camera sees (explains why opening the app takes a few seconds of black screen to say it doesn't work)
    3 - I know there was a 3, but my brain is fried as I'm about to go go bed so I'll edit-updates tomorrow when I am awake and back at my computer.

    However, this doesn't exactly explain why the new bootloader causes a force close and then phone reboot unless Samsung either messed up code somewhere in the new BL, or did it intentionally to create more frustration. Nor does it say how.

    We are all working very hard on this and working from different angles to try to cover as much ground as possible. Ivan said he had a possible fix, but he's been Mia for a week and no one has been able to get ahold of him so we can't rely on that right now!
    8
    do you think it would work if i unlock my bootloader then flash a variant firmware then relock it?
    If you try to relock the bootloader with an unsigned firmware, it will brick your phone and you'd have to use Odin to flash factory firmware to fix it.

    I'm getting close to finding solutions, just hang tight.
    Still have half of our kernel code to go through. But I found the camera drivers and source code, which helps me know what to look for
    7
    Just to update since it's been a while.
    I have not been able to do a lot with this recently. The team has been working on it, but I have had numerous situations pull me away. Busy season for business since it's starting to get cold so I've been working nonstop. In the process of hiring more people so I can have more free time.

    Really debating doing a few things that I can't talk publicly about atm in order to get more Intel on the camera.
    I do apologize about the lackluster update because I know a lot of people are really looking forward to this
    7
    So I'm not an android developer (been using Linux for 29 years though) and I do not yet have this phone but am planning on it. Still using rooted Note 8.

    Question - did any of you look at this from a different perspective - like what actions happen when you unlock the bootloader? If you can find the instructions that are executed when you "flip that switch" you can see the command that they are running to disable the cameras. I don't know if you can do strings searches for whatever the message is that is shown when you unlock the BL on the phone, but you should be able to download most of the software from / to your PC and search from there. Maybe they're are doing something like a linux module blacklist. I don't know where Android keeps the files like modules.conf (I'll search my rooted Note8 later) but that could be a possibility.

    Are there tools in Android where you can closely monitor when new jobs start to maybe see what happens when the BL is unlocked? If so, then maybe you can upload 'strace' and repeat the process to see what is executed.

    I figure for them to be able to change your phone on the fly that quickly, AND to put it back once the BL is locked (assuming no flashes) it has to be something like a command or a module. Since it also looks to see if anything was flashed I'm leaning towards a program, although if these things still run dm-verity then a command might not be necessary since flashes should be seen on boot.

    If it's a command it could be a new one. Maybe if someone has the earlier Fold (rooted) they could do a "ls -latR /" and someone could do the same on the Fold 3 - then do a diff to see what new commands show up.

    Then again - maybe I'm just too familiar with Linux and there are too many differences with Android. Hopefully this at least helps spur thought.