Database Info

EFS, modemst1, modemst2, fsg, backup partitions - Backup needed and what do they do?

Sorry for posting this in Android Development, but I think this is important information that many other people might want to know as well:
In addition to the EFS partition, there are several partitions on our n9005 devices that do not exist in official odin roms.
This means that they must be unique to your phone, and they might be as important to back up as the EFS folder to prevent IMEI loss or other problems (like those bootloops many people get when flashing kernels, which appear to be tied to corrupted modemst1 partitions).
These partitions are: modemst1, modemst2, fsg, fsc, backup, dbi, ddr, pad
You can see them by executing the following command:
Code:
ls -l /dev/block/platform/msm_sdcc.1/by-name/
---
CWM does not back up EFS at all afaik, and the EFS backup tools usually only take the EFS partition while ignoring the others.
TWRP is the only one which also backs up modemst1 and modemst2 as far as I can tell. (it creates 2 additional efs backup files with 3MB in size - which is exactly the size of these partitions.)
--
From further research (this was discussed in the S3 forum) it turns out that the "fsg" and the "backup" partitions are meant to take copies of the modemst1 and modemst2 partitions - this can be done/forced by executing "reboot nvbackup" in terminal or with adb. So these partitions are meant to hold the backups of modemst1 and modemst2. But I'm not sure if our devices ship with these backups already made - the S3's apparently did not, so users had to do this backup themselves. (and/or use dd to also create image backups of these partitions)
People in the S3 forum reported that when they had corrupted modemst1 and/or modemst2 partitions (and no backup available) that while they still had their imei through EFS backup (or written to the phone with qualcomm tool) that they could only use the phone on roaming with these partitions corrupted.
---
So does anyone actually know more about this? Please lets use this thread to figure out (and then create some sort of sticky with the info) what these partitions actually do and if they need backup.
The "bootloop" fix goes as far as formatting modemst1 and modemst2 (I done it myself too in terminal before) to fix the bootloop issue. And its said that the partitions contents are just recreated then. But from which source? EFS or the fsg / backup partitions? etc.
This really needs some further investigation I think.
---
What I also did was to compare all the backups I had and see if they were the same or if they did differ.... and the weird thing is that EVERY single backup I have of my EFS folder or the modemst1 and modemst2 partitions do differ in checksum and also in binary diff.
Even the EFS folder did change over the time it seems. (partially this is caused by me editing the wifi mac ... but even before I did that the efs backups did differ from backup to backup).
But nonetheless, it seems that my phone is actually working alright. I have my imei, and I can just normally log in to my carrier network (can only test hsdpa+ though) and wifi is alright too.
So it appears that modemst1 and modemst2 indeed get recreated if they are formatted, but what about those other partitions. Unfortunately (since I only have one backup of these, made by hand) I cannot compare them to see if they also changed over the time.
--
Last but not least: modemst1, modemst2, fsg (meant to have copy of modemst1) and backup (meant to hve copy of modemst2) also differ on my device..... (can you guys who are fit in the terminal maybe also test if the partitions differ on your phones or if they are indeed copies?)
...
Would really like to understand these partitions more...

Thank you so much, always wondered what all those things meant and what they did...very informative

thanks you for making this thread.
so we can understand it.
i edited and made a windows efs backup tool for making backup and restore EFS, modemst1, modemst2.
and i will edit aroma method too.
... if we need more backup of more partitions, i will edit EFS Tool for them (dd backup/restore method)
http://forum.xda-developers.com/showpost.php?p=49460571&postcount=4

so I got some more infos:
I checked the "fsg" and "backup" partition, and they did not change over the course of all my actions. Even the partitions on the system are exactly the same as they were when I took backups. (remember: EFS and modemst1 and modemst2 constantly changed, and I could not find 2 exact copies in my backups).
So this means fsg and backup are indeed left untouched.
----
Since they are meant to hold backups of modemst1 and modemst2 which can be restored with "reboot nvrestore" I tried that as well.
But apparently they do not contain valid backups when you first get your phone (just like in the S3 case).
When I tried nvrestore the device rebooted and showed a message like "no nvbackup found" in red letters. (phone was stuck in this mode, even with forced reboot by holding down power - only pulling the battery got my device back to normal life... man was I scared when this message kept reappearing on hard reset)..
---
So in turn this means, the best thing to do when you get a new N3 (and didnt mess up modemst1 and modemst2 yet by flashing) that you should run "reboot nvbackup" in terminal.
This will fill the fsg and backup partition with valid copies of modemst1 and modemst2 which later can be restored with "reboot nvrestore".
---
Still not sure what these partitions are really about - they seem to be the "nvram" of the device (whatever that is lol) ... and I *think* there are things stored like carrier specific settings from what I understood. So simlock and netlock etc is stored there apparently. But since the note3's are all simlock free as far as I know (at least our n9005s) this should not really be important to us.
But when they are corrupted we get the bootloops.
These can be fixed by simply formatting the partitions, but I'm not 100% sure if this has any downsides yet. (aka if we need our original modemst1 and modemst2, or if it does not matter....)
ADD: I read in another post that someone lost his imei when his modemst1 got corrupted/formatted. But I can just say that I manually formatted modemst1 and modemst2 before (if you try this, back them up first though!!!!!!!) and I kept my imei and could connect phone to carrier etc. So the imei does not seem to be stored there really.
---
Someone has to know more about this, please enlighten us.....

Interesting subject...
To add bits, pit file dump:
Code:
PIT dump v1.0 by LeTama
- 30 partitions in PIT file
- Format string = [COM_TAR2MSM8974]
01|APNHLOS | 0x00002000 | 0x00007800 | 8192 | 30720 | 15360 KB | NON-HLOS.bin
02|MODEM | 0x00009800 | 0x0001CB80 | 38912 | 117632 | 58816 KB | modem.bin
03|SBL1 | 0x00026380 | 0x00000400 | 156544 | 1024 | 512 KB | sbl1.mbn
04|DBI | 0x00026780 | 0x00000040 | 157568 | 64 | 32 KB | sdi.mbn
05|DDR | 0x000267C0 | 0x00000040 | 157632 | 64 | 32 KB |
06|ABOOT | 0x00026800 | 0x00001000 | 157696 | 4096 | 2048 KB | aboot.mbn
07|RPM | 0x00027800 | 0x00000400 | 161792 | 1024 | 512 KB | rpm.mbn
08|TZ | 0x00027C00 | 0x00000400 | 162816 | 1024 | 512 KB | tz.mbn
09|PAD | 0x00028000 | 0x00005000 | 163840 | 20480 | 10240 KB |
10|PARAM | 0x0002D000 | 0x00005000 | 184320 | 20480 | 10240 KB | param.bin
11|EFS | 0x00032000 | 0x00007000 | 204800 | 28672 | 14336 KB | efs.img.ext4
12|MODEMST1 | 0x00039000 | 0x00001800 | 233472 | 6144 | 3072 KB | nvrebuild1.bin
13|MODEMST2 | 0x0003A800 | 0x00001800 | 239616 | 6144 | 3072 KB | nvrebuild2.bin
14|BOOT | 0x0003C000 | 0x00005800 | 245760 | 22528 | 11264 KB | boot.img
15|RECOVERY | 0x00041800 | 0x00006800 | 268288 | 26624 | 13312 KB | recovery.img
16|FOTA | 0x00048000 | 0x00006800 | 294912 | 26624 | 13312 KB |
17|BACKUP | 0x0004E800 | 0x000037EE | 321536 | 14318 | 7159 KB |
18|FSG | 0x00051FEE | 0x00001800 | 335854 | 6144 | 3072 KB |
19|FSC | 0x000537EE | 0x00000002 | 341998 | 2 | 1 KB |
20|SSD | 0x000537F0 | 0x00000010 | 342000 | 16 | 8 KB |
21|PERSIST | 0x00053800 | 0x00004000 | 342016 | 16384 | 8192 KB | persist.img.ext4
22|PERSDATA | 0x00057800 | 0x00004800 | 358400 | 18432 | 9216 KB | persdata.img.ext4
23|SYSTEM | 0x0005C000 | 0x00480000 | 376832 | 4718592 | 2359296 KB | system.img.ext4
24|CACHE | 0x004DC000 | 0x00096000 | 5095424 | 614400 | 307200 KB | cache.img.ext4
25|HIDDEN | 0x00572000 | 0x0000F000 | 5709824 | 61440 | 30720 KB | hidden.img.ext4
26|USERDATA | 0x00581000 | 0x00000000 | 5771264 | 0 | 0 KB | userdata.img.ext4
70|PGPT | 0x00000000 | 0x00000022 | 0 | 34 | 17 KB | pgpt.img
71|PIT | 0x00000022 | 0x00000010 | 34 | 16 | 8 KB | MSM8974.pit
72|MD5 | 0x00000032 | 0x00000020 | 50 | 32 | 16 KB | md5.img
73|SGPT | 0x03A3DFDF | 0x00000021 | 61071327 | 33 | 16 KB | sgpt.img
-----------------
- signature /trailer size = [4204]
It's showing more locations than the one exposed by kernel like pgpt /sgpt (primary/secondary gpt partition table), pit table, md5 (?).
Last, there is the rpmb partition that we can't see without knowing the access key.

genius.lizard2 said:
thanks you for making this thread.
so we can understand it.
i edited and made a windows efs backup tool for making backup and restore EFS, modemst1, modemst2.
and i will edit aroma method too.
... if we need more backup of more partitions, i will edit EFS Tool for them (dd backup/restore method)
http://forum.xda-developers.com/showpost.php?p=49460571&postcount=4
Click to expand...
Click to collapse
Thank you, worked perfectly.:good:

[GUIDE] How to dump and write back the storage on most of Qualcomm devices

This is a generic guide that could be suitable for many Qualcomm based devices, once the phone can be triggered to EDL mode.
To make sure this guide will work as expect, following requirements are needed:
- Know how to trigger the phone to EDL mode, and you can force reboot the phone (Required for Driver Changing)
- Qualcomm EDL mode doesn't require service authentication, or specially modded (e.g. Lumia Emergency Files)
- Firehose file for your SoC and storage type (eMMC or UFS storage)
- Latest Qualcomm USB Drivers (at least 2.1.2.0 or newer, you can check yourself in Device Manager) and QPST Tool
Driver version is pretty important. If older than 2.1.2.0, it won't support partition dumping properly.
You may need to reboot your Windows PC to Disable Driver Signature Enforcement mode to allow you use the driver.
I won't provide any download link of the proper drivers, please find yourself.
Click to expand...
Click to collapse
For non-Android Smartphones, HP Elite X3 (At least for prototype unit) is confirmed working with this method.
Most of Android Smartphones should work as well.
Step 1: Trigger the phone to EDL mode
Following methods can be used as reference:
- Connect your phone to PC with a specific key pressed
e.g. TCL / Alcatel / Blackberry Android Smartphones can use Volume Down key to trigger to EDL mode
- EDL cable (DIY or order it on eBay / AliExpress, keyword: Xiaomi EDL cable)
e.g. Smartisan Smartphones that made recently can use EDL cable to unlock the bootloader.
- Fastboot command
e.g. Few Xiaomi Phones
- Wire trick
If you know where's the test point / components (like resistant) on CLK pin of eMMC/UFS storage is connected as well, short it to the GND will trigger your phone to EDL mode.
This will be usable for almost every Qualcomm devices, once you have schematic provided by the manufacturer.
- Erase aboot / abl / xbl / UEFI from your phone
This method is dangerous, do it at your own risk!
Step 2: Change the Driver to Qualcomm HS-USB QDLoader 9008
Skip this step if it's already indicated as HS-USB QDLoader 9008 in Device Manager, "Ports (COM or LPT)" category.
If it's indicated as HS-USB Diagnostics 9008 in "Ports (COM or LPT)" category, or "QHSUSB__BULK" in "Universal Serial Bus devices" category, you must update the driver to Qualcomm HS-USB QDLoader 9008, then reboot your phone to Qualcomm EDL mode again to ensure the EDL port will not throttle.
To reboot your phone, you need to perform hard reboot until you see the port disappeared immediately or refresh (in case the phone is bricked).
Step 3: Open QFIL, load Firehose file
You must choose correct storage type in right down corner.
In many cases keep it as "emmc" for default, otherwise choose "ufs" for flagship devices. In this case we choose emmc.
Then choose "Flat Build" as Build Type, and select the firehose file for your phone. If there's no firehose file specifically for your device, you may want to choose another firehose file for the same SoC, same storage type for different phone.
For example, I used the "prog_emmc_firehose_8996_ddr.elf" for ZUK Z2 on HP Elite X3 and it works perfectly.
In many cases, you can obtain firehose file for your phone from stock firmware.
Click to expand...
Click to collapse
Step 4: Open Partition Manager
Now choose "Tools" - "Partition Manager", and please pay attention to the Status box.
When it indicates:
Code:
2019-07-18 20:04:19.775 20:04:19: Sahara protocol completed
2019-07-18 20:04:19.776 Sending Programmer Finished
2019-07-18 20:04:19.776 Switch To FireHose
2019-07-18 20:04:19.777 Wait for 3 seconds...
If you didn't see the output above, then the firehose file is incorrect or the EDL port is throttled. Reboot your phone to EDL mode again.
Then you've partially succeeded, just wait for the Partition Manager appears.
This is the partition table of your phone. Please take note on the Start LBA and LBA number of the last partition.
Take HP Elite X3 partition table for example, the last partition is "Data", it's Start LBA and LBA number are 0x01E20000 and 0x0565BFDF. Add both of them will get the total sector numbers of whole eMMC storage - in this case, 0x0747BFDF, or 122,142,687 sectors. Multiple the sector numbers with 512 will get the total bytes of the eMMC storage, in this case, the capacity of eMMC storage is 62,537,055,744‬ bytes.
You'll need the number 122,142,687 for later use.
If you don't want to dump userdata partition, just use the Start LBA value of userdata partition and convert it to decimal values - the overall dump will not contain actual userdata.
Don't close Partition Manager, we need to keep it for later use.
Now choose either Step 5A or 5B as your wish.
Step 5A: Dump the storage
Please copy following path to your File Explorer:
Code:
%AppData%\Qualcomm\QFIL
This will redirect you to C:\Users\[your_user_name]\AppData\Roaming\Qualcomm\QFIL .
Find the COMPORT_XX directory respective to your exact COM port - in this case, I choose COMPORT_8 for example.
And open a command prompt or PowerShell window here.
Execute following command here, remember to change the COM port number and num_sectors to your exact number, or the actual path of fh_loader.exe and your dump if possible:
Note, this command will not create the path of your dump for you, you must create yourself.
Code:
"C:\Program Files (x86)\Qualcomm\QPST\bin\fh_loader.exe" --port=\\.\COM8 --search_path=D:\path\to\your\dump --convertprogram2read --sendimage=full_dump.bin --start_sector=0 --lun=0 --num_sectors=122142687 --noprompt --showpercentagecomplete --zlpawarehost=1 --memoryname=emmc
Now just wait for dumping procedure complete.
Expected output should look like this:
Code:
20:45:50: INFO: Current working dir (cwd): C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\
20:45:50: INFO: Showing network mappings to allow debugging
20:45:50: INFO: Looking for file 'full_dump.bin'
(_)
__ ____ _ _ __ _ __ _ _ __ __ _
\ \ /\ / / _` | '__| '_ \| | '_ \ / _` |
\ V V / (_| | | | | | | | | | | (_| |
\_/\_/ \__,_|_| |_| |_|_|_| |_|\__, |
__/ |
|___/
20:45:50: WARNING: Couldn't find the file 'full_dump.bin', returning NULL
(_)
__ ____ _ _ __ _ __ _ _ __ __ _
\ \ /\ / / _` | '__| '_ \| | '_ \ / _` |
\ V V / (_| | | | | | | | | | | (_| |
\_/\_/ \__,_|_| |_| |_|_|_| |_|\__, |
__/ |
|___/
20:45:50: WARNING: User specified --num_sectors=524288 but file only has 524288 sectors. **Ignoring --num_sectors
20:45:50: INFO: User wants to talk to port '\\.\COM8'
20:45:50: INFO: Took 0.00000000 seconds to open port
20:45:50: INFO: Sorting TAGS to ensure order is <configure>,<erase>, others, <patch>,<power>
20:45:50: INFO: If you don't want this, use --dontsorttags
20:45:50: INFO: Looking for file 'full_dump.bin'
(_)
__ ____ _ _ __ _ __ _ _ __ __ _
\ \ /\ / / _` | '__| '_ \| | '_ \ / _` |
\ V V / (_| | | | | | | | | | | (_| |
\_/\_/ \__,_|_| |_| |_|_|_| |_|\__, |
__/ |
|___/
20:45:50: WARNING: Couldn't find the file 'full_dump.bin', returning NULL
20:45:50: INFO: Sending <configure>
20:45:50: INFO: TARGET SAID: 'Calling usb_al_bulk_set_zlp_mode(TRUE) since ZlpAwareHost='1''
20:45:50: INFO: TARGET SAID: 'Calling hotplug_poll_device('MMC')'
20:45:50: INFO: fh.attrs.MaxPayloadSizeToTargetInBytes = 1048576
20:45:50: INFO: fh.attrs.MaxPayloadSizeToTargetInBytesSupported = 1048576
20:45:50: INFO: In handleRead('full_dump.bin')
20:45:50: INFO: Looking for file 'full_dump.bin'
(_)
__ ____ _ _ __ _ __ _ _ __ __ _
\ \ /\ / / _` | '__| '_ \| | '_ \ / _` |
\ V V / (_| | | | | | | | | | | (_| |
\_/\_/ \__,_|_| |_| |_|_|_| |_|\__, |
__/ |
|___/
20:45:50: WARNING: Previous Filesize is 0 bytes. Therefore reading size of partition!! Please check 'full_dump.bin'
20:45:50: INFO: =======================================================
20:45:50: INFO: <read> (262144.0KB) 524288 sectors from location 0 FILE: 'full_dump.bin'
20:45:50: INFO: =======================================================
20:45:52: INFO: Overall to target 2.000 seconds (32.34 MBps)
20:45:54: INFO: Overall to target 4.000 seconds (32.38 MBps)
20:45:56: INFO: Overall to target 6.000 seconds (32.37 MBps)
20:45:58: INFO: Overall to target 7.844 seconds (32.64 MBps)
20:45:58: INFO: TARGET SAID: 'Finished reading from sector address 0 to 524288'
20:45:58: INFO: =======================================================
20:45:58: INFO: ===================== SUCCESS =========================
20:45:58: INFO: =======================================================
20:45:58: INFO: ==============================================================
20:45:58: INFO: Files used and their paths
20:45:58: INFO: 1 'C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\port_trace.txt'
20:45:58: INFO: 2 'C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\full_dump.bin'
(_)
__ ____ _ _ __ _ __ _ _ __ __ _
\ \ /\ / / _` | '__| '_ \| | '_ \ / _` |
\ V V / (_| | | | | | | | | | | (_| |
\_/\_/ \__,_|_| |_| |_|_|_| |_|\__, |
__/ |
|___/
20:45:58: INFO: ==============================================================
20:45:58: INFO: NOTE: There were WARNINGS!! Repeated here, but please see log for more detail
Couldn't find the file 'full_dump.bin', returning NULL
User specified --num_sectors=524288 but file only has 524288 sectors. **Ignoring --num_sectors
Couldn't find the file 'full_dump.bin', returning NULL
Previous Filesize is 0 bytes. Therefore reading size of partition!! Please check 'full_dump.bin'
NOTE: There were WARNINGS!! Repeated above, but please see log for more detail
20:45:58: INFO: ==============================================================
20:45:58: INFO: _ (done)
20:45:58: INFO: | |
20:45:58: INFO: __| | ___ _ __ ___
20:45:58: INFO: / _` |/ _ \| '_ \ / _ \
20:45:58: INFO: | (_| | (_) | | | | __/
20:45:58: INFO: \__,_|\___/|_| |_|\___|
20:45:58: INFO: {All Finished Successfully}
20:45:58: INFO: Overall to target 7.969 seconds (32.12 MBps)
Writing log to 'C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\port_trace.txt', might take a minute
Log is 'C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\port_trace.txt'
You can use 7-Zip archiver to open this dump and extract any partition you want.
Step 5B: Write the dump back to storage
Open Partition Manager, and don't close it.
Please copy following path to your File Explorer:
Code:
%AppData%\Qualcomm\QFIL
This will redirect you to C:\Users\[your_user_name]\AppData\Roaming\Qualcomm\QFIL .
Find the COMPORT_XX directory respective to your exact COM port - in this case, I choose COMPORT_8 for example.
And open a command prompt or PowerShell window here.
Execute following command here, remember to change the COM port number and num_sectors to your exact number, or the actual path of fh_loader.exe and your dump if possible:
In this case, the dump is located at D:\path\to\your\dump\full_dump.bin .
Code:
"C:\Program Files (x86)\Qualcomm\QPST\bin\fh_loader.exe" --port=\\.\COM8 --search_path=D:\path\to\your\dump --sendimage=full_dump.bin --start_sector=0 --lun=0 --noprompt --showpercentagecomplete --zlpawarehost=1 --memoryname=emmc
Now just wait for the procedure complete.
The output should look like this:
Code:
20:05:30: INFO: Current working dir (cwd): C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\
20:05:30: INFO: Showing network mappings to allow debugging
20:05:30: INFO: Looking for file 'full_dump.bin'
20:05:31: INFO: User wants to talk to port '\\.\COM8'
20:05:31: INFO: Took 0.01600000 seconds to open port
20:05:31: INFO: Sorting TAGS to ensure order is <configure>,<erase>, others, <patch>,<power>
20:05:31: INFO: If you don't want this, use --dontsorttags
20:05:31: INFO: Looking for file 'full_dump.bin'
20:05:31: INFO:
Total to be tansferd with <program> or <read> is 36.09 GB
20:05:31: INFO: Sending <configure>
20:05:31: INFO: TARGET SAID: 'Calling usb_al_bulk_set_zlp_mode(TRUE) since ZlpAwareHost='1''
20:05:31: INFO: TARGET SAID: 'Calling hotplug_poll_device('MMC')'
20:05:31: INFO: fh.attrs.MaxPayloadSizeToTargetInBytes = 1048576
20:05:31: INFO: fh.attrs.MaxPayloadSizeToTargetInBytesSupported = 1048576
20:05:31: INFO: In handleProgram('full_dump.bin')
20:05:31: INFO: Looking for file 'full_dump.bin'
20:05:31: INFO: =======================================================
20:05:31: INFO: {<program> FILE: 'D:\path\to\your\dump\full_dump.bin'}
20:05:31: INFO: {<program> (36.09 GB) 75685888 sectors needed at location 0 on LUN 0}
20:05:31: INFO: =======================================================
20:05:31: INFO: TARGET SAID: 'start 0, num 75685888'
20:05:33: INFO: Overall to target 2.031 seconds (26.59 MBps)
20:05:33: INFO: {percent files transferred 0.15%}
20:05:35: INFO: Overall to target 4.063 seconds (26.34 MBps)
20:05:35: INFO: {percent files transferred 0.29%}
20:05:37: INFO: Overall to target 6.094 seconds (26.26 MBps)
20:05:37: INFO: {percent files transferred 0.43%}
20:05:39: INFO: Overall to target 8.110 seconds (26.26 MBps)
20:05:39: INFO: {percent files transferred 0.58%}
20:05:41: INFO: Overall to target 10.125 seconds (26.27 MBps)
20:05:41: INFO: {percent files transferred 0.72%}
20:05:43: INFO: Overall to target 12.141 seconds (26.27 MBps)
20:05:43: INFO: {percent files transferred 0.86%}
20:05:45: INFO: Overall to target 14.141 seconds (26.31 MBps)
20:05:45: INFO: {percent files transferred 1.01%}
20:05:47: INFO: Overall to target 16.156 seconds (26.49 MBps)
20:05:47: INFO: {percent files transferred 1.16%}
20:05:49: INFO: Overall to target 18.172 seconds (26.52 MBps)
20:05:49: INFO: {percent files transferred 1.30%}
20:05:51: INFO: Overall to target 20.188 seconds (26.55 MBps)
20:05:51: INFO: {percent files transferred 1.45%}
20:05:53: INFO: Overall to target 22.188 seconds (26.59 MBps)
20:05:53: INFO: {percent files transferred 1.60%}
20:05:55: INFO: Overall to target 24.188 seconds (26.62 MBps)
20:05:55: INFO: {percent files transferred 1.74%}
20:05:57: INFO: Overall to target 26.188 seconds (26.62 MBps)
20:05:57: INFO: {percent files transferred 1.89%}
20:05:59: INFO: Overall to target 28.188 seconds (26.61 MBps)
20:05:59: INFO: {percent files transferred 2.03%}
20:06:01: INFO: Overall to target 30.235 seconds (26.59 MBps)
20:06:01: INFO: {percent files transferred 2.18%}
20:06:03: INFO: Overall to target 32.266 seconds (26.56 MBps)
20:06:03: INFO: {percent files transferred 2.32%}
20:06:05: INFO: Overall to target 34.281 seconds (26.57 MBps)
20:06:05: INFO: {percent files transferred 2.47%}
20:06:07: INFO: Overall to target 36.328 seconds (26.56 MBps)
20:06:07: INFO: {percent files transferred 2.61%}
20:06:09: INFO: Overall to target 38.328 seconds (26.56 MBps)
20:06:09: INFO: {percent files transferred 2.75%}
20:06:11: INFO: Overall to target 40.360 seconds (26.56 MBps)
20:06:11: INFO: {percent files transferred 2.90%}
20:06:13: INFO: Overall to target 42.391 seconds (26.56 MBps)
20:06:13: INFO: {percent files transferred 3.05%}
(ignored too many logs)
20:28:17: INFO: Overall to target 1366.235 seconds (26.33 MBps)
20:28:17: INFO: {percent files transferred 97.33%}
20:28:19: INFO: Overall to target 1368.266 seconds (26.33 MBps)
20:28:19: INFO: {percent files transferred 97.48%}
20:28:21: INFO: Overall to target 1370.281 seconds (26.33 MBps)
20:28:21: INFO: {percent files transferred 97.63%}
20:28:23: INFO: Overall to target 1372.313 seconds (26.33 MBps)
20:28:23: INFO: {percent files transferred 97.78%}
20:28:25: INFO: Overall to target 1374.313 seconds (26.33 MBps)
20:28:25: INFO: {percent files transferred 97.93%}
20:28:27: INFO: Overall to target 1376.344 seconds (26.34 MBps)
20:28:27: INFO: {percent files transferred 98.08%}
20:28:29: INFO: Overall to target 1378.344 seconds (26.34 MBps)
20:28:29: INFO: {percent files transferred 98.22%}
20:28:31: INFO: Overall to target 1380.360 seconds (26.34 MBps)
20:28:31: INFO: {percent files transferred 98.37%}
20:28:33: INFO: Overall to target 1382.375 seconds (26.34 MBps)
20:28:33: INFO: {percent files transferred 98.51%}
20:28:35: INFO: Overall to target 1384.406 seconds (26.34 MBps)
20:28:35: INFO: {percent files transferred 98.66%}
20:28:37: INFO: Overall to target 1386.438 seconds (26.34 MBps)
20:28:37: INFO: {percent files transferred 98.80%}
20:28:39: INFO: Overall to target 1388.438 seconds (26.34 MBps)
20:28:39: INFO: {percent files transferred 98.94%}
20:28:41: INFO: Overall to target 1390.453 seconds (26.34 MBps)
20:28:41: INFO: {percent files transferred 99.09%}
20:28:43: INFO: Overall to target 1392.485 seconds (26.34 MBps)
20:28:43: INFO: {percent files transferred 99.25%}
20:28:45: INFO: Overall to target 1394.516 seconds (26.34 MBps)
20:28:45: INFO: {percent files transferred 99.40%}
20:28:47: INFO: Overall to target 1396.531 seconds (26.34 MBps)
20:28:47: INFO: {percent files transferred 99.55%}
20:28:49: INFO: Overall to target 1398.750 seconds (26.33 MBps)
20:28:49: INFO: {percent files transferred 99.66%}
20:28:51: INFO: Overall to target 1400.766 seconds (26.33 MBps)
20:28:51: INFO: {percent files transferred 99.81%}
20:28:53: INFO: Overall to target 1402.797 seconds (26.33 MBps)
20:28:53: INFO: {percent files transferred 99.96%}
20:28:54: INFO: Overall to target 1403.422 seconds (26.33 MBps)
20:28:54: INFO: {percent files transferred 100.00%}
20:28:54: INFO: TARGET SAID: 'Finished programming start_sector 75685888 and TotalSectorsToProgram 75685888'
20:28:54: INFO:
20:28:54: INFO: =======================================================
20:28:54: INFO: ==================== {SUCCESS} ========================
20:28:54: INFO: =======================================================
20:28:54: INFO: {percent files transferred 100.00%}
20:28:54: INFO: ==============================================================
20:28:54: INFO: Files used and their paths
20:28:54: INFO: 1 'C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\port_trace.txt'
20:28:54: INFO: 2 'D:\path\to\your\dump\full_dump.bin'
20:28:54: INFO: _ (done)
20:28:54: INFO: | |
20:28:54: INFO: __| | ___ _ __ ___
20:28:54: INFO: / _` |/ _ \| '_ \ / _ \
20:28:54: INFO: | (_| | (_) | | | | __/
20:28:54: INFO: \__,_|\___/|_| |_|\___|
20:28:54: INFO: {All Finished Successfully}
20:28:54: INFO: Overall to target 1403.578 seconds (26.33 MBps)
20:28:54: INFO: {percent files transferred 100.00%}
Writing log to 'C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\port_trace.txt', might take a minute
Log is 'C:\Users\HikariCal\AppData\Roaming\Qualcomm\QFIL\COMPORT_8\port_trace.txt'
If you only want to write back only one specific partition, you need to specify the start_sector value to the decimal value of a partition's Start LBA.
Always keep the Partition Manager window opened!
Step 6: Quit Partition Manager
After everything dumped, you can close Partition Manager, the QFIL will reboot your phone back to EDL mode or reboot your phone back to normal mode.
Then you can force reboot your phone or mess up your phone as you want.

reserved

Awesome Guide!

Qualcomm HS-USB QD loader 9008 drivers showing briefly in device manager
I put Samsung Note 3 ( N9005) Qualcomm based mobile on EDL by ADB Command. The command does work & phone reboot to show in device manager Qualcomm usb Driver, BUT Qualcomm USB drivers disappear after few seconds .... What could be the issue....as i wanted to use QPST ( QFil) to flash the phone but its giving error that no port is selected.
How to make " Qualcomm HS-USB QD loader 9008 " drivers to appear permanently in Device manager.
searched a lot on goolge but nothing is working...
Pls any one help.

user agent said:
I put Samsung Note 3 ( N9005) Qualcomm based mobile on EDL by ADB Command. The command does work & phone reboot to show in device manager Qualcomm usb Driver, BUT Qualcomm USB drivers disappear after few seconds .... What could be the issue....as i wanted to use QPST ( QFil) to flash the phone but its giving error that no port is selected.
How to make " Qualcomm HS-USB QD loader 9008 " drivers to appear permanently in Device manager.
searched a lot on goolge but nothing is working...
Pls any one help.
Click to expand...
Click to collapse
I remember Galaxy Note 3 can remove the battery right?
In may cases, Qualcomm based phone can stay at EDL mode without battery.

the partitiion maneger do not appear
Hey, Thank you so much for prividing this GUIDE!
I just try to maake a backup of my data. I followed the steps above but the partition manager do not appear. Anyone know what is the problem? Log see below. Thank you for any coming tipps!
2020-04-19 23:31:12.778 Validating Application Configuration
2020-04-19 23:31:12.790 Load APP Configuration
2020-04-19 23:31:12.810 COM:12
2020-04-19 23:31:12.810 PBLDOWNLOADPROTOCOL:0
2020-04-19 23:31:12.810 PROGRAMMER:True
2020-04-19 23:31:12.810 PROGRAMMER:\Firefox_download\01\images\prog_ufs_firehose_sdm845_ddr.elf
2020-04-19 23:31:12.810 RESETSAHARASTATEMACHINE:False
2020-04-19 23:31:12.810 SAHARAREADSERIALNO:False
2020-04-19 23:31:12.810 SEARCHPATH:\Firefox_download\01\images
2020-04-19 23:31:12.810 ACKRAWDATAEVERYNUMPACKETS:False
2020-04-19 23:31:12.810 ACKRAWDATAEVERYNUMPACKETS:100
2020-04-19 23:31:12.810 MAXPAYLOADSIZETOTARGETINBYTES:False
2020-04-19 23:31:12.810 MAXPAYLOADSIZETOTARGETINBYTES:49152
2020-04-19 23:31:12.810 DEVICETYPE:ufs
2020-04-19 23:31:12.810 PLATFORM:8x26
2020-04-19 23:31:12.810 VALIDATIONMODE:0
2020-04-19 23:31:12.811 RESETAFTERDOWNLOAD:False
2020-04-19 23:31:12.811 MAXDIGESTTABLESIZE:8192
2020-04-19 23:31:12.811 SWITCHTOFIREHOSETIMEOUT:30
2020-04-19 23:31:12.811 RESETTIMEOUT:200
2020-04-19 23:31:12.811 RESETDELAYTIME:2
2020-04-19 23:31:12.811 METABUILD:
2020-04-19 23:31:12.811 METABUILD:
2020-04-19 23:31:12.811 FLATBUILDPATH:C:\
2020-04-19 23:31:12.811 FLATBUILDFORCEOVERRIDE:True
2020-04-19 23:31:12.811 QCNPATH:C:\Temp\00000000.qcn
2020-04-19 23:31:12.811 QCNAUTOBACKUPRESTORE:False
2020-04-19 23:31:12.811 SPCCODE:000000
2020-04-19 23:31:12.811 ENABLEMULTISIM:False
2020-04-19 23:31:12.811 AUTOPRESERVEPARTITIONS:False
2020-04-19 23:31:12.811 PARTITIONPRESERVEMODE:0
2020-04-19 23:31:12.811 PRESERVEDPARTITIONS:0
2020-04-19 23:31:12.811 PRESERVEDPARTITIONS:
2020-04-19 23:31:12.811 ERASEALL:False
2020-04-19 23:31:12.812 Load ARG Configuration
2020-04-19 23:31:12.888 Validating Download Configuration
2020-04-19 23:31:12.890 Image Search Path: D:\Firefox_download\01\images
2020-04-19 23:31:12.895 Programmer Path:\Firefox_download\01\images\prog_ufs_firehose_sdm845_ddr.elf
2020-04-19 23:31:13.548 Process Index:0
2020-04-19 23:31:13.567 Qualcomm Flash Image Loader (QFIL) 2.0.2.3
2020-04-19 23:32:56.567 Start Download
2020-04-19 23:32:56.588 Program Path:\Firefox_download\01\images\prog_ufs_firehose_sdm845_ddr.elf
2020-04-19 23:32:56.593 ***** Working Folder:C:\Users\Administrator\AppData\Roaming\Qualcomm\QFIL\COMPORT_12
2020-04-19 23:32:57.013 Binary build date: Apr 27 2018 @ 03:04:33
2020-04-19 23:32:57.015 QSAHARASERVER CALLED LIKE THIS: 'C:\Program Files (x86)\QUALCOMM\QPST\bin\QSaharaServer.ex'Current working dir: C:\Users\Administrator\AppData\Roaming\Qualcomm\QFIL\COMPORT_12
2020-04-19 23:32:57.018 Sahara mappings:
2020-04-19 23:32:57.020 2: amss.mbn
2020-04-19 23:32:57.020 6: apps.mbn
2020-04-19 23:32:57.021 8: dsp1.mbn
2020-04-19 23:32:57.022 10: dbl.mbn
2020-04-19 23:32:57.022 11: osbl.mbn
2020-04-19 23:32:57.023 12: dsp2.mbn
2020-04-19 23:32:57.023 16: efs1.mbn
2020-04-19 23:32:57.024 17: efs2.mbn
2020-04-19 23:32:57.024 20: efs3.mbn
2020-04-19 23:32:57.025 21: sbl1.mbn
2020-04-19 23:32:57.025 22: sbl2.mbn
2020-04-19 23:32:57.026 23: rpm.mbn
2020-04-19 23:32:57.027 25: tz.mbn
2020-04-19 23:32:57.027 28: dsp3.mbn
2020-04-19 23:32:57.028 29: acdb.mbn
2020-04-19 23:32:57.030 30: wdt.mbn
2020-04-19 23:32:57.031 31: mba.mbn
2020-04-19 23:32:57.032 13: D:\Firefox_download\01\images\prog_ufs_firehose_sdm845_ddr.elf
2020-04-19 23:32:57.032
2020-04-19 23:32:57.033 23:32:56: Requested ID 13, file: "D:\Firefox_download\01\images\prog_ufs_firehose_sdm845_ddr.elf"
2020-04-19 23:32:57.033
2020-04-19 23:32:57.034 23:32:57: 715496 bytes transferred in 0.391000 seconds (1.7451MBps)
2020-04-19 23:32:57.034
2020-04-19 23:32:57.035
2020-04-19 23:32:57.035
2020-04-19 23:32:57.036 23:32:57: File transferred successfully
2020-04-19 23:32:57.036
2020-04-19 23:32:57.036
2020-04-19 23:32:57.037
2020-04-19 23:32:57.038 23:32:57: Sahara protocol completed
2020-04-19 23:32:57.038 Sending Programmer Finished
2020-04-19 23:32:57.039 Switch To FireHose
2020-04-19 23:32:57.039 Wait for 3 seconds...
2020-04-19 23:33:00.041 Max Payload Size to Target:49152 Bytes
2020-04-19 23:33:00.041 Device Type:ufs
2020-04-19 23:33:00.042 Platform:8x26
2020-04-19 23:33:00.043 Disable Ack Raw Data Every N Packets
2020-04-19 23:33:00.044 Skip Write:False
2020-04-19 23:33:00.044 Always Validate:False
2020-04-19 23:33:00.045 Use Verbose:False
2020-04-19 23:33:00.050 ***** Working Folder:C:\Users\Administrator\AppData\Roaming\Qualcomm\QFIL\COMPORT_12
2020-04-19 23:33:00.124
2020-04-19 23:33:00.126 Base Version: 18.02.16.18.26
2020-04-19 23:33:00.131 Binary build date: Apr 27 2018 @ 03:04:29
2020-04-19 23:33:00.131 Incremental Build version: 18.04.27.03.04.29
2020-04-19 23:33:00.138
2020-04-19 23:33:00.138 23:33:00: INFO: FH_LOADER WAS CALLED EXACTLY LIKE THIS
2020-04-19 23:33:00.139 ************************************************
2020-04-19 23:33:00.140 C:\Program Files (x86)\QUALCOMM\QPST\bin\fh_loader.exe --port=\\.\COM12 --search_path=C:\Users\Administrator\AppData\Roaming\Qualcomm\QFIL\COMPORT_12 --convertprogram2read --sendimage=fh_gpt_header_0 --start_sector=1 --lun=0 --num_sectors=1 --noprompt --showpercentagecomplete --zlpawarehost=1 --memoryname=ufs
2020-04-19 23:33:00.142 ************************************************
2020-04-19 23:33:00.142
2020-04-19 23:33:00.143 23:33:00: INFO: Current working dir (cwd): C:\Users\Administrator\AppData\Roaming\Qualcomm\QFIL\COMPORT_12\
2020-04-19 23:33:00.144 23:33:00: INFO: Showing network mappings to allow debugging
2020-04-19 23:33:00.145 23:33:00: INFO: Looking for file 'fh_gpt_header_0'
2020-04-19 23:33:00.147
2020-04-19 23:33:00.147
2020-04-19 23:33:00.148 (_)
2020-04-19 23:33:00.149 __ ____ _ _ __ _ __ _ _ __ __ _
2020-04-19 23:33:00.150 \ \ /\ / / _` | '__| '_ \| | '_ \ / _` |
2020-04-19 23:33:00.151 \ V V / (_| | | | | | | | | | | (_| |
2020-04-19 23:33:00.151 \_/\_/ \__,_|_| |_| |_|_|_| |_|\__, |
2020-04-19 23:33:00.152 __/ |
2020-04-19 23:33:00.153 |___/
2020-04-19 23:33:00.153
2020-04-19 23:33:00.154
2020-04-19 23:33:00.154 23:33:00: WARNING: Couldn't find the file 'fh_gpt_header_0', returning NULL
2020-04-19 23:33:00.156
2020-04-19 23:33:00.156
2020-04-19 23:33:00.157 (_)
2020-04-19 23:33:00.158 __ ____ _ _ __ _ __ _ _ __ __ _
2020-04-19 23:33:00.158 \ \ /\ / / _` | '__| '_ \| | '_ \ / _` |
2020-04-19 23:33:00.159 \ V V / (_| | | | | | | | | | | (_| |
2020-04-19 23:33:00.160 \_/\_/ \__,_|_| |_| |_|_|_| |_|\__, |
2020-04-19 23:33:00.160 __/ |
2020-04-19 23:33:00.161 |___/
2020-04-19 23:33:00.161
2020-04-19 23:33:00.162
2020-04-19 23:33:00.163 23:33:00: WARNING: User specified --num_sectors=1 but file only has 1 sectors. **Ignoring --num_sectors
2020-04-19 23:33:00.163
2020-04-19 23:33:00.164
2020-04-19 23:33:00.164 23:33:00: INFO: User wants to talk to port '\\.\COM12'
2020-04-19 23:33:00.165 23:33:00: INFO: Took 0.01500000 seconds to open port
2020-04-19 23:33:00.166 23:33:00: INFO: Sorting TAGS to ensure order is <configure>,<erase>, others, <patch>,<power>
2020-04-19 23:33:00.167 23:33:00: INFO: If you don't want this, use --dontsorttags
2020-04-19 23:33:00.167
2020-04-19 23:33:00.168 23:33:00: INFO: Looking for file 'fh_gpt_header_0'
2020-04-19 23:33:00.171
2020-04-19 23:33:00.172
2020-04-19 23:33:00.172 (_)
2020-04-19 23:33:00.173 __ ____ _ _ __ _ __ _ _ __ __ _
2020-04-19 23:33:00.174 \ \ /\ / / _` | '__| '_ \| | '_ \ / _` |
2020-04-19 23:33:00.174 \ V V / (_| | | | | | | | | | | (_| |
2020-04-19 23:33:00.175 \_/\_/ \__,_|_| |_| |_|_|_| |_|\__, |
2020-04-19 23:33:00.176 __/ |
2020-04-19 23:33:00.177 |___/
2020-04-19 23:33:00.178
2020-04-19 23:33:00.179
2020-04-19 23:33:00.179 23:33:00: WARNING: Couldn't find the file 'fh_gpt_header_0', returning NULL
2020-04-19 23:33:00.180 23:33:00: INFO: Sending <configure>
2020-04-19 23:33:00.181
2020-04-19 23:33:00.181 23:33:00: INFO: TARGET SAID: 'INFO: Binary build date: Dec 27 2019 @ 18:17:54'
2020-04-19 23:33:00.182
2020-04-19 23:33:00.182 23:33:00: INFO: TARGET SAID: 'INFO: Binary build date: Dec 27 2019 @ 18:17:54
2020-04-19 23:33:00.183 '
2020-04-19 23:33:00.184
2020-04-19 23:33:00.184 23:33:00: INFO: TARGET SAID: 'INFO: Chip serial num: 2650911984 (0x9e01b4f0)'
2020-04-19 23:33:00.185
2020-04-19 23:33:00.186 23:33:00: INFO: TARGET SAID: 'INFO: Supported Functions (14):'
2020-04-19 23:33:00.187
2020-04-19 23:33:00.188 23:33:00: INFO: TARGET SAID: 'INFO: program'
2020-04-19 23:33:00.188
2020-04-19 23:33:00.189 23:33:00: INFO: TARGET SAID: 'INFO: read'
2020-04-19 23:33:00.190
2020-04-19 23:33:00.190 23:33:00: INFO: TARGET SAID: 'INFO: nop'
2020-04-19 23:33:00.191
2020-04-19 23:33:00.191 23:33:00: INFO: TARGET SAID: 'INFO: patch'
2020-04-19 23:33:00.192
2020-04-19 23:33:00.192 23:33:00: INFO: TARGET SAID: 'INFO: configure'
2020-04-19 23:33:00.193
2020-04-19 23:33:00.194 23:33:00: INFO: TARGET SAID: 'INFO: setbootablestoragedrive'
2020-04-19 23:33:00.194
2020-04-19 23:33:00.195 23:33:00: INFO: TARGET SAID: 'INFO: erase'
2020-04-19 23:33:00.196
2020-04-19 23:33:00.196 23:33:00: INFO: TARGET SAID: 'INFO: power'
2020-04-19 23:33:00.197
2020-04-19 23:33:00.198 23:33:00: INFO: TARGET SAID: 'INFO: firmwarewrite'
2020-04-19 23:33:00.198
2020-04-19 23:33:00.199 23:33:00: INFO: TARGET SAID: 'INFO: getstorageinfo'
2020-04-19 23:33:00.199
2020-04-19 23:33:00.200 23:33:00: INFO: TARGET SAID: 'INFO: benchmark'
2020-04-19 23:33:00.201
2020-04-19 23:33:00.201 23:33:00: INFO: TARGET SAID: 'INFO: emmc'
2020-04-19 23:33:00.202
2020-04-19 23:33:00.202 23:33:00: INFO: TARGET SAID: 'INFO: ufs'
2020-04-19 23:33:00.203
2020-04-19 23:33:00.203 23:33:00: INFO: TARGET SAID: 'INFO: fixgpt'
2020-04-19 23:33:00.204
2020-04-19 23:33:00.205 23:33:00: INFO: TARGET SAID: 'INFO: End of supported functions 14'
2020-04-19 23:33:00.205
2020-04-19 23:33:00.207 23:33:00: INFO: TARGET SAID: 'ERROR: Only nop and sig tag can be recevied before authentication.'
2020-04-19 23:33:00.208 23:33:00: INFO: fh.attrs.MaxPayloadSizeToTargetInBytes = 1048576
2020-04-19 23:33:00.210 23:33:00: INFO: fh.attrs.MaxPayloadSizeToTargetInBytesSupported = 1048576
2020-04-19 23:33:00.211 23:33:00: INFO: Something failed. The target rejected your <configure>. Please inspect log for more information
2020-04-19 23:33:00.211
2020-04-19 23:33:00.212 Writing log to 'C:\Users\Administrator\AppData\Roaming\Qualcomm\QFIL\COMPORT_12\port_trace.txt', might take a minute
2020-04-19 23:33:00.213
2020-04-19 23:33:00.213
2020-04-19 23:33:00.214 Log is 'C:\Users\Administrator\AppData\Roaming\Qualcomm\QFIL\COMPORT_12\port_trace.txt'
2020-04-19 23:33:00.215
2020-04-19 23:33:00.215 Download Fail:FireHose Fail:FHLoader Fail:FHLoader Failrocess fail
2020-04-19 23:33:00.225 Finish Get GPT
the other Log is attached here.
View attachment port_trace.txt

Excuse me, do you happen to have any official documentation on EDL?
Sorry for the slight offtopic.

Phone stuck in EDL Mode
Hello hikari, my device Nokia 4.2 (TA-1152) is stuck in EDL MODE after dumping the boot image file.
Can you please help me to exit from EDL mode?

Hi! even with another firehose, Crosscall Core-X3 won't accept entering Sahara mode. wrong 'pkhash'.
Recovery show HS8917QC, modem show 8937. I tried many of each without success. I don't know which one is relevant.
[ro.product.device]: [HS8917QC]
[ro.hmct.modem.version]: [MSM8937.LA.3.0.1-00490-STD.PROD-1]
[ro.fota.oem]: [hisense8917_8.1]
[ro.fota.platform]: [MSM8917_8.1]
[ro.bootimage.build.fingerprint]: [CROSSCALL/L750/HS8917QC:8.1.0....]
[gsm.version.baseband]: [MPSS.JO.3.0-00464-8937_GENNS_PACK-1]
[gsm.version.baseband1]: [MPSS.JO.3.0-00464-8937_GENNS_PACK-1]
fastboot getvar all : https://pastebin.com/pmPDpeJ8
Of course no firehose neither full image is available for this exotic device.
Bless you.

Thank you for providing the instructions!
I'd like to extract LeEco Le Max 2 (X820) but QFIL won't bring me the Partition Table.
Device recognized as "Qualcomm HS-USB QDLoader 9008 (COM12)" in Device Manager.
QFIL tells me 10:52:37: ERROR: function: sahara_rx_data:276 Unable to read packet header. Only read 0 bytes.
(Log attached.)
I used "prog_emmc_firehose_8996_ddr.elf" because I didn't find a firehose for X820. May this error be caused by a wrong firehose file? If yes, is it safe to have a try with one of the firmware image files without bricking the device or destroying data?
Length Name
------ ----
16777216 adspso.bin
405504 BTFM.bin
201304 cmnlib.mbn
256008 cmnlib64.mbn
1048576 ddr.mbn
39976 devcfg.mbn
296 devinfo.bin
793040 emmc_appsboot.mbn
264120 hyp.mbn
226008 keymaster.mbn
85004288 NON-HLOS.bin
42728 pmic.elf
229540 rpm.mbn
1634304 tz.mbn
1836136 xbl.elf
Or is it more likely that this model just doesn't respond?

Anyone ever tried this on an ROG phone 2?

Step 3: Open QFIL, load Firehose file
Hello everyone. I have nokia 1.4 TA-1322. I have downloaded several firmwares from the different websites but the emmc filefouse prog_emmc_firehose *** ddr.mbn and Rawprogram .xml files missing in all of them.
Do someone know where can I fount the emmc Firehose and Rawprogram .xml files?

hikari_calyx said:
This is the partition table of your phone. Please take note on the Start LBA and LBA number of the last partition.
Take HP Elite X3 partition table for example, the last partition is "Data", it's Start LBA and LBA number are 0x01E20000 and 0x0565BFDF. Add both of them will get the total sector numbers of whole eMMC storage - in this case, 0x0747BFDF, or 122,142,687 sectors. Multiple the sector numbers with 512 will get the total bytes of the eMMC storage, in this case, the capacity of eMMC storage is 62,537,055,744‬ bytes.
Click to expand...
Click to collapse
Hello, my partitions on my phone are wildly different compared to these. The userdata partition says it's only about 3,933,729,792 bytes. It's a 32GB phone, any reasons why it's so tiny?

Thanks for taking time to write all this out and help out a lot of people. Everything made sense until I got to
"it's Start LBA and LBA number are 0x01E20000 and 0x0565BFDF. Add both of them will get the total sector numbers of whole eMMC storage - in this case, 0x0747BFDF, or 122,142,687 sectors"
I don't think this is common knowledge. Could you please explain or just point me in the right direction to understand how adding 0x01E20000 and 0x0565BFDF resulted in 0x0747BFDF, and how we translate that string of characters into 122,142,687?
Thank you!

Hello everyone. I have a bricked Asus Zenfone 8 and I'm trying to recover userdata partitiion from it using 9008 mode. I have correct Firehose file and everything should work fine. I've easily recovered data from system partition using this manual, but I have problem with userdata. This partition is huge, around 230 GB, and phone just disconnects from PC in the middle of the process. First time it downloaded 98GB, second time - 60GB, so I don't think this is because of broken flash memory or smth. What can be a reason of this problem and how to solve that? Thanks for any reply!

Cirrus9 said:
Thanks for taking time to write all this out and help out a lot of people. Everything made sense until I got to
"it's Start LBA and LBA number are 0x01E20000 and 0x0565BFDF. Add both of them will get the total sector numbers of whole eMMC storage - in this case, 0x0747BFDF, or 122,142,687 sectors"
I don't think this is common knowledge. Could you please explain or just point me in the right direction to understand how adding 0x01E20000 and 0x0565BFDF resulted in 0x0747BFDF, and how we translate that string of characters into 122,142,687?
Thank you!
Click to expand...
Click to collapse
Hi. This string of characters is hexadecimal numeral system. You can use standart Windows calculator in programmer mode to convert these numbers.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Thank you! Learned something new today!

Hi! This guide is great. I have an issue with the firehose file where I found the right firehose file from my device using firehose finder on GitHub. However, that file is in .bin format instead of .elf. How can I convert it, and is that safe?

kjullian19 said:
However, that file is in .bin format instead of .elf. How can I convert it, and is that safe?
Click to expand...
Click to collapse
Firehose loaders are technically ELF 32 or 64 bit files but may be named elf, bin, img, mbn, whatever.
Use a hex editor and look at the start of the file.
It should be 7f 45 4c 46
Or use my elfview.exe (in the sig) to check it out.
Or use my qcomview.exe (in the sig) to check it out.
Code:
C:\>elfview /p motog.bin
# Type Flags Size Offset Address
-- ------- ----- ------- ------ --------
0 null 7 1016 000000 00000000
1 null 2.2 7384 001000 4602c000
2 load RWZ 0 06b4b0 0c100000
3 load RX 7772 0549f0 0c119000
4 load RWZ 0 056850 0c11c000
5 load RWZ 0 06b4b0 0c11e000
6 load RWZ 0 0549f0 0c219000
7 load RX 301376 003000 0c225000
8 load RWZ 0 04c940 0c276c00
9 load RW 32932 04c940 0c279c00
10 load RWZ 0 0549f0 0c286c00
11 load RWX 85080 056850 0c29b000
12 load 1RWX 84 06b4b0 0c2c9000
13 load 1RWX 29168 06b504 0c2c9054
14 load 1RWX 1496 0726f4 0c2d0244
15 load 5RX 139264 072ccc 0c350000
16 load RWZ 0 0549f0 45e11000
C:\>qcomview /h motog.bin
64 bit ELF, Version 6, SHA384
0 00000000 000003f8 a3836cd6c3e2dbed 5dd00c97349c8598 92a5051c08ae65d4 171ba1ece407a7b2 1cdf27a97ff437c7 0488bb944956fbc2 Ok
1 00001000 00001cd8
2 0006b4b0 00000000
3 000549f0 00001e5c 3972d9e5346b52cc e71c31a437500b8f 57f2fc8124e97cd5 b2f70a4829e98196 03d89d4b946261e2 9b2a58949b92b7dc Ok
4 00056850 00000000
5 0006b4b0 00000000
6 000549f0 00000000
7 00003000 00049940 503b424c75f6d657 e4363c830deeebee afe0ac82ce04dfec e8ac03fb47b129a3 fc221acc0d515b22 ed17d86b0f6b585c Ok
8 0004c940 00000000
9 0004c940 000080a4 2f7aec3605fbce70 ec0c83a703435845 e969988f390787d7 aa8d0a13a6d9e06f ee2af4e9b86b8a75 fc81fbe1017d1c64 Ok
10 000549f0 00000000
11 00056850 00014c58 fec3a6b9f6d71a18 aadd3f722fc73bea d3197c24c397d55d 4f3d4a9c25661db1 152c60664fcbe4a6 c2441120afc4b3c9 Ok
12 0006b4b0 00000054 db139c6f70d88269 a61cb1a7be2ce363 55faf1ff1c3b9c3d 27cd8d65bef7f710 9bc83c6255ea8104 6d7ac582cc778f15 Ok
13 0006b504 000071f0 a27a7dc0040a1bfa 8e24e4a42bead90e ae10a91c37d19105 bce9da69383004ea c933b87ac4a88653 ccbb4a6b1407d15d Ok
14 000726f4 000005d8 8dcaae787361a3c4 3bad6d344641d061 35170b5a30607e20 a30cd23884bbc0b0 790681aa36a1fe60 98501a103b62088a Ok
15 00072ccc 00022000 1f939df47e7fae80 2c127e10474ff9e6 2faecd5fab873bf8 928cab0a5ef28261 5d4b19cc57cca817 37fa9fad42971c40 Ok
16 000549f0 00000000

Thanks Renate. I'm new to this stuff, so you might have to ELI5, I'm not seeing 7f 45 4c 46 in your log.
Ultimately, I need to learn how to convert the binary file into a compatible .elf file. Will either elfview or qcomview do that?
Thanks again and sorry for the dumb questions

Axon 10 Pro Fully bricked

Hi,
I tried to flash my A2020G, as I have with other phones before. I got stuck in a Bootloop but managed to recover with the US firmware and was able to install twrp. In twrp I completely wiped and formatted the data, as i normally do. Then, I couldnt send a zip file over, so I tried to reboot. Bad Idea! I lost my recovery (Device corrupt). So I reflashed the firmware, but still got stuck in a bootloop, tried everything, nothing got me out. So I flashed the Axon 7 firmware. Even worse Idea. Now, the screen stays black, none of the combinations work. When I plug it in it connects and the Programmer of the edl tool connects as well. I reflashed everything but the screen still stays black. No acces to fastboot as well. Now I'm helpless and hope someone can help me out! When I do edl reset, it gives me this error, maybe that can help.
12:11:48: INFO: Sending <power>
_____
| ___|
| |__ _ __ _ __ ___ _ __
| __| '__| '__/ _ \| '__|
| |__| | | | | (_) | |
\____/_| |_| \___/|_|
12:11:50: {ERROR: XML not formed correctly. Expected a < character at loc 0}
_____
| ___|
| |__ _ __ _ __ ___ _ __
| __| '__| '__/ _ \| '__|
| |__| | | | | (_) | |
\____/_| |_| \___/|_|
12:11:50: {ERROR: 3. TAG not found or recognized}
_____
| ___|
| |__ _ __ _ __ ___ _ __
| __| '__| '__/ _ \| '__|
| |__| | | | | (_) | |
\____/_| |_| \___/|_|
12:11:50: {ERROR:
There is a chance your target is in SAHARA mode!!
There is a chance your target is in SAHARA mode!!
There is a chance your target is in SAHARA mode!!
This can mean
1. You forgot to send DeviceProgrammer first (i.e. QSaharaServer.exe -s 13rog_emmc_firehose_8994_lite.mbn)
2. OR, you did send DeviceProgrammer, but it has crashed and/or is not correct for this target
Regardless this program speaks FIREHOSE protocol and your target is speaking SAHARA protcol, so this will not work
}
Writing log to 'D:\gfrtill\Downloads\Axon10Pro_(More)_EDL_Tools_v1.1d\Axon10Pro_(More)_EDL_Tools_v1.1d\Reset (from EDL)\port_trace.txt', might take a minute
Log is 'D:\gfrtill\Downloads\Axon10Pro_(More)_EDL_Tools_v1.1d\Axon10Pro_(More)_EDL_Tools_v1.1d\Reset (from EDL)\port_trace.txt'
Press any key to exit

Error has now gone, still no output though. Im guessing i might have ruined one of the drivers?!?

Use QFIL or Windows 7 64-bit command line tool + "QSaharaserver.exe" + "fh_loader.exe", through "Qualcomm HS-USB QDLoader 9008（COM30）" to OPPO R9S

Use QFIL or Windows 7 64-bit command line tool + "QSaharaserver.exe" + "fh_loader.exe", through "Qualcomm HS-USB QDLoader 9008（COM30）" to OPPO R9S, send the "img" file is always failed.
Hello everyone,
I often encountered an acquaintance in these days: Mr."Error" !
I don't like him at all, but he often shakes in front of me. My head is a bit dizzy!
Is there any good way to disappear this Mr. "Error"?
First, my computer's system: Windows 7 64-bit, has entered the test mode.
The screenshot of the test mode is as follows:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Second, the OPPO R9S mobile phone uses the Snapdragon 625 (MSM8953) CPU, eMMC 5.1 model of memory.
After OPPO R9S mobile phone connecting to the computer with a USB cable, the opening is first vibrating, and then it is in a black screen state.
Then, in the Windows device manager, the port (COM and LPT) can see "Qualcomm HS-USB QDLoader 9008 (COM30)" device.
##########################################################
The first kind test：
The tools used is as follows:
QFIL Version 2.0.2.3
OPPO R9S related files——prog_emmc_firehose_8953_ddr.mbn、rawprogram0.xml、patch0.xml、recovery.img
In the process of use, in the device manager, the port (COM and LPT) can see "Qualcomm HS-USB QDLoader 9008（COM30）" device.
Test failed.
Mr. "Error" Say:
2022-02-03 12:36:18.083 12:36:17: ERROR: function: sahara_rx_data:277 Unable to read packet header. Only read 0 bytes.
2022-02-03 12:36:18.083
2022-02-03 12:36:18.099 12:36:17: ERROR: function: sahara_main:983 Sahara protocol error
2022-02-03 12:36:18.099
2022-02-03 12:36:18.099 12:36:17: ERROR: function: main:320 Uploading Image using Sahara protocol failed
2022-02-03 12:36:18.115
2022-02-03 12:36:18.115
2022-02-03 12:36:18.115 Download Fail:Sahara Fail:QSaharaServer Failrocess fail
2022-02-03 12:36:18.115 Finish Download
Screenshot below:
Why ? Sahara doesn't like me? ? ?
##########################################################
Second kind test:
The tools used is as follows:
Windows 7 64-bit command line tool, QSaharaServer.exe and fh_loader.exe in the MiFlash 20191206 toolbox,
OPPO R9S related files——prog_emmc_firehose_8953_ddr.mbn、rawprogram0.xml、patch0.xml、recovery.img
In the process of use, in the device manager, the port (COM and LPT) can see "Qualcomm HS-USB QDLoader 9008（COM30）" device.
The relevant main orders I entered are as follows:
QSaharaServer.exe –p \\.\COM30 -s 13:\OPPOR9S\113391\6\prog_emmc_firehose_8953_ddr.mbn
fh_loader.exe --port=\\.\COM30 --erase=0 --sendxml=rawprogram0.xml,patch0.xml --search_path=D:\OPPOR9S\113391\6 --noprompt --showpercentagecomplete --memoryname=eMMC --reset
Testing still failed.
Mr. "Error" shouted:
_____
| ___|
| |__ _ __ _ __ ___ _ __
| __| '__| '__/ _ \| '__|
| |__| | | | | (_) | |
\____/_| |_| \___/|_|
12:45:22: {ERROR: ReadPort:5272 Could not read from '\\.\COM30', Windows API ReadFile failed! Your device is probably *not* on this port
However, this Mr. "Error" is wrong!
I clearly see that there is "Qualcomm HS-USB QDLoader 9008 (COM30)" in port (COM and LPT).
Why??????????????

Things have changed.
After connecting the phone to the computer, press the "Volume +", "Volume -" and "Power" buttons at the same time for 10 seconds.
So, in the device manager, the original "Qualcomm HS-USB QDLoader 9008 (COM30)" has become "Qualcomm HS-USB QDLoader 9008 (COM3)".
So, the old Mr. Error is gone.
However, here comes the new Mr. Error.
Note: The following error log content, the original text is without emoji pictures.
#################QFIL Error begin#########################
QFIL Error:
……
2022-02-04 02:23:28.706 31: mba.mbn
2022-02-04 02:23:28.706 13: D:\OPPOR9S\113391\6\prog_emmc_firehose_8953_ddr.mbn
2022-02-04 02:23:28.706
2022-02-04 02:23:28.722 02:23:28: Requested ID 13, file: "D:\OPPOR9S\113391\6\prog_emmc_firehose_8953_ddr.mbn"
2022-02-04 02:23:28.722
2022-02-04 02:23:28.722 02:23:28: 353828 bytes transferred in 0.281000 seconds (1.2008MBps)
2022-02-04 02:23:28.737
2022-02-04 02:23:28.737
2022-02-04 02:23:28.737
2022-02-04 02:23:28.737 02:23:28: File transferred successfully
2022-02-04 02:23:28.737
2022-02-04 02:23:28.737
2022-02-04 02:23:28.753 NOTE: Target requested image 13 which is DeviceProgrammer. Forcing QUIT. This is by design, ** All is well ** SUCCESS!!
2022-02-04 02:23:28.753
2022-02-04 02:23:28.753
2022-02-04 02:23:28.753 02:23:28: Sahara protocol completed
2022-02-04 02:23:28.769 Sending Programmer Finished
2022-02-04 02:23:28.784 Switch To FireHose
2022-02-04 02:23:28.784 Wait for 3 seconds...
2022-02-04 02:23:31.795 Max Payload Size to Target:49152 Bytes
2022-02-04 02:23:31.795 Device Type:emmc
2022-02-04 02:23:31.795 Platform:8x26
2022-02-04 02:23:31.811 Disable Ack Raw Data Every N Packets
2022-02-04 02:23:31.811 Skip Write:False
2022-02-04 02:23:31.811 Always Validate:False
2022-02-04 02:23:31.811 Use Verbose:False
2022-02-04 02:23:31.889 ***** Working Folder:C:\Users\Userstest\AppData\Roaming\Qualcomm\QFIL\COMPORT_3
2022-02-04 02:23:31.920 Download Fail:FireHose Fail:FHLoader Fail:FHLoader Fail:The system can not find the file specified.
2022-02-04 02:23:31.998 Finish Get GPT
#################QFIL Error end#########################
######"QSaharaserver.exe + fh_loader.exe" Error begin############
"QSaharaserver.exe + fh_loader.exe" Error:
_____
| ___|
| |__ _ __ _ __ ___ _ __
| __| '__| '__/ _ \| '__|
| |__| | | | | (_) | |
\____/_| |_| \___/|_|
23:50:47: {ERROR: DetermineTag:6180 XML not formed correctly. Expected a < character at loc 0
_____
| ___|
| |__ _ __ _ __ ___ _ __
| __| '__| '__/ _ \| '__|
| |__| | | | | (_) | |
\____/_| |_| \___/|_|
23:50:47: {ERROR: GetNextPacket:7254 3. TAG not found or recognized
_____
| ___|
| |__ _ __ _ __ ___ _ __
| __| '__| '__/ _ \| '__|
| |__| | | | | (_) | |
\____/_| |_| \___/|_|
23:50:47: {ERROR: GetNextPacket:7264
There is a chance your target is in SAHARA mode!!
There is a chance your target is in SAHARA mode!!
There is a chance your target is in SAHARA mode!!
This can mean
1. You forgot to send DeviceProgrammer first (i.e. QSaharaServer.exe -s 13rog_emmc_firehose_8994_lite.mbn)
2. OR, you did send DeviceProgrammer, but it has crashed and/or is not correct for this target
Regardless this program speaks FIREHOSE protocol and your target is speaking SAHARA protcol, so this will not work
######"QSaharaserver.exe + fh_loader.exe" Error end############
prog_emmc_firehose_8953_ddr.mbn、rawprogram0.xml、patch0.xml、recovery.img---Is there something wrong with these files?
It took me a lot of time to find these files at first, and I got them from some maintenance software.
By the way: how do you get these files in general?
Don't tell me about the official website of the mobile phone, they do not provide wire brush packs publicly.

"FHLoader Fail" problem solved.
Before I solved it, I also found it difficult.
After various attempts and searches, I accidentally checked the installation directory of "QFIL" and found that there is no "fh_loader.exe" file in this directory.
Copy the file "fh_loader.exe" from other places to the installation directory of "QFIL", and then try to read the information of each partition of eMMC, this time it is successful.
Check out the screenshot:
Next, I can do some of the things I want to do.
Did something go wrong? ! Does that solve it? Is it too simple?
I have encountered this kind of thing many times, and sometimes it is just a small oversight, and as a result, it takes a lot of time to check.

Qualcomm abl (Android bootloader) packing/signing

The Qualcomm XBL (SBL1) and Firehose loader images are packed somewhat reasonably.
They are ELF images (32 or 64 bit) with no sections but 3 or more programs:
Code:
E:\>elfview xbl /p
# Type Flags Size Offset Address
-- ------- ----- ------- ------ --------
0 null 960 000000 00000000 // this is the standard ELF header
1 null 6952 001000 9fdb6000 // this is the signing
2 load RX 350012 003000 14015000 // these are various things that actually get loaded
3 load RWZ 0 058740 14077000
4 load RW 31844 058740 1407a000
5 load RWZ 0 0603B0 14084800
6 load RWZ 0 0603B0 85e00000
7 load RX 11824 0603B0 146ae000
8 load RW 2916 0631E0 146b1000
9 load RWX 107032 063D50 14098000
10 load RWZ 0 07DF70 146b2000
11 load RWX 1792000 07DF70 9fc00000
12 load RX 78208 233770 14699000
13 load RX 171536 2468F0 85e35000
14 load RW 6409 270700 85ea8000
15 load RWZ 0 272010 85e97000
That is to say:
Code:
32 bit ELF file
Program table
Signing
Header
Hashes // one for each program, the 2nd is zeroes as you can't hash the hash!*
Signature
Certificate chain
Payload // multiple programs
So the XBL loads the next one, usually abl which is the Android bootloader which also implements the fastboot protocol.
Now we get a bit deep in the gumbo:
Code:
E:\>elfview abl /p
# Type Flags Size Offset Address
-- ------- ----- ------- ------ --------
0 null 148 000000 00000000 // this is the standard ELF header
1 null 6536 001000 9fa22000 // this is the signing
2 load RWX 139264 003000 9fa00000
Code:
32 bit ELF file
Program table
Signing
Header
Hashes
Signature
Certificate chain
LZMA archive
MZ Windows executable
PE Portable executable
64 bit ARM code
This is all (U)EFI compatibility so it has sworn fealty to Intel/Microsoft.
So, accepting all the idiocy of this, my question remains:
7-Zip can extract the structure of what is the #2 (i.e. the third) program:
Code:
C:\>7zip ablefi
Type = UEFIf
ERRORS:
Headers Error
Physical Size = 139264
Method = LZMA
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
D.... 9E21FD93
D.... 9E21FD93\EE4E5898
..... 0 9E21FD93\EE4E5898\0.raw
D.... 9E21FD93\EE4E5898\VOLUME
..... 20 9E21FD93\EE4E5898\VOLUME\FFFFFFFF
..... 376832 9E21FD93\EE4E5898\VOLUME\LinuxLoader.efi
------------------- ----- ------------ ------------ ------------------------
376852 139264 3 files, 3 folders
Errors: 1
The "program" itself starts with 16 bytes 0x00.
If I remove these 16 bytes then 7-Zip can't decypher the file.
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
*Please note that although you can't hash the hash, you can Can the Can

@Appreciative
Sorry, I don't have anything technical documents on this at all except for Qualcomm stuff at the level of a PowerPoint.
All that stuff from booting onward is non-disclosure aggreement restricted.
I think that SecureBoot is in a OTP (one time programmable) fuse, but I don't know.
I can monitor the hardware console while booting the Firehose loader:
Code:
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.4-00246-S660LZB-1
S - IMAGE_VARIANT_STRING=Sdm660LA
S - OEM_IMAGE_VERSION_STRING=cibuild
S - Boot Interface: Unknown
S - Secure Boot: Off
S - Boot Config @ 0x00786070 = 0x000001c1
S - JTAG ID @ 0x00786130 = 0x000cc0e1
S - OEM ID @ 0x00786138 = 0x00000000
S - Serial Number @ 0x12345678 = 0x12345678
S - OEM Config Row 0 @ 0x00784188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00784190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x007841a0 = 0x007030000b580100
S - Feature Config Row 1 @ 0x007841a8 = 0x00000000000000c0
S - Core 0 Frequency, 3715 MHz
S - PBL Patch Ver: 5
S - I-cache: On
S - D-cache: On
B - 0 - PBL, Start
B - 7024 - bootable_media_detect_entry, Start
B - 141363 - bootable_media_detect_success, Start
B - 141369 - elf_loader_entry, Start
B - 19372540 - auth_hash_seg_entry, Start
B - 19372841 - auth_hash_seg_exit, Start
B - 19481121 - elf_segs_hash_verify_entry, Start
B - 19534026 - elf_segs_hash_verify_exit, Start
B - 19534831 - auth_xbl_sec_hash_seg_entry, Start
B - 19563960 - auth_xbl_sec_hash_seg_exit, Start
B - 19563963 - xbl_sec_segs_hash_verify_entry, Start
B - 19570674 - xbl_sec_segs_hash_verify_exit, Start
B - 19570719 - PBL, End
B - 0 - SBL1, Start
I've also pieced together some addresses from logs and dumping the DTB:
Code:
00780000 msm-core
00780350 secure_boot
00784138 serial_number
00784188 oem_config0
00784190 oem_config1
007841a0 feature_config0
007841a8 feature_config1
00786040 jtagfuse
00786070 boot_config
00786130 jtag_id
00786138 oem_id

Nice work. This saved me days of hard work.
Renate said:
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
Click to expand...
Click to collapse
Did you ever find a solution to this re-pack problem? I'd like to do something similar for the bootloader on my tablet.

Yahoo Mike said:
Did you ever find a solution to this re-pack problem? I'd like to do something similar for the bootloader on my tablet.
Click to expand...
Click to collapse
Nope, I havn't gotten back to this yet.
I guess it's just a question of biting the bullet and diving into this swamp of stupid packing.

Renate said:
...
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
Click to expand...
Click to collapse
After a bit of research, I can answer that question.
It starts with nulls because it's not an LZMA header. It's a UEFI Firmware Volume (FV) header, in which the first 16 bytes are always zero.
I looked at a few UEFI FV editing tools, but none of them do quite what we want. So I've started on my own. I'll keep you posted on progress.
Here's a summary of my research:
Code:
The layout of a UEFI Firmware Volume
====================================
see: UEFI Platform Initialization Specification, Vol. 3 (https://uefi.org/specifications)
see also: https://sudonull.com/post/125061-UEFI-BIOS-file-device-part-two-UEFI-Firmware-Volume-and-its-contents
+----------------+----------------+
| | FV Header |
| |================|--------------------+-------------------+
| | | | FF Header |
| | | |===================|---------------+
| | | | | FS Header |
| | | | FF Section (FS) |===============|
| | | | #1 | data |
| | | Firmware File (FF) | | |
| | | #1 |-------------------|---------------+
| | | | . . . | . . .
| | | |-------------------|
| | | | FF Section (FS) |
| UEFI | Firmware | | #N |
| Firmware | File |--------------------|-------------------+
| Volume (FV) | System (FFS) | | . . .
| | | . . . |
| | | |
| | |--------------------|
| | | |
| | | Firmware File (FF) |
| | | #N |
| | | |
+----------------+----------------+--------------------+
To implement this, an object model might look like this:
* a FirmwareVolume object has 1 FirmwareFileSystem
* a FirmwareFileSystem has 0..n FirmwareFile objects
* a FirmwareFile object has 0..n FirmwareFileSection objects
Just to make life interesting, one type of FF Section is the EFI_SECTION_FIRMWARE_VOLUME_IMAGE.
It has a UEFI Firmware Volume as its data. So there can be FVs nested in other FVs ad infinitum.
FF Sections can also be encrypted, compressed or encoded by an OEM.
Once decrypted/decompressed/decoded, these sections contain further FF sections.
And in accordance with Murphy's Law, the file we want (LinuxLoader.efi) is in one of those nested firmware volumes. ...And you guessed it - the nested FV is compressed using LZMA. Presumably that's deliberate - so you can't directly edit the bootloader in the abl.elf.
So I plan for my tool to do two things:
extract the LinuxLoader.efi file from the abl.elf file
repack a modified LinuxLoader.efi back into the ELF file.
I don't know if a repack will work. There are some checksums in the EFi headers. And the whole ABL.ELF might be signed by a private RSA key and the SoC will refuse to load it without the correct signature. We'll see..

Yahoo Mike said:
After a bit of research, I can answer that question.
It starts with nulls because it's not an LZMA header. It's a UEFI Firmware Volume (FV) header, in which the first 16 bytes are always zero.
Click to expand...
Click to collapse
Well, that's very clever of them. Most standards use "magic" values in the header.
These guys have taken a bold stand: "When you see 16 0x00 it's an unambiguous sign that you've found our UEFI FV!"
<rant>
I've dealt with kernels that were uncompressed, compressed with gzip or compressed and a decompressor stub.
So, imagine my surprise when I ungzipped a kernel from a boot image recently and found that it starts with "MZ".
"OMG, did Bill Gates buy Android? Is this the MS-DOS compatibilty layer?"
No, it's just the MS-DOS header stuck on a Windows PE header stuck on a kernel.
Code:
00000000 t _head
00000000 T _text
00000040 t pe_header
00000044 t coff_header
00000058 t optional_header
00000070 t extra_header_fields
000000f8 t section_table
00001000 T do_undefinstr
00001000 t efi_header_end
00001000 T _stext
</rant>

Renate said:
Well, that's very clever of them. Most standards use "magic" values in the header.
These guys have taken a bold stand: "When you see 16 0x00 it's an unambiguous sign that you've found our UEFI FV!"
<rant>
I've dealt with kernels that were uncompressed, compressed with gzip or compressed and a decompressor stub.
So, imagine my surprise when I ungzipped a kernel from a boot image recently and found that it starts with "MZ".
"OMG, did Bill Gates buy Android? Is this the MS-DOS compatibilty layer?"
No, it's just the MS-DOS header stuck on a Windows PE header stuck on a kernel.
Code:
00000000 t _head
00000000 T _text
00000040 t pe_header
00000044 t coff_header
00000058 t optional_header
00000070 t extra_header_fields
000000f8 t section_table
00001000 T do_undefinstr
00001000 t efi_header_end
00001000 T _stext
</rant>
Click to expand...
Click to collapse
Yes, very clever. But there is method in their madness. According to the spec: "The first 16 bytes are reserved to allow for the reset vector of processors whose reset vector is at address 0."
There is a bit of magic at byte 0x28 in the FV header. It's always "_FVH". That's how you identify a UEFI FV. But I guess the first 16 nulls are always a big hint.
...and it's great to see that the ghost of MS-DOS lives on. It reminds me of what we used to say in my early programming days: "DOS is boss".

I've been looking into this hashing business.
I know that I'm basically on the right track.
I can take a Firehose loader (basically a custom xbl) make a trivial spelling change somewhere and it will refuse to load.
I can recalculate the SHA256, replace it and it will load correctly.
I have a WIP that checks the hashes on xbl/abl/firehose loaders (all basically the same).
I see tons of files that check out 100%.
Code:
C:\>qcomview /h poke3.bin
64 bit ELF, SHA256
0 00000000 00000318 a117dbc5 e643e404 361bfe30 45fbda01 4c153842 59a4cbe8 09b7da55 a2dd413e OK
1 00001000 00001ac8
2 00003000 0005709c 7b833734 f2763b9e 35f3310c f6fb22a9 a514eac0 3eddbe46 b5ff339b 3c7b045c OK
3 0005a0a0 00000000
4 0005a0a0 00009f00 6296c006 31852f79 b99691c3 e8d598f2 9d323e9a ba0358aa b742901f 506709d5 OK
5 00063fa0 00009908 41176495 3e07ad84 8923398e ce854131 91066dca 43f253fa c027c4f4 a3c21483 OK
6 0006d8b0 00000000
7 0006d8b0 00001e7c fe77c473 b02e4a71 d3f287e4 cf85ccbe b5a43326 53930bd8 d68e4e40 6e71a0b8 OK
8 0006f730 00000000
9 0006f730 000188d8 1bfef74c ed467a22 8616419d e71ab1ea 22a717e5 4874c704 541793ed f5d5c5e5 OK
10 00088010 00000000
11 00088010 00000000
12 00088010 00012dc0 b72cb77e 81026632 446c3462 cc6c83fc d7904333 cb8807cc 27d6e4c9 189c7ca4 OK
I see a bunch of files that don't check out at all.
I can SHA256 a program chunk and the SHA256 appears nowhere in the entire file.
Are they salting the SHA256 or using a different hash?
Edit: Oh, it looks like SHA512. Er, maybe SHA3 512?
Edit: Ok, big deal, so I can't count. It's SHA(2)-384. WIP can be found http://www.temblast.com/qcomview.htm
The SHA256 displays the calculated and verifies.
The SHA384 displays the file content and does not verify (yet). calculated and verifies.
There is also an option to dump an ASN1 listing of the certificate chain.

Renate said:
WIP can be found http://www.temblast.com/qcomview.htm
Click to expand...
Click to collapse
qcomview works great. Thanks.
With @Renate 's invaluable guidance, I put together a tool to extract the LinuxLoader from the abl.elf file, and to repack a modified LinuxLoader back into the abl.elf file. But it comes with a warning: don't try to run a modified abl.elf on a device with SecureBoot on - if you do, you will probably brick your device. Of course, if SecureBoot is off, this tool should work for you.
If you want to try it, the tool source is available at: github.com/Yahoo-Mike/lltool. It's still in beta. It was only tested on a limited number of ELF files and it might need some fine-tuning for different OEMs. So feel free to report issues or send pull requests. If it doesn't work on your ELF file, send me a link to the file and I'll see what I can do.

Yahoo Mike said:
If you want to try it, the tool source is available at...
Click to expand...
Click to collapse
Nice work! (And a bunch of it.)
I just got around to modding my abl. I just did it manually.
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
It made a world of difference. I got rid of the 30 second delay for being Orange. It seems I waste half a day with that 30 seconds.
Have you got a SecureBoot=off device?
I'm sure many people are getting sick of all the restrictions.

Renate said:
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
Click to expand...
Click to collapse
Spot on!
Renate said:
Have you got a SecureBoot=off device?
Click to expand...
Click to collapse
No, unfortunately. That's why I'm still hunting around for other options. I'm currently thinking about self-signing the modded abl.elf. Maybe I'll get lucky and the OEM allows that on my device...
BTW, I don't suppose you know the answer to this question: How to find "hw_soc_version" for a QCom SOC?

Usually the SHA256 of the root CA corresponds to the "Hash" burned into the chip.
I see that's true for about 80% of the loaders in the repository.
There may be a newish wrinkle where there is an encryption step or something.
But if you're SecureBoot, everything has to match all the way down.

Some trivia from our favorite loader repository:
Code:
Older style, not an ELF [ 89]
32 bit ELF, Version 3, SHA256 [460]
32 bit ELF, Version 3, SHA384 [ 8]
64 bit ELF, Version 3, SHA256 [ 31]
64 bit ELF, Version 5, SHA256 [ 65]
32 bit ELF, Version 6, SHA384 [ 4]
64 bit ELF, Version 6, SHA384 [ 54]
Of course a bunch of these are duplicated and put in different directories.

Renate said:
I just got around to modding my abl. I just did it manually.
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
Click to expand...
Click to collapse
I've got it down to 100% automatic now. It uses a makefile and a few of my "glue" utilities.
Code:
hexcalc size(ablmod)-3000 > hexcalc.tmp

My Xperia XZ2 got turned off secure boot after unlocking bootloader, is this actually off? I don't trust secure:no in fastboot getvar secure

I'm wondering if my phone will brick if flashing abl mod

cuynu said:
I'm wondering if my phone will brick if flashing abl mod
Click to expand...
Click to collapse
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.

Renate said:
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.
Click to expand...
Click to collapse
Unfortunately, there is no firehose loader for Xperia XZ2 nor sony phones

Renate said:
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.
Click to expand...
Click to collapse
I can get to EDL by short testpoint in the mainboard, but the PID not 9008, it is PID:ADE5

cuynu said:
I can get to EDL by short testpoint in the mainboard, but the PID not 9008, it is PID:ADE5
Click to expand...
Click to collapse
Mmm, that seems strange.
Because the VID/PID comes out of the ROM PBL and I've never seen any override on 05c6/9008.
OTOH fastboot often has wacky VID/PIDs.
Look at the manufacturer/product strings and see if it's Qualcomm CDMA Technologies MSM and QUSB__BULK.
https://www.ftdichip.com/Support/Utilities.htm#MicrosoftUSBView