The FFU is just the lock and key of the data though, isn't it? Maybe the programming of the xml and flashprogrammer would be simpler? Thoughts...?
Create rawprogram0.xml from FFU file and extract partition as raw file
- Thread starter TristanLeBoss
- Start date
The FFU is just the lock and key of the data though, isn't it? Maybe the programming of the xml and flashprogrammer would be simpler? Thoughts...?
I'm also done identifying each partition:
Code:
"SBL1" is a SBL (Secondary Boot Loader) file with a 80 bytes header
Codeword[4]: d1dc4b84
Magic[4]: 3410d773
Image ID[4]: 15000000 (SBL1_IMG)
Reserved 1[4]: ffffffff
Reserved 2[4]: ffffffff
Image source[4]: 50000000
Image destination pointer[4]: 00c000f8
Image size[4]: f8480400
Code size[4]: f8480400
Signature pointer[4]: f80805f8
Signature size[4]: 00000000
Certificate chain pointer[4]: f80805f8
Certificate chain size[4]: 00000000
OEM root certificate selelected[4]: 01000000
OEM number of root certificates[4]: 01000000
Reserved 5[4]: ffffffff
Reserved 6[4]: ffffffff
Reserved 7[4]: ffffffff
Reserved 8[4]: ffffffff
Reserved 9[4]: ffffffff
"UEFI_BS_NV" is an empty partition
"UEFI_RT_NV" is an empty partition
"UEFI" is an ARM binary file with a 40 bytes header
Image ID[4]: 05000000 (APPSBL_IMG)
Flash partition version[4]: 03000000
Image source[4]: 00000000
Image destination pointer[4]: 00002000
Image size[4]: 00800d00
Code size[4]: 00800d00
Signature pointer[4]: 00802d00
Signature size[4]: 00000000
Certificate chain pointer[4]: 00802d00
Certificate chain size[4]: 00000000
"PADDING0" is an empty partition
"DPP" is a FAT partition
"DBI" is an ARM binary file with a 40 bytes header
Image ID[4]: 1e000000
Flash partition version[4]: 03000000
Image source[4]: 00000000
Image destination pointer[4]: 000080fe
Image size[4]: 982d0000
Code size[4]: 982d0000
Signature pointer[4]: 982d80fe
Signature size[4]: 00000000
Certificate chain pointer[4]: 982d80fe
Certificate chain size[4]: 00000000
"RPM" is an ARM ELF (Executable and Linkable Format) file
Magic[16]: 7f454c46010101000000000000000000
Type[2]: 0200 (ET_EXEC [Executable file])
Machine[2]: 2800 (EM_ARM [Advanced RISC Machines ARM])
Version[4]: 01000000
Entry point address[4]: 91001000
Start of program headers[4]: 34000000
Start of section headers[4]: 00000000
Flags[4]: 02000005
Size of this header[2]: 3400
Size of program headers[2]: 2000
Number of program headers[2]: 0400
Size of section headers[2]: 2800
Number of section headers[2]: 0000
Section header string table index[2]: 0000
"TZ" is an ARM ELF (Executable and Linkable Format) file
Magic[16]: 7f454c46010101000000000000000000
Type[2]: 0200 (ET_EXEC [Executable file])
Machine[2]: 2800 (EM_ARM [Advanced RISC Machines ARM])
Version[4]: 01000000
Entry point address[4]: 000081fe
Start of program headers[4]: 34000000
Start of section headers[4]: 00000000
Flags[4]: 02000005
Size of this header[2]: 3400
Size of program headers[2]: 2000
Number of program headers[2]: 1000
Size of section headers[2]: 2800
Number of section headers[2]: 0000
Section header string table index[2]: 0000
"WINSECAPP" is an ARM ELF (Executable and Linkable Format) file
Magic[16]: 7f454c46010101000000000000000000
Type[2]: 0200 (ET_EXEC [Executable file])
Machine[2]: 2800 (EM_ARM [Advanced RISC Machines ARM])
Version[4]: 01000000
Entry point address[4]: 0090fe07
Start of program headers[4]: 34000000
Start of section headers[4]: 00000000
Flags[4]: 02000005
Size of this header[2]: 3400
Size of program headers[2]: 2000
Number of program headers[2]: 0400
Size of section headers[2]: 2800
Number of section headers[2]: 0000
Section header string table index[2]: 0000
"TZAPPS" is a FAT partition
"BACKUP_TZAPPS" is an empty partition
"MODEM_FS2" is an empty partition
"MODEM_FSC" is an empty partition
"PLAT" is a FAT partition
"EFIESP" is a FAT partition
"MMOS" is a FAT partition
"MainOS" is a NTFS partition
-> Boot sector backup at offset 2566913536 match the boot sector from sector 0
"Data" is a NTFS partition
-> Boot sector backup at offset 7899971072 match the boot sector from sector 0
Last edited:
Yes, the FFU is just one type of container (TOT is another one). But we can of course create a GPT + BIN files to flash with a rawprogram0.xml. or fastboot...
Actually, it depends on how we can flash something on the Nexus 5x...
Does the below have any meaning to you. It looks like it is not reading my sbl version. Which is not good still. I blanked out two of the fields for my own good...
The good thing is is that the board is readable.
Code:
C:\Users\nate0\Documents\platform-tools\Windows\Flash\test\windows>emmcdl.exe -p COM1 -info
Version 2.15
SerialNumber: -
MSM_HW_ID: 0x009690e1
OEM_PK_HASH: -
SBL SW Version: 0x00000000
Status: 0 The operation completed successfully.The good thing is is that the board is readable.
Can you try these commands:
Code:
emmcdl -p COM1 -gptDump the GPT from the connected device so we can check if the GPT is intact and has not been damaged.
Code:
emmcdl -p COM1 -f prog_emmc_firehose_8994_lite.mbn -d SBL1 -o SBL1_from_Phone.binDump the SBL1 partition from the connected device so we can check if the SBL1 partition is intact and has been written correctly. This way we can check if the flash programmer you used works.
Last edited:
I am realizing now what events took place now. I never was able to write over or erase the sbl1 from emmcdl in Emergency mode even though I could put the phone in edl mode from fastboot, I actually pushed the SDL1.bin from fastboot. Then tried to push other images to the other partitions manually. It was kinda late at night so I did not remember at first. Then when the phone got stuck in EDL mode I attempted to use the 3 or 4 different flash programmers to send the sdl1 back or do other functions. None have succeeded. All fail and I believe since the programmer is not the correct one needed. Any command I run with the current programmers does not succeed. See below as all give same or similar output. They try to run but the phone ends up timing out or disconnecting, because I have to reconnect it to the cable or reboot it to get it to respond normally again
GPT Check:
C:\Users\nate0\Documents\platform-tools\Windows\Flash\test\windows>emmcdl -p COM1 -gpt
Version 2.15
Finding all devices in emergency download mode...
Qualcomm HS-USB QDLoader 9008 (COM1)
Finding all disks on computer ...
0. \\.\PhysicalDrive0 Size: 305245MB, (625142448 sectors), size: 512 Mount:C:, Name:[]
\\.\PhysicalDrive1
No valid GPT found
Status: 13 The data is invalid.
Attempt Dump of GPT:
C:\Users\nate0\Documents\platform-tools\Windows\Flash\test\windows>emmcdl -p COM1 -f prog_emmc_firehose_8994_lite.mbn -d SBL1 -o SBL1_from_Phone.bin
Version 2.15
Downloading flash programmer: prog_emmc_firehose_8994_lite.mbn
Successfully open flash programmer to write: prog_emmc_firehose_8994_lite.mbn
Waiting for flash programmer to boot
Dumping data to file SBL1_from_Phone.bin
Dumping at start sector: 0 for sectors: 0 to file: SBL1_from_Phone.bin
Programming device using SECTOR_SIZE=512
<?xml version = "1.0" ?><data><configure MemoryName="emmc" ZLPAwareHost="1" SkipStorageInit="0" SkipWrite="0" MaxPayloadSizeToTargetInBytes="1048576"/></data>
ERROR: No response to configure packet
Status: 21 The device is not ready.
The GPT is invalid. I did not notice this before, so I changed the port number and see it now as physical drive41:
C:\Users\nate0\Desktop\8675_W00\8675_W00>emmcdl -p COM41 -gpt
Version 2.15
Finding all devices in emergency download mode...
Qualcomm HS-USB QDLoader 9008 (COM41)
Finding all disks on computer ...
0. \\.\PhysicalDrive0 Size: 305245MB, (625142448 sectors), size: 512 Mount:C:, Name:[]
\\.\PhysicalDrive41
No valid GPT found
Status: 13 The data is invalid.
Last edited:
Can you try this tool and see if the "Restore/Upgrade/Download" option works?
http://www.wugfresh.com/nrt/
To be sure the programmer doesn't work, you can try to use these tools (and especially QFIL from Qualcomm; the method #2):
https://boycracked.com/2015/06/03/unbrick-lenovo-a6000/
Indeed, they both use a flash programmer and a rawprogram0.xml + BIN files. I think if the flash programmers you have don't work, QFIL (the official tool from Qualcomm) should somehow complain.
Can you also try this:
http://xdaforums.com/nexus-5x/general/lg-nexus-5x-download-mode-t3237490
Last edited:
Ok, I created a rawprogram0.xml using the TOT file and the files from the bootloader.img (part of the Google packages).
Unzip and put the TOT file (LGH791AT-00-V10f-NXS-XXX-OCT-03-2015-32G-MDA89E-US.tot) from the other thread in the same folder.
There is also a simpler version which only uses files from the bootloader.img: I think it's best to start with this one as - if it works - it should restore the boot.
Unzip and put the TOT file (LGH791AT-00-V10f-NXS-XXX-OCT-03-2015-32G-MDA89E-US.tot) from the other thread in the same folder.
There is also a simpler version which only uses files from the bootloader.img: I think it's best to start with this one as - if it works - it should restore the boot.
Taking a look...
Any specific way to flash? Pulling my hair out trying different flashers, some give different errors at times, but honestly the phone seems to time out time to time and I have to reset it holding the power button in for like 15 sec.
Yes, the 2 methods from this page: https://boycracked.com/2015/06/03/unbrick-lenovo-a6000/
QFIL will give you a log file (Right click in the "Status" part of the window and "Save log"), post them here.
Here is a ZIP file with 5 flashers.
Last edited:
I ran it from two computers. QFIL required a patch0.xml which I substituted the generic one from the miflash into. Both computers produced the same result. I am at work right now until tomorrow, so I will need to post the log later, but the issue it seems I am running into is the handshakes. I am inclined to believe it is either the cable USB A to C I am using (meaning I need a different serial cable), drivers, or the flash programmers are not any good for this device. Are those 5 programmers the Mi4c and two Lenovo programmers? If so I have those too. I am all guinea pig to testing at this point, but limited as to how often I can work on it. So I will post when I can. Thanks for you help TristanLeBoss.
TristanLeBoss:
There was a point during the flash process with miflash that I thought it might work. But did not. Attached are two logs. One with a first attempt and using an 8994 programmer downloaded from this thread that I downloaded. Second attempt log was after I had tried reinstalling drivers. I attempted many more times, with the other programmers, and would get the same result as log1 until later all attempts were resulting in log2. Could not get miflash to talk correctly to the phone after those first attempts looked like they were progressing, but kept failing. I tried a dozen times with different programmers and different two different PCs. I am not leaving out the margin for my own error, as I may have not had the phone charged well enough, or may have missed a detail somewhere, so I am still researching and looking into what I can try differently. Let me know what you make of these logs.
QFIL could not even get past the sahara initialization, so I did not spend a lot of time with it...
For now I handed the phone off to some folks that have tools to potentially get it back working. The first thing he asked after he attempted to turn on the phone and found no activity was "does the computer still recognize the phone", which it does of course, so I think there is hope that they might be able to help. Should know more info after Monday. Thanks.
There was a point during the flash process with miflash that I thought it might work. But did not. Attached are two logs. One with a first attempt and using an 8994 programmer downloaded from this thread that I downloaded. Second attempt log was after I had tried reinstalling drivers. I attempted many more times, with the other programmers, and would get the same result as log1 until later all attempts were resulting in log2. Could not get miflash to talk correctly to the phone after those first attempts looked like they were progressing, but kept failing. I tried a dozen times with different programmers and different two different PCs. I am not leaving out the margin for my own error, as I may have not had the phone charged well enough, or may have missed a detail somewhere, so I am still researching and looking into what I can try differently. Let me know what you make of these logs.
QFIL could not even get past the sahara initialization, so I did not spend a lot of time with it...
For now I handed the phone off to some folks that have tools to potentially get it back working. The first thing he asked after he attempted to turn on the phone and found no activity was "does the computer still recognize the phone", which it does of course, so I think there is hope that they might be able to help. Should know more info after Monday. Thanks.
The phone is soft-bricked: it fails to boot and fallback to the 9008 mode. LG/Google can easily reload the system on it because they have the needed files. But without the MPRG8992.hex and 8992_msimage.mbn files, I don't think we can to recover the phone. Maybe JTAG can come to help but "Nexus 5X JTAG" query leads to no interesting result.
The problem is that - for some reason - the GPT seems to be bad. I think it would have been easier if the GPT was still intact.
The phone is covered by a 1 year warranty by either LG or Google. Maybe, the simplest thing to do is to send it to them. Because the phone has been released in September of 2015, it's for sure still covered by the warranty.
I agree.
I actually called LG US being in the US, but since this is an International variant, they could not locate the imei in their database, oddly enough Google could not locate this imei either...they pointed me toward contacting the supplier of the phone in the country of origin. I bought it from a private party, who stated he bought it from the Google store while in Canada. My dialing options did not let me dial into Canada LG support, but I was able to chat with them. They wanted a proof of purchase from me to be able to work with me. This sounding legit to folks?
Currently I am waiting on this phone repair and will post back if they succeeded or not and then will go from there.
---------- Post added at 01:29 PM ---------- Previous post was at 01:15 PM ----------
There is a way to generate the HEX programmer file from a FFU actually but I only found this on Lumia devices using the thor2 command. But since the original image is packaged in a TOT file it does not seem that is possible here or maybe it is...Have you read this posting? Finally... unbrick your Lumia device QHSUSB_DLOAD without JTAG
Through this experience I have concluded these things:
-Windows Mobile though not popular is pretty darn secure (XDA WP Secure Boot Post)
-I am not giving up the pursuit of this, but If my Nexus device gets revived I've decided to let it be native to Android. Even though it is intriguing to think of a dual boot/alternative OS device.
-Since I continually go back and forth between Windows Mobile and Android devices I will hope that there is a chance to own a device with multiple OS support Android/Windows that is released officially in the US. Seems Microsoft is teaming up with several Chinese Partners to port their OS to already existing devices.
-Windows Mobile though not popular is pretty darn secure (XDA WP Secure Boot Post)
-I am not giving up the pursuit of this, but If my Nexus device gets revived I've decided to let it be native to Android. Even though it is intriguing to think of a dual boot/alternative OS device.
-Since I continually go back and forth between Windows Mobile and Android devices I will hope that there is a chance to own a device with multiple OS support Android/Windows that is released officially in the US. Seems Microsoft is teaming up with several Chinese Partners to port their OS to already existing devices.
Indeed, experimenting with Windows 10 should be done on a phone that you can recover from soft brick. At least, we learned something about Windows Mobile 10. I shared the discoveries in another thread
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
19I was searching for the "ffutoraw.exe" file referenced in the "rawprogram0.xml" file from the Xiaomi Mi4 Windows Mobile 10 ROM when I discovered a small tool which can also do the work.
Here is the eMMC DL tool v2.15 from Qualcomm. This tool is publicly available. It's part of the "DragonBoard Update Tool" (dragonboardupdatetool_x64.zip or dragonboardupdatetool_x86.zip) available on this webpage: https://developer.qualcomm.com/hardware/dragonboard-410c/tools Once installed, you will find the file in "C:\Program Files (x86)\Qualcomm\DragonBoardUpdateTool".
This small EXE actually has 3 useful functions regarding FFU file:
- "Create rawprogram0.xml for a FFU file; need -o"
- szOutputFile = rawprogram0.xml
- "-splitffu szFFUFile -o szOutputFile"
- "Split FFU file into partition binary chunks; need -o"
- szPartName = partition name or "all" to extract all partitions
- szOutputFile = destination folder for bin files
- "-dumpffu szFFUFile szPartName -o szOutputFile"
- "Download FFU file to device in emergency download; need -o and -p"
- "-ffu szFFUFile"
(I tried the rawprogram0.xml creation with the Xiaomi Mi4 Windows Mobile 10 ROM and the produced file was exactly the same as the one included in the ZIP file.)
Launching the EXE from the command line will echo an help screen:
1Oh, I forgot to add that - to my knowledge - this tool doesn't implement the image integrity validation (signature check [embedded catalog] and hash check [embedded hash table]).
Would be interesting to find out what happen if the stock 950 FFU file is flashed as-is to a Nexus phone...
There is 3 problems I can think about:
- UEFI: the phone may need to have a Microsoft key in its "db" store to authenticate the Windows Mobile bootloader.
- Partitions: does the layout need to be exactly the same as the Android version?
- Drivers: even if the SoC is the same, they may be some tweaks...1
I'm going to look into this further. Thank you. What's stopping us from using a Lumia ffu for an identical soc and storage size of another device? I've been contemplating this and since all the drivers and cabs are signed already might be possible. Also with your script what's stopping you from signing those files yourself and making a test build image?
---------- Post added at 07:52 PM ---------- Previous post was at 07:44 PM ----------
Good points. Much deeper than I was thinking but along the same lines. I would think the partitioning needs to be identical the 950 rom since that's how it was built. But it might not matter since ffus blank the entire storage in the process of flashing you can technically partition it however you want but then your building that configuration from scratch. How difficult is it to dump the partitioning of a 6p? I'm still looking but that's the next best candidate being unlockadble in seeing if this is feasible. Sorry for any typos,sending these last two from my phone.1
I attached the one I have but don't know if it's the one to use for this phone.1Ok, I created a rawprogram0.xml using the TOT file and the files from the bootloader.img (part of the Google packages).
Unzip and put the TOT file (LGH791AT-00-V10f-NXS-XXX-OCT-03-2015-32G-MDA89E-US.tot) from the other thread in the same folder.
There is also a simpler version which only uses files from the bootloader.img: I think it's best to start with this one as - if it works - it should restore the boot.
New posts
-
Development [ROM][13][OFFICIAL] PixelOS [AOSP][STABLE][06/07/2023]- Latest: fersouza777
-
[Hisense a9] Root - Reward Offered (Snapdragon 662)- Latest: idonotbelonghere
-
