• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

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

Search This thread

jrkruse

Recognized Contributor
Aug 9, 2009
8,169
12,425



What would you like me to do google it my self then copy and paste the definition for you. Your asking me what something is you don’t understand then try to find out. If you have no clue what edl 9008 mode is then you may want to read up about it before trying it. Im not being unhelpful I have many people ask the same questions over and over when the answer can be found with a simple search. Here is what a google search found for me
https://www.96boards.org/documentation/consumer/guides/qdl.md.html


Sent using some kind of device I modified
 

plainbum

Senior Member
Jun 26, 2011
459
31
Chicago - Western suburb
and your being lazy lol
And you are being a jerk.
elliwigy, I did Google it before I asked my question. I did not understand the results and explanations I found, so I came here and asked.
Maybe you don't understand everyone that comes here is on your level on knowledge and they way you treat people has an effect on this forum of whether new people feel welcomed to asking questions or not.

---------- Post added at 01:49 AM ---------- Previous post was at 01:42 AM ----------

What would you like me to do google it my self then copy and paste the definition for you. Your asking me what something is you don’t understand then try to find out. If you have no clue what edl 9008 mode is then you may want to read up about it before trying it. Im not being unhelpful I have many people ask the same questions over and over when the answer can be found with a simple search. Here is what a google search found for me
https://www.96boards.org/documentation/consumer/guides/qdl.md.html


Sent using some kind of device I modified
I'd like you to point out where someone else asked the same question as I did? Right never happened.
I did "Google it" before your unhelpful first reply. But I did't understand the answers. SO If it bothers you so much to reply to people like me then you should have simply ignored my question instead of being rude.
 

elliwigy

Forum Moderator / Recognized Dev / Dev Relations
Staff member
XDA App Taskforce
And you are being a jerk.
elliwigy, I did Google it before I asked my question. I did not understand the results and explanations I found, so I came here and asked.
Maybe you don't understand everyone that comes here is on your level on knowledge and they way you treat people has an effect on this forum of whether new people feel welcomed to asking questions or not.

---------- Post added at 01:49 AM ---------- Previous post was at 01:42 AM ----------


I'd like you to point out where someone else asked the same question as I did? Right never happened.
I did "Google it" before your unhelpful first reply. But I did't understand the answers. SO If it bothers you so much to reply to people like me then you should have simply ignored my question instead of being rude.

im with jrkruse on this one.. i dont think we could explain it any better than what uve supposedly already read and these types questions get old after so many..

instead of asking a very broad question that is easily found on 1000s of websites maybe u should try asking questions about what you dont understand and maybe ud get better replies..
 

DroidisLINUX

Senior Member
May 28, 2013
494
197


Kid grow a pair and shut up already this isn't your house, this isn't your forum he made a rom and did the work to show us how to flash a rom in edl mode. He described it pretty well. If you honestly read that Google post and still need clarification I am going to give it to you because you are like a baby and I am sick and tired of people blaming others for their own ignorance.

Edl = emergency download mode. 9008 is just a number.

In edl mode the USB becomes a flashing tool on Qualcomm device's, it will allow you to flash to the emmc. This makes it able to flash his rom onto of the system.img that was nougat with the locked eng boot loader because it is a signed Samsung rom. This then allows you to boot safestrap while maintaining pie. Or going back to oreo or a rooted nougat.

Edl might be able to do more it says you can use the firehose protocols so that .XML you see when you flash a combo file. It can run an xml program and read write peek poke files or operations on the phone's internal memory might allow for flashing of unsigned .img though the problem with that is Samsung has signed checks on all of there partitions on the hardware level so if the file isn't signed bootloader you may get a brick even if you just unzipped the boot and rezipped it. There are some exceptions like the eng bootloader seems to unlock the key to a modified system.img. however we have not gotten a boot.img to load that is not Samsung for this reason.
Though I am sure it is possible

This edl to pie is a step in the right direction, only problem is we should have done this on nougat so we could take advantage of the root. With this and the eng bootloader for nougat and safestrap you could probably get rom slots to work, but now we are on bl5 and less opportunities to get a multi rom or unsigned system.img to work. That being said do some of your own homework

If you read his post and googled that edl and read this and still don't understand then I suggest you go buy an iPhone cause you are in the wrong area of life.
 

elliwigy

Forum Moderator / Recognized Dev / Dev Relations
Staff member
XDA App Taskforce
of course it allows flashing unsigned img, how u think flashing a system.img works and getting safestrap? they modify the system.img therefore breaking sig..

edl needs the signed programmer and properly formatted xmls.. on n8 you can then flash anything pretty much..

problem is it doesnt disable secure boot.. so unsigned boot.img for example will flash but will not boot as it is checked by secure boot process whereas system isnt on n950u allowing to boot modified system..

reason why pie root is difficult on n8 is bcuz theres no pie combo which would have permissive boot.img so pie needs to use stock boot.img which will block root stuff bcuz of selinux enforcing

but yes, ur post is correct
 
  • Like
Reactions: freeblue192004

Delgoth

Senior Member
Dec 1, 2010
636
183
of course it allows flashing unsigned img, how u think flashing a system.img works and getting safestrap? they modify the system.img therefore breaking sig..

edl needs the signed programmer and properly formatted xmls.. on n8 you can then flash anything pretty much..

problem is it doesnt disable secure boot.. so unsigned boot.img for example will flash but will not boot as it is checked by secure boot process whereas system isnt on n950u allowing to boot modified system..

reason why pie root is difficult on n8 is bcuz theres no pie combo which would have permissive boot.img so pie needs to use stock boot.img which will block root stuff bcuz of selinux enforcing

but yes, ur post is correct

That's why I'm really about to give up Pie and just go back to Nougat. Now that I see the method to get a normal(ish) and usable system image onto the thing, that's all I wanted. I wanted my Command Line Access to understand the newer android versions. The hardware is still good regardless. Thanks peeps. I kind of overlooked the fact at first that, with safestrap we can easily remove the unusable factory system on Rev5. I use Nova Launcher Prime anyways.

Although as of like two days ago my USB port is now acting funny, I have to use my wireless charger more often than not. I might not even get to do this for a minute. I'm still no expert myself personally. I read a lot of your posts jrkruse and elliwigy, I can follow you most of the time, I just can't do it myself yet. Y'all have a way of explaining things well though I've found for me. Because I've done google searches many times for concepts in flashing that I get pretty weak results for a lot, but then I can find one explanation from one of you two that blows the 5 results in google out of the water with the details for our device.

I want to better understand what we can do with https://alephsecurity.com/2018/01/22/qualcomm-edl-2/

I know. Tried and pretty much failed. But I'm still kinda convinced there is a way to maybe use the edl method with newer exploits to maybe get some more work done. I don't know. I just like to try and understand how the engineers put the device together. Half the time I don't even have a Real Legit use for it, but I just wanted to learn it or about it. Just to know.
 
Last edited:

unimatrix725

Senior Member
Apr 13, 2011
246
46
Big Stoned Gap, VA
I have a subscription to (UAT) Uni-Android-Tool.

http://forum.gsmhosting.com/vbb/f1019/
I also have (BST) Best Smart Tools. The UAT is more updated.



I will be happy to help or contribute if these tools could help. I'm more concerned about fixing my v30 than anything. I would be willing to allow remote access to tools if that's possible.



UaT let me make rawprogram.xml& patch0.xml for LG. I need the loader/firehose for v30 which is suspiciously missing. Uat has a huge list of those loaders. Specifically Samsung devices. I'm going to read this whole thread. There's allot more leaked files for Samsung than LG...?
 

Eudeferrer

Senior Member
Aug 27, 2012
709
247
Miami
I'm pretty sure this thread has been abandoned since it's been over a month with no work or replies of any kind. I think everyone has moved to bigger and better devices.

Sent from my Pixel 3 XL
 

Eudeferrer

Senior Member
Aug 27, 2012
709
247
Miami
thats a pretty bold statement coming from someone with a Pixel 3 :eek:
You do realize Note 8s are already 2 generations behind and most people have moved on to newer devices right? I do have multiple devices including my beloved Note8. However, after using it for a while, I moved on. I still wish a solution would be found if anything just to defy Samsung. After the frustration with Samsung's locked bootloader and limited root, I went to a pixel 3XL which has served me well so far. I periodically check here for updates but notice the lack of development which I attribute (perhaps erroneously) to developers moving on.

Sent from my Pixel 3 XL
 

butchieboy

Senior Member
Feb 15, 2012
8,959
5,016
springfield.il
and? whats your point
Because his signature says Pixel could mean he posted with that. Easy cowboy..lol

Sent from my SM-N960U using Tapatalk

---------- Post added at 03:40 AM ---------- Previous post was at 03:38 AM ----------

Maybe has more than one device like many people[emoji6][emoji106]

Sent from my SM-N950U using Tapatalk
Hey Mike...things never change bro...[emoji1787][emoji23]

Sent from my SM-N960U using Tapatalk
 

Top Liked Posts

  • There are no posts matching your filters.
  • 35
    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: