yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] pbedard:
Hes gouing to sell it to samsung ??
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
This is from another thread dealing with the boot signing.

https://xdaforums.com/android/software-hacking/signing-boot-images-android-verified-t3600606/page2

Post 18 and 19
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] elliwigy:
In order to claim bounty itd need to be something not reported yet.. zeroing out partitions not new.. I zeroed out my param and it caused all sorts of visual issues lol.. I just left oem unlock on when I first went to combo so frp doesn't really work at all for me lol
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] elliwigy:
edl is absolutely qualcomms implementation.. but on sammy locked sd devices the edl programmers which are needed to do anything in edl mode have to be signed by samsung as well as for the rev that you need.. Theres no way around that..

luckily though all you need is the right programmer and then possibilities are endless as you can then write anything.. of course if not signed and ur test doesnt actually bypass secure boot or unlock bl it wont boot lol..

edl is basically like a root shell when it comes to having write access to the entire device..

i dont know what if anything is signed with qualcomm keys.. edl mode starts up before anything and requires a sammy signed programmer to work (thanks sammy).. I tried multiple times on multiple devices to flash qc signed firmware and always secure boot fail...

unfortunately the keys you speak of in fota.zip and elsewhere are of no use.. i also went down that road more than once lol.. the private key is needed along with the other parts of the chain such as public key to sign anything.. u cant sign a firmware image with only one half (the public part) as well as its impossible to crack it.. its also hard wired at the factory and typically never seen again..

the dumpkey and bootsigner etc. arent much help to obtain the priv key.. if u r signing with ur own custom keys sure but the device will ignore it and fail to boot.. the only "keys" we can make and use would only be for user apps, wifi, vpn etc..

Ive wasted too much time on keys lol.. like weeks haha.. i used to think we could sign firmware using keys from qc and device should boot in a yellow state but no luck lol

i think ur on the right trac tho, process of elimination.. if the stuff ur lookin into doesnt pan out then move on to another potential solution.

i have the note 9 currently.. im looking into combo firm more, configfs modes, efs, diag etc.. i am probably going to the electronic store later to get some supplies to make a uart cable/jig..

My buddy that helped out with s8/s8+ root has shown me proof of rooted s9/s9+ on combo firm.. should work for note 9 also im hoping.. if he ever shares how its done lol

the S8+ i was able to "adb reboot edl" to get into it.. the s9 and up not so lucky.. i have yet to find a way into edl on my n9 without actually bricking it lol.. theres no programmers yet either..

i do have some qc msm8998 files you might b interested in.. im talkin build tools, programmers, sectools, scripts etc for edl stuffs that was leaked from a qc employee.. i wont post publicly tho due to the nature of the files (ppl can literally kill their devices) as well as i dont want anyone gettin in trouble.. so send me a pm if ur interested in takin a look
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
Yes I agree totally about the programmer.

We have it. If your lucky enough to still have your device on rev 2 bootloader.

Fortunately I never updated my device.

In fact I couldn't get samfail V 2.5 to run. Maybe I could but samfail 2.0 works fine so i'm definitely on the

U2 Bootloader.

This is the official Samsung Signed EDL Package for REV 2.

Ill attach the spreadsheet to that is the decodec GPT for the EDL package.

My thoughts with this are to build the rest of the system to run with the EDL bootloaders.

Kinda like building a combination.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] rippedwarrior69:
Dang mine is on v3.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] CountKrzysztof:
I'm so glad I kept my Note 8 on the U1 bootloader! I figured if a bootloader exploit were ever discovered, it would require an older bootloader and since root never came for Oreo, I never updated in case anything like this came along.

I'll be keeping an eye on this thread. You guys are amazing! Hopefully something workable comes out of all this.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] pbedard:
Rip u3 n higher
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
The boot process is the following:

The SoC ROM (aka Primary Boot Loader, PBL) code searches for the Secondary Boot Loader (SBL) on the boot device (eMMC or SD card). SBL includes 2 code segments.

The first SBL segment is loaded (and authenticated) into internal memory, on the Cortex A53.

The second SBL segment is loaded (and authenticated) into the RPM memory (RPM is a coprocessor on the SoC).

SBL #1 initializes the DDR

SBL #1 loads into DDR and authenticate the TZ and HYP images. then the RPM firmware is loaded into RPM RAM.

SBL #1 then loads the Application boot loader (APPSBL, e.g. LK) into DDR

SBL #1 job is finished, and the trusted firmware and hypervisor take over and initialize various things in the platform. and also the RPM is released from reset

Eventually we end up in LK which is the first open source component in the boot stack, which everyone can rebuild/update from sources.

The firmware need to be placed on the boot device using a strict GPT. Each firmware is place on its own partition for example.

gpt_both0.bin: this is the GPT that is flashed on the eMMC (or SD card). We generate the GPT ourselves in our build scripts using this tool [1]. It is possible for anyone to generate their own GPT, of course the basic structure should be kept but new partitions can be added/tweaked.

sbl1.mbn: this is the SBL firmware , containing the initial bootloader code for A53 and RPM.

rpm.mbn: RPM firmware.

hyp.mbn: Hypervisor (called QHEE in QCOM vocabulary)

tz.mbn: trusted firmware (called QSEE in QCOM vocabulary)

tz-psci.mbn : same as above. in the past we had 2 variants of the TZ firmware, the initial release did not have support for PSCI, and that was added later. We have kept both variants for some time (I believe that we only have one version in the latest bootloader release), and we recommend to use the PSCI version.

emmc_appsboot.mbn: this is the LK ELF image. This file is built by Linaro, from sources.

NON-HLOS.bin: it contains some firmware (DSP, WLAN, …). we don’t really use this file, it’s mostly an artifact from the downstream android where these firmware are on a separate partitions. on Linux we put all firmware in /lib/firmware instead.

And now about sbc_1.0_8016.bin, this is a new file that we added in the most recent release. It is called 'CDT" data in QCOM jargon. It contains platform information that allow the SBL to identify the board it is running on (e.g. CPU, RAM, board name/type, …). Up until last release these information was hardcoded in the SBL image we got from QCOM, but that was a hack that was done at launch, which we finally had to get rid off. Since the last QCOM firmware release, the information is no longer hardcoded into SBL, so CDT data is needed so that SBL can detect the board properly. This information is later on used by the bootloader to load the appropriate DTB file. This is a fairly complex and legacy process… but basically without CDT data the wrong DTB file could be loaded and passed to the kernel.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
Little Kernel

Now if we review a little about the Little Kernel we get an Idea of whats going on.

You can take a look here for example.

2.3 Kernel authentication 

Generation of signed boot.img.

a. The Android build system supports generation of the signed boot image using the user’s private key.

b. The build system calculates the SHA256 hash of the raw boot.img and signs the hash with the user’s private key (specified by $(PRODUCT_PRIVATE_KEY) flag defined in device/qcom/common/common.mk. It then concatenates this signed hash value at the end of raw boot.img to generate signed boot.img.

c. Users must set the PRODUCT_PRIVATE_KEY flag with their private key file. Currently, it is set to device/qcom/common/qcom.key, which is a test private key and open sourced on CAF.

d. On the Android Lollipop release, Verified boot (Google’s defined mechanism) is used for the authentication of kernel and recovery images.  LK (Android boot) authenticates the kernel (boot.img).

a. If the TARGET_BOOTIMG_SIGNED= true flag is set in the target’s BoardConfig.mk file, LK verifies boot.img before booting up into Linux kernel.

b. During bootup, LK strips out the raw boot.img and signed hash attached at the end of the image. LK calculates the SHA256 hash of the complete raw boot.img and compares it with the hash provided in the boot.img. If both hashes match, kernel image is verified successfully. Call flow in LK for verifying signed kernel image – verify_signed_bootimg()→ image_verify().

c. On successful verification of the kernel image, LK passes “androidboot.authorized_kernel=true” to the kernel in the kernel command line.

d. Users must add their own certificate with public key in the bootable/bootloader/lk/platform/msm_shared/certificate.cfile. LK uses this certificate for decryption of the signed hash value present in the end of the boot.img.

Now what does this mean??

This says to me that the LK is where we want to defeat the boot chain.

Well yea that's pretty obvious.

We can build LK and there are actually already build LK that are unlocked ( don't verify boot ).

We cant run it because sbl check the signature of LK.

Soo lets think. :confused:

If we can hijack the boot process ( which we can ).

Can we execute a LK to reinitialize the device without the boot image check?

Soo im thinking ok we need to chain boot some stuffs.

Currently we can hijack the boot process with safestrap.

What else can we do at that point?

Can we call a install of u-boot and execute unsigned boot.img?

Calling U-Boot inside of Safestrap and then calling the normal boot.

Even better.

As my curiosity got the best of me I started looking at how safestrap operates.

I have built FISH before wich is similar and figured that safestrap loads a ramdisk which is the recovery.

And it does.

But more interestingly I was looking at the init files.

The elf files.

So if safestrap can execute and elf file.

CAN IT EXECUTE LK?

That is the question.:eek:
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
One more quick note.

In the log we see

TargetName="MSM8996" DateTime="Nov 22 2017 - 16:56:54

This is where I was saying before that the msm8998 and the msm8996 share much stuff.

Yes in the actual QC Source build the msm8998 will be different but mostly only in a few config files.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] pbedard:
Moved to 960f thanks for your hard work
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
Don't worry I will finish the above guide.

Were just starting to have fun.

A little research into the kexec.

My question is the host kernel hast to be patched.

Yes I know the samhung source is out.

But we still need all the proprietary drivers.

And what about signing. Maybe possible to patch the kernel without compressing it and still pass???

Kexec certianly is an answer. We know how to shut down the system cleanly so I don't think we need a full reboot. Safestrap.

I see its been bundled with kexec in the past.

So little documentation on safestrap. Wheres the motherload.

Kexec can do more that load android kernel.

It can load any elf kernel. I bet even LK you know little kernel. ABOOT.

Safestrap itself though. I see elf files for init.

What Kind of elf files are they. Are they elf kernels as well.

If there is a way to kexec or safestrap little kernel I have a build that i know is good that will work on our devices and be fully unlocked.

Unlocked when booted on that kernel.

For sure some interesting thoughts.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
A little more about the firehose and xml programmers

What Else can we do with the Firehose ??? :cowboy::fingers-crossed::cowboy::highfive:

Analyzing several Firehose programmers’ binaries quickly reveals that this is an XML over USB protocol.

What addresses.

Ill attach the file.

Open it in a text editor after you unzip it.

Peek is safe but don't go poke around unless you really know what your doing.

MaN Now we are starting to have some fun.:cool:

The upload rate over poke is extremely slow. This very poor throughput is due to the fact that each poke only allows uploading 8 bytes (encoded as 16 bytes) at a time, with 499 pokes per XML.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] JedidroidX:
Amazing stuff, this firehouse protocol from EDL mode bypassing the bootloader and implementing a secondary bootloader sounds promising. The peek and poke tags sound crucial to implementing some nasty code. I love it, I will be taking a day off work to play with all these goodies. My note 8 Verizon variant is on U1 and was flashed with the Samsung unlocked firmware to reduce the default verizon bloatware and other things. I will keep things simple by flashing a Firmware with the U2 bootloader before attempting to flash this little kernel I'm hearing about.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] plainbum:
I'm on U1 bootloader also, I blocked updates, :)
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
That is sorta the Idea but not entirely. The LK i'm talking about can't be flashed to the device. It will fail signature check and brick.

What i'm trying to figure out is how to use a hijack like safestrap and modify it to exe the LK. All work basically has to be done after all verification of the boot chain.

There is the possibility of using the peek and poke and the FIREHORSE framework. But to do that we will be needing to reverse aboot and decompile it in IDA.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] gsser:
This thread has a future lol, good work dude
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
In a nutshell here is one hypothesis that is stuck in my brain.

#1 Utilizing shell script we have the ability to hijack the boot chain. ( FISH or Safestrap ).

Both execute shell code that interrupt the boot process and shut down the running processes.

Safestrap uses e2fsck which is executed as root and takes control. ( Currently it runs a initrd )

Fish uses the /system/su.d/ for script execution.

What I want to do is hijack the boot the very same way.

But instead of loading a ramdisk I want to exe a patched version of LK.

Little Kernel is the aboot or appsbl or emmc_appsboot.mbn , or lk.

If I could find a binary that can correctly load and execute lk ( an ELF 32 ) that we can patch into the root filesystem of the hijack then the unlocked version of the lk will load custom boot.img / custom kernel without secboot failure because secboot is disabled.

Looking at the root filesystem of the hijack / or any normal boot - recovery image there is the (init).

the init binary ( which is a ELF32 ) I believe runs the normal init scripts in the root filesystem.

The .rc and .sh files that finish the device initialization.

The question is maybe it's possible to replace this init binary with our patched lk. There both ELF32 so whatever calls the init elf should be able to call the lk.elf.

But the roadblock could be or the question is are the flags and vairables like boot_mode still hanging around in memory with the device in the state its in. If the lk can't find the input it needs that sbl normally passes to it then it probably can run properly.

If so can we edit and recompile the LK to ignore or not even look for this stuffs to begin with. After all it is just an elf file.

Basically like the windows phones jump from loads UEFI and jumps to load little kernel to make windows phone android phone.

We want to run stock little kernel the hijack then execute lk again. ( But our own )

I'm sure enough that a dev can write us a shell script to put the device into the state it's in when sbl2 passes off to lk. I'm just not sure if it's possible by the time the kernel is loaded.

Anyway you get the idea. For now i'm gonna try to implement the hijack in a way that it uses the sdcard for rather then the ufs. This way when things go wrong ( They Will ) I won't be reflashing my device. Just pull the sdcard fix and try again.

This is interesting and im betting it's qualcomms implementation and exsist in our sbl too.

https://discuss.96boards.org/t/db820c-bootloader-lk-or-edk2/4308/8

Maybe we can trick xbl to bypass lk then goto UEFI and jumps back to lk somehow.

First thing first for me. I'm gonna see if i can get as much running off sdcard first for hijack part. Basically making safestrap treat my sdcard like it's a rom slot. Then figure out how to patch in lk.

And yes. KEXEC has some potential.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] JedidroidX:
I found some interesting information but this has probably been taken into consideration already. The link talks about arm processor and the use of Exceptional vectors and how the processor resets when certain traps are encountered. The link also goes into detail about Little Kernel and how to disassemble Aboot.

http://www.newandroidbook.com/Articles/aboot.html

Here's some of the info regarding image stripping:

Additionally, some vendors (notably Samsung) use their own implementation. The following steps will prepare aboot for disassembly:

Strip the image of its header: This can be done by using dd if=/dev/aboot of=aboot.sans.header bs=40 skip=1.

Trim the image to CodeSize bytes: This can be done by using split -b CodeSize aboot.sans.header. You will get two parts: xaa and xab. The xab contains the singature and certificates, so its size should be exactly that of (Certs + SigSize).

Following these steps, and loading the result into a disassembler (e.g. IDA or Hopper), you'll still need to rebase the image to the ImgBase value specified in the header (which you've stripped). You'll see something similar to this:

0F900000 ea000006 B 0x0F900020 ; B _reset ---------+

0F900004 ea00351c B 0x0F90D74C	; B _undef |

0F900008 ea003522 B 0x0F90D498 ; B _swi |

0F90000C ea003528 B 0x0F90D4B4 ; B _prefabt |

0F900010 ea00352E	B 0x0F90D4D0 ; B _dataabt |

0F900014 ea003534 B 0x0F90D4EC ; B _addrexc |

0F900018 ea003534	B 0x0F90D4F0 ; B _irq |

0F90001C ea00354B B	0x0F90D550 ; B _fiq |

_reset: |

0F900020 ee110f10 MRC p15, 0, R0,c1,c0, 0 ;<--------------+

0F900024 e3c00a0b BIC R0, R0, #0xB000

..
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
Yes that is the correct way.

To get into more details of why you would want to go that route can be found here. This can actually be used as a guide for us.

https://alephsecurity.com/2018/01/22/qualcomm-edl-5/

There are about 6 or 7 pages if you click the sections in the bottom of each read.

This is there FIREHORSE framework.

Its not a typo it is called firehorse.

https://github.com/alephsecurity/firehorse

The hurdle for us to get over taking this approach.

I'm pretty positive we need to be connected to UART for debugging.

The usb of the device is used to run the firehose. (HOSE)

The UART of the device is used to run the firehorse. (HORSE)

We need a Uart or Jtag Pinout Diagram.

To get uart we need to find the RX and TX pads on the motherboard.

Not as bad as trying to get the full JTAG Pinout but still requires access to the board.

As an example

https://www.96boards.org/documentat...nboard410c/guides/uart-serial-console.md.html

A simple device can find the pins for us. There is a more expensive Commercial version.

https://www.adafruit.com/product/1550

For a lot cheaper we could build.

https://github.com/cyphunk/JTAGenum

And the last method provided you have a totally destroyed device.

The msm8998 processor conforms to a Ball Grid Array spec.

As well as the UFS memory.

If you desolder the processor and or the UFS I know there are schematics available that tell what each pin of the BGA are. So knowing one side (THE BGA) you use a multimeter and check for continuity to the pads you think might be what your looking for. TX RX PWR GND

After all that you have to solder the wires to the pads on the motherboard or use a jig that makes the connections.

This cable could be used for connecting UART

https://www.arrow.com/en/products/ttl-232rg-vreg1v8-we/ftdi-chip

I do plan on running some of these experiments

Actually I'm gonna buy a dragonboard just to play with. The 820 isn't available on the public market yet but the 410 is and its only $75

https://www.arrow.com/en/products/dragonboard410c/arrow-development-tools

The 820 is the one that has the same chipset as the note.

My idea here is I can use the dragon to develop and test my work on a fully unlocked device that is very well documented.

Then once everything is perfected figure out how to replicate it on the Note 8.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
The potentially quicker route.

I honestly believe the idea of chain loading is totally viable.

The only thing stopin it right now is how to run the second lk.

In reality I believe that EFI Droid may be the answer to accomplish this.

So far a few of the other devs are taking some interest in this idea. [MENTION=4770483]afaneh92[/MENTION] is the person who ported safestrap to the samsung devices.

He also has ported EFI Droid to a S5 previously.

So far he's been helpful and pointed me in the right directions regarding safestrap.

I have requested him to help me port EFI Droid to the Note 8. He said he's really busy but might be able to find some time.

[MENTION=5545101]steadfasterX[/MENTION] is the dev who came up with Android FISH which is very similar to safestrap. I have been in contact with him and he too is going to be a major player in the development of some stuffs.

I myself am not an expert at anything. I know enough to get myself in trouble. My strengths are in shell scripting and utilizing the sd card for stuffs it was never meant to do.

[MENTION=1661600]kronickhigh[/MENTION]

He is going to school for arm assembly and hopefully he will be onboard. Maybe he can tell us how to run the lk.

Were all busy but it's gonna take several of us that are talented in different areas to make this go faster.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] kronickhigh:
I have been watching everything you guys are doing, but you guys are way over my head. I'm taking an intro to embedded systems course right now on the msp432. I doubt I'll be of much use, but I'm super interested.
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] kinglove1211:
N950U bootloader unlock.

[B[/B]

Hey I been following what you're trying to do and I got a Sprint note 8 on rev2 2 bootloader that I can offer up to find the jtag pads. Its screen was smashed and I removed it but it still boots up and it's basically already disassembled.I think the battery has went dead tho cause when I plug it in to charge the red light flashes but I just hooked it to the computer and it still shows as a note 8.So if you want it to dissect even further then let me know a place to send it to and I will get it out Monday morning.Thanks for the time you're putting in on an unlock. I'm sure the community is very thankful
[Samsung Galaxy Note 8 ROMs, Kernels, Recoveries, &] BigCountry907:
Thank you so much. I sent you a pm.

For sure that would be a big help.

Since its still operational once the jtag pinout is determined it could be used for testing.