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

BigCountry907 · Oct 15, 2018 at 6:14 PM

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:

BigCountry907 · Oct 16, 2018 at 12:00 AM

Always 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.

BigCountry907 · Oct 16, 2018 at 4:25 PM

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.

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

xRaZeR_FuZioNx · Oct 19, 2018 at 2:29 AM

BigCountry907 said:
This partition table has the FRP partition.

The actual FRP partition in this SD recovery image is empty. And so are a bunch of other ones; they all seem to be blanked out with 00s. Maybe they are used for mounting the images? But in that case, what would be responsible for mounting them? I think one of the partitions that actually has an ELF header might be worth looking at.

BigCountry907 · Oct 19, 2018 at 12:50 PM

The sdcard image is for the dragonboard to boot into fastboot mode.
So you are correct. Most of the partitions are empty.
The bootloaders are present on the sdcard.
I havent determined if they are running or not.

The only byte that matters on the FRP partition is the last byte.
00 = FRP Lock Off
01= FRP Lock On.

If you install Liveboot then the log files on bootup are saved.
Looking in that log I can see the sdcard partitions are being mounted.

If you
cat /proc/mounts

You will see many are mounted.

This was just an initial test to see if the sd card would get read on boot.
It does so now im working on building a card with the V2 samfail installed.

My hope is to boot a full system off of the sdcard.
Then development can be done without touching the UFS.
If we can get the bootloaders to run off the sdcard as well this will open a huge door for us.

I will let you know how it goes with my next test.

BigCountry907 · Oct 19, 2018 at 2:22 PM

The thing that is significant thus far is the fact that booting with the sdcard IS SETTING frp LOCK TO OFF.
The normal Samsung Note 8 partition scheme uses Persist and Persistent partition for setting the FRP on or off.
If both persist and persistent are ZERO then FRP = off.

So the stock bootloader will read partitions that are (whitelisted) and verified to be Qualcomm Unique GUID Type.
Possibly even boot a bootloader that is not signed by Samsung but signed by Qualcomm.
If Qualcomm signed bootloaders will run then we can actually compile sign and boot our own bootloader.

Here is how.
https://www.96boards.org/documentation/consumer/dragonboard/dragonboard820c/guides/

Building the SD rescue image

The scripts to build the SD rescue image can be found here:
https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader-dragonboard820c.yaml,
where we defined the script parameters and variables

https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader/dragonboard820c/builders.sh:
where the actual commands are being executed.

Same Chip so we can use the source code.

BigCountry907 · Oct 19, 2018 at 3:57 PM

I will attach here the first revision of my GPT Decoder Spreadsheet.
It takes the GPT which is the UFS Partition Table and decodes it.
Once the GPT is decoded we can use it to make the following.

Rawprogram.xml >> used for flashing in EDL Mode like emmcdl.exe or dragonboard "QDL"
Partition.xml >> used for making GPT files and the Rawprogram.xml and is used by qualcomm tools like Ptool.py Msp.py ext.
Partitions.txt >> used for flashing sd cards or writable devices using mksdcard script.

So essentially the GPT is the foundation of everything. The GPT is what the samsung .PIT files write.
You can pull the GPT off the device using the shell.
Here are the commands.

The MAIN GPT. Tables
The main GPT is the first 24kb of each device block on the UFS (ie sda, sdb, sdc, sdd)

Code:

adb shell
su
dd if=/dev/block/sda of=/sdcard/gpt_main0.bin bs=1024 count=24
dd if=/dev/block/sdb of=/sdcard/gpt_main1.bin bs=1024 count=24
dd if=/dev/block/sdc of=/sdcard/gpt_main2.bin bs=1024 count=24
dd if=/dev/block/sdd of=/sdcard/gpt_main3.bin bs=1024 count=24

The BACKUP GPT. Tables
The backup GPT is the last 20kb of each device block on the UFS (ie sda, sdb, sdc, sdd)
So the start address of the backup gpt is total size in kb of disk - 20kb.
To get the skip= number you have to take the total kb of the disk and subtract 20 kb from it.
This is for the U2 bootloader.

Code:

adb shell
su
dd if=/dev/block/sda of=/sdcard/backup-sda-gpt.bin bs=1 skip=63916978176
dd if=/dev/block/sdb of=/sdcard/backup-sdb-gpt.bin bs=1 skip=4173824
dd if=/dev/block/sdc of=/sdcard/backup-sdc-gpt.bin bs=1 skip=4173824
dd if=/dev/block/sdd of=/sdcard/backup-sdd-gpt.bin bs=1 skip=62894080

We will be needing someone to pull the GPT tables from all the bootloader versions except for U2.
I am on U2 and this spreadsheet is for U2.
I will need the other GPT tables to build the unbrick for other bootloader versions.
Look at the spreadsheet and the different sheets in it.
You will get an Idea of how it works.
I use formulas and link to the pasted GPT tables to decode them.
This spreadsheet still needs work so some of the data is manually edited at this time.
But for U2 bootloader rev this spreadsheet is correct.

Use open office to use or look at this spreadsheet. << ITS FREE
Use 7z to unzip the files

BigCountry907 · Oct 19, 2018 at 8:29 PM

NEW possibly very Exciting Discovery.
Don't get too excited because i need to verify but from what i see.

In the AP_N950USQS2BQK2_CL12461033_QB15680825_REV00_user_low_ship_MULTI_CERT_meta

There is a folder called meta-data.
In that folder there is a password protected zip called FOTA.
The password is fotatest1234

I see everything in there is to sign files.

BigCountry907 · Oct 20, 2018 at 1:00 AM

Now what im thinking is related to my first ever android hack several years back.
By generating my own .pk8 and .pem keypair I figured out how to dump the publick key into the keyform used to verify the signature of ota zip packages to flash in a stock recovery.
By taking the key dump and replacing it in the recovery /res/keys.

The group of files in the above mentioned zip file is for signing packages and boot and recovery image.
I believe if I can find where the publick half of the keypair for verifying the boot signature I can replace it and sign my boot and recovery with my own keys. The bootloader still verifies the signature but it passes because its verifying my public half of the keypair against a file signed by my keypair.

I might know already where the certificate is. I need to pull out a old tool.
I wrote this shell script years ago for this very purpose. I think its broken slightly. I was working on it and never finished.

But if you know shell code the errors are easy enough to fix.
The setup will work. Its posted here.
https://drive.google.com/file/d/0B8jitdIyh2NtMHo4Q1ZLbFk3aEE/view

There are a couple of threads I wrote about it.
https://androidforums.com/threads/root-rom-recovery-r-d.975147/

Quick Ho to

Now Im not saying do all of that. But im saying Im pretty sure I might be able to use this same process to self sign our boot and recovery images. Then we don't need a bootloader unlock.

Our custom boot and recovery will be certified samsung official.

Just a lot to work on now. The sdcard and now the signing project.
Now were starting to have some real fun.

pbedard · Oct 20, 2018 at 1:14 AM

Sorry to be off topic i hope the sanfail team is on board with u

BigCountry907 · Oct 20, 2018 at 1:17 AM

One more writeup about the recovery signature hack

What happens is that the stock recovery checks the public part of the key pair against a file in the recovery.img ram disk. Usually /res/keys. You can locate this call in one of the recovery log files located in the /cache. When you get your device the /res/keys that is in the ramdisk is generated by the manufacture keyset therefore limiting the update.zip to be signed with the manufacturer keys.

So I have tested and found a way to change that. Like I said I have tested and it works. If you pull your stock recovery image or get it from a factory update.

Take that recovery.img and split it into the seperate kernel and ramdisk.
Extract or mount the ramdisk -cpio.

Generate your own set of private keys using the same public exponent as the factory rom.
Example and probably most common: Exponent: 3 (0x3)
Example: Releasekey.x509.pem and Releaseke.pk8 generated with Exponent: 3 (0x3)

Take the new keys and use DumpPublicKey.jar to create a new keys file.

Replace the /res/keys file with the one created from your keys.

Repack the ramdisk.

Repack the recovery.img using the correct offsets.

Either flash the new recovery.img to the device or use fastboot to boot it.
Example: fastboot boot recovery.img

Now take an update.zip and edit the updaterscript so that it will fail at an assert / unless you actually want to flash the update.

Sign the update zip using your .x509.pem and .pk8 keypair. You have to use the signapk.jar with the -w option else it wont work.

It will pass the signature verification of the recovery for sure.
We just did the same thing that the manufacturer does with there keys.

I dont anticipate any problems with the bootloader because the new recovery.img is identical to the original recovery.img except for the /res/key is your key.

The boot loader isn't checking that key "that i know of" so it doesn't know anything is different.

And that is how to load any update you want. You sign it with your own key. You make the recovery.img /res/keys with the matching keys.

Now if you are a developer you could probably figure out how to do all of the above.
Otherwise there is a lot more to it than it seems.

dazemc · Oct 20, 2018 at 3:21 AM

Even if you were able to flash system images, would they still not have to be stock(ish)? Would you not still have to go through the whole rigamarole of obtaining combo bootloaders and disabling dm-verity? What about rebuilding a kernel that is kexec enabled and flashing over the recovery partition to chainload another kernel? Would the bootloader not check the signature since it's already been 'signed'?

elliwigy · Oct 20, 2018 at 10:38 AM

BigCountry907 said:
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:

i just got paid for a exploit i reported to samsung back in may lol.. it was rated a high vuln.. it was for msm8998 chipsets on 7.0 (only tested on vzw tab s3)

I was listed on sept. security bulletin even lol.. i got 2500$ (1950$ after korea n us taxes n fees n w.e else.)

The exploit (without going into details) allowed flashing a modified partition and executing scripts/commands in init context.. the patch basically said they blocked or removed all init scripts lol

i never reported SamPWND.. it wouldnt be elig anyways bcuz it uses leaked eng firmware with the exploits

if ur sdcard trick does disable frp you cant report it now since u already posted publicly lol

elliwigy · Oct 20, 2018 at 11:11 AM

BigCountry907 said:
The thing that is significant thus far is the fact that booting with the sdcard IS SETTING frp LOCK TO OFF.
The normal Samsung Note 8 partition scheme uses Persist and Persistent partition for setting the FRP on or off.
If both persist and persistent are ZERO then FRP = off.

So the stock bootloader will read partitions that are (whitelisted) and verified to be Qualcomm Unique GUID Type.
Possibly even boot a bootloader that is not signed by Samsung but signed by Qualcomm.
If Qualcomm signed bootloaders will run then we can actually compile sign and boot our own bootloader.

Here is how.
https://www.96boards.org/documentation/consumer/dragonboard/dragonboard820c/guides/

Building the SD rescue image

The scripts to build the SD rescue image can be found here:
https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader-dragonboard820c.yaml,
where we defined the script parameters and variables

https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader/dragonboard820c/builders.sh:
where the actual commands are being executed.

Same Chip so we can use the source code.

isnt the note 8 msm8998? the dragonboard strings u posted are for the older msm8996 chipset as well as they are for lab purposes.. theres quite a few differences even without taking into consideration the chipsets are different...

one being samsung.. samsung takes qualcomms firmware/source and customizes the crap out of it.. disabling/removing fastboot, implementing the odin protocol etc etc

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

even in edl, edl doesnt per say let the phone boot unsigned firmware.. its merely a flashing mechanism.. so it will allow you to flash just about anything if using signed programmers and everything else is proper but if that firmware is not signed the device will not boot due to secure boot..

the private key is burned into hardware at the factory..

with that being said, i would look at the non volatile partitions that arent required to be signed and see if theres anything there that we can modify to help in unlocking the bl.. partitions like param, or steady or misc etc etc that we could modify and flash in edl and still boot as its not checked for integrity if that makes sense lol

partitions like misc.. on combo you can do in shell "setprop sys.boot_mode ffbm" and itll write ffbm-01 to the misc partition then boot into a special diagnostic mode which you can even see it in the last kmsg/boot logs.. maybe theres a boot mode or somethin similar that turns boot from sdcard on?

dunno bout newer devices but s7 and s6 etc. the unlockable sd variants use crom.apk (their bls have a crom lock)... pushing req libs with root and running logcat while running crom it writes a "KIWIBIRD" flag to the steady partition then when device boots it reads it and bl is unlocked..

On newer locked sd devices theres an eng mode.. theres an eng cert that gets flashed in odin that i believe writes to stead or param, not sure lol but u get the point..

just trying to say theres other routes to look at that i think would be more viable.

i spent close to a year messin with edl on msm8998 (s8+ g955u), it is a viable way in if u can figure it out.. unsigned firmware like boot.img, recovery.img and the usual partitions never booted for me.. always secure check fail even when flashing with edl..

theres an old read but decent and somewhat related to sdcard.. samsung devices used to have an option in odin called t. flash that was supposed to flash the stuff in odin to an sdcard in the device.. i think he crafted a boot.img then tflashed stock or somethin like that lol.. it was yearsago so surely patched unless sammy goofed and quitely re-enabled it lol

elliwigy · Oct 20, 2018 at 11:18 AM

to add after reviewing further, the dragonboard 820c is closest to snapdragon 820 which was in the S7 devices.. or similar to msm8996.. note 8 was msm8998 or closer to snapdragon 830? if that exists lol

pbedard · Oct 20, 2018 at 3:27 PM

BigCountry907 · Oct 20, 2018 at 3:43 PM

dazemc said:
Even if you were able to flash system images, would they still not have to be stock(ish)? Would you not still have to go through the whole rigamarole of obtaining combo bootloaders and disabling dm-verity? What about rebuilding a kernel that is kexec enabled and flashing over the recovery partition to chainload another kernel? Would the bootloader not check the signature since it's already been 'signed'?

I'm not saying to do the recovery.img mod.
I'm saying use that as a template to be able to sign our own boot and recovery images.

First
Generating custom signing keys

The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.

Code:

# private key
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt

# public key
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der

Second
Signing the boot image
Using the BootSignature.jar file sign the boot image using the keys generated above

If we look in that fota.zip
the path is /fota/OTA/tools

We have a boot_signer.sh and BootSignature.jar
Looking in the boot signer script we see.

#! /bin/sh
# Start-up script for BootSigner

BOOTSIGNER_HOME=`dirname "$0"`
BOOTSIGNER_HOME=`dirname "$BOOTSIGNER_HOME"`

java -Xmx512M -jar "$BOOTSIGNER_HOME"/framework/BootSignature.jar "[email protected]"

So to sign the boot image our command would be.

Code:

java -Xmx512M -jar BootSignature.jar  /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img

To check the signature

Code:

java -jar BootSignature.jar -verify boot_signed.img

Now if we had Samsungs .pk8 and samsungs .x509.der things would be easy.
The .x509.der we can get off the device its got to be in the ramdisk.
But the .pk8 is the private key and usually we can't get that.

The thing is maybe we can.
The variable "[email protected]" has to be these keys and if the boot.img is getting signed on the device after a patch or update then its hiding somwhere. If we can find that we can sign our own boot.img and the device will say there samsung official.

The other option is where I was talking about what I did to the recovery image.

Some Where there is the KEY used to verify to boot.img signature.

In the case of the recovery and flashing update zips it it the /res/keys found in the ramdisk.
The /res/keys is a dumped form of the keypair made by using dumpkey.jar also found in the /fota/OTA/tools.
By running dumpkey.jar against our custom signing keys we get the form of the key used in /res/keys.

If the boot.img signature scheme used the same method all we need to know is where the equivalent /res/keys is at and replace it with ours.

It could very well be in the ramdisk.

For me to make this work what i need to know is where is the KEY that is used to verify the boot.img signature.
Or if we can get the "[email protected]" variable output in the boot_signer script then we will have both keys.
I highly doubt but it could be possible there hard coded in the BootSignature.jar thats in the fota folder.

It would be helpful if I had a copy of any OTA Update that someone pulled off a device before they installed the update. Preferably a full update from one android version to the next like going from N to O

MY Questions are.
Anyone out there have a copy of a OTA Update?
Anyone know the location of the KEY used to verify the Boot signature?
Has anyone installed an update and seen the update package unpack / repack and sign the boot.img or any log refering to the verification of the boot signature.
If the update unpacked the boot then it had to sign it.

Hopefully you understand now what direction I am headed in with Auto-Key script.
All the code to manipulate the keys I have written in the akey.sh already.

If we can sign our own boot and recovery we don't need to unlock the bootloader.

My final question is
Is the Kernel signed also? Or since the DM-Verity days are they only relying on the boot.img signature.

BigCountry907 · Oct 20, 2018 at 3:58 PM

elliwigy said:
i just got paid for a exploit i reported to samsung back in may lol.. it was rated a high vuln.. it was for msm8998 chipsets on 7.0 (only tested on vzw tab s3)

I was listed on sept. security bulletin even lol.. i got 2500$ (1950$ after korea n us taxes n fees n w.e else.)

The exploit (without going into details) allowed flashing a modified partition and executing scripts/commands in init context.. the patch basically said they blocked or removed all init scripts lol

i never reported SamPWND.. it wouldnt be elig anyways bcuz it uses leaked eng firmware with the exploits

if ur sdcard trick does disable frp you cant report it now since u already posted publicly lol

I wasn't thinking of reporting the FRP trick.
There are a ton of ways to accomplish the same thing.
If you

Code:

dd if=/dev/zero /dev/block/sda5

and

Code:

dd if=/dev/zero /dev/block/sda12

Well FRP lock = off.

I just hate the Idea of someone using my work to profit from samsung.
I love for people to use my work and to contribute to it to help everyone.

So screw the money I just want to help.
Cool to know that you did get paid though.

BigCountry907 · Oct 20, 2018

elliwigy said:
isnt the note 8 msm8998? the dragonboard strings u posted are for the older msm8996 chipset as well as they are for lab purposes.. theres quite a few differences even without taking into consideration the chipsets are different...

This is the main reason I like the Samsung EDL Bootloaders.

one being samsung.. samsung takes qualcomms firmware/source and customizes the crap out of it.. disabling/removing fastboot, implementing the odin protocol etc etc

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

Have you looked at that yet?

Code:

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

Looks Pretty Familiar.

No im not saying that Ive tested this yet. But it is a possibility.
My guess is that the EDL bootloaders that Lack Samsung Customization including KNOX might and I say again Might read the devinfo partition.
It is there for some reason. So the Question is Why??? What does it do.
That is the reason for my interest in the EDL Firmware.

Code:

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

Again this is misinterpretation.
I'm not saying we are going to run the dragonboard firmware on our devices.
If you know the dragonboard tools some of them are very useful.
It is proven already the sd card can indeed influence the devices operation.
Basically I am utilizing some dragonboard tools to replicate what odin does to the sdcard when you use T-FLASH.
The sd card is very viable and a great means of testing. BUT also a lot of work.

Dragonboard 820 is as close to the actual source code we are going to get right now.
If you dig down in the bootloaders you will find many reference to msm8996 source code.
The msm8996 and msm8998 share a lot.
And Little Kernel is Little Kernel.
Liarno has good source trees that are for building LK with different functions.
If we can unlock the bootloader and run our own LK thats sure where id start.
Also for understanding how LK works and the different functions what better of a source than a very well documented one.

I actually have quite a bit of Leaked Qualcomm Source Code. Its a bit older but still very viable.
More than enough to understand how the security mechanisms work if you really dig into it.

partitions like misc.. on combo you can do in shell "setprop sys.boot_mode ffbm" and itll write ffbm-01 to the misc partition then boot into a special diagnostic mode which you can even see it in the last kmsg/boot logs.. maybe theres a boot mode or somethin similar that turns boot from sdcard on?

Thank You very much for pointing this out.
There are uses for that for sure.

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

I'm just looking for that one quirk that gets us a way in.
Its like looking for a needle in a haystack.
Its never expected to be there and found entirely by mistake. After you step on it.
If you don't play in the haystack you will never step on the needle.

Thank you again for your insight. If you have any other knowledge of things like that it all helps.
Maybe that is a way to trigger the SD.
The process of debating always leads to something.
Like setprop sys.boot_mode ffbm.
If everyone shares there finds eventually putting them all together gets something accomplished.

BigCountry907 · Oct 20, 2018 at 4:46 PM

pbedard said:
Rip

RIP what?
This party is just getting started.
Pay attention.....you might be surprised how much you can learn. :cowboy:

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

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Forum Moderator / Recognized Developer

Forum Moderator / Recognized Developer

Forum Moderator / Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member