Reflashing Nexus 7 in APX mode, Ubuntu, Gentoo(uclibc/dietlibc), TWRP, hard bricked , sbkdetect , sbkcheck , sbk key
At the begining it was a word and the word was 2 bytes and half-nibble.
I have
Nexus 7 (bootloader unlocked), TWRP installed, and Ubuntu installed with
fastboot erase boot
fastboot flash boot raring-preinstalled-desktop-armhf+nexus7.bootimg
fastboot erase userdata
fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img
fastboot reboot
At the beginning it was fully operational ubuntu.
I wanted to compile gentoo with optimized flags and libs - uclibc/dietlibc and to compare benchmarks with ubuntu and android.
Before experimenting I maked full backup of all partitions.
dd if=/dev/mmcblk0p1 bs=8M | nc -l -p 777
and from computer nc 192.168.0.4 777 > p1
I did the same command for p2, p3, p4, p5, p6, p7, p8, p9, boot1, boot0.
And I backuped /dev/mmcblk0 , which contained all those partitions.
I wanted to understand how it structured on the tablet.
In the process of experimenting first sectors from 0 to 64 was zeroed.
I tried to restore the device in APX mode.
Info about device:
On the box:
Nexus7 ASUS 1B/T30L/16/1G/V , CSSN:015d3248bb080218, SN:CBOKBC595625
Model ME370T , Made in China
[greped from dmesg]
Tegra Revision: A03 SKU: 0x83 CPU Process: 2 Core Process: 0
I checked most of the messages from the forum related to reflashing and restoring
soft/hard bricked tablets.
I tried to restore the device with sdk for Tegra3(for Nexus7) from developer site - developer.nvidia.com.
I registered and got SDK - Tegra Android DEveloper Pack 2.0 for windows. Then I tried to run it.
Several big files was created (there are look like files in nakasi-xxx-firmare-xxx) ,
and process stoped at moment of flashing.
Then I tried to reflash the device under linux.
usb-device
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 20 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0955 ProdID=7330 Rev=01.03
S: Manufacturer=NVIDIA Corp.
S: Product=APX
C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=32mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
The easiest way to prepare the device is running
"udevadm monitor" and pressing and holding the button/buttons until You'll see the message
"add" from udevadm.
I founded that the device in my situation, started with any of following combinations
PwrUp/PwrUp+Vol_+/PwrUp+Vol_.
You can check it with
usb-device | egrep "NVIDIA|APX"
I tried to run different nvflash programs and found working one:
Nvflash v1.8.90246 / 1197539 Bytes / md5sum
d0f1fdada0508d77906d89098ad60091 nvflash
I tried
nvflash --rawdevicewrite 0 64 0_64.dat --bl bl --go
to restore zeroed sectors. It not working without correct sbk key.
I sniffed usb data with wireshark for different sbk keys and found this:
Then device is powering
GET DESCRIPTOR / Data / A.P.X
GET DESCRIPTOR / Data / N v i d i a C o r p 0x2e 0x00
SET CONFIGURATION Request
SET CONFIGURATION Response
URB_BULK in
URB_BULK out / Leftover Capture Data / 180208bb48325d01 // this is CSSN from end to beginning
URB_BULK out / Leftover Capture Data / 1028 Bytes -- generated by nvflash using some func(CSSN)
0x04 0x04 0x00 0x00 and 16 bytes and rest is 0x00
URB_BULK in 0x04 0x00 0x00 0x00
URB_BULK out / Leftover Capture Data / 4096 Bytes
When I tried different sbk keys, I got different answers from the device - those 4096 bytes
of leftover_captured_data. I realized then after checking ONE wrong sbk key , I needed to reboot the device (power off/power on).
And I received next messages:
rcm version 0X4
Command send failed (usb write failed)
You can check URB status in wireshark after running nvflash.
If key is wrong , You'll get "Broken pipe" EPIPE.
I tried
nvflash --format_all --go
in the hope that I do not needed sbk key. In
www_patentmaps_com/topic/Handling_of_secure_storage_key_in_always_on_domain_1.html developers told that
In some cases You do not need to know sbk key for reflashing the device .
And I tried manual decryption
# trying to check if decryption is correct with some generated sbk keys
#
#0xF0D1E800 0x74DB0700 0x7C20E402 0x9839F903
openssl aes-128-cbc -K F0D1E80074DB07007C20E4029839F903 -iv 0 -d -in bct.enc -out bct.dcr -nopad
# incorrect sbk key 0xF0D1E80074DB07007C20E4029839F903
bct.dcr suppouse to look like bct structure
if You need to find more info about manual decryption check showthread.php?t=1698560
even if You have correct decrypted buffer and encrypted buffer , AES are not susceptible to
known-plaintext attacks.
Solution 0 ) Send it to ASUS (read the warranty before)
( in my case i still need that sbk key for deleveloping purpose and I hope
that key will be added to sdk)
Solution 1 ) The are couple of algorithms of generating sbk key from CSSN
usualy it a simple formula and we need to guess that constants
Solution 2 ) Reverse engineering of usb protocol.
Part of the code in the device, that responsible for usb protocol can be vulnerable.
ASUS BIOS developers is good, but a chance exist.
This is a new device on the market. My guess - that part of code can be common for
many models - they just recompile that for different models.
This joke for that developers:
If constructors will build the houses , like programers writing the
programs, then the first flying woodpecker will destroy the civilization.
For now, I am checking algorithms of generation of sbk key.
[ I still looking for any infos about generation sbk from CSSN ]
[ I trying to restore formula of generation sbk key from nvflash that I have ]
[ You can help me with posting every nvflash that you have ]
I tried sbkcheck but I get segmentation fault // solution - found the proper
libusb or better ask sbkcheck.c from author and recompile it.
if You can't get sbkcheck.c then analyze sbkcheck
readelf -a ./sbkcheck > sbkcheck._
objdump -d ./sbkcheck > sbkcheck.dump
./sbkcheck: file format elf32-i386
[cutted]
8048d25: a1 84 a4 04 08 mov 0x804a484,%eax
8048d2a: 89 c2 mov %eax,%edx
8048d2c: b8 41 8f 04 08 mov $0x8048f41,%eax [ offset 0x0000f41 in ./sbkcheck ] Error in bulk transfer
8048d31: 89 54 24 0c mov %edx,0xc(%esp)
8048d35: c7 44 24 08 17 00 00 movl $0x17,0x8(%esp)
8048d3c: 00
8048d3d: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp)
8048d44: 00
8048d45: 89 04 24 mov %eax,(%esp)
8048d48: e8 4b fa ff ff call 8048798 <[email protected]>
8048d4d: b8 ff ff ff ff mov $0xffffffff,%eax
8048d52: eb 70 jmp 8048dc4 <main+0x35a>
8048d54: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp)
8048d5b: 00
8048d5c: 8b 44 24 64 mov 0x64(%esp),%eax
8048d60: 89 04 24 mov %eax,(%esp)
8048d63: e8 70 fa ff ff call 80487d8 <[email protected]>
8048d68: 8b 44 24 4c mov 0x4c(%esp),%eax
8048d6c: 3d 01 00 02 00 cmp $0x20001,%eax !!!!! if $0x20001 getted from device !!!!
8048d71: 75 0e jne 8048d81 <main+0x317>
8048d73: c7 04 24 6b 8f 04 08 movl $0x8048f6b,(%esp) [ offset 0x0000f6b in ./sbkcheck ] Detected SBKv2
8048d7a: e8 39 fa ff ff call 80487b8 <[email protected]>
8048d7f: eb 1a jmp 8048d9b <main+0x331>
8048d81: c7 04 24 7a 8f 04 08 movl $0x8048f7a,(%esp) [ offset 0x0000f7a in ./sbkcheck ] Detected SBKv1
8048d88: e8 2b fa ff ff call 80487b8 <[email protected]>
[cutted]
I wanted to find the difference between sbkv1 and sbkv2 and sbkv3.
And I still looking for sources of sbkcheck.c and Sbkdetect.c or latest
sbkcheck/Sbkdetect
I found some info about tegrarcm () - for reflashing with u-boot bootloader but
It does not supported locked devices with an encrypted boot key, only
open devices such as the ventana, cardhu, or dalmore reference boards.
git://nv-tegra.nvidia.com/tools/tegrarcm.git
and good infos at
http_download_nvidia_com/tegra-public-appnotes
developer_download_nvidia_com/tegra
I found patents info:
www_patentmaps_com/topic/Handling_of_secure_storage_key_in_always_on_domain_1.html
Handling of secure storage key in always on domain
and this pdf www_sourceconference_com/publications/bos12pubs/android-modding-source.pdf
SBK of a Tegra device is leaked or predictable
P.S. Sorry for my bad bad English
Forgive my ignorance but what is this?
sgt. meow said:
Forgive my ignorance but what is this?
Click to expand...
Click to collapse
I think he/she is saying he/she wrote some length of zeros to /dev/block/mmcblk0 and is now in possession of a N7 brick.
The rest of it is sort of stream-of-conciousness documentation of efforts to figure out how to rescue it from that situation.
Scary thing is I understand most of what he/she is saying. Quite a bit of effort put in to this, actually.
I hope she/he succeeds. If there is anyone else working on cracking APX/nvflash/tegrarcm, they are doing so silently... so I am happy to see that someone is trying.
After relating the OP with your post, I seem to understand almost half of the post. But nvflash, sbk keys and algorithms are all but a haze to me.
I understood what you meant. It's the devvy bits regarding nvflash that frazzled me. I really do hope you succeed in your attempts.
I am on the same boat as Sgt. Meow, but you mentioned doing a back up of all the partitions. In what format did you do this? Using what? It sounds like you got NVflash to work or at least do something. If that is the case and your backup is a .img then you should be able to push that to mmcblk0p0 and have a working device again.
Sent from my LG-P999 using xda premium
I backuped from running ubuntu.
I added the command to my first message.
And I still retranslating the message to "normal English"
I think You can do it from TWRP.
I still looking for latest sbkcheck.c , Sbkdetect.c
or executable sbkcheck/Sbkdetect
www_cs_tcu_edu/people/professors/publications/sbk-tmc-2008.PDF
We need to find bivariate l-degree polynomial, like in case of Acer Iconia A500 (tegra2)
Impact(repercussion) of moonlight on lamb's testicles in a shadow
@ OP
You should not break the 10 post barrier like this. You can try helping others in other forums. That way you can earn some Thanks too (not that it should matter anyway). Please take it into consideration. That being said, I wish you all the best with your project and hope you succeed.
sgt. meow
Another very helpful info
www.google.com/patents/us20090204803.pdf
plus
http://www.google.com/patents/us20090204803
Ok, so since you used dd to make an image of your chip, you should be able to use NVflash to write that back to mmcblk0. I don't know that reflashing the entire chip has ever been done, but reflashing individual partitions via NVflash has been done and is a great way to de-brick.
Sent from my LG-P999 using xda premium
Волк said:
Ok, so since you used dd to make an image of your chip, you should be able to use NVflash to write that back to mmcblk0. I don't know that reflashing the entire chip has ever been done, but reflashing individual partitions via NVflash has been done and is a great way to de-brick.
Click to expand...
Click to collapse
Someone has reported doing this successfully for a N7?
Link please! (To my knowledge the successes with nvflash and the Asus TF2xx have not been reproduced on the N7)
Волк said:
Ok, so since you used dd to make an image of your chip, you should be able to use NVflash to write that back to mmcblk0. I don't know that reflashing the entire chip has ever been done, but reflashing individual partitions via NVflash has been done and is a great way to de-brick.
Sent from my LG-P999 using xda premium
Click to expand...
Click to collapse
I can restore from backup, when I'll get sbk
As bftb0 said, how can you even use nvflash on the N7's? Can I use the dd command on a working N7 that has CM 10.1 and twrp in apx mode to save the boot partition or the bootloader and also get the sbk?
Is there really any way to retrieve the sbk on a working N7 to date? So far I think everyone has been unsuccessful, and I have posted on several threads about on how to restore by other methods such as jtag? I think even with jtag if I could access it on the mainboard and be able to use it, I would still need complex script/software. I don't think anyone is ever going to be able to figure out how to get nvflash to work on our devices!!
androidfr33k said:
Can I use the dd command on a working N7 that has CM 10.1 and twrp in apx mode to save the boot partition or the bootloader and also get the sbk?
Click to expand...
Click to collapse
osm0sis has a thread / script in these (XDA N7) forums which allows altering lock state of an individual tablet by capturing/writing the bootloader partition using dd as you describe. But the catch is that every device performs this operation in a unique manner combining the sbk with a device serial# to uniquely encrypt/sign the boot loader - so you can not capture it from a working tablet and write it to a different (bricked) tablet.
Also, the sbk is not stored in flash memory - the flash memory is considered to be "untrusted media" by the processor. (That's what the patent documents that the OP provided links to describe)
bftb0 said:
osm0sis has a thread / script in these (XDA N7) forums which allows altering lock state of an individual tablet by capturing/writing the bootloader partition using dd as you describe. But the catch is that every device performs this operation in a unique manner combining the sbk with a device serial# to uniquely encrypt/sign the boot loader - so you can not capture it from a working tablet and write it to a different (bricked) tablet.
Also, the sbk is not stored in flash memory - the flash memory is considered to be "untrusted media" by the processor. (That's what the patent documents that the OP provided links to describe)
Click to expand...
Click to collapse
Can I capture it on my working tablet to use if I brick my tablet (same tablet)? If so then that is a great tool!!
androidfr33k said:
Can I capture it on my working tablet to use if I brick my tablet (same tablet)? If so then that is a great tool!!
Click to expand...
Click to collapse
Yes you may capture it, No it is not for brickings (due to chicken-vs-egg issues).
http://forum.xda-developers.com/showthread.php?t=2068207
The purpose of it is primarily to allow unlocking/relocking of the bootloader without wiping the user data partition.
Since it does this by writing the appropriate partition from a booted kernel (either OS or recovery), it clearly is not for "bootloader got messed up" bricks.
I mentioned it in the context of this thread (it's a little off-topic) because the devs involved had noticed in the course of their work that the binary blob of data for the bootloader is uniquely encrypted for each tablet. This is consistent with the process shown in the (.pdf) Patent filings that the OP provided.
I haven't tried it yet, so I can't vouch for it, but others have (but note the thread date, too - probably before v4.18 boot loader - I also don't know if that is significant or not). Doing this is on my "to do list", though.
Not so long ago I started experiencing severe freezes and lockups on my I9300. The symptoms were well known as pre-SDS lockups. Before SDS workarounds have been released such symptoms would mean a death sentence for the device. While this is not the case any more the freezes still make the phone virtually unusable.
So far the only way to bring the phone back to usability was a full wipe of the device combined with filling the partitions with some data in order to ensure that every sector has been written to. Some have also succeeded to get rid of such behaviour after flashing stock firmware (after having been running AOSP).
Some technical background
The reason for the freezes (at least on my device) were block read errors. This is roughly equivalent to a situation where you HDD starts having bad sectors, however flash memory is a bit different to a magnetic disk drive. The read errors encountered most likely due to data corruption resulting in CRC errors during read. In my case the dmesg (kernel log) showed the following errors:
Code:
[ 5896.313473] c0 mmc0: it occurs a critical error on eMMC it'll try to recover eMMC to normal state
[ 5896.482283] c0 mif: set_hsic_lpa_states: 304: called(exynos4_check_usb_op+0x84/0x100):
[ 5896.482469] c0 mif: set hsic lpa enter: active state (0), pda active (0)
[ 5896.665712] c0 mmc0: Fixing MoviNAND SDS bug.
[ 5896.708336] c0 mmc0: Verifying SDS patch.
[ 5896.794283] c0 mmc0: recovering eMMC has been done
[ 5896.794412] c0 brq->sbc.opcode=23,brq->cmd.opcode=18.
[ 5896.794539] c0 brq->sbc.error=-131,brq->cmd.error=0, brq->stop.error=0,brq->data.error=0.
[ 5896.794789] c0 mmcblk0: unknown error -131 sending read/write command, card status 0x900
[ 5896.795869] c0 end_request: I/O error, dev mmcblk0, sector 21590248
[ 5896.796034] c0 end_request: I/O error, dev mmcblk0, sector 21590256
[ 5896.796182] c0 end_request: I/O error, dev mmcblk0, sector 21590264
[ 5896.796379] c0 CMD aborting case in MMC's block layer ret 0.
[ 5896.796512] c0 mmcblk0: CMD18, ARG=0x14970e8.
[ 5896.796613] c0 packed CMD type = 0.
[ 5896.796700] c0 mmc0, request returns 4.
Instead of doing a full wipe of the device's internal flash memory partitions I've tried out another method. I was looking for a program that would rewrite all the data without actually wiping it. Such operation would cause the data to be written again and additionally the wear levelling algorithm inside the eMMC controller would have the chance to relocate the data to another physical block on the flash memory chip.
It turned out that the program I was looking for is already there - just not fully thought of being the right one to use in such case.
When bad blocks encounter on a HDD on your PC you normally need to scan the whole media and mark all the bad blocks found on the filesystem so that they can no longer be allocated for file storage. On Linux this task is performed by the e2fsck system utility which uses another utility called badblocks to do the scan and report the unusable blocks. It is the latter that is interesting.
Among several options found in the badblocks utility there are three methods for discovering such broken blocks:
- read-only where the program will attempt to read all blocks one-by-one.
- non-destructive read-write in which case the program will for each block: read it, fill it with a pattern and write back the original content.
- destructive write where all blocks will be filled by pattern(s) destroying any existing content.
The two last modes are interesting for the purpose of rewriting your device's memory partitions to get rid of bad blocks.
The non-destructive read-write mode can be used to attempt to recover without wiping the contents of the partition. This is mostly relevant to the /data partition (and possibly /efs) as all other ones can be easily restored. Note however that when a read error occurs the data in that sector is already lost. When you attempt to recover such partition it will appear to be working again, but some apps may be crashing randomly as some of their data is corrupted. The non-destructive read-write mode can also be used to prevent freezes from happening. All you need is to treat the /data partition this way once a while (not too often - every 6 months without a factory reset).
The destructive write mode can be used in case you don't care for the data. This is equivalent to the methods used so far (wiping the partition and filling it with random junk). This mode can also be used to securely* wipe your phone before selling it or giving it away.
* Due to wear levelling this is actually not a secure wipe as some of the data will still persist on the Flash memory chip. However it is secure from a user point of view as the data is no longer visible and recovering it will most likely require advanced and expensive procedures.
Fix and prevent
Rewriting your flash partition data will fix freezes due to bad blocks. However when freezes start to happen this usually means that some data is already unreadable and therefore - lost. In order to refresh the data the non-destructive write test in badblocks can be used periodically to rewrite the data. This will result in a small speedup of your phone.
Important: You must be careful not to rewrite your partition too often as each flash memory block has a limited number of erase cycles (around 100,000 for SLC and 10,000 for MLC chips). Doing this too often will actually damage your chip in the long term making your phone unusable. I believe that rewriting your /data partition every 6 months without a factory reset should prevent any issues. You do not need to do this if you periodically factory-reset your phone as in such case the data is rewritten anyway.
Step-by-step instructions
DISCLAIMER: This may be a dangerous operation if not executed properly. I do not accept any responsibility for damage that it may cause. Please do this on your own risk.
Prerequisites
Before you begin there are some requirements that need to be fulfilled:
A recent backup of your phone. Remember - there are three kinds of people in this world - those who make backups, those who have not yet lost their data and those morons who still refuse to make backups despite loosing data.
SDS-proof recovery. This is true for all recent recoveries these days, but better make sure. The recovery must also allow ADB connections. While this is true for all recoveries, some have problems with it. In my case I couldn't connect to CWM 6.0.4.4 as ADB kept complaining that the connection is unauthorized. Flashing latest Philz Touch (6.00.8 in my case) solved the problem.
ADB installed on your PC. Please search forum or internet to find instructions.
badblocks binary for Android recovery. Since this utility is not included in the recovery by default you need to obtain it elsewhere. The one I've built is attached to this post.
Instructions
These assume we're working on the /data partition. For other partitions please check their corresponding device node and modify the instructions accordingly.
Reboot to recovery.
Do a nandroid backup if not done before.
Connect to your phone using the USB cable.
Run adb push badblocks sbin/badblocks. In case you have just downloaded the attached ZIP file unzip it first to extract the badblocks binary.
Run adb shell to enter a shell on your phone.
Run chmod 0755 sbin/badblocks to make the badblocks binary executable.
Make sure your /data is not mounted. The quick way is to run mount. It will list all mounted filesystems. If /data on /dev/block/mmcblk0p12 is among them you'll need to unmount it by running: umount /data. If it complains about the filesystem being busy you'll need to reboot the phone and enter recovery again. After that repeat all the steps.
Once you are sure that /data is not mounted run: badblocks -b 4096 -n -t 0xFF -s /dev/block/mmcblk0p12. This command is where the main magic happens. What it does is it reads every sector, fills it with 0xFF bytes and then writes back the original data. This way the data is unchanged, but every block gets rewritten. After running badblocks you should see some percentage indicator about the progress. The operation on /data should take around an hour. Observe any errors that may occur. In my case there were none, but if the flash is heavily worn out there may be some unrecoverable sectors.
In case there are no errors everything should be done. Optionally you may want to trim the /data filesystem as all blocks have been rewritten and the eMMC conroller will think that there are no unused blocks on the device. You can do this by mounting the /data filesystem (mount /data) and running fstrim (fstrim -v /data).
You're good to go. Type exit in the ADB shell and reboot your phone into the system.
In case you do not care for the data on the partition you may run badblocks in destructive mode. In such case in step 7 replace "-n" with "-w" in badblocks command line: badblocks -b 4096 -w -t 0xFF -s /dev/block/mmcblk0p12
The same procedure can be repeated for other filesystems (/system, /cache). I would not recommend doing this on the partitions containing the kernel, recovery, efs or bootloader unless you're asking for trouble.
Reserved for future use.
This should seriously be stickied. Works better than using the dummy file generator that everyone recommends.
Actually, if you're getting SDS freeze on patched firmware with V2 fix (XXEMB2+) it is SDS fix recovering bad block. It's even stated in your kernel message.
This method is good if you want to get rid of misc freezes and fix all blocks at once. Because badblocks forces kernel to rewrite all blocks instead of only one/affected block (during normal freeze).
May be useful, but it's not a magic trick. If somebody gets freezes and kernel can't fix it itself then magic badblocks binary won't help him, unfortunately.
I wonder if you could use e2fsck to mark some permanently broken blocks as bad blocks on the filesystem so that they won't be used for filesystem data. A similar thing used to be done on HDDs. The problem that I see here is that the FTL may relocate that block somewhere and it may end up being reused somewhere else and keep doing damage.
I'm really curious how does the eMMC controller on the I9300 handle permanently broken blocks. Does it have some reservoir of usable blocks (like in modern SSD disks) that can be used as a replacement?
KrissN said:
I wonder if you could use e2fsck to mark some permanently broken blocks as bad blocks on the filesystem so that they won't be used for filesystem data. A similar thing used to be done on HDDs. The problem that I see here is that the FTL may relocate that block somewhere and it may end up being reused somewhere else and keep doing damage.
I'm really curious how does the eMMC controller on the I9300 handle permanently broken blocks. Does it have some reservoir of usable blocks (like in modern SSD disks) that can be used as a replacement?
Click to expand...
Click to collapse
This is actually a very good question, I'm wondering as well. If you're clever enough then you may download my latest ArchiDroid 2.X Experimental ROM with built-in debian and try to discover that with native linux gnu utilities.
JustArchi said:
This is actually a very good question, I'm wondering as well. If you're clever enough then you may download my latest ArchiDroid 2.X Experimental ROM with built-in debian and try to discover that with native linux gnu utilities.
Click to expand...
Click to collapse
Desctructive mode? Will that be equivalent to a lets say factory reset? ie losing all user made data.
Wow, this really helped. I am using SM-G355H (not really made with exynos but with sc8830 from spreadtrum but still by samsung) and was afraid that the phone has failed for good. Though the partition failing was the /system/ not the /data/, OP's badblocks build and instructions definitely fixed it, like magic.
Additional note: To identify which partition is failing
Take note of the failing sector, in my case it's at 1879872
Code:
mmcblk0: error -110 transferring data, sector [B]1879872[/B], nr 256, cmd response 0x900, card status 0xb00
and find the partition using the output of this command where /dev/block/mmcblk0 is the block device
Code:
sgdisk --print [B]/dev/block/mmcblk0[/B]
It will print something like:
Code:
Logical sector size: 512 bytes
Disk identifier (GUID): 52444E41-494F-2044-4D4D-43204449534B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7618526
Partitions will be aligned on 512-sector boundaries
Total free space is 21949 sectors (10.7 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 15871 3.8 MiB 0700 FIXNV1
2 15872 23551 3.8 MiB 0700 FIXNV2
3 23552 27647 2.0 MiB 0700 SBL1
4 27648 31743 2.0 MiB 0700 SBL2
5 31744 41983 5.0 MiB 0700 WDSP
6 41984 52223 5.0 MiB 0700 WDSP_BACKUP
7 52224 72703 10.0 MiB 0700 MODEM
8 72704 93183 10.0 MiB 0700 MODEM_BACKUP
9 93184 93695 256.0 KiB 0700 FOTA_SIG
10 93696 110079 8.0 MiB 0700 OTA
11 110080 117759 3.8 MiB 0700 RUNTIMENV1
12 117760 125439 3.8 MiB 0700 RUNTIMENV2
13 125440 131071 2.8 MiB 0700 PARAM
14 135680 176639 20.0 MiB 0700 efs
15 176640 186879 5.0 MiB 0700 prodnv
16 186880 187391 256.0 KiB 0700 Odin_reserved
17 187392 218111 15.0 MiB 0700 KERNEL
18 218112 248831 15.0 MiB 0700 RECOVERY
19 248832 494591 120.0 MiB 0700 CSC
20 494592 2829311 1.1 GiB 0700 system
21 2829312 2890751 30.0 MiB 0700 HIDDEN
22 2890752 7609343 2.3 GiB 0700 userdata
Find the partition whose start and end sectors contain that failing sector. In my case it's the system since
1879872 in within 494592 to 2829311
Code:
20 [B]494592 2829311[/B] 1.1 GiB 0700 system
DISCLAIMER: This guide describes procedures with tools that are designed to write directly to the storage of your device. This has the potential to lead to data loss or bricking your device. If you follow this guide carefully, none of these things should happen. That being said, you are still responsible for your own actions and how you handle the tools mentioned in this guide. Caution is advised.
When do i need this?The following procedure can be used to get your device back into a booting state if all else fails. Usually you'd want to use this tool to get a working recovery running on your device and then go from there. If your bootloader is locked you can use this tool to flash the stock recovery again and unlock the bootloader as ususal.
If that is not sufficient, you can also reflash all of firmware, bootloader and stock recovery.
This guide is not needed if:- The device still boots into stock recovery or TWRP
Flashing the official OxygenOS can fix many issues and you can unlock your bootloader as needed.
- The bootloader is unlocked. Use fastboot flash recovery <twrp image>
Check it with fastboot oem device-info
Use TWRP v3.0.2-0 with the OxygenOS 2 bootloader and the latest TWRP with the OxygenOS 3 bootloader.
- The ROM still boots and is rooted. Flash a stock recovery in a root shell:
adb root && adb shell
dd of=/dev/block/platform/msm_sdcc.1/by-name/recovery if=/sdcard/OxygenOS_recovery.img
OxygenOS 2 Lollipop recovery - OxygenOS 3 Marshmallow recovery
On custom ROMs, you can usually enable root access for ADB in developer settings, even if you didn't root them youself.
If any link is dead, search for it on https://web.archive.org
Spoiler: Verify downloaded files
The OxygenOS recovery links download from OnePlus's official amazon cloud storage. To verify, compare with the OxygenOS download link from the official page. OnePlus no longer links to these files and provides no checksums, you can use these to verify your download:
Code:
de38f20e72da38d48899f14d022cc1b1cd6bff0f4a506adb7bcf0153e73b1934 OPX_recovery.img
2810feb0d87686ea0529d8718600fdf3181cf0c93f0b9e29e5f13004af0e2d84 OPX_MM_recovery.img
e2fb0f0fef7d644cf3e6c1c0699381074fd4a83f64be319b75b9942443a95c90 OnePlusXOxygen_14_OTA_019_all_201611071506_03f73e21449d4d31.zip
fd58d703cf677dc5148ab5dd0f4af6c3df13faeb51166719e17aa192a86a6c0a OPX_UnBrick_Mini_By_Naman_Bhalla.zip
Don't continue unless you actually checked if your bootloader is still unlocked. Sometime it is re-locked on accident if some things go wrong.
Recovery and ROM only boot with a compatible bootloader. If you're not sure, try one then the other.
There are two major versions of the OnePlus X bootloader, one from OxygenOS 2 (Lollipop) and one from OxygenOS 3 (Marshmallow), released ca. September 2016, all newer ROMs should be compatible.
Trying to boot into a ROM or recovery that is incompatible with the installed bootloader will get you stuck on the bootlogo screen. On the OxygenOS 2 bootloader the "Powered by Android" part will disappear.
A locked OxygenOS 2 bootloader will boot any compatible software.
A locked OxygenOS 3 bootloader will only boot software signed by OnePlus. When trying to boot an unsigned ROM or recovery the device will vibrate, splash the bootlogo for a second and reboot, resulting in an endless loop.
If all else fails: Flashing through EDL
You may know the legendary Mega Unbrick Guide for A Hard Bricked OnePlus X by Naman Bhalla but it only works on Windows.
It uses EDL, a hidden Qualcomm interface that allows direct read/write access to the devices flash storage to restore firmware, bootloader and stock recovery.
EDL is a powerful tool. A device in EDL mode will follow all instructions given to it without checking whether it would be a good idea to do so. If the instructions tell your device to overwrite userdata, IMEI or MAC address it will do so. Only flash files that are meant for your device. Don't edit any file unless you know what it does.
Preparation:You need to be at least somewhat familiar with the command line to do this.
- Install git from your distribution
- Download and compile the open source flashing tool QDL. Follow the section "Get the Linux flashing tool" from these instructions.
- Temporarily add QDL to your $PATH with export PATH="$(pwd):$PATH"
QDL must be able to communicate with your device. You can install the appropriate udev rules right now or try it without them first.
- Open a text editor sudo nano /etc/udev/rules.d/51-edl.rules
- Copy these rules and paste them. Ctrl+S to save, Ctrl+X to exit
- The rules should apply the next time you connect your device
- If flashing does not work check the file contents: cat /etc/udev/rules.d/51-edl.rules
- If you can't read the file: sudo chmod a+r /etc/udev/rules.d/51-edl.rules
- If the new rules still don't load for some reason: sudo udevadm control --reload
- Download the "UnBrick tool mini" as uploaded by Naman Bhalla. (direct link)
- Create a clean working directory and extract the zip file.
Customize what to flash:By default, the UnBrick tool mini will flash OxygenOS 2 bootloader, firmware and stock recovery. From there you can flash the latest OxygenOS and unlock your bootloader again for a clean start.
Flashing OxygenOS will always install a compatible bootloader and firmware and OxygenOS will automatically upgrade the recovery during the boot process.
If this is what you want just skip to the next step.
The UnBrick tool will flash config.bin and persist.img and reset these partitions.
Resetting config will re-lock the bootloader.
Resetting persist will require it to be repopulated again. OxygenOS can do this but most Custom ROMs will have broken sensors.
If you don't want to flash certain files, rename them or move them to another directory.
If you only want to flash certain partitions like the recovery, create a new directory, e.g. flash_recovery-only. Download the recovery version you need:
OxygenOS 2 Lollipop recovery - OxygenOS 3 Marshmallow recovery
Copy it to the new directory and rename it to recovery.img to match the filename the UnBrick tool uses.
Additionaly, copy these files from the UnBrick tool:
gpt_main0.bin
gpt_backup0.bin
patch0.xml
prog_emmc_firehose_8974.mbn
rawprogram0.xml
Main procedure:
cd to the directory with the files from the UnBrick tool. Go to your custom directory if you created one in the previous step.
Run qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml
QDL will wait for your device to connect.
If QDL asks for permissions go back to "Preparation" and install the udev rules.
With the OnePlus X powered off hold VolUp and connect it to the PC. Otherwise, connect it to the PC first and hold Power+VolUp until it connects in EDL mode.
To verify the connection you can check lsusb or sudo dmesg -w
Devices in EDL mode show up with idVendor=05c6 and idProduct=9008, usually as Product: QHSUSB__BULK
lsusb example: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
To filter the output: lsusb -d 05c6:9008
QDL should print several lines of output, reporting what is flashed etc.
Once it's done, QDL will kick your device out of EDL mode. If everything is alright your phone should vibrate and boot to the charging screen. You should be able to boot to recovery now.
Congratulations on unbricking your device on a Linux machine, enjoy.
Changelog:
2019-12-12 - Original post
??? - undocumented edits
2020-05-24 - Fix possible execution of QDL without patch0.xml which would break the partition table
2022-09-05 - Fix unnessesarily confusing instructions
Thanks
I have a new TWRP on my OPX, but I don't really know what to change in the rawprogram0.xml file.
emilianoheyns said:
I have a new TWRP on my OPX, but I don't really know what to change in the rawprogram0.xml file.
Click to expand...
Click to collapse
I'm not sure if i correctly understood your situation so i am going to assume the folloing:
- You are running a Linux based operating system on your desktop computer
- You have downloaded all necessary files as mentioned in the guide and successfully compiled qdl
- You want to use modern (newer than 2016) ROMs and the current OnePlus firmware and bootloader, i.e. from OxygenOS 3.1.4
- On your OnePlus X, you have "the old bootloader" installed, that is firmware prior to OxygenOS 3 (based on Marshmallow), i.e. firmware from OxygenOS 2.2.1 or similar
- Additionally, you accidentaly flashed TWRP version 3.0.2-1 or newer to your OnePlus X and rebooted into a soft-bricked state
If these assumptions are correct, i suggest as the easiest solution to reflash a compatible TWRP and update your firmware using that version of TWRP. If you can use your recovery, it is almost always the easiest method to make any remaining modifications in the recovery.
The procedure is as follows:
- From https://dl.twrp.me/onyx/, download TWRP version 3.0.2-0 and 3.3.1-0
- Reflash an old version of TWRP that is compatible, i.e. anything version 3.0.2-0 and below.
Once you flashed TWRP in one way or another, continue with the following steps to update your bootloader:
- Reboot to that version of TWRP to see if you succeeded
- In TWRP, install either one of the following to update your firmware:
- The official OxygenOS 3.1.4 zip downloaded from OnePlus via https://www.oneplus.com/support/softwareupgrade- Only the firmware by following this guide: https://forum.xda-developers.com/oneplus-x/general/guide-update-bootloader-firmware-to-t347891766- Copy to your device: twrp-3.3.1-0-onyx.img and the installation zip you chose in the previous step
- Flash the zip in TWRP. Once TWRP is done flashing, immediately flash a version of TWRP 3.0.2-1 or later to recovery
- In TWRP, choose Reboot > Recovery. If your OnePlus X reboots to TWRP, everything went good and you can go on to flash roms and anything else like you're used to. Just note that very old ROMs (like from 2016 and before) will no longer boot on your device, but you can revert your Firmware by flashing the follwing zip: https://forum.xda-developers.com/oneplus-x/general/zip-recovery-flashable-firmware-radio-t3381420
Just remember that immediately after flashing this zip in TWRP, you have to flash TWRP version 3.0.2-0 or older again.
Now, there are some differnt cases that affect how TWRP initially needs to be flashed:
1. Your OnePlus X bootloader is not locked
(tested by running "fastboot oem device-info" on your desktop while your phone is connected in fastboot mode)
If your bootloader is still unlocked you can avoid the hassle of using qdl and simply resort to "fastboot flash recovery <recovery image file>" to fix your device.
2. Your ROM still boots and that ROM is rooted.
In this situation you can still avoid going through the hassle of using qdl.
All you need to do is to get a root shell running. There are several ways to achieve this:
- In a Terminal Emulator on the device run the command "su"
- On a desktop with your phone connected with adb enabled:
- Run either "adb root" and then "adb shell"
- Or run "adb shell" and within that shell, run "su"
Once you got the shell running you can flash your recovery with
"dd of=/dev/block/bootdevice/by-name/recovery if=/sdcard/twrp-3.0.2-0-onyx.img"
To get the image to your device if downloaded on your desktop you can use "adb push twrp-3.0.2-0-onyx.img /sdcard/"
3. Your ROM does not boot or is not rooted.
This is the case where you absolutely need qdl and the situation i assume you are in.
Once you downloaded and unpacked the package from Naman Bhalla, you should see a directory containing the rawprogram0.xml and prog_emmc_firehose_8974.mbn files and a lot of others. You can take just the rawprogram0.xml and the prog_emmc_firehose_8974.mbn file and copy them to your working directory for the next steps.
Now, open rawprogram0.xml in a text editor. Search for the string "recovery". You will see a line starting with "<program" and ending in "/>". In your case, only the line containing " label="recovery" " and " filename="recovery.img" " is relevant. Remove all other lines starting with "<program" and save. Optionally, rename the file to "program-onyx-recovery.xml" or something you will recognize. This might be useful if you plan to keep the file and use it again in the future.
Now, optionally change filename="recovery.img" to the file name of your TWRP file or just rename your downloaded TWRP file to "recovery.img".
To flash, make sure that the following files are in your working directory:
- prog_emmc_firehose_8974.mbn
- rawprogram0.xml (but your customized version)
- recovery.img (whatever recovery you want to flash)
If that is settled, run qdl as explained in my initial guide in the original post to flash the recovery file.
Edit 2022-09-04: This whole paragraph only applies to the OxygenOS 2 bootloader. A locked OxygenOS 3 bootloader will only boot a signed ROM or a signed recovery. However, the device storage can always be dumped through EDL and the final point about encryption always applies.
Some final remarks on locked bootloader on the OnePlus X:
For the future, remember to just keep your bootloader unlocked. It can save you a lot of hassle.
And if you feel uncomfortable about walking around with an unlocked bootloader:
Re-locking the bootloader while TWRP is installed doesn't give any security benefit at all (for obvious reasons). Even if your Recevery would not be open to any local attacker, a locked bootloader doesn't give you much of a benefit on the OnePlus X.
Yes, the generic attac surface of simply using "fastboot flash" is gone, but remember how easy it is to find the UnBrick tool for the OnePlus X we used in this guide. Any attacker can use it as well to flash a malicious recovery onto your device, even if your bootloader is locked - and your OnePlus will boot it.
This is because the OnePlus X does not support Android Verified Boot. This is a security feature on newer Android devices that prevents booting unsigned software if the bootloader is locked. This can prevent flashing malicious firmware, OS or revovery onto a device. But since it also prevents booting TWRP you'd likely be walking around with an unlocked bootloader anyway even if your device were to support this security feature.
Funnily enough, this leads to the conclusion that running your OnePlus X with stock OxygenOS, Recovery and locked bootloader is about as insecure as running TWRP and having an unlocked bootloader if we are talking about an attacker with physical access to the device who also knows about this tool. And since such a tool exists for pretty much every android device as it is originally used to flash these devices in their factories and can be publicly found for most devices, it can be assumed that any attacker has access to this tool.
So remember, the only protection you can have on a OnePlus X is encrypting your data with a strong passcode and hoping that your data stays private even if you might lose your device.
I have no problems with having an unlocked bootloader -- I thought this device had one already. Yesterday it was running TWRP3.0.2-1 and LOS Marshmellow, I just screwed it up trying to upgrade it to an unofficial LOS16. It would first bootloop constantly, then I tried QDL, and now it doesn't even seem to turn on; I can hold the power button for a full minute but the screen remains black, and there's no vibration as I'm used to. It does show up in QDL mode; I tried the procedure as per point 3, using twrp-3.0.2-1 as the recovery image. QDL says:
Code:
HELLO version: 0x2 compatible: 0x1 max_len: 1024 mode: 0
READ image: 13 offset: 0x0 length: 0x50
READ image: 13 offset: 0x50 length: 0x1000
READ image: 13 offset: 0x1050 length: 0x1000
READ image: 13 offset: 0x2050 length: 0x1000
READ image: 13 offset: 0x3050 length: 0x1000
READ image: 13 offset: 0x4050 length: 0x1000
READ image: 13 offset: 0x5050 length: 0x1000
READ image: 13 offset: 0x6050 length: 0x1000
READ image: 13 offset: 0x7050 length: 0x1000
READ image: 13 offset: 0x8050 length: 0x1000
READ image: 13 offset: 0x9050 length: 0x1000
READ image: 13 offset: 0xa050 length: 0x1000
READ image: 13 offset: 0xb050 length: 0x1000
READ image: 13 offset: 0xc050 length: 0x1000
READ image: 13 offset: 0xd050 length: 0x1000
READ image: 13 offset: 0xe050 length: 0x1000
READ image: 13 offset: 0xf050 length: 0x1000
READ image: 13 offset: 0x10050 length: 0x1000
READ image: 13 offset: 0x11050 length: 0x1000
READ image: 13 offset: 0x12050 length: 0x1000
READ image: 13 offset: 0x13050 length: 0x1000
READ image: 13 offset: 0x14050 length: 0x890
END OF IMAGE image: 13 status: 0
DONE status: 0
qdl: failed to read: Connection timed out
LOG: Host's payload to target size is too large
LOG: [email protected] [email protected]
LOG: [email protected] [email protected]
LOG: [email protected] [email protected]
LOG: start 1409024, num 31680
LOG: Finished sector address 1440704
[PROGRAM] flashed "recovery" successfully at 3960kB/s
no boot partition found
but the OPX still won't boot.
Is your bootloader actually unlocked?
The OnePlus X ships with a locked bootloader that prevents flashing files to the device using fastboot.
The usual steps to modify the OnePlus X and installing custom ROMs are:
- Unlock the bootloader by running "fastboot oem unlock" on a desktop PC while the phone is connected in fastboot mode.
- Flash TWRP by running "fastboot flash recovery TWRP.img" on a desktop PC while the phone is connected in fastboot mode.
Pressing the volume up button while turning on the device normally puts it into fastboot mode and "Fasboot Mode" will be displayed in the middle of the screen along with the oneplus logo.
Unlocking only works with the original OnePlus recovery and if the option "Allow OEM unlocking" is checked in the developer settings. Unlocking requires wiping all userdata.
Did you never do this yourself with your OnePlus X? Did you get this device as a used phone from someone else who already unlocked the bootloader?
What do you mean by "bootloop constantly"? Could you not boot the recovery?
Are you saying you already ran QDL with the unmodified files from the UnBrick tool?
If you really had TWRP 3.0.2-1 running before all your problems started, then doing so initially soft-bricked your device to begin with, as i outlined in footnote [1] of my original post.
I am not sure of the precise timeline and order of your descriptions. I currently assume that you're saying:
1. Had a working device with ROM: "LineageOS 13.0" Recovery: "TWRP version 3.0.2-1" Firmware: Unknown
2. Flashed some "lineage-16.0-unofficial.zip" in TWRP
3. When rebooting, "bootloops" appeared [How did that look? What was affected - just ROM or recovery as well?]
4. Run QDL with the unmodified files from the UnBrick tool that is linked in my original post
5. Phone does not react to button presses except when putting into EDL mode
6. Run QDL with recovery only as described in Point 3 of my follow up post, with the image file of TWRP version 3.0.2-1, QDL repoted success
7. Still not booting [What exactly does this mean? Still no reaction to button presses? Dees the phone vibrate and bring up the OnePlus logo?]
I've followed the mentioned steps and Im still stuck on linux logo..
I desesperately need help, bought a bricked second hand Oneplus X which I know nothing of in terms of past actions but previous owner
BolitaBolita said:
I've followed the mentioned steps and Im still stuck on linux logo..
I desesperately need help, bought a bricked second hand Oneplus X which I know nothing of in terms of past actions but previous owner
Click to expand...
Click to collapse
If you did not modify any files from the unbrick tool by Naman Bhalla and qdl ran through sucessfully, it should have flashed a compatible combination of bootloader and stock recovery so you should be able to reboot to that one.
If this is not the case, you can also go with flashing just a TWRP image. Since there are really just two possible versions of the bootloader (at least in regards to booting compatibility) this should succeed after the second try at most. If not, it means that some other stuff might be broken as well.
As i wrote in my OP, for the OnePlus X any TWRP v3.0.2-0 or older is compatible with the "old bootloader" (Lollipop) and any TWRP v3.0.2-1 or newer is compatible with the "new bootloader" (Marshmallow).
What you basically want to achieve is to just get any recovery booting (be it Stock, TWRP, orangefox or any other useful recovery). From that point, it is fairly easy to get anywhere else on the OnePlus X.
As for other things that can break:
Most of the partitions in your device can be restored to an intact state by flashing an official OxygenOS zip (https://www.oneplus.com/support/softwareupgrade). There are some other ways but this is the safe and easy method.
Only a few partitions cannot be restored once tampered, since they are unique to the specific device. If this happens to be the case, then it can be fairly hard to fix. If the previous owner had unlocked the devices bootloader and flashed some stuff on it, you should ask them whether they might have some TWRP backups around, namely of the partitions "Persist" and "EFS".
SebiderSushi said:
If you did not modify any files from the unbrick tool by Naman Bhalla and qdl ran through sucessfully, it should have flashed a compatible combination of bootloader and stock recovery so you should be able to reboot to that one.
If this is not the case, you can also go with flashing just a TWRP image. Since there are really just two possible versions of the bootloader (at least in regards to booting compatibility) this should succeed after the second try at most. If not, it means that some other stuff might be broken as well.
As i wrote in my OP, for the OnePlus X any TWRP v3.0.2-0 or older is compatible with the "old bootloader" (Lollipop) and any TWRP v3.0.2-1 or newer is compatible with the "new bootloader" (Marshmallow).
What you basically want to achieve is to just get any recovery booting (be it Stock, TWRP, orangefox or any other useful recovery). From that point, it is fairly easy to get anywhere else on the OnePlus X.
As for other things that can break:
Most of the partitions in your device can be restored to an intact state by flashing an official OxygenOS zip (https://www.oneplus.com/support/softwareupgrade). There are some other ways but this is the safe and easy method.
Only a few partitions cannot be restored once tampered, since they are unique to the specific device. If this happens to be the case, then it can be fairly hard to fix. If the previous owner had unlocked the devices bootloader and flashed some stuff on it, you should ask them whether they might have some TWRP backups around, namely of the partitions "Persist" and "EFS".
Click to expand...
Click to collapse
Thank you for your reply SebiderSushi.
The only option I have in terms of recovery booting is the Oneplus original one since I bought the phone bricked (can't access dev options and can't connect through ADB for oem unlock).
I've managed to unlock the bootloader and tried to flash the official OsOxygen zip. The update stopped halfway and the phone bricked once again.
I've tried the Naman Bhalla unbrick tool with the MSMdownloadtool 2.1 (previously attempted 2.0). The process runs successfully, until its marked in green 'download complete'. Phone still bricked.
I'm currently attempting with QFIL through this thread https://www.droidsavvy.com/unbrick-qualcomm-mobiles/
Drivers correctly installed, port 9008 is detected and QFIL is currently. I'm using the files from the unbrick tool by Naman Bhalla for this. The output is the following:
Process Index:0
Programmer Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
Image Search Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla
Please select the XML file
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:2
Start Sending Programmer
Sending Programmer Finished
Switch To FireHose
Max Payload Size to Target:49152 Bytes
Device Type:eMMC
Platform:8x26
Disable Ack Raw Data Every N Packets
Ack Raw Data:False
Skip Write:False
Always Validate:False
Use Verbose:False
COM Port number:3
Sending NOP
FireHose NOP sent successfully
Sending Configuration
Device Type:eMMC
Platform:8x26
Request payload size 0xc000 is not the same as support payload size, change to 0x20000
Set TxBuffer 0x20000, RxBuffer 0x4000
Firehose configure packet sent successfully!
Total Bytes To Program 0x62AE4A0
Download Image
PROGRAM: Partition 0, Sector: 0, Length: 33 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\gpt_backup0.bin
PROGRAM: Written Bytes 0x4200 (64)
Program Size: 0.02 MB
PROGRAM: Partition 0, Sector: 0, Length: 34 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\gpt_main0.bin
PROGRAM: Written Bytes 0x4400 (64)
Program Size: 0.02 MB
PROGRAM: Partition 0, Sector: 1609554, Length: 1024 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\config.bin
PROGRAM: Written Bytes 0x80000 (64)
Program Size: 0.50 MB
PROGRAM: Replace the partition sectors number 0x8000 to file size in sector 0x254
PROGRAM: Partition 0, Sector: 1460242, Length: 596 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\logo.bin
PROGRAM: Written Bytes 0x4a800 (64)
Program Size: 0.29 MB
PROGRAM: Replace the partition sectors number 0x8000 to file size in sector 0x74f0
PROGRAM: Partition 0, Sector: 1409024, Length: 29936 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\recovery.img
PROGRAM: Written Bytes 0xe9e000 (64)
Program Size: 14.62 MB
PROGRAM: Replace the partition sectors number 0x10000 to file size in sector 0x26a3
PROGRAM: Partition 0, Sector: 294912, Length: 9891 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\persist.img
PROGRAM: Written Bytes 0x4d4600 (64)
Program Size: 4.83 MB
PROGRAM: Partition 0, Sector: 259048, Length: 20480 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\static_nvbk.bin
PROGRAM: Written Bytes 0xa00000 (64)
Program Size: 10.00 MB
PROGRAM: Partition 0, Sector: 238568, Length: 20480 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\dynamic_nvbk.bin
PROGRAM: Written Bytes 0xa00000 (64)
Program Size: 10.00 MB
PROGRAM: Replace the partition sectors number 0x3e8 to file size in sector 0x28d
PROGRAM: Partition 0, Sector: 229376, Length: 653 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\tz.mbn
PROGRAM: Written Bytes 0x51a00 (64)
Program Size: 0.32 MB
PROGRAM: Replace the partition sectors number 0x3e8 to file size in sector 0x174
PROGRAM: Partition 0, Sector: 182272, Length: 372 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\rpm.mbn
PROGRAM: Written Bytes 0x2e800 (64)
Program Size: 0.18 MB
PROGRAM: Replace the partition sectors number 0x800 to file size in sector 0x380
PROGRAM: Partition 0, Sector: 180224, Length: 896 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\emmc_appsboot.mbn
PROGRAM: Written Bytes 0x70000 (64)
Program Size: 0.44 MB
PROGRAM: Replace the partition sectors number 0x40 to file size in sector 0x17
PROGRAM: Partition 0, Sector: 148480, Length: 23 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\sdi.mbn
PROGRAM: Written Bytes 0x2e00 (64)
Program Size: 0.01 MB
PROGRAM: Replace the partition sectors number 0x400 to file size in sector 0x22d
PROGRAM: Partition 0, Sector: 147456, Length: 557 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\sbl1.mbn
PROGRAM: Written Bytes 0x45a00 (64)
Program Size: 0.27 MB
PROGRAM: Replace the partition sectors number 0x20000 to file size in sector 0x1c983
PROGRAM: Partition 0, Sector: 16384, Length: 117123 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\NON-HLOS.bin
PROGRAM: Written Bytes 0x3930600 (64)
Program Size: 57.19 MB
Total Size: 98.68 MB
Total Size: 28 Seconds
Throughput: 3.52 MB/Seconds
PATCH: Partition 0, Sector: 9, Offset 40 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 40 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 32 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 24 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 72 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-33.
PATCH: Partition 0, Sector: 1, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(2,4096)
PATCH: Partition 0, Sector: 0, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-33.,4096)
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(1,92)
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-1.,92)
Total download file size: 98.68066MB
Throughput: 3.524309M/s
Reset Phone
Waiting for reset done...
Download Fail:FireHose Fail Fail to find QDLoader port after switch
Finish Download
BolitaBolita said:
The only option I have in terms of recovery booting is the Oneplus original one since I bought the phone bricked (can't access dev options and can't connect through ADB for oem unlock).
Click to expand...
Click to collapse
Now what exactly do you even mean when you say "Bricked"?
If you can boot into recovery, then your device is usually not bricked, but even if, it is usually not in a state where using a flashing tool and risking to **** up the device for good has any real advantage over solving whatever problem in the recovery.
As long as your device doesn't have any hardware errors (broken storage) then the official OnePlus Recovery should almost always be able to install the official OxygenOS.
Under what terms did you even buy this device? How did the previous owner describe the state of the device and its defects if they mentioned them?
BolitaBolita said:
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\config.bin
Click to expand...
Click to collapse
You are using windows, so how did you even end up in this thread?
Sorry for the delay -- I thought I had set up notifications and didn't want to push on the point until you had time, but I did not receive a notification for this.
SebiderSushi said:
Is your bootloader actually unlocked?
The OnePlus X ships with a locked bootloader that prevents flashing files to the device using fastboot.
The usual steps to modify the OnePlus X and installing custom ROMs are:
- Unlock the bootloader by running "fastboot oem unlock" on a desktop PC while the phone is connected in fastboot mode.
- Flash TWRP by running "fastboot flash recovery TWRP.img" on a desktop PC while the phone is connected in fastboot mode.
Click to expand...
Click to collapse
I had a LineageOS running on the OPX before I screwed up an upgrade of LOS. I had TWRP on the phone. The bootloader must be unlocked then yes?
SebiderSushi said:
Pressing the volume up button while turning on the device normally puts it into fastboot mode and "Fasboot Mode" will be displayed in the middle of the screen along with the oneplus logo.
Click to expand...
Click to collapse
broadly, that is what I had done before, but right now I don't even get the fastboot logo.
SebiderSushi said:
Unlocking only works with the original OnePlus recovery and if the option "Allow OEM unlocking" is checked in the developer settings. Unlocking requires wiping all userdata.
Click to expand...
Click to collapse
Right, but I had passed that station before, as it was running LOS.
SebiderSushi said:
Did you never do this yourself with your OnePlus X? Did you get this device as a used phone from someone else who already unlocked the bootloader?
Click to expand...
Click to collapse
No, I did all this myself, but screwed up the update to a non-official LOS.
SebiderSushi said:
What do you mean by "bootloop constantly"? Could you not boot the recovery?
Click to expand...
Click to collapse
I could not, no, but now I'm not even getting the fastboot logo
SebiderSushi said:
Are you saying you already ran QDL with the unmodified files from the UnBrick tool?
Click to expand...
Click to collapse
Correct, yes.
SebiderSushi said:
I am not sure of the precise timeline and order of your descriptions. I currently assume that you're saying:
1. Had a working device with ROM: "LineageOS 13.0" Recovery: "TWRP version 3.0.2-1" Firmware: Unknown
2. Flashed some "lineage-16.0-unofficial.zip" in TWRP
3. When rebooting, "bootloops" appeared [How did that look? What was affected - just ROM or recovery as well?]
Click to expand...
Click to collapse
Initially I could get to recovery, I tried to upgrade to the latest TWRP for the OPX, when I tried to restart that to recovery, it would just vibrate and reboot continuously
SebiderSushi said:
7. Still not booting [What exactly does this mean? Still no reaction to button presses? Dees the phone vibrate and bring up the OnePlus logo?]
Click to expand...
Click to collapse
Currently, the screen stays black, and I can hold volume up or power for 20 seconds with no reaction (no vibrate, no logo)
First off, i'm extremely sorry for my delay! I also happened to notice your message just today.
Right now i got around and tried reproducing your scenario on my own OnePlus X.
As you said that you ran the unmodified setup from the unbrick tool according to my guide, i did as well - and ran into the same issue you were describing.
After some fiddling around, i realized that you must supply the patch0.xml file as well for a complete flash on the OnePlus X when you also modify the GPT (partition table), which the unmodified rawprogram0.xml does. This is not the case if you only install a recovery or other individual partitions so it slipped my mind. I deeply apologize for not testing the command line for the unmodified UnBrick tool package well enough while writing my Guide.
If nothing else is wrong, running
"/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml"
with the unmodified UnBrick tool will fix the device back to a booting state with the stock recovery and Lollipop Bootloader installed on the device., it did so in my case.
Alternatively, if you don't want to reflash all partitions from the package, you can also just try running
"/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn patch0.xml"
Short of any good documentation, i guessed that the problem appeared because the unmodified rawprogram0.xml also writes the GPT table in its last two program elements. If you look in patch0.xml, you can see that it takes care of the GPT in some way. Once i removed the two program items regarding the GPT, rawprogram0.xml could be applied without needing to flash patch0.xml together with it.
So i assume that it is safe to individually flash any partition listed it rawprogram0.xml apart from the GPT. If your GPT is not in a valid state, there's not much booting going on, since your device won't be able to even read your bootloader from the disk without a partition table.
emilianoheyns said:
I had a LineageOS running on the OPX before I screwed up an upgrade of LOS. I had TWRP on the phone. The bootloader must be unlocked then yes?
Click to expand...
Click to collapse
While this implies that you very likely once had an unlocked bootloader to allow installation of TWRP to your device, it is not necessarily the case. For one, it is possible to re-lock the bootloader on the OnePlus X and still boot and use custom recoveries and software. Only flashing images via fastboot becomes impossible again if you relock the bootloader. This is because the OnePlus X is a fairly old device (remember it came out with android 5.1). Such old devices don't support features like Android Verified Boot yet. This is the standard on modern android devices and it implies that a locked bootloader should only load and boot untampered system partitions as signed by the device vendor.
Edit 2022-09-04: I was wrong about this. This only applies to the OxygenOS 2 bootloader. Trying to boot an unsigned ROM or recovery with an unlocked OxygenOS 3 bootloader causes the exact symptoms that were described; The bootloader repeatedly tries booting in an infinite loop. Probably the LOS fash that went wrong caused the bootloader to re-lock, which is why rebooting to recovery didn't work afterwards as well as booting the ROM.
Also, qdl (or any othe software using the Qualcomm Emergency Download Mode) can also install custom Recoveries or ROMs to the devices without unlocking the bootloader and flashing stuff through fastboot.
After that, you can also boot back into fastboot mode and the run
fastboot oem device-info
from your computer to check if your devices bootloader is currently unlocked or not. If it is not, this is a perfect chance to unlock it, since you already got the official recovery installed and probably no user data to take care of anyway.
Hi, thanks for getting back to me. The problem I'm facing currently is that the OPX currently seems unresponsive -- the screen stays black, and no vibration, seemingly regardless of what button combination I use or how long I keep it on the charger. Any idea what key combo is most likely to bring it up in a state that QDL would see it?
I have fetched a fresh copy of OPX_UnBrick_Mini_By_Naman_Bhalla; I'm sorry to have to ask again, but I should then copy over prog_emmc_firehose_8974.mbn, rawprogram0.xml and patch0.xml unchanged, and run `/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml`? I think I'd prefer to get it back to a booting state to then figure out what I can safely flash on it.
---------- Post added at 04:35 PM ---------- Previous post was at 04:30 PM ----------
I should note, if I connect the charger, the red charging light comes on for a second, maybe two, end then goes out again. It does not come back on unless I plug in again, even if I let it charge overnight.
In my case the usual route to enter EDL mode worked fine - that is, disconnect your OnePlus X from any power source for a few seconds, then press and hold the Volume Up button and after a few seconds reconnect it to your PC where you run qdl, then release the button and execute qdl.
If you want to flash the default confuguration of the unbrick tool you must open your terminal window in the folder you extracted from the download (or cd to it). This is because the files that are flashed to the device are in this folder as you caj see and they are being referenced with relative paths / their filenames from within "rawprogram0.xml".
SebiderSushi said:
In my case the usual route to enter EDL mode worked fine - that is, disconnect your OnePlus X from any power source for a few seconds, then press and hold the Volume Up button and after a few seconds reconnect it to your PC where you run qdl, then release the button and execute qdl.
Click to expand...
Click to collapse
Ah well, it must have died somewhere along the way then. When I do that, even after having it on the charger, nothing shows up in dmesg. Thanks in any case!
I wouldn't give up just yet. The actual rule for entering EDL mode on the OnePlus X is:
- The device must be powered off at the beginning
- The Volume Up button must be in pressed state when connecting it to the computer
Edit 2022-09-04: I was wrong about this. It is also possible to hold Power+Vol Up while connected to the PC until the device shows up in dmesg -w
Everything else, like waiting few seconds here and there is mostly safeties to ensure each state is entered or recognized cleanly.
I mostly had my phone running fresh from the last flashing process, which means that qdl had turned it off cleanly for me. So i definitely had good conditions to enter EDL mode.
I don't know what's going on with your notification LED since i didn't notice this on my device or payed any attention to it - but it might indicate that your phone could be in a not cleanly powered off state.
You can still try pressing the power button for a longer time (maybe about 10 to 30 seconds) to see if that switches off your device the right way before you retry entering EDL mode.
Or do any other experiments pressing buttons or try with different cables.
When was the last time you could successfully connect your device in any mode and which mode was it?
The symptoms you described about black screen, no vibrations or any reaction to button presses were also present on my device as well so this is i'd guess it's just normal for the state.
If you get it back to a booting state you should be able to install the official OxygenOS right from the stock recovery, or flash a compatible TWRP image using qdl or fastboot and copy any remaining data that you want to keep.
@SebiderSushi, could you please take a look at >this post< and hint if anything else can be done using edl on linux?