[DISCUSSION][S7-SNAPDRAGON]Unlock Bootloader - R&D

[Arch9]

At this point i think we should open up bounty thread, just like the LG V20 that the bootloader just unlocked a few weeks ago.

 

[Delgoth]

I'm glad to see a lot of R&D I've been able to do with @droidvoider on the Note 5 also seems to be applying here as well.

If you would please look over our thread at: https://xdaforums.com/android/help/injecting-root-setting-selinux-stages-t3573036

Check out the last few pages regarding the progress we've made using the dirtycow exploit. We've actually gotten our console to run within the INIT context. All that is needed now, is proper manual setup of the SU binaries. Most of what I saw on Page 1 of this thread I have written about as well.

I believe there is still a way to make this happen guys.

 

[JosueMirandapr]

So... I made a telegram group just for Snapdragon users to get more effective communication and get helped with all together... If you like this idea, join the group and invite all developers for this Snapdragon s7 or s7 edge users... No Exynos users

https://t.me/joinchat/FJKSa0PqxRWAlXQpLM4rkg

Lets make things better for a custom roms in the future and wishing to have unlock bootloader soon

 

[XCnathan32]

Psa: for anyone still looking at the DD/Flashfire Chinese bootloader method, DO NOT TRY IT, I'm no developer by any means, but by looking at some threads, it appears many people think that the hard bricked device is caused by incorrect partition sizes, and while that may be a part of it. The (most likely) reason that the device is hard bricked is this: "We build our chain of trust according to this definition, starting with the first piece of immutable software running out of read-only-memory (ROM). This first ROM bootloader cryptographically verifies the signature of the next bootloader in the chain, then that bootloader cryptographically verifies the signature of the next software image or images, and so on." source So it looks like when the first bootloader running out of read only memory detects that the chinese flashed bootloader that was flashed has the wrong signature, it doesn't let that bootloader load, which results in no DL mode, no recovery, and an expensive paperweight. Any dev feel free to correct me if i'm wrong.

So, would it be possible to somehow copy the sig from the US S7 to the Chinese S7 BL and then flash it?
Or would it be possible to somehow mod the US BL to check for a flag (like the chinese BL) and unlock the BL if it detects the flag.
Also, how is it not possible to flash a boot.img that was repacked, even if it wasn't modded? How does the phone check for that, because the signature shouldn't be modified just by unpacking and repacking it, right?
The S7 active (which i have) still runs on the V2 BL, so if anyone knows if that could help active users achieve unlock in any way, please let me know.

Once again, i'm not a dev, but i'm willing to learn and help as much as I can, so if anyone could point me into the right direction, that would be greatly appreciated

 

[miniminus]

i was going to post that exact thing about us active user's having bootloader version 2 like the Chinese models
and they talk of the CROM app that unlocks it ? but this is not discussed at length anywhere ?
did i read right that CROM, app was how they unlocked the S5 as thats still on v2 as well ?
is there 'much' risk invovled trying the CROM method ?

UPDATE
just reread the info from OP..
CROM app (Chinese phones have this app to unlock their phones):
Result: This app communicates to Samsung servers and ends up writing a flag (kiwibird?) to STEADY partition. US phones dont have this partition so this currently wont work.
as active is a US based phone, i presume' it doesnt have such a partition either ?? how would we check ? in flashfire ?

UPDATE 2
well reading this post
https://xdaforums.com/s7-edge/samsu...ecovery-official-twrp-galaxy-s7-edge-t3458589
""You will need to unlock your bootloader now. To do this, download the app "CROM Service By Samsung Electronics Co., Ltd." from the Galaxy Apps store and run it.
Follow the instructions in the CROM Service app to allow your device to accept custom images in download mode.""
kinda shows that this WILL unlock the bootloader, so probably WILL work on our actives..
but then it will also trip KNOX too presumably...

UPDATE 3
what i really want to know, is how the TMO (t-mobile) boot.mg files seems to allow you to alter system files, but RETAIN DM-Verity !

 

[XCnathan32]

i was going to post that exact thing about us active user's having bootloader version 2 like the Chinese models
and they talk of the CROM app that unlocks it ? but this is not discussed at length anywhere ?
did i read right that CROM, app was how they unlocked the S5 as thats still on v2 as well ?
is there 'much' risk invovled trying the CROM method ?

UPDATE
just reread the info from OP..
CROM app (Chinese phones have this app to unlock their phones):
Result: This app communicates to Samsung servers and ends up writing a flag (kiwibird?) to STEADY partition. US phones dont have this partition so this currently wont work.
as active is a US based phone, i presume' it doesnt have such a partition either ?? how would we check ? in flashfire ?

UPDATE 2
well reading this post
https://xdaforums.com/s7-edge/samsu...ecovery-official-twrp-galaxy-s7-edge-t3458589
""You will need to unlock your bootloader now. To do this, download the app "CROM Service By Samsung Electronics Co., Ltd." from the Galaxy Apps store and run it.
Follow the instructions in the CROM Service app to allow your device to accept custom images in download mode.""
kinda shows that this WILL unlock the bootloader, so probably WILL work on our actives..
but then it will also trip KNOX too presumably...

UPDATE 3
what i really want to know, is how the TMO (t-mobile) boot.mg files seems to allow you to alter system files, but RETAIN DM-Verity !

US phones don't have a STEADY partition, but that's not the only problem. The Chinese bootloader checks for the kiwibird flag, the US versions don't. So even if you could add a steady partition with the flag kiwibird, the US bootloader would ignore that and continue as normal. Not sure if the active's bootloader ignores the flag too, but I would assume so.
EDIT: compared the emmc_appsboot.mbn in HxD and the Chinese file contains multiple entries with KIWIBIRD and the S7 active's file doesn't contain any. I've already tried replacing the active's emmc_appsboot.bin with the chinese one and flashing it, but it fails verification.

I haven't heard about Tmobile phones allowing you edit system files, but I do know that smaller carriers like Tmo and sprint typically allow phones to have unlocked bootloader, while bigger carriers almost always lock their devices (ATT & Verizon) So that may be the reason why Tmo users can change system files.

 

[miniminus]

yes it seems even thou hardware wise the chinese, and the US are the same, software wise they seem to differ, and are not compatible due to the chain of trust ! ...
i did try the CROM app, but it doesnt load properly, not sure if its suppose to have a menu system atall ??

yes it seems the tmobile boot.img, doesnt check system folder for dm-verity from what i can gather...
after WAY to many hours, as im still learning myself, found its that at the source ! as making a custom one for the active... sadly i cannot get to the specific place where this vulnerability/check is
but it is the source of all the 'roms' ,custom flashfire scripts, for debloating, adblocking via host file, custom roms, and differing system apps ..

sadly it seems its not something we can replicate for the active we can only customize the engineering.boot.img !
not sure how much we can mess with it ? could we some how edit it to behave the same as original ? is the whole boot.img hash checked ?
what i REALLY wanna find out is how they blocked the Gear VR on the active!!! its how i got to this point !

 

[XCnathan32]

yes it seems even thou hardware wise the chinese, and the US are the same, software wise they seem to differ, and are not compatible due to the chain of trust ! ...
i did try the CROM app, but it doesnt load properly, not sure if its suppose to have a menu system atall ??

yes it seems the tmobile boot.img, doesnt check system folder for dm-verity from what i can gather...
after WAY to many hours, as im still learning myself, found its that at the source ! as making a custom one for the active... sadly i cannot get to the specific place where this vulnerability/check is
but it is the source of all the 'roms' ,custom flashfire scripts, for debloating, adblocking via host file, custom roms, and differing system apps ..

sadly it seems its not something we can replicate for the active we can only customize the engineering.boot.img !
not sure how much we can mess with it ? could we some how edit it to behave the same as original ? is the whole boot.img hash checked ?
what i REALLY wanna find out is how they blocked the Gear VR on the active!!! its how i got to this point !

We can customize the engineering boot.img?? If we really can this could mean great things like overclocking and better performance, maybe even aosp... Are you sure we can edit the boot.img?

 

[miniminus]

we can already overclock etc and alter CPU/GPU/Temps, thats what the engineering boot interferes with and either gives loads of lag, or pants battery life..
why i was thinking as it lets system wide mods, could we use stock kernel? inside the eng. one so feels like stock, but with root, and dm-verity like s7.t-mobile boot.img ... so make our own hybride one ?
but i expect its hashed up and checked !

 

[XCnathan32]

we can already overclock etc and alter CPU/GPU/Temps, thats what the engineering boot interferes with and either gives loads of lag, or pants battery life..
why i was thinking as it lets system wide mods, could we use stock kernel? inside the eng. one so feels like stock, but with root, and dm-verity like s7.t-mobile boot.img ... so make our own hybride one ?
but i expect its hashed up and checked !

How'd you overclock yours? I couldn't figure out how to OC mine. I tried modifying the stock boot.img for root, but somehow the phone can tell it has been modified and it fails a security check.

 

[miniminus]

would have more luck 'trying' to modifying engboot.img, as that has less restriction imposed on it.....
messing around with clock, and governors, can be done by numerous apps, or maunually via scripts, like what is included in the 2.82 superSU installer root

 

[Delgoth]

Psa: for anyone still looking at the DD/Flashfire Chinese bootloader method, DO NOT TRY IT, I'm no developer by any means, but by looking at some threads, it appears many people think that the hard bricked device is caused by incorrect partition sizes, and while that may be a part of it. The (most likely) reason that the device is hard bricked is this: "We build our chain of trust according to this definition, starting with the first piece of immutable software running out of read-only-memory (ROM). This first ROM bootloader cryptographically verifies the signature of the next bootloader in the chain, then that bootloader cryptographically verifies the signature of the next software image or images, and so on." source So it looks like when the first bootloader running out of read only memory detects that the chinese flashed bootloader that was flashed has the wrong signature, it doesn't let that bootloader load, which results in no DL mode, no recovery, and an expensive paperweight. Any dev feel free to correct me if i'm wrong.

So, would it be possible to somehow copy the sig from the US S7 to the Chinese S7 BL and then flash it?
Or would it be possible to somehow mod the US BL to check for a flag (like the chinese BL) and unlock the BL if it detects the flag.
Also, how is it not possible to flash a boot.img that was repacked, even if it wasn't modded? How does the phone check for that, because the signature shouldn't be modified just by unpacking and repacking it, right?
The S7 active (which i have) still runs on the V2 BL, so if anyone knows if that could help active users achieve unlock in any way, please let me know.

Once again, i'm not a dev, but i'm willing to learn and help as much as I can, so if anyone could point me into the right direction, that would be greatly appreciated

What you can see quite quickly, The SM-G935F still runs on builds using the SW Rev 1 Bootloader. Hence the 1A, or 1B tag before the final build number. That is why that phone is fully rooted, and exactly how the carriers keep their branded phones from being transferred from carrier to carrier in the US. Our current Nougat and late MM bootloaders utilize the SW Revision 4 bootloader.

Through these different bootloader binary revisions, they change/update the master keystore partition on the Snapdragon S7/Edge devices. The Engineering Kernel (Read: Eng boot.img) does not enforce DM-Verity checking, in the same way that Passive SELinux does not enforce root permissions. So if the DM-Verity check fails at the AP/Rom/System level the bootloader has still maintained its integrity and will allow the modified system to boot using the "clean" bootloader.

That chain of trust you referred to, or the keystore of acceptable & flashable signatures, is kept in most likely in the "tzdata", "persistent", or "recovery" partition of the SD S7. We do not have a "STEADY" partition correct, but we do have a "persistent" partition that communicates with the Modem & RIL during boot. It also helps coordinate operations in DL Mode. I don't know how to dive deeper into the dumps of data that I do have with those.
Copying the signature from one boot.img to another one, is actually theoretically possible. But I have a strong feeling the Device Serial Number that is burned into the device, (the number you see when you press the home button instead of the volume up button at the first DL Mode screen.), Is somehow a part of the equation to verifying the bootloaders trust zone. But that has to be done using a customized build of the "mkbootimg" command line tool. If you want to repack the kernel you have to make sure your "mkbootimg" program is actually appending the signature when it compiles all the blobs.

The signature itself is appended on as the extra payload data that 7-Zip tells you about when extracting the ODIN .tar Package Files. Literally just extra bits of data added to the end of the archive that the bootloader knows where to look for. But The DM-Verity Signatures are made using a Hash Tree Data Structure. The correct way go about building such a tool for the S7 deals with modifying the way the LG's "EasyRecowvery" method, minus the dirty cow, looks into the hardware.

By the way, the current Nougat Eng Kernel's we have for the US Snapdragon S7, are signed with the Nougat 7.0 Test-Keys. Back in the days of the First Samsung Galaxy devices, the stock recovery shipping with Test-Key Signatures is what allowed us to bypass the signature verification of the sideloading zips.

******

i was going to post that exact thing about us active user's having bootloader version 2 like the Chinese models
and they talk of the CROM app that unlocks it ? but this is not discussed at length anywhere ?
did i read right that CROM, app was how they unlocked the S5 as thats still on v2 as well ?
is there 'much' risk invovled trying the CROM method ?

UPDATE
just reread the info from OP..
CROM app (Chinese phones have this app to unlock their phones):
Result: This app communicates to Samsung servers and ends up writing a flag (kiwibird?) to STEADY partition. US phones dont have this partition so this currently wont work.
as active is a US based phone, i presume' it doesnt have such a partition either ?? how would we check ? in flashfire ?

UPDATE 2
well reading this post
https://xdaforums.com/s7-...-edge-t3458589
""You will need to unlock your bootloader now. To do this, download the app "CROM Service By Samsung Electronics Co., Ltd." from the Galaxy Apps store and run it.
Follow the instructions in the CROM Service app to allow your device to accept custom images in download mode.""
kinda shows that this WILL unlock the bootloader, so probably WILL work on our actives..
but then it will also trip KNOX too presumably...

UPDATE 3
what i really want to know, is how the TMO (t-mobile) boot.mg files seems to allow you to alter system files, but RETAIN DM-Verity !

US phones don't have a STEADY partition, but that's not the only problem. The Chinese bootloader checks for the kiwibird flag, the US versions don't. So even if you could add a steady partition with the flag kiwibird, the US bootloader would ignore that and continue as normal. Not sure if the active's bootloader ignores the flag too, but I would assume so.
EDIT: compared the emmc_appsboot.mbn in HxD and the Chinese file contains multiple entries with KIWIBIRD and the S7 active's file doesn't contain any. I've already tried replacing the active's emmc_appsboot.bin with the Chinese one and flashing it, but it fails verification.

I haven't heard about Tmobile phones allowing you edit system files, but I do know that smaller carriers like Tmo and sprint typically allow phones to have unlocked bootloader, while bigger carriers almost always lock their devices (ATT & Verizon) So that may be the reason why Tmo users can change system files.

Like I mentioned above about the partitions we DO Have that are persistent, there may still be a way somewhere. Yes, maybe they've taken out their KIWIBIRD bird flag for bootloader unlocks, but that doesn't mean there isn't still something leftover from building the Chinese firmware. Being two software revisions back however, does make the chances a lot slimmer for the current US devices. But as you stated here in your "Update 2", CROM talks to the Radio Chip and Download Mode in order to allow the devices to keep custom software from ODIN.

I've been saying for 8 months, that the Modem and Download Mode are the two important keys to unlocking/rooting the newer Samsung Flagships. The Modem firmware is the ONE piece of software that gets root perms first during the boot process, and the Radio Interface Layer is what controls the persistent partitions of our SD Devices. The T-Mobile files allow you to make changes to the system partition just as the current ENG Kernel from AT&T does.

because the ENG Kernels do not enforce DM-Verity. They allow the device to still boot after the Verity verification fails in Recovery Mode. Once on the Eng Kernel, it's possible to use ADB Shell Root and mount all the partitions RW and dump them/modify them. Combination Factory Firmwares also allow this to happen. And the Exynos Variants of the Galaxy Lines, normally have ENG Sboot files available that give ADB Root in the absence of anything else.

Currently with the Galaxy S7/Edge the ENG Root method utilizes a leaked kernel from AT&T that is signed with signatures accepted by all of the devices in the line. AT&T used Test Keys to sign the image, that is why the other carrier branded devices can still flash it. Because it is signed with a google test key it seems. Or a samsung test key. And those are supposed to be publicly available at some places.

I also feel that it would be possible to use the ENG Kernel to do a full dump of a device running the same build as the January ENG Kernel in order to get enough code and services to re-engineer the ENG Kernel.

 

[XCnathan32]

Copying the signature from one boot.img to another one, is actually theoretically possible. But I have a strong feeling the Device Serial Number that is burned into the device, (the number you see when you press the home button instead of the volume up button at the first DL Mode screen.), Is somehow a part of the equation to verifying the bootloaders trust zone. But that has to be done using a customized build of the "mkbootimg" command line tool. If you want to repack the kernel you have to make sure your "mkbootimg" program is actually appending the signature when it compiles all the blobs.

The signature itself is appended on as the extra payload data that 7-Zip tells you about when extracting the ODIN .tar Package Files. Literally just extra bits of data added to the end of the archive that the bootloader knows where to look for. But The DM-Verity Signatures are made using a Hash Tree Data Structure. The correct way go about building such a tool for the S7 deals with modifying the way the LG's "EasyRecowvery" method, minus the dirty cow, looks into the hardware.

So would there be any way to somehow read those extra bits and append them onto a modified kernel tar? Sorry if that's a dumb question, but I do not understand crypto very well.

because the ENG Kernels do not enforce DM-Verity. They allow the device to still boot after the Verity verification fails in Recovery Mode. Once on the Eng Kernel, it's possible to use ADB Shell Root and mount all the partitions RW and dump them/modify them. Combination Factory Firmwares also allow this to happen. And the Exynos Variants of the Galaxy Lines, normally have ENG Sboot files available that give ADB Root in the absence of anything else.

So does that mean it would be possible to flash a custom recovery, or would the locked bootloader not allow the device to boot even with dm-verity disabled?

 

[Craz Basics]

The ENG boot doesn't disable signature check right? Only disables write protection to the system partition

 

[Delgoth]

(.1.)So would there be any way to somehow read those extra bits and append them onto a modified kernel tar? Sorry if that's a dumb question, but I do not understand crypto very well.

(.2.)So does that mean it would be possible to flash a custom recovery, or would the locked bootloader not allow the device to boot even with dm-verity disabled?

Re: #1 -- Yes, there are ways to read those bits of data. The question is though, which bits exactly, and at what time & context.
Re: #2 -- If you are talking about using a build of TWRP, more than likely not. Their Recovery system is just too different from Samsung's stock Recovery. That's not to say a Custom Recovery isn't possible though. People have gotten to used to just using TWRP anymore, we'd actually need here, a 'custom' Custom Recovery.

The ENG boot doesn't disable signature check right? Only disables write protection to the system partition

Both actually. It disables Write Protection to the System Partition (and all other partitions as well), by allowing the ADB Shell to run as root. But it does also disable the signature check of the system partition, by not enforcing DM-Verity Protocols on the System and initramfs partitions.

 

[Craz Basics]

Re: #1 -- Yes, there are ways to read those bits of data. The question is though, which bits exactly, and at what time & context.
Re: #2 -- If you are talking about using a build of TWRP, more than likely not. Their Recovery system is just too different from Samsung's stock Recovery. That's not to say a Custom Recovery isn't possible though. People have gotten to used to just using TWRP anymore, we'd actually need here, a 'custom' Custom Recovery.



Both actually. It disables Write Protection to the System Partition (and all other partitions as well), by allowing the ADB Shell to run as root. But it does also disable the signature check of the system partition, by not enforcing DM-Verity Protocols on the System and initramfs partitions.

Oh I gotcha. Thanks for clearing that up.

 

[XCnathan32]

Re: #2 -- If you are talking about using a build of TWRP, more than likely not. Their Recovery system is just too different from Samsung's stock Recovery. That's not to say a Custom Recovery isn't possible though. People have gotten to used to just using TWRP anymore, we'd actually need here, a 'custom' Custom Recovery.

So in theory, if we could build a custom recovery for the s7, it would work despite the chain of trust, sig checks, etc.
How would we go about building a custom recovery? Could we just modify the stock recovery to not check for signatures in flash ZIP from sd card?

Both actually. It disables Write Protection to the System Partition (and all other partitions as well), by allowing the ADB Shell to run as root. But it does also disable the signature check of the system partition, by not enforcing DM-Verity Protocols on the System and initramfs partitions.[/QUOTE]

So we can modify the ramdisk in the boot.img since dm verity is disabled? I'm fairly certain that contains a lot of settings we can tweak like overclocking (which personally I really want to get for this device)

 

[Delgoth]

This picture is taken from looking at a raw dump of the "sblapp" partition in the hex view of DiskInternal's "Linux Reader", it is also known as the 'Application Secondary Bootloader':


I see that there is still text included within the G935U Firmware's bootloader that references the KIWI(Bird) flag settable in the Chinese Snapdragon's Firmware.

 

[Bones519]

Feel free to disregard or delete this post if inappropriate. I am NOT a developer but I have been rooting and flashing for years and ended up disappointed with my s7 edge US unlocked version's inability to have the bootloader unlocked. I was googling and found this article for unlocking the bootloader and rooting verizon s7 and s7 edge... http://www.samsungsfour.com/tutoria...r-and-root-verizon-galaxy-s7-and-s7-edge.html
I thought that's what you were working on here. Has it already been done? And would it work not only for 930v and 935v, but also for the 935u? Am I missing something here? Or is this article incorrect?

 

[YMNDLZ]

Feel free to disregard or delete this post if inappropriate. I am NOT a developer but I have been rooting and flashing for years and ended up disappointed with my s7 edge US unlocked version's inability to have the bootloader unlocked. I was googling and found this article for unlocking the bootloader and rooting verizon s7 and s7 edge... http://www.samsungsfour.com/tutoria...r-and-root-verizon-galaxy-s7-and-s7-edge.html
I thought that's what you were working on here. Has it already been done? And would it work not only for 930v and 935v, but also for the 935u? Am I missing something here? Or is this article incorrect?

This doesn't unlock the bootloader, all it does is allow us to root. If you follow the guide on the site you'll be running the engboot we use to root, but if you try installing TWRP or flashing the Chinese Qualcomm bootloader it'll brick your phone and stop it from booting. Don't trust the titles on articles written on sketchy sites.