{WIP} N950U Bootloader Unlocking (Build) / EDL Rom / SD-Card Booting {msm8998}
- Thread starter BigCountry907
- Start date
-
- Tags
- bootloader edl msm8998 n950u
Nothing buddy. I dont like to bicker here. No harm intended[emoji106][emoji481]
Sent from my SM-N975U using Tapatalk
Sent from my SM-N975U using Tapatalk
I've been following this thread for some time now, and haven't seen any posts from OP since February 2019.
I don't suppose it would be rude to ask for a progress update at this point in time? It would be nice to see anything uplifting.
(Using the Chimera rom on my phone at the moment, however it leaves much to be desired since System UI constantly crashes at seemingly random intervals. I suspect this would be fixed if it didn't have to stem from the dev rom.)
I don't suppose it would be rude to ask for a progress update at this point in time? It would be nice to see anything uplifting.
(Using the Chimera rom on my phone at the moment, however it leaves much to be desired since System UI constantly crashes at seemingly random intervals. I suspect this would be fixed if it didn't have to stem from the dev rom.)
Please don't be rude or reply with unhelpful/unrelated/unproven information. :/
Just because you've given up doesn't mean you need to spread negative opinions when others still have hope.
@BigCountry907 , Since my question was directed at you primarily, Would you be able to chime in? It's been almost a year.
Is this project on hold? Is there a snag? Have you given up on it? Either an update or closure is all I'm asking for.
With it being said by you thats its been over a year since anything has been done then its a pretty good assumption that the thread is probably dead and the OP has moved on
Sent from some device I modified
Thank you i have bootloader version 7 and don't like the firmware but have no way to go back.
It's a very sad news.
There is a new method that allows you to flash a prerooted Nougat firmware
SM-N950U Extreme Syndicate Root
SM-N950U Extreme Syndicate Root
yessir.. so is s9 s9+ and n9 with extreme syndicate root fyi
@BigCountry907
You might be able to take what you've found, try it on an older model, and it might work!(Samsung's signature and token were "theoretically interusable" before the S20 model)
Similar threads
- Poll
Top Liked Posts
-
There are no posts matching your filters.
-
35I 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:19State 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.
You can get it at safari https://www.safaribooksonline.com using a free trial.Code:Instant Optimizing Embedded System Using BusyBox
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.17Always follow A String Theory
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.
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
Locked or Unlocked
Load addresses. Re-Base if you have an IDA.
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.12The 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.
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_DEVICE12
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.
