[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
This is the main reason I like the Samsung EDL Bootloaders.

The EDL package is QUALCOMM. It lacks the Samsung Customization.

If it is possible to take those bootloaders that are signed and build the rest of the android system its hard to tell what we could end up with. Maybe the bootloaders in the EDL have the ability to be unlocked by the normal Qualcomm method that utilizez the DEVINFO partition that is present on our devices.

Have you looked at that yet?

greatqlte:/ # hexdump -C -v /sdcard/devinfo.img
00000000 41 4e 44 52 4f 49 44 2d 42 4f 4f 54 21 01 01 00 |ANDROID-BOOT!...|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Looks Pretty Familiar.

Bootloader Unlocking

For some devices, such as several Xiaomi ones, partition flashing is sufficient for being able to unlock the Android Bootloader (which disables the verification of the rest of the chain):

[Primary Bootloader (PBL)]

|

`---NORMAL BOOT---.

[Secondary Bootloader (SBL)]

|-.

| [Applications Bootloader (ABOOT)]

| `-.

| [boot.img]

| |-- Linux Kernel

| `-- initramfs

| `-.

| [system.img]

|

`-[TrustZone]

The bootloader locking bit of such devices is held in the devinfo partition, parsed by the Android Bootloader.

Attackers can simply flip the lock bit, to load an arbitrary boot image. This will not cause any factory reset.

Reading devinfo using our framework prior to the attack yields the following output:

> hexdump devinfo.bin

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 41 4E 44 52 4F 49 44 2D 42 4F 4F 54 21 00 00 00 ANDROID-BOOT!...

00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Setting 1 at offsets 0x10, 0x18, and flashing the modified devinfo will unlock the bootloader:

:cowboy:

No im not saying that Ive tested this yet. But it is a possibility.

My guess is that the EDL bootloaders that Lack Samsung Customization including KNOX might and I say again Might read the devinfo partition.

It is there for some reason. So the Question is Why??? What does it do.

That is the reason for my interest in the EDL Firmware.

i dont think the sdcard approach is viable.. secure boot is enabled and the partitions u speak of flashed to an sdcard are not signed appropriately so the device wouldnot boot up if it was in fact trying to run off the sdcard.

Again this is misinterpretation.

I'm not saying we are going to run the dragonboard firmware on our devices.

If you know the dragonboard tools some of them are very useful.

It is proven already the sd card can indeed influence the devices operation.

Basically I am utilizing some dragonboard tools to replicate what odin does to the sdcard when you use T-FLASH.

The sd card is very viable and a great means of testing. BUT also a lot of work.

Dragonboard 820 is as close to the actual source code we are going to get right now.

If you dig down in the bootloaders you will find many reference to msm8996 source code.

The msm8996 and msm8998 share a lot.

And Little Kernel is Little Kernel.

Liarno has good source trees that are for building LK with different functions.

If we can unlock the bootloader and run our own LK thats sure where id start.

Also for understanding how LK works and the different functions what better of a source than a very well documented one.

I actually have quite a bit of Leaked Qualcomm Source Code. Its a bit older but still very viable.

More than enough to understand how the security mechanisms work if you really dig into it.

Thank You very much for pointing this out.

There are uses for that for sure.

The sd card working or not working to accomplish anything all depends on how the samsung and the EDL bootloaders are written.

THEY DO SUPPORT THE SD.

I'm just looking for that one quirk that gets us a way in.

Its like looking for a needle in a haystack.

Its never expected to be there and found entirely by mistake. After you step on it.

If you don't play in the haystack you will never step on the needle.

Thank you again for your insight. If you have any other knowledge of things like that it all helps.

Maybe that is a way to trigger the SD.

The process of debating always leads to something.

Like setprop sys.boot_mode ffbm.

If everyone shares there finds eventually putting them all together gets something accomplished.