a potential bootloader unlock method

[JerryYOJ]

I've been looking to use this exploit to unlock my huawei too. Through intial investigation, I've found that all the oem unlock option in settings app does is invoke PersistentDataBlockService 's setoemunlock method to set bootloader unlockable.
However, the services verifies access by only allowing calls from a specific package's uid, which is defined in framwork-res.apk as config_persistentDataPackageName, but its unfortunately set to null by huawei, meaning that nobody could get access to the service.
But, all the service did is writing one byte to the end of frp partition with its path stored in [ro.frp.pst], mine is /dev/block/bootdevice/by-name/frp
Since the service runs on system_server, and system_server is forked from zygote, is there a way to bypass the service and directly write to the device?
the frp device file is owned by system and belongs to system group
brw------- 1 system system u:object_r:frp_block_device:s0 8, 11 2025-04-19 23:10 frp
so it should be easy to get the uid to perform the write operation, but the selinux context prove to be a huge hurdle.
The selinux context it has frp_block_device only allows
init_30_0 recovery_30_0 update_binary_30_0 shell_30_0 system_server_30_0 ueventd_30_0
to write to it, others have every file operation blocked in selinux policy
so we need to obtain system_server context or shell context(actually adb shell has this, but adb shell have uid 2000 instead of 1000) through zygote
is this possible?

[Anonymous941]

Hello, and thanks for the helpful information about how exactly OEM unlocking works! Currently my toolkit uses service call in order to use the oem_lock service, because that's as far as I was able to trace the settings app through various functions (mostly abstractions) in AOSP.

I've been trying very hard to understand how Zygote gives apps their SELinux context in order to change the privapp context to something else or add any other contexts, but haven't been able to figure it out, so I don't know whether it's possible to do what you describe. Any help would be appreciated - here is what I currently have for the seinfo argument, that based on the arguments appears to give the most privileged context:

zygote-injection-toolkit/zygote_injection_toolkit/stage1.py

Line 193 in b9dfce8

"--seinfo=platform:isSystemServer:privapp:targetSdkVersion=29:complete",

It seems other Zygote arguments affect SELinux too. What I could is that any context an app, system or otherwise, is permitted to inherit should be possible through Zygote injection - the only limitations Zygote imposes on this exploit are that you cannot set the UID or GID to less then 1000 (including, sadly, root), and that you can't enable any process capabilities.

The relevant source files seem to be external/selinux/libselinux/src/android/android_platform.c and external/selinux/libselinux/src/android/check_seapp.c (duplicated in system/sepolicy/tools/check_seapp.c, but I'm unable to figure out the interaction between Zygote and SELinux due to how complicated and interconnected AOSP is. Any help would be appreciated

Also there is an active attempt, not by me, to exploit CVE-2024-53197, which would give temporary root using a USB kernel vulnerability and requires a $4 Raspberry Pi Pico. Obviously that would bypass any SELinux restrictions. Since it's not my project, I don't know much about it, but you're welcome to join the Discord or its Matrix bridge where it's being developed on the channel #cve-usb-out-of-bounds (focused on Oculus Quest rooting but the exploit works on all Android devices): https://discord.gg/ABCXxDyqrH, https://matrix.to/#/#quest-rooting:matrix.org

[CamsShaft]

@Anonymous941
I can give you some potentially useful information regarding process checks. Once you become system_app, write a native C code that's relevant to whatever it is you need it for. Let's say you want your process to be seen as shell but running with uid 1000. When you compile your C code just name it shell and then run it as system. Then check ps -Af while either in adb shell or system shell otherwise you won't see it. This is what will pop up,

system 29795 17576 0 46:09 pts/1 00:00:01 shell

And believe it or not, whatever you run that C code against and if it's specifically checking for that process as system, it will bypass it... and this is on a North American Samsung device which we all know is nearly impossible to do anything with.

Shhhh... you saw nothing. 🤫🤐

[Anonymous941]

@CamsShaft Interesting, I'll have to try that. Thanks for sharing. I happen to have a locked US Samsung Verizon variant tablet, is it possible to unlock the bootloader of a US Samsung device using this, or escalate privileges to root? I tried to use the oem_lock service but the carrier lock is set and a signature is required. I don't know much about Android services other then oem_lock

[CamsShaft]

Currently, as far as I know, the only methods to unlock the bootloader on North American Samsung snapdragon devices are through unlock tokens. It also seems like public disclosure for root methods and exploits have slowed down quite a lot the past few years. I'm part of a small group that searches for new local privilege escalation techniques and they are very few and far between from what I've seen. That being said, maybe you have more experience in android as a whole and would have better luck with your knowledge. Also, regarding services, the best place to find the most information is by decompiling framework.jar into its Java source code and finding the binder files that start with "I" like IPackageManager.java etc.. and look for a bunch of these --> TRANSACTION_ about halfway into the file, then good luck putting everything together and understanding it to make the proper service call... Anything to do with oem_lock will not get you far at all without a token as I mentioned. If you know anything about AT commands and engmode then you might have a small chance at spoofing something if you're very skilled, but even those are extremely restricted. I'm a bit limited in the info I can give out besides what's public and common knowledge since Samsung loooves to throw patches at everything like Oprah handing out cars like candy. If you want to chat more about anything we'll see what we can do about that. Anyways I hope this helps you a bit!

[Anonymous941]

It also seems like public disclosure for root methods and exploits have slowed down quite a lot the past few years. I'm part of a small group that searches for new local privilege escalation techniques and they are very few and far between from what I've seen.

@CamsShaft I have good news for you! I'm part of a project that's very close to getting a temporary root exploit that works on all Android devices using the Cellebrite zero-day USB exploit chain, using a Raspberry Pi Pico. You can find information on this other exploits we are exploring in this repository. It's called XRBreak and they have a kernel write primitive of 4 bytes and are currently trying to defeat KASLR. You're welcome to join if you want, help with this would be really appreciated as few members have an intricate knowledge of Android (and neither do I, I barely could write this toolkit). It has a Discord server and Matrix bridge: https://discord.gg/3V7yrnDe2R, #xrbreak:itycodes.org.

There's also a larger project related to modding Android VR headsets (although it's no longer the main place the Cellebrite USB exploit chain is being developed), XRBreak split off of it a few days ago due to some drama: https://discord.gg/ABCXxDyqrH, quest-rooting:matrix.org

[CamsShaft]

I'll definitely check it out when I have a minute, I do know about cellebrite but haven't done anything about it. Usually when people say "all android" I'm immediately skeptical because they don't take into account how heavily modified/locked down Samsung devices are or they just skip Samsung entirely. There's very little about Samsung because developers are too comfortable in their little aosp security blankets copying and pasting code word for word from the android website haha 😜 unfortunately I know next to nothing about kernel stuff because these phones are so locked down but I can take a look there anyways and see if I can lend a bit of knowledge if possible. Also forgot to mention the other thing about Samsung and that's fucking SELINUX!!!! Don't even get me started hahaha

[Anonymous941]

Usually when people say "all android" I'm immediately skeptical because they don't take into account how heavily modified/locked down Samsung devices are or they just skip Samsung entirely. There's very little about Samsung because developers are too comfortable in their little aosp security blankets copying and pasting code word for word from the android website haha

I can confirm that my US Samsung tablet is vulnerable, because it causes a crash when I run the payload. Also this exploit works on all Linux kernels, including Android, so hopefully that includes Samsung. SELinux might be a pain though, here's an article on bypassing it, methods 5 and 6 (used to?) work on Samsung devices

[CamsShaft]

The cellebrite exploit causes a crash too? I know the zygote one does, just had to factory reset a couple weeks ago after doing it a few too many times. I was trying to stabilize it by modifying the payload and think I forgot to remove the last one still in the hidden api setting.

[Anonymous941]

Yes, one of the Cellebrite exploits has caused a freeze and reboot on my Samsung tablet, just like the other devices

[JerryYOJ]

Well I dont know linux kernels very well so I couldnt help with the usb exploiting, I'm now currently stuck at obtaining the selinux context for modifying the frp file.
But at least I completed the second return value confusion challenge so you dont need to reboot every time you do the exploit
gist

[JerryYOJ]

It seems like you need a combination of uid AND seinfo to get the context, selinux dont just give you what you ask in seinfo :(
so a system uid and shell context is impossible. Its all on the kernel exploit then

[Anonymous941]

You can get shell only with UID 2000 and the right app name, see /etc/selinux/plat_app_contexts. I'm not sure why you'd want to modify the FRP file though, this exploit requires ADB (or a permission only grantable through ADB) anyway to run in the first place, and if you have that you can just disable FRP with setprop or many other methods oops, I forgot this was how OEM unlocking works

[Anonymous941]

But at least I completed the second return value confusion challenge so you dont need to reboot every time you do the exploit

Which part of that script fixes the return value confusion, is it "/system/bin/logwrapper echo \$(id) #" > payload.txt?

[JerryYOJ]

But at least I completed the second return value confusion challenge so you dont need to reboot every time you do the exploit

Which part of that script fixes the return value confusion, is it "/system/bin/logwrapper echo \$(id) #" > payload.txt?

the return value confusion is fixed by utilizing zygote's arg parsing bug to make it drop the legit request from system_server. To do that, I made my payload command's arg cout absurdly high, forcing zygote to read up the legit command buffer from system_server behind me, thus dropping the legit command, only returning one (incorrect) pid.

the usage of the script is to first use payload.sh to generate a payload.txt, and then use exploit.sh to write the payload.txt into the api_exemption setting