{WIP} N950U Bootloader Unlocking (Build) / EDL Rom / SD-Card Booting {msm8998}

Search This thread

BotsOne

Senior Member
Apr 3, 2011
383
613
Colorado Springs
Thank you for offering to help.
Darn that u5 bootloaders.

Why won't the samfail method work on the U5.
Does the combination / service Rom allow a modified system image?
If you can use a modified system image we could try something.
One of 2 things would have to happen.
We would need root or use chrot or prot to write the safestrap script to the e2fsck in /system/bin.
Any shell script you name e2fsck and copy to /system/bin will run as root without su upon early boot.

Of course it better fix e2fsck so it runs as normal just like safestrap.

Otherwise still providing you can run modified system.
I could patch the recovery keys so we can flash a zip signed by our own keys.
Then you just pre-root the system image and flash it through recovery.

Normally to patch the recovery I would unpack the ramdisk and replace the /res/keys with my key but then recovery will fail signing.
However we can do the above and hexdump both recovery then get a diff of the files to locate the Keystring then open the recovery in hex editor and edit the Keystring in hex.

The only possible problem is that since the key is in the RAMDISK and the ramdisk is compressed hopefully the compression don't screw things up.

Yes the recovery is signed but the bytes we need to change are a Keystring always the same length. It is expected to be there. So hopefully it'll pass.
If the recovery is hashed byte for byte it could fail. For some reason I think it'll pass.

Far as your experience with the N950U.
I'm interested to know what your team tried to do with the edl bootloaders.
They seem much more stockish and less Samsung modified. So I wonder if the secure boot settings are more stockish and rely on Devinfo partition.

Thinking like putting together a combination Rom with that set of bootloaders. The GPT is quite different and would require some modification. But the GPT itself says much because the .pit partition table is not a part of it like the other rooms.

In the beginning of the /dev/block/sda there is a hidden partition between the end of the GPT table and the beginning of XBL. If you look you will find the .pit in there.

So normal and the combination rooms use the first 8 disk sectors were as the EDL uses only the First 6.

Lastly.
What are the best boxes. (Octoplus) (zx3) some other. I plan to buy one ir more. I have had tools in the past that come with access to firmware that's not publicly available. It's worth having the tools for that alone.

Here are my thoughts/questions on what I've read so far.

Has anyone successfully used EDL to flash that v2 bootloader? If so, do you know if the version field in the signed bootloader image header is being increased in order to revoke old images? If we had the GPT tables from the v5 bootloader could we potentially flash an older BL and therefore flash older security-patch versions? That would perhaps expose some exploits that may be helpful. Not entirely sure this is possible. Let me know if I'm missing something. EDL seems like it would be the best route to explore at this point, given you have those signed firehose files.

As far as the FOTA file, I cracked the one on the s8 myself before the password was made public using a tool I found on the web. We literally tried every thing we could with those files and in the end, they ended up being more of a distraction than anything. I almost shat myself when I cracked the file though, I thought I had discovered something big =/ EDIT: after reading a bit further it looks like perhaps you were able to make use of those files by modifying the recovery partition to accept your generated keypair? Am I reading that correctly? If so, what happened when you tried it? Would anything modified boot? Might be an avenue worth exploring. Could also prove to be another big time-suck too. IIRC we were leaked a set of QC Private keys and were unable to make use of those. I think we concluded that Sammy probably burned their own keys into the ROM. I saw that you were asking where to get the key that is burned into ROM to verify the boot.img I remember being able to pull it using EDL. We compared the hash of the burned key (Found through EDL) to the hash of the leaked QC keys and it was a mismatch so those keys that were leaked were worthless. Also - Sammy nerfed fastboot and it is unusable. I think I remember seeing some stuff about it while researching the s8 saying that it is still included, just disabled. Not sure about that one I'd have to poke around a bit. Even if it is there, no one has ever found a way to use it.

Elliwigy's idea about using non-volatile partitions might be worth exploring, apparently the bootloader is reading values from the misc. and other partitions. Engineer mode and crom/kiwibird are 2 other vectors he brought up that might be of use. He also mentioned T.flash or whatever it's called. That could possibly aid in filling up those empty partitions on the sdcard that you made. Just a thought.

I remember checking out the s8 aboot in IDA and I think there were some strings that were of interest.

Now, to *try and answer some of your questions, like I said I'm a bit rusty lol.

I don't think newer bl revisions will allow you to flash modified partitions. I think this is why samFail doesn't work anymore. I'm not positive, I don't know much about samFail. I like the idea of doing a hexdump & diff diff of the recovery files that would be a good learning experience even if nothing comes of it. As far as what I've done concerning EDL most of what I did I was getting a Sahara error. Can't remember exactly but I think it was due to the xml being modified incorrectly. Seems like you know what you are doing in that area so maybe we can make something happen on the note. As far as boxes go I really don't have any experience using one, just the good ole arch linux box =D I've heard the zx3 name being thrown around in some Chinese threads that were about similar chipsets, but like I said I have zero experience.

That being said, Sammy has gotten very good at securing these devices. No doubt about that, but I've always believed that no device is ever impenetrable. Where there is a will there's a way =)

You got any better way of communicating? Hangouts or I've got a discord server we could start a room on there I think it's got better logging than Hangouts. Either way let me know your thoughts and keep up the good work.
 

BigCountry907

Senior Member
Oct 15, 2015
508
675
This is kind of a circle Because we can't load fish until after safestrap, but we need fish to be able to boot a safestrap rom I think,your going to need to rebuild safestrap for note 8. I have faith.

Fish and safestrap are very similar.
They both hijack the boot in pretty much the same way.
Safestrap has code that wires what slot to boot.

Essentially I'm going through both safestrap and fish and re-writing a lot of code to use it a bit differently.
One of the things will be booting some partitions off of the sdcard.
At this point even severly locked down devices will have a chance as long as you can get the e2fsck file swapped out in /system for the hijack.

I'm going to call it Hot-Boot.
Basically it will re-boot the boot from booted state. Hence Hot-Boot.
Due to the level of control we have using this method everything should work out well.
Hot-Boot utilizes the e2fsck.bin that in executed even before anything in su.d
Everything executes as ROOT so other than getting the e2fsck.bin replaced by the Hot-Boot (e2fsck.sh) in the device /system root isn't even needed.

Hot-Boot will load a ramdisk and run the init binary to run TWRP Recovery.
A similar process will be used to Hot-Boot the device.
Hot-Boot will take over the boot and shutdown all processes.
The root filesystem will be replaced by the Hot-Boot filesystem.
The Hot-Boot filesystem will launch U-Boot and not the init.bin.
U-Boot will then Load a Kernel and the rest of the initrd for a custom android system.

Provided I don't have any trouble executing U-Boot this should all work smoothly.
All customized stuffs will be loaded from the sdcard partitions. So other than the 1 file nothing on the emmc / UFS will need changed.
 

BigCountry907

Senior Member
Oct 15, 2015
508
675
Here are my thoughts/questions on what I've read so far.

Has anyone successfully used EDL to flash that v2 bootloader?

after reading a bit further it looks like perhaps you were able to make use of those files by modifying the recovery partition to accept your generated keypair?

I saw that you were asking where to get the key that is burned into ROM to verify the boot.img I remember being able to pull it using EDL. We compared the hash of the burned key (Found through EDL) to the hash of the leaked QC keys and it was a mismatch so those keys that were leaked were worthless.

I don't think newer bl revisions will allow you to flash modified partitions. I think this is why samFail doesn't work anymore.

That being said, Sammy has gotten very good at securing these devices. No doubt about that, but I've always believed that no device is ever impenetrable. Where there is a will there's a way =)

You got any better way of communicating?

I have not flashed the full edl package but i have flashed single partitions so the firehose and edl indeed work for V2. The edl rom is only the bootloaders so it will currently only boot into Download Mode.
Far as running a full rom with the edl bootloaders......That is one Idea I have. But we would have to use the EDL GPT. And basically build the AOSP to run with it.

Far as the recovery goes I can patch the keys in the recovery so you can sideload any update.zip signed with the keypair. If the U5 combination Rom allows a modified /system the recovery could be a way to flash it. I'm unsure why samfail don't work on Rev 5.
If it is because odin flashing the system don't work then the recovery trick might work.

Far as communication im on Freenode in the carbonfusion channel alot.
But thats steadfasterx channel for FISH.
If you want to set up a channel on freenode we can use that.

Currently I'm working on writing my Hot-Boot Script.
If I can get U-Boot to fire I believe we will have some type of fastboot.
U-Boot apparently has a form of fastboot.
If we can get fastboot up then we can fastboot boot Little Kernel and actually Hot-Boot LK.
In other words we could port some thing similar to efidroid.

This is a definite possibility.
If there exist or if someone could compile a binary executable that can load Little Kernel that is all we need. We would use that binary to Hot-Boot a unlocked version of Little Kernel from the safestrap / fish hijacked enviornment.
Similarly I think U-Boot will be able to load from the hijack. But it could require some type of binary to load it as well.

First I have to get all the Hot-Boot code written. :eek:
 

BigCountry907

Senior Member
Oct 15, 2015
508
675

No worries.
I have finished researching U-Boot.
I'm positive we can get this working. And with U-Boot we can load custom Kernels / Custom Aboot / Custom System you get the idea.
I am currently re-working the safestrap and fish hijacks. I'm writing the Hot-Boot scripts using some of the techniques applied in both of those hijacks.
In the end the Hot-Boot Hijack will simply load the U-Boot.bin rather than executing the init.

I have had a limited amount of time to work on this and since im working solo it only goes so fast.
At any rate there is no doubt in my mind that I can get this working.
Realistically we might be looking around christmas time. Could be sooner but theres a ton of work to do.

On a positive note the Hot-Boot Hijack will be fairly portable. Meaning it will work with any device that normally is capable of running safestrap.
Root isn't even really required. Everything runs as root on bootup from the e2fsck trick.

I call it a Trick because during normal bootup e2fsck is automatically executed as a part of the normal boot process.
What we are doing is renaming /system/bin/e2fsck to /system/bin/e2fsck.bin
Then we are taking our System Shell Script and naming it e2fsck.
So on boot up when e2fsck is called it is running our script. Similar to the init.d provided by supersu.

the only problem i see is that with DM-Verity like on the note 9 we need to at a minimum be able to call a shell script with the e2fsck.
Might not be able to edit e2fsck unless something like samfail allows to run a modified system.
There is always a way though. That i am sure. Hopefully after x mas i can save the money to get a note 9.

In a nutshell all is well. I am positive this is going to work for the * series of samsung devices.
AS said its a matter of time to write the code build U-Boot and get it all debugged.

:cowboy::cowboy:
 

BigCountry907

Senior Member
Oct 15, 2015
508
675
Actually I've not got an answer yet as to why samfail won't work.
Is it that the Odin cannot write the rooted system the way it works with older bootloaders.
Or is it that the boot image in the combination firmware will not allow permissive selinux and or a modified system image because of dm-verity.

Each of those questions answers a different problem to solve.
I believe we can use the EDL firehose to write a modified system. So we can pre root the system image and install the hotboot scripts then flash the image to the device in EDL mode.
I know antiroolback means you can't flash the bootloaders but that doesn't mean that the firehose won't work.

That needs to be tested. I'm also pretty sure I can patch the recovery to let us flash images.

Now if a custom system cannot be run then that's a different story.
So maybe the samfail team can tell us what's not working.

Flashing the system with edl would require the system.img to be split into sparse chunks and you need the patch zeros xml but it's easy enough to do.

The other option could be hex patching the e2fsck file to call safestrap or hotboot from a sdcard partition. All depends on how touchy the dm-verity is. In E2fsck it would only take one line of code to start the process.

Beyond that if all else fail then possibly we can build the bootable sdcard. Either approach the system data cache boot and safestrap can all be on a SD card and boot from the and never touch the UFS.
 

JohnKCG

Member
Jun 14, 2017
15
9
Well, I recently bought an snapdragon note 8 because I always liked snapdragon more than exynoss, because in past Mali wasn't as good as adreno, that and custom rom potential, after reading that the USA note was locked down I thought I burned cash and well, I like to modify the hell out of my devices, that is in fact why I stick with android rather than Ios, I must say thank you Big Country, you are doing this not for cash, not for fame, but because you just want to help people like me learn this kind of programming and boost custom rom like world for a device as competent as the note 8, thanks also to safestrap and fish team, from what I read your efforts are also making this possible, sorry for my bad English by the way
 

SomeGuy2008

Senior Member
Aug 22, 2008
167
24
Just came across this thread. My vzw note 8 has been sitting at stock N950USQU1AQH7 security patch level 8/1/17 since I got phone in hopes that a bootloader unlock would eventually come. I used package disabler (I think thats what its called) to disable automatic system updates. If im reading this correct, this is still very much a WIP and a method to unlock the bootloader and use custom roms (such as LOS) will likely be an option at some point? From my reading it will likely not be a simple process to get a stock n8 to have an unlocked bootloader using this method?

Thanks for all your hard work BigCountry907, Looks like you have been and are continuing to put a lot of time and effort into this!

~SG
 

Jhfreeze

Senior Member
Oct 30, 2014
459
438
Texas
Wow, read most of this thread and am very hopeful for your efforts and everything you've found so far. Your doing some great work here I wish I had the coding skills to help you. I'll be following your thread and will help if there's any way I can. I already got the note 9 N960F/DS and giving the TMO N8 N950U to the wife rooted BLv3 on Chimera...like she even cares, but it'll be available for testing any final build your able to put together.
 
  • Like
Reactions: nerdbyproxy

taysandman

Member
May 15, 2016
31
8
High level indeed. Excited about your enthusiasm and potential.
My linux...I’m of no help…useless…

Unless... you point me in the direction of a donation page. Unfortunately it won't be 200k, but perhaps others would like to join in too.

Damn Silicon Nazis...Together we can end this oppression.
Remember that all through history, there have been tyrants and murderers, and for a time, they seem invincible. But in the end, they always fall. Always.” ~ Gandi :)
 
Last edited:
  • Like
Reactions: Saafir

BigCountry907

Senior Member
Oct 15, 2015
508
675
State of Booting Custom Systems

I have made some progress although things are getting a bit more complex.
After spending some time analyzing Safestrap and it's inner workings I do believe that i'm headed in the right direction.

If you view safestrap for what it is ( a boot hijack ) but understand the potential of the method it certainly is our window to get in. Safestrap in a nutshell is a bash script that is executed nearly after the kernel is loaded.

So what does that mean?
Basically the device is booted to a point where bare metal programming techniques can be used.
Bare metal programming involves bringing up the embedded system by compiling the functionality we need into binaries that can be executed at this boot state.

For example if you take a quick look at this book.
Code:
 Instant Optimizing Embedded System Using BusyBox
You can get it at safari https://www.safaribooksonline.com using a free trial.
It's short to the point and easy to follow.

This shows how we can create a minimal boot image.
Including how to compile busybox and add command functionality to the build then make a ramdisk and init files.

Anything like this is executable using the safestrap method. By safestrap method i mean taking the e2fsck file and writing a shell script to replace it. e2fsck is a filesystem check and run by the system after the kernel is loaded.

So yes you could follow the instructions in that book and boot the N950U into a bash shell on startup.

Now the limitation we have to overcome is dealing with the kernel.
We don't have the ability to hijack the boot process before the kernel is loaded.
Loading a new kernel on top of a running kernel is not the easiest thing to to.

If the stock kernel had loadable module support enabled then we could build the kexec module and load the kernel using kexec. This is how multiboot in safestrap works on devices that can run kexec. But the stock samsung kernel dosen't have loadable module support.

This is where I hope to use U-Boot.
So lets talk about U-Boot a little.
In our case U-Boot is actually a 4th stage bootloader.
The boot sequence is like this.

(System as it is now)
PBL then SBL1 then SBL2 then Little Kernel then android boot.img

(System booting with u-boot)
PBL then SBL1 then SBL2 then Little Kernel then u-boot.img then android boot.img

In a unlocked device the standard boot.img is replaced by U-boot.img. ( NOT U-BOOT .bin ! ).
Be careful differentiating the files of u-boot.
U-boot.bin and U-boot.img are not the same. U-boot.img is the u-boot.bin the kernel and the device tree packed together using (the u-boot version) mkbootimg.

Initially I was hoping that u-boot.img ( the packed U-boot ) was triggered by init like the android boot image is. If that were the case this would be simple because we would boot into safeboot mount the partitions we want to run (SLOT) and then fire init. Essentially the way safestrap runs TWRP recovery.

This is not the case. What happens is little kernel is actually loading U-Boot.bin into ram in place of the android kernel. In a sense you could say U-Boot is the kernel at that point. Once U-Boot.bin is loaded into ram it executes and overwrites itself with the android kernel.
Or interrupting U-Boot during boot will boot into the U-boot shell. From the U-Boot shell we could load anything. ELF, Kernels, Stand alone programs, Literally anything. In a nutshell U-Boot is basically a binary that can load code into any Ram Memory address and start it's execution.

Look at U-Boot in the same sense as the "fastboot boot" command.
Using ( fastboot boot boot.img ) fastboot is loading the boot.img into memory and executing it on the fly.

As example this is the process U-Boot uses to load the linux kernel on the dragonboard.
This is the boot script.

Code:
[SIZE="5"][COLOR="Green"]#1[/COLOR][/SIZE][COLOR="RoyalBlue"] it sets up the command line vairable that gets passed to the kernel. Same as commandline in android boot.img.[/COLOR]
bootargs=root=/dev/mmcblk1p1 rw rootwait console=tty0 console=ttyMSM0,115200n8 rootfs=ext4 noinitrd selinux=0

[SIZE="5"][COLOR="SeaGreen"]#2[/COLOR][/SIZE] [COLOR="DeepSkyBlue"]used by u-boot to know what addresses to load the kernel and device tree too.
"bootm" is the command that executes the loading.
[COLOR="red"][SIZE="5"]"ext4load" [/SIZE][/COLOR]and "[SIZE="5"][COLOR="Red"]bootm[/COLOR][/SIZE]" -->> Functions that execute from the loaded u-boot.bin (important)
[/COLOR]
bootcmd=ext4load mmc 1:1 ${kernel_addr_r} /boot/uImage; ext4load mmc 1:1 ${fdt_addr_r} /boot/apq8016-sbc.dtb; bootm ${kernel_addr_r} - ${fdt_addr_r}

[COLOR="SeaGreen"][SIZE="5"]#3[/SIZE][/COLOR] [COLOR="RoyalBlue"]the uenvcmd is executed by the u-boot.bin and is just the variable that is equal to the bootcmd.[/COLOR]
uenvcmd=run bootcmd

So whats the problem here?
We cannot directly execute the u-boot.bin. It's loaded into ram before the kernel.
So lets talk about the environments. By that i mean the boot state of the device.

We have Kernel Space { This is basically commands executed in the kernel }
We have User Space { This is the system after the kernel is loaded and some programs start to run.
We have U-Boot Environment. { This is the device with the U-Boot.bin loaded into Ram before the kernel is loaded.

Normally this is not so important because the normal boot process is loading U-Boot prior to loading the kernel. So normally we start out in the U-Boot environment.
In the U-Boot environment we have access to the ext4load and bootm commands as well as everything else U-Boot contains.

In our case we are in Userspace ( the kernel is loaded already ).
We do not have the ext4load or bootm commands and also the command line ( U-Boot Variables ) do not exist. They exist in the U-Boot environment that we don't have because we haven't loaded u-boot.img we have loaded android boot.img.

This is where things get complicated.
We know that once the kernel is loaded that U-boot.bin no longer exist in RAM. And that's in a normal case where the system was booted with U-Boot initially. Once the kernel is running we are in user space and the u-boot environment is non existent. For our scenario where in that boat. Little kernel has loaded the android kernel.

Now developers being developers of course it makes sense to have the ability to load U-Boot on the fly for testing u-boot builds without flashing the device.
This is how i will proceed to verify the concept.
Loading U-Boot over TFTP.

Not totally ideal but a workable start.
Code:
U-Boot implements tftp command to download the kernel and filesystem (in case of ramdisk) images to SDRAM. You can then choose to directly boot the newly downloaded images or write them to non-volatile memory using U-Boot commands and then copy the the images to SDRAM from this memory for subsequent boots. 
http://processors.wiki.ti.com/index.php/Booting_Linux_kernel_using_U-Boot

Now the one catch here and maybe i'm wrong but it seems that the device may be booted into the u-boot environment therefore the device or Target is booted to the U-Boot shell and then the Kernel and device tree are loaded over tftp.
https://community.arm.com/dev-platforms/w/docs/236/tftp-remote-network-kernel-using-u-boot

We want to load the linux kernel using u-boot but we have to load u-boot first.
Remember i said u-boot is loaded in place of the kernel.
So rather than tftp the kernel and starting it we are going to tftp the uboot.bin and start it.

This becomes trivial because if you remember we are trying to do this from userspace.
If you also remember u-boot no longer exist in ram after the kernel is loaded.

That means we need to compile the U-Boot functions that are needed to tftp boot into standalone binaries that can be executed from user space. Sounds a bit far out there right.

Not really...we have the source code and in the beginning of this post I linked you to a book that shows you how to take this kind of source and run it on bare metal. It will be a little bit of work though.

So what do we need? Is this even possible?
Looking here answers some questions..
https://blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:tftp_loading_files
Code:
Common Examples
u-boot.bin

[COLOR="Red"][SIZE="5"]A common example of using the tftp command is loading up a U-Boot binary to test:[/SIZE][/COLOR]

bfin> tftp 0x1000 u-boot.bin
Using Blackfin EMAC device
TFTP from server 192.168.0.2; our IP address is 192.168.0.15
Filename 'u-boot.bin'.
Load address: 0x1000
Loading: ############################
done
Bytes transferred = 141016 (226d8 hex)
bfin> go 0x1000
## Starting application at 0x00001000 ...

Here we loaded the u-boot.bin file into external memory at address 0x1000. Then we proceeded to simply start executing at that address.

Ok that's getting pretty close but were still not quite there yet.
This is loading u-boot.bin which is what we want to do but it is still doing it from the U-boot environment. "The target is booted to the u-boot shell" ( IN U-BOOT ENV )

The closest to what i'm trying to do so far is exactly this.
https://devtalk.nvidia.com/default/...load-and-boot-from-ram-using-tftpboot-method/

Everything is just about working in that thread except the guy needs to set the cpu registers.
We may or may not run into that since where taking the device almost to bare metal using safestrap. We will need to set up some environment variables and possibly set some cpu registers.

Im thinking that we are going to need to build some of the u-boot functions as standalone binaries. Fortunately this is easy for some functions. If we tie these functions into the safestrap boot using the method contained in the previously mentioned book that may work. We also have the option of possibly adding these functions into the busybox binary.

Here is a example that we will need to follow to set u-boot environment variables from userspace.

https://www.denx.de/wiki/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux

So in a nutshell that is abut where i am at.
I have a dragonboard to test on to prove the concept.
I compiled u-boot last night so im about ready to get testing.

This way i can get u-boot up and running properly on the dragon.
I will start out the normal way by flashing u-boot.img to the boot.img partition.
After all is well and working correctly I can set up dragonboard like the Note 8.
Port safestrap type hijack to the dbragon then try to load the know working u-boot from the safestrap environment. Once this is working its just a matter of porting things over to the note 8.
 

JohnKCG

Member
Jun 14, 2017
15
9
Looks like you are slowly getting to make things working, I recently received my note 8, thankfully it has the very first u1 bootloader and is the US unlocked one, having an S5 on oreo and a tab s2 on pie, I can easily stay on nougat until Android pie lands on note 8, which I estimate is around may or even further, if you need testers just shout it, am pretty sure that a lot of people here who aren't on your level of knowledge (just like me) want to contribute to your work on any possible way, thanks a ton for your hard work and let's be positive that we are unlocking the note 8
 

iunlock

Senior Member
May 22, 2010
2,005
975
Galaxy
I have made some progress although things are getting a bit more complex.
After spending some time analyzing Safestrap and it's inner workings I do believe that i'm headed in the right direction.

If you view safestrap for what it is ( a boot hijack ) but understand the potential of the method it certainly is our window to get in. Safestrap in a nutshell is a bash script that is executed nearly after the kernel is loaded.

So what does that mean?
Basically the device is booted to a point where bare metal programming techniques can be used.
Bare metal programming involves bringing up the embedded system by compiling the functionality we need into binaries that can be executed at this boot state.

For example if you take a quick look at this book.
Code:
 Instant Optimizing Embedded System Using BusyBox
You can get it at safari https://www.safaribooksonline.com using a free trial.
It's short to the point and easy to follow.

This shows how we can create a minimal boot image.
Including how to compile busybox and add command functionality to the build then make a ramdisk and init files.

Anything like this is executable using the safestrap method. By safestrap method i mean taking the e2fsck file and writing a shell script to replace it. e2fsck is a filesystem check and run by the system after the kernel is loaded.

So yes you could follow the instructions in that book and boot the N950U into a bash shell on startup.

Now the limitation we have to overcome is dealing with the kernel.
We don't have the ability to hijack the boot process before the kernel is loaded.
Loading a new kernel on top of a running kernel is not the easiest thing to to.

If the stock kernel had loadable module support enabled then we could build the kexec module and load the kernel using kexec. This is how multiboot in safestrap works on devices that can run kexec. But the stock samsung kernel dosen't have loadable module support.

This is where I hope to use U-Boot.
So lets talk about U-Boot a little.
In our case U-Boot is actually a 4th stage bootloader.
The boot sequence is like this.

(System as it is now)
PBL then SBL1 then SBL2 then Little Kernel then android boot.img

(System booting with u-boot)
PBL then SBL1 then SBL2 then Little Kernel then u-boot.img then android boot.img

In a unlocked device the standard boot.img is replaced by U-boot.img. ( NOT U-BOOT .bin ! ).
Be careful differentiating the files of u-boot.
U-boot.bin and U-boot.img are not the same. U-boot.img is the u-boot.bin the kernel and the device tree packed together using (the u-boot version) mkbootimg.

Initially I was hoping that u-boot.img ( the packed U-boot ) was triggered by init like the android boot image is. If that were the case this would be simple because we would boot into safeboot mount the partitions we want to run (SLOT) and then fire init. Essentially the way safestrap runs TWRP recovery.

This is not the case. What happens is little kernel is actually loading U-Boot.bin into ram in place of the android kernel. In a sense you could say U-Boot is the kernel at that point. Once U-Boot.bin is loaded into ram it executes and overwrites itself with the android kernel.
Or interrupting U-Boot during boot will boot into the U-boot shell. From the U-Boot shell we could load anything. ELF, Kernels, Stand alone programs, Literally anything. In a nutshell U-Boot is basically a binary that can load code into any Ram Memory address and start it's execution.

Look at U-Boot in the same sense as the "fastboot boot" command.
Using ( fastboot boot boot.img ) fastboot is loading the boot.img into memory and executing it on the fly.

As example this is the process U-Boot uses to load the linux kernel on the dragonboard.
This is the boot script.

Code:
[SIZE="5"][COLOR="Green"]#1[/COLOR][/SIZE][COLOR="RoyalBlue"] it sets up the command line vairable that gets passed to the kernel. Same as commandline in android boot.img.[/COLOR]
bootargs=root=/dev/mmcblk1p1 rw rootwait console=tty0 console=ttyMSM0,115200n8 rootfs=ext4 noinitrd selinux=0

[SIZE="5"][COLOR="SeaGreen"]#2[/COLOR][/SIZE] [COLOR="DeepSkyBlue"]used by u-boot to know what addresses to load the kernel and device tree too.
"bootm" is the command that executes the loading.
[COLOR="red"][SIZE="5"]"ext4load" [/SIZE][/COLOR]and "[SIZE="5"][COLOR="Red"]bootm[/COLOR][/SIZE]" -->> Functions that execute from the loaded u-boot.bin (important)
[/COLOR]
bootcmd=ext4load mmc 1:1 ${kernel_addr_r} /boot/uImage; ext4load mmc 1:1 ${fdt_addr_r} /boot/apq8016-sbc.dtb; bootm ${kernel_addr_r} - ${fdt_addr_r}

[COLOR="SeaGreen"][SIZE="5"]#3[/SIZE][/COLOR] [COLOR="RoyalBlue"]the uenvcmd is executed by the u-boot.bin and is just the variable that is equal to the bootcmd.[/COLOR]
uenvcmd=run bootcmd

So whats the problem here?
We cannot directly execute the u-boot.bin. It's loaded into ram before the kernel.
So lets talk about the environments. By that i mean the boot state of the device.

We have Kernel Space { This is basically commands executed in the kernel }
We have User Space { This is the system after the kernel is loaded and some programs start to run.
We have U-Boot Environment. { This is the device with the U-Boot.bin loaded into Ram before the kernel is loaded.

Normally this is not so important because the normal boot process is loading U-Boot prior to loading the kernel. So normally we start out in the U-Boot environment.
In the U-Boot environment we have access to the ext4load and bootm commands as well as everything else U-Boot contains.

In our case we are in Userspace ( the kernel is loaded already ).
We do not have the ext4load or bootm commands and also the command line ( U-Boot Variables ) do not exist. They exist in the U-Boot environment that we don't have because we haven't loaded u-boot.img we have loaded android boot.img.

This is where things get complicated.
We know that once the kernel is loaded that U-boot.bin no longer exist in RAM. And that's in a normal case where the system was booted with U-Boot initially. Once the kernel is running we are in user space and the u-boot environment is non existent. For our scenario where in that boat. Little kernel has loaded the android kernel.

Now developers being developers of course it makes sense to have the ability to load U-Boot on the fly for testing u-boot builds without flashing the device.
This is how i will proceed to verify the concept.
Loading U-Boot over TFTP.

Not totally ideal but a workable start.
Code:
U-Boot implements tftp command to download the kernel and filesystem (in case of ramdisk) images to SDRAM. You can then choose to directly boot the newly downloaded images or write them to non-volatile memory using U-Boot commands and then copy the the images to SDRAM from this memory for subsequent boots. 
http://processors.wiki.ti.com/index.php/Booting_Linux_kernel_using_U-Boot

Now the one catch here and maybe i'm wrong but it seems that the device may be booted into the u-boot environment therefore the device or Target is booted to the U-Boot shell and then the Kernel and device tree are loaded over tftp.
https://community.arm.com/dev-platforms/w/docs/236/tftp-remote-network-kernel-using-u-boot

We want to load the linux kernel using u-boot but we have to load u-boot first.
Remember i said u-boot is loaded in place of the kernel.
So rather than tftp the kernel and starting it we are going to tftp the uboot.bin and start it.

This becomes trivial because if you remember we are trying to do this from userspace.
If you also remember u-boot no longer exist in ram after the kernel is loaded.

That means we need to compile the U-Boot functions that are needed to tftp boot into standalone binaries that can be executed from user space. Sounds a bit far out there right.

Not really...we have the source code and in the beginning of this post I linked you to a book that shows you how to take this kind of source and run it on bare metal. It will be a little bit of work though.

So what do we need? Is this even possible?
Looking here answers some questions..
https://blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:tftp_loading_files
Code:
Common Examples
u-boot.bin

[COLOR="Red"][SIZE="5"]A common example of using the tftp command is loading up a U-Boot binary to test:[/SIZE][/COLOR]

bfin> tftp 0x1000 u-boot.bin
Using Blackfin EMAC device
TFTP from server 192.168.0.2; our IP address is 192.168.0.15
Filename 'u-boot.bin'.
Load address: 0x1000
Loading: ############################
done
Bytes transferred = 141016 (226d8 hex)
bfin> go 0x1000
## Starting application at 0x00001000 ...

Here we loaded the u-boot.bin file into external memory at address 0x1000. Then we proceeded to simply start executing at that address.

Ok that's getting pretty close but were still not quite there yet.
This is loading u-boot.bin which is what we want to do but it is still doing it from the U-boot environment. "The target is booted to the u-boot shell" ( IN U-BOOT ENV )

The closest to what i'm trying to do so far is exactly this.
https://devtalk.nvidia.com/default/...load-and-boot-from-ram-using-tftpboot-method/

Everything is just about working in that thread except the guy needs to set the cpu registers.
We may or may not run into that since where taking the device almost to bare metal using safestrap. We will need to set up some environment variables and possibly set some cpu registers.

Im thinking that we are going to need to build some of the u-boot functions as standalone binaries. Fortunately this is easy for some functions. If we tie these functions into the safestrap boot using the method contained in the previously mentioned book that may work. We also have the option of possibly adding these functions into the busybox binary.

Here is a example that we will need to follow to set u-boot environment variables from userspace.

https://www.denx.de/wiki/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux

So in a nutshell that is abut where i am at.
I have a dragonboard to test on to prove the concept.
I compiled u-boot last night so im about ready to get testing.

This way i can get u-boot up and running properly on the dragon.
I will start out the normal way by flashing u-boot.img to the boot.img partition.
After all is well and working correctly I can set up dragonboard like the Note 8.
Port safestrap type hijack to the dbragon then try to load the know working u-boot from the safestrap environment. Once this is working its just a matter of porting things over to the note 8.
Excellent breakdown. Thank you for that. One of the finest pieces I've read on xda. Bravo.

Sent from my SM-N950U using Tapatalk
 

dazemc

Senior Member
Oct 18, 2014
211
85
30
Enumclaw
I know my way around BASH quite well if you need help in that department. I can set up a build environment pretty easily as well....
Also, thank you for introducing me to TFTP. Without doing much more searching this sounds very similar to netboot.

EDIT: It is a function of netboot ?*♂️
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 34
    I think it's time to get this party started.

    There is hope ->> Initial Analysis

    I have built a spreadsheet that takes a hexdump of the GPT tables and decodes them.
    This provides the means of generating the Partition.xml and Rawprogram.xml.
    Also one can learn alot by analyzing the GPT.

    With the ability to generate the partition.xml it can then be converted to partitions.txt that the Dragon-Board db_boot_tools (mksdcard) can be used to burn the SD Card.

    The ability to build the rawprogram.xml also provides us the opportunity to build EDL roms and flash them using the emmcdl.exe or the QDL download tool for dragonboard.
    This means we can build unbrick roms / anything we want and flash it in edl mode unrestricted.

    Currently there is available the Factory Samsung EDL Recovery Files for Boot Loader Rev 2.
    https://www.needrom.com/download/unbrick-samsung-qualcom-9008-files/
    I have looked at them and they are legitimate.

    Analyzing the GPT tables included in the EDL package I can determine that these are Standard Qualcomm Bootloaders that operate on a Standard QC partition table.
    My theory is that being standard Qualcomm Images the bootloader is unlockable by standard Qualcomm method.
    The board_info partition. As seen here.

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

    Another great resource is everything for the dragonboard 820c. Its the same chipset.
    A ton of available source code is at our disposal.

    In a nutshell because i dont have a lot of time to get into details at the moment.

    I ran my first SD Card Test.
    Simply burned the Dragonboard 820c SD Rescue image to a sd card.
    https://www.96boards.org/documentat...board820c/installation/board-recovery.md.html

    To my surprise if you insert this SD Card into the device and boot into download mode.
    You will see FRP=OFF.

    This proves my theory that the possibility of booting a full system on a sd card is real.
    The sd card is read early in the boot chain.
    I have to investigate and see exactly how this is setting frp off.
    This partition table has the FRP partition.
    The note 8 uses the persist partition for the frp switch.
    So how the sd card is turing FRP off is the question I am working on answering at the moment.

    I can conclude.
    The device is definitely reading partitions off the SD Card.
    It is beating the FRP lock out of the box.

    This means either the stock bootloaders have functionality built in to look for the FRP partition that normally is not present on our devices. Meaning the stock bootloaders can read other partitions of the sd card.

    Or somewhere in the boot chain one or more of the dragonboard bootloaders are executing off the sd card.
    If that is the case Hope is very Great for us. Dragonboard has available the LK source code that we can modify and build.
    Dragonboard also has pre-compiled bootloaders specifically for booting on sd card that we can use.

    Also the samsung bootloaders in the EDL files are very promising.
    If we can build the aosp system to go with the edl bootloaders ( If they are unlockable ) were golden.

    If the Dragonboard Bootloaders are executing on the sd card were even more golden.
    If this is the case we can even use the dragonboard 820c AOSP build ( includes sources )
    All we really should need to change would relate to hardware differences.

    Seems crazy but there is no rational explanation as to how the sd card turns FRP off other than the possibility of somewhere in the boot chain the drangonboard BL is executed on the sdcard.
    Unless like i said the samsung bootloaders have the stock qualcomm functionality as well.

    Either way you look at it. We defeated the FRP protection by flashing a sdcard and booting with the sdcard in the device. That is enough proof in itself that there is hope.

    It would be superb if some of the other Samsung Devs, Like the samfail team would climb on board to work on some of this. I am very skilled in some aspects and in other aspects i could use some help.
    Either way give me a couple months and we will be there.

    My only question is has anyone ever been actually paid by Samsung for finding Exploits?
    From what ive read on there site it says $200,000 K or more for a bootloader unlock.
    Makes me wonder if I should be sharing this information with anyone.
    But money aside...thats what samsung wants. There using greed against us. They don't want us to work together.

    I will be getting into some very deep presentations of my work as time provides.
    That way the community can learn and help on this exciting journey.

    Damm I still can't believe it turned FRP off. :silly:
    Just goes to show ya. Don't doubt it till you try it no matter how far out it may seem. :highfive:
    19
    State of Booting Custom Systems

    I have made some progress although things are getting a bit more complex.
    After spending some time analyzing Safestrap and it's inner workings I do believe that i'm headed in the right direction.

    If you view safestrap for what it is ( a boot hijack ) but understand the potential of the method it certainly is our window to get in. Safestrap in a nutshell is a bash script that is executed nearly after the kernel is loaded.

    So what does that mean?
    Basically the device is booted to a point where bare metal programming techniques can be used.
    Bare metal programming involves bringing up the embedded system by compiling the functionality we need into binaries that can be executed at this boot state.

    For example if you take a quick look at this book.
    Code:
     Instant Optimizing Embedded System Using BusyBox
    You can get it at safari https://www.safaribooksonline.com using a free trial.
    It's short to the point and easy to follow.

    This shows how we can create a minimal boot image.
    Including how to compile busybox and add command functionality to the build then make a ramdisk and init files.

    Anything like this is executable using the safestrap method. By safestrap method i mean taking the e2fsck file and writing a shell script to replace it. e2fsck is a filesystem check and run by the system after the kernel is loaded.

    So yes you could follow the instructions in that book and boot the N950U into a bash shell on startup.

    Now the limitation we have to overcome is dealing with the kernel.
    We don't have the ability to hijack the boot process before the kernel is loaded.
    Loading a new kernel on top of a running kernel is not the easiest thing to to.

    If the stock kernel had loadable module support enabled then we could build the kexec module and load the kernel using kexec. This is how multiboot in safestrap works on devices that can run kexec. But the stock samsung kernel dosen't have loadable module support.

    This is where I hope to use U-Boot.
    So lets talk about U-Boot a little.
    In our case U-Boot is actually a 4th stage bootloader.
    The boot sequence is like this.

    (System as it is now)
    PBL then SBL1 then SBL2 then Little Kernel then android boot.img

    (System booting with u-boot)
    PBL then SBL1 then SBL2 then Little Kernel then u-boot.img then android boot.img

    In a unlocked device the standard boot.img is replaced by U-boot.img. ( NOT U-BOOT .bin ! ).
    Be careful differentiating the files of u-boot.
    U-boot.bin and U-boot.img are not the same. U-boot.img is the u-boot.bin the kernel and the device tree packed together using (the u-boot version) mkbootimg.

    Initially I was hoping that u-boot.img ( the packed U-boot ) was triggered by init like the android boot image is. If that were the case this would be simple because we would boot into safeboot mount the partitions we want to run (SLOT) and then fire init. Essentially the way safestrap runs TWRP recovery.

    This is not the case. What happens is little kernel is actually loading U-Boot.bin into ram in place of the android kernel. In a sense you could say U-Boot is the kernel at that point. Once U-Boot.bin is loaded into ram it executes and overwrites itself with the android kernel.
    Or interrupting U-Boot during boot will boot into the U-boot shell. From the U-Boot shell we could load anything. ELF, Kernels, Stand alone programs, Literally anything. In a nutshell U-Boot is basically a binary that can load code into any Ram Memory address and start it's execution.

    Look at U-Boot in the same sense as the "fastboot boot" command.
    Using ( fastboot boot boot.img ) fastboot is loading the boot.img into memory and executing it on the fly.

    As example this is the process U-Boot uses to load the linux kernel on the dragonboard.
    This is the boot script.

    Code:
    [SIZE="5"][COLOR="Green"]#1[/COLOR][/SIZE][COLOR="RoyalBlue"] it sets up the command line vairable that gets passed to the kernel. Same as commandline in android boot.img.[/COLOR]
    bootargs=root=/dev/mmcblk1p1 rw rootwait console=tty0 console=ttyMSM0,115200n8 rootfs=ext4 noinitrd selinux=0
    
    [SIZE="5"][COLOR="SeaGreen"]#2[/COLOR][/SIZE] [COLOR="DeepSkyBlue"]used by u-boot to know what addresses to load the kernel and device tree too.
    "bootm" is the command that executes the loading.
    [COLOR="red"][SIZE="5"]"ext4load" [/SIZE][/COLOR]and "[SIZE="5"][COLOR="Red"]bootm[/COLOR][/SIZE]" -->> Functions that execute from the loaded u-boot.bin (important)
    [/COLOR]
    bootcmd=ext4load mmc 1:1 ${kernel_addr_r} /boot/uImage; ext4load mmc 1:1 ${fdt_addr_r} /boot/apq8016-sbc.dtb; bootm ${kernel_addr_r} - ${fdt_addr_r}
    
    [COLOR="SeaGreen"][SIZE="5"]#3[/SIZE][/COLOR] [COLOR="RoyalBlue"]the uenvcmd is executed by the u-boot.bin and is just the variable that is equal to the bootcmd.[/COLOR]
    uenvcmd=run bootcmd

    So whats the problem here?
    We cannot directly execute the u-boot.bin. It's loaded into ram before the kernel.
    So lets talk about the environments. By that i mean the boot state of the device.

    We have Kernel Space { This is basically commands executed in the kernel }
    We have User Space { This is the system after the kernel is loaded and some programs start to run.
    We have U-Boot Environment. { This is the device with the U-Boot.bin loaded into Ram before the kernel is loaded.

    Normally this is not so important because the normal boot process is loading U-Boot prior to loading the kernel. So normally we start out in the U-Boot environment.
    In the U-Boot environment we have access to the ext4load and bootm commands as well as everything else U-Boot contains.

    In our case we are in Userspace ( the kernel is loaded already ).
    We do not have the ext4load or bootm commands and also the command line ( U-Boot Variables ) do not exist. They exist in the U-Boot environment that we don't have because we haven't loaded u-boot.img we have loaded android boot.img.

    This is where things get complicated.
    We know that once the kernel is loaded that U-boot.bin no longer exist in RAM. And that's in a normal case where the system was booted with U-Boot initially. Once the kernel is running we are in user space and the u-boot environment is non existent. For our scenario where in that boat. Little kernel has loaded the android kernel.

    Now developers being developers of course it makes sense to have the ability to load U-Boot on the fly for testing u-boot builds without flashing the device.
    This is how i will proceed to verify the concept.
    Loading U-Boot over TFTP.

    Not totally ideal but a workable start.
    Code:
    U-Boot implements tftp command to download the kernel and filesystem (in case of ramdisk) images to SDRAM. You can then choose to directly boot the newly downloaded images or write them to non-volatile memory using U-Boot commands and then copy the the images to SDRAM from this memory for subsequent boots. 
    http://processors.wiki.ti.com/index.php/Booting_Linux_kernel_using_U-Boot

    Now the one catch here and maybe i'm wrong but it seems that the device may be booted into the u-boot environment therefore the device or Target is booted to the U-Boot shell and then the Kernel and device tree are loaded over tftp.
    https://community.arm.com/dev-platforms/w/docs/236/tftp-remote-network-kernel-using-u-boot

    We want to load the linux kernel using u-boot but we have to load u-boot first.
    Remember i said u-boot is loaded in place of the kernel.
    So rather than tftp the kernel and starting it we are going to tftp the uboot.bin and start it.

    This becomes trivial because if you remember we are trying to do this from userspace.
    If you also remember u-boot no longer exist in ram after the kernel is loaded.

    That means we need to compile the U-Boot functions that are needed to tftp boot into standalone binaries that can be executed from user space. Sounds a bit far out there right.

    Not really...we have the source code and in the beginning of this post I linked you to a book that shows you how to take this kind of source and run it on bare metal. It will be a little bit of work though.

    So what do we need? Is this even possible?
    Looking here answers some questions..
    https://blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:tftp_loading_files
    Code:
    Common Examples
    u-boot.bin
    
    [COLOR="Red"][SIZE="5"]A common example of using the tftp command is loading up a U-Boot binary to test:[/SIZE][/COLOR]
    
    bfin> tftp 0x1000 u-boot.bin
    Using Blackfin EMAC device
    TFTP from server 192.168.0.2; our IP address is 192.168.0.15
    Filename 'u-boot.bin'.
    Load address: 0x1000
    Loading: ############################
    done
    Bytes transferred = 141016 (226d8 hex)
    bfin> go 0x1000
    ## Starting application at 0x00001000 ...
    
    Here we loaded the u-boot.bin file into external memory at address 0x1000. Then we proceeded to simply start executing at that address.

    Ok that's getting pretty close but were still not quite there yet.
    This is loading u-boot.bin which is what we want to do but it is still doing it from the U-boot environment. "The target is booted to the u-boot shell" ( IN U-BOOT ENV )

    The closest to what i'm trying to do so far is exactly this.
    https://devtalk.nvidia.com/default/...load-and-boot-from-ram-using-tftpboot-method/

    Everything is just about working in that thread except the guy needs to set the cpu registers.
    We may or may not run into that since where taking the device almost to bare metal using safestrap. We will need to set up some environment variables and possibly set some cpu registers.

    Im thinking that we are going to need to build some of the u-boot functions as standalone binaries. Fortunately this is easy for some functions. If we tie these functions into the safestrap boot using the method contained in the previously mentioned book that may work. We also have the option of possibly adding these functions into the busybox binary.

    Here is a example that we will need to follow to set u-boot environment variables from userspace.

    https://www.denx.de/wiki/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux

    So in a nutshell that is abut where i am at.
    I have a dragonboard to test on to prove the concept.
    I compiled u-boot last night so im about ready to get testing.

    This way i can get u-boot up and running properly on the dragon.
    I will start out the normal way by flashing u-boot.img to the boot.img partition.
    After all is well and working correctly I can set up dragonboard like the Note 8.
    Port safestrap type hijack to the dbragon then try to load the know working u-boot from the safestrap environment. Once this is working its just a matter of porting things over to the note 8.
    17
    Always follow A String Theory

    :D No pun intended.
    A lot can be determined by running the strings command on a elf file. It's sorta google for developers.

    Lets take a quick Look.

    From the xbl.elf in the edl package.

    This is our boot sequence.
    SEC Image Loaded, Delta
    XBLRamDump Image Loaded, Delta
    PMIC Image Loaded, Delta
    APDP Image Loaded, Delta
    QSEE Dev Config Image Loaded, Delta
    QSEE Image Loaded, Delta
    QHEE Image Loaded, Delta
    RPM Image Loaded, Delta
    STI Image Loaded, Delta
    ABL Image Loaded, Delta
    APPSBL Image Loaded, Delta
    DDR Training Image Loaded, Delta


    What can we boot from.
    /home/dpi/qb5_8814/workspace/GREATQLTE_USA_SINGLE/nhlos/boot_images/QcomPkg/XBLLoader/boot_pbl_v2.c
    PBL, Start
    bootable_media_detect_entry, Start
    bootable_media_detect_success, Start

    /home/dpi/qb5_8814/workspace/GREATQLTE_USA_SINGLE/nhlos/boot_images/QcomPkg/XBLLoader/boot_hash.c
    DDR Frequency, %d MHz
    PBL Patch Ver: %d
    Core 0 Frequency, %d MHz
    Boot Interface:
    NAND
    eMMC
    SDCARD
    None
    Unknown


    Locked or Unlocked
    /home/dpi/qb5_8814/workspace/GREATQLTE_USA_SINGLE/nhlos/boot_images/QcomPkg/XBLLoader/boot_logger.c
    Secure Boot:
    %s @ 0x%08x = 0x%016llx
    %s @ 0x%08x = 0x%08x
    Boot Config
    JTAG ID
    OEM ID
    Serial Number
    OEM Config Row 0
    OEM Config Row 1
    Feature Config Row 0
    Feature Config Row 1
    Raw PTE Row 3
    Raw PTE Row 0


    Load addresses. Re-Base if you have an IDA.


    /home/dpi/qb5_8814/workspace/GREATQLTE_USA_SINGLE/nhlos/boot_images/Build/Msm8998LA_Core/RELEASE_CLANG38LINUX/AARCH64/QcomPkg/XBLCore/XBLCore/DEBUG/Sec.dll
    [Config]
    Version = 3
    MaxMemoryRegions = 64
    [MemoryMap]
    # EFI_RESOURCE_ EFI_RESOURCE_ATTRIBUTE_ EFI_MEMORY_TYPE ARM_REGION_ATTRIBUTE_
    #MemBase, MemSize, MemLabel(32 Char.), BuildHob, ResourceType, ResourceAttribute, MemoryType, CacheAttributes
    #--------------------- DDR -----
    0x80000000, 0x05800000, "Kernel", AddMem, SYS_MEM, SYS_MEM_CAP, Reserv, WRITE_BACK_XN
    0x86000000, 0x00200000, "SMEM", AddMem, MEM_RES, UNCACHEABLE, Reserv, UNCACHED_UNBUFFERED_XN
    0x94000000, 0x09400000, "DXE Heap", AddMem, SYS_MEM, SYS_MEM_CAP, Conv, WRITE_BACK_XN
    0x9D400000, 0x02400000, "Display Reserved", AddMem, MEM_RES, SYS_MEM_CAP, MaxMem, WRITE_BACK_XN
    0x9F800000, 0x00200000, "FV Region", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
    0x9FA00000, 0x00200000, "ABOOT FV", AddMem, SYS_MEM, SYS_MEM_CAP, Reserv, WRITE_BACK_XN
    0x9FC00000, 0x00300000, "UEFI FD", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK
    0x9FF00000, 0x0008C000, "SEC Heap", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
    0x9FF8C000, 0x00001000, "CPU Vectors", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK
    0x9FF8D000, 0x00003000, "MMU PageTables", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
    0x9FF90000, 0x00040000, "UEFI Stack", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
    0x9FFD0000, 0x00027000, "DBI Dump", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
    0x9FFF7000, 0x00008000, "Log Buffer", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
    0x9FFFF000, 0x00001000, "Info Blk", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
    [RegisterMap]
    #--------------------- Other -----
    0x14680000, 0x00040000, "IMEM Base", NoHob, MMAP_IO, INITIALIZED, Conv, NS_DEVICE
    0x146BF000, 0x00001000, "IMEM Cookie Base", AddDev, MMAP_IO, INITIALIZED, Conv, NS_DEVICE
    0x16000000, 0x01000000, "QDSS_STM", AddDev, MMAP_IO, INITIALIZED, Conv, NS_DEVICE
    #--------------------- Register --
    0x00620000, 0x00020000, "UFS_RUMI", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x00070000, 0x00010000, "BOOT_CONFIG", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x00100000, 0x000B0000, "GCC CLK CTL", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x00778000, 0x00008000, "RPM MSG RAM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x00780000, 0x00007000, "SECURITY CONTROL", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x00790000, 0x00010000, "PRNG_CFG_PRNG", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x010A3000, 0x00001000, "MPM2_SLP_CNTR", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x010AA000, 0x00001000, "MPM2_TSENS0", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x010AB000, 0x00001000, "MPM2_TSENS0_TM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x010AC000, 0x00001000, "MPM2_PSHOLD", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x010AD000, 0x00001000, "MPM2_TSENS1", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x010AE000, 0x00001000, "MPM2_TSENS1_TM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x01C00000, 0x00007000, "PCIE WRAPPER AHB", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x01DA0000, 0x00020000, "UFS UFS REGS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x01DC0000, 0x00040000, "CRYPTO0 CRYPTO", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x01FC0000, 0x00026000, "TCSR_TCSR_REGS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x03400000, 0x00C00000, "TLMM CSR", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x08000000, 0x02800000, "PMIC ARB SPMI", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x05065000, 0x00009000, "GPUCC", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x06000000, 0x00100000, "QDSS_QDSS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x06400000, 0x00200000, "HMSS_QLL", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x0A800000, 0x0011B000, "USB30_PRIM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x0A920000, 0x00010000, "USB_RUMI", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x0C000000, 0x00200000, "PERIPH_SS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x0C800000, 0x00800000, "MMSS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x17900000, 0x00030000, "QTIMER", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x17A00000, 0x00010000, "APCS_GIC500_GICD", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x17B00000, 0x00100000, "APCS_GIC500_GICR", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x17800000, 0x00100000, "APCS_CC", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x1B000000, 0x01000000, "PCIE WRAPPER AXI", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x0502A000, 0x00002000, "GPMU_BLOCK0", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x05026000, 0x00002000, "GPMU_DRAM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    0x05030000, 0x00002000, "GPU_ISENSE", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    [ConfigParameters]
    # Update count if more than default 30 entries #
    ConfigParameterCount = 52


    So at a minimum we can see that this bootloader can boot from sd-card. The address table shows where things are loading in memory. This is good for disassembling the elf files.

    I really think the sd card can get us a way in.
    12
    The Goal

    In the end this is the boot sequence we would like to see.
    If you looked at the strings in the previous post you will recognize some of the information here.
    ================================================================================
    Successful boot sequence
    ================================================================================

    Format: Log Type - Time(microsec) - Message - Optional Info
    Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
    S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.0-00301
    S - IMAGE_VARIANT_STRING=M8996LAB
    S - OEM_IMAGE_VERSION_STRING=crm-ubuntu68
    S - Boot Interface: UFS
    S - Secure Boot: Off
    S - Boot Config @ 0x00076044 = 0x000001c9
    S - JTAG ID @ 0x000760f4 = 0x4003e0e1
    S - OEM ID @ 0x000760f8 = 0x00000000
    S - Serial Number @ 0x00074138 = 0x2e8844ce
    S - OEM Config Row 0 @ 0x00074188 = 0x0000000000000000
    S - OEM Config Row 1 @ 0x00074190 = 0x0000000000000000
    S - Feature Config Row 0 @ 0x000741a0 = 0x0050000010000100
    S - Feature Config Row 1 @ 0x000741a8 = 0x00fff00001ffffff
    S - Core 0 Frequency, 1228 MHz
    B - 0 - PBL, Start
    B - 10412 - bootable_media_detect_entry, Start
    B - 47480 - bootable_media_detect_success, Start
    B - 47481 - elf_loader_entry, Start
    B - 49027 - auth_hash_seg_entry, Start
    B - 49129 - auth_hash_seg_exit, Start
    B - 82403 - elf_segs_hash_verify_entry, Start
    B - 84905 - PBL, End
    B - 86955 - SBL1, Start
    B - 182969 - usb: hs_phy_nondrive_start
    B - 183305 - usb: PLL lock success - 0x3
    B - 186294 - usb: hs_phy_nondrive_finish
    B - 190442 - boot_flash_init, Start
    D - 30 - boot_flash_init, Delta
    B - 197548 - sbl1_ddr_set_default_params, Start
    D - 30 - sbl1_ddr_set_default_params, Delta
    B - 205509 - boot_config_data_table_init, Start
    D - 200659 - boot_config_data_table_init, Delta - (60 Bytes)
    B - 410713 - CDT Version:3,Platform ID:24,Major ID:1,Minor ID:0,Subtype:0
    B - 415410 - Image Load, Start
    D - 22570 - PMIC Image Loaded, Delta - (37272 Bytes)
    B - 437980 - pm_device_init, Start
    B - 443744 - PON REASON:pM0:0x200000061 PM1:0x200000021
    B - 480161 - PM_SET_VAL:Skip
    D - 40016 - pm_device_init, Delta
    B - 482083 - pm_driver_init, Start
    D - 2928 - pm_driver_init, Delta
    B - 488671 - pm_sbl_chg_init, Start
    D - 91 - pm_sbl_chg_init, Delta
    B - 495442 - vsense_init, Start
    D - 0 - vsense_init, Delta
    B - 505171 - Pre_DDR_clock_init, Start
    D - 396 - Pre_DDR_clock_init, Delta
    B - 509045 - ddr_initialize_device, Start
    B - 512766 - 8996 v3.x detected, Max frequency = 1.8 GHz
    B - 522373 - ddr_initialize_device, Delta
    B - 522404 - DDR ID, Rank 0, Rank 1, 0x6, 0x300, 0x300
    B - 526247 - Basic DDR tests done
    B - 594994 - clock_init, Start
    D - 274 - clock_init, Delta
    B - 598349 - Image Load, Start
    D - 4331 - QSEE Dev Config Image Loaded, Delta - (46008 Bytes)
    B - 603808 - Image Load, Start
    D - 5338 - APDP Image Loaded, Delta - (0 Bytes)
    B - 612409 - usb: UFS Serial - 2f490ecf
    B - 616801 - usb: fedl, vbus_low
    B - 620431 - Image Load, Start
    D - 55418 - QSEE Image Loaded, Delta - (1640572 Bytes)
    B - 675849 - Image Load, Start
    D - 2013 - SEC Image Loaded, Delta - (4096 Bytes)
    B - 683413 - sbl1_efs_handle_cookies, Start
    D - 457 - sbl1_efs_handle_cookies, Delta
    B - 691892 - Image Load, Start
    D - 14396 - QHEE Image Loaded, Delta - (254184 Bytes)
    B - 706319 - Image Load, Start
    D - 14061 - RPM Image Loaded, Delta - (223900 Bytes)
    B - 721111 - Image Load, Start
    D - 3233 - STI Image Loaded, Delta - (0 Bytes)
    B - 727913 - Image Load, Start
    D - 34709 - APPSBL Image Loaded, Delta - (748716 Bytes)
    B - 762713 - SBL1, End
    D - 680028 - SBL1, Delta
    S - Flash Throughput, 94000 KB/s (2959024 Bytes, 31250 us)
    S - DDR Frequency, 1017 MHz
    Android Bootloader - UART_DM Initialized!!!

    [0] BUILD_VERSION=
    [0] BUILD_DATE=16:07:51 - Nov 17 2017
    [0] welcome to lk
    [10] platform_init()
    [10] target_init()
    [10] RPM GLink Init
    [10] Opening RPM Glink Port success
    [10] Opening SSR Glink Port success
    [20] Glink Connection between APPS and RPM established
    [20] Glink Connection between APPS and RPM established
    [40] UFS init success
    [80] Qseecom Init Done in Appsbl
    [80] secure app region addr=0x86600000 size=0x2200000[90] TZ App region notif returned with status:0 addr:86600000 size:35651584
    [100] TZ App log region register returned with status:0 addr:916d4000 size:4096
    [100] Qseecom TZ Init Done in Appsbl
    [120] Loading cmnlib done
    [120] qseecom_start_app: Loading app keymaster for the first time
    [150] <8>keymaster: ""KEYMASTER Init ""
    [160] Selected panel: none
    Skip panel configuration
    [160] pm8x41_get_is_cold_boot: cold boot
    [170] boot_verifier: Device is in ORANGE boot state.
    [180] Device is unlocked! Skipping verification...
    [180] Loading (boot) image (348160): start
    [190] Loading (boot) image (348160): done
    [190] use_signed_kernel=1, is_unlocked=1, is_tampered=0.
    [200] Your device has been unlocked and cant be trusted.
    Wait for 5 seconds before proceeding

    [5200] mdtp: mdtp_img loaded
    [5210] mdtp: is_test_mode: test mode is set to 1
    [5210] mdtp: read_metadata: SUCCESS
    [5230] LK SEC APP Handle: 0x1
    [5230] Return value from recv_data: 14
    [5240] Return value from recv_data: 14
    [5250] Return value from recv_data: 14
    [5260] DTB Total entry: 1, DTB version: 3
    [5260] Using DTB entry 0x00000123/00000000/0x00000018/0 for device 0x00000123/00030001/0x00010018/0
    [5270] cmdline: androidboot.bootdevice=624000.ufshc androidboot.verifiedbootstate=orange androidboot.veritymode=enforcing androidboot.serialno=2f490ecf androidboot.baseband=apq mdss_mdp.panel=0
    [5290] Updating device tree: start
    [5290] Updating device tree: done
    [5290] Return value from recv_data: 14
    [5300] RPM GLINK UnInit
    [5300] Qseecom De-Init Done in Appsbl
    [5300] booting linux @ 0x80080000, ramdisk @ 0x82200000 (0), tags/device tree @ 0x82000000
    [5310] Jumping to kernel via monitor

    U-Boot 2017.11-00145-ge895117 (Nov 29 2017 - 10:04:06 +0100)
    Qualcomm-DragonBoard 820C

    DRAM: 3 GiB
    PSCI: v1.0
    MMC: [email protected]: 0
    In: [email protected]
    Out: [email protected]
    Err: [email protected]
    Net: Net Initialization Skipped
    No ethernet found.
    Hit any key to stop autoboot: 0
    switch to partitions #0, OK
    mmc0 is current device
    Scanning mmc 0:1...
    Found /extlinux/extlinux.conf
    Retrieving file: /extlinux/extlinux.conf
    433 bytes read in 71 ms (5.9 KiB/s)
    1: nfs root

    Retrieving file: /uImage
    19397184 bytes read in 2024 ms (9.1 MiB/s)
    append: root=/dev/nfs rw nfsroot=192.168.1.2:/db820c/rootfs,v3,tcp rootwait ip=dhcp consoleblank=0 console=tty0 console=ttyMSM0,115200n8 earlyprintk earlycon=msm_serial_dm,0x75b0000 androidboot.bootdevice=624000.ufshc androidboot.verifiedbootstate=orange androidboot.ver0

    Retrieving file: /apq8096-db820c.dtb
    38134 bytes read in 37 ms (1005.9 KiB/s)

    ## Booting kernel from Legacy Image at 95000000 ...
    Image Name: Dragonboard820c
    Image Type: AArch64 Linux Kernel Image (uncompressed)
    Data Size: 19397120 Bytes = 18.5 MiB
    Load Address: 80080000
    Entry Point: 80080000


    Specifically what we want to accomplish.

    Format: Log Type - Time(microsec) - Message - Optional Info
    Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
    S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.0-00301
    S - IMAGE_VARIANT_STRING=M8996LAB
    S - OEM_IMAGE_VERSION_STRING=crm-ubuntu68
    S - Boot Interface: UFS
    S - Secure Boot: Off
    S - Boot Config @ 0x00076044 = 0x000001c9
    S - JTAG ID @ 0x000760f4 = 0x4003e0e1
    S - OEM ID @ 0x000760f8 = 0x00000000
    S - Serial Number @ 0x00074138 = 0x2e8844ce
    S - OEM Config Row 0 @ 0x00074188 = 0x0000000000000000
    S - OEM Config Row 1 @ 0x00074190 = 0x0000000000000000
    S - Feature Config Row 0 @ 0x000741a0 = 0x0050000010000100
    S - Feature Config Row 1 @ 0x000741a8 = 0x00fff00001ffffff

    S - Core 0 Frequency, 1228 MHz
    B - 0 - PBL, Start
    B - 10412 - bootable_media_detect_entry, Start
    B - 47480 - bootable_media_detect_success, Start

    If we can set this the bootloader is unlocked.
    Boot Config @ 0x00076044 = 0x000001c9

    From our xbl.elf strings.
    Secure Boot:
    %s @ 0x%08x = 0x%016llx
    %s @ 0x%08x = 0x%08x
    Boot Config
    JTAG ID
    OEM ID
    Serial Number
    OEM Config Row 0
    OEM Config Row 1
    Feature Config Row 0
    Feature Config Row 1

    0x00070000, 0x00010000, "BOOT_CONFIG", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
    12

    No worries.
    I have finished researching U-Boot.
    I'm positive we can get this working. And with U-Boot we can load custom Kernels / Custom Aboot / Custom System you get the idea.
    I am currently re-working the safestrap and fish hijacks. I'm writing the Hot-Boot scripts using some of the techniques applied in both of those hijacks.
    In the end the Hot-Boot Hijack will simply load the U-Boot.bin rather than executing the init.

    I have had a limited amount of time to work on this and since im working solo it only goes so fast.
    At any rate there is no doubt in my mind that I can get this working.
    Realistically we might be looking around christmas time. Could be sooner but theres a ton of work to do.

    On a positive note the Hot-Boot Hijack will be fairly portable. Meaning it will work with any device that normally is capable of running safestrap.
    Root isn't even really required. Everything runs as root on bootup from the e2fsck trick.

    I call it a Trick because during normal bootup e2fsck is automatically executed as a part of the normal boot process.
    What we are doing is renaming /system/bin/e2fsck to /system/bin/e2fsck.bin
    Then we are taking our System Shell Script and naming it e2fsck.
    So on boot up when e2fsck is called it is running our script. Similar to the init.d provided by supersu.

    the only problem i see is that with DM-Verity like on the note 9 we need to at a minimum be able to call a shell script with the e2fsck.
    Might not be able to edit e2fsck unless something like samfail allows to run a modified system.
    There is always a way though. That i am sure. Hopefully after x mas i can save the money to get a note 9.

    In a nutshell all is well. I am positive this is going to work for the * series of samsung devices.
    AS said its a matter of time to write the code build U-Boot and get it all debugged.

    :cowboy::cowboy:
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone