Database Develop

[HW][OT] E:V:A's Discussion Thread

This is my own completely Off Topic Discussion thread.
A place where I will bring HW related discussions, that do not fit into
specific threads or discussions.
Please, do not post here with general questions or other junk that I have not initiated myself.
Also do not ask where to find files/programs mentioned in this thread, because if I have not linked to them, I don't know!
They will be removed. (Thanks for understanding.)
See you.

<< Better reserve for more dragons >>

Didn't see that anyone mentioned it and I'm not sure if the S4 modems are as well, but the initial container that the modems are in on the HTC used S3 chips is a fat16 format. I saw that with a simple hex editor showed it and I was able to see the modem file structure as well. I'll snag a few S4 modems later today and take a look. Couldn't unpack and repackaged though, which is probably the EFS formatting with it.

Off topic goes in off topic

Sorry it took so long
I had intended to do this at least a week ago, but had not the chance. Both the S3 HTC Radios and the S4 HTC Radios are fat 16 imgs.
As you see in the Rezound screenshot, in the first few lines of the HEX table in the bottom left mentions no volume label and a fat 16 label on the type. in addition when I use IMG viewers it shows the same with both the MDM9K image and the main IMG. This should theoretically enable us to possibly use amss imgs or other parts of the radios with other devices or even cross the modem over to other Samsung devices with the same modem chips.
In addition as per the Ville screenshot, this is the One S modem for one of the European basebands. Again the HEX shows Fat 16 as the file type, but the file structure and amount of files are much more plentiful. If this can become of any use, great. If not, oh well... but it is good food for thought either way.
On other notes, I did try to copy files from the LTE baseband (MDM9k) from the Vivid and move them to the MDM9k IMG for the rezound, but the IMG bloated. I haven't had enough time to try and mount the images in my Ubuntu environment, but doing it in Winblows caused the IMG to bloat up too much and caused radio issues and IMEI unknown blanks.
Happy perusing and happy hunting!

Very nice, but I doubt you'll be able to mix modem files (between different devices) unless you're absolutely sure that the device modem and AP HW is the same. Apparently from another recent conversation, it seem that HTC and Qualcomm are both moving to unified source code for their devices. So it can still be true that many of those files are the same across devices.
Could you write a few lines on how you go about this extraction and do it for the HTC One X (LTE)?
Also don't forget that US HTC One X (or S, or whatever) is not the same hardware and the European one!
On second thought, I think this is what you got..right?

Pretty much. Seems like another situation where I should have spoke up when I first saw it with Qualcomm S3 modems in May. On moving files though, I was planning to stay in family. S3 w/ S3 ect.

^^ BTW. Could you tell if there are any structural differences (content wise) between files of same prefix, but sequential postfix? What is strange is that they are all very different sizes, which indicate they probably have very different content...
If it was just one solid piece of firmware, it would just have been chopped up into equal sized pieces...

I'll look closer on that. I do remember that most of the sequential pieces were the same size minus either the first or the last, holding with your theory.

Maybe not the right place, but have you looked at the pit files?
COM_TAR2MSM8960
MODEM non-tlos.bin
sbl1.mbm
sbl2.mbm
sbl3.mbm
aboot.mbm
rpm.mbm
BOOT boot.img
TZ
PAD
PARAM
EFS efs.img (ext4)
MODEMST1 nvrebuild1.bin
MODEMST2 nvrebuild2.bin
system.img (ext4)
userdata.img (ext4)
persist.img (ext4)
cache.img (ext4)
recovery.img (ext4)
FOTA
BACKUP
FSG
SSD
GROW
PGPT pgpt.img
PIT MSM8960.pit
MD5 md5.img
SGPT sgpt.img
I know it is not really new, but I hadn't seen the img names.

The ones I took screenshots of were for 3rd and 4th Gen Snapdragon processors, radio.imgs for HTC devices. The Samsung pit files may give good cross references though. I'll re-unbox my Amaze this evening and check the mounts to see any information on the single file broken into pieces theory.

"eMMC Partition tools usage for msm7x30/msm8x60"
(A repost from Anyclub...)
In the eMMC boot, there are some changes in eMMC partitioning.
Code:
[SIZE=2]partition.xml - Everything begins with this file, which describes the number of
partitions desired, and how many sectors each one should be.
PartitioningTool.py - translates partition.xml into binary partitions
msp.exe - writes binary partitions to SD/eMMC cards using card reader
mjsdload.cmm - writes binary partitions to SD/eMMC cards using Trace32
msp.py - writes binary partitions to a single image file
QPST - writes binary partitions to SD/eMMC cards on Target
[/SIZE]
Helper /Debug Tools:
Code:
[SIZE=2]parseBinaryPartitionFile.pl - Decodes MBR partition tables. Run:
"Perl parseBinaryPartitionFile.pl partition.bin"
to generate the partition information
parseGPT.pl - Decodes GPT partition tables
[/SIZE]
partition.xml
These are the property entries that can be added in new partiton.xml to specify the configuration.
Code:
[SIZE=2]<parser_instructions>
WRITE_PROTECT_BOUNDARY_IN_KB = 0
GROW_LAST_PARTITION_TO_FILL_DISK = false
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY = false
</parser_instructions>[/SIZE]
WRITE_PROTECT_BOUNDARY_IN_KB: Typical boundaries are 64MB, i.e. 65536 KB. This
means that a 256MB eMMC card has 4 write protect boundaries. Any or all of
them can be marked as read-only. Different vendors allow for different sized
boundaries.
GROW_LAST_PARTITION_TO_FILL_DISK: In partition.xml the size of each partition
is specified. If this field is TRUE, then the last partition size is ignored
and set to 0. Then during patching this size is updated such that the last
partition extends to use all remaining space.
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY: To allow total flexibility, it
could be that a partition that is currently writeable might need to be marked
as read-only. This can only happen *if* that partition begins on a write
protect boundary (i.e. 64MB). Thus if this field is TRUE, then all logical
partitions are positioned such that they begin on a write protect boundary.
PartitioningTool.py
Is a new tool used to generate the the partition.xml
When run, it will output following 5 files:
1. emmc_lock_regions.xml
This hold the sector ranges that need to be marked as read-only by the
operating system (this is from readonly="true" in partition.xml) i.e. modem
code and boot images are typically on read-only partitions Typical
Write-Protect boundary is 64MB = 131072 sectors = 0x20000 sectors. The file
below is protecting the very first 64MB region of the card,
Boundary #0
Starting at sector 0
Ending at sector 131071 (for a total of 131072 sectors)
Code:
[SIZE=2]<?xml version="1.0" ?>
<protect>
<!-- NOTE: This is an ** Autogenerated file ** -->
<!-- NOTE: Sector size is 512bytes, WRITE_PROTECT_BOUNDARY_IN_KB=0, WRITE_PROTECT_BOUNDARY_IN_SECTORS=0 -->
<!-- NOTE: "num_sectors" in HEX "start_sector" in HEX, i.e. 10 really equals 16 !! -->
<program boundary_num="0" num_boundaries_covered="1"
num_sectors="20000" num_sectors_dec="131072" physical_partition_number="0"
start_sector="0" start_sector_dec="0"/>
<information WRITE_PROTECT_BOUNDARY_IN_KB="0"/>
</protect>
[/SIZE]
2. partition0.bin
This holds the partition tables, i.e. MBR followed by all EBRs. This is the
partition table in binary format. It is copied over to the storage device in a
1 to 1 manner. I.e. how it looks in partition0.bin is exactly how the
partition table will look on the storage device. partition0.bin is a "generic"
file meant to fit on *any* size SD/eMMC card, as a result, there are 0's that
need to be patched,such as EXT partition and last partition size.
3. patch0.xml
Contain the patching instructions to tailor each partition table
"partition0.bin" to a specific SD/eMMC card. I.e. the partition0.bin
partition tables can be applied to any size storage device As a result,
there are empty values (zeros) in the partition tables that must be filled
in with a specific cards sector size
There are two ways to apply this patch:
a) (patch before) When you patch the "zeros" in the partition tables held in the file partition0.bin, and then write it to the card
b) (patch after) When you write partition0.bin to the card (which still has "zeros" in it), and then patch the cards partition tables directly
4. rawprogram0.xml
precise sector details of all partitions and what files (if any) need to
be placed there. In addition to writing partition tables onto a device,
often times it is desired to write one or more files into the partition
area as well, The File has partition name (i.e. label), where it begins
(start_sector) and how big it is (num_partition_sectors). It also
describes what file(s) to write to this partition, as well as any
offsets.
Example:
Code:
[SIZE=2]<program file_sector_offset="0" filename="partition0.bin" label="MBR"
num_partition_sectors="1" physical_partition_number="0"
size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin " label="EXT"
num_partition_sectors="2" physical_partition_number="0"
size_in_KB="1.0" start_sector="779"/>
[/SIZE]
The 1st line describes taking the 1st sector from partition0.bin, and writing it to sector 0 of the card.
The 2nd line describes taking the 2nd and 3rd sector from partition0.bin and writing it to sector 779 of the card.
I.e. file_sector_offset = 2 and num_partition_sectors=2
5. loadpt.cmm
This is used by the mjsdload.cmm to flash the image.
msp.exe
This is used to apply the patches
This program will program a memory card (SD/eMMC) attached to the PC as USB mass storage device
Use -d to detect the path of the memory card if you are unsure what to do first
Commands list:
Code:
[SIZE=2]-h (Print this help message) Ex. msp -h
-d (Detect which storage device ID is active) Ex. msp -d
-p (Print partition information) Ex. msp -p /dev/sdb
-pp (Print partition information - DETAILED) Ex. msp -pp /dev/sdb
-x (Write files as outlined in rawprogram.xml) Ex. msp -x rawprogram.xml /dev/sdb
-xx (Write files as outlined in rawprogram.xml - DETAILED) Ex. msp -xx rawprogram.xml /dev/sdb
-s (Write SINGLE IMAGE "singleimage.bin" as outlined in rawprogram.xml) Ex. msp -s rawprogram.xml 8192
-v (Verify file written correctly as outlined in rawprogram.xml) Ex. msp -v rawprogram.xml boot.img /dev/sdb
-f (Program single file as outlined in rawprogram.xml) Ex. msp -f rawprogram.xml boot.img /dev/sdb
[/SIZE]
To program the SD/eMMC with msp.exe in mass storage mode:
Code:
[SIZE=2]STEPS Complete example (patch after)
-------------------------------------------------------------
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Program your device msp -x rawprogram0.xml /dev/sdb
Patch your device msp -xx patch0.xml /dev/sdb
STEPS Complete example (patch before)
-------------------------------------------------------------
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Patch your files msp xx patch0.xml 15758336 (patch the 8GB card offline,this will change the partition0.bin)
Program your device msp x rawprogram0.xml /dev/sdb
[/SIZE]
The msp.py program can also used to patch the files.
For example:
python msp.py patch0.xml 15758336
This will patch the 8GB card offline, and change the partition0.bin.

Qualcomm DBL format (source Anyclub)
DBL is combined by three images.
dbl.bin - the raw DBL image
dbl.hd - the dbl header image
dbl_preamble.mbn - the preamble image with following format:
Code:
[SIZE=2]+------------+
|Dbl-preamble|
+------------+
|Dbl-header |
+------------+
|Dbl.bin |
+------------+
[/SIZE]
PBL is using the dbl_preamble to detect the NAND page size. The NAND controller
can detect 512 byte and 2 Kbyte page size automatically, but for NAND page size
more than 2K, PBL needs preamble to determine the page size, so for 512/2K
NAND,eMMC,eSD,oneNAND , the preamble is optional.
For the dbl_preamable, the first two words are same as dbl header, they are
codeword and magic,
ref image_header.c
Code:
data_ptr = autodetectpage;
*data_ptr = sbl_header.codeword;
data_ptr++;
*data_ptr = sbl_header.magic;
data_ptr++;
*data_ptr = AUTODETECT_PAGE_SIZE_MAGIC_NUM;
the third one is auto page size detection magic number.
The usage of the auto detection magic number is as below description To
understand this more clearly, for example ,if the dbl_preamble is 8KB. When we
detect the NAND page size > 2KB, we will set the default page size as 2K, then
try to read the preamble image from NAND flash, in case the page size is 4KB,
when read, can get 2 magic number in 8K size because page size will increase
with 4K byte steps, so page size is detected and that is 8K/2 = 4. For the 8K
page NAND, 1 magic number is read from the 8K size preamble image, so the page
size will be 8K/1 = 8K.
Dbl_preamble layout:
Code:
[SIZE=2]+-------------------------------------------------+
| codeword|magic|autodetection_ magic|............|
2K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
4K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
6K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
8K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
+-------------------------------------------------+
[/SIZE]

E:V:A said:
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Program your device msp -x rawprogram0.xml /dev/sdb
Patch your device msp -xx patch0.xml /dev/sdb
Click to expand...
Click to collapse
Hello, where i can find these files, i have qpst but there are no such files.

So does this explain why the pit references: pgpt.img, md5.img, sgpt.img but they aren't on any partition, (they should be after GROW blk0p23)

dviguha said:
Hello, where i can find these files, i have qpst but there are no such files.
Click to expand...
Click to collapse
I think it could be part of the Qualcomm Development Acceleration Resource Toolkit (QDART), as it supersedes QPST. But I'm not sure...
joederp said:
So does this explain why the pit references: pgpt.img, md5.img, sgpt.img but they aren't on any partition, (they should be after GROW blk0p23)
Click to expand...
Click to collapse
Where do you find these references?
I don't know, so if you find out let us know.

http://forum.xda-developers.com/showthread.php?t=1848267
If you dump the pit file you can see the references if you open in hex editor. Since it defines partition locations it appears they are either after last partition.. I haven't looked into technical pit stuff.
Sent from my SGH-T999 using xda app-developers app

Photo Place Holder Post
All images that I have not yet posted goes here...

Where can i find parseBinaryPartitionFile.pl or parseGPT.pl ?

vache said:
Where can i find parseBinaryPartitionFile.pl or parseGPT.pl ?
Click to expand...
Click to collapse
You tell me!

TF701T NvFlash Unbrick Solution(tested)

TF701T NvFlash Unbrick Solution(tested)
(continue of the threadhttps://forum.xda-developers.com/showthread.php?t=2655888)
Charge tab before unbricking.
Connect tab to PC.
If your tab not started already in APX mode, then run APX mode by pressing button combination Vol+ and Power.
Insall drivers from "usb_drivers" if needed.
If there is a problem with the installation of drivers, use Google to search- how to install unsigned drivers.
When device installed correctly run "tf701t_flash.bat".
If flash process interrupts with error like ...read\write error..., then probably EMMC memory chip is damaged and need to replace.
If flash process complete, then we ready to next step.
Prepare fat32 formatted microSD card.
Download from ASUS site update package.
https://www.asus.com/us/Tablets/The_New_ASUS_Transformer_PadTF701T/HelpDesk_BIOS/
It _MUST_ be Version V10.14.1.47, SKU(region)- of your choice.
The downloaded file will look like **_epaduser_10_14_1_47_UpdateLauncher.zip
There will be another archive inside that archive.
Extract it, and rename it to t4_sdupdate.zip
Put t4_sdupdate.zip in root of microSD card.
Insert microSD card in tab, then start tab in recovery mode by pressing Vol- and Power key combination.
Follow onscreen instructions to complete recovery process.
After all you tab must be restored to factory state JB Android.
Now you may update firmware version using OTA or sdcard.
NvFlash TF701T Unbrick
http://mega.nz/#!mk8k0Y5S!TQJVfcQudH9HIMnapiGZWccV3VvygnTjDWYLxJte4lo
mirror
http://smartjtagbox.com/owncloud/index.php/s/T8DKqDuhSZzffSp

What is this? A covert ad campaign for Mega? How about hosting the file somewhere that does not force you to download an app, open an account and all that cr***? I'd be really curious to see the code, but not like this.....
Sent from my TF700T using Tapatalk

berndblb said:
What is this? A covert ad campaign for Mega? How about hosting the file somewhere that does not force you to download an app, open an account and all that cr***? I'd be really curious to see the code, but not like this.....
Click to expand...
Click to collapse
Where did you see the ad or need to register, or requirement of install the program for downloading?
Just checking in IE and FF.
I see a big red button- "download", no ads, and no requirements.
Ok, for those who have problems with mega.nz added a mirror for download.

TF701t - Hard Reset Fails ...
Dear Community,
I wanted to hard reset my TF701t to delete my data and give it to another one.
But now it stucks in "deleting data" ... that endures a minute then a dead android is on the screen.
When I want to reboot it, the hard reset comes again and want to delete everything, but the dead android is coming back :/
I can't go in Recovery Mode (Volume-down + Power)
Connection to APX works but, see pic below ...
I don't know what I could try anymore ...
Hope somebody have an idea.
Best greetings,
Symbic
Bild -> url: ibb.co/iFP5JH
{
"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"
}

Symbic said:
Dear Community,
I wanted to hard reset my TF701t to delete my data and give it to another one.
But now it stucks in "deleting data" ... that endures a minute then a dead android is on the screen.
When I want to reboot it, the hard reset comes again and want to delete everything, but the dead android is coming back :/
I can't go in Recovery Mode (Volume-down + Power)
Connection to APX works but, see pic below ...
I don't know what I could try anymore ...
Hope somebody have an idea.
Best greetings,
Symbic
Bild -> url: ibb.co/iFP5JH
Click to expand...
Click to collapse
Link to the picture is broken, so we cannot see what result you got...
What's your situation: Bootloader unlocked? Custom recovery? I guess not since you get the dead Android?

link to screenshot ok.
as i can see- problems begin after trying access to EMMC chip.
"Taking backup of EKS"
unfortunately with 90% certainty i can say that the EMMC chip damaged.

mr.bin said:
link to screenshot ok.
as i can see- problems begin after trying access to EMMC chip.
"Taking backup of EKS"
unfortunately with 90% certainty i can say that the EMMC chip damaged.
Click to expand...
Click to collapse
Can I do anything else to test the EMMC chip?

Symbic said:
Can I do anything else to test the EMMC chip?
Click to expand...
Click to collapse
In that state the EMMC chip can be tested with the special equipment like EasyJtag box.

Hello Mr Bin, registered an account just to say thank you...
You have no idea.. was helping a friend to update, but the guy who sold it(tf701) had bought it from different region and turned it to US, so we ended up hard bricking it.
Long story short, we hard bricked it.
Thank you for your hard work in making the fix, and a big THANK you for sharing it...
Perfect fix, its better than before because it got updated to .47 (we couldnt update, no OTA no manual, too old version for custom recoveries)
Again.. thanks :good::good:

Thanks.
But, after clicking to RCK, shows Android with blue procesing line and after few seconds android with open door and red triangle !. After few minutes bootloop....nothing more.
What can i doing again?

Wow! It's back!
Hi.
First of all: Thank you very much! I was sure my tablet was a goner... It is actually back. One tip I'd like to add: I had to try around a bit to get into APX mode. But essentially I just had to connect the tablet to my PC and then push "Volume up" and power at the same time - and ignore that the screen did not light up ...
Again: Thanks a lot!

Mr.Bin,
You have resurrected my TF701T! Thank you SOOOO MUCH! You are an actual genius! Thanks!

Help w installation
I have the same problems although i have not installed any custom OS but after few months of not using it didnt load up and ended in APX mode.
Tried this solution, installed the driver, started the .bat file and ended up here :
Nvflash 3.08.1704 started
Using blob 3.08.1704
chip uid from BR is: 0x600000015c3e10080c000000190301c0
rcm version 0X350001
Skipping BoardID read at miniloader level
System Information:
chip name: unknown
chip id: 0x35 major: 1 minor: 2
chip sku: 0x3
chip uid: 0x000000015c3e10080c000000190301c0
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
board id: 0
warranty fuse: 0
dk burned: true
boot device: emmc
operating mode: 6
device config strap: 0
device config fuse: 17
sdram config strap: 0
RCM communication completed
sending file: flash.bct
- 8192/8192 bytes sent
flash.bct sent successfully
BCT sent successfully
odm data: 0x82098000
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: bootloader.bin
data send failed NvError 0x120002
command failure/warning: bootloader download failed (bad data)
I would be very thankful for any information you could read from this. Just would like to know if i even have a chance of getting it back on.

So, I was running fine with CROMi-X KitKat, but wanted to upgrade to Marshmallow (to install sw not supported in KitKat), so decided to try KatKiss 6.0. It's been years since I've played with flashing ROMs, but I did a little reading to refresh my memory. Then I rebooted into recovery (ClockworkMod), backed everything up, then wiped everything, formatted /data, and tried flashing the KatKiss zip file. At that point, it just sat there forever at the ASUS logo screen:
I've tried several times to boot back into recovery by holding the Vol+ and Power buttons, but it either doesn't boot, or boots to the above screen. I've connected it to my Mac w/ the Android SDK Platform Tools, but adb doesn't see any device listed. [I've got an old Windows laptop (XP?)] I could use if it will do something the Mac can't.]
Any advice on how I can save this tablet?

This method can be apply to tft300t?

Hi! What a great thread! After lurking on this forum for many years, i've registered to expose my issue with an old tf701 that was given to me by a friend. He say me he installed esexplorer and deleted file to clean space. Next day he rebooted and never been able to boot system. Now tablet is in bootloop ending with blackscreen and backlight on. Im able to open in fastboot and talk with minimal adb and fastboot. RCK update ending with fallen robot, Wipe data/cache ending with fallen robot. APX mode also working and ive run mr.bin's Nvflash unbrick tool with this result:
Nvflash 3.08.1704 started
Using blob 3.08.1704
chip uid from BR is: 0x600000015c3e10060400000001058440
rcm version 0X350001
Skipping BoardID read at miniloader level
System Information:
chip name: unknown
chip id: 0x35 major: 1 minor: 2
chip sku: 0x3
chip uid: 0x000000015c3e10060400000001058440
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
board id: 0
warranty fuse: 0
dk burned: true
boot device: emmc
operating mode: 6
device config strap: 0
device config fuse: 17
sdram config strap: 1
RCM communication completed
sending file: flash.bct
- 8192/8192 bytes sent
flash.bct sent successfully
BCT sent successfully
odm data: 0x82098000
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: bootloader.bin
| 1463232/1463232 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
Taking backup of EKS
Receiving file: EKS_0400000001058440.bin, expected size: 4194304 bytes
/ 4194304/0 bytes received
file received successfully
Taking backup of PER
Receiving file: PER_0400000001058440.bin, expected size: 8388608 bytes
/ 8388608/0 bytes received
file received successfully
Taking backup of ABT
Receiving file: ABT_0400000001058440.bin, expected size: 4194304 bytes
/ 4194304/0 bytes received
file received successfully
Continuing create using flash.cfg
setting device: 2 3
deleting device partitions
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: DFI
creating partition: BMP
creating partition: ABT
creating partition: GP1
creating partition: SOS
creating partition: DTB
creating partition: LNX
creating partition: APP
creating partition: CAC
creating partition: APD
creating partition: ADF
creating partition: MSC
creating partition: USP
creating partition: PER
creating partition: CRA
creating partition: MDA
creating partition: EKS
creating partition: UDA
creating partition: GPT
sending file: bootloader.bin
| 1463232/1463232 bytes sent
bootloader.bin sent successfully
sending file: xusb_sil_rel_fw
- 126464/126464 bytes sent
xusb_sil_rel_fw sent successfully
sending file: ABT_0400000001058440.bin
/ 4194304/4194304 bytes sent
ABT_0400000001058440.bin sent successfully
sending file: recovery.img
\ 7272704/7272704 bytes sent
recovery.img sent successfully
sending file: boot.img
- 6760704/6760704 bytes sent
boot.img sent successfully
sending file: PER_0400000001058440.bin
/ 8388608/8388608 bytes sent
PER_0400000001058440.bin sent successfully
sending file: EKS_0400000001058440.bin
/ 4194304/4194304 bytes sent
EKS_0400000001058440.bin sent successfully
failed executing command 26 NvError 0x120002
command failure/warning: sync failed (bad data)
bootloader status: Bct Write Failed (code: 22) message: nverror:0x40005 (0x14000
5) flags: 0
Click to expand...
Click to collapse
Advise would be great help. I dont know if mmc could be dead, it showing some successful tranfert but keep failing at same place. Thanks!

Hello. These commands for nvflash make a backup and installation of the system.
REED
@cls
@nvflash.exe --blob blob.bin --bl bootloader.bin --read 9 recovery.img --read 11 boot.img --read 12 system.img
@pause
WRITE
@cls
@nvflash.exe --blob blob.bin --bl bootloader.bin --download 9 recovery.img --download 11 boot.img --download 12 system.img
@pause
Thanks mr.bin for a great tool

Important information who uses nvflash!
3 files (ABTxxxxxxxxxxxxxxxx.bin, EKS_xxxxxxxxxxxxxxxx.bin, PER_xxxxxxxxxxxxxxxx.bin, which are created after running nvflash, must be flashed again. Otherwise, it will be impossible to unlock the tablet again and the serial number will be lost. Save in a safe place and then rename the files to EKS, ABT, PER.
To do this, create a second file with the bat extension. In a text editor, type these lines
Code:
nvflash --wait --blob blob.bin --bl bootloader.bin --download 7 ABT --download 21 EKS --download 18 PER --go
If these files are saved on the unlocked tablet, then after their firmware unlocking will be restored.
Also, using nvflash, you can resize partitions, flash a bootloader with file system markup, recovery.

There is no way to load an unlocked bootloader in this process ??

[WIP]Dissecting the bootloader aka: get rid of annoying "Your device is corrupt"

[WIP]Dissecting the bootloader aka: get rid of annoying "Your device is corrupt"
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
Code:
> adb shell
# dd if=/dev/block/bootdevice/by-name/abl_b of=/sdcard/img.abl_a
# <ctrl-D>
> adb pull /sdcard/img.abl_a
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
Code:
> binwalk -e img.abl_a
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
4488 0x1188 Certificate in DER format (x509 v3), header length: 4, sequence length: 1279
5771 0x168B Certificate in DER format (x509 v3), header length: 4, sequence length: 1133
6908 0x1AFC Certificate in DER format (x509 v3), header length: 4, sequence length: 1149
12408 0x3078 LZMA compressed data, properties: 0x5D, dictionary size: 16777216 bytes, uncompressed size: 487624 bytes
I am thinking that bytes 0...4487 is the real bootloader code, so:
Code:
> head --bytes=4488 img.abl_b > abc
> file abc
abc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, corrupted section header size
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
Code:
> readelf abc
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x9fa00000
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NULL 0x000000 0x00000000 0x00000000 0x00094 0x00000 0
NULL 0x001000 0x9fa30000 0x9fa30000 0x01988 0x02000 0x1000
LOAD 0x003000 0x9fa00000 0x9fa00000 0x30000 0x30000 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
Elf file type is EXEC (Executable file)
Entry point 0x9fa00000
There are 3 program headers, starting at offset 52
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...

foobar66 said:
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
I am thinking that bytes 0...4487 is the real bootloader code, so:
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...
Click to expand...
Click to collapse
Wow! Excited to see this! Thanks

It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.

foobar66 said:
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
Code:
> adb shell
# dd if=/dev/block/bootdevice/by-name/abl_b of=/sdcard/img.abl_a
# <ctrl-D>
> adb pull /sdcard/img.abl_a
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
Code:
> binwalk -e img.abl_a
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
4488 0x1188 Certificate in DER format (x509 v3), header length: 4, sequence length: 1279
5771 0x168B Certificate in DER format (x509 v3), header length: 4, sequence length: 1133
6908 0x1AFC Certificate in DER format (x509 v3), header length: 4, sequence length: 1149
12408 0x3078 LZMA compressed data, properties: 0x5D, dictionary size: 16777216 bytes, uncompressed size: 487624 bytes
I am thinking that bytes 0...4487 is the real bootloader code, so:
Code:
> head --bytes=4488 img.abl_b > abc
> file abc
abc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, corrupted section header size
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
Code:
> readelf abc
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x9fa00000
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NULL 0x000000 0x00000000 0x00000000 0x00094 0x00000 0
NULL 0x001000 0x9fa30000 0x9fa30000 0x01988 0x02000 0x1000
LOAD 0x003000 0x9fa00000 0x9fa00000 0x30000 0x30000 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
Elf file type is EXEC (Executable file)
Entry point 0x9fa00000
There are 3 program headers, starting at offset 52
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...
Click to expand...
Click to collapse
Good job, if needed i can help with the checking

tech_head said:
It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.
Click to expand...
Click to collapse
abl.img is not the bootloader i guess.

tech_head said:
It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.
Click to expand...
Click to collapse
On other devices they've been able to swap this image with another one to "hide" the message, to "get rid of it".

Would we sweet if we could get rid of the unlocked bootloader message too.

dennisbednarz said:
Would we sweet if we could get rid of the unlocked bootloader message too.
Click to expand...
Click to collapse
+1

U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool

jacksummers said:
U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool
Click to expand...
Click to collapse
Different issue.
They are not trying to get rid of the red warning but the yellow warning for an unlocked BL.
On this phone, if you have a "red" warning you use the MSMDownload tool and go back factory including locking the BL.
This is a different case.

Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
Code:
> lsusb
Bus 001 Device 034: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
And then:
Code:
> dmesg
[ 9395.999112] usb 1-1: new high-speed USB device number 34 using xhci_hcd
[ 9396.149376] usb 1-1: New USB device found, idVendor=05c6, idProduct=9008
[ 9396.149380] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9396.149383] usb 1-1: Product: QUSB_BULK_CID:0402_SN:33B9DDAC
[ 9396.149386] usb 1-1: Manufacturer: Qualcomm CDMA Technologies MSM
[ 9396.150184] qcserial 1-1:1.0: Qualcomm USB modem converter detected
[ 9396.150372] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB0
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...

foobar66 said:
Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
Code:
> lsusb
Bus 001 Device 034: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
And then:
Code:
> dmesg
[ 9395.999112] usb 1-1: new high-speed USB device number 34 using xhci_hcd
[ 9396.149376] usb 1-1: New USB device found, idVendor=05c6, idProduct=9008
[ 9396.149380] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9396.149383] usb 1-1: Product: QUSB_BULK_CID:0402_SN:33B9DDAC
[ 9396.149386] usb 1-1: Manufacturer: Qualcomm CDMA Technologies MSM
[ 9396.150184] qcserial 1-1:1.0: Qualcomm USB modem converter detected
[ 9396.150372] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB0
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...
Click to expand...
Click to collapse
Use this https://forum.xda-developers.com/oneplus-6t/how-to/tool-6t-msmdownloadtool-v4-0-oos-9-0-5-t3867448
Should try for several times with instruction here

Question - when does device show red warning? When u disable dm verity?
I unlocked and rooted but only had yellow warning, but when i installed aosp gsi i had a red warning. Once of the step to install the rom was flashing vbmeta and disabling dm verity.

patelparth120595 said:
Question - when does device show red warning? When u disable dm verity?
I unlocked and rooted but only had yellow warning, but when i installed aosp gsi i had a red warning. Once of the step to install the rom was flashing vbmeta and disabling dm verity.
Click to expand...
Click to collapse
Disabled dm-verity caused red warning, i guess.
---------- Post added at 10:01 AM ---------- Previous post was at 09:58 AM ----------
foobar66 said:
Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
And then:
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...
Click to expand...
Click to collapse
Edited abl.img ? and flashed via recovery/fastboot ?

AnoopKumar said:
Edited abl.img ? and flashed via recovery/fastboot ?
Click to expand...
Click to collapse
No, just flashed using dd command in TWRP shell.

foobar66 said:
No, just flashed using dd command in TWRP shell.
Click to expand...
Click to collapse
Phone still dead ?

OK ... I managed to recover my phone !
A windows PC with the MSM program did the trick.
I am now back to stock 9.0.5

foobar66 said:
OK ... I managed to recover my phone !
A windows PC with the MSM program did the trick.
I am now back to stock 9.0.5
Click to expand...
Click to collapse
I assume that, there is nothing to do with the abl.img. Only thing we can do with it is change the default strings to a song lyric or something. abl.img is the uefi firmware i guess. Bootloader is using the images stored in the logo partition.

Gsi's flash without breaking verity if u flash to both slots. And totally format. Fastboot -w. The phone sees any changes to partitions as corruption and breaks verity, hence red warning.. if someone would be inclined to talk to invisiblek from the essential threads, he could tell u of a fix. The solution is not in abl. It's in the stock boot.img. if I had more time, I would help
---------- Post added at 02:52 PM ---------- Previous post was at 02:51 PM ----------
tech_head said:
Different issue.
They are not trying to get rid of the red warning but the yellow warning for an unlocked BL.
On this phone, if you have a "red" warning you use the MSMDownload tool and go back factory including locking the BL.
This is a different case.
Click to expand...
Click to collapse
No, they are talking about breaking verity also. Seems to be both messages, but more recently the broken verity message. Which there is two types, one u can boot from, one u cannot.

jacksummers said:
U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool
Click to expand...
Click to collapse
I would love that idea. That would be really nice to have on our device

QFIL Partition Manager Working!

I started working to get QFIL to work with the Sprint OnePlus 7 Pro 5G as soon as I got the MSMDownloadTool for it.
I accomplished getting the partition manager working, which allows us to flash individual (SIGNED) partitions. We can now try flashing individual international partitions to gain unlocked bootloaders WITHOUT MSM and the need to flash entirely different variants. Plus, 5G users will keep their 5G modems! I need somebody with an international version to join me in TeamView or something, in order to pull the Bootloader and other Partitions.
If another dev here can help me in getting this to work, we could be on the road to bootloader unlocks without SIM unlocks.

jthein1989 said:
I started working to get QFIL to work with the Sprint OnePlus 7 Pro 5G as soon as I got the MSMDownloadTool for it.
I accomplished getting the partition manager working, which allows us to flash individual (SIGNED) partitions. We can now try flashing individual international partitions to gain unlocked bootloaders WITHOUT MSM and the need to flash entirely different variants. Plus, 5G users will keep their 5G modems! I need somebody with an international version to join me in TeamView or something, in order to pull the Bootloader and other Partitions.
If another dev here can help me in getting this to work, we could be on the road to bootloader unlocks without SIM unlocks.
Click to expand...
Click to collapse
Wow, you did it?
I saw the first thread you made where you were talking about extracting .xml files and firehose from OPS file for OP7P 5G for single partition backup/restore via qfil, but oneplus didn't provide you msm tool for 5g variant because "they didn't have it" (which is a lie, becuse if you watch a video from linus tech tips on how he visited oneplus quality test thing back in oneplus 6t days, you would have seen a section where they use THE SAME TOOL, in the firmware flashing section)
Could you provide a full list of files you got from .ops file? Did you get everything that is needed for flashing?
It would be nice if you could do something like this for oneplus 7 pro regular one, so we don't have to have our phones factory reset and BL locked after msm tool flash.

jthein1989 said:
I started working to get QFIL to work with the Sprint OnePlus 7 Pro 5G as soon as I got the MSMDownloadTool for it.
Click to expand...
Click to collapse
I've gotten to around the same point as you have, however I'm having a little bit a trouble getting QFIL to flash a partition. I think it has to do with me missing the proper rawprogram and patch0 XML files. Did you need these at all? If so, how did you obtain them? Appreciate the effort by the way, this ain't easy stuff.
---------- Post added at 09:46 PM ---------- Previous post was at 09:42 PM ----------
Xenos7 said:
Wow, you did it?
I saw the first thread you made where you were talking about extracting .xml files and firehose from OPS file for OP7P 5G for single partition backup/restore via qfil, but oneplus didn't provide you msm tool for 5g variant because "they didn't have it" (which is a lie, becuse if you watch a video from linus tech tips on how he visited oneplus quality test thing back in oneplus 6t days, you would have seen a section where they use THE SAME TOOL, in the firmware flashing section)
Could you provide a full list of files you got from .ops file? Did you get everything that is needed for flashing?
It would be nice if you could do something like this for oneplus 7 pro regular one, so we don't have to have our phones factory reset and BL locked after msm tool flash.
Click to expand...
Click to collapse
He was actually able to obtain the MSM tool from OnePlus. There's a thread on this forum for the download somewhere.
I've also been able to somewhat decrypt and extract files from OPS, but all I was able to obtain was the Firehose binary and an XML file, which contains program and patch commands. There's more to extract but I'm not completely sure how he did it to be honest.

Xenos7 said:
Wow, you did it?
I saw the first thread you made where you were talking about extracting .xml files and firehose from OPS file for OP7P 5G for single partition backup/restore via qfil, but oneplus didn't provide you msm tool for 5g variant because "they didn't have it" (which is a lie, becuse if you watch a video from linus tech tips on how he visited oneplus quality test thing back in oneplus 6t days, you would have seen a section where they use THE SAME TOOL, in the firmware flashing section)
Could you provide a full list of files you got from .ops file? Did you get everything that is needed for flashing?
It would be nice if you could do something like this for oneplus 7 pro regular one, so we don't have to have our phones factory reset and BL locked after msm tool flash.
Click to expand...
Click to collapse
I finally got the MSM for the Sprint variant. You can find that in my other post.
It's actually quite easy to pull partitions from the phone. As a matter of fact you can use both QFIL or MSM to do it. I haven't created a guide to do it through QFIL, yet... You can find my MSM guide in my Sprint MSM post.
To flash through QFIL you use partition manager to read and write individual partitions because the xmls aren't needed, partition manager maps out the UFS through Sahara.
And I must state. DO NOT use provision xmls to download, only to open Partition Manager.
You can only decrypt the firehose and provisioning xml from ops, not the partitions unfortunately. But you can pull every partition through MSM if you really want them. In my personal opinion, you only need a couple really. Except in the case of 5G phones, you need more for those.

Guy50570 said:
I've gotten to around the same point as you have, however I'm having a little bit a trouble getting QFIL to flash a partition. I think it has to do with me missing the proper rawprogram and patch0 XML files. Did you need these at all? If so, how did you obtain them? Appreciate the effort by the way, this ain't easy stuff.
---------- Post added at 09:46 PM ---------- Previous post was at 09:42 PM ----------
He was actually able to obtain the MSM tool from OnePlus. There's a thread on this forum for the download somewhere.
I've also been able to somewhat decrypt and extract files from OPS, but all I was able to obtain was the Firehose binary and an XML file, which contains program and patch commands. There's more to extract but I'm not completely sure how he did it to be honest.
Click to expand...
Click to collapse
You shouldn't need the RawProgram or Patch XMLs to write through partition manager. The partition manager already knows where they are located.
Provisioning XMLs are used by QFIL to map out LUNs, which are just virtual drives on the UFS. RawProgram and Patch XMLs are used by QFIL to map the partitions in the LUNs. Which in this case aren't needed. (MSMDownloadTool maps both LUNs and Partitions, but doesn't have the ability to flash single partitions).
Edit: Sorry, I didn't see the other question. In order to get RawProgram and Patch XMLs, you have to decrypt the GPT partitions. I have the scripts to make them, but it's a headache, and they shouldn't be needed.

jthein1989 said:
You shouldn't need the RawProgram or Patch XMLs to write through partition manager. The partition manager already knows where they are located.
Provisioning XMLs are used by QFIL to map out LUNs, which are just virtual drives on the UFS. RawProgram and Patch XMLs are used by QFIL to map the partitions in the LUNs. Which in this case aren't needed. (MSMDownloadTool maps both LUNs and Partitions, but doesn't have the ability to flash single partitions).
Edit: Sorry, I didn't see the other question. In order to get RawProgram and Patch XMLs, you have to decrypt the GPT partitions. I have the scripts to make them, but it's a headache, and they shouldn't be needed.
Click to expand...
Click to collapse
So those 2 xmls are generated from PrimaryGPT and BackupGPT, and they are used to generate partition table of the device, and to point qfil to which partitions to flash different images correct?
If that's the case then it's logical they are not needed for single partition flashing.
Single partition flashing is done with only using sahara comunication with the device (and firehose?) correct?
And what is counted in as a "signed" image for flashing. Can we just take a dd of an image and flash it with qfil later, or do we need to use msm tool readback to do so? Those should be fine right?
If not then only ones which should work are ones in .ops, and there is a little bit of a problem when it comes to obtaining them.
Edit: When I said what is counted in as signed, dd or msm dump, I meant if they are unchanged, and all official, will they still be counted as signed, or recognized as official?

Xenos7 said:
So those 2 xmls are generated from PrimaryGPT and BackupGPT, and they are used to generate partition table of the device, and to point qfil to which partitions to flash different images correct?
If that's the case then it's logical they are not needed for single partition flashing.
Single partition flashing is done with only using sahara comunication with the device (and firehose?) correct?
And what is counted in as a "signed" image for flashing. Can we just take a dd of an image and flash it with qfil later, or do we need to use msm tool readback to do so? Those should be fine right?
If not then only ones which should work are ones in .ops, and there is a little bit of a problem when it comes to obtaining them.
Click to expand...
Click to collapse
You bring up a great point. I'm not sure if you can write partitions gained from MSM's ReadBack functionality in QFIL? I'm sure, no I'm positive you can write partitions read from QFIL though. I'm not aware of any way to extract partitions from an ops in order to even attempt to write them.
That is why I needed somebody with an unlocked phone to ReadBack through MSM or Read from QFIL their partitions. In order to attempt to write them individually through QFIL.

jthein1989 said:
You shouldn't need the RawProgram or Patch XMLs to write through partition manager. The partition manager already knows where they are located.
Provisioning XMLs are used by QFIL to map out LUNs, which are just virtual drives on the UFS. RawProgram and Patch XMLs are used by QFIL to map the partitions in the LUNs. Which in this case aren't needed. (MSMDownloadTool maps both LUNs and Partitions, but doesn't have the ability to flash single partitions).
Edit: Sorry, I didn't see the other question. In order to get RawProgram and Patch XMLs, you have to decrypt the GPT partitions. I have the scripts to make them, but it's a headache, and they shouldn't be needed.
Click to expand...
Click to collapse
Hm, I see. Wonder why I'm getting this error then.
Code:
09:42:54: {ERROR: program FAILED - Please see log}
Writing log to 'C:\Users\{username}\AppData\Roaming\Qualcomm\QFIL\COMPORT_5\port_trace.txt', might take a minute
Log is 'C:\Users\{username}\AppData\Roaming\Qualcomm\QFIL\COMPORT_5\port_trace.txt'
Send Image Fail:FireHose Fail:FHLoader Fail:Process fail
Finish Send Image
Everything else before this point seems to work just fine so, slightly confused here as to what I need.

Guy50570 said:
Hm, I see. Wonder why I'm getting this error then.
Everything else before this point seems to work just fine so, slightly confused here as to what I need.
Click to expand...
Click to collapse
I will try to look. Sundays are a busy day for me. I'll let you know.

jthein1989 said:
I will try to look. Sundays are a busy day for me. I'll let you know.
Click to expand...
Click to collapse
Hey, no worries, I'm not in any rush, just trying to help out the best I can.

Any update?

Flashing a single partition is not hard, you do need the payload and the patch both xml, not to mention loader,
Below is an example from a ZTE: Zmax Pro:
rawprogram0.xml
Code:
<?xml version="1.0" ?>
<data>
<!--NOTE: This is an ** Autogenerated file **-->
<!--NOTE: Sector size is 512bytes-->
<program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="recovery.img" label="recovery" num_partition_sectors="98304" partofsingleimage="false" physical_partition_number="0" readbackverify="false" size_in_KB="49152.0" sparse="false" start_byte_hex="0x15000000" start_sector="688128"/>
</data>
patch0.xml:
Code:
<?xml version="1.0" ?>
<patches>
<!--NOTE: This is an ** Autogenerated file **-->
<!--NOTE: Patching is in little endian format, i.e. 0xAABBCCDD will look like DD CC BB AA in the file or on disk-->
<!--NOTE: This file is used by Trace32 - So make sure to add decimals, i.e. 0x10-10=0, *but* 0x10-10.=6.-->
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="168" filename="gpt_main0.bin" physical_partition_number="0" size_in_bytes="8" start_sector="11" value="NUM_DISK_SECTORS-34." what="Update last partition 38 'userdata' with actual size in Primary Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="168" filename="DISK" physical_partition_number="0" size_in_bytes="8" start_sector="11" value="NUM_DISK_SECTORS-34." what="Update last partition 38 'userdata' with actual size in Primary Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="168" filename="gpt_backup0.bin" physical_partition_number="0" size_in_bytes="8" start_sector="9" value="NUM_DISK_SECTORS-34." what="Update last partition 38 'userdata' with actual size in Backup Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="168" filename="DISK" physical_partition_number="0" size_in_bytes="8" start_sector="NUM_DISK_SECTORS-24." value="NUM_DISK_SECTORS-34." what="Update last partition 38 'userdata' with actual size in Backup Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="48" filename="gpt_main0.bin" physical_partition_number="0" size_in_bytes="8" start_sector="1" value="NUM_DISK_SECTORS-34." what="Update Primary Header with LastUseableLBA."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="48" filename="DISK" physical_partition_number="0" size_in_bytes="8" start_sector="1" value="NUM_DISK_SECTORS-34." what="Update Primary Header with LastUseableLBA."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="48" filename="gpt_backup0.bin" physical_partition_number="0" size_in_bytes="8" start_sector="32" value="NUM_DISK_SECTORS-34." what="Update Backup Header with LastUseableLBA."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="48" filename="DISK" physical_partition_number="0" size_in_bytes="8" start_sector="NUM_DISK_SECTORS-1." value="NUM_DISK_SECTORS-34." what="Update Backup Header with LastUseableLBA."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="32" filename="gpt_main0.bin" physical_partition_number="0" size_in_bytes="8" start_sector="1" value="NUM_DISK_SECTORS-1." what="Update Primary Header with BackupGPT Header Location."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="32" filename="DISK" physical_partition_number="0" size_in_bytes="8" start_sector="1" value="NUM_DISK_SECTORS-1." what="Update Primary Header with BackupGPT Header Location."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="24" filename="gpt_backup0.bin" physical_partition_number="0" size_in_bytes="8" start_sector="32" value="NUM_DISK_SECTORS-1." what="Update Backup Header with CurrentLBA."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="24" filename="DISK" physical_partition_number="0" size_in_bytes="8" start_sector="NUM_DISK_SECTORS-1." value="NUM_DISK_SECTORS-1." what="Update Backup Header with CurrentLBA."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="72" filename="gpt_backup0.bin" physical_partition_number="0" size_in_bytes="8" start_sector="32" value="NUM_DISK_SECTORS-33." what="Update Backup Header with Partition Array Location."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="72" filename="DISK" physical_partition_number="0" size_in_bytes="8" start_sector="NUM_DISK_SECTORS-1" value="NUM_DISK_SECTORS-33." what="Update Backup Header with Partition Array Location."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="88" filename="gpt_main0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="1" value="CRC32(2,5120)" what="Update Primary Header with CRC of Partition Array."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="88" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="1" value="CRC32(2,5120)" what="Update Primary Header with CRC of Partition Array."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="88" filename="gpt_backup0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="32" value="CRC32(0,5120)" what="Update Backup Header with CRC of Partition Array."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="88" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="NUM_DISK_SECTORS-1." value="CRC32(NUM_DISK_SECTORS-33.,5120)" what="Update Backup Header with CRC of Partition Array."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="16" filename="gpt_main0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="1" value="0" what="Zero Out Header CRC in Primary Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="16" filename="gpt_main0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="1" value="CRC32(1,92)" what="Update Primary Header with CRC of Primary Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="16" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="1" value="0" what="Zero Out Header CRC in Primary Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="16" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="1" value="CRC32(1,92)" what="Update Primary Header with CRC of Primary Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="16" filename="gpt_backup0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="32" value="0" what="Zero Out Header CRC in Backup Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="16" filename="gpt_backup0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="32" value="CRC32(32,92)" what="Update Backup Header with CRC of Backup Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="16" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="NUM_DISK_SECTORS-1." value="0" what="Zero Out Header CRC in Backup Header."/>
<patch SECTOR_SIZE_IN_BYTES="512" byte_offset="16" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="NUM_DISK_SECTORS-1." value="CRC32(NUM_DISK_SECTORS-1.,92)" what="Update Backup Header with CRC of Backup Header."/>
</patches>
Now you see the idea?

Have there been any developments on the Sprint OP7Pro 5g? I was gifted one this holiday and practically have no use for it until bootloader unlock is available.

jthein1989 said:
I started working to get QFIL to work with the Sprint OnePlus 7 Pro 5G as soon as I got the MSMDownloadTool for it.
I accomplished getting the partition manager working, which allows us to flash individual (SIGNED) partitions. We can now try flashing individual international partitions to gain unlocked bootloaders WITHOUT MSM and the need to flash entirely different variants. Plus, 5G users will keep their 5G modems! I need somebody with an international version to join me in TeamView or something, in order to pull the Bootloader and other Partitions.
If another dev here can help me in getting this to work, we could be on the road to bootloader unlocks without SIM unlocks.
Click to expand...
Click to collapse
What would you like from my 7Pro?
I'm running 10.3 though.

Del

I have to give a big shout out and I just want to thank everyone for their hard work on figuring the procedures out for unlocking the bootloader, and flashing the these phones.
The tutorial for unlocking the bootloader for the Sprint Oneplus 7 Pro 5G work flawlessly if you follow the tutoralial:
https://forum.xda-developers.com/on...otloader-unlock-sprint-oneplus-7-pro-t4042145
When I first received my phone I bought off eBay I went ahead and set the phone up and upgraded the phone over OTA to
android OS to v10.0.2. This was so I could use the TWRP for Q (10) during the bootloder unlock setup to fix the issues with it
rebooting back into the bootloader. One thing I did learn during the process that it might try to boot into system and
get stuck on the Sprint 5G boot animation. So to force it to power cycle press (VOLUME UP + POWER) buttons and hold them
until it does reboot and then quickly press and hold the (VOLUME UP + VOLUME DOWN + POWER) buttons to boot back into bootloader and
run the FIX instructions again.
Once the bootloader was unlocked I used this tutorial to cross flash the firmware to the OnePlus 7 Pro 5G European. Then went through
the phone setup process and then installed the Oxegen Updater APK to downloaded the firmware to forced it to update to the latest 10.0.6 firmware by manually installing
it through the System Update under the gear Local update. Tutorial found here:
https://forum.xda-developers.com/oneplus-7-pro/how-to/discussion-oneplus-7-pro-5g-rom-gsi-t4042583
Then I followed the tutorial to installing TWRP for Q (10) and to root installing Magisk:
https://forums.oneplus.com/threads/...magisk-twrp-oneplus-7-pro-android-10.1178410/
I found out during the process of flashing and updating to the Oxegen 10.0.6 European firmware the bootloader had re-locked.
So I had to follow the steps once again to unlock the bootloader and then followed the guide of rooting the Sprint OnePlus 7 Pro
5G.
Now to the part I have run into trouble trying to remove the SIM LOCK on the phone to Sprint:
I tried to follow the tutorial of SIM UNLOCKING the T-Mobile OnePlus 7 Pro:
https://forum.xda-developers.com/oneplus-6t/how-to/guide-sim-unlock-t-mobile-version-type-t3915269
Fist I did back up my phone in TWRP. However, when you run these two fastboot commands from the bootloader it will FAIL:
fastboot erase modemst1
fastboot erase modemst2
The Error messages are:
Erasing 'modemst1' FAILED (remote: 'Erase is not allowed for Critical Partitions')
fastboot: error: Command failed
Erasing 'modemst1' FAILED (remote: 'Erase is not allowed for Critical Partitions')
fastboot: error: Command failed
So after doing some research and running this fastboot command I found out that not everything unlocked:
fastboot oem device-info
And it's output:
(bootloader) Verity mode: true
(bootloader) Device unlocked: true
(bootloader) Device critical unlocked: false
(bootloader) Charger screen enabled: true
(bootloader) enable_dm_verity: true
(bootloader) have_console: false
(bootloader) selinux_type: SELINUX_TYPE_INVALID
(bootloader) boot_mode: NORMAL_MODE
(bootloader) kmemleak_detect: false
(bootloader) force_training: 0
(bootloader) mount_tempfs: 0
(bootloader) op_abl_version: 0x31
(bootloader) cal_rebootcount: 0x31
OKAY [ 0.064s]
Finished. Total time: 0.071s
As you can see the Device critical unlocked is: false. So you cannot write to those partitions.
I tried the fastboot commands:
fastboot flashing unlock_critical
fastboot oem unlock_critical
Both with same message:
FAILED (remote: ' Device already : unlocked!')
fastboot: error: Command failed
I even tried the shell commands to overwrite the two partitions from TWRP and from command prompt using
adb from platform tools:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst2
And it's output:
/system/bin/sh: adb: inaccessible or not found
Modemst1, modemst2 and zero do exist but being bootloader critial locked you still cannot write to the partitions even with root.
So next I looked into using QPST package and erasing the partitions using Partition Manager from QFIL utility but need the firehose
file for SM8150 chipset and the following site does not have it listed:
https://forum.hovatek.com/thread-25696.html
Good tutorial on using the QFIL and updating partition:
https://www.youtube.com/watch?v=MdknZvaTwl4
So finding this thread it was said you extract the firehose file from the MsmDownloadTool OPS file. I tried using the python script github to dump the OPS file
but I could never get crypto to compile correctly on my windows box for python and used another branch said not a WIN32 file error for crypto. Found here:
https://github.com/bkerler/oppo_decrypt
So my question is how do you extract the firehose file from the MsmDownloadTool OPS file so we can possibly enable writing to the critical partitions so you can make other updates
such as modifying the apns-conf.xml because you cannot write to critical partitions even with root privileges.
Thanks in advance for any advice and help!

Hi pulled with oppo_decrypt..

joecowboy said:
I have to give a big shout out and I just want to thank everyone for their hard work on figuring the procedures out for unlocking the bootloader, and flashing the these phones.
The tutorial for unlocking the bootloader for the Sprint Oneplus 7 Pro 5G work flawlessly if you follow the tutoralial:
https://forum.xda-developers.com/on...otloader-unlock-sprint-oneplus-7-pro-t4042145
When I first received my phone I bought off eBay I went ahead and set the phone up and upgraded the phone over OTA to
android OS to v10.0.2. This was so I could use the TWRP for Q (10) during the bootloder unlock setup to fix the issues with it
rebooting back into the bootloader. One thing I did learn during the process that it might try to boot into system and
get stuck on the Sprint 5G boot animation. So to force it to power cycle press (VOLUME UP + POWER) buttons and hold them
until it does reboot and then quickly press and hold the (VOLUME UP + VOLUME DOWN + POWER) buttons to boot back into bootloader and
run the FIX instructions again.
Once the bootloader was unlocked I used this tutorial to cross flash the firmware to the OnePlus 7 Pro 5G European. Then went through
the phone setup process and then installed the Oxegen Updater APK to downloaded the firmware to forced it to update to the latest 10.0.6 firmware by manually installing
it through the System Update under the gear Local update. Tutorial found here:
https://forum.xda-developers.com/oneplus-7-pro/how-to/discussion-oneplus-7-pro-5g-rom-gsi-t4042583
Then I followed the tutorial to installing TWRP for Q (10) and to root installing Magisk:
https://forums.oneplus.com/threads/...magisk-twrp-oneplus-7-pro-android-10.1178410/
I found out during the process of flashing and updating to the Oxegen 10.0.6 European firmware the bootloader had re-locked.
So I had to follow the steps once again to unlock the bootloader and then followed the guide of rooting the Sprint OnePlus 7 Pro
5G.
Now to the part I have run into trouble trying to remove the SIM LOCK on the phone to Sprint:
I tried to follow the tutorial of SIM UNLOCKING the T-Mobile OnePlus 7 Pro:
https://forum.xda-developers.com/oneplus-6t/how-to/guide-sim-unlock-t-mobile-version-type-t3915269
Fist I did back up my phone in TWRP. However, when you run these two fastboot commands from the bootloader it will FAIL:
fastboot erase modemst1
fastboot erase modemst2
The Error messages are:
Erasing 'modemst1' FAILED (remote: 'Erase is not allowed for Critical Partitions')
fastboot: error: Command failed
Erasing 'modemst1' FAILED (remote: 'Erase is not allowed for Critical Partitions')
fastboot: error: Command failed
So after doing some research and running this fastboot command I found out that not everything unlocked:
fastboot oem device-info
And it's output:
(bootloader) Verity mode: true
(bootloader) Device unlocked: true
(bootloader) Device critical unlocked: false
(bootloader) Charger screen enabled: true
(bootloader) enable_dm_verity: true
(bootloader) have_console: false
(bootloader) selinux_type: SELINUX_TYPE_INVALID
(bootloader) boot_mode: NORMAL_MODE
(bootloader) kmemleak_detect: false
(bootloader) force_training: 0
(bootloader) mount_tempfs: 0
(bootloader) op_abl_version: 0x31
(bootloader) cal_rebootcount: 0x31
OKAY [ 0.064s]
Finished. Total time: 0.071s
As you can see the Device critical unlocked is: false. So you cannot write to those partitions.
I tried the fastboot commands:
fastboot flashing unlock_critical
fastboot oem unlock_critical
Both with same message:
FAILED (remote: ' Device already : unlocked!')
fastboot: error: Command failed
I even tried the shell commands to overwrite the two partitions from TWRP and from command prompt using
adb from platform tools:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst2
And it's output:
/system/bin/sh: adb: inaccessible or not found
Modemst1, modemst2 and zero do exist but being bootloader critial locked you still cannot write to the partitions even with root.
So next I looked into using QPST package and erasing the partitions using Partition Manager from QFIL utility but need the firehose
file for SM8150 chipset and the following site does not have it listed:
https://forum.hovatek.com/thread-25696.html
Good tutorial on using the QFIL and updating partition:
So finding this thread it was said you extract the firehose file from the MsmDownloadTool OPS file. I tried using the python script github to dump the OPS file
but I could never get crypto to compile correctly on my windows box for python and used another branch said not a WIN32 file error for crypto. Found here:
https://github.com/bkerler/oppo_decrypt
So my question is how do you extract the firehose file from the MsmDownloadTool OPS file so we can possibly enable writing to the critical partitions so you can make other updates
such as modifying the apns-conf.xml because you cannot write to critical partitions even with root privileges.
Thanks in advance for any advice and help!
Click to expand...
Click to collapse
I pulled the firehose for the T-Mobile. It's uploaded on my sim unlock post

Awesome, I will have to do some more testing! I love this phone. Thank you!

joecowboy said:
Awesome, I will have to do some more testing! I love this phone. Thank you!
Click to expand...
Click to collapse
I have been testing like crazy.i just confurmed the lock is 100% in the modemst1 and modemst2. But they are encrypted so that the sim info has to pass through them .so that if deleted there no way to get the sims to work.we need a programmer this is way over my head.

[TUTORIAL] How to unbrick Nexus 7 without blob.bin (REQUIRES ANOTHER NEXUS 7 2012)

Thanks to @Jirmd for letting me use his post as a reference.
Original post: https://forum.xda-developers.com/nexus-7/general/unbrick-nexus-7-tegra-3-device-t4078627
Alternative Method:
1. https://github.com/tofurky/tegra30_debrick
2. https://forum.xda-developers.com/t/...-without-another-n7-or-tegra30-device.4305955
(Both methods do not require another Nexus 7)
Requirements:
1. Linux-based OS (I use Ubuntu 18.04)
2. NvFlash and Wheelie (You can download the Linux version down below)
3. A USB cable (A good and sturdy one)
4. Nerve of steel lol
5. Must have APX driver installed.
6. Another Nexus 7 (Ask someone that have it or ask me)(MUST BE ROOTED AND HAVE TWRP RECOVERY INSTALLED)
7. ADB (platform-tools)
1. DUMP SBK VIA USB
Step 1: Download fusee-launcher for Nexus 7 from this link and extract it to a folder:
http://www.mediafire.com/file/sgwsa79idk24z8u/fusee-launcher-n7.zip/file
Step 2: Open a terminal inside of the folder then type:
Code:
sudo apt-get install python-usb python3-usb
Wait for it to complete. After that, type:
Code:
pip install pyusb
Step 3: Connect your device to a USB 3.0 port (REQUIRED). You can check for connection using "lsusb". There must be a "NVidia Corp" in the list.
Step 4: Type:
Code:
sudo ./fusee-launcher.py –tty dump-sbk-via-usb.bin
Something like this should appear:
Code:
05f4a5d01'
Stack snapshot: b'0000000000000000100000003c9f0040'
EndpointStatus_stack_addr: 0x40009f3c
ProcessSetupPacket SP: 0x40009f30
InnerMemcpy LR stack addr: 0x40009f20
overwrite_len: 0x00004f20
overwrite_payload_off: 0x00004de0
payload_first_length: 0x00004de0
overwrite_payload_off: 0x00004de0
payload_second_length: 0x0000c7b0
b'00a0004000300040e04d0000b0c70000'
Setting rcm msg size to 0x00030064
RCM payload (len_insecure): b'64000300'
Setting ourselves up to smash the stack...
Payload offset of intermezzo: 0x00000074
overwrite_payload_off: 0x00004de0
overwrite_len: 0x00004f20
payload_overwrite_len: 0x00004e5c
overwrite_payload_off: 0x00004de0
smash_padding: 0x00000000
overwrite_payload_off: 0x00004de0
Uploading payload...
txing 73728 bytes total
txing 4096 bytes (0 already sent) to buf[0] 0x40003000
txing 4096 bytes (4096 already sent) to buf[1] 0x40005000
txing 4096 bytes (8192 already sent) to buf[0] 0x40003000
txing 4096 bytes (12288 already sent) to buf[1] 0x40005000
txing 4096 bytes (16384 already sent) to buf[0] 0x40003000
txing 4096 bytes (20480 already sent) to buf[1] 0x40005000
txing 4096 bytes (24576 already sent) to buf[0] 0x40003000
txing 4096 bytes (28672 already sent) to buf[1] 0x40005000
txing 4096 bytes (32768 already sent) to buf[0] 0x40003000
txing 4096 bytes (36864 already sent) to buf[1] 0x40005000
txing 4096 bytes (40960 already sent) to buf[0] 0x40003000
txing 4096 bytes (45056 already sent) to buf[1] 0x40005000
txing 4096 bytes (49152 already sent) to buf[0] 0x40003000
txing 4096 bytes (53248 already sent) to buf[1] 0x40005000
txing 4096 bytes (57344 already sent) to buf[0] 0x40003000
txing 4096 bytes (61440 already sent) to buf[1] 0x40005000
txing 4096 bytes (65536 already sent) to buf[0] 0x40003000
txing 4096 bytes (69632 already sent) to buf[1] 0x40005000
txing 4096 bytes total
txing 4096 bytes (0 already sent) to buf[0] 0x40003000
Smashing the stack...
sending status request with length 0x00004f20
The USB device stopped responding-- sure smells like we've smashed its stack. :)
Launch complete!
b'4445414442454546'
DEADBEEF
b'3030303030303030'
00000000
b'3030303030303030'
00000000
b'3034303030303930'
04000090
b'4634314330433241'
F41C0C2A
b'3133333731333337'
13371337
b'3535353535353535'
55555555
b'3430303033303030'
40003000
b'3430303035303030'
40005000
b'4141414141414141'
AAAAAAAA
b'3131313131313131'
11111111
b'3030303030303236'
00000026
b'3232323232323232'
22222222
b'68656c6c6f2c20776f726c640a00'
hello, world
b'e57de3bab6cb499d874d5772cb219f0101042c20'
Traceback (most recent call last):
File "./fusee-launcher.py", line 823, in <module>
buf = switch.read(USB_XFER_MAX)
File "./fusee-launcher.py", line 530, in read
return self.backend.read(length)
File "./fusee-launcher.py", line 134, in read
return bytes(self.dev.read(0x81, length, 3000))
File "/usr/local/lib/python3.6/dist-packages/usb/core.py", line 988, in read
self.__get_timeout(timeout))
File "/usr/local/lib/python3.6/dist-packages/usb/_debug.py", line 60, in do_trace
return f(*args, **named_args)
File "/usr/local/lib/python3.6/dist-packages/usb/backend/libusb1.py", line 833, in bulk_read
timeout)
File "/usr/local/lib/python3.6/dist-packages/usb/backend/libusb1.py", line 936, in __read
_check(retval)
File "/usr/local/lib/python3.6/dist-packages/usb/backend/libusb1.py", line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 110] Operation timed out
Search for the line "hello, world" inside of your log. It looks like this in this example:
Code:
hello, world
b'e57de3bab6cb499d874d5772cb219f0101042c20'
The last 8 characters are not your SBK. This is the first 8 numbers of your Device ID. Delete this and delete the b' at the start and also the ' at the end.
The result should look like this:
Code:
e57de3bab6cb499d874d5772cb219f01
Congratulation, you have successfully dump your device SBK via USB.
2. GETTING YOUR CPU UID
Step 1: Download Wheelie and NvFlash then extract it to a folder.
Step 2: Download this broken blob.bin file (REQUIRE)
http://www.mediafire.com/file/32cxvjv2wajokqf/blob.bin/file
Then place it inside of the Wheelie and NvFlash folder.
Step 3: Open a terminal inside of the folder then type:
Code:
./wheelie --blob blob.bin
After that, something like this should appear:
Code:
Wheelie 0.1 - Preflight for nvflash.
Copyright (c) 2011-2012 androidroot.mobi
========================================
[=] Chip UID: 0x98254853062001158
[-] Incorrect SBK or SBK type selected. nverror: 0x4.
Search for "Chip UID", remove the "0x" at the beginning. The result should look like this:
Code:
98254853062001158
Congratulation, you got your chip UID
3. GENERATE BLOB FILES USING ANOTHER NEXUS 7
Step 1: Download MkNvfBlob from this link:
https://github.com/GeorgeMato4/nvcrypttools/blob/forN7/precompiled/precompiledN7.tar.xz
Note: Extract this to your Nexus 7.
Step 1.1: Reboot into TWRP recovery.
Step 2: Open a terminal inside of you ADB folder then type:
Code:
adb shell
After that:
Code:
su
Type this command after that:
Code:
mkdir /AndroidRoot
Last one:
Code:
cat /proc/cpuinfo > /AndroidRoot/cpuinfo
Pull the cpuinfo file using this command:
Code:
adb pull /AndroidRoot
Note: You could copy your cpuinfo file to your PC using MTP (IDK how to do this so search Google lol)
Open your ADB folder and there should be a AndroidRoot folder with a cpuinfo file inside of it.
Open cpuinfo using a Text Editor. Something like this should be inside:
Code:
Processor : ARMv7 Processor rev 9 (v7l)
processor : 0
BogoMIPS : 1993.93
processor : 1
BogoMIPS : 1993.93
processor : 2
BogoMIPS : 1993.93
processor : 3
BogoMIPS : 1993.93
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 9
Hardware : grouper
Revision : 0000
Serial : 015d4a5f202c0401
Replace the Serial line with your Chip UID.
After that, place the cpuinfo file back to the /AndroidRoot folder on your device using this command:
Code:
adb push AndroidRoot /
After you are done, don't close the ADB windows.
Step 3: Download bootloader.xbt:
https://github.com/GeorgeMato4/nvcrypttools/blob/forN7/bootloaders/bootloader.grouper.XBT
And BCT for your device:
https://github.com/GeorgeMato4/nvcrypttools/blob/forN7/bct/n7.bct
And copy these two files to the /AndroidRoot folder on your device.
Step 4: Type this command on the ADB windows:
Code:
cd /AndroidRoot
After that, type:
Code:
chmod 777 ./mknvfblob
After that, type:
Code:
./mknvfblob -W -K <your SBK> --blob /AndroidRoot/test.blob --bctin /AndroidRoot/n7.bct --bctr /AndroidRoot/testr.bct --bctc /AndroidRoot/testc.bct --blin /AndroidRoot/bootloader.grouper.XBT --blout /AndroidRoot/test.ebt
Wait for it to do its job.
After that, go to your /AndroidRoot folder and copy all the file that just got generated (testr.bct, testc.bct. test.ebt, test.blob) to your PC using the adb pull command on Step 2
Congratulation, you have successfully generate blob for your bricked device.
4. UNBRICK YOUR DEVICE (The fun part )
Step 1: Boot your bricked device into APX mode either using Power button or Power + Vol UP.
Step 2: Open a terminal inside of the folder where you place your NvFlash folder (move the blob file inside of that folder, all of them)
Step 3: Open a terminal inside of your Wheelie and NvFlash folder. Type:
Code:
sudo ./nvflash --bl test.ebt --bct testr.bct --blob test.blob
If you got this command:
Code:
command error: no command found
Then try this one instead:
Code:
./nvflash --setbct --create --configfile <your flash.cfg> --bl test.ebt --bct testr.bct --blob test.blob
If you got the NvError, its fine.
Something like this should appear (the first command):
Code:
Nvflash v1.13.87205 started
Using blob v1.13.00000
chip uid from BR is: 0x0000000000000000015d2bc285340e0f
rcm version 0X30001
System Information:
chip name: unknown
chip id: 0x30 major: 1 minor: 3
chip sku: 0x83
chip uid: 0x0000000000000000015d2bc285340e0f
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 4
device config strap: 1
device config fuse: 17
sdram config strap: 0
sending file: recovery.bct
- 6128/6128 bytes sent
recovery.bct sent successfully
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: bootloader.ebt
- 2146912/2146912 bytes sent
bootloader.ebt sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
A Google Logo should appear on your device screen with the text "Battery is too low" on the upper left corner. Unplug the battery and replug it. After that, plug it into a wall charger for atleast 4 hour.
Step 4: Unplug the battery and boot into APX mode again using the button combination.
Step 5: Type this command while holding down the Vol DOWN button:
Code:
sudo ./nvflash --resume --download 8 boot.img
Replace "boot.img" with your ROM boot.img file. If you download another boot.img that isn't for your ROM, your device will bootloop.
Step 6:
Type:
Code:
sudo ./nvflash --resume --download 4 bootloader.img
Replace "bootloader.img" with your bootloader.img file name (You could get it inside of the Factory Image)
And after its done, your device should technically unbrick now. But I still recommend you re-flash stock ROM.
Step 7: The final step
Boot into your OS using the command below:
Code:
sudo ./nvflash --resume --go
If your device boot back into APX mode, maybe you have done something wrong. Try again.
If you got a Google logo on your device then congratulation! Your device is now unbricked.
Note: If step 7 didn't work, try booting this recovery image using this command:
Code:
fastboot boot flatline_grouper.img
Link for the recovery image is in the "Links" section.
Note: To get into Fastboot, add the "--go" line at the end of the command in Step 5
Code:
sudo ./nvflash --resume --download 8 boot.img --go
HOLD DOWN VOL DOWN while doing this command, you should get into fastboot at
After you are in the Flatline recovery, navigate to the "Advanced" section using the VOL buttons. Select it using the POWER button.
Select the "wheelie" at the end of the list.
Select "I agree".
After that, select "Step 1: Flash AndroidRoot.mobi custom bootloader." IGNORE Step 2 because it won't gonna work anyways.
Your device should reboot and the Google logo should appear, that means that your device is unbricked.
Note: If you wanted to flash stock ROM, open the "image-*******.zip" inside of the factory image and open the android-info.txt file. Edit the "require-bootloader" line to "4.13". After that, it should work.
Links:
flash.cfg: http://www.mediafire.com/file/j90hc1dfz58aytq/flashcfg.zip/file
flatline_grouper.img: https://www.mediafire.com/file/z1jvgy6km33f7bf/flatline_grouper.img/file
Wheelie, NvFlash and platform-tools (For ADB) (Works for both Linux and Windows): https://www.mediafire.com/file/0nuy4indgvagq3v/nvflash-and-platformtool.zip/file
Download the Factory Image for your Nexus 7 incase you want to re-flash stock ROM (nakasi or nakasig): https://developers.google.com/android/images#nakasi
That is. If you need any help, message me.
Update: After a few days of troubleshooting, fixing and updating my post, it seems like the step to unbrick your Nexus 7 2012 may depends on how did you brick it, what OS version you are running or the condition of your device. So you may have to "think outside the box" sometimes in this guide.
Update #2: Some helpful advice from @Jirmd with some minor change:
When you get this error :
Code:
Nvflash v1.10.76762 started
Using blob v1.13.00000
chip uid from BR is: 0x0000000000000000015d4a5f202c0401
rcm version 0X30001
System Information:
chip name: unknown
chip id: 0x30 major: 1 minor: 3
chip sku: 0x83
chip uid: 0x0000000000000000015d4a5f202c0401
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 4
device config strap: 2
device config fuse: 17
sdram config strap: 1
sending file: testr.bct
- 6128/6128 bytes sent
testr.bct sent successfully
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: test.ebt
- 2146896/2146896 bytes sent
test.ebt sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 0 3
failed executing command 11 NvError 0x120002
command failure: create failed (bad data)
bootloader status: specified device is invalid (code: 6) message: nverror:0x4 (0x4) flags: 0
after this command :
Code:
./nvflash --configfile flash.cfg --create --bct testr.bct --setbct --bl test.ebt --blob test.blob --sync
Probably you have broken your internal storage!
You can probably flash:
Bootloader image (bootloader.img)
Kernel image (boot.img)
Recovery image (recovery.img aka TWRP)
But you CAN'T flash a new system via TWRP or fastboot, because the bootloader or the recovery was unable to connect to the partitions table.
You can try this command to erase bad blocks:
Code:
./nvflash --resume --configfile flash.cfg --obliterate
Reboot to APX mode and try the above command again.
But, broken internal storage is pretty much unrepairable.
There is some possibility of disassembly your device and overheat your memory IC, but this method is not easy and need more technical skill.
And in my case this did not help.
Click to expand...
Click to collapse
In my case, this command also gives me the nverror 0x4 but it also did something to my Nexus 7 as it was required for the next step.
Update #3: Updated the guide and removed some unessacery steps.
Update #4: Updated.

Hi, enderzip...
I've been keeping track of the recent developments regarding bricked Nexus 7's, APX mode and nvFlash, here on XDA. There's currently quite a few threads on this topic.
As I understand it, you've been motivated by a desire to recover data from your bootloader bricked Nexus 7. So my question is simple...
'Have you been successful?'
Have you actually resurrected a bricked Nexus 7 with no functioning bootloader AND with no originally created flatline wheelie blobs?
If so, you have done what I thought could not be done! I tip my hat to you, with your tenacity and your technical understanding of the complex issues involved.
If I had a Linux system myself, I'd be half-minded to dig out my old Nexus 7, deliberately bugger up the bootloader, and follow your instructions for the sheer technical challenge!
--------------------------------------
Some general thoughts...
The Nexus 7 is old (c.2012), and likely not many people use it anymore, but that's not what's important here. What is important is the persistence, the huge technical ability, and the sheer bloody minded refusal ~ by some ~ to let their Nexus 7 die... to go into what the poet Dylan Thomas called that 'good night'...
"Do not go gentle into that good night,
Old age should burn and rave at close of day;
Rage, rage against the dying of the light."
https://poets.org/poem/do-not-go-gentle-good-night
And in so doing, mayhap enderzip and others, have provided potential clues for other devices, other hardware, other phones or tablets, when faced with similar hard brick problems. One can but hope.
The above post by enderzip is technically way beyond me, and I have no immediate use for it, but it's a fundamental distillation of everything XDA stands for - namely, experimentation and creativity.
It's basically, amazing!
Thanks enderzip
Rgrds,
Ged.

Hello Enderzip,
Thank you so much for this very good an detailed tuto.
I followed cautiously your instructions but I am blocked @ step 3.
The command "mkdir /AndroidRoot" returns "mkdir : '/AndroidRoot' : Read-only file system".
I suspect Android system partition as read only but does know way to change.
I would appreciate your clever support.
Thank you in advance.
Envoyé de mon Nexus 4 en utilisant Tapatalk

zak4 said:
Hello Enderzip,
Thank you so much for this very good an detailed tuto.
I followed cautiously your instructions but I am blocked @ step 3.
The command "mkdir /AndroidRoot" returns "mkdir : '/AndroidRoot' : Read-only file system".
I suspect Android system partition as read only but does know way to change.
I would appreciate your clever support.
Thank you in advance.
Envoyé de mon Nexus 4 en utilisant Tapatalk
Click to expand...
Click to collapse
You could manually create the folder if you have root. By using those Root File explorer on Google Play Store.
I recommend you using this one: https://play.google.com/store/apps/details?id=com.clearvisions.explorer
Open the app then go to the root section, create a new folder name: AndroidRoot
And you are good to go.
If the above method didnt work, type these command one by one:
Code:
adb shell
su
mount -o rw,remount /system
You can mount your /system back to Read-Only using this command:
Code:
mount -o ro,remount /system

GedBlake said:
Hi, enderzip...
I've been keeping track of the recent developments regarding bricked Nexus 7's, APX mode and nvFlash, here on XDA. There's currently quite a few threads on this topic.
As I understand it, you've been motivated by a desire to recover data from your bootloader bricked Nexus 7. So my question is simple...
'Have you been successful?'
Have you actually resurrected a bricked Nexus 7 with no functioning bootloader AND with no originally created flatline wheelie blobs?
If so, you have done what I thought could not be done! I tip my hat to you, with your tenacity and your technical understanding of the complex issues involved.
If I had a Linux system myself, I'd be half-minded to dig out my old Nexus 7, deliberately bugger up the bootloader, and follow your instructions for the sheer technical challenge!
--------------------------------------
Some general thoughts...
The Nexus 7 is old (c.2012), and likely not many people use it anymore, but that's not what's important here. What is important is the persistence, the huge technical ability, and the sheer bloody minded refusal ~ by some ~ to let their Nexus 7 die... to go into what the poet Dylan Thomas called that 'good night'...
"Do not go gentle into that good night,
Old age should burn and rave at close of day;
Rage, rage against the dying of the light."
https://poets.org/poem/do-not-go-gentle-good-night
And in so doing, mayhap enderzip and others, have provided potential clues for other devices, other hardware, other phones or tablets, when faced with similar hard brick problems. One can but hope.
The above post by enderzip is technically way beyond me, and I have no immediate use for it, but it's a fundamental distillation of everything XDA stands for - namely, experimentation and creativity.
It's basically, amazing!
Thanks enderzip
Rgrds,
Ged.
Click to expand...
Click to collapse
Yes, I have successfully unbrick my Nexus 7 WITHOUT any type of blob file i have generated before.
And no, you should thank @Jirmd instead of me. If he didn't post his thread, my Nexus is still probably a paperweight.

Deleted.

@enderzip
Thank you Enderzip. I succeeded the creation of AndroidRoot with the command for write permission on system.
I have another issue about extraction of SBK of my bricked Nexus 7. I prepared everything (download of fusee-launcher, pyusb installation ...), checked connection of my device through APX (see below) but when I type sudo ./fusee-launcher.py –tty dump-sbk-via-usb.bin I got :
[email protected]:~/Downloads/fusee-launcher-n7$ lsusb
Bus 002 Device 096: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer
Bus 002 Device 061: ID 0955:7330 NVIDIA Corp.
Bus 002 Device 004: ID 046d:0805 Logitech, Inc. Webcam C300
Bus 002 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
...
[email protected]:~/Downloads/fusee-launcher-n7$ sudo ./fusee-launcher.py --tty dump-sbk-via-usb.bin
sudo: ./fusee-launcher.py : command not found
Sorry to be blocked again.

@enderzip
I found a solution to my issue by allowing the "execution of the file as program" in the permissions of fusee-launcher.py file.
Fusee-launcher started but quickly stopped before application stack dumping : message delivered by fusee-launcher is to use USB 3.0 and I realized that I have only USB 2.0 on my old desk computer.
Does someone know how to patch EHCI driver ? Is it a possible solution ?
Thanks for your advice.

enderzip said:
Yes, i have successfully unbrick my Nexus 7 WITHOUT any type of blob file i have generated before.
And no, you should thank @Jirmd instead of me. If he didn't post his thread, my Nexus is still probably a paperweight.
Click to expand...
Click to collapse
enderzip, wow, you soo good and cool. I am totaly glad for this, how you make your tutorial. And we must give thanks for AndroidRoot team and Jenkinsen. Without this people, we all have only paperweight.
Now, i will try make my moded mknvfblob worked standalone. Without Tegra 3, only on linux X86 PC.
And, i will try make tutorial for nexus 7 , how boot linux from usb, without multiboot. ( For case, when is your internal storage totaly unreparable damaged.)

Deleted.

Thank you Enderzip. I will follow your advice and buy a USB 3.0 PCI Express card and try later.
Again many thanks to you and Jmrd for your tutorial that will enable us to revive our bricked Nexus 7.
Envoyé de mon Nexus 4 en utilisant Tapatalk

I know this might be a stupid question, but what is the boot.img at step 6? The grouper factory image contains a "bootloader-grouper-4.23.img" and a zip containing a "boot.img", I guess that's the file we should flash?

gormatrax said:
I know this might be a stupid question, but what is the boot.img at step 6? The grouper factory image contains a "bootloader-grouper-4.23.img" and a zip containing a "boot.img", I guess that's the file we should flash?
Click to expand...
Click to collapse
The boot.img is inside the .zip inside of the factory image. I think the name is "image-nz---.zip"

Step 5 works and returns the same as in the guide, the tablet shows the google logo, without the battery too low in the corner.
However, at step 6, i get this:
Code:
Nvflash v1.13.87205 started
[resume mode]
command failure: Error querying partition type (bad data)
bootloader status: partition table is required for this command (code: 8) message: nverror:0x5 (0x1000005) flags: 0
what should i do?
edit: for good measure this is the result from step 5:
Code:
Nvflash v1.13.87205 started
Using blob v1.13.00000iles ┼§˛■q
chip uid from BR is: 0x0000000000000000015d25689b3c1019
rcm version 0X30001
System Information:
chip name: unknown
chip id: 0x30 major: 1 minor: 3
chip sku: 0x83
chip uid: 0x0000000000000000015d25689b3c1019
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 4
device config strap: 1
device config fuse: 17
sdram config strap: 0
sending file: testr.bct
- 6128/6128 bytes sent
testr.bct sent successfully
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: test.ebt
- 2146896/2146896 bytes sent
test.ebt sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 0 3
failed executing command 11 NvError 0x120002
command failure: create failed (bad data)
bootloader status: specified device is invalid (code: 6) message: nverror:0x4 (0x4) flags: 0

@enderzip thank you so much for this detailed guide. Now I was able to generate the image (blobs) myself. When flashin the images (blobs), both the ones generated by you and the ones generated by me, following error is received... Could you help on this?
Code:
Wheelie 0.1 - Preflight for nvflash.
Copyright (c) 2011-2012 androidroot.mobi
========================================
Waiting for device in APX mode...
[=] Chip UID: 0x15d16897a500403
[=] RCM Version: 0x30001
[=] CPU Model: Tegra 3
[+] Sending bootloader...
[-] Error 3 sending command
Thanks Steffen

gormatrax said:
Step 5 works and returns the same as in the guide, the tablet shows the google logo, without the battery too low in the corner.
However, at step 6, i get this:
Code:
Nvflash v1.13.87205 started
[resume mode]
command failure: Error querying partition type (bad data)
bootloader status: partition table is required for this command (code: 8) message: nverror:0x5 (0x1000005) flags: 0
what should i do?
edit: for good measure this is the result from step 5:
Code:
Nvflash v1.13.87205 started
Using blob v1.13.00000iles ┼§˛■q
chip uid from BR is: 0x0000000000000000015d25689b3c1019
rcm version 0X30001
System Information:
chip name: unknown
chip id: 0x30 major: 1 minor: 3
chip sku: 0x83
chip uid: 0x0000000000000000015d25689b3c1019
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 4
device config strap: 1
device config fuse: 17
sdram config strap: 0
sending file: testr.bct
- 6128/6128 bytes sent
testr.bct sent successfully
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: test.ebt
- 2146896/2146896 bytes sent
test.ebt sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 0 3
failed executing command 11 NvError 0x120002
command failure: create failed (bad data)
bootloader status: specified device is invalid (code: 6) message: nverror:0x4 (0x4) flags: 0
Click to expand...
Click to collapse
In this case, uss this command instead:
Code:
sudo ./nvflash --setbct --create --configfile <flash.cfg file name> --resume --download 8 boot.img --go
It may or may not work.

enderzip said:
In this case, uss this command instead:
Code:
sudo ./nvflash --setbct --create --configfile <flash.cfg file name> --resume --download 8 boot.img --go
It may or may not work.
Click to expand...
Click to collapse
It doesn't work, it says that --resume must be first in the command. I moved it to the front, but then it said that it needed the bct file:
command:
Code:
nvflash --resume --setbct --create --configfile flash16.cfg --download 8 boot.img --go
result:
Code:
Nvflash v1.13.87205 started
[resume mode]
bct file required for this command
command failure: create failed
I tried passing the testr.bct to it, but it looks even worse:
command:
Code:
nvflash --resume --setbct --create --configfile flash16.cfg --bct testr.bct --download 8 boot.img --go
result:
Code:
Nvflash v1.13.87205 started
[resume mode]
sending file: testr.bct
- 6128/6128 bytes sent
testr.bct sent successfully
failed executing command 12 NvError 0x120002
command failure: create failed (bad data)
bootloader status: module is in invalid state to perform the requested operation
(code: 4) message: nverror:0x8 (0x8) flags: 0
When executing each command, the tablet was showing the Google logo, after performing part 4 step 4.
Note that I also get the error that @steffenm82 is getting when running
Code:
wheelie --blob test.blob
, however that didn't stop the next step from working...

gormatrax said:
It doesn't work, it says that --resume must be first in the command. I moved it to the front, but then it said that it needed the bct file:
command:
Code:
nvflash --resume --setbct --create --configfile flash16.cfg --download 8 boot.img --go
result:
Code:
Nvflash v1.13.87205 started
[resume mode]
bct file required for this command
command failure: create failed
I tried passing the testr.bct to it, but it looks even worse:
command:
Code:
nvflash --resume --setbct --create --configfile flash16.cfg --bct testr.bct --download 8 boot.img --go
result:
Code:
Nvflash v1.13.87205 started
[resume mode]
sending file: testr.bct
- 6128/6128 bytes sent
testr.bct sent successfully
failed executing command 12 NvError 0x120002
command failure: create failed (bad data)
bootloader status: module is in invalid state to perform the requested operation
(code: 4) message: nverror:0x8 (0x8) flags: 0
When executing each command, the tablet was showing the Google logo, after performing part 4 step 4.
Note that I also get the error that @steffenm82 is getting when running
Code:
wheelie --blob test.blob
, however that didn't stop the next step from working...
Click to expand...
Click to collapse
Hmm, have you tried switching the USB port? Maybe the USB cable too.

steffenm82 said:
@enderzip thank you so much for this detailed guide. Now I was able to generate the image (blobs) myself. When flashin the images (blobs), both the ones generated by you and the ones generated by me, following error is received... Could you help on this?
Code:
Wheelie 0.1 - Preflight for nvflash.
Copyright (c) 2011-2012 androidroot.mobi
========================================
Waiting for device in APX mode...
[=] Chip UID: 0x15d16897a500403
[=] RCM Version: 0x30001
[=] CPU Model: Tegra 3
[+] Sending bootloader...
[-] Error 3 sending command
Thanks Steffen
Click to expand...
Click to collapse
Sorry for my late reply, in this case, try skipping to the next step.

I must say that @enderzip guide make my nexus 7 back on it´s feet despite not having previously generated blobs. After some days of research and some nights via PM and FB messenger he managed to bring my Nexus back on. So Yes @GedBlake he managed to unbrick a nexus 7 with no previous generated blobs. But the mentor of this tutorial was @Jirmd. In adittion, thanks to this 2 wonderful persons that make my Nexus 7 back to it´s gold years!!!