Database Info

Unbricking D6603?

Hi,
First I expect my post is in the right section.
I would like to work on a unbricking process for the sony xperia Z based MSM8974AC phones.
I read a lot of posts about LG nexus 5 and other phones based on the same soc, which, in a bricked state, present himself in a "QD Loader 9006" under windows. Also some other devices, under ubuntu, are external storage attached (emmc directly on /dev/sdb)
What I have understand:
when the emmc is corrupt (but not fried) a rom, somewhere, had basics to present the device to the computer and interact with this loader.
With this loader, the computer should load a emergency hex into ram. Then the phone should be recognized as "QD Loader 9008" under windows. At this step the emergency loader is able to 'serial flash'/'jtag-flash' over usb the emmc.
This process had been applied to the z1 (rhine based board) but, AFAIK, not yet on the shinano.
With some research I found the emergency mode on z3 is hidden, it can only be activated with the testpoint. (Are this one the right one? )
Also on every posts I found, the emergency msm8974.hex loaded into ram is device specific. As I have a working d6603 is there a way to extract it? Where can we found it? (I won't break/open my device!)
Another point is the TA partition. The other unbricking guide I found never had TA partitions. I know our boot choinload is signed:
munjeni said:
PBL is first in bootchain and without hacking them first we have no chance since whole bootchain is signed!
Click to expand...
Click to collapse
If you check in the ta partitions they are qualcomm and other sony certificates.
Code:
strings TA.emmc.win| grep -i x509
Do you think this certificates are used to sign the chainload? If not where are they stored? (somewhere I read the famous rom with the SPL reside is OTP).
As my goal is to reflash a full emmc (in case of corrupt gpt partition table for example) a ta backup could be enough?
Last think: I plan to buy a xperia to dev on this but it is really expensive for my (about 80$) so my progress on this can be really slow.....
Sorry for long post but I would be the more accurate possible
What do you think about it? Is there any chance to get an working unbricking process?
P.S.: for reference.

No idea if this is useful info but here goes:
On some devices, i.e. Xiaomi , you get into the Qloader Mode if alle Partitions on the EMMC are deleted. I had the impression that this is similar to the starting point of a newly produced device which has not been flashed with any ROM and thus only offers the "naked" emmc.

Bäcker said:
No idea if this is useful info but here goes:
On some devices, i.e. Xiaomi , you get into the Qloader Mode if alle Partitions on the EMMC are deleted. I had the impression that this is similar to the starting point of a newly produced device which has not been flashed with any ROM and thus only offers the "naked" emmc.
Click to expand...
Click to collapse
Really interesting!
Also I'm following a thread about swapping emmc on a nexus 5 (also snapdragon 801) and they are able to reflash full emmc.
From your xiaomi information I found this post, and this post. But somewhere i read that our shinano boards can't be placed in disaster recovery without a test-point. (here for the z1).
I'm currently discussing with a z3c seller it could be interresting if i can test on a shinano device!
Also, all the xperia bootchain is signed. So what is happening if we start with a empty emmc? Afaik there is a special tag in the GPT header which contain a hash. Could it be the bootchain signature?

First, yes:
xxlsm said:
they will have no possibility to move back to stock or to send the phone to Sony for warranty reasons (because of the unlocked bootloader and missing origin TA partition)
Click to expand...
Click to collapse
is exactly what i mean. Every thread, forums, blogs, TA dumps, s1 sources i can found, make me understand there is no way to get back. Also a lot of rom (ftf versions) flash weird bootloader to the device. Everything on our xperia bootchain is crappy. If you touch one bit of your GPT headers, you are screwed.
BUT i never try the xperia pc companion as i am a Linux guy which refuse to spend 4 days to install a ****ty os on my computer for one software. So i had a windows7 vm with emma. But every times i try sony pc companion, the device reboot 10 seconds after plugin-in and nothing else happened.
So you are right, my information on this are obsolete as i don't try the 'hero' loader.
I have not yet upgraded the op but now i own a third z3, buy to brick it for this kind of experiments. Do you think it is relevant to give a try with pc companion? (I have not found the testpoints yet)
xxlsm said:
Another point ist that the bootloader upgrade is revertible. You can use the repair function of the Xperia PC Companion to downgrade to the older bootloader. Then you are also able to restore old TA Backups.
Click to expand...
Click to collapse
Are you sure? Did you try it personally? I'm really surprised because i parse my TA dump before unlocking, after unlocking, after upgrading and the structure is heavily modified, so if the bootloader is downgraded with PC companion, the TA partition get downgraded too?
(personally interested because sony refused my repair in despite of the law due to bootloader 'rooted' )
Anyway thanks for pointing that, i will take a further look on the hero loader.

After upgrading to the Android N Developer Preview and downgrading back with the Xperia PC Companion, I did a new TA Backup just to compare the origin TA-Partions with included DRM functions. I actually noticed a difference in the size of the two backups. But the restore dry run function of TA-Backup didn't show any errors, therefore all signature checks of the tool were executed succesfully on the device with the downgraded bootloader. For this reason I came to my conclusion that a bootloader downgrade is revertible and old backups are restorable. The "cat /proc/cmdline" command output also showed an older bootloader version (no "hero" term included anymore).I didn't restore it in reality because I din't want to mess with my daily rom. I don't know if a downgrade with the "unofficial" Flashtool would lead into the same results with the downgraded bootloader because I haven't given it a try. Maybe I will test it in the future when I plan a clean install anyway. I actually prefer windows either because of the better compiler collection, but I use dualboot because of a specific software I have to use which is only available for windows right now. That's why I din't try to downgrade with the "unofficial" flashtool.

xxlsm said:
After upgrading to the Android N Developer Preview and downgrading back with the Xperia PC Companion, I did a new TA Backup just to compare the origin TA-Partions with included DRM functions. I actually noticed a difference in the size of the two backups. But the restore dry run function of TA-Backup didn't show any errors, therefore all signature checks of the tool were executed succesfully on the device with the downgraded bootloader. For this reason I came to my conclusion that a bootloader downgrade is revertible and old backups are restorable. The "cat /proc/cmdline" command output also showed an older bootloader version (no "hero" term included anymore).I didn't restore it in reality because I din't want to mess with my daily rom. I don't know if a downgrade with the "unofficial" Flashtool would lead into the same results with the downgraded bootloader because I haven't given it a try. Maybe I will test it in the future when I plan a clean install anyway. I actually prefer windows either because of the better compiler collection, but I use dualboot because of a specific software I have to use which is only available for windows right now. That's why I din't try to downgrade with the "unofficial" flashtool.
Click to expand...
Click to collapse
Just a point, if you get a problem with your TA partition, your device is done, that is why i open this topic: restore a device with screwed TA partition or empty emmc.
All the xperia toolchain is signed, the preloader (not the right word but can remember at the moment), the GPT table, s1 (bootloader), the TA partition and finally the kernel if your bootloader is locked. So if one part of this signed toolchain is 'corrupted' your device won't boot anymore.
I never used the unofficial flashtool too. I never flash ftf files as they always includes TA patches and 'new' bootloader.
I tries multiples times to downgrade my bootloader with the official emma but every times without success, so i guess i will give a try with pc companion on someone else computer.
Thanks.

Well in fact I use the unofficial Flashtool, but I haven't tried to downgrade the bootloader with this tool yet because I sticked with the PC Companion for downgrading. You have the opportunity to exclude every component of the tft file (including TA-Updates). Apart from that, our situation is a bit different. I upgraded to the OpenDevices Bootloader with the PC Companion and my TA-Partition remained locked and untouched because I didn't have to unlock it with the PC Companion like with emma. I will wait until an Android N root exploit gets revealed, so that I can backup the origin TA-Partition on the new bootloader to be on the safe site. But in your place, I would still give the Xperia Companion a try in order to unbrick the device. I just wanted to let you know that. And in my case a downgrade from the Android N Hero Bootloader to an earlier version was possible, so maybe it could be worth to try for you.

Cross post with the boot guide thread.
Good evening everyone,
I spoke briefly with @nailyk about bootloaders and he suggested me to write these pieces of info here.
I'm not a developer nor an expert, so I can't go much in depth, but I was messing around with my D6603 and I flashed the .200 firmware with upgraded bootloader using EMMA.
After that I flashed this firmware (it's Sony's Concept for Marshmallow, latest build), originally posted by @yecomixer on the thread for this ROM here on xda. Flashing it substituted my upgraded bootloader with the Hero bootloader (This one). So I guess that everyone looking to revert back from the EMMA upgraded bootloader may try that since it worked fine on my device.
The same Hero bootloader can be found on the N Developer Preview for the Xperia Z3, but, even though I flashed that ROM (both DP3 and DP4), I didn't try going from the EMMA firmware to the Developer Previews, so I can't say if it would work in the same way.

For some few days I have a (sik!) windows computer. Install pc companion and update my brickable device to N preview. Sadly I don't know how to root N so no TA backups before unlock of this device (never rooted, never unlocked).
Sadly I install N, oem unlock, flash twrp then reboot. N refused to start (as usual, fastboot oem unlock empty the partition but doesn't recreate it :s). Hopefully fastboot format userdata/cache solve this.
Now I hope I will be able to dump the hero loader and install it on my other devices.
Then I will test your downgrade process.
One day, by accident, I restore a (unlocked) TA backup of my daily driver on my dev device (both bootloader 'v2'). Nothing changed, device running fine and was on stock o0.
P.S. we notice this partition scheme:
Code:
Number Start (sector) End (sector) Size Code Name
1 256 4351 2048K 0700 TA
2 4352 5375 512K 0700 sbl1
3 5376 5887 256K 0700 s1sbl
4 5888 6015 65536 0700 dbi
5 6016 7039 512K 0700 aboot
6 7040 8063 512K 0700 rpm
7 8064 9087 512K 0700 tz
8 9088 10111 512K 0700 sbl1bak
9 10112 10623 256K 0700 s1sblbak
10 10624 10751 65536 0700 dbibak
11 10752 11775 512K 0700 abootbak
12 11776 12799 512K 0700 rpmbak
13 12800 13823 512K 0700 tzbak
14 13824 54783 20.0M 0700 boot
15 54784 75263 10.0M 0700 ramdump
16 75264 108031 16.0M 0700 recovery
17 108032 108095 32768 0700 DDR
18 147456 150527 1536K 0700 modemst1
19 155648 158719 1536K 0700 modemst2
20 163840 166911 1536K 0700 fsg
21 172032 188415 8192K 0700 apps_log
22 188416 189439 512K 0700 misc
23 189440 190463 512K 0700 persistent
24 196608 4382719 2044M 0700 system
25 4382720 5406719 500M 0700 oem
26 5406720 5816319 200M 0700 cache
27 5816320 30535646 11.7G 0700 userdata
edit: maybe I will test downgrade quicker than expected because now I'm stuck at error 7 into twrp with empty device

So this hero loader is the worst ever.
With non stock kernel he refused to work at all. No way to enter into recovery, no commands accepted.
I'm now downloading the .575 with emma. At the bottom of the windows the bootloader version included is mentioned. All the version proposed for my device are '27' which is the 2nd one.
So I really don't get how do you downgrade to '15' @xxlsm ... Maybe you have another list of rom proposed and mine doesn't include the first version.
While flashing with pc companion and with emma device is in flashmode and recognized as "SOMC Flash Device".

Sony devices is diferent at least which I found on z1c. Sony unbrick bin is caled s1 boot preloader. Binary file is very similar to mprg binary (the same header have) but sony certificate is at the end of the bin file. That bin is signed with sony certificate. How things work. Test point puts phone into s1 boot download mode, preloader is sent to phone, verified header (0x40 bytes), sent body, and finaly certificate verified, after that unbricking things is sent similar like flashing with ftf. You can't use mprg files which is not signed by sony! Sony unbrick proces you can sniff by an usb protocol sniffer by sniffing for example s1tool which have unbrick binary for z1c, trought sniff dump you can see all protocol things and also construct/extract that preloader as I allready done, that binary file is signed by sony which mean pbl indeed expects sony certificate. If trim area is broken or formated there is no way to unbrick by preloader, only by direct emmc for example by using z3x easy jtag tool with emmc adapter, for that you will need pinout. Just to save your time

munjeni said:
Sony devices is diferent at least which I found on z1c. Sony unbrick bin is caled s1 boot preloader. Binary file is very similar to mprg binary (the same header have) but sony certificate is at the end of the bin file. That bin is signed with sony certificate. How things work. Test point puts phone into s1 boot download mode, preloader is sent to phone, verified header (0x40 bytes), sent body, and finaly certificate verified, after that unbricking things is sent similar like flashing with ftf. You can't use mprg files which is not signed by sony! Sony unbrick proces you can sniff by an usb protocol sniffer by sniffing for example s1tool which have unbrick binary for z1c, trought sniff dump you can see all protocol things and also construct/extract that preloader as I allready done, that binary file is signed by sony which mean pbl indeed expects sony certificate. If trim area is broken or formated there is no way to unbrick by preloader, only by direct emmc for example by using z3x easy jtag tool with emmc adapter, for that you will need pinout. Just to save your time
Click to expand...
Click to collapse
Thanks a lot.
I read many times your mission impossible thread and found a bunch of useful information about a possible unbricking process. With this and some other topics (listed into the OP iirc) I have in mind exactly what you described: sniffing emma to dump the preloader.
I also subscribe this thread which learn me there is a raw eMMC access into the soc.
Maybe you know I'm currently reading free-electrons documentation? Last one. They have some slides about the boot process. So I can't understand something: if we have an empty eMMC and put the phone into qdloader mode, there is no eMMC access by the soc as the minimal loader (s1 boot download) is too small to handle it, that is why we need the preloader. If the preloader isn't signed (custom one or something like this) why would it prevent rewriting TA or the full eMMC?
btw all of this is still untested because I didn't find pinouts. How do you find it for your z1c?

If you brick trim area in hard way as I done 2 years ago, you will not be able to repair trim area by test point anyway (which is a main problem). You can flash other things but not trim area since we don't have trim_area in sin format - mean signed format! In that case your trim area is damaged device will not boot which mean hard bricked. All things put to sony must be signed by sony cert. Not signed mean can't use. But Z3X jtag tool with emmc adapter alow you to solder box pinouts to the your phone emmc pinc - direct access (pins you need to locate on mainboard). In time when I bricked my phone I didn't found pinouts but now after I updated pc software of the easy jtag some devices is updated including my z1c, now I have pinout but thats too late since I already got new mainboard and it was a year ago...
About qhsusb bulk I think it will not work since on nexus device boot chain is totaly diferent that sony one.

. .

I wanna ask you @munjeni about how you find the testpoint but rereading your post make me feel it will be hard.
Anyway I will be more active on this thread now as I just f*ck my device replacing the tz partition.
Who can use tz to boot. Those sony bootchain is a real crap.
some links:
testpoint: https://forum.xda-developers.com/z3/help/help-z3-hard-bricked-t3216404
testpoint: http://www.forensicfocus.com/Forums/viewtopic/t=15219/
hardware manuals: http://gsm-manuals.com/59-Sony schematics and service manuals.html

So the test point of my d6603 is at the same location. I will edit this post with a picture later.
Recognized at:
Code:
Bus 001 Device 022: ID 0fce:9dde Sony Ericsson Mobile Communications AB

Looks like there is no s1tool for z3. The most recent version I found is 19.05.2015 and get this output:
Code:
Welcome S1 Tool [19.05.2015].
That is small and crippled subset of SETOOL2 service tool.
TO CONNECT NEXT PHONES
X10 Xperia,E10 Mini,E15 Xperia X8,U20 Mini Pro
LT15 Xperia ARC,MT15 Xperia NEO,R800 Xperia PLAY
PRESS AND HOLD "BACK" BUTTON...
ST18 Xperia RAY,ST15 Xperia Mini,SK17 Xperia Mini Pro
and Sony Xperia phone
PRESS AND HOLD "Volume Down" BUTTON...
PLEASE ATTACH TURNED OFF PHONE NOW
Waiting for phone ...
PROCEDURE STOPPED BY USER
supported phone was not detected
Elapsed:65 secs.
SELECT FIRMWARE PACKAGES
YOU CAN SELECT SEVERAL PACKAGES WITH CTRL BUTTON
CHECKING PACKAGES ...
DETACH USB CABLE FROM PHONE
REMOVE BATTERY FROM PHONE
ATTACH TESTPOINT
PRESS "READY", THEN ATTACH USB CABLE TO PHONE
will use Sahara protocol ...
REMOVE TESTPOINT NOW, THEN PRESS "READY"
PROCESSING ...
SERIAL NUMBER : 196A460E
HARDWARE ID : 04000100E1407B00
HASH :CF19D6FAD8029B66B15246BF3C9D216FC1D2235D87706E0458C7125BB1E436EC
[B]HARDWARE ID 04000100E1407B00 NOT SUPPORTED
[/B]Elapsed:35 secs.
Edit: Looks like the official website for s1.

d6603 testpoint
sony xperia z3 D6603 testpoint
recognized as
Code:
SOMC Flash Device
or
Code:
0fce:9dde Sony Ericsson Mobile Communications AB
After blinking red one time.
Battery need to be removed.

@mathorv why you deleted your post?
Links looked fine.
I didn't try SEMCTool Flasher but will do asap. @BigCountry907 also tell me about a specific revival cable.
Will try this too asap and report.

nailyk said:
@mathorv why you deleted your post?
Links looked fine.
I didn't try SEMCTool Flasher but will do asap. @BigCountry907 also tell me about a specific revival cable.
Will try this too asap and report.
Click to expand...
Click to collapse
About https://forum.xda-developers.com/showthread.php?t=1333818
Wanted to help but I was afraid of making fool of myself
million different ideas ( no neccessary OPs, but maybe some clues in threads)
http://forum.gsmhosting.com/vbb/f778/sony-xperia-z-c6602-c6603-c6606-c6616-dead-boot-repair-1877259/
http://forum.gsmhosting.com/vbb/f778/sony-xperia-z1-c6902-c6903-dead-boot-repair-1876818/
http://sony.yt/topic/7732-sony-xperia-z3-d6616-bricked/
Explanation of why s1 tool is not for z3 - no broken z3 rsa 4k key(missing vulnerability):
http://sony.yt/topic/7820-sony-xperia-z3-dual-d6633-damaged-ta-trim-area/
s1tool info
http://sony.yt/topic/5324-s1tool-tu...l-xperia-qsd8250-msm7227-msm8255-smartphones/
You are sure that buying one with "borken" screen is out of the question?
some people mentioned holding vol button for two minutes while reviving z3

G5 H30 Hard-Brick

I discovered a forum pertaining to the G5 a few days ago for methods of rooting the device (http://forum.xda-developers.com/tmob...-h830-t3384526). To the best of my abilities, I believe I followed each step correctly. After I used the LGUP tool to install the file while the device was in download mode, it began boot-looping on the initial boot screen with an error message displaying "boot verification failed". I found a post on the same forum from someone who was experiencing the same error on their device. Tungkick posted a response that provided a solution to the issue; "IF Boot Verification Failed error > download stock full flash again>> enabable usb debugging + oem unlock> adb reboot bootloader> fastboot oem unlock> then up file tot add twrp again." I downloaded the stock file and used LGUP to flash it to the device.
I believe I made the mistake of selecting "upgrade" instead of "refurbish" before I initiated the flash. When the file finished installing, the screen on my device went black. Since then, I've been incapable of booting my phone up. When I connect it to my laptop, the Device Manager reads it as: "Qualcomm HS-USB QDLoader 9008". I researched some methods but wasn't successful in finding one that fixed my phone. Although, I could've found a site that provided a solution but I might've failed to follow the instructions properly. I assure you I gave my best effort to fix this issue myself, but I'm desperate to seek help from anyone at this point.
I would sincerely appreciate any feedback that would assist in resolving this issue. Here are the Web addresses:
(1) http://www.droidsavvy.com/unbrick-qualcomm-mobiles/
(2) http://www.androidbrick.com/unbrick-...-qhsusb_dload/
(3) http://www.androidbrick.com/ultimate...oad_qpst_qfil/

Unfortunately your phone is done. None of those links work for the G5, or the G4 even.
If you purchased it from a retailer, send it to LG for a warranty replacement. Be 'mysterious' and ignorant about how it happened. Will take about 1.5 weeks to get it back. They just reflash the phone and you're as good as before. Or, show it to T-Mobile and they will send a refurbished replacement out, for either $5 or $20, depending on your phone insurance.
It's quite odd that this happened according to your description. From your profile, you have the H830, right? Do you know if you were on 10A or 10D?
From the beginning, did you select OEM unlock in Android developer settings, and then unlock the bootloader? If not, that will lead to that type of error you got. The instructions are all over the place and the tutorials are not always as complete as they should be.
I don't think refurbish vs upgrade makes a difference--one will wipe the /data, the other won't. If you have the right stock KDZ file, LGUP (you used LGUP, not LGFlash right?) will simply return you to stock so you can try again.
That error occurs if you try to flash an older firmware version OR flash a different model KDZ. Neither of those should occur with LGUP as it has safeguards.

waylo said:
Unfortunately your phone is done. None of those links work for the G5, or the G4 even.
If you purchased it from a retailer, send it to LG for a warranty replacement. Be 'mysterious' and ignorant about how it happened. Will take about 1.5 weeks to get it back. They just reflash the phone and you're as good as before. Or, show it to T-Mobile and they will send a refurbished replacement out, for either $5 or $20, depending on your phone insurance.
It's quite odd that this happened according to your description. From your profile, you have the H830, right? Do you know if you were on 10A or 10D?
From the beginning, did you select OEM unlock in Android developer settings, and then unlock the bootloader? If not, that will lead to that type of error you got. The instructions are all over the place and the tutorials are not always as complete as they should be.
I don't think refurbish vs upgrade makes a difference--one will wipe the /data, the other won't. If you have the right stock KDZ file, LGUP (you used LGUP, not LGFlash right?) will simply return you to stock so you can try again.
That error occurs if you try to flash an older firmware version OR flash a different model KDZ. Neither of those should occur with LGUP as it has safeguards.
Click to expand...
Click to collapse
Yeah, I was on 10D. OEM unlock and USB debugging were enabled; the bootloader was unlocked, as well. This is all a mystery to me, honestly. I've never experienced an issue like this before. I appreciate you taking the time to help

Hmm, weird scenario then, as it seems like everything went exactly the way it was supposed to. Good luck with the replacement, it's not that hard, just annoying.
If you're happy with the G5 you have, send it through LG. If you'd prefer to get it a tad sooner and don't mind playing the refurb lottery, go through T-Mobile.

waylo said:
Hmm, weird scenario then, as it seems like everything went exactly the way it was supposed to. Good luck with the replacement, it's not that hard, just annoying.
If you're happy with the G5 you have, send it through LG. If you'd prefer to get it a tad sooner and don't mind playing the refurb lottery, go through T-Mobile.
Click to expand...
Click to collapse
Thanks, man. Take care

If your bootloader was unlocked already then you should have twrp still, try booting into that with a button combo or thru adb terminal you'll need a file called no dm-verify zip witch you can find on the fourms, be sure to wipe your caches as well. I believe this is your problem is you may have forgot to flash this and that's why your not booting. And I would try to flash the 10d fluence ROM as well and follow his instructions on how to do so it may solve your boot loop and you won't have to wait for another phone.

I made a stupid mistake trying to flash a H850 build on H830 devices via TWRP.
I ended up with a dead device with 9008 driver communication only. Now, I've managed to get MSM8996 programmer file in order to flash bootloaders back to the device via QPST utility and all I'm missing is rawprogram0.xml file that contains the exact start_byte_hex values of each one of the bootloader files in order to be successfully downloaded to the phone.
I would highly appreciate some help from anyone with a rooted LG G5 to get the exact start_byte_hex of each one of the phone's partitions in order to build my own rawprogram0.xml file or alternatively just get the complete LG G5 rawprogram0.xml file from someone who already have his hands this file
I'll post here all revive steps and tools used once I'll have all files needed and get a successful revive results on my device.

Crossdead said:
If your bootloader was unlocked already then you should have twrp still, try booting into that with a button combo or thru adb terminal you'll need a file called no dm-verify zip witch you can find on the fourms, be sure to wipe your caches as well. I believe this is your problem is you may have forgot to flash this and that's why your not booting. And I would try to flash the 10d fluence ROM as well and follow his instructions on how to do so it may solve your boot loop and you won't have to wait for another phone.
Click to expand...
Click to collapse
Dude, I concur with your method entirely haha.
I wanted to root my phone and install a custom recovery simultaneously (idiotic decision, I guess). So I just waited until someone posted a forum with the files that were compatible for the G5's most recent update. Ironically, the files didn't install properly or something, so my phone went into a bootloop. The same developer who posted that forum with the root and recovery files, provided a solution to the issue. Which was, initially, flashing the stock files to the device, then proceed with installing the root/recovery files.
I then flashed the stock files to the device and simultaneously at completion, my phone powered off. Still, my phone is incapable of communicating with my laptop because something is wrong with the drivers on the LG and I've only been able to find outdated and ineffective solutions for it. Thank you for lending a hand though, man. If you have any alternatives, please let me know.

motman said:
I made a stupid mistake trying to flash a H850 build on H830 devices via TWRP.
I ended up with a dead device with 9008 driver communication only. Now, I've managed to get MSM8996 programmer file in order to flash bootloaders back to the device via QPST utility and all I'm missing is rawprogram0.xml file that contains the exact start_byte_hex values of each one of the bootloader files in order to be successfully downloaded to the phone.
I would highly appreciate some help from anyone with a rooted LG G5 to get the exact start_byte_hex of each one of the phone's partitions in order to build my own rawprogram0.xml file or alternatively just get the complete LG G5 rawprogram0.xml file from someone who already have his hands this file
I'll post here all revive steps and tools used once I'll have all files needed and get a successful revive results on my device.
Click to expand...
Click to collapse
Same here, man! I thought I was so close to fixing it but the QPST tool would always display an error indicating that there was an issue with the rawprogram0.xml file. I don't believe I used MSM8996 programmer file, though... Would you mind posting a link of the download, please? Thank you for posting.

Colbyfales_25 said:
Same here, man! I thought I was so close to fixing it but the QPST tool would always display an error indicating that there was an issue with the rawprogram0.xml file. I don't believe I used MSM8996 programmer file, though... Would you mind posting a link of the download, please? Thank you for posting.
Click to expand...
Click to collapse
Here you go, I guess that you will have to use the lite version
https://www.mediafire.com/?epv3qq83ag2vqar

motman said:
Here you go, I guess that you will have to use the lite version
https://www.mediafire.com/?epv3qq83ag2vqar
Click to expand...
Click to collapse
I found a way to create the required rawprogram0.xml and patch0.xml files from a working phone via Python script.
Python should be installed on your computer in order to run this tool. All we need is someone with a working phone who will be willing to run this tool and create the required files...
Tool:
https://www.mediafire.com/?jh2owbccrfj6rne
Script description:
http://forum.xda-developers.com/showthread.php?t=1884417&page=2

motman said:
I found a way to create the required rawprogram0.xml and patch0.xml files from a working phone via Python script.
Python should be installed on your computer in order to run this tool. All we need is someone with a working phone who will be willing to run this tool and create the required files...
Tool:
https://www.mediafire.com/?jh2owbccrfj6rne
Script description:
http://forum.xda-developers.com/showthread.php?t=1884417&page=2
Click to expand...
Click to collapse
I'm on it. I'll keep you apprised throughout the process.

Colbyfales_25 said:
I'm on it. I'll keep you apprised throughout the process.
Click to expand...
Click to collapse
Cool

Colbyfales_25 said:
I'm on it. I'll keep you apprised throughout the process.
Click to expand...
Click to collapse
Ever get a chance to make any progress with this?

SophiaNOTLoren said:
Ever get a chance to make any progress with this?
Click to expand...
Click to collapse
Unfortunately, no. I had access to Ubuntu's OS but wasn't successful finding another G5. Theoretically, using the Python rawprogram0.xml and patch0.xml scripts, along with an operable G5, It's plausible to recover the phone. I essentially just went into a retail store and told them that the phone had spontaneously shut-off and wouldn't reboot. They provided a replacement and that was the end of it.

So i got on of these but sprint model well g5
i have a full dump from before my phone bricked
but not through the script from lgups partition dump how can i push these back to mine or make a partition xml from my dump or even a sdcar debrick img? lol Im not picky any of these would suit me. lol Not askin to much

Colbyfales_25 said:
Unfortunately, no. I had access to Ubuntu's OS but wasn't successful finding another G5. Theoretically, using the Python rawprogram0.xml and patch0.xml scripts, along with an operable G5, It's plausible to recover the phone. I essentially just went into a retail store and told them that the phone had spontaneously shut-off and wouldn't reboot. They provided a replacement and that was the end of it.
Click to expand...
Click to collapse
Ah, that's a shame. I bought mine on eBay, and I'm on Metro not TMobile proper, so sadly that avenue's not much use for me.

for UFS Chip only can use Nuprog to rewrite full flash to chip direct or use cm2 dongle with Open memory tool plugin and can flash it in 9008 port
Device Found!
Initialize ...
Handshake passed!
BB_IDC_CPU : SnapDragon 820 [MSM8996]
ID_BLOCK_S : B861DCBB
ID_BLOCK_I : 009470E1
ID_BLOCK_E : 2A703DB9
ID_BLOCK_L : C4CF6F2386EC1D32B0AF58AB5E37F2A3
ID_BLOCK_L : 527BBE85A099E0CC4DA13129613BB67A
Pickup loader from firmware package
Loader Sent! Initializing ...
Running FireHose on BBID : MSM8996 , FLASH : UFS , mVER : 1
ExtInfo : 0x0000C000/0000C000/00001000/00001000/00001000
UFS Device : SAMSUNG KLUCG4J1CB-B0B1 0800
UFS SectSize : 0x1000
UFS LU0 Size : 0x00000007602F0000 : 29,50 GiB
--------------UFS Device Info--------------
UFS Total Active LU: 0x6
UFS wManufacturerID: 0x1ce
UFS Boot Partition Enabled: 0x1
UFS LU Write Protect: 0x0
UFS Boot LUN ID: = 0x0
UFS Memory Type: 0x0
UFS LU Total Blocks: 0x0
UFS Supported Memory Types: 0x800f
UFS LUN Enable Bitmask: 0x3f
UFS bConfigDescrLock: 0x0
Boot Ok!
Flash Chain : 74
Flashing now
Flashing : persist.img
Flashing : cache.img
Flashing : devcfg.mbn
Flashing : devcfg.mbn
Flashing : dynamic_nvbk.bin
Flashing : reserve1.bin
Flashing : reserve2.bin
Flashing : config.bin
Flashing : userdata.img
Flashing : gpt_main0.bin
Flashing : gpt_backup0.bin
Flashing : xbl.elf
Flashing : gpt_main1.bin
Flashing : gpt_backup1.bin
Flashing : xbl.elf
Flashing : gpt_main2.bin
Flashing : gpt_backup2.bin
Flashing : gpt_main3.bin
Flashing : gpt_backup3.bin
Flashing : rpm.mbn
Flashing : rpm.mbn
Flashing : tz.mbn
Flashing : tz.mbn
Flashing : hyp.mbn
Flashing : hyp.mbn
Flashing : sec.dat
Flashing : pmic.elf
Flashing : pmic.elf
Flashing : NON-HLOS.bin
Flashing : adspso.bin
Flashing : mdtp.img
Flashing : emmc_appsboot.mbn
Flashing : emmc_appsboot.mbn
Flashing : logo.bin
Flashing : boot.img
Flashing : boot_aging.img
Flashing : system.img
Flashing : recovery.img
Flashing : BTFM.bin
Flashing : keymaster.mbn
Flashing : keymaster.mbn
Flashing : cmnlib.mbn
Flashing : cmnlib.mbn
Flashing : cmnlib64.mbn
Flashing : cmnlib64.mbn
Flashing : apdp.mbn
Flashing : msadp.mbn
Flashing : gpt_main4.bin
Flashing : gpt_backup4.bin
Flashing : md5.img
Flashing : gpt_main5.bin
Flashing : gpt_backup5.bin
Click to expand...
Click to collapse

MA7MOD_GSM said:
for UFS Chip only can use Nuprog to rewrite full flash to chip direct or use cm2 dongle with Open memory tool plugin and can flash it in 9008 port
Click to expand...
Click to collapse
This is rather interesting. I have a working g5 (H830) and a bricked on stuck on qdloader mode.
Can you point me in the direction of reading the backup from the working one to resurrect the bricked phone?
Currently have access to Octoplus Jtag Pro box. I do have cm2 dongle as well.
Hit me up soon, i hope.
Best Regards

hiroprotagonist said:
This is rather interesting. I have a working g5 (H830) and a bricked on stuck on qdloader mode.
Can you point me in the direction of reading the backup from the working one to resurrect the bricked phone?
Currently have access to Octoplus Jtag Pro box. I do have cm2 dongle as well.
Hit me up soon, i hope.
Best Regards
Click to expand...
Click to collapse
Let’s start with cm2
MSM8996 & UFS & MemoryTool
-Connect Working H830 in edl mode by press down,up and connect usb setup Cm2 QLM driver
-Open Cm2QLM and chose Memory Tool
-Chose full files and Make read
-Connect dead H830 with memory tool and make restore readed files from first working h830
-Send Screen Shot
#MA7MOD_GSM

bootloader / qfuses / ARB - how not to brick your phone for funsies v1

This is version one of this document. I know the formatting is not great, and I will be fixing that over time. Also, there is some pieces that are missing, and some of it may not entirely be correct yet. I will try to make note if I am unsure.
I am composing this because I couldn't find a good resource that explained all of this in one place.
So after bricking my phones (G4, V10, V20 -- sometimes deliberately) many times, I thought I would share a little information. I gathered this information by:
* accident
* decompiling the various pieces of the firmware
* documentation found on the net
* reading source code
First some background on the boot procedure for SD8XX based phones (SD800, 801, 808, 810, 820).
It goes like this:
CPU (Qfuses: ARB / KEY (SHA1?) / TRUSTED_BOOT, FEAT_A, FEAT_B) <--> PBL <--> XBL (SBL1) -> ABOOT -> BOOT
The XBL (Seconday Boot Loader) is very similar to UEFI on a PC. It loads a lot of modules (firmware) that make the devices on the phone work, and allow it to boot. The XBL has an RSA cert that it uses to verify most of the modules that it loads.
The XBL loads (and verifies - does it also check ARB per module?):
(RSA) - aboot (Applications Boot)
(RSA) - apdp -- ??
(RSA) - cmnlib (Common Libraries) -- These are just shared libraries that the other parts of the firmware use
(RSA) - cmnlib64 (Common Libraries 64bit) -- Same as above, but for the 64bit components.
(RSA) - devcfg (Device Configuration)
(RSA) - hyp (Hypervisor) -- this is what runs the NON-HLOS, and I believe is one of the first things that XBL loads.
(RSA) - keymaster -- This does several things, but one of the things it handles is the fingerprint sensor
modem -- This is your modem firmware.
(RSA) - msadp -- ??
persist -- ??
(RSA) - pmic -- ??
raw_resources
rct -- ??
(RSA) - rpm -- Resource and Power Management
sec -- ??
(RSA) - tz -- TrustZone You can thank this guy for handling the security of the QSEE (Qualcomm Secure Execution Environment). It checks the RSA certs for the images that are labled above with (RSA).
The XBL only loads these if:
* The phone is booting to the HLOS (Android)
* The phone is booting to recovery (No idea why it would need them in recovery, but it does)
If you are going into download mode, or fastboot mode, they do not get loaded.
The PBL is located in ROM -- true Read Only Memory. There is no changing it unless you physically unsolder the chip.
When you power on the phone, the PBL gets loaded, and does a couple of things, but the one we are concerned with is it loading the SBL (Secondary Boot Loader, or XBL on the V20).
It verifies the integrity of the XBL by reading a key from a qfuse on the CPU. If it matches, it continues the boot process. It also checks the ARB (Anti-RollBack) version qfuse. If the ARB version of the XBL is greater than the ARB version currently blown into the qfuse, it will blow the bits needed to match the current ARB of the XBL that it is trying to load. When a Qfuse is blown, it can't be "unblown", so you are stuck with that ARB version now.
When a Qualcomm chip ships from the factory, none of the Qfuses are blown -- the chip is fully unlocked. It is then up to the OEM to decide what features it wants to have enabled, as well as should trusted boot be enabled. As far as I know, EVERY OEM blows the TRUSTED_BOOT qfuse on production phones, which means that the PBL will verify the SBL (XBL). This means that the SBL (XBL) must be signed. This signature is also in the CPU via blown qfuses. I don't believe that there is any room to modify the SHA1 signature once it has been blown into the CPU -- but I have nothing to back this up. That means that as long as you ONLY use an XBL that has the same signature as what is blown into your CPU -- AND -- you don't try to run an XBL with a LOWER ARB version, that your phone will boot. Doesn't mean it is going to work, but it will at least boot to download mode if you haven't messed up aboot or laf (we will get to that).
If the XBL is corrupt, or wasn't signed, or was signed but with a different key, or has an ARB version that is less than what is in the CPU, the CPU will go into HS-USB QDLoader 9008 mode, and your phone is a brick. QDLoader mode is built into the (CPU? PBL?) so that the boot loader can be fixed. If you have the right tools (QPST) AND a signed firehose, then you can flash the proper firmware back onto your phone. Good luck finding a signed firehose -- they leak from OEMs very rarely here recently. In the past (when they were using eMMC), before UFS, you could boot from an SD card and recover your phone. The V20 uses a UFS chip that presents itself as multiple LUNs, and does not have a UFS card slot -- so I do not believe it is possible to boot from SD card anymore. This is something that is still being investigated however.
So, lets say all is good -- PBL verified the XBL, and said it was OK. Now it is time for the XBL to load ABOOT.
Once again, there is verification. This time the XBL verifies ABOOT with its own RSA key. If ABOOT is OK, then it loads. At this point, you will have download mode, and at least you can recover (if you have a KDZ). No matter what -- NEVER mess with XBL or ABOOT unless you absolutely want a brick. If ABOOT is corrupt or invalid in some way, then the CPU goes into QD_LOADER (9008) mode.
So now we have ABOOT loaded. ABOOT does a lot of things. Directly, it provides fastboot mode, indirectly, it provides download mode by booting laf. In order to have download, you have to have a working laf. LAF is just a kernel with an initrd that runs lafd (more on that later). ABOOT also allows you to boot recovery. Again, recovery is just a kernel with an initrd.
ABOOT loads (all just kernels with an appropriate initrd:
boot
laf (download mode)
recovery
depending on the mode it is in.
What we care about most is boot (that is the kernel, that loads the system partition). If you don't have an unlocked boot loader, and you have modified your kernel, the boot will fail, since aboot verifies the signature. This will usually just result in a boot loop, but don't count on that. The good news is that a corrupt boot or recovery doesn't prevent you from getting into download mode -- better have a KDZ though.
So to sum up. If you don't want to brick your phone so bad that it has to be replaced or repaired:
* Don't flash an XBL that has a lower ARB version
* Don't flash an XBL that has a qfuse key that is not in your CPU (cross model flashing -- make SURE the model you are flashing uses the same key)
* Don't flash an aboot that wasn't signed with the RSA cert that is in your XBL
* Don't nuke your laf partition AND your recovery partition at the same time.
More to come -- especially better formatting.
EDIT1: The PBL is not a separate chip, it is in the Qualcomm CPU (QFPROM) -- This is also where the qfuses are located. The thing is huge, there is more than enough space that a vendor could update the key (it is a 2048 bit RSA key -- NOT an SHA1 hash), but more importantly it is 32k. Part of QFPROM is the PBL, the rest is for the vendor key(s?), and then there are feature banks. For example, can the boot loader be unlocked can be checked via a feature fuse.
Camera features, modem features, a lot of things can be determined by what the OEM wants to blow. One of the important things that is determined, is UART on or off. On the v20, it appears this is blown, so there is no way to get a console.
What is interesting is that there is a pin for voltage to write to the QFPROM. That pin can either have voltage, or be shorted to ground. Now, here is a big question, what if that pin was shorted to ground? Would the phone continue to boot in the event that a request to write to QFPROM happened (IE: booting an XBL with a greater ARB). If it would, then get a new phone with ARB 0, ground that pin, and they could never update the key, or ARB version. But if the OEM did update the RSA key used to sign firmware, it would no longer match the key in the CPU -- so it would need to be reversible.
QFPROM searches all available IO paths for a valid SBL. If that SBL has support to continue booting on the path that it was found, then it will.
This explains why on UFS based phones like the V20, you can get some life out of it if you have a properly formatted SD card, and are in QDLoader mode. The QFPROM reads the XBL, but the XBL has no clue where to go from there. There is no support for finding the other parts of the firmware via SD card -- it MUST have multiple LUNs. On older phones with eMMC, when the SBL was loaded, the SD card was initialized as mmcblk0 and the SBL couldn't tell the difference between it and the eMMC. So, it is now verified that there is no way out of 9008 mode if your phone has UFS except for the signed firehose route.
So what is a firehose? It is just a SBL that is booted via USB, with very limited functionality. The Qualcomm CPU still verifies its integrity (which is why it must be signed if you want it to work). Note1: Does the firehose check ARB?
EDIT2: So it appears that there are several toggles in QFPROM to enable / disable debug mode. Are they all blown? Can the phone be put back into debug mode? In debug mode signature verification is disabled -- as long as SBL is valid, it will load it and run it. This would give us the chance to "crack" the XBL so that it no longer uses its RSA to verify the rest of the boot chain.
A portion of the QFPROM address space is mapped into the HLOS address space. You can view certain portions from a running kernel. I will make a separate update on that. Technically you should be able to write to them as well. This sounds like a recipe for me bricking another phone! W00T!!
EDIT3: It would appear that the partition layout is in QFPROM. Again, this just backs up the fact that you will never be able to boot from SD card. So, how do the DragonBoards boot from SD card? It is my theory that they have both partition layouts in their QFPROM. So, next question, if that is the case, could we write an SD card partition layout into QFPROM? Yea, that is probably WAY out there
-- Brian

So what is this ?? Allow us to flash roms on an Arb enabled device ?

pbedard said:
So what is this ?? Allow us to flash roms on an Arb enabled device ?
Click to expand...
Click to collapse
Only for information.

@askermk2000 See EDIT 3.

Any way you'd be needing help continuing this particular endeavor?

Sure, trace out pad G31 from the CPU and cut it (that is QFPROM programming power), and then short it to ground. After that, flash firmware that has a higher ARB version and see what happens
If there is no power, fuses can't be blown, so ARB can't be incremented. Also, if we use the debug firehose, the debug fuse wouldn't blow.
I am not willing to test this theory with any of my phones though....
-- Brian

Thank you sir for this very valuable V20 information.

Until @Phoenix591 posted a link to this post, I had forgotten all about it. I am finally making version 2 which will have actual formatting, and be MUCH more readable, but most importantly -- it will have no assumptions -- just pure fact based on all the knowledge I have gained since first writing this. This version has several things that are inaccurate, and a lot of assumptions.
-- Brian
-- Brian

Thank you keep update and your valuable time, hope you can success to make V20 back from the dead.

Can ARB be disabled
Is the PBL that verifies the SBL or XBL and prevents firmware downgrade located in the eMMC with the SBL and other files or in a physically seperate storage medium, can it be modified via jtag box or any other method to disable ARB without replacing hardware, and would modifying the tot/kdz also work

chris2288 said:
Is the PBL that verifies the SBL or XBL and prevents firmware downgrade located in the eMMC with the SBL and other files or in a physically seperate storage medium, and can it be modified to disable ARB without replacing hardware or not?
Click to expand...
Click to collapse
runningnak3d can probably answer this better than I, but I'll give one anyway, and he can supplement if needed
One: Yes
Two: No. Downgrade is not prevented by any part of the bootloader. It's prevented by LGUP. Though if you try to downgrade you'll have a dead phone.
Three: There is no eMMC in LG V20. There is UFS - Universal Flash Storage. If you're suggesting PBL is on there, it's not, it's in the CPU itself (internal eprom).
Four: No, it can not be disabled. Perhaps as a challenge to the most well equipped and competent engineers and scientist you can think of, yes, maybe then.

The only thing I can think of to add to @askermk2000's post is that you can disable ARB from incrementing by cutting a lead on the motherboard and sending it to ground. However if ARB has been incremented you can never go back to a lower version.
-- Brian

Do you know what pin to short to force it into download mode?
runningnak3d said:
This is version one of this document. I know the formatting is not great, and I will be fixing that over time. Also, there is some pieces that are missing, and some of it may not entirely be correct yet. I will try to make note if I am unsure.
-- Brian
Click to expand...
Click to collapse

r4736 said:
Do you know what pin to short to force it into download mode?
Click to expand...
Click to collapse
I hope you can see yourself from your post how unnecessary and annoying it is when quoting a large post like that.
As to your question:
Are you saying LG has implemented a function to bypass bootloader verification and boot directly to LAF partition? Or is this simply a case of confusion?
See, this V20 goes into EDL (emergency download) mode automatically, there is no need to short any testpoints to get 9008 mode, unless you'd want
to enter that mode even when the phone is NOT bricked, although that wouldn't do you much good. EDL/9008 = Dead phone, at least in the case of most
phones these days.
I don't believe those testpoints (if they even exist) are known for the V20, perhaps if you can get a hold of the datasheet/repair manual.

I did not, I was busy this morning, but I fixed that now.
askermk2000 said:
I don't believe those testpoints (if they even exist) are known for the V20, perhaps if you can get a hold of the datasheet/repair manual.
Click to expand...
Click to collapse
Yes this is why I am asking around seeing if anyone has those (datasheet/repair manual). Also yes trying to get it into emergency download mode since it is not on its own.

r4736 said:
Yes this is why I am asking around seeing if anyone has those (datasheet/repair manual). Also yes trying to get it into emergency download mode since it is not on its own.
Click to expand...
Click to collapse
Ok I never would have guessed you where asking because of that...
If you get into edl mode, then there is only one possible option for you, and that is to use the LG firehose that is around, but no one has dared to use as of yet because it likely will mess up your phone.
I found it over a year ago at gsmhosting forum. The thread in question indicated that it was only for data retrieval, and that the phone would be unusable afterwards. @runningnak3d by his own analysis, also came to suspect something like that might happen if you use it.
That's why I said getting into 9008 mode wouldn't do you any good, but I guess if you have no other option it might be worth a try.
Edit: Well actually, you might be able to get someone with octoplus or such box to fix it, if you can get into 9008. It doesn't work for H918 but might for you.

askermk2000 said:
I guess if you have no other option
Click to expand...
Click to collapse
Yeah, it's fun. I wasn't paying attention and used did to restore the aboot backup while in USB mode. So it does practically nothing. Detectable by nothing, nothing on the screen. The only signs of life are it doing the power on vibrate, and the creek will only come on to blink a ! Battery warning if plugged in with battery removed. Thank goodness it's just a spare, v30 visits my daily.
I'm half thinking about taking it to a LG repair center here in Hong Kong. If it's not expensive if like to have it working.

Apologies for resurrecting a month old thread, I usually don't resort to posting, but I cannot find an answer to my problem in the ~700 pages I've read between here and development.
Long story short, I had a scare the other night fiddling with some build.prop settings resulting in a bootloop. I had been so stupid when I got this phone and flashed it I was on my Ubuntu partition which I no longer have. I never backed anything up, let alone install and get the sdk/adp working on my win10 drive. I am so lucky I was able to get it to finally boot without losing any data.
So I figured it's time to update. Here's what I know. I am bootloader unlocked, unencrypted, and rooted. I'm on H918, the last cmremix that was released, Jan 1 2017, 7.1.1. From what I can tell was compiled with sdk 25. However I'm showing "unknown" under baseband, and mbn, there's also multiple mentions of different sdks throughout different system files.
I've tried ripping apart a twrp system image backup for any mention of ARB, but to no avail. I've tried digging through multiple threads to determine a timeline when ARB was implemented, again to no avail, since I don't technically know which version I'm actually on.
Are there any adb commands or specific system file I can tear apart to determine my devices status in regards to flashing a 10p+ ROM. I've seen multiple mentions of if you're already unlocked and rooted it's much easier to keep it, but I've also seen just as many stating the opposite.
Again sorry for the novel, and bringing up a month old thread.

joeyk240 said:
Apologies for resurrecting a month old thread, I usually don't resort to posting, but I cannot find an answer to my problem in the ~700 pages I've read between here and development.
Long story short, I had a scare the other night fiddling with some build.prop settings resulting in a bootloop. I had been so stupid when I got this phone and flashed it I was on my Ubuntu partition which I no longer have. I never backed anything up, let alone install and get the sdk/adp working on my win10 drive. I am so lucky I was able to get it to finally boot without losing any data.
So I figured it's time to update. Here's what I know. I am bootloader unlocked, unencrypted, and rooted. I'm on H918, the last cmremix that was released, Jan 1 2017, 7.1.1. From what I can tell was compiled with sdk 25. However I'm showing "unknown" under baseband, and mbn, there's also multiple mentions of different sdks throughout different system files.
I've tried ripping apart a twrp system image backup for any mention of ARB, but to no avail. I've tried digging through multiple threads to determine a timeline when ARB was implemented, again to no avail, since I don't technically know which version I'm actually on.
Are there any adb commands or specific system file I can tear apart to determine my devices status in regards to flashing a 10p+ ROM. I've seen multiple mentions of if you're already unlocked and rooted it's much easier to keep it, but I've also seen just as many stating the opposite.
Again sorry for the novel, and bringing up a month old thread.
Click to expand...
Click to collapse
You're almost certainly arb 0 (pre10p) since you were on that old rom. There are checks in x86cpu's lineage builds that makes it error out if it's the wrong one before it does anything too.

Phoenix591 said:
You're almost certainly arb 0 (pre10p) since you were on that old rom. There are checks in x86cpu's lineage builds that makes it error out if it's the wrong one before it does anything too.
Click to expand...
Click to collapse
Yeah, I'm about 40min deep into the "Checking for updates" screen, so I'm pretty hopeful everything went okay. I'm going to post a step by step in x86's thread for people coming from outdated ROM's like I was, if everything goes okay.

[GUIDE] AN ESSENTIAL GUIDE FOR G935F/FD

AN ESSENTIAL GUIDE FOR G935F/FD​
DISCLAIMER☆THIS WILL BE A HUGE WORD WALL, SO DON'T BOTHER WITH THIS IN ADVANCE IF YOU MIND READING LARGE AMOUNTS OF WORDS ON SCREEN
☆THIS ISN'T A ROOT GUIDE EXACTLY BUT WHEN YOU READ THIS TILL THE END, ROOTING WILL BE AS EASY AS BREATHING FOR YOU (LITERALLY)
NOTE : THIS GUIDE DOESN'T APPLIES TO YOU IF YOU ALREADY KNOW BASICS AND/OR ARE ADVANCED USER WHO KNOWS GUTS OF ANDROID. THIS IS EXPLICITLY FOR NOOBS LIKE MYSELF WHO ACCIDENTALLY MESS THEIR DEVICES AND GET A BRICK !
WARNING : THIS DOESN'T APPLIES FOR ANY OTHER MODEL THEN G935F/FD, AND IS JUST FOR INFORMATIONAL PURPOSES, I WILL NOT BE RESPONSIBLE FOR ANY DAMAGE CAUSED TO YOUR DEVICE FOLLOWING THIS GUIDE.
P.SHERE I PRESENT MY FIRST GUIDE FOR S7 SERIES, YOU CAN SAY ITS A BASIC ROOTING GUIDE AND SUCH GUIDES ARE EVERYWHERE HERE ON S7 FORUMS BUT THIS ONE CONTAINS VITAL INFORMATION WHICH I COLLECTED FROM VARIOUS SOURCES AND TRIED KEEPING IT AT ONE PLACE AND FOR THE NOOBS LIKE ME WHO DON'T KNOW WHERE TO SEARCH FOR THESE THINGS
ALSO AS I RECEIVE HUNDREDS OF PM'S FOR HELP REGARDING PEOPLE ACCIDENTALLY TURNING OEM UNLOCK OFF AND MESSING THEIR DEVICES, I HAD TO MAKE A GUIDE NOW SO EVERYONE CAN BENEFIT FROM THIS
AND YEAH I CANNOT HELP ANYONE REMOTELY NOW, SORRY LIFE SUCKS IN AT TIMES
AND YOU GUYS KNOW THAT S7 SERIES ARE ALMOST EOL BY SAMSUNG SO I TRIED MAKING AN EOL GUIDE TOO
--------------------------------------------------------------------​
INTRODUCTION
EFS :
EFS (encrypting file system) is the partition which stores nv data of your phone, that is a read only partiton and it contains nv data (non-volatile data) memory which stores all the vital data from the manufacturer which is non volatile or in other words.. not to be removed/modified in any way.. and So, this nv data kinda makes your phone a 'phone'
UFS :
The UFS is universal flash storage chip also known as nand memory in older terms, your internal memory chip on the s7 edge series.. it contains all the android partitions of your phone i.e everything your smartphone has to be a 'smartphone' ..
DM-VERITY :
Device-Mapper verification is a new security measure in latest samsung devices, it basically checks system integrity i.e to check if system partition is modified by any method .. if your system partition is modified even willingly by yourself by any method like non-systemless root/mod/custom binaries etc, dm-verity will kick in and prevent your phone from booting normally. DM-verity is explicitly present in recovery partition which prevents boot on activating and it kicks in through a check inside the stock kernel which activates it.. apparently, removing dm-verity in recovery or kernel makes the device boot-able again.
DRK :
DRK or device root key is present in efs partition of your phone, DRK is a device-unique asymmetric key pair that is signed by Samsung's root key through an X.509 certificate, this certificate proves that the DRK was produced by Samsung. DRK is explicitly present in EFS partition. If due to any reason your drk gets corrupted/deleted, you get a permanent type of dm-verity error and your phone will not boot even stock samsung roms without dm verity disabler zips ..
NV DATA :
Non-volatile data is present on efs partition and includes, device specific vital manufacturer binaries which are never to be modified/removed in anyway. This includes device specific network certificates, IMEIs, SERIAL numbers, bluetooth ids/mac addresses, DRK, nfc parameters and others etc ..
PARTITIONS :
Android adopts linux like partitions and file tables, but most of the partitions present on samsung phones are not to be modified/messed up in any way, other then backing them up. The most common partitions to modify/format include :
1. DATA
2. CACHE
3. DALVIK CACHE
4. SYSTEM
But system partition is often recommended to not modify/format for the reasons I will explain further down in the guide ..
A partitions screenshot of s7 edge G935F running a stock rooted rom on version 8 binary
{
"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"
}
The highlighted ones in yellow contain your nv data..
NOTE : ITS A VITAL STEP TO BACKUP ALL NV DATA PARTITIONS AFTER ROOTING (SHOULD BE THE FIRST THING TO DO AFTER ROOTING! )
PARTITION STYLE/IMAGE TYPE :
S7 series (exynos) partition table is A type on oreo stock firmware and until pie based custom roms.. one ui 2.0 introduced A/B style partitioning. Only difference between them is about how hard magisk implementation is in A/B and also the absence of ramdisk. You can get more info in magisk's documentation on github.
FIRMWARE TYPES :
All firmwares before the 10th binary update are called as A firmwares, the 10th or 0 one being called as A and after onwards from that we call the binaries as B firmwares i.e all firmwares from G935FXX1XXXXX to G935FXX9XXXXX will be called A firmwares simply, the 10th one being G935FXXAXXXXX and after that B firmware starts as G935FXXBXXXXX and then binaries continue like C/D/E/F if samsung wanted to update the device further.. S7 exynos are currently on 8th version binary.. where the binary number is actually the bootloader number and you cannot downgrade to lower version binaries from a higher version ..
Also the B firmwares are a very special case, will explain later further down later.
BOOTLOADER VERSION :
Refer to the above paragraph. Numbers/alphabets after XX and before XXXXX denote the version number of the binaries or in other words the bootloader version, which after upgrading to a higher version cannot be downgraded to a lower bootloader version ..
WHAT IS AP/CP/CSC/BL/PIT?
AP is Application Processor, known as PDA in older terms, the core android of the flashing package, CP being the Core Processor also known as modem, while CSC is Consumer Software Customization which contains regional/country based settings for your phone which includes network settings and custom preloaded software, also to mention that CSC has two types CSC and HOME_CSC ..
CSC contains the pit file which partitions and formats the phone before flashing in odin, while HOME_CSC doesn't include pit file and is meant to upgrade/dirty flash without wiping data in odin.. PIT means partition information table, if you are flashing CSC you don't need to manually extract and place pit file in odin as this is automatically done when flashed using CSC..
ODIN :
Odin, the lord of the dead as known in norse mythology is actually a lord of dead samsung phones too you already know what this is, but in case if you really don't; then this is a flashing software for samsung phones and you don't need to select any advanced options in odin when flashing.. just select auto-reboot and f.reset when flashing stock firmwares - all other options are obsolete and/or have no use for s7 series devices. Also when flashing any recovery don't tick auto reboot just f.reset and manually force reboot from download mode to custom recovery using key combinations
DOWNLOAD, RECOVERY MODE, SAFE MODE AND FORCE REBOOT :
While phone is turned off, holding vol down+home+power buttons will make you go in download mode.
And while phone is off, holding vol up+home+power buttons will make you go in recovery mode ..
Holding vol down after samsung animation comes during boot would make you enter in safe mode (this option is obsolete since in most bootloops we cannot go in safe mode because phone isn't booting properly to accept safe mode key input)
Hold vol down+home+power buttons on any screen to force reboot phone ..
DOWNLOAD MODE INFO :
There are details written in download mode which are very useful for diagnosing various issues.
Such as :
>Real Model Number : displays real phone's hardware model.
>System Status : displays intact-ness of /system partition.
>Binary Status : displays intact-ness of other partitions like boot (kernel) or recovery etc.
>KNOX Status : displays the hardware e-fuse status for warranty purposes. Anything other then 0x00 means its tripped.
>Letters B/K/S : letter B means bootloader version number, K for kernel's and S for system's version number. You cannot flash any firmware with lower numbers then displayed here because secure bootloader will always block it.
UPLOAD MODE :
There is not much info on this or any info at all for the matter. All I know per my personal experience is that it happened due to SBL (secure bootloader) error after flashing an incompatible firmware. It can be due to any other software or hardware reasons, but my guess is that it protects phone from becoming a complete brick in case of bootloader error or corruption. But again, its so scarce that hardly any reliable information exists about it and I'm not gonna brick my phone just to see if it really 'works'
FRP LOCK :
FRP lock is the factory reset protection, it kicks in two ways.
1. You had oem unlock off and you forgot to delete your/last google account on device before factory resetting it and for some reason you also forgot that google account's password, so this frp lock kicks in and you need to login with that last google account to regain access to your phone, this is basically an anti-theft measure, also ironically there were/are ways to bypass it too ..
2. If you disable oem unlock after rooting/modifying/installing custom binaries or you try to root/modify/install custom binaries without enabling oem unlock first, you get custom binary blocked by frp on next boot, for solving this you just need to flash back stock rom.. and login with last google account password if required ..
3. Its a bit same like no. 2, but this one is a dreaded and notorious issue.. happens when your drk or efs gets corrupted due to any reason and you also "Accidentally" turn OEM Unlock OFF (lmao) . Now when you flash custom binary you get the same frp lock as no. 2, BUT you cannot boot stock rom back to Enable OEM Unlock due to drk error/efs corruption (which prevents even stock rom from booting up because of dm-verity error) and you cannot fix drk/dm-verity error by flashing no verity zips.. because custom binary block by frp error.......
So now you know its not a good idea to do "Accidents"
COMBINATION BINARIES :
Combination binaries are troubleshooting firmwares developed specially for repairing by samsung which don't have dm-verity checks as well as no developer options either, which mainly can be used to fix imei/efs issues AFTER restoring a backup which you are SURE to be WORKING and taken from an earlier/working environment..
Sometimes combination roms can fix efs/imei and network issues without restoring a working earlier backup (in case of some software bug), though this only works if the original factory efs of your phone is intact ..
NOTE : AS OF NOW, LATEST COMBINATION ROMS FOR VERSION 7 AND 8 BINARIES AREN'T AVAILABLE ON THE POPULAR AND TRUSTWORTHY SOURCES - NOT EVEN ON PAID ONES. SO EITHER DON'T UPGRADE YOUR PHONES TO LATEST BINARIES OR DON'T MESS THEM UP SO THEY DON'T REQUIRE COMBINATION ROMS TO FIX THEM
--------------------------------------------------------------------​
MAIN GUIDE AND ISSUES TROUBLESHOOTING
NOW THAT YOU HAVE READ MY ENCYCLOPEDIA, I WILL BEGIN WITH MY DARWIN PHILOSOPHIES
1. DEVELOPER OPTIONS AND OEM UNLOCK :
Developer options are the first step when you want or even think of modifying/rooting your device in anyway. You go in about section of your phone and tap build number 8 times to enable developer options and then you need to ENABLE OEM UNLOCK BEFORE MODIFYING/ROOTING YOUR DEVICE IN ANYWAY POSSIBLE
FLASHING ROMS AFTER ENABLING OEM UNLOCK DOES NOT CHANGE ITS STATE
BE WARNED : CLEARING DATA OF SETTINGS APP OR FOLLOWING ANY GUIDE ON INTERNET TO DISABLE DEVELOPER OPTIONS AFTER ROOTING/MODIFYING YOUR PHONE CAN RESULT IN OEM UNLOCK BEING TURNED OFF AND YOU GETTING THE CUSTOM BINARY BLOCKED BY FRP MESSAGE
AND YES PLEASE DON'T ACCIDENTALLY TURN OEM UNLOCK OFF FOR HEAVEN'S SAKE
2. USB DEBUGGING :
Although not vital, but usb debugging is needed for using adb from your pc and adb has many useful commands if you like digging in the linux shell, plus many no-root apps require adb commands to make them run some useful functions without root.. I recommend keeping it on just in case.
3. DM-VERITY ERRORS :
Ah yes, I hate this one, this is one of the most notorious errors I have ever seen, DM verity as told above is a system integrity check for modifications, but this dm-verity thing on occasion can make a hard brick coupled with some kind of encryption in the kernel/bootloader, Master @Chainfire describes such behaviour in one of his posts here, it was on nougat though and I can only expect it to be worse on oreo ..
https://forum.xda-developers.com/showpost.php?p=72204306&postcount=978
In simple terms a s7 can become a partial hard brick IF user had no access to a working rom (due to dm-verity) and custom recovery is broken/can't be flashed (due to OEM Unlock being turned off) ..
What worries me most, is that I could not get my device in any sort of booting state without formatting /data and /cache in recovery (something that you would normally be able to do through ODIN by flashing empty images). This means that if you end up in this broken state and for any reason recovery isn't functional, your device may be unrecoverable and essentially bricked. It is certainly not unheard of to have a broken recovery, especially on Samsung devices. Combine the two, and it is a certainty that some users will eventually end up bricked.
Click to expand...
Click to collapse
So, if anyone modifies their system partition after root without disabling dm-verity check in the stock kernel or they root using non-systemless method or they did a swipe for system modifications in twrp or they installed any non-systemless mod, they get dm-verity error.. For most part a dm-verity error due to a modified system partition on a rooted phone can be easily fixed by flashing no-verity zips in twrp recovery ..
OR by flashing a stock firmware of matching binary through odin ..
Even if you have accidentally turned oem unlock off, you simply reflash stock firmware and go in developer options to re-enable oem unlock. This is what I call type 1 dm-verity which is the easy one to fix ..
NOW, lets see another scenario where some people accidentally turned oem unlock off (yeah believe me there are tons of users doing this these days lol) and for those people dm-verity was not going away even after a stock firmware reflash and because they turned OEM UNLOCK OFF they could NOT flash custom binaries to bypass dm-verity either.. HENCE THEIR DEVICE WAS IN A STATE OF SEMI-PERMANENT HARD-BRICK..
My search revealed that a corrupted/missing DRK in EFS partition was actually the root cause of this type of dm-verity error, such unfortunate users CANNOT EVER REVERT BACK TO A STOCK UNMODIFIED ROM (without restoring an intact DRK backup) and they ALWAYS HAVE TO FLASH NO VERITY ZIPS TO USE/BOOT STOCK ROM..
But if OEM UNLOCK IS TURNED OFF, they get STUCK BADLY because device rejects any custom binaries like no-verity zips and twrp etc ..
My further search concluded that since the stock recovery kicked in dm verity, So if the AP file of firmware is extracted and stock recovery is deleted from it, while the boot.img is renamed as recovery.img and only system.img alongwith renamed recovery.img is repacked and flashed alongwith BL, CP and CSC, it allows users to BOOT into stock rom to ENABLE OEM UNLOCK AGAIN and use their device with custom binaries, and so their device is back to the living once more
The exact steps are as follow :
1. Extract the correct matching-binary firmware package.. then extract the AP file, and copy boot.img and system.img to a new separate folder ..
2. Rename boot.img to recovery.img and repack this renamed recovery.img alongwith system.img (only these 2) using autotar tool (I've posted the link to autotar tool now although it gets detected as a virus, So download at your own risk) or any other tar packing utility ..
AutoTar Tool
3. Flash this modified AP using latest odin along with BL, CP and CSC (not HOME_CSC) and only tick auto reboot and f.reset in odin options ..
Your phone should boot now and you can ENABLE OEM UNLOCK to flash custom binaries and make your phone usable again.. personally tested that this method works ..
BE WARNED THAT THIS METHOD REQUIRES ATLEAST 10% BATTERY FOR FLASHING AND BOOTING
Since many devices had been hard bricked for months and battery being drained completely, they couldn't boot or complete flash due to their phone becoming dead in the middle of flashing process or booting process ..
I recommend charging phone by a wireless charger in this state (since wireless charger is said to be working even in bricked state, also connecting it to a charger while in download mode may give it some charge) or simply try continously to boot it, if flash using above method is successful then don't reflash anymore just try to boot phone while putting it on charger ..
And hopefully your device will get out of this dreaded dm-verity + frp lock due to custom binary ..
Here's my original post for such dm-verity fix : https://forum.xda-developers.com/showpost.php?p=82294339&postcount=11
WARNING : MULTIPLE INTERRUPTED/INCOMPLETE FLASHES DUE TO NO BATTERY OR BATTERY DYING IN THE MIDDLE OF FLASHING PROCESS CAN CAUSE PERMANENT UFS CHIP HARDWARE DAMAGE !!
END NOTE : ALL OF DM-VERITY ISSUES ONLY HAPPEN ON A FULLY STOCK ROM WITH STOCK BOOT/KERNEL AND STOCK RECOVERY, ONCE A CUSTOM ROM OR CUSTOM BOOT/KERNEL AND CUSTOM RECOVERY ARE FLASHED, THEN THERE MAY NOT BE A NEED TO FLASH NO VERITY ZIPS, BECAUSE DM-VERITY MAY ALREADY BE DISABLED IN THE CODE. REFER TO YOUR RESPECTIVE ROM THREAD FOR THE REQUIRED INFO.
4. FORCED ENCRYPTION :
My personal experience and testing with root on android 8.0 stock oreo made me conclude that for some reason, the latest twrp as well as tkkg's modified twrp (which only supports quota) fails to mount /data even after formatting, when we reboot first time into system after formatting data and then go again in twrp, twrp fails to see /data again ..
Well, this is not a huge problem BUT if due to any reason your phone got in a non-fixable bootloop and you still got valuable data on it, then there's no practical way to recover it, except copying and moving it from twrp to external sd card/usb otg ..
So yeah an accessible /data is a big factor for me to have it working ..
Tkkg's post on encryption : https://forum.xda-developers.com/showpost.php?p=77296095&postcount=2228
link where he says he hasn't added encryption support : https://forum.xda-developers.com/showpost.php?p=77314388&postcount=1251
I first thought that latest official/tkkg's twrp would have fixed this problem, but even when forced encryption is disabled using zips, every twrp I tried could not see /data partition ..
EDIT : OFFICIAL TWRP 3.3.1+ WORKS BUT WE NEED TO FLASH MAGISK RIGHT AFTER BOOTING TWRP FOR FIRST TIME AFTER DOING A FORMAT DATA UNDER WIPE OPTIONS, AFTER THIS REBOOT TO SYSTEM, AND ENCRYPTION WON'T COME BACK AND YOU WOULD BE ABLE TO ACCESS DATA AFTER EVERY REBOOT IN TWRP !!! SEEMS LIKE IF NO MAGISK = NO /DATA ACCESS IN TWRP OR IN OTHER WORDS "FORCED ENCRYPTION"
5. ODIN ISSUES :
Many users on the forums reported issues with flashing via odin, my own experience and research tells me it can be due to :
》You're using a wrong model firmware.
》You're using a counterfeit/modified phone whose real hardware model is different then what's displayed.
》Your phone's internal nand storage hardware got faulty and fails to write anything on it.
》Odin's version is wrong and/or you got a fake software (can happen when downloading odin from fishy webs)
》Either your PC/Samsung usb drivers/usb cables/usb ports got some bugs/issues.
》Smart switch is running in background processes and it is known to mess with odin flashing (often that's the culprit)
You can try to download odin from a reputable web, re-verify that you're using correct firmware and smart switch isn't running as a background process. Also try checking with some other usb cables/ports or PC. Also verify that your phone isn't a counterfeit product (hardware modified)
If you were already rooted or flashed a custom rom before, and you're sure that OEM Unlock is enabled in developer options, you can try flashing twrp in odin and then a custom rom through twrp - as a last resort. But if you haven't rooted/enabled OEM Unlock before, this won't work either and you may had to take your phone to a repair shop
Heads Up : Incase you didn't knew, but if odin fails a flash or flash gets interrupted at or during sboot.bin (the bootloader flashing step) or you flash a wrong bootloader which unfortunately download mode couldn't stop from getting flashed, it can cause hard bricking due to corrupted bootloader (no download mode) and can only be fixed via UART interface using a hardware repair box. Ofcourse this doesn't include failed flashes at sboot which are due to download mode blocking the flash (its actually protecting itself from flashing a wrong/incompatible bootloader)
6. ROOTS AND SYSTEM-LESS ROOTS :
I guess in all my rant you must have noticed that the biggest problem comes in when efs partition becomes corrupted specifically, now when i searched countless pages of users and their issues I came to conclusion that somehow ROOTS using system modifications and also TWRP with system modifications enabled HAVE A HIGHER CHANCE TO MESS/CORRUPT EFS PARTITION, specifically the FULLY MODIFIED CUSTOM ROMS OUT THERE (AND NO I AM NOT BLAMING ANY CUSTOM ROM OR DEV, JUST THAT A FULLY ACCESSIBLE SYSTEM PARTITION HAVE MORE RISK OF CORRUPTING EFS PAR MY OBSERVATION- I hope to be wrong lol)
Now, thats where system-less roots come in !!
THEY ARE SIMPLY AWESOME AND NOT BECAUSE I AM A FANBOY OF MAGISK BUT BECAUSE THEIR ACCESS TO SYSTEM PARTITION IS TOTALLY INDIRECT WHICH INTURN PASSES SAFETY NET CHECKS TOO.
SYSTEM-LESS ROOTS ARE ONE OF THE BEST EVOLUTION OF ROOTS, IN MY VIEW SYSTEM-LESS ROOT AND SYSTEM-LESS CUSTOM ROM DEV BASE ARE ONE OF THE BEST ROOT AND ROM RESPECTIVELY NOT BECAUSE IT ONLY PERFORMS WELL AND FEELS STABLE BUT BECAUSE IT HAS THE LEAST TENDENCY TO CORRUPT EFS BECAUSE IT IS MUCH MORE CLOSER TO STOCK ROM! A BIG SHOUT OUT TO @_alexndr FOR HIS SUPERB SYSTEM-LESS DEV BASE.. AND THE BEST THING IS THAT DOWNLOAD MODE REPORTS SYSTEM AS OFFICIAL AND PASSES SAFETY NET EVEN WHEN YOU'RE ROOTED AND USING EDXPOSED !
THAT BEING SAID, THE BIGGEST REASONS OF EFS CORRUPTIONS ARE NOT DUE TO CUSTOM ROMS, BUT DUE TO THE VARIOUS MODS AND INCORRECT FOLLOWING OF FLASHING/INSTRUCTIONS WHICH CAUSE THIS.. AND SOMETIMES FAULT/ERROR OF THE HARDWARE TOO.. AND VERY RARELY ITS A MISTAKE ON DEV'S PART ..
Moving on to root types, you got Super SU along with its system-less root option and Magisk (has system-less root as default); both have hiding root options as well, you just need to choose your preference and flash it in twrp.. I really don't recommend king root or any other root types !!
FOR USING SYSTEM-LESS ROOT KEEP SYSTEM READ ONLY IN TWRP!!! (DO NOT SWIPE TO ALLOW SYSTEM MODIFICATIONS WHEN BOOTING IN TWRP FOR FIRST TIME AND TICK DON'T ASK ME AGAIN)
BE AWARE ! CHOOSING SYSTEM MODIFICATIONS IN TWRP WILL AUTOMATICALLY CAUSE NON-SYSTEMLESS ROOT METHOD !
ALSO : WITH MAGISK ONE NEEDS TO FLASH IT AFTER FLASHING NO VERITY ZIPS IN TWRP (IF USING MAGISK IN NON-SYSTEMLESS MODE OR DUE TO DRK BEING CORRUPTED)
Please note that CF Auto root is now obsolete for s7 series on version 5+ binaries ..
7. BOOTLOADER EXCEPTION BUG (SBL ERRROR) :
Another rare and possibly dangerous bug, ironically I encountered it on my first days of getting this device
That screen was terrifying for a noob like me at that time lol, now how did I got it in first place ?
Yeah I tried to be a smart-ass and flashed a normal bootloader along with a combination firmware in odin lol (tried to bypass bootloader blocking flash of lower binary version), flash was successful and when phone booted it caused bootloader exception bug ..
And what I did to solve it ? Simply hold home button until you see upload mode and then force reboot by combination keys and then immediately hold download mode combination keys to go in download mode and reflash stock rom
Seems like other people on forums weren't that lucky to get out of this error easily
Possibly, this error can also be caused by some hardware fault/bug.
Further investigation revealed that SBL error (secure bootloader error) is particularly a semi-corrupted bootloader which in reality would cause the device to become a hard brick which can only be recovered through UART interface using a hardware box (which essentially requires us to open phone's guts), but instead it caused bootloader to get in a fail-safe 'UPLOAD MODE' which is surprising actually because any wrong bootloader flash is sure to make your device a permanent brick.
So better NOT cross-flash firmwares or bootloaders not designed for your phone, specially which are apparently made for same hardware as yours but you may not be that lucky to get in upload mode after that, So :
>Don't try to flash a G935F (global) bootloader on a G935W8 (Canada variant) or G935V/T/A/U (US variants) or G9350/K/L/S (Chinese/Korean/Hongkong variants etc) and vice versa.
>Don't try to flash a G9350/K/L/S (Chinese/Korean/Hongkong variants etc) bootloader on G935V/T/A/U (US variants) or G935F (global) or G935W8 (canada variant) and vice versa.
>The above instructions includes both normal and combination firmwares. Also don't try to flash normal firmware's bootloader with combination firmware or vice versa.
>Don't try to downgrade bootloader by 'any method'..
>Don't use any 'patched odin' to flash an incompatible firmware.
>Don't try to flash bootloader using flashfire/twrp or any other mobile flashing utility.
8. NETWORK AND IMEI'S ISSUES :
Regarding loss of network signals, there are 2 possibilities, either that your imei got deleted/corrupted due to a bad efs partition or your phone's imei was changed and a network certificate patch was used to make it working, and you reflashed your phone through odin or any other flashing method which removed that network certificate patch and you lost your signals ..
Now both can be fixed only by a box or box-like alternative see this thread link for more info :
1. https://forum.xda-developers.com/s7-edge/how-to/fix-imei-downgrading-g935f-fd-t3947911
Remember : There's always a risk of bricking your device or screwing it further by using such (box-free) tools ..
Moreover, signals can be lost when flashing old modem on newer bootloader, it can be fixed by reflashing correct firmware (matching bootloader version) for your phone ..
Signals can also be lost by a bugged out csc (probably due to a bad efs), for solving this you can try changing your csc code by flashing different csc firmware with matching bootloader version (preferably a single csc firmware like dbt/xeu) and then reflashing your original csc to revert back and applying the fix mentioned in No. 1 thread link above.
A bugged out/corrupted efs is often the main culprit for signals issue, which needs combination rom with matching bootloader version and/or an earlier working efs backup to fix it.
See this thread link below for more on this :
2. https://forum.xda-developers.com/s7-edge/how-to/guide-how-to-fix-check-drk-imei-issues-t3379516
Another option is if you got an older working efs backup, just restore it and then give appropriate permissions and then flash combination rom for your rom, but problem is.. you need quite a bit of linux command knowledge and updating the permissions according to your own phone and android version (originally it was done on note 4) plus combination roms for latest binaries are not getting released into public now !!
Please refer to this thread link of note 4 below :
3. https://forum.xda-developers.com/note-4/general/fix-drk-dm-verity-factory-csc-serial-t3422965
As a token I provide my phone's DRK, the prov_data folder (for getting rid of dm-verity error by following No. 3 thread link of note 4 above).. if anyone experienced and interested enough wants to experiment to fix their drk/dm-verity errors permanently ..
NOTE : As policy of xda, I'm not sharing any imei/personal phone data, but just a DRK encrypted key which could benefit users with dm-verity and drk errors, if anyone finds it against xda's terms or rules, feel free to report my shared prov_data (but it has already been shared before for note 4)
BUT EVEN WITH THIS PROV DATA AND SUCCESSFULLY GIVING PERMISSIONS YOU WOULD STILL NEED COMBINATION ROM TO FIX DRK AND SIGNALS/IMEI AS STATED IN NOTE 4 THREAD !
ALSO THIS WILL ONLY WORK ON DEVICES BEING ROOTED AND IN WORKING CONDITION !
TIP : WELL, SOMETIMES YOU TRAVEL ALL THE WORLD TO FIND SOMETHING WHEN ITS ALREADY THERE IN YOUR HOME OR NEIGHBOURHOOD AND SAME THINGS CAN HAPPEN WITH THESE ISSUES TOO, IN THE END YOU DID EVERYTHING YOU CAN TO TRY AND GET YOUR SIGNALS FIXED WHEN YOU JUST HAD TO REPLACE YOUR SIM CARD LOL
SO YEAH SIM CARD CAN BE FAULTY TOO, ALWAYS TRY CHANGING SIM CARDS FIRST IF YOU GET ANY NETWORK ISSUES. ALSO, SOMETIMES ITS THE PHONE'S MODEM HARDWARE THAT'S FAULTY AND YOU CAN'T DO ANYTHING ON THE SOFTWARE SIDE.
9. BATTERY DRAIN ISSUES :
Ever since the version 7 binary update i.e december 2019 security patch and later, I noticed my phone draining battery heavily due to android system and kernel.. and I lost almost 50% of s.o.t and also created this warning thread here :
https://forum.xda-developers.com/showpost.php?p=81410317
SO YEAH. I RECOMMEND USERS TO NOT UPDATE TO VERSION 7 BINARIES OR LATER !! IT WILL ONLY CAUSE A DELIBERATE SAMSUNG CREATED BATTERY DRAIN TO PUSH USERS FOR UPGRADING THEIR PHONES !
10. BINARY UPDATES :
Since samsung has officially made s7 series eol, the updates they will now push would always to some extent, try to limit device in some ways - like the huge battery drains with version 7+ binaries and the fact that you cannot downgrade, the whole point is that they want users to upgrade their phones and hence they will push such updates which will further limit our device !
Also let me tell you, once S7 reaches Version 11 or in other words 'B' binary, its stated that twrp will not work and I think even root will be much harder to achieve and sustain.. if I'm wrong then I request someone to please correct me
ALL IN ALL, UPGRADING BINARIES WILL ONLY CAUSE YOU TO BE STUCK ON EVEN WORST FIRMWARES !!
I REALLY RECOMMEND TO NOT UPDATE YOUR PHONES ANYMORE !!
11. PERSONAL RECOMMENDS :
I am not the one to recommend anyone something but if you do want to get root but want stability, unmodified system-partition, less risks of your phone being messed up or simply you care for your phone's health; this is still a great phone
I heavily recommend alexndr's custom devbase rom or if you don't want that debloated stock rom, you can just use his system-less devbase root option too.. along with system-less Magisk ..
AND MY BIGGEST RECOMMENDATION IS :
ALWAYS BACKUP YOUR EFS AND NV DATA PARTITIONS FIRST THING AFTER ROOT !!!
This is it from this noob guide of mine, thanks for reading such a long "rant", I hope it would benefit you. My original aim was to create an END OF LIFE GUIDE for S7 series combining various info, and I think I'm partially successful in it
I'm always open to add new info and/or correct anything which I mentioned wrong, also if you need any help feel free to post a reply.. I'm not able to help remotely anymore though
But no matter, all the info I learned remains archived in this thread till the end of times
USEFUL LINKS :
ODIN
ODIN
SAMSUNG STOCK ROMS
SAMSUNG USB DRIVERS
OFFICIAL TWRP
SUPER SU
SUPER SU
MAGISK
MAGISK
SYSTEM-LESS ROOT DEVBASE
SYSTEM-LESS DEVBASE ROM
NoVerityOptEncrypt
NoVerityForceEncrypt
ALL CREDITS TO THEIR RESPECTIVE CONTRIBUTORS​

.............................

shah22 said:
.............................
Click to expand...
Click to collapse
https://www.reddit.com/r/GalaxyS7/comments/qn5q99
What do you think about that problem?

Question the boot.img file was downloaded to my phone to root it and then it has no identifiable imei number

the boot.img file was loaded into my phone in order to get root after that it could not detect imei numbers. Although they are in fastboot. I tried many different firmwares for this phone, but there is no result! I ask for your help. I was left without communication (sorry for not being very clear. I don't understand Russian and don't understand English at all, that's why I'm writing through a translator

The first thing you want to do is STOP FLASHING random images. It sounds like you are going to cause more harm than good if you keep going.
Figure out which firmware you started on (WW, EU, CN) and get the raw firmware for it. Follow the instructions to flash the raw firmware.
If that doesn't work, then you may need to contact the manufacturer, BUT at least you will be restored to stock. I cannot promise they will help you, but it sounds like you did more than flash a boot image. The IMEI is not stored there.

twistedumbrella said:
The first thing you want to do is STOP FLASHING random images. It sounds like you are going to cause more harm than good if you keep going.
Figure out which firmware you started on (WW, EU, CN) and get the raw firmware for it. Follow the instructions to flash the raw firmware.
If that doesn't work, then you may need to contact the manufacturer, BUT at least you will be restored to stock. I cannot promise they will help you, but it sounds like you did more than flash a boot image. The IMEI is not stored there.
Click to expand...
Click to collapse
Tell me where you can find the pure CN firmware? This phone was presented to me in this form already. And they told what happened to him. I doubt that ASUS support will help me, since in addition to everything according to the owner, the EMMCCDL_GUI utility was used. So I ask for help from knowledgeable people here.

And most importantly, what to flash and how?

Repair your ASUS ROG Phone 5 with EDL mode
If your phone can only enter EDL mode (9008 mode) this firmware is glad to help you. It can be flashed in through the miflash tool. The firmware is made through the official package...
forum.xda-developers.com
RAW Firmware Collection and Guide
All fastboot / adb commands require using the side USB-C port https://developer.android.com/studio/releases/platform-tools.html#download Make sure you have fastboot installed Add platform tools to PATH (post 2) Make a backup of anything...
forum.xda-developers.com

twistedumbrella said:
Repair your ASUS ROG Phone 5 with EDL mode
If your phone can only enter EDL mode (9008 mode) this firmware is glad to help you. It can be flashed in through the miflash tool. The firmware is made through the official package...
forum.xda-developers.com
RAW Firmware Collection and Guide
All fastboot / adb commands require using the side USB-C port https://developer.android.com/studio/releases/platform-tools.html#download Make sure you have fastboot installed Add platform tools to PATH (post 2) Make a backup of anything...
forum.xda-developers.com
Click to expand...
Click to collapse
did not help(

What? So no one will help ???

Return the phone or wait until the methods exist.
Those are the only quick answers left.

twistedumbrella said:
Return the phone or wait until the methods exist.
Those are the only quick answers left.
Click to expand...
Click to collapse
It was opened. This is not an option either

If you purchased it used and the seller refused a return, it sounds like they were trying to recover what they could by selling their problem to someone else. It's likely they knew there wasn't a self-service fix right now.
Just to be clear, what you need is a low-level EDL restore. As it stands, one of the files required is not available to the public. If you have a local repair shop, they may be able to do it (and will likely charge a fee).
Do NOT pay someone over the internet. It CANNOT be done remotely.