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

Question Unlocking bootloader will disable the camera?

Search This thread
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
 

jemfalor

Senior Member
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
thinking out loud will help everyone. so everyone please chime in your 2cents!
 

jemfalor

Senior Member
list all partitions in the phone vs the boot images in BL, AP, CP , and CSC. are there any Partitions not from stock firmware? those Partitions are things we should check where data persists across flash.

i realised this after flashing variant csc.

after changing csc, indeed sop is to format or wipe. i suspect, some data and configuration are initialized only after certain data has been wiped or purged or removed or blanked.

observing these changes may require twrp with multidisabler enabled, disabling fbe.
 
Last edited:

Mario119

Senior Member
Dec 26, 2013
193
63
Nexus 7 (2013)
Nexus Player
Looks like a new update is out, at least for the Unlocked 512GB model. The update is identified as F926U1UEU1AUG8 and the changelog only mentions "improved security and stability"

Not sure if they've done anything else behind the scenes, however.
 
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..
 

jemfalor

Senior Member
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
 
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
Back to having free time, the param partition is a good place to look as it is the second thing that the bootloader loads up. I'll also be looking into that today, as well as the devinfo partition as that's where the system reads the status of the bootloader.

I noticed some unique variances in the dtbo image as well (device tree objects). We have 8 dts files in our dtbo(generally for different board versions/revisions) but as far as I found, all fold 3 boards use the same board and revision. 2 of the dts files are missing the code that points to the Hex location of the camera(dts3 and dts6).
I have to check into the dtb files inside the kernel today for discrepancies as the bootloader calls on the dtb files at the very beginning directly after it checks board version and checks/verifies the unlock status of the bootloader, before it even loads the kernel init. So I'm going to look for potential code that may point to which one gets loaded.

I received an update notice for the unlocked version. Knowing somethings can differ between updates, like an updated bootloader, and can prevent rooting, should we hold off if we are still on the original firmware it shipped with?
So the new bootloader files aren't all the exact same, but the actual bootloaders (xbl, abl) haven't changed version, so they are still backwards compatible.
Having said that, if you don't see any benefits from upgrading, hold off for a while just in case. The new update doesn't really bring any useful benefits
 

exocetdj

Senior Member
Dec 2, 2011
6,687
4,226
Jah's making me crazy
Back to having free time, the param partition is a good place to look as it is the second thing that the bootloader loads up. I'll also be looking into that today, as well as the devinfo partition as that's where the system reads the status of the bootloader.

I noticed some unique variances in the dtbo image as well (device tree objects). We have 8 dts files in our dtbo(generally for different board versions/revisions) but as far as I found, all fold 3 boards use the same board and revision. 2 of the dts files are missing the code that points to the Hex location of the camera(dts3 and dts6).
I have to check into the dtb files inside the kernel today for discrepancies as the bootloader calls on the dtb files at the very beginning directly after it checks board version and checks/verifies the unlock status of the bootloader, before it even loads the kernel init. So I'm going to look for potential code that may point to which one gets loaded.


So the new bootloader files aren't all the exact same, but the actual bootloaders (xbl, abl) haven't changed version, so they are still backwards compatible.
Having said that, if you don't see any benefits from upgrading, hold off for a while just in case. The new update doesn't really bring any useful benefits
apparently we now have 4GB of extra "virtual ram"- apparently samsungs "Ram +" has been added

- edit - looks like thats been in since the start actually
 
Last edited:

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
    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.
    6
    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.
    6
    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
  • 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
    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.
    6
    Potential Good news updates!
    Slight ramble atm because it's still early and spilling information.

    It seems that since Android 11, AIDL(Android interface device language) is implemented instead of HIDL, making it so that the HAL layer(code layer that interacts with hardware devices to create their action states such as on, off, etc) is altered by a vendor through the vendor folders and not through deeper means. Because this makes it easier to change via Ota updates.

    Camera provider HAL, which enumerates the available individual camera devices known to the provider, and provides updates about changes to device status, such as connection, disconnection

    This means that another potential fix could be turning the camera back on after the OS has been booted by editing the code from the vendor folder, *if that is how they did it*. Root would of course be needed for this. Will be checking the vendor folder here in a while.


    All relevant links and info to what I've said are located in the link below