bkerler
need help to make a full dump from fibocom fm190w modem
where I can find help to use this sofware to make a full dump from a fibocom fm190w? thanks
@RenateUSB here are some data: chipset is SDX75 Memory 8Gb LPDDR4x+8Gb Nand Flash
I also attach the tech specs of module. No idea what is HWID, hash. Sorry
Well, just run the Python EDL client and see what it spits out. That's presuming that you can get this thing into EDL mode. There's also a question of whether this thing has Secure Boot enabled. I've dumped some NANDs using Firehose loaders, but apparently there is also a "streaming" way. There are some real experts on modems (not me) in other places.
There are Firehoses for SDX20, SDX24, SDX55 but none I know for SDX25, SDX75
Yeah, but I'm not sure about compatibility across versions. Firehose loaders can work for multiple models.
You can use this loader to dump it: prog_firehose_sdx7x.elf.zip
Anyway the dump currently works only with rs method, because edl doesn't get the partition layout as it has changed position on these new platform
edl rs 0 262144 fibo_190_dump.bin --loader=prog_firehose_sdx7x.elf --memory=NAND
In this way you can make a raw dump. Please note that this loader treats empty\badblock as 0xEE so you cannot restore it as is. You need to repack/cleaup each partition (UBI partitions\volumes needs to be recreated by hand) :)
Mmm, there's the issue of bad blocks, but the main problem is that fresh erased EBs have to not be written as that makes them used.
Mmm, there's the issue of bad blocks, but the main problem is that fresh erased EBs have to not be written as that makes them used.
if you mean the 0xEE, the firehose loader treats emtpy\bad block in that way (it depents on how Qualcomm compiles it, some loader dump all empty\bad block with 0xFF).
Anyway if look at the raw content, you can see that offset of magic number AA73EE55 for partition layout is different between SDX75 and SDX65
Yes, I can see that.
ubi fibo_190_dump_cut.bin
0000 RRXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX sbl
0001 RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0002 RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0003 RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0004 RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0005 RXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RXXXXXXXX...--------------------
0006 -------------------------------- --------------------------------
0007 -------------------------------- --------------------------------
0008 -------------------------------- --------------------------------
0009 -------------------------------- --------------------------------
0010 -------------------------------- --------------------------------
0011 -------------------------------- --------------------------------
0012 -------------------------------- --------------------------------
0013 -------------------------------- --------------------------------
0014 -------------------------------- --------------------------------
0015 -------------------------------- --------------------------------
0016 VV.C---------------------------- -------------------------------- mibib
0017 -------------------------------- --------------------------------
0018 -------------------------------- --------------------------------
0019 -------------------------------- --------------------------------
I got confused with the two threads.
Does the Firehose loader linked above work with this FM190W? The loader is signed with QC test. We've not seen the hash on the FM190W or whether it's without Secure Boot.
I got confused with the two threads.
Does the Firehose loader linked above work with this FM190W? The loader is signed with QC test. We've not seen the hash on the FM190W or whether it's without Secure Boot.
I got my dump using that loader in my FM190W-GL :)
You might want to add that loader to the loader repo here. What's the hash on your FM190W? The loader is: f953644308944bb8 11ca0ec2a736a17f e38509941ce7f558 60130857813c8378 e93359b70dfd874c 270dca08a53bd99f I don't know if the other hash is implicit or explicit on your device: 467f3020c4cc788d 2a27a6e097ffa7bf c24e82c2d56953d3 b45b494cdba5c242 2a947d2c81b5752b 8a2ac9eac8acdf34
You might want to add that loader to the loader repo here. What's the hash on your FM190W? The loader is: f953644308944bb8 11ca0ec2a736a17f e38509941ce7f558 60130857813c8378 e93359b70dfd874c 270dca08a53bd99f I don't know if the other hash is implicit or explicit on your device: 467f3020c4cc788d 2a27a6e097ffa7bf c24e82c2d56953d3 b45b494cdba5c242 2a947d2c81b5752b 8a2ac9eac8acdf34
How to check that info? Let me know so I will post :)
When you run an EDL client it normally prints out the HWID and hash before it loads the Firehose. That's unless your device is Sahara v3 which does not tell you anything. Normally QC SOCs have three hashes, but they are often the same.
Just run a plain edl command after going to 05c6/9008 mode.
It will either say version 3 or print out the hash.
Since going to "multiple ELFs" (like your Firehose loader) there are a total of five ELFs. The second and third are signed by real (not test) Qualcomm hashes, the fourth and fifth are signed by the OEM.
As some of this is newish and I don't own any MELF devices, I'm not sure if the QC hash is one of three, or if it's hidden in the ROM.
And we also don't know if your device has Secure Boot enabled or not.
When you run an EDL client it normally prints out the HWID and hash before it loads the Firehose. That's unless your device is Sahara v3 which does not tell you anything. Normally QC SOCs have three hashes, but they are often the same.
Just run a plain
edlcommand after going to 05c6/9008 mode. It will either say version 3 or print out the hash.Since going to "multiple ELFs" (like your Firehose loader) there are a total of five ELFs. The second and third are signed by real (not test) Qualcomm hashes, the fourth and fifth are signed by the OEM.
As some of this is newish and I don't own any MELF devices, I'm not sure if the QC hash is one of three, or if it's hidden in the ROM.
And we also don't know if your device has Secure Boot enabled or not.
Looks like a v3 device:
Keystone library is missing (optional).
Qualcomm Sahara / Firehose Client V3.62 (c) B.Kerler 2018-2025.
main - Using loader prog_firehose_sdx7x.elf ...
main - Waiting for the device
main - Device detected :)
sahara - Protocol version: 3, Version supported: 1
main - Mode detected: sahara
sahara -
Version 0x3
------------------------
Serial: 0x4436a6b7a58
sahara - Protocol version: 3, Version supported: 1
sahara - Uploading loader prog_firehose_sdx7x.elf ...
sahara - 64-Bit mode detected.
sahara - Firehose mode detected, uploading...
sahara - Loader successfully uploaded.
Slaps forehead. Yeah, if it's using MELFs it has to be v3.
Here's a zipped, modified loader.
I changed the spelling of a word then rehashed.
So the hashing is good, but the signing is bad.
If you can load this and do something simple like edl printgpt that will show you that it's not Secure Boot.
Slaps forehead. Yeah, if it's using MELFs it has to be v3.
Here's a zipped, modified loader. I changed the spelling of a word then rehashed. So the hashing is good, but the signing is bad. If you can load this and do something simple like
edl printgptthat will show you that it's not Secure Boot.
it's not fused, boot also with your hacked loader:
➜ Fibocom_190 edl printgpt --loader=hack_firehose_sdx7x.elf --memory=NAND
Keystone library is missing (optional).
Qualcomm Sahara / Firehose Client V3.62 (c) B.Kerler 2018-2025.
main - Using loader hack_firehose_sdx7x.elf ...
main - Waiting for the device
main - Device detected :)
sahara - Protocol version: 3, Version supported: 1
main - Mode detected: sahara
sahara -
Version 0x3
------------------------
Serial: 0x4436a6b7a58
sahara - Protocol version: 3, Version supported: 1
sahara - Uploading loader hack_firehose_sdx7x.elf ...
sahara - 64-Bit mode detected.
sahara - Firehose mode detected, uploading...
sahara - Loader successfully uploaded.
main - Trying to connect to firehose loader ...
firehose - INFO: Binary build date: Jul 3 2024 @ 10:32:22
firehose - INFO: Binary build date: Jul 3 2024 @ 10:32:22
firehose - INFO: Chip serial num (0x6a6b7a58) Chip ID (0x443)
firehose - INFO: Supported Functions (15):
firehose - INFO: program
firehose - INFO: read
firehose - INFO: nop
firehose - INFO: patch
firehose - INFO: configure
firehose - INFO: setbootablestoragedrive
firehose - INFO: erase
firehose - INFO: power
firehose - INFO: firmwarewrite
firehose - INFO: getstorageinfo
firehose - INFO: benchmark
firehose - INFO: emmc
firehose - INFO: ufs
firehose - INFO: fixgpt
firehose - INFO: getsha256digest
firehose - INFO: End of supported functions 15
firehose
firehose - [LIB]: Couldn't detect MaxPayloadSizeFromTargetinBytes
firehose
firehose - [LIB]: Couldn't detect TargetName
firehose - TargetName=Unknown
firehose - MemoryName=nand
firehose - Version=1
firehose - Trying to read first storage sector...
firehose - Running configure...
firehose - Storage report:
firehose - total_blocks:4096
firehose - block_size:262144
firehose - page_size:4096
firehose - num_physical:1
firehose - manufacturer_id:173
firehose - serial_num:163
firehose - fw_version:
firehose - mem_type:NAND
firehose - prod_name:
firehose_client - Supported functions:
-----------------
program,read,nop,patch,configure,setbootablestoragedrive,erase,power,firmwarewrite,getstorageinfo,benchmark,emmc,ufs,fixgpt,getsha256digest
firehose - Nand storage detected.
firehose - Scanning for partition table ...
Progress: |██████████| 100.0% Scanning (Sector 0x400 of 0x400, ) 0.00 MB/s
Progress: |██████████| 100.0% Scanning (Sector 0x400 of 0x400, ) 0.00 MB/s
firehose - Found partition table at sector 1024 :)
Parsing Lun 0:
Name Offset Length Attr Flash
-------------------------------------------------------------
sbl 00000000 00400000 0xff/0x1/0x0 0
mibib 00400000 00280000 0xff/0x1/0xff 0
efs2 00680000 00B00000 0xff/0x1/0xff 0
tz 01180000 00480000 0xff/0x1/0x0 0
tz_devcfg 01600000 00100000 0xff/0x1/0x0 0
cmnlib64 01700000 00180000 0xff/0x1/0x0 0
keymaster 01880000 00100000 0xff/0x1/0x0 0
ddr 01980000 00080000 0xff/0x1/0xff 0
ddr_debug 01A00000 00180000 0xff/0x1/0xff 0
apdp 01B80000 00100000 0xff/0x1/0x0 0
xbl_config 01C80000 00180000 0xff/0x1/0x0 0
xbl_ramdump 01E00000 00200000 0xff/0x1/0x0 0
multi_oem 02000000 00100000 0xff/0x1/0x0 0
multi_qti 02100000 00100000 0xff/0x1/0x0 0
cdt 02200000 00100000 0xff/0x1/0x0 0
aop 02300000 00100000 0xff/0x1/0x0 0
aop_devcfg 02400000 00100000 0xff/0x1/0x0 0
qhee 02500000 00200000 0xff/0x1/0x0 0
abl 02700000 00100000 0xff/0x1/0x0 0
uefi 02800000 004C0000 0xff/0x1/0x0 0
loader_sti 02CC0000 00180000 0xff/0x1/0x0 0
boot 02E40000 03300000 0xff/0x1/0x0 0
scrub 06140000 04680000 0xff/0x1/0x0 0
misc 0A7C0000 001C0000 0xff/0x1/0x0 0
devinfo 0A980000 00180000 0xff/0x1/0x0 0
fota 0AB00000 001C0000 0xff/0x1/0x0 0
sec 0ACC0000 00100000 0xff/0x1/0x0 0
ipa_fw 0ADC0000 00100000 0xff/0x1/0x0 0
qupfw 0AEC0000 00100000 0xff/0x1/0x0 0
shrm 0AFC0000 00100000 0xff/0x1/0x0 0
cpucpfw 0B0C0000 00100000 0xff/0x1/0x0 0
usb_qti 0B1C0000 00100000 0xff/0x1/0x0 0
efs2bak 0B2C0000 00500000 0xff/0xff/0x0 0
rfnvbak 0B7C0000 00480000 0xff/0x1/0x0 0
fibonv 0BC40000 01500000 0xff/0x1/0x0 0
fibonvbak 0D140000 01500000 0xff/0x1/0x0 0
oeminfo 0E640000 00240000 0xff/0x1/0x0 0
oemconfig 0E880000 00440000 0xff/0x1/0x0 0
custconfig 0ECC0000 00B00000 0xff/0x1/0x0 0
oemlogs 0F7C0000 00300000 0xff/0x1/0x0 0
systemdata 0FAC0000 01F00000 0xff/0x1/0x0 0
modem 119C0000 07840000 0xff/0x1/0x0 0
recovery 19200000 03300000 0xff/0x1/0x0 0
recoveryfs 1C500000 03D00000 0xff/0x1/0x0 0
system 20200000 09800000 0xff/0x1/0x0 0
userdata 29A00000 16600000 0xff/0x1/0x0 0
Well, that's convenient. It means that you can patch abl (or anything else) if you want.
Does this thing have a UART console too? Why were you looking for a dump?
Well, that's convenient. It means that you can patch abl (or anything else) if you want.
Does this thing have a UART console too? Why were you looking for a dump?
Are you asking to me?
That’s to have a backup (that needs to be reworked in case of restore, I known) and swap firmware with Quectel RM551. These modules can swap firmware, and the RM551s firmware has better band aggregation and custom WebUI :)
@stich86 could you share your experience? I also need to flash a fm190w-gl with quectel firmware, but I need to make a working full dump in case to restore. thanks in advance
@stich86 could you share your experience? I also need to flash a fm190w-gl with quectel firmware, but I need to make a working full dump in case to restore. thanks in advance
As I have said, full dump cannot be restore as is, you have lots of 0xEE using that firehose, so partitions needs to be cleaned (cut the 0xEE where possible) and hopes that it works. So currently an edl backup isn't a safe way. May be you can ask Fibocom if they give you the firmware to restore.
I asked fibocom, they didn't aswer even for the website registration... thanks for sharing
As I have said, full dump cannot be restore as is, you have lots of
0xEEusing that firehose, so partitions needs to be cleaned (cut the0xEEwhere possible) and hopes that it works. So currently an edl backup isn't a safe way.
Mmm... I don't have any NANDs devices with me now, but I do have some backups and they don't have any EEEEEEEEs. I don't remember if I've done full restores, but I've definitely patched whole EBs.
As I have said, full dump cannot be restore as is, you have lots of
0xEEusing that firehose, so partitions needs to be cleaned (cut the0xEEwhere possible) and hopes that it works. So currently an edl backup isn't a safe way.Mmm... I don't have any NANDs devices with me now, but I do have some backups and they don't have any EEEEEEEEs. I don't remember if I've done full restores, but I've definitely patched whole EBs.
lots of firehose in the wild make dumps with 0xEE where are no written blocks. On my experience on ZTE devices, clean up the partition until the last 0xFF makes a sufficent way to restore a working dump on the unit. There are also some firehose loaders that write dump empty\badblock as 0xFF instead of 0xEE but it's a lottery :D
Even writing FFs will screw up the device as it will flash the "spare" bits. With FFs (ok, EEs if you like) you need to not write that page.
Even writing FFs will screw up the device as it will flash the "spare" bits. With FFs (ok, EEs if you like) you need to not write that page.
that's what i've said (sorry for the misunderstanding). Normally when I repack a partition, i'll go to the last "good" bit and cut from the all 0xEE (not replacing with 0xFF). I'll erase the partition and write the new contect without those bytes, and it works.
I know that's not an elegant solution, but only way if you don't have firmware from vendors (like ZTE is doing most of the time..)
Well, then here's half your problem solved. This Firehose loader should read empties as FFs. Please give it a shot.
Well, then here's half your problem solved. This Firehose loader should read empties as FFs. Please give it a shot.
oh nice, now it dumps with 0xFF instead of 0xEE, what have you changed? I'm curious :)
Mmm, just figure out which ELF is actually for Firehose, disassemble it and figure out which instruction to patch.