Database Users

Tab SBK burning logic in boot loader and other thoughts

After stupidly doing OTA update and getting SBK flashed on my tab I have been analyzing what how it happened. I figured I would put info here in hopes it might help someone else. Now this is basically my theories based on analysis of the bootloader code. I could be 150% wrong, Caveat emptor.
Useful resource was the Uboot git repository that has some Tegra 2 support:
git.denx.de/?p=u-boot.git;a=summary
Also Ac100 kernel tree gave some insight into fuse logic:
gitorious.org/ac100/kernel/trees/cd81507c9c1075b363f5af1222fa93deee09a13e/arch/arm/mach-tegra/include
Onto the boot loader itself. Even on the unlocked tablet (First thing I did is copied everything using nvflash) the bootloader has logic to burn the fuse settings from FOTA mode. There seem to be 3 modes:
1. Static Key hardcoded in the bootloader
2. Production key that is passed through some parameters area
3. Random key
Now if I am understanding the code right. If the last case is what is used then ultimate unlock does not seem likely as every unit would have its own key.
I am still hoping it is the case #2 that is usually used.
Another avenue of getting SBK I was thinking is getting an unlocked tab to get to fetch update but not let it install. If it is case #2 and key is shared by tablets this could be the way to get hands on it.

I spent some time looking into this a few months ago and came to more or less the same conclusion. My feeble attempt at throwing the bootloader into IDA didn't pan out, especially since I'm a tightass and was trying to trick the free version into letting me load it, and messing around in objdump got nowhere. There's a lot to be gathered from the strings and looking at the Android-side FOTA code though. It seems that one of the partitions (can't remember which) holds a structure used to send messages back to the bootloader, one of which can contain the SBK and other keys. However, some people managed to get their SBK burned by asking to be repartitioned in ODIN, so in that case either a random or predefined SBK must be used. I have my doubts that the FOTA mechanism is being used, and was likely left in for possible future use.
I am curious to see how options 1 & 3 are determined. One possibility is that the SBK may be hashed from the emmc's CID (a unique 128-bit key hardcoded into the onboard flash chip), as that's checked and printed early on in the serial output of the bootloader. (on the other hand, my GS2 does the same thing, it may just be force of habit for Sammy).
The SBK flash code in the bootloader appears to print the SBK to burn during the burning process. IF someone were to still have an unlocked tablet AND they were willing to lock it in the name of science, someone could capture the serial output during the process. One of four things will result: No useful output at all and the tab gets locked, an SBK is printed and it doesn't work on that tab, an SBK is printed and it works on that tab and no others, or an SBK is printed and it's valid for all tabs.
In all likelihood it is completely random. There are probably very few Tabs that come back to Sammy for service that validly need a complete reflash under warranty. In that case it would be most secure to lock the door and throw away the key, and just bite the bullet on the few boards that need to be trashed and replaced.

There seems to be a trigger file written to EFS partition with parameters of what to write to the fuse from a quick look at some strings.
On a separate note. I was thinking on how to tell which option Samsung chose. If the same version of boot loader in encrypted with the same key would it not result in the same encrypted partition? If so then collecting bootloader version with say first 32 bytes of encrypted partition from users should tell if same encryption key is used. Unless some sort of per machine is combined with SBK.

We know the encryption is AES, so it's symmetrical and therefore any keys won't be randomly salted. However, like you said it's likely that the encryption key includes the device serial number or something else that would keep partitions on identically keyed devices from matching. A quick test of this would be to compare bootloader partition dumps from two devices locked with the same SBK, i.e. two Transformers. What's important to realize is that the decryption of the bootloader is driven by firmware built into the Tegra2 that's identical for all chips, so what applies to one Tegra2 device applies to the rest.

[Q] N7 APX mode only - full recovery?

Hi all,
Has anyone followed Rayman's excellent article the-inner-workings-of-secure-boot-key-and-nvflash and fully recovered a N7 from APX only mode?
I have this situation which I think resulted from the battery dying during the 4.4.2 update - Doh I know, but thought I had enough juice to complete the update.
Rayman says the required files will be made available but I cannot find them anywhere

Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.

Erovia said:
Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.
Click to expand...
Click to collapse
Did you read the article? Sounds like you can use the sbk which is a hash of the cpuid...

Nope, but why don't you ask around in the flatline topic?

Erovia said:
Nope, but why don't you ask around in the flatline topic?
Click to expand...
Click to collapse
too much of a noob to post on the forum, but thanks for the pointer.
FYI Raymans article. It does sound possible to bring it back, but there was no follow up with the required files;
What is Secure Boot Key and how does it work?
I've been getting lots of questions about this, so here is some simple background:
The secure boot key is an AES128 encryption key that can used to encrypt various data on the flash memory. It's a generic nvidia tegra2 thing, that the manufacturer can optionally use to make their device more "secure".
When the SBK is set, it's stored in a one-time-programmable "fuse". This also means that now that the key is out, they can't change it on already released devices, only new devices.
When the tegra2 starts up, the AES key is available to the hardware AES engine only. E.g. not even the bootloader can read it back! However, the bootloader can *use* the key to encrypt whatever data it wants through the hardware AES engine. And here is the explanation why the blob flashing method actually works! The bootloader checks for the blob in the staging partition and encrypts and flashes it as needed.
Once the bootloader is done, it clear the key from the AES engine which makes it impossible to encrypt or decrypt things from within the OS.
So what happens when it boots into APX/Nvflash mode?
The basic APX mode is stored in the BootROM and hence can never be changed. It appears to accept only a very limited range of commands, and each command needs to be encrypted using the SBK to be accepted. If it receives a command that's not properly encrypted, it disconnects the USB and appears to be off. This is the dreaded "0x4" error that people have been getting when attempting to get nvflash working.
It should be noted, that even with the SBK inputted into nvflash, most regular nvflash commands won't be available. I'm still not entirely sure why (and I can't rule out it will change).
What *is* available, is the nvflash --create command. What this command does is repartition and format all partitions, set bct and odmdata and send over all needed partitions to the device (and encrypt them as needed). This means a full recovery is possible, but regular ability to flash e.g. just boot.img or read partitions off of the device is not possible at this point.
So what do we need for nvflash?
In order to get a working (e.g. --create) nvflash, we need a few bits of information as well as some files:
◦Secure Boot Key
◦BCT file (boot device setup, ram configuration and a bit more)
◦ODM data (board-specific bit-field specifying various board settings. *Needs* to be correct
◦flash.cfg (e.g. list of settings and names/identifiers of partitions.
On top of these files, we also need all the partitions, e.g. bootloader.bin, boot.img, recovery.img and system.img. Luckily, these partition files are available in official ASUS updates and can be extracted from the blob file using my blob tools
The first four peices aren't readily available, but through lots of effort and a good deal of luck, we have managed to recreate the needed files. Secure Boot Key has already been released (note that this was by far the hardest!) and the rest will most likely follow over the weekend. Keep in mind that we want to keep this legal, so don't expect us to release any ready-made packs for unbricking! We will however make the recreated files available. Since these are recreated and not actual ASUS files, there should be no problems with them.
I hope this helps give a better understanding of how and what secure boot key is and what it gives us.

[DEV] LG G5 VS987 bootloader unlock

LG G5 VERIZON VS987
Unofficial bootloader unlock
In-Progress
This is a project to disassemble and rebuild an unlocked aboot that passes the sbl loader test, thus allowing installation of custom kernels, read/write access to system, TWRP recovery, and custom ROMs. You can follow the progress or ask questions about it here, or offer your help to make my life a little easier. Donations help, too, especially to maintain the machine these VMs and tools run on.
PHASE 1 - RAMDISK EXTRACTION: DONE
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
PHASE 3 - CERTIFICATE EXTRACTION: IN-PROGRESS
Extracting and parsing the PCS data. It's needed for verification by the sbl to avoid security fail when booting a modified aboot.
PHASE 4 - UNLOCKING NEEDS DONE
Re-coding aboot to accept a bootloader unlock, and access to fastboot.
PHASE 5 - RECOMPILATION AND TESTING (ABOOT)NEEDS DONE
Re-building the aboot binary and testing it.
PHASE 5 - LITTLEKERNEL AND SYSTEM ACCESS (BOOT)NEEDS DONE
Puling apart stock kernel, grabbing needed modules, disabling SELinux and dmverify.
Analysing system image, removing boot-time LG security checks, applying root.
PHASE 6 - TWRP BUILD (RECOVERY) NEEDS DONE
Building user-friendly recovery image.
PHASE 7 - BUILD TOT FILE NEEDS DONE
Package it all into an LGUp Flashable TOT and release.
If you would like to help with this project, please make yourself known.
If you would like to donate to show thanks, the button is underneath my name or in my profile.
If you have a comment or can leave documentation or advice, do so below ​

Nice.. Hoping for the best

LupineDream said:
LG G5 VERIZON VS987
Unofficial bootloader unlock
In-Progress
This is a project to disassemble and rebuild an unlocked aboot that passes the sbl loader test, thus allowing installation of custom kernels, read/write access to system, TWRP recovery, and custom ROMs. You can follow the progress or ask questions about it here, or offer your help to make my life a little easier. Donations help, too, especially to maintain the machine these VMs and tools run on.
PHASE 1 - RAMDISK EXTRACTION: DONE
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
View attachment 4016279
View attachment 4016280
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
View attachment 4016278
PHASE 3 - CERTIFICATE EXTRACTION: IN-PROGRESS
Extracting and parsing the PCS data. It's needed for verification by the sbl to avoid security fail when booting a modified aboot.
PHASE 4 - UNLOCKING NEEDS DONE
Re-coding aboot to accept a bootloader unlock, and access to fastboot.
PHASE 5 - RECOMPILATION AND TESTING (ABOOT)NEEDS DONE
Re-building the aboot binary and testing it.
PHASE 5 - LITTLEKERNEL AND SYSTEM ACCESS (BOOT)NEEDS DONE
Puling apart stock kernel, grabbing needed modules, disabling SELinux and dmverify.
Analysing system image, removing boot-time LG security checks, applying root.
PHASE 6 - TWRP BUILD (RECOVERY) NEEDS DONE
Building user-friendly recovery image.
PHASE 7 - BUILD TOT FILE NEEDS DONE
Package it all into an LGUp Flashable TOT and release.
If you would like to help with this project, please make yourself known.
If you would like to donate to show thanks, the button is underneath my name or in my profile.
If you have a comment or can leave documentation or advice, do so below ​
Click to expand...
Click to collapse
Nice to know there is people working on an unofficial bootloader unlock for the lg g5 good job !
I would also like to ask a question if you don't mind : once done, does this variant of the g5 is similar enough to some variants to be able to "port" the unlock or the approach is too specific to the variant ?

Im currently grabbing a more android build-friendly release of Xenial. Google does not support building from a x86 OS. When I tried to git the "official" google toolchain in consideration of doing things 100% correct in a VM, I ran into the dreaded "x86 build host unsupported" problem. The VM host I am grabbing is here: https://forum.xda-developers.com/chef-central/android/guide-how-to-setup-ubuntu-16-04-lts-t3363669 I am going to need the google build source for the kernel, plus the makefiles for the generic arm v7a neon arcitecture. Best do it all the right way instead of having to re-do it all later.
In the meantime, I am cramming some thumb-2 tutorials. La la la~

nalf3in said:
Nice to know there is people working on an unofficial bootloader unlock for the lg g5 good job !
I would also like to ask a question if you don't mind : once done, does this variant of the g5 is similar enough to some variants to be able to "port" the unlock or the approach is too specific to the variant ?
Click to expand...
Click to collapse
I'd have to check the aboot and boot / kernel to see if there's any major differences. Since this is a direct aboot disassembly, it's varient specific, but I will surely be checking if the approach can be applied to different varients' booters via scripting or some such thing. It would mean coding of a patchfile and a TOT builder, adding an entire extra level of complexity, but I'll get to your answer as soon as I have finished with this model.

Howdy there,
Looks like you're attempting to modify an element in the Qualcomm Secure Boot chain (aboot in this case) - unfortunately what you're trying to do won't work.
I don't want to rain on your parade here, or discourage you from learning something for the sake of learning it but simply modifying a component of the boot stack by recompiling it and slapping the same signatures on it isn't possible.
I'd recommend you take a look at any of the awesome posts on XDA about how the Secure Boot 3 (is there a newer version?) process works as you'll see that each step in the boot process (pbl -> xbl -> {tz, rpm} -> aboot) is verified using RSA public/private key signatures.
You won't be able to simply extract the certificate chain from the old aboot (LK) image and append it to your source-built LK, as the hash embedded in the certificate chain won't match the computed hash of the LK application.
Your next thought would be "what if I could find where the validation function is called and replace it?", but you'll find that each step in the boot process calls TrustZone's secureboot verification functions which rely on data stored in qFuses.
Even then, the function TrustZone itself calls is actually provided by PBL and is burned into the chip itself.
Essentially, the path you're trying to take is one that Qualcomm has thoroughly hardened the boot process to protect against.
I'm not trying to discourage you from learning, since doing this sort of reverse engineering is very fascinating and a fun learning exercise - I just want to let you know that if you try to flash a modified aboot image that you'll end up with a brick (and no way that I'm aware of to recover short of soldering up some UFS lines and reflashing like that since iirc even JTAG is disabled now and we lack signed programmers for USB recovery).
Check out one of the Secure Boot PDFs that are available on Google/XDA and you should see what I mean.
Best of luck to you, and happy learning!

LupineDream said:
(Attachment 2 & 3): I have extracted the ramdisks from the KDZ bin data. I have the ramdisks and accompneying kernel files in tar files.
View attachment 4016279
View attachment 4016280
PHASE 2 - TARGET DISASSEMBLY: DONE
(Attachment 1): I have disassembled the ELF binaries. objdump is sloppy, but I was able to get to the branch instructions and find my offsets for each subroutine. I also located the factory signature data for verification by sbl.
View attachment 4016278
Click to expand...
Click to collapse
Like thecubed said, by flashing a modified aboot you'll brick the device, but the fact that you figured out how to extract the aboot image is EXTREMELY impressive! If you wouldn't mind it would be very helpful if you make a guide on how you did that or if you could post your extracted aboot files that would be much much appreciated An insight on how aboot for the G5 works would be something very nice to have

thecubed said:
Howdy there,
Looks like you're attempting to modify an element in the Qualcomm Secure Boot chain (aboot in this case) - unfortunately what you're trying to do won't work.
I don't want to rain on your parade here, or discourage you from learning something for the sake of learning it but simply modifying a component of the boot stack by recompiling it and slapping the same signatures on it isn't possible.
...
[ removed in quote ]
...
Best of luck to you, and happy learning!
Click to expand...
Click to collapse
Thank you for the inspiration. The task has been a thorough crash-course in arm v7a NEON Cortex technology and thumb-2 assembler. I was concerned when I saw the TrustZone documentation from ARM and the ACEP (Arbitrary Code Execution Prevention) stack. Your mention of qfuse brings back memories of the Samsung "Golden Routines" folly.
Unfortunetly I wasn't a backer of the Raspberry PI, but there are other PCBs with GPIO pins. My reason for mention this is the JTAG connundrum you mentioned. It is null and void to a soldering gun, a few resisters ($2-$3, and the on-chip ARM debugging interface included in most integrated ARM chipsets. PCBs that run Linux with a GPIO pin array are the cheapest and most flexable solution to an expensive piece of lab / R & D equipment (JTAG), and the impact on the bank account is a fraction of what it would cost the end-consumer.
Hash collisions and backprop neural nets. What? OK, I'll explain. Most reverse engineering begins with monitoring the usual operation of the device as you are aware. Approach 1 involves training a backpropping neural network to recognize (within a reasonably less amount of computation) a hash collision. Of course, you aren't going to be getting to these pre-coded hashes without breaking the RSA chain (thats 100 zeros O__O ) , this is fixed by monitoring the debug interface we both mentioned earlier, at power-on. ARM processors work such that they cannot do DMAC (direct memory access computation), so the values need to be pushed into registers and acted on as plain byte, then pushed back to memory. Sniff, find out what's coming to/from the qfuse memory bus area into registers, dump the data, and you'll have your root CA with luck. You'll be looking for the in operand, that is, the one that is to be acted on in the cipher that is incoming from qfuse. Cycle-timing to ignore the rest of the computations for this byte, you're basically waiting until qfuse pushes the next byte of its keys into a register and grabbing it in the same cycle the instruction is working on it.
That said, with a $100 and a soldering gun and a laptop, you have your RSA key direct from CPU memory via the debug interface. After you've got your root CA, would it be feasable to start decrypting the intermediate CA chain for each component of boot until you get the hash? In theory this should work without brute-force, but a lot of time in a code window and with an oscilliscope. Once you've had the decrypted hash, you can begin to look for a hash collision. There are open source tools that will find hash collisions in an hour or less using neural nets. Write an aboot that complies to this hash collision, flash it, and qfuse will not be able to tell the difference.
Thats my theory on exploiting the fact ARM needs to do its computations in an area that is accessable to the debug interface. Of course my theory falls apart if the TrustZone chipset has its own processor.
Honestly Annoying said:
Like thecubed said, by flashing a modified aboot you'll brick the device, but the fact that you figured out how to extract the aboot image is EXTREMELY impressive! If you wouldn't mind it would be very helpful if you make a guide on how you did that or if you could post your extracted aboot files that would be much much appreciated An insight on how aboot for the G5 works would be something very nice to have
Click to expand...
Click to collapse
I'd be okay with writing such guide as long as it followed community guidelines. I should not be posting disassembled code and analysis if it's against the rules to do so. If a mod could clear this for me....

After searching around I located the true specs for the G5. It's a Snapdragon 820 SoC. It runs the new ARM v8A instruction set.
More detailed information here -> http://www.tomshardware.com/reviews/snapdragon-820-performance-preview,4389-2.html.
More specifically, it's on the msm8996 platform: http://system-on-a-chip.specout.com/l/1170/Qualcomm-Snapdragon-820-MSM8996
Phones with this arcitechture: https://www.kimovil.com/en/list-smartphones-by-processor/qualcomm-snapdragon-820-msm8996
Xiaomi Mi5 has official bootloader unlock via a tool (reverse engineer to work with our platform?)
HTC 10 bootloader on certain models can be oem-unlocked.
Lenovo ZUK Z2 bootloader can be oem-unlocked
LG V20 bootloader can be oem-unlocked, and is the closest in hardware to our G5!
Perhaps stealing a kernel and boot from a similar varient that allows it, signing it with our key, hash-matching it? It all runs on the same platform with the same instruction set. Most of these phones have unlockable bootloaders.
I'd say the best target would be that unlock tool by Xaoimi. Its usually the third party vendor's tools you can find the biggest security holes in. xD From their documentation, it isn't an "enable OEM unlock" switch in Developer Options used to enable the unlock, the tool itself actually works on the bootloader. Perhaps the tool uses a feature of the MSM8996 we aren't aware of. It's worth looking into.

LupineDream said:
Thank you for the inspiration. The task has been a thorough crash-course in arm v7a NEON Cortex technology and thumb-2 assembler. I was concerned when I saw the TrustZone documentation from ARM and the ACEP (Arbitrary Code Execution Prevention) stack. Your mention of qfuse brings back memories of the Samsung "Golden Routines" folly.
Unfortunetly I wasn't a backer of the Raspberry PI, but there are other PCBs with GPIO pins. My reason for mention this is the JTAG connundrum you mentioned. It is null and void to a soldering gun, a few resisters ($2-$3, and the on-chip ARM debugging interface included in most integrated ARM chipsets. PCBs that run Linux with a GPIO pin array are the cheapest and most flexable solution to an expensive piece of lab / R & D equipment (JTAG), and the impact on the bank account is a fraction of what it would cost the end-consumer.
Hash collisions and backprop neural nets. What? OK, I'll explain. Most reverse engineering begins with monitoring the usual operation of the device as you are aware. Approach 1 involves training a backpropping neural network to recognize (within a reasonably less amount of computation) a hash collision. Of course, you aren't going to be getting to these pre-coded hashes without breaking the RSA chain (thats 100 zeros O__O ) , this is fixed by monitoring the debug interface we both mentioned earlier, at power-on. ARM processors work such that they cannot do DMAC (direct memory access computation), so the values need to be pushed into registers and acted on as plain byte, then pushed back to memory. Sniff, find out what's coming to/from the qfuse memory bus area into registers, dump the data, and you'll have your root CA with luck. You'll be looking for the in operand, that is, the one that is to be acted on in the cipher that is incoming from qfuse. Cycle-timing to ignore the rest of the computations for this byte, you're basically waiting until qfuse pushes the next byte of its keys into a register and grabbing it in the same cycle the instruction is working on it.
That said, with a $100 and a soldering gun and a laptop, you have your RSA key direct from CPU memory via the debug interface. After you've got your root CA, would it be feasable to start decrypting the intermediate CA chain for each component of boot until you get the hash? In theory this should work without brute-force, but a lot of time in a code window and with an oscilliscope. Once you've had the decrypted hash, you can begin to look for a hash collision. There are open source tools that will find hash collisions in an hour or less using neural nets. Write an aboot that complies to this hash collision, flash it, and qfuse will not be able to tell the difference.
Thats my theory on exploiting the fact ARM needs to do its computations in an area that is accessable to the debug interface. Of course my theory falls apart if the TrustZone chipset has its own processor.
I'd be okay with writing such guide as long as it followed community guidelines. I should not be posting disassembled code and analysis if it's against the rules to do so. If a mod could clear this for me....
Click to expand...
Click to collapse
Hello again!
Regarding your points:
JTAG is disabled on most production devices, as in 100% inoperable. No amount of soldering will enable it. I'm sure there are some exceptions to the rule, but in this case I'm fairly confident in saying that the JTAG interface on the G5 is unusable.
...even if JTAG was enabled, the Qualcomm Secure Boot stack is designed to protect itself from the exact type of attack you're describing here. The component of TrustZone that is doing the verification of boot images is not running in anything that is JTAG-accessible, and to my understanding it's not even running in the main ARM core.
Re: hash collisions and neural nets... What you're describing sounds neat in theory, but in application (again, to my knowledge) won't work. I suggest you read up on how RSA works.
RSA is public/private key cryptography - in this case, the certificates contained on the phone are the public component, and LG/Qualcomm are the only ones with the private component. "Extracting the CA" will yield the public portion that is only useful for verifying signatures, not signing them.
The only way you'd be able to sign anything and have the phone trust it is to either a) replace the CA on the phone (not possible, it's burned into qFuses) or b) obtain the private component of the CA or any of it's subsidiaries (also burned into qFuses)
CA chains aren't encrypted, they're just a list of things that the device will accept a signature for. In our case it's Qualcomm as the Root CA, then LG as an intermediate (and possibly a few other intermediates to allow OTA updates to come from differing builders/engineering teams within LG). Again, extracting the 'hash' of a CA will do no good here, as there's no meaningful collisions that can be generated and still be a valid boot image. I'm not the best person to explain RSA in depth, so I'd really recommend doing some further research on it.
LupineDream said:
After searching around I located the true specs for the G5. It's a Snapdragon 820 SoC. It runs the new ARM v8A instruction set.
More detailed information here -> http://www.tomshardware.com/reviews/snapdragon-820-performance-preview,4389-2.html.
More specifically, it's on the msm8996 platform: http://system-on-a-chip.specout.com/l/1170/Qualcomm-Snapdragon-820-MSM8996
Phones with this arcitechture: https://www.kimovil.com/en/list-smartphones-by-processor/qualcomm-snapdragon-820-msm8996
Xiaomi Mi5 has official bootloader unlock via a tool (reverse engineer to work with our platform?)
HTC 10 bootloader on certain models can be oem-unlocked.
Lenovo ZUK Z2 bootloader can be oem-unlocked
LG V20 bootloader can be oem-unlocked, and is the closest in hardware to our G5!
Perhaps stealing a kernel and boot from a similar varient that allows it, signing it with our key, hash-matching it? It all runs on the same platform with the same instruction set. Most of these phones have unlockable bootloaders.
I'd say the best target would be that unlock tool by Xaoimi. Its usually the third party vendor's tools you can find the biggest security holes in. xD From their documentation, it isn't an "enable OEM unlock" switch in Developer Options used to enable the unlock, the tool itself actually works on the bootloader. Perhaps the tool uses a feature of the MSM8996 we aren't aware of. It's worth looking into.
Click to expand...
Click to collapse
Bootloaders for other phones will not work on our phone, as of course it'll fail the Secure Boot check.
Bootloader unlock tools for other phones will not work because they're relying on manufacturer specific unlock code that's compiled into aboot (LK). Qualcomm's CAF version of LK doesn't include any unlock code checking functionality, so most manufacturers add that themselves.
LG, in this case, is not even including the code for a bootloader unlock in the US model bootloaders. If you're familiar with C, essentially LG has `#ifdef`'d the entire section of code out (including fastboot).
The V20 bootloader does indeed contain oem-unlock code, but Secure Boot will prevent you from flashing the V20's bootloader (even if it magically was code-compatible with the G5) because Secure Boot checks the hardware ID that's burned into qFuses.
This means, to add a bootloader unlock, you'd have to modify aboot, which can't be done because of Secure Boot. Secure Boot components can't be modified because of RSA, and the RSA verification can't be altered because the keys are burned into qFuses.

thecubed said:
Hello again!
Regarding your points:
JTAG is disabled on most production devices, as in 100% inoperable. No amount of soldering will enable it. I'm sure there are some exceptions to the rule, but in this case I'm fairly confident in saying that the JTAG interface on the G5 is unusable.
...even if JTAG was enabled, the Qualcomm Secure Boot stack is designed to protect itself from the exact type of attack you're describing here. The component of TrustZone that is doing the verification of boot images is not running in anything that is JTAG-accessible, and to my understanding it's not even running in the main ARM core.
Re: hash collisions and neural nets... What you're describing sounds neat in theory, but in application (again, to my knowledge) won't work. I suggest you read up on how RSA works.
RSA is public/private key cryptography - in this case, the certificates contained on the phone are the public component, and LG/Qualcomm are the only ones with the private component. "Extracting the CA" will yield the public portion that is only useful for verifying signatures, not signing them.
The only way you'd be able to sign anything and have the phone trust it is to either a) replace the CA on the phone (not possible, it's burned into qFuses) or b) obtain the private component of the CA or any of it's subsidiaries (also burned into qFuses)
CA chains aren't encrypted, they're just a list of things that the device will accept a signature for. In our case it's Qualcomm as the Root CA, then LG as an intermediate (and possibly a few other intermediates to allow OTA updates to come from differing builders/engineering teams within LG). Again, extracting the 'hash' of a CA will do no good here, as there's no meaningful collisions that can be generated and still be a valid boot image. I'm not the best person to explain RSA in depth, so I'd really recommend doing some further research on it.
Bootloaders for other phones will not work on our phone, as of course it'll fail the Secure Boot check.
Bootloader unlock tools for other phones will not work because they're relying on manufacturer specific unlock code that's compiled into aboot (LK). Qualcomm's CAF version of LK doesn't include any unlock code checking functionality, so most manufacturers add that themselves.
LG, in this case, is not even including the code for a bootloader unlock in the US model bootloaders. If you're familiar with C, essentially LG has `#ifdef`'d the entire section of code out (including fastboot).
The V20 bootloader does indeed contain oem-unlock code, but Secure Boot will prevent you from flashing the V20's bootloader (even if it magically was code-compatible with the G5) because Secure Boot checks the hardware ID that's burned into qFuses.
This means, to add a bootloader unlock, you'd have to modify aboot, which can't be done because of Secure Boot. Secure Boot components can't be modified because of RSA, and the RSA verification can't be altered because the keys are burned into qFuses.
Click to expand...
Click to collapse
So in this case, what would be the next image in the stack that would allow any kind of modifications? Should I be looking at boot.img instead? Would there be a method of tricking the signed and secure boot chain into believing what it sees isn't executing as root?
had been looking through some old methods of root, like causing a boot error by zeroing laf or flashing over it, causing the bootloader to drop you into fastboot, booted securely from there you could call a kcal perameter of the stock kernel that allowed a sort of debugging mode with systemwide root. That exploit was in the G2 era, and how that device obtained root.
I've seen a method that causes Knox to lock up on some Samsung devices by overloading its memory addresses or repeatedly zeroing certain bits of RAM.
I'd really need to find out what method works. If you can't make any modification, maybe there's a workaround to make it THINK everything is legit beyond the boot chain.

aboot decription
Ok I have been working on an lg g5 vs987 myself and I got to the recoding the aboot part and was totally lost its all encrypted and I have no idea where to start to even see what the code is really saying I am new to this website and I am also new to coding on android if you can guide me in the right direction I might be able to help. I have always dreamed of being a part of a development like this and now I might have a shot. Thank you so much for your work and I hope to hear from you soon!

alphawolves said:
Ok I have been working on an lg g5 vs987 myself and I got to the recoding the aboot part and was totally lost its all encrypted and I have no idea where to start to even see what the code is really saying I am new to this website and I am also new to coding on android if you can guide me in the right direction I might be able to help. I have always dreamed of being a part of a development like this and now I might have a shot. Thank you so much for your work and I hope to hear from you soon!
Click to expand...
Click to collapse
Dissembling and recoding aboot wont work no matter even if it is not encrypted..
It is already mentioned above by @thecubed ..
The secure boot will always verify the signature and dissassembly will generate no signature.
We need to find the private keys used for generating the public hash.. but that is not possible unless leaked from lg which is also very unlikely..
What a hacker can do is find a bug/vulnerability in aboot that can bypass secureboot..or a hardware loophole..
Plus there is a trustzone that itself secures the secureboot process.. so we have to find ways to exploit the bootchain so that we can somehow make the bootloader load unsigned ramdisks/recovery and such..
experienced people could do it.. but i guess there has been a lot of fuss between devs and wannabees..
Also if we can get debug build of aboot/ramdisk we can flash them to get unlock or at the very least root..
I am not expert on this but that how its simply put

A brave member sent me a very useful PDF specification on the TSF. The TSF is the official name for the portion of the integrated circuitry that controls the storage of the secure boot chain. The hardware routines are there to allow root to happen, but as stated before by @thecubed, LG commented out the entire section of a boot at compile time that allows anything to occur. Now the approach is to disassemble HOW the code that LG commented out works in the international variant that has an OEM unlock. Hardware routines exist that place the TSF into non-commercial mode, disabling functionality of certain enterprise software and deauth-ing the root CA in qfuse, allowing the user to flash their own signing certificates to the TSF (TrustZone) when a request to switch off CC mode is sent. There are all kinds of virtual memory protections, ACE protections, malicious code protections, and other things that the TSF handles. Trying any kind of unauthorised write to protected areas of memory results in blow of qfuse write fuse. It's actually a physical microscopic fuse that when pushed a specific voltage pops at a microscopic level kind of like a big fuse blowing only at a very tiny level. At this point write access anywhere is gone. This happens at the same time a full wipe of the system happens. That is why they say once qfuse blows your phone becomes a very expensive cup holder. Because after the qfuse blows there is no way of software recovery.
The only way to be able to disable commercial (CC mode) and be allowed to do anything to put your own boot chain in is to place the device in debug mode. The international varient contains code how to accomplish this, our devices don't. You would need to compile an app that runs in normal mode, causes a flag to be set that places the device into debug mode, then reboot. While in debug boot, you should be able to execute a CC unlock manually. The PDF I got says it's very specifically timed when this can happen, what parts of boot the TSF allows it to happen, and a rough explanation if what disabling CC mode means. The only way of getting root is to use the TSF-approved method but all this code is removed. The TSF does not stop you from executing code if booted into factory debug mode. The new approach I propose is to find an exploit to get into userdebug, and manually write an unlock routine with disassembled information from the international varient., pushing it directly into execution memory while in userdebug, being absolutely sure to give the TSF what it asks for, when it asks for it, at the exact timing for it.

LupineDream said:
A brave member sent me a very useful PDF specification on the TSF. The TSF is the official name for the portion of the integrated circuitry that controls the storage of the secure boot chain. The hardware routines are there to allow root to happen, but as stated before by @thecubed, LG commented out the entire section of a boot at compile time that allows anything to occur. Now the approach is to disassemble HOW the code that LG commented out works in the international variant that has an OEM unlock. Hardware routines exist that place the TSF into non-commercial mode, disabling functionality of certain enterprise software and deauth-ing the root CA in qfuse, allowing the user to flash their own signing certificates to the TSF (TrustZone) when a request to switch off CC mode is sent. There are all kinds of virtual memory protections, ACE protections, malicious code protections, and other things that the TSF handles. Trying any kind of unauthorised write to protected areas of memory results in blow of qfuse write fuse. It's actually a physical microscopic fuse that when pushed a specific voltage pops at a microscopic level kind of like a big fuse blowing only at a very tiny level. At this point write access anywhere is gone. This happens at the same time a full wipe of the system happens. That is why they say once qfuse blows your phone becomes a very expensive cup holder. Because after the qfuse blows there is no way of software recovery.
The only way to be able to disable commercial (CC mode) and be allowed to do anything to put your own boot chain in is to place the device in debug mode. The international varient contains code how to accomplish this, our devices don't. You would need to compile an app that runs in normal mode, causes a flag to be set that places the device into debug mode, then reboot. While in debug boot, you should be able to execute a CC unlock manually. The PDF I got says it's very specifically timed when this can happen, what parts of boot the TSF allows it to happen, and a rough explanation if what disabling CC mode means. The only way of getting root is to use the TSF-approved method but all this code is removed. The TSF does not stop you from executing code if booted into factory debug mode. The new approach I propose is to find an exploit to get into userdebug, and manually write an unlock routine with disassembled information from the international varient., pushing it directly into execution memory while in userdebug, being absolutely sure to give the TSF what it asks for, when it asks for it, at the exact timing for it.
Click to expand...
Click to collapse
Thanks for that post @LupineDream ! I unfortunately doesn't understand most of the things you explained but perhaps I can save you a bit of time (your last post looks like you aren't aware of that exploit but thats maybe only me misundertanding) ; as far as I know the adb root method develloped by @HonestlyAnnoying include a userdebug kernel so (afaik) we already know an exploit to get into userdebug on marshmallow(dirty santa) and the fact that the users needs to run marshmallow shouldn't matter as (afaik) once the bootloader unlocked, the userdebug kernel is no longer needed and it is possible to change it.
Edit: just saw your post on the adb root thread, so I guess you are now aware of the exploit Sorry for the post, I just wanted to be sure you didn't missed it.

nalf3in said:
Thanks for that post @LupineDream ! I unfortunately doesn't understand most of the things you explained but perhaps I can save you a bit of time (your last post looks like you aren't aware of that exploit but thats maybe only me misundertanding) ; as far as I know the adb root method develloped by @HonestlyAnnoying include a userdebug kernel so (afaik) we already know an exploit to get into userdebug on marshmallow(dirty santa) and the fact that the users needs to run marshmallow shouldn't matter as (afaik) once the bootloader unlocked, the userdebug kernel is no longer needed and it is possible to change it.
Edit: just saw your post on the adb root thread, so I guess you are now aware of the exploit Sorry for the post, I just wanted to be sure you didn't missed the exploit.
Click to expand...
Click to collapse
Yes thank you for affirming that, but not to worry, I got it. LG has an sbl module called anti-rollback that prevents flashing older software. If we look at the boot chain:
Code:
recovery
| /------------------ laf (fastboot)
__________________|__|_________________________________________ laf (security fail screen)
/ / / /
pbl -> sbl > aboot > boot (kernel/ramdisk) > system
^ ^
| |
| \-- IS_UNLOCKED and sig_Check()
Anti-rollback
I beleive anti-rollback was updated to a new version that prevents this on Nugout. Correct me if I'm wrong. I've tried every LG hidden menu code I could find to see, but can't even seem to get the hidden menu working... And the reason they did this is because of the worldwide alerts about dirtycow, which affects not only Android, but the whole of Linux, so we need a nogout kernel. A marshmallow kernel with the new anti-rollback would theoretically end up in the red triangle of death.
We need someone that has an engineering model with a userdebug kernel. LG makes you apply. Their program is called "LG GATE", and they are very picky. I think that's what helped out the Sprint community. Someone got a hold of a developer / engineering model with a marshmallow kernel.

Well, I already heard of that strange issue with the hidden menu and I always though it was a code 18 but after googling, it looks like it some carrier potentially disabled it.. Anyway, I can confirm you that the anti-rollback version is still 0 on my h831 running the latest nougat unless the hidden menu is "lying". (And most variant I know except sprint, which did triggered the counter with the update, stayed at their rollback version). I still encounter the same issues most people on nougat experienced with the adb root (wasn't able to get past reboot and needed to flash with uppercut a fresh 7.0 ) so I guess the issue is somewhere else.
Also, if you need any information that is on the hidden menu, feel free to ask me
http://m.imgur.com/gallery/fTwgSUF

Very exciting, gl

finally they are working on it

What about this line in the aboot.bin
(from canadian aboot)
LOAD:0F960100 aBootVerificati DCB " : boot verification skip ",0xA,0
Is there any way to disable boot verification? no need to go with full bootloader unlock.. if it's possible to just disable boot verification, right?

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

Models: SM-G930_, SM-G935_ (Flat & Edge, all Snapdragon variants, NOT Exynos)
Developer thread only!
Work in Progress!
DONT flash anything on your phone unless you either a)Dont care of the result or b)Know what you're doing! I will take NO RESPONSIBILITY for you breaking your phone! Know the risks!
Research & Development Thread for Unlocking S7 bootloader
What is this thread?
This is a thread with all information (research) I can find regarding the locked bootloader for the S7 Snapdragon (Exynos has been unlocked so this thread will NOT cover that.) There are a lot of great seasoned Devs out there, but it seems all have given up, or remained in the dark. Flagships like the S7 we all bought because they're amazing phones, but it appears the future is locked bootloaders; if you're here then you're interested in custom ROMs. If we give up and can't 'crack this', then I'm afraid amazing phones like this will never get custom ROMs, ie, that will be a thing of the past.
In other words, there doesn't appear to be any development anymore on trying to unlock the bootloader. Hope is lost... or is it? Therefore, we need new talent. We need a new generation of developers walking into the game knowing that what they're trying to do is almost impossible. I'm hoping this thread will quickly bring any developer up to speed so we can get some "unlocking Dev rookies". We are recruiting! Come here and ask questions regarding this so hopefully you can figure this out!
I'm going to update from time to time the first few posts with critical info, links to info, etc. My goal with this thread is to put all of the great information from the community in one place. I don't way people to have to search this entire thread, rather get the info quick so they can begin developing quick, so we can get an unlocked bootloader, QUICK!
Remember, there were previous locked bootloaders, but many of them have been cracked so let's take away the 'impossibility factor'!
Who is this thread for?
Anyone that wants to quickly be brought up to speed on the S7 locked bootload status, all the hurdles, etc
Developers that want to be part of the future of locked bootloaders and something great!
Who can post and what posts are allowed?
Anyone with PRODUCTIVE comments towards unlocking the bootloader or efforts already completed (regarding of fail or success)
Developers working on this initiative
Developers with questions for other developers regarding this
Wanna-be developers with questions (There is no shame, and you never know if YOU just might be the rookie dev we're looking for to unlock this! If you're willing to try something to potentially brick your device, then you can play here Or maybe you might throw out an idea that might spark an idea with someone else that leads to an unlock.)
Links to things that have been attempted
Information you think people should know regarding this, that's not already listed. Or information you think should be in the original post so people can easily see it. (I don't want great info hidden deep in the thread, rather on the first page)
Keep me honest! If I post nonsense or inaccurate information, WE NEED you to correct me! Last thing I want to do is steer anyone in the wrong direction!
What NOT to post:
"+1"
"Thanks"
Petitions
Bounties
ANYTHING NEGATIVE! Negative Nancy, PLEASE go away!!
Etc. In other words, DONT waste thread space with nonsense. (Don't let that comment confuse you however with the 'very welcoming' questions from developers; This SHOULD be a collaborative thread. Productive input certainly welcome.) The idea is to QUICKLY allow someone to read this and get ALL the info to start trying to crack this. Going through pages and pages of irrelevant or useless comments will only make the goal more difficult, or prevent our new rookies from coming up to speed and trying to unlock this bootloader.
Who am I and what am I trying to get out of this?
I'm an application engineer and developer that bought an S7 from Tmobile and found out the hard way it had no way to get a custom rom, despite TMobiles past of typically allowing this. I'm frustrated like you all & want my phone unlocked, pure and simple! Besides, this is a community, and what better of an agenda than to try and conquer what others have said, "that's impossible"!
Other Notes:
MANY, many thanks to all the contributors out there!!! I got most of this information from other forums on XDA!
Following few posts will have resources and additional links. This thread is new so I'll find a good organization method in time.
PLEASE subscribe if you are (or want to be) a contributing developer, or have anything to add - or if you can answer others questions. I think a lot of this knowledge will expand to other devices, and not just Samsung, but future devices as well.
Please let me know of anything to fix with this thread, like tags, thread description, etc.
Make sure to send the link to this thread to people you think might be interested (but don't spam them!) Or post a link to this thread in other seemingly dead threads on unlocking this bootloader. Alone it just may be impossible to do this...but as a community, sharing all of our knowledge...we can do this!
Still not motivated to do this? Try this: https://www.google.com/webhp?source...=1&espv=2&ie=UTF-8#q=s7+bootloader+bounties&*
If you found this thread useful hit "Thanks"!
.

Information
Quick facts
Exynos bootloader is unlockable, which is why we won't talk about that here!
S7 Variants https://en.wikipedia.org/wiki/Samsung_Galaxy_S7#Variants
US & China use a Snapdragon processor, all other locations use the Exynos
Knox counter: will void warranty (if you still have one!) Most could careless if there's a remote possibility of unlocking the bootloader. Methods or tampering could possibly trip this counter.
Mostly when people say a phone is "locked", they mean locked to a CARRIER. That is NOT what we're talking about here - we're talking about a locked bootloader which allows you to install a custom ROM.
FRP: (Factory Reset Protection) Requires username/pass after factory resetting http://www.androidcentral.com/factory-reset-protection-what-you-need-know Reset: https://forum.xda-developers.com/galaxy-s7/how-to/samsung-factory-reset-protection-gmail-t3446788
Bootloader version: PhoneSettings->AboutPhone->Baseband version: 5th from last number.
Ex: Bbaseband: G935UUES4AQC1 = Bootloader version 4 @thescorpion420 (Tmobile & U = ver4, China=ver2)
Locked bootloader
Easy way to tell you bootloader locked status(?)
What is the bootloader? Part of the Android boot process. See all about it here: http://newandroidbook.com/
Why can't we currently unlock the bootloader? There is something called the chain of trust, whereby 'everything' from when the phone first turns on, through each 'piece' it verifies the contents of the flash is legit and from a listed trusted source (either Samsung or carrier). What controls this is the current, existing software/FW on your phone. So if we took what's there and removed these checks, we currently don't have a way to write this to your phone, since "we" aren't from the list of trusted sources. How do they enforce this? The images need to be digitally signed.
What does it mean to digitally sign a file (or image, FW in our case)? There is a private key and public key. Samsung and/or Carrier have the private key, your phone has the public key. Author writes a new SW package, then uses a tool to get a checksum. The checksum gets encrypted with the private key. The encrypted checksum gets appended to the SW package. Using OTA (over the air deployment) or ODIN, we push the package to the phone. The phone decrypts the appended encrypted checksum using its public key, does a checksum on the remaining package, and makes sure they both match. Now you can see why we can't fake this! Only way would be to find an exploit or get the private key so we can sign these ourselves!

Links (relevant threads)
Potential way to unlock bootloader? https://forum.xda-developers.com/tmobile-s7-edge/help/potential-to-unlock-bootloader-t3544220
ROOT DISCUSSION / TEKXv2 Dev Thread Extension SM-G935T - Dev Section / Discoveries https://forum.xda-developers.com/tmobile-s7-edge/how-to/root-discussion-future-sticky-root-t3327399
G935AVPT cross bootloader, flash Chinese Version , support ALL lte band,Knox stil 0!! https://forum.xda-developers.com/ve...ross-bootloader-flash-chinese-t3432190/page15 or
https://forum.xda-developers.com/att-s7-edge/how-to/g935avpt-cross-bootloader-flash-chinese-t3435043
High-level explanation on whats going on with this locked bootloader: https://www.xda-developers.com/galaxy-s7-bootloader-lock-explained-you-might-not-get-aosp-after-all/
Resources
Android Internals: A Confectioner's Cookbook http://newandroidbook.com/
Many thanks to Jonathan Levin for releasing that to the public for free, but please support his work via the other listed means. Also Reverse Engineering Aboot: http://newandroidbook.com/Articles/aboot.html
Samsung Source (Tmobile) http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=SM-G930T
Bootloaders, Encryption, Signing http://www.androidpolice.com/2011/0...ncryption-signing-and-locking-let-me-explain/
LOCK download mode (opposite but might have useful info) https://ge0n0sis.github.io/posts/20...-mode-using-an-undocumented-feature-of-aboot/

Tools
Phone Apps
Root Browser app (doesnt need root) access all files on phone (across ALL partitions?) https://play.google.com/store/apps/details?id=com.jrummy.root.browserfree&hl=en
Phone INFO (get info about phone) https://play.google.com/store/apps/details?id=org.vndnguyen.phoneinfo&hl=en
Other
S7 USB driver http://samsungodin.com/SamsungUSBDriver/USB_Drivers_1.5.27.0.rar
ADB (Install Android SDK)
DD: https://forum.xda-developers.com/showthread.php?t=1153991 (can be "disk destroyer" if used stupidly)
Sandbox: Possible to make a virtual S7 to test on? (including ALL partitions such as aboot, etc)
Ubunto VM: How to build a Linux VM for Dev & testing on this: http://imicrov.com/small-tech/android-development/android-development-with-ubuntu-in-virtualbox VMWare: http://www.vmware.com/products/player/playerpro-evaluation.html Ubunto image: http://www.osboxes.org/ubuntu/

Flashing
Info https://code.tutsplus.com/articles/an-introduction-to-android-firmware--cms-26791
Firmware (Android ROM) is stored in a writable form of memory called NAND flash memory, the same type of memory that is used in storage devices, such as USB sticks and SD cards
Bootloader more info
Ways to Flash
ODIN - Odin3_v3.12_PrinceComsy (ODIN is Samsungs replacement of Fastboot) https://www.androidfilehost.com/?fid=24591023225177749 or http://samsungodin.com/ (?)
ODIN is the only possible way (that we know of). You push a download from PC to phone, it runs checksum and signature verification, if it doesnt match what it expects, it never writes from memory to phone and throws away image. This intense security likely due to Samsung pay.
ADB - No standard way to do this, but maybe something creative might work...
Heimdall https://forum.xda-developers.com/galaxy-s7/how-to/guide-heimdall-to-flash-firmware-t3452904 (still work? couple years since updated) Sourcecode: https://github.com/Benjamin-Dobell/Heimdall
USB jig: https://forum.xda-developers.com/galaxy-s7/accessories/usb-jig-t3347793/page4 eBay: http://www.ebay.com/sch/i.html?_odk....H0.Xusb+jig+s7.TRS0&_nkw=usb+jig+s7&_sacat=0 Or make your own: http://www.instructables.com/id/USB-JIG-to-give-life-to-your-Bricked-mobile/
SD card: https://forum.xda-developers.com/showpost.php?p=69235306&postcount=38
Z3X Box: eBay: http://www.ebay.com/itm/2016-Z3X-BO...I-Unlock-Flash-Tool-C3300KCable-/291810363162
Safestrap(?)
Flash Errors & What they mean:
Failed aboot Fused 2> binary 1 - bootloader error: ?
SECURE CHECK FAIL: No Bueno! You're trying to flash something that's not digitally signed correctly
Firmware/Files:
AP (Application Processor or PDA or Android Partition): Android. System partition with recovery, etc. Recovery, kernel and ROM will be in this file. This is the only FW that is open source.
Typical contents of update.zip:
android-info.txt: Text file specifying the prerequisites of the build, such as the version numbers of the bootloader and the radio firmware that the build needs
boot.img: Binary file that contains both a Linux kernel and a ramdisk in the form of a GZIP archive. The kernel is a boot executable zImage that can be used by the bootloader. The ramdisk, on the other hand, is a read-only filesystem that is mounted by the kernel during the boot process. It contains the well known init process, the first process started by any Linux-based operating system. It also contains various daemons such as adbd and healthd, which are started by the init process More info
recovery.img: Very similar to boot.img. It has a boot executable kernel file the bootloader can use and a ramdisk. Consequently, the recovery image too can be used to start an Android device. When it is used, instead of Android, a very limited operating system is started that allows the user to perform administrative operations, such as resetting the device's user data, installing new firmware, and creating backups.
system.img: Partition image thats mounted on the empty system directory from boot.img. Contains the Android OS binaries as well as system apps, fonts, framework JAR files, libraries, media codecs, bloatware, etc. (Most used for flashing a custom ROM)
userdata.img: Partition image that will be mounted on the empty data directory from boot.img. Custom ROMs typically come with this image as blank so that it resets the contents of the data directory.
BL (Bootloader): Proprietary code that is responsible for starting the Android operating system when an Android device is powered on. Typically, it checks if the operating system it is starting is authentic as well. (Checks if the boot partition has been signed using a unique OEM key, which belongs to the device manufacturer, & is private.) Ie, Locked bootloader. Fastboot, IF allowed on a device, disables this check.
CP (Core Processor): Modem. This proprietary Radio firmware is another operating system on an independent processor called a baseband processor, independent of Android. This adds the cellular radio capabilities of the device like 3g & LTE. Qualcomm, etc develop this FW.
CSC (Consumer Software Customization): It is specific to geographical region and carriers. It contains the software packages specific to that region, carrier branding and APN setting. Eg Wi-Fi Calling. Flashing will lose your data (factory reset). Variations of CSC may retain data.
PIT files (Partition Information Tables) (Danger! Dont flash these unless you know what youre doing!)
Different variants of the S7 have different partition sizes; same phone/same carrier with different storage size have different PIT. One issues people were having flashing images for other variants is that the partition would fill up. A workaround would be to reformat with a correct PIT file and check "repartition" in ODIN. More info via @[Ramad] https://forum.xda-developers.com/sho...d.php?t=999097
"Get PIT for mapping" error while flashing (indicates you need a PIT file to flash what youre trying to flash)
-Extract current PIT file from phone: http://www.**********.com/how-to-ext...alaxy-devices/ (need root)

Unlock Methods
High-Level Ways to Unlock:
Get leaked private key so we can sign our own images
Find exploits
Dev bootloader gets leaked
?
What does work:
Can flash digitally signed images
Can write to partitions with engineering kernel
Ideas:
Use engineering kernel that has root to somehow modify bootloader partition to remove digital signature checks - at level/entry point can or should this be done? (ie, where in boot process at a minimum do we need to remove the check?)
Thread on installing LineageOS on bootloader locked Note 3: (this possible on our device?) https://forum.xda-developers.com/redmi-note-3/how-to/kate-guide-install-lineage-os-locked-t3546154
Thread on Recovery for locked bootloaders by @hsbadr : (work on our device?) https://forum.xda-developers.com/an...g/tool-multirom-recovery-replacement-t3102395
...Reading sdd10 line by line. I did find an entry "Device is unlocked! Skipping verification...". I'm starting to think we need to look into recovery-side exploits" @Flippy125 https://forum.xda-developers.com/tmobile-s7-edge/help/potential-to-unlock-bootloader-t3544220/page2
Back rev bootloader version (or other partition) to reintroduce security exploits (dont believe you can backrev though, easily) dd Chinese version? (Hard brick?) https://forum.xda-developers.com/showpost.php?p=70977356&postcount=39 @thescorpion420
Exploits: (known existing)
SD card most vulnerable?
Samsung Source available I believe (in its entirety though? See Resources links above) Perhaps viewing this may reveal exploits
?
Attempted Methods:
OEM Unlock in Android Settings menu: YES! We tried that!
Flashed Chinese images via ODIN. People used PIT (Partition Information Table) files and checked reformat partitions in ODIN and still failed.
Result: Errors during flash process, won't take, "Thread Failed" error
Chinese bootloader is v2 where all US models are v4(? How to determine?)
Convert Chinese ROM to another variant: https://forum.xda-developers.com/android/general/guide-how-to-convert-chinese-roms-based-t3577469
Use 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.
Dirty cow exploit - (didnt work) indicated by @Binary100100

Android OS & Everything about it
Engboot kernel write protection seems to be off, so it appears you can use dd to write to normally write protected partitions such as the bootloaders (ex: "dd if=/sdcard/aboot of=/dev/block/sdd10"). In my testing I was successfully "dd" a backed up aboot (secondary bootloader) partition and also write to the modem partition and have it stick @qwewqa
MBN files: Multi boot binary firmware. Mostly used with Samsung, binary data for storing the device's memory partitions, such as the resources and power manager, secondary boot loader, AP boot loader, and trust zone. Can't just edit, need source then compiling creates mbn files? Info: https://www.quora.com/What-is-mbn-file-format-where-is-it-used https://forum.xda-developers.com/showpost.php?p=29787988&postcount=31
Create MBN: https://forum.xda-developers.com/showpost.php?p=28145975&postcount=198 Moreinfo: https://forum.xda-developers.com/showpost.php?p=28149932&postcount=212
Cook custom ROM: https://forum.xda-developers.com/showthread.php?t=901417
Extract mbn files using unyaffsmbn: https://forum.xda-developers.com/showpost.php?p=6303911&postcount=827
How to get existing versions, eg, bootloader version? (Many versions are in Phone->Settings->About device)
Partitions... needed to be modified(?) @qwewqa https://forum.xda-developers.com/tmobile-s7-edge/help/potential-to-unlock-bootloader-t3544220
- rpm (Resource and Power Manager / Primary Bootloader) located at /dev/block/sdd1 (/dev/block/bootdevice/by-name/rpm)
- aboot (AP Bootloader / Secondary Bootloader) located at /dev/block/sdd10 (/dev/block/bootdevice/by-name/aboot)
- xbl (Extended Bootloader) located at /dev/block/sdb1 (/dev/block/bootdevice/by-name/xbl)
- ? located at /dev/block/sdc1
- Sdd1 is the primary bootloader
Boot Process @qwewqa
RPM = Resource and Power Manager = Primary Bootloader
ABoot = AP Bootloader = Secondary Bootloader
I believe the boot process is "RPM > ABoot > boot.img (Main OS)", so both the rpm and aboot file would be needed
Partitions (Correct? via @silentwind827)
https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565
https://source.android.com/devices/bootloader/partitions-images
http://davinci-michelangelo-os.com/2017/01/22/edit-init-rc-android/
ls -l /dev/block/bootdevice/by-name/
cat /proc/partitions
/dev/block/sda1 => modemst1
/dev/block/sda2 => modemst2
/dev/block/sda3 => fsc
/dev/block/sda4 => ssd
/dev/block/sda5 => persist
/dev/block/sda6 => efs
/dev/block/sda7 => param
/dev/block/sda8 => misc
/dev/block/sda9 => keystore
/dev/block/sda10 => devcfg
/dev/block/sda11 => frp
/dev/block/sda12 => bota
/dev/block/sda13 => fota
/dev/block/sda14 => persistent [edited]
/dev/block/sda15 => apnhlos
/dev/block/sda16 => modem
/dev/block/sda17 => boot (Kernel, RAMdisk, & boot images get flashed here see link above for details)
/dev/block/sda18 => recovery
/dev/block/sda19 => persdata
/dev/block/sda20 => system
/dev/block/sda21 => cache
/dev/block/sda22 => userdata
/dev/block/sdb1 => xbl
/dev/block/sdd1 => rpm
/dev/block/sdd2 => tz
/dev/block/sdd3 => hyp
/dev/block/sdd4 => fsg
/dev/block/sdd5 => sec
/dev/block/sdd6 => pmic
/dev/block/sdd7 => dsp
/dev/block/sdd8 => dip
/dev/block/sdd9 => mdtp
/dev/block/sdd10 => aboot
/dev/block/sdd11 => devinfo
/dev/block/sdd12 => bluetooth
/dev/block/sdd13 => lksecapp
/dev/block/sdd14 => keymaster
/dev/block/sdd15 => cmnlib
/dev/block/sdd16 => cmnlib64
/dev/block/sdd17 => apdp
/dev/block/sdd18 => msadp
/dev/block/sdd19 => dpo
/dev/block/sdd20 => ddr
/dev/block/sdd21 => pad

Restore Stock Methods
(Since we need a way to fix a bricked phone while we're trying to break it!)
Hard bricks likely not restorable though?)
Note: Not all of these methods will work, depending on how bad you bricked your phone.
https://www.androidsage.com/2016/03/...ware-download/
How to Fix a Bootloop: Turn off your device and reboot into recovery mode by press and holding Power + Volume down + Home keys for a few seconds. From the Recovery, select Wipe Data / Factory Reset. Confirm the action and reboot once done. Your device should now boot up.
Samsung Kies & Samsung Smart Switch https://forum.xda-developers.com/galaxy-s7/how-to/guide-revert-to-stock-anytime-kies-t3396314
Stock Files
Stock Files Collection https://forum.xda-developers.com/galaxy-s7/how-to/s7-s7e-stock-rom-bootloader-modem-t3383963
[Collection] Firmware/ROM Full, PIT Files https://forum.xda-developers.com/galaxy-s7/how-to/collection-firmware-rom-pit-files-t3326707

Alternatives to unlocked bootloader
A Quick and Simple Summary list of things to get by until we get custom roms:
[ROM][TMOBILE][S7_SM-G930T][Oreo Rooted]
Use Engineering kernel to get root https://forum.xda-developers.com/tm...eres-how-rooted-nougat-s7-edge-g935t-t3567502 (SOME people complain of lag with the engineering kernel)
Remove bloatware:
Debloater by @gatesjunior (Works on latest Android with root) https://forum.xda-developers.com/android/software/debloater-remove-carrier-bloat-t2998294
Other apps: Titanium Backup, Package Disabler Pro, Root Package Disabler
Freeze these apps: https://forum.xda-developers.com/galaxy-s7/how-to/touchwiz-bloatware-save-to-remove-list-t3330241
Stock ROM Engineering kernel modified, with root (NOT installed traditionally via recovery like TWRP) Ex: https://forum.xda-developers.com/tmobile-s7-edge/development/rom-t3572739 by @jrkruse or https://forum.xda-developers.com/tm...ekx-dev-deodex-systemui-3minit-multi-t3411776 by @TEKHD
xposed not available yet for nougat as of 4/1/2017

kevin712467 said:
Alternatives to unlocked bootloader
A Quick and Simple Summary list of things to get by until we get custom roms:
Use Engineering kernel to get root https://forum.xda-developers.com/tm...eres-how-rooted-nougat-s7-edge-g935t-t3567502 (SOME people complain of lag with the engineering kernel)
Remove bloatware:
Debloater by @gatesjunior (This still work?) https://forum.xda-developers.com/android/software/debloater-remove-carrier-bloat-t2998294
Other apps: Titanium Backup, Package Disabler Pro, Root Package Disabler
Freeze these apps: https://forum.xda-developers.com/galaxy-s7/how-to/touchwiz-bloatware-save-to-remove-list-t3330241
xposed not available yet for nougat as of 4/1/2017
Click to expand...
Click to collapse
Not on the newer versions of Android unless rooted, then it does.

Does anyone know if the phone boots differently when using a)the SD card boot & b)USB jig? Or z3x box? If so, how? (I'm guessing the jig boots the same as button pressing into download mode, but wanted to leave no leaf unturned!) Knowing this might open some doors of vulnerability if it boots differently. All the reading I did about this, I haven't read about anyone trying to flash an image via either of these methods. (I'm assuming & hoping this is even possible & you can actually boot off the SD card, if not at least install via SD) Testers?! (Reference "Flashing -> Ways to Flash" above for details, links.)

can try on your phone 7 edge

kevin712467 said:
Alternatives to unlocked bootloader
A Quick and Simple Summary list of things to get by until we get custom roms:
Use Engineering kernel to get root https://forum.xda-developers.com/tm...eres-how-rooted-nougat-s7-edge-g935t-t3567502 (SOME people complain of lag with the engineering kernel)
Remove bloatware:
Debloater by @gatesjunior (Works on latest Android with root) https://forum.xda-developers.com/android/software/debloater-remove-carrier-bloat-t2998294
Other apps: Titanium Backup, Package Disabler Pro, Root Package Disabler
Freeze these apps: https://forum.xda-developers.com/galaxy-s7/how-to/touchwiz-bloatware-save-to-remove-list-t3330241
Stock ROM Engineering kernel modified, with root (NOT installed traditionally via recovery like TWRP) Ex: https://forum.xda-developers.com/tmobile-s7-edge/development/rom-t3572739 by @jrkruse or https://forum.xda-developers.com/tm...ekx-dev-deodex-systemui-3minit-multi-t3411776 by @TEKHD
xposed not available yet for nougat as of 4/1/2017
Click to expand...
Click to collapse
well ive been reading the BL.mdf file and how ive done it if you delete the mdf extension and etract it as a tar file youll get three files with encryption, some of it is readable i'm studying the code and looking for loop holes. however i have tried flashing the G935F BL file on my G935V and it gives me an device ID not supported error so if we can somehow implant the US models device ID to the G935F BL file we should have an unlocked bootloader. it's just a theory but i believe this would be a great start for us models of the s7 edge.

kenshin6106 said:
well ive been reading the BL.mdf file and how ive done it if you delete the mdf extension and etract it as a tar file youll get three files with encryption, some of it is readable i'm studying the code and looking for loop holes. however i have tried flashing the G935F BL file on my G935V and it gives me an device ID not supported error so if we can somehow implant the US models device ID to the G935F BL file we should have an unlocked bootloader. it's just a theory but i believe this would be a great start for us models of the s7 edge.
Click to expand...
Click to collapse
The 935f bootloader is for exynos, you want to flash the 9350 bootloader. Odds are if you succeeded in flashing the 935f bootloader you'd have a nice shiny paperweight.

kenshin6106 said:
well ive been reading the BL.mdf file and how ive done it if you delete the mdf extension and etract it as a tar file youll get three files with encryption, some of it is readable i'm studying the code and looking for loop holes. however i have tried flashing the G935F BL file on my G935V and it gives me an device ID not supported error so if we can somehow implant the US models device ID to the G935F BL file we should have an unlocked bootloader. it's just a theory but i believe this would be a great start for us models of the s7 edge.
Click to expand...
Click to collapse
Where are you finding a "BL.mdf" file? I'm looking at stock images and see mostly mbn, bin, and img files. Is this an extraction of one of these files, images? Not sure this will help but here they talk about "brushing" (flashing) 'pick and choose' images making a compilation for a full flash (like pick US modem, with chinese bl, etc) & the Chinese are successful using US "pieces"/images despite having a different phone variant https://forum.xda-developers.com/ve...g935v-cross-bootloader-flash-chinese-t3432190 Another possible way could be the opposite of what you're trying: implant the international device ID on our phone so the image can flash without your error. (via engineering kernel possible to change this value, wherever it sits?)
Also, another thought: I wonder if there's a way to modify the PC ODIN tool (or Heimdall since that source is easily available) to add functions to talk to "hidden functions" on ODIN (on the phone) to unlock it that way. Or modify it to turn it more into an interactive console so we can navigate and investigate the phone's ODIN program. Does anyone know if the ODIN source for the phone side has been leaked? If not, any intelligent folks out there know how to 'reveal' all methods so we can go through it and maybe find exploits? (This been done already?)
One more thing: Those thinking the S8 is nearly out now so let's give up... Well, can anyone predict the future like I can?!! I'm SURE it will be locked as well. I wouldn't be surprised however if any exploit we can find for the S7 will be relevant on the S8!
Thanks for the efforts kenshin6106 ! And all the viewers of this thread make sure to hit the "Thanks" button on the bottom right of the developers posts to show your support. Remember, most think this is a dead subject, let's change that mentality!!

Can anyone please indicate what images or partitions are allowed to be downgraded, version-wise (if any)? I'm reading conflicting information - or its hard to tell if the bl rejected it due to a fundamental error or because it will not allow down-reving, whereby it would be possible had an acceptable image been used. eg, I read the bootloader cannot go from ver4 (US) to ver2 (Chinese). I'm not sure what's accurate. And Does ODIN/bootloader allow you to go from Nougat to Marshmellow? Knowing this will help with our unlocking methods...

Any instructions on how to flash g930p to u firmware I get errors

Bump.

I have a rooted SM-G930v using the engineering kernel, but I find the limitations of having a locked bootloader hyper-frustrating. In fact, I started researching which non-samsung android phone will be my next. (Looking at the Huawei P10/P11). I've been trying to use Magisk, TWRP, and a few other tools and have come to the realization that none of these are possible with a locked bootloader. Why is it that the Chinese variants have unlocked bootloaders? Samsung surely didn't make the decision to lock down their devices. It must be the US carriers that insist on locking down their devices and systems so that people can't modify certain apps, systems, and roms. Like bloatware for example. We just can't have nice things.
I wish I had more time to work on this, but I am not very experienced and I would almost rather get a similar device that is easier to root. I will however follow this thread and contribute what I can.

Chiller252 said:
I have a rooted SM-G930v using the engineering kernel, but I find the limitations of having a locked bootloader hyper-frustrating. In fact, I started researching which non-samsung android phone will be my next. (Looking at the Huawei P10/P11). I've been trying to use Magisk, TWRP, and a few other tools and have come to the realization that none of these are possible with a locked bootloader. Why is it that the Chinese variants have unlocked bootloaders? Samsung surely didn't make the decision to lock down their devices. It must be the US carriers that insist on locking down their devices and systems so that people can't modify certain apps, systems, and roms. Like bloatware for example. We just can't have nice things.
I wish I had more time to work on this, but I am not very experienced and I would almost rather get a similar device that is easier to root. I will however follow this thread and contribute what I can.
Click to expand...
Click to collapse
Check out this thread - https://forum.xda-developers.com/s7...heoretical-variant-bootloader-unlock-t3627286
We need testers!!

YT9213AJ 2gb/16gb rooting/recovery

Do not blindly flash this device without knowing what you are doing. While the device is hard to brick in general, it is very easy for someone new to brick it by flashing the wrong partitions.
I will write a generalized tutorial that will cover the basics and hopefully make everyone feel better about flashing the device. At first I was skeptical but after understanding everything, I have to say it really isn't that bad, and I am here doing all the leg work for these fake 2gb (its really 1gb ram) and 16gb hdd
OK I am goin gto try and put all of this information in one place because these units say android 10 or 10.1 but in reality cpu-z they are android 9 with api of 27 (will double check to be sure. This unit says it is 2gb ram but it is indeed 1024 MB (q GB). I am not sure if the other custom firmwares dumps from 1gb yt9213aj models will work without problems on these yt9213aj units that say 2gb.
In order to try anything you need to first make a scatter file for your unit. I messaged the manufacture of my unit for a firmware and they sent it. I unzipped it and looked at the scatter file and it is of a different formatting than one that comes from mtk droid tool.
So, mtk droid tool doesn't work with OS versions 9 or higher. It is the problem of adb. But we can follow this guide https://forum.xda-developers.com/t/...not-revealed-error-in-mtkdroid-tools.3582571/ and get it to work.
Once you have your device connected and recognized in droid tools you should first create the scatter file, as this is the most important step to do a full readback in SP flash tools.
Once you have a backup, you are in the clear for the most part. I am still trying to figure out how to backup preloader and etc if possible.
Now you will also need to connect some kind of wire or some small buttons taken from something disassembled. Just something that you can use as a mock button because there is no hardware button on the device for up/down and OK and you cannot use the touch buttons. So you need to short these traces while in recovery in order to get further/
The main point of this thread is to update the existing ones and to add tools and stuff nmeeded in one location because it has taken me over 5 days to search for all fo this, and I am still not done, so lets make it a little easier on the new comers because the last thing we want to do is brick each others devices by using old outdated guides that don't fully work.
Flow chart of process: install mtk droid tools and sp flash tools ->enable oem debugging and oem unlock on device -> follow guide to get mtk droid tools to work -> get scatter file using mtk droid tools -> make a full readback in sp flash tools -> solder wires/buttons onto test points -> boot to fastboot and unlock bootloader -> fastboot flash recovery <image name> -> boot into recovery and install root and/or custom firmware.
Anyone more skilled knows any better?
This post is a WIP and will be updated periodically as I source information. The main idea behind this post is to bring all resources for yt9213aj in one spot. There is plenty of information, its just very hard to navigate especially for someone new to flashing these devices, and even worse to someone who has never flashed any device

OK after trying what seems like 300 twrp's I finally found one that does work with this device. I thin kthe main difference here is that the board is a new revision and some arch changes caused older version that were ported to not work. This one booted right into it but was in russian, which is easily fixable within the twrp gui.
I will add all of these files to the op when I have collected everything.
I do not think that this version board I have has hifi? Maybe I am mistaken? I have an audio glitch at 19-20 when playing music, the sound will get louder and sound good for a fraction of a second then return to sounding ****ty. So I will look into this more. What sucks is that there are so many of the same **** that doesn't work for this model so its like... I would rather garggle gasoline than have to sift through forums that were translated on the fly
Anyway here is the twrp for this particular device - https://www.dropbox.com/s/vogg7854a7ln2zu/twrp-9213aj.img?dl=0
EDIT: also you can boot to fastboot (adb reboot bootloader) and use fastboot getvar all to get factory partition sizes that's needed to create scatter file (you will need to use a hex calculator to create it, or wait for me to upload my scatter file once I have it done). You need to be making dumps in sp flash tool way before you are ever writing anything. Make plenty of readbacks and get to know how to read it before you write anything. Blindly flashing is not what you really want to do lol
Mtk drivers for pc
to install, you will need to disable signature verification and I had to turn on test signing as well

I have successfully rooted this thing. I did encounter something kind of strange though. When I patched the boot.img I had from the device and the one I got in ota update and patched with magisk. When I booted and checked the root with magisk it said there was an unsupported root using su already. It did this for both boot.imgs.
Anyone ever heard of this on stock firmwares? I am able to grant root permissions to busybox and etc so it seems to be working OK. Maybe the root that is there is the chinese root for backdoor tracking and surveillance xD
Wonder how to see what unsupported su commands are being sent?
EDIT: i also took a lot of pictures of the board. It is yt9213aj v1.2 board. I will update the original post in the few days with everything needed for this model including testpoints etc. The test points are a little different but its pretty much the same. The only two you need in the end are the two bigger ones (for unlocking bootloader) then your set. You could drill some holes and run wire down to the trace and put some hardware buttons for the mcu to use to select things in fastboot and official recovery.
There is also another port/connector on this thing above the touch sensor board. I think we could buy a ribbon cable to connect here and run it to another board with hardware button. Actually I think the connector is for hardware buttons specifically but I don't know for sure. Must do more research

These things have are rooted from the factory. When I try to use magisk it says there is another unsupported su. The Unsu.zip floating around cures that. Then you can install magisk.
Also another thing about these things being prerooted... I think you can dump and flash without any extra sp flash tools or mtkdroid. I was dumping the partitions using adb pull function. Adb pull /dev/block/platform/soc/11230000.mmc/by-name/<insert partition name here>"
And
"/dev/block/mmcblk0pxx" where xx is the specific partition to read/write to.
I had got a scatter.txt in the ota update I obtained from the manufacturer which had all the partition layouts. I used this and a log from a failed supersu.zip install to create a scatter.txt for this particular device. The supersu log can be obtained by trying to flash the supersu zip in recovery, then in adg just pull the log file adb shell cat /tmp/recovery.log. Once you have this, you will have to use brain.exe to make your own scatter for sp flash tools.
All in all its pretty easy to actually root the device, and they are actually rooted from the factory, most likely for some functions within the os to work (like surveillance and spying xD) but that can easily be removed with the unsu.zip then install magisk.
I will be writing up a guide for this specific model in a few more days. If you read this thanks for listening to the rumbling of a mad man

Just discovered another problem. When I try to edit anything in /system it says its read only. Mounting is or remounting it shows as successful with no errors, but something is blocking it from mounting as system. I am trying to rename this audio_effects.conf and it willnt let me. I think it might be some proprietary code in the kernel designed to block mounting or remounting of certain or all partitions.
I think that a lot of them are software locked, like the fader and balance and volume level. Notice how some of these have glitches when turning the volume up and down. I think that there is some code that disables some functions of higher end units, depending on the model. If you buy a cheaper 100 dollar head unit, maybe it is indeed just software locked down.
I know for fact the amp chip in my head unit, YD7388, sec sheet says 4 channel. But my device is only 2 channel, no fader. Also the spec sheet says it needs no output capacitor but mine has one I think (there is a huge capacitor soldered next to the chip. I have some pics of the board and test points and chip markers etc. Once I have everythign ready I will make a nice guide

Wow I think I found the reason this thing outputs as 2 channel on 4 speakers. I need someone with a real 4 channel version to message me so I can get a few files for comparison. If this is the case, a simple magisk module would fix the fixed 2 channel problem we have. In the audio_policy_configuration.xml they have all output set as
XML:
<devicePort tagName="FM Tuner Out" type="AUDIO_DEVICE_OUT_FM" role="sink">
<profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
samplingRates="44100" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
</devicePort>
I wonder if you set AUDIO_CHANNEL_OUT_STEREO to multichannel or maybe like "AUDIO_CHANNEL_OUT_QUAD " as described in the official android docs say, I wonder if that would enable true 4 channel (or 5.1)?
If someone who has a 4 real 4 channel stereo and it is around the model of yt9213aj, then send me a message so we can collaborate. If you are not rooted do not worry I will help you