Database Info

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.

[PROJECT] Real Unbrick for hard-bricked Moto Z Play (addison)

Welcome everyone!
This project has started, becouse we need real solution for the problem. The problem of hard bricked Moto devices. It is like a curse.
When my device bricked I have done solid research, I have gathered many informations and files essential to revive my cellphone but 5 years experience of linux, rooting, compiling kernels and roms weren't enough to make it work.
But nevermind. I am even more determinated and I am asking ALL of You guys here to help me. Together we will come to solution.
Here is what I got, happy reading :
DICTIONARY:
PBL - Primary bootloader of the chip - this is like BIOS for phone so it checks chip for damage and problems and then it tries to load SBL but if SBL is corrupted or checksum doesn't match, PBL invokes Qualcomm HS-USB QDLoader 9008 emergency mode. PBL is hard flashed into SoC and can't be corrupted by firmware.
SBL - Second stage bootloader wich is more advanced than PBL. It initializes phone hardware and ABOOT.
ABOOT - Application bootloader (HBOOT). You probably know this one well. Android botloader.
Full mmcblk0 backup - Backup of whole phone flash storage byto to byte.
blankflash - method of repairing msm phones in 9008 state
programmer.mbn - Special type of software programmer that is being sent to chip in Qualcomm 9008 emergency mode. There it comunicates with pc via firehose protocol. Each phone has set of their own programmers, they are unique to phone and other programmers don't work. These programmers are signed so tampering it results in not working one.
firehose protocol - it is used to tell programmer what operations it must do on chip.
singleimage.bin - this package contains instructions for programmer and set of files it need (for example to replace)
gpt_main0.bin - Partition layout
rawprogram0.xml - instructions for programmer
patch0.xml - I don't know yet
STAR.exe - Application for managing and editing contents of singleimage.bin aka blankflash files
QPST - Flash tool from Qualcomm it basic function is to handle blank-flashing in a better way, also it allows for in-depth debugging of the process
Qualcom Premium Tool - Program made by Mppg Myanmar that is capable of making unlocking bootloader, OEM locks, making backup/restore of chip firmware, handling blank-flashing in VERY specific way (creating instructions for programmer), reading eMMC structure from firmware (can generate gpt layout so very useful!!!), modyfing FW and removing Xiaomi account. It also contains ALL programmers
for more:
https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565
https://alephsecurity.com/
https://github.com/alephsecurity/firehorse
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick
INFO:
1. What causes the brick
I bet 100$ that you hard-bricked your Moto Z Play by installing OTA updates after downgrading firmware. This is only known reason for me at the time of writing this. There is most probable reason why it happens, look:
There are two most common chips on which smartphones are built - Qualcomm and Mediatek. While Mediatek chips are "modification friendly" and simple, Qualcomm chips are somewhat more advanced and have many features that can be enabled or disabled during prorammming in factory. One of them is PBL signature checking. During programming of your phone, proper signatures of SBL are written to it. When someone tries to override default SBL with the new one, it checksums are compared with that stored. If they match, new one is flashed, if not, then update does not happen.
Ok, but what it has to do with brick?!
I explain:
1. You decide to downgrade your firmware
2. During flashing, everything goes "well" (Phone boots), but trully update is partial:
FW in chip is (obviously) more recent that the one you downgrade to, and SBL signature is different (updated), so when it is compared to the signature of SBL from FW you want to flash, it don't match. That don't rise error and flashing continues. Only partition that stays untouched is bootloader, but all other partitions get replaced by those in FW zip. SBL is still compatible with the new partition offsets and partition layout overall so phone functions normally.
3 When OTA is executed, it checks the version of currently installed firware. The most reliabe way to do it is to check checksum of SBL which is pretty logical becouse it's checksum is like "fingerprint" of firmware. Normally, if it would detect the old firmware, OTA would be stopped, but newer SBL tricks it and OTA installs anyway.
4 Results are horrible, becouse OTA does not check GPT table and flashes partitions in bad sectors, corrupting FW.
This causes bootloader to go into Qualcomm HS-USB QDLoader 9008 safe mode.
5 Viola! Hard brick!
2. How to fix it?
That is jolly good question! What we have to do is to reflash full chip firmware. Suprisingly I see some solutions, but those need to be developed:
A) SD-BOOT
It turns out that our fancy chip can probably boot from SD-CARD! The procedure works like this:
- When chip starts, one of the very first things it does is loading the memory, so it can actually work. The trick, is that chip loads it from specific disk, marked with exact name (I don't remember which, but I will do research). Speccially repared SD-CARD can appear with that name, so chip boots from it, not from internal memory. (This trick is proved to work on this model)
How to do it?
- Get full dd of working phone - it must be phone with the SAME chip and very likely the same model
- flash it to SD-CARD of 32GB or more, class 10 speed or higher, directly to card, not partition
- put card in phone, turn it on and wait
- you should see HBOOT
- select fastboot and flash new FW via it
- viola!
!!!THIS IS COMPLICATED PROCEDURE, I WILL MAKE DETAILED THREAD SOON, BUT FOLLOW IT ONLY IF YOU KNOW WHAT ARE YOU DOING!!!
B) FIREHOSE/SAHARA ATTACK
This could be achieved by sending payload via Firehose programmer that would allow to break verification of SBL or somehow allow SBL to be flashed. Now, PBL blocks attempts to update SBL. I have thesis that it is becouse PBL do not allows for SBL downgrade, so it's version must be higher, but we try to flash same version of SBL so it doesn't work. That thesis needs confirmation.
C) CRAFT BLANKFLASH
This would be last resort. It will work for sure, but this method needs knowledge and I don't know if it is doable.
STEP 1: Get white-listed blankflash checksums from OTA (we would need to reverse engineer those)
STEP 2: Break hash
STEP 3: Craft blankflash with needed hash
STEP 4: Flash
NEVER USE BLANKFLASH (ATTENTION!)
DO NOT try any blankflash files. They can make situation a lot worse and even physically (!) dmage your phone.
D) JTAG
Medusa Box etc.
E) Qualcomm Premium Tool
This can even work, but it is untested and there is a slight chance that can worsen state of phone (needs confirming).
The tool is very advanced and I need to gather info about usage, so very probable to be a good solution if we will learn how to use it!
E) METHOD 7
Interesting method from this guy: (7th option, I have contacted him if it is compatibile)
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick/blob/master/Unbrick%20methods.md
3. DOWNLOAD
(Links will be aded *soon*)
XDA:DevDB Information
Unbrick Developement for Moto Z Play (addison) Full-Brick, Tool/Utility for the Moto Z Play
Contributors
Bobernator, Stayn, Artim_96, Camarda
Version Information
Status: Nightly
Created 2019-05-04
Last Updated 2019-05-14

I really hope we can get a fully working detailed method to unbrick this device, I'll follow this project and try to help what I can, my phone isn't bricked but I think that an unbrick guide is absolutely necessary.
By the way, did you tried the Qualcomm Board Diag method? Before the Moto Z Play I had a LG G3 and got it hard-bricked and my pc would recognize it as "Qualcomm HS-USB QDLoader 9008" too, using the Board Diag method I got to erase completely the emmc and flash each partition manually, that got it back to life again, of course theres a requirement and it's the AP Chipset files. I don't know if you already tried so you tell me

Stayn said:
I really hope we can get a fully working detailed method to unbrick this device, I'll follow this project and try to help what I can, my phone isn't bricked but I think that an unbrick guide is absolutely necessary.
By the way, did you tried the Qualcomm Board Diag method? Before the Moto Z Play I had a LG G3 and got it hard-bricked and my pc would recognize it as "Qualcomm HS-USB QDLoader 9008" too, using the Board Diag method I got to erase completely the emmc and flash each partition manually, that got it back to life again, of course theres a requirement and it's the AP Chipset files. I don't know if you already tried so you tell me
Click to expand...
Click to collapse
Hi! Really nice to read that . I didn't tried it but i will chec k it out in a while. Sorry for not responding immediatelly but this will change from now, I have XDA app so I stay updated.

Have you seen this post? There's apparently a new Oreo blankflash https://forum.xda-developers.com/showpost.php?p=79514510&postcount=419

echo92 said:
Have you seen this post? There's apparently a new Oreo blankflash https://forum.xda-developers.com/showpost.php?p=79514510&postcount=419
Click to expand...
Click to collapse
Website is legit, sounds like something good, but i will byte-compare it to my other blank flashes in collection. Maby it will worsen state of my device but I will try it.
Ps. I am working on a download section!!!
EDIT: DO NOT TRY IT YET. As you can see in the link this has been uploaded 2 days ago. Post has 1 day, so this is suspicous as hell.

Bobernator said:
Website is legit, sounds like something good, but i will byte-compare it to my other blank flashes in collection. Maby it will worsen state of my device but I will try it.
Ps. I am working on a download section!!!
EDIT: DO NOT TRY IT YET. As you can see in the link this has been uploaded 2 days ago. Post has 1 day, so this is suspicous as hell.
Click to expand...
Click to collapse
I understand the reason to be suspicious, since there's also no way to verify the origin of this blankflash. Also, is there a OPNS27.76-12-22-10 firmware? I thought OPNS27.76-12-22-9 was the last build?

I will answer this way:

Bobernator said:
I will answer this way:
Click to expand...
Click to collapse
That blankflash looks like it worked - seems your device is in fastboot mode despite the photo angle.

echo92 said:
That blankflash looks like it worked - seems your device is in fastboot mode despite the photo angle.
Click to expand...
Click to collapse
Yes, it worked! But do not make misteake and after you flash blankflash do not flash full firmware. Instead flash only recovery - TWRP and make backup of modemst1, modemst2 and FSG partitions, so you can revert your IMEI. After that full flash android 8 FW

Bobernator said:
Yes, it worked! But do not make misteake and after you flash blankflash do not flash full firmware. Instead flash only recovery - TWRP and make backup of modemst1, modemst2 and FSG partitions, so you can revert your IMEI. After that full flash android 8 FW
Click to expand...
Click to collapse
Can you see your recovery partition with the dummy bootloader from the blankflash? Do you have to flash the GPT/bootloader from firmware first?

Well, this is nuts @Bobernator, I'm really happy we have an unbrick method.
If MTP is still working, you can flash the file I attached to this post to automatically backup the required partitions, this can also be helpful in case anyone wants a full IMEI Backup, also, I tried this step:
fastboot flash fsg mmcblk0p29_fsg_backup
fastboot flash modemst1 mmcblk0p27_modemst1_backup
fastboot flash modemst2 mmcblk0p28_modemst2_backup
Click to expand...
Click to collapse
and it gives me permission denied when flashing modemst1 and modemst2, I think we should flash modem NON-HLOS.bin and erase modemst1 and modemst2, if you agree I'll update the zip I made to backup NON-HLOS.bin instead of modemst1 and modemst2

Quick question, is it worth mentioning only to perform steps 12 and 13 (flashing your FSG and modemst backups) if your device has no signal/IMEI issues after flashing the Oreo firmware? Just wondering since the firmware flash and subsequent boot may correctly rebuild the modemst files...

echo92 said:
Quick question, is it worth mentioning only to perform steps 12 and 13 (flashing your FSG and modemst backups) if your device has no signal/IMEI issues after flashing the Oreo firmware? Just wondering since the firmware flash and subsequent boot may correctly rebuilt the modemst files...
Click to expand...
Click to collapse
I don't know for sure but a backup is always recommended and more if it is the IMEI, then, you can flash all partitions and then before restoring the backup boot into the system and check by yourself if you're getting signal and its working... :good:

Stayn said:
I don't know for sure but a backup is always recommended and more if it is the IMEI, then, you can flash all partitions and then before restoring the backup boot into the system and check by yourself if you're getting signal and its working... :good:
Click to expand...
Click to collapse
Yup, an IMEI backup is always useful Just wanted to ask since it's not pointed out in the opening post's guide to check your IMEI/signal before committing to step 12/13. If it's working, no need for those two steps!

@echo92 I forgotten about IMEI totally so I can't tell you, but I can't confirm that's safe to flash gpt and bootloader from OREO fw (8.0). I did this way and everthing is working. Even OTA updates to most recent witouth problems! Here are the proofs (language is "Polish" if you want to translate):

Stayn said:
Well, this is nuts @Bobernator, I'm really happy we have an unbrick method.
If MTP is still working, you can flash the file I attached to this post to automatically backup the required partitions, this can also be helpful in case anyone wants a full IMEI Backup, also, I tried this step:
and it gives me permission denied when flashing modemst1 and modemst2, I think we should flash modem NON-HLOS.bin and erase modemst1 and modemst2, if you agree I'll update the zip I made to backup NON-HLOS.bin instead of modemst1 and modemst2
Click to expand...
Click to collapse
I really appreciate this! Thanks!
If you update your ZIP, I will attach it into the project today, and I will try to find out solution for you, becouse it looks if you can't restore IMEI now (correct me if I am wrong)

echo92 said:
Yup, an IMEI backup is always useful Just wanted to ask since it's not pointed out in the opening post's guide to check your IMEI/signal before committing to step 12/13. If it's working, no need for those two steps!
Click to expand...
Click to collapse
You are surely right. I will correct thread today.

Bobernator said:
I really appreciate this! Thanks!
If you update your ZIP, I will attach it into the project today, and I will try to find out solution for you, becouse it looks if you can't restore IMEI now (correct me if I am wrong)
Click to expand...
Click to collapse
Don't worry about the IMEI, I got it again after flashing my fsg backup, modem and erasing modemst1 and modemst2, now the problem is that on every ROM I get everytime a popup "com.android.phone" has stopped, till I remove the sim card, what could this be? This isn't my main phone so I'm not worried at all but this could happen to someone else

Dial *#06#, if you will get nothing or zero's that means it can be modem failure
Ps. Is your zip updated now?

Hello Guys,
I have the exact same problem. All started here with a changed screen that after update to 8 stopped working, so I did downgrade to 7, and the touch as back, than it started doing the OTA updates and I (dumb enough) accepted it, and now I have a bricked device.
***EDIT***
Now I could get access to the bootloader again, the flash blank worked but it had a catch, if I just executed the bat, it would not work, I had to open a CMD with admin rights, go to the folder and run the bat from there.
***EDIT 2***
So restored bootloader, and booted just like before it was corrupted, now it keeps asking for update, and I disabled it on the "Developer Menu", is that enough? Will not play with updates on this device anymore, android 7.1.1 with 2017 security updates will do it.
***EDIT 3***
Now I have a Mobile Network problem, it does recognize the SIM Chip, but won't get network access, I didn't backup before doing the Blank Flash, but it was not showing on the system before (because the downgrade from 8 to 6, and them upgrade to 7), is there a way to recover it or fix this no network registration possible?

[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 Rooting the Pixel Tablet

Just finished rooting my new Tablet.
Unlocked bootloader, Flashed new factory image and patched Magisk all by manual methods.
PixelFlasher didn't work as it does on Pixel 7 Pro, so save some time and wait for the official support.
Happy to help if anyone gets stuck.

Thanks for the update. Which file did you patch with Magisk to get root?
Are you passing Safetynet?

Rooted the thing 5 minutes out of the box.
Magisk stable. Passes safety net.
Follow a Pixel 7 rooting thread use the latest posted images, patch init_boot.img
I disabled verity too in case a custom kernel is done in the future.

bleez99 said:
Rooted the thing 5 minutes out of the box.
Magisk stable. Passes safety net.
Follow a Pixel 7 rooting thread use the latest posted images, patch init_boot.img
I disabled verity too in case a custom kernel is done in the future.
Click to expand...
Click to collapse
Would do the same. Thank you

MArtyChubbs said:
Just finished rooting my new Tablet.
Unlocked bootloader, Flashed new factory image and patched Magisk all by manual methods.
PixelFlasher didn't work as it does on Pixel 7 Pro, so save some time and wait for the official support.
Happy to help if anyone gets stuck.
Click to expand...
Click to collapse
I don't have the tablet, so the support file would greatly help to add official support for it.
Would you be able to provide it?
If not do you recall what exactly happened?
Was it during processing, patching or flashing?
Thanks
Update:
Aside from flashing, which I can't because I don't have the tablet, the latest version of PixelFlasher is able to process, extract init_boot and create a patch without any issues both for factory image and full OTA.
I even went as far as attempting to flash factory (without actually flashing) to inspect the final flashing script, and everything in there looked right.
I don't see how / where it could have failed, based on what I've seen it should work.
Hence a support file would greatly help if there is any issue to identify.
Thanks

just unlocking the bootloader w/PixelFlasher (latest ver.) "corrupted" my Slot B boot (Your device is corrupted) and it refuses to boot (grin).
Also, I'm pretty sure it said "no init_boot found" as part of device info. I can't confirm as I'm not with the tablet today.

ntegra said:
just unlocking the bootloader w/PixelFlasher (latest ver.) "corrupted" my Slot B boot (Your device is corrupted) and it refuses to boot (grin).
Also, I'm pretty sure it said "no init_boot found" as part of device info. I can't confirm as I'm not with the tablet today.
Click to expand...
Click to collapse
If you could provide a support file from PixelFlasher I can check, and you don't need to repeat the steps to get a support file, just launch PF and hit the support button or from the help menu.
If the unlock command has not changed, I don't see how it would cause that.
All the unlock button does is
if it is in adb mode, it reboots to bootloader mode and then issues the command
fastboot flashing unlock
If it is already in bootloader mode, it just issues the command.
I'm baffled and would really like to get to the bottom of this.

badabing2003 said:
If you could provide a support file from PixelFlasher I can check, and you don't need to repeat the steps to get a support file, just launch PF and hit the support button or from the help menu.
If the unlock command has not changed, I don't see how it would cause that.
All the unlock button does is
if it is in adb mode, it reboots to bootloader mode and then issues the command
fastboot flashing unlock
If it is already in bootloader mode, it just issues the command.
I'm baffled and would really like to get to the bottom of this.
Click to expand...
Click to collapse
soonest I could provide is 6 hours or so..

@badabing2003 yeah, I'll try to get that support file within the next hour. The tool said everything was successful but it always rebooted back to the bootloader when unlocking the bootloader or flashing a new image, thus I had to do everything manually
Update: @badabing2003 Support file is attached. Thanks!

I plan on rooting mine right away. Did anyone have a delay on their order? I have a trip coming up and it's supposed to arrive the day before.

Thanks @MArtyChubbs and @ntegra for providing support files.
@ntegra
Comments / observations based on your support file.
You started with Pixel 7pro,
You had an error during flashing
Code:
Sending sparse 'vendor_b' 3/3 (130768 KB) FAILED (Error reading sparse file)
fastboot: error: Command failed
rebooting to bootloader ...
Rebooting into bootloader FAILED (Write to device failed (no link))
fastboot: error: Command failed
Sleeping 5-10 seconds ...
flashing pf_boot ...
This is communication issue, phone unplugged or disconnected during flash or wire loose or bad driver / port / cable ...
But then you flashed p7p ok,
Moved to the tablet, which was locked at this point
Code:
Selected Device on 2023-06-20 20:00:50:
Device ID: REDACTED
Device Model: tangorpro
Device Active Slot: a
Device Mode: adb
Has init_boot partition: False
Device is Rooted: False
Device Build: TD2A.230203.028
Device API Level: 33
Device Architecture: arm64-v8a
sys_oem_unlock_allowed: 1
ro.boot.flash.locked: 1
ro.boot.vbmeta.device_state: locked
vendor.boot.verifiedbootstate:
ro.product.first_api_level: 33
ro.boot.verifiedbootstate: green
vendor.boot.vbmeta.device_state:
ro.boot.warranty_bit:
ro.warranty_bit:
ro.secure: 1
ro.zygote: zygote64
ro.vendor.product.cpu.abilist: arm64-v8a
ro.vendor.product.cpu.abilist32:
Device Bootloader Version: tangorpro-1.0-9584303
Magisk Manager Version:
Magisk Path: None
Checked for Package: com.topjohnwu.magisk
You proceeded to unlock the bootloader with PF
Which it did successfully
Code:
Selected Device on 2023-06-21 06:09:09:
Device ID: REDACTED
Device Model: tangorpro
Device Active Slot: a
Device Mode: f.b
Has init_boot partition: False
Device Unlocked: True
One thing to point out, after bootloader unlock, PF keeps the phone in bootloader mode (in case you might want to do other stuff)
But I think people tend to expect it to reboot to system, because I noticed this might have thrown you off seeing it in bootloader mode.
What I'll do for the next release is that unless you select no reboot option, PF should automatically reboot.
Another thing I noticed is that you attempted to create a patch while the phone is in bootloader mode
Which does not work, because that can only work in ADB mode.
In the next version I'll disable the patch button so that when in bootloader mode, you can't press it.
I see that you rebooted to system and the device was unlocked
Code:
Selected Device on 2023-06-21 06:14:41:
Device ID: REDACTED
Device Model: tangorpro
Device Active Slot: a
Device Mode: adb
Has init_boot partition: False
Device is Rooted: False
Device Build: TD2A.230203.028
Device API Level: 33
Device Architecture: arm64-v8a
sys_oem_unlock_allowed: 1
ro.boot.flash.locked: 0
ro.boot.vbmeta.device_state: unlocked
vendor.boot.verifiedbootstate:
ro.product.first_api_level: 33
ro.boot.verifiedbootstate: orange
vendor.boot.vbmeta.device_state:
ro.boot.warranty_bit:
ro.warranty_bit:
ro.secure: 1
ro.zygote: zygote64
ro.vendor.product.cpu.abilist: arm64-v8a
ro.vendor.product.cpu.abilist32:
Device Bootloader Version: tangorpro-1.0-9584303
Magisk Manager Version:
Magisk Path: None
Checked for Package: com.topjohnwu.magisk
Installed Magisk and created a patch.
All good.
You then proceeded to flash with
Flash To Inactive Slot: True
Everything about the flashing went well, but the phone stayed in bootloader mode.
I see now why that happened.
It flashed ok, but then it tried to flash the patched image to boot partition instead of init_boot partition.
PF detects if it needs to flash into init_boot partition or boot partition by doing two checks.
1- If it is defined in PF, and up to version 5.3.2.1 only defined are 'panther', 'cheetah', 'lynx' because at the time of the release only those were known. (tangorpro added in the next version)
2- By checking partitions and seeing if there is a init_boot partition, this way it would be forward working with future devices, but sadly due to oversight the code was looking for init_boot and expecting to find it, but there is init_boot_a and init_boot_b, and not init_boot, (fixed in the next version)
@MArtyChubbs
The flashing your tablet had the same fate as above, PF tried flashing boot partition instead of init_boot.
Fixed, I should have a release later today.
For anyone who cannot wait, and wants to use PF, all you have to do is before hitting OK to continue flashing, hit the Edit script before continuing button and modify the line
Code:
flash boot pf_boot.img
to
Code:
flash init_boot pf_boot.img
As for unlocking, I don't see errors, but I see that the phone was not detected,
Do you recall exactly what happened? perhaps it was showing the wipe message and hence why it was not really yet to be detected?
Code:
2023-06-20 16:58:12 Unlock Bootloader
*** Dialog ***
WARNING!!! THIS WILL ERASE ALL USER DATA FROM THE DEVICE
Make sure you first read either of the guides linked in the help menu.
Failing to follow the proper steps could potentially brick your phone.
Note: Pressing OK button will invoke a script that will utilize
fastboot commands, if your PC fastboot drivers are not propely setup,
fastboot will wait forever, and PixelFlasher will appear hung.
In such cases, killing the fastboot process will resume to normalcy.
Do you want to continue to Unlock the device bootloader?
Press OK to continue or CANCEL to abort.
______________
2023-06-20 16:58:14 User Pressed Ok.
Rebooting device REDACTED to bootloader ...
Waiting 5 seconds ...
2023-06-20 16:58:31 No Device is selected!
2023-06-20 17:12:46 Scanning for Devices ...
No Devices found.

@badabing2003,
Thanks for the response. great program, excellent support. For me, the first p7p failed (I agree with you) due to comm problem. I forget that the USB ports on one side of my laptop are flakey. I watched it bomb out writing system_b (I think) and just moved the cable to the other side and reran the flash to 100%.
For the tablet... I ran unlock twice (was still locked after first attempt). I "want" to say that the "your device is corrupt" was in between the two runs (unlock / reboot / device corrupt / unlock again) but definitely showing corrupt before first flash attempt. After a couple attempts to boot, I put it back into bootloader (and also download & recovery modes) and flashed the patched image, but it didn't help I'm guessing because of the init_boot(_b). Will be patiently waiting (neither slot are booting-grin) for your next release. I'm in no rush.

@badabing2003 I'd like to thank you as well! Love the tool and your excellent support. You and @Freak07 are such an asset to the community as are soo many other devs...

rester555 said:
I plan on rooting mine right away. Did anyone have a delay on their order? I have a trip coming up and it's supposed to arrive the day before.
Click to expand...
Click to collapse
No, arrived right on time.

MArtyChubbs said:
No, arrived right on time.
Click to expand...
Click to collapse
Looks like mine is coming on the earliest day of the planned shipping dates.

@MArtyChubbs and @ntegra
PixelFlasher 5.3.2.0 is released which adds support for Pixel Tablet.
There is also a dedicated support thread.
📳🔥PixelFlasher for Google Tablet Support Thread.
This is the support thread of PixelFlasher (PixelFlasher is an open-source self contained GUI tool to facilitate Pixel phone device flashing/rooting/updating with extra features). Note: This thread is meant for issues and problems faced in...
forum.xda-developers.com
Thanks for your support.

badabing2003 said:
@MArtyChubbs and @ntegra
PixelFlasher 5.3.2.0 is released which adds support for Pixel Tablet.
works a treat!
Click to expand...
Click to collapse

I got my tablet. Made the painstakingly slow mistake of updating the OTA before unlocking. The OTA takes forever.

Got my tablet. Had it rooted in less than 30 minutes.

rester555 said:
I got my tablet. Made the painstakingly slow mistake of updating the OTA before unlocking. The OTA takes forever.
Click to expand...
Click to collapse
Yep OTA on a device is very slow and is incremental, specially if you have to flash several times if you are free months behind.
Even if you don't unlock your bootloader, you can sideload OTA in PixelFlasher.