Related
The concepts in this post are already well explained elsewhere. My motivation in writing this is to consolidate the information in one place and to help others who are new or like me might be confused about properly updating their Galaxy S4 T-Mobile (M919). Many thanks to people who take the time to write tutorials and explain concepts. If you see errors or parts that are misleading please point them out and I will correct them.
There is a decent explanation of what Kernel, ROM, Baseband and a Bootloader are over there:
http://www.reddit.com/r/AndroidQues...what_are_all_the_different_pieces_of_android/
The first thing I did after buying my Galaxy S4 was to flash a custom ROM (CyanogenMod) and Recovery (ClockworkMod). I kept current with new updates but after some time I noticed that even though new CM versions were incrementally improving, the overall feel was somewhat sluggish and the cell reception was worse than that of my friends' stock phones. Flashing custom kernels certainly improves the overall handling but the issues persist.
After digging around I discovered that custom ROMs like CyanogenMod only update the ROM and Kernel partitions. Other third parties make custom Recoveries but the Bootloader and Baseband are closed-source and at the exclusive ownership of the manufacturer. The manufacturer only releases source code for parts of the ROM and Kernel. Those get picked by developers and make their way into custom ROMs. The Galaxy S4 was originally released with Android 4.2. Even though the current CyanogenMod version targets Android 4.4 when you flash it on your phone, the Bootloader and Baseband will still be the original 4.2-derived ones. To find out what version Baseband you are currently running head over to http://www.sammobile.com/firmwares/. Put M919 in the "Search device here" box and you will get a list of Baseband names for each official Samsung release. You can view your current Baseband version by looking in your phone's "About phone" section.
WARNING! WARRANTY VOID
Flashing firmware voids the phone's warranty. There used to be a way to erase all traces of such activity but since Android 4.3 Samsung has improved their security (Knox) and flashing Bootloader 4.3 or newer will permanently brand your phone as compromised. It will also lock the bootloader making it difficult to Root your phone if you want to run rooted stock TouchWiz. This guide assumes you want to run a rooted custom ROM.
I hated every phone I got at release as it takes several months to fix problems and get everything running perfectly. At this point I finally feel my S4 is running great and this update is worth voiding the warranty. I think the aforementioned warranty is 1 year so depending on when you bought your phone it could already be expired.
My house and job are in poor signal areas and often I was getting no service and occasionally a single bar. Cell phones boost power to the antenna when signal is weak and dial it down when signal is good. The battery drains quickly when reception is poor in addition to missing calls.
I went from firmware M919UVUAMDL (April 2013, Android 4.2) to M919UVUFNH7 (Sept 2014, Android 4.4).
Issues fixed with this update:
- cell reception is much improved!
- no more unnnecassary battery drain due to weak reception
- better overall performance
- much less heat
New Problems:
- locked bootloader
- impossible to revert back to old bootloader
- warranty void
HOW TO UPDATE
There should be a way to only flash the Bootloader and Baseband but I couldn't do it.
I flashed the latest stock image from http://www.sammobile.com/ with Odin. This overwrites the Bootloader, Baseband, Recovery, Kernel and ROM. Afterwards I flashed a custom Recovery (CWM) with Odin. From Recovery it's easy to flash a custom ROM and Kernel. This method left the Data partition intact so all my pictures and phone numbers were available afterwards. I urge you to back them up anyway as I have wiped them accidently in the past and it's not pretty.
Instructions
Assuming you are already running a custom Recovery:
- Get the latest firmware package from www.sammobile.com
- Boot into Recovery and make a backup (these usualy don't backup your data)
- Put the phone in Download Mode and connect to Odin
- in Odin make sure only Auto Reboot is checked
- in Odin load the firmware in PDA/AP and flash it
- when the phone boots make sure you are running the corect baseband
- go back to Download Mode and Odin
- unzip and flash the attached Recovery file from this thread with the same settings as above
- Boot into recovery and restore your backup
This should do it, enjoy! If you don't understand some of these steps Google them and you will find a ton of tutorials that explain them much better than I can.
If you didn't make a backup or are unable to restore it, download a ROM zip on the phone and use Recovery to flash it.
The attached file is an Odin-flashable ClockworkMod touch Recovery for M919 (Galaxy S4 T-Mobile).
So I followed a tutorial to unlock bootloader and root the Note 4 from Verizon (SM-N910V). First off I am gong to say that it was definitely challenging and time consuming. Mainly due to the inconsistencies in the tutorials. You got a few that claim it's unstable or that something wasn't mentioned or left out... Which is true. I not only encountered the lags and freezing, but also the "reboot cycle", that occured after the first round of unlocking bootloader. Now I am not trying to claim that I am better or that the authors are dumb, because as difficult as this "hobby", everyone has their own an unique style...
I was able to unlock bootloader and flash TWRP recovery, but was unable to flash any CF-AutoRoot, SuperUser, or any custom Rom. Along with that any "Stock" firmware I downloaded and tried to flash via ODIN or through TWRP was unsuccessful. Thankfully to persistence and a lot of research I was able to find a workable set of Firmware files on none other than an XDA_Forum.
http://forum.xda-developers.com/not...mware-firmware-kernel-modem-recovery-t2942937
The above link contains the necessary files required for any unfortunates that may occur while unlocking/rooting note 4. I used ODIN to flash files in this order. Recovery image, kernel image, and then Firmware image... I did download Modem file but was not needed as the Firmware image already contained it. NONE!!! I repeat... NONE of this was done through TWRP, once you flash the recovery image TWRP recovery is over-written and the familiar Android Factory Recovery System is now in place. Also I would like to note that I onriginally started with 5.1.1, the image/tar files I flashed are 6.0.1. I know for a fact that just like any upgrade, while you do have some bugs and fixes... it is doable and actually lesser of a headache than one might guess.
Ayways I hope that the information I have provided was helpful and beneficial to SOMEONE out there in the world... GOOD LUCK EVERYONE!!!
** STOP & DO NOT ** ​
Pass Go (... or collect 200 dollars ...)
Attempt this without reading the first page entirely at least
Attempt this without knowledge of how to recover from softbrick status
Flash any non official Firmware if you're banking on a warranty claim later {It may or may not work}
Post in this thread, any super negativity, disbelief, or naysaying.
Blame any Project/Thread contributor(s) for what YOU did, when YOU flashed your device. Please, no one forced you to press start in ODIN.
Preface
*****
[FOR THE LATEST UPDATE: GO TO POST #185 for the next steps towards rev 4/5 bootloaders.]
https://forum.xda-developers.com/showpost.php?p=79764173&postcount=185
Bootloader v3 and v4 devices currently on MM or Nougat can use the Factory Binary for their particular bootloader version in order to install a 5.1.1 based ROM that can have an untethered full root. To downgrade back to 5.1.1 use the combination firmware available for your bootloader revision. From there you CAN root 5.1.1 un-tethered.
** I do believe using the Binary 5 Combination Firmware, you can still root using the method for the v4 Bootloader, if you don't mind downgrading back to 5.1.1 and being on the combination firmware.
** I still haven't got a root method for fully rooting 6.0.1, or rooting 7.0 at all. These root methods will have your device ending up on a 5.1.1 build of Android.
For rooting Bootloader v4, please see @droidvoider 's Post #110, Post #110
Since there have been many threads scattered throughout the N920A forums about how to root 6.0.1/5.1.1, and how to downgrade the AT&T Galaxy Note 5 MM Builds back to LL builds, I've decided to collect up all the information I've had time to gather. This thread pertains to downgrading marshmallow builds to lollipop builds, and it covers gaining a tethered root system. What I am also going to cover is what I've discovered about the Factory Binary Firmware for this device. This includes what I call the Eng Modem & Eng Sboot, and how the PB2 Eng Kernel can be used with all three of the above.
Throughout all of my testing on the device, I have never once tripped my KNOX counter. The warranty remained valid on the device and it has been persistently rooted.
@TechNyne66 has outlined {proven} instructions for attaining a Tethered Root. I know there are already a few threads circulating the forum here about Root Status & Progress of the Note 5, and I hate just adding one more to the mix, but this isn't meant to be a general discussion thread.
I spent a lot of time reading over the last two years about the Exynos7420 SoC and I am always trying to learn more than high level google searches can give to me. There are a lot of hardware level topics involved I need more information on, hopefully the devs on XDA with this kind of knowledge would contact me. Because google does not always have the answers we search for when it comes to mobile hardware. It is in the minds of the devs here, and not always posted publicly. Not everyone in the world who wants the abilities granted by root access, is ready/able to deal with the potential hazards and security risks to their Device & Personal Lives. But they never will be ready, if we cannot study what those risks are in the first place.
Just remember, there is a reason things like SuperSu exist in the first place. Without a method to manage access to root privelages by installed apps, you'd be using an Open Source Universal Remote that knows everything about you, its surrounding environment, and knows how to manipulate said data. Given the nature of the Exynos7420's 64bit Architecture, all known variants of the SM-G920, SM-G925, and SM-N920 should theoretically be able to run or boot any code we could ever write for a computing device. We have the build-tools. It's just a matter of using a specific version of a particular tool depending on the timing & current context. Ideally.
My Device Results
*****
The firmware that was initially installed on my particular AT&T Note 5 when I first got it, was the August 1st 2016 build "UCS3BPH4". I have the Full ODIN Package, as well as the OTA.zip that upgrades PE6 to PH4. I also have the OTA.zip for upgrading PB2 to PE5.
I really need, if anyone has some, any unreleased official OTA updates for adb instead of just all ODIN files. I'd also like some advice on how examine how the bootloader loads a kernel, and what it looks for when it does. The update chain of OTAs to the PE5 build would be great. The N920A is odd in the sense that AT&T released two different update paths for their devices. Some devices ended up on the left path, and some on the right path.
When I flashed the Unlocked PH4 Modem, my device became carrier unlocked and opened the APN Editor. I consider it an Eng Modem.
When I flashed the Eng PH1 Sboot.bin from the Factory Binary and the Eng PB2 Kernel, I became able to Flash+Root a Lollipop Build that would stick on rebooting. Using a device with a Version 3 Bootloader. If there are other ways to downgrade to lollipop from marshmallow without using the Eng Sboot, please tell me.
I'm not trying to say at this point that the 3APH1 Firmware is actually a real eng binary like they found for the S8. But the system image on the firmware does have some interesting tidbits I haven't seen in any other Factory Binary I've messed with. It's more than normal.
If you cannot find any of the items I'm referring to in the links below. PM Me.
*****
What I understand about 3BPH4
Included Files in Full ODIN Package:
AP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
BL_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
CP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
CSC_ATT_N920AATT3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
NOBLELTE_USA_ATT.pit
If I remember reading correctly, ODIN FW whose CSC file does not include a 'hidden.img' in their Cache.img are technically Unbranded ROMs. If this is still true today, then this firmware minus CSC is actually unbranded but uses the AT&T multi-cert CSC. Unless I didn't look hard enough, I did not find a hidden.img when I used CacheRipper to unpack the Cache.img -- I don't remember what post I read this in, I read many threads all the time, I can't confirm at this moment this assumption still holds in modern builds or this device series. Still testing other theories.
I'm not sure about other N920a's, but I have a multi-CSC cert on the device, meaning it should be able to accept any firmware compatible within the same series. At least that's how I remember it being. Same goes for my VZW S5 & S6 Edge. -- I don't know how common Multi-CSC certs are still. I honestly can't remember NOT having a Multi-CSC on any of the Samsung Devices I've owned. Mine all have them. I just have some intuitive feeling the Multi-CSC is basically a requirement for Unlocking.
I have successfully downgraded the AP file many times to earlier builds by flashing the AP by itself. I have successfully done a full cold boot after downgrading the PH4 AP file to PB2, OJ1, and OGG. I successfully flashed the PE6 AP file as well.
I have successfully downgraded the CSC file many times when downgrading the AP file as well. I cannot remember at this moment if I had success downgrading the CSC by flashing only the earlier FW CSC file. The One time I can remember, I flashed only the '.PIT' file included with PH4 & the CSC file of the earlier FW. I do know that I've downgraded the AP file and not the CSC with no errors. I have NOT yet tried to downgrade the CSC file by itself to an earlier version than the Installed AP. -- It remains to be tested in more detail how the AP File and PIT File affect the flashing of a different CSC.
The PH build series is the first publicly available FW for the N920A to use a Level 3 Bootloader Binary. I notice this change from Binary 2 to Binary 3 on most devices going from 5.1.1/6.0 to 6.0.1 Builds on Samsung Devices. With the Exception of Verizon, who has been using a Level 4 Bootloader Binary for quite some time, most Carriers are just now getting around to Level 3 Binaries in their Firmware. Leading many people to believe it is completely locked to a level 3 and can never boot anything designed for an earlier binary. -- While I have so far not been able to test a method for fully downgrading all parts of the BL File from Binary 3 to Revision 1 or 2, a Revision 3 bootloader can still boot a Binary 2 ROM. Although I'm told it is possible to fully downgrade all parts of the PH4 bootloader to an earlier version, but have not successfully done so.
I have successfully downgraded the 3BPH4 sboot.bin included within the BL File of the Full ODIN Package. I did it by packaging the earlier sboot.bin into a tar by itself and flashing in the BL slot of ODIN (3.10.6). Anytime I try to flash a full revision 2 bootloader it quite expectedly fails the flash at param.bin. It trips the alarm in Download Mode by stating the error Binary 2 Device 3. In my successes here, Download Mode still showed Official Device Status, Valid KNOX Bit/Warranty Status, Passing DM-Verity Verification. In all my flashes thus far I've never tripped KNOX. Once, the device status changed from Official to Custom, but KNOX was still showing valid. It wouldn't boot due to an error about invalid kernel length, but everything was valid status under the hood. -- The two downgrades I'm referring to, are the downgrades from
N920AUCS3BPH4 sboot -> N920AUCU3APH1 engsboot
Using the Bootloader from the Factory Binary, we can downgrade from Android 6.0.1 to 5.1.1. I also have the N920C_XXU3API1_ENGSBOOT, but ODIN wouldn't even start to flash it before failing. I don't have the param.bin or cm.bin for either of the ENGSBOOT files. If they even exist publicly or privately.
N920AUCS3BPH4 sboot -> N920AUCU2APB2 sboot
Like I mentioned above, I downgraded the sboot from a binary 3 to a binary 2, by flashing only the sboot.bin and not trying to downgrade the param.bin or cm.bin. But I think having the stock PH4 param.bin & cm.bin could be what is leading to a couple roadblocks. While the flash to PB2 sboot went off without a hitch, and did successfully do a full boot, it only lasted for about 20 minutes. When more tests caused it to stick in a bootloop to prevent itself from tripping the KNOX warranty bit due to invalid kernel length causing failed boot. This is also the only time in all my tests that my Device changed from Official to Custom status. Reflashing the Full PH4 package returned everything back to Stock. I also flashed Systemless Root (Which worked btw! But Verity Caught it, hence why the session lasted only 20 minutes or so) during this test session which could have also done it potentially.
My Best experience flashing most of the files I've tried successfully, came from using ODIN v3.10.6, and it does not seem to be a standard ODIN. Instead of just Odin3.exe & Odin3.ini, these are the files that came bundled inside the Odin zip:
Odin Downloader Release Notes.xlsx
Odin3 v3.10.6.exe
Odin3.ini
S1PlugIn.bundle_141117.zip
SS_DL.dll
But it seems like this version of ODIN has some kind of FTP mode within it for grabbing something I have no idea at this moment. So insights from someone smarter than me would be nice. I think FTP mode was enabled by connecting the Device to odin, while in RNDIS USB Mode. If not, I know that connecting to ODIN in that connection mode did something odd in one of the ODIN versions I have. ALSO, what are all the modded versions running around supposed to be used for exactly? And how were they modded? Often times they fail to flash simple things this v3.10.6 flashes successfully without blinking.[/color]
*** *** ***
Rooting/Downgrading Files Involved
I.Note5 Online Repo - https://drive.google.com/folderview?id=0B4PoJYLnmv1BNzY2OXB3QlFfcVk
** This is the folder where I'm keeping all files referenced here + other N920A related material.
II. Binary 3 Lollipop Bootloader (N920AUCU3APH1 sboot.bin, FRP eng Bootloader) - https://drive.google.com/folderview?id=0B4PoJYLnmv1BQ19qeVFUd2cxaWM
** This sboot can be flashed overtop of the Stock PH4 sboot.bin and IT WILL NOT trip KNOX. This is the only "binary 3" bootloader for our device I've found that will boot 5.1.1 based ROM's or Kernels. Using this bootloader, you can flash 5.1.1 based ODIN AP Firmware Files (ROMS) & continue to have Official Device status for Warranty/KNOX Purposes.
III. 2APB2 Lollipop Eng Kernel - https://drive.google.com/folderview?id=0B4PoJYLnmv1BQVBfQUdYeE5IR1U
** This is a 5.1.1 based, rooted kernel. As far as I know this is a leaked Engineering Kernel from the 2APB2 build. Flashing this Kernel and the PH1 eng sboot, overtop of Stock PH4, gives access to an ADB Root Shell during the bootloop/failure. Flashing this kernel overtop of a stock LL based Kernel allows a bootable rooted system.
IV. Metalcated g920a 5.1.1 Root v4 -
** This is Metalcated's Root Method for the Galaxy S6. This zip is used for the Root-Install & Root-Boot script files. The Root-Install command should be ran once the PB2 Kernel has been flashed and successfully rebooted the first time. Afterwards, the Root-Boot command should be ran during the device's next boot process, to continue using the PB2 Kernel & maintain a bootable system.
*** *** ***
6.0.1 Downgrading Instructions (tested using full Stock PH4 FW)
1.) Enable Developer Options
2.) Enable OEM Unlock
3.) Enable USB Debugging (For a safe bet I make sure to "always remember the device" by saving the RSA Key)
4.) Power Off then Boot into Download Mode
5.) Flash the Binary 3 Lollipop Bootloader using the "BL" slot in ODIN. (Listed Above)
6.) Once Bootlogo Appears, reboot into download mode by holding, VOL Down + HOME + POWER
7.) Now Flash the AP File of the Lollipop FW you want to install. (The OGG ROM, has no DM-Verity in Recovery Mode)
8.) Boot into Recovery Mode
9.) Wipe Data/Factory Reset
10.) Reboot
*** *** ***
5.1.1 Tethered Root Instructions (tested on PB2 & OJ1 ODIN AP FW/ROM's)
1.) Enable Developer Options
2.) Enable OEM Unlock
3.) Enable USB Debugging (For a safe bet I make sure to "always remember the device" by saving the RSA Key)
4.) Power Off then Boot into Download Mode
5.) Flash the PB2 eng Kernel (Listed Above)
6.) Once Booted, recheck steps 1-3, then run the "root-Install" script (.cmd for Windows, .sh for Linux) from Metalcated's zip archive.
7.) During Device Boot Up, make sure the device the connected to your PC, and run the "root-Boot" script from Metalcated's zip archive. And the device should finish booting successfully with the PB2 eng Kernel still intact.z
removed outdated information about Note 5 source codes.. Please see links by Delgoth for updated info
** too many words on someone elses thread **
I think the main problem for you is that you are on a binary 4. I have not tested any of this using a device that starts on binary 4.
But thank you for this, and I will go over these a little later today. I do already have the MM sources for the N920A/V/C and am working on that this week.
Flashing the PB2 flashed a LL rooted kernel, thats why on a device with MM installed it will hang. But during that hang plug it into the pc and open ADB
See if you have root shell.
Just wondering if anyone got anywhere with this. I know nothing about what you guys are talking about but I have N920AUCS4CPL1 and was wondering if anyone figured out a root for it
We have another thread up in the General Android Q&A Forum. I currently have adb shell with eng kernel running Lollipop U1AOGG AP running the U3APH1 eng bootloader.
I also have Busybox support, and can make persistent changes to the /system & /data directories
Droidvoider has also created a type of custom odin/heimdall flashing application used during runtime.
This is big stuff!!!
https://forum.xda-developers.com/android/help/injecting-root-setting-selinux-stages-t3573036/page2
in binray 3 not working, tested
What do you mean when you say it did not work for binary 3? Which FW build did you test? And how did you use ODIN when you flashed?
What tests of yours failed specifically? Because I've successfully downgraded to Lollipop from both the PHA & PH4 builds. I haven't actually tried PJ1. But with the corrupt bootloader issue people have mentioned. It would depend on if you upgraded to a Binary 4 sboot or not.
Sent from my Galaxy Note5 using XDA Labs
Does this thread only apply to the at&t note 5?
shawtypanda said:
Does this thread only apply to the at&t note 5?
Click to expand...
Click to collapse
Yes! This isn't going to work on Verizon.
Actually it could potentially work for Verizon.
If you substitute the Verizon Combination Firmware for the AT&T and apply the same principles accordingly.
So you're saying that there could be a root for the verizon version of this phone?
shawtypanda said:
So you're saying that there could be a root for the verizon version of this phone?
Click to expand...
Click to collapse
I need a Verizon tester for my stuff. Your security patch level can not exceed October, 2016. Please check in Settings|Device|About what your security patch level is. If your patch level is 2017, it is not likely I will be attempting to gain root. Unless there are reports of issues such as battery drain, or if enough people complain about not being able to switch carriers again. freddierice connected the dots with his tools which I have altered to be mine.
Greyhat Root Project - Root Console is a tool which executes commands from a text file, not a root shell
trident is freddierice's tool exactly being converted for the Note 5 (yes verizon also) It is a root shell so to speak, but I'm still working on sepolicy injection (read no context hack yet, limited by context)
Greyhat Root Project -- Root Console
Build a cmd_list.txt to issue commands as root. It also replaces screencap with dirtycow so you can use dirtycow with the two contexts. root + system_server or install_recovery. From install_recovery I am able to switch to init context, maybe a couple others, this feature is being finalized today. But ultimately until I finish trident we don't have reload init, can't reload policy
trident Note 5 version
This is still being converted it does work but the INIT_OFFSET needs to be worked out still, then it should reload init which will reload sepolicy correctly.
edit
The binaries for Greyhat Root Project -- Root Console are specific to each build of Android. You can certainly try the Android 6 or Android 5 toolbox / applypatch on your device but if it fails I need to compile a version specifically for your build. Please PM me with build number, obtain as follows
1. Plug in your device and ensure you can connect to adb shell
2. adb shell getprop ro.build.id
(if you're in the shell already leave off the adb shell) getprop ro.build.id
3. PM me that number, should look like MMB29K
I'm on the latest ota update so I'm assuming I don't qualify but if there's a way for me to downgrade or something so I can test this then I will. But how's the progress? I'm curious
What's this funny stuff about us being able to root our EQC6 (Did we have this update? I don't remember) firmware lol ?? I'm not sure this is even close to the truth, I can already see the bricks happening to mislead ppl. Check it out and tell me (us) what we really wanna hear or give us the sad but real truth
http://www.teamandroid.com/2017/05/...d-70-att-galaxy-note-5-n920a-nougat-firmware/
If someone need I can test verizon version if it ever will be..
I'm on 5.1.1. Was waiting for root, but now thinking of upgrading to nougat. Would be a good idea if waiting for root, or should just stick with 5.1.1
Aurey24 said:
What's this funny stuff about us being able to root our EQC6 (Did we have this update? I don't remember) firmware lol ?? I'm not sure this is even close to the truth, I can already see the bricks happening to mislead ppl. Check it out and tell me (us) what we really wanna hear or give us the sad but real truth
http://www.teamandroid.com/2017/05/...d-70-att-galaxy-note-5-n920a-nougat-firmware/
Click to expand...
Click to collapse
Yeah that looks to be an auto generated page.
I think we're almost done. Basic Shell root is achieved. I had SuperSU half installee before I reflashed. On MM builds.
But on the Note 5 and S6 edge it is coming quickly. Ive just been too busy the last two weeks to check out the signatures.
just recently got my hands on a Note 5 but didn't realise that the N920A was near impossible to root. I was just about to update this phone to the stock nougat but then found this thread today and it looks promising.
Currently running the PB2 firmware. If this root ends up being successful, will it only allow for a permanent root on 5.1.1 or 6.0.1? Or will you be able to flash a ROM like Nougat Nemesis and everything will be okay? Understandable that time will only tell. I'm currently using the Nemesis Nougat on my s6 Edge as my daily driver but would much rather use the Note 5 with Nemesis as my daily driver.
I can see why people love the Note. It truly is a great phone.
is this still a thing?
All,
my sgh-i747 WiFi doesn't appear to work. under settings> WiFi slider (OFF)> slide to on (remains off)
next goto WiFi setup screen: no devices listed, buttons at bottom of screen dim/greyed out.
history:
phone was bricked by a forced ATT update. I finally did a rom update/reinstall to push a working stock kernel kitkat 4.4.2
thx
Rob
ALSO i need working links to Lollipop for sgh-1747 using oden
PS: I do ROM , hardware and software updates on data storage systems with petabytes of storage. BUT THIS PHONE MAKES ME FEEL STUPID....
My Hats Off to All Of You Who Hack, Play, or Make Mods for the Phones.
Boot image not matching firmware on your phone can cause wifi to not work. The kernel doesn't have the what it needs to work with the radio you have installed. It is a fairly typical stock rom problem. Custom roms typically have broader support instead of being targeted at a specific firmware.
First step is to figure out what exactly you have on your phone now. Need to know bootloader, modem, and boot image versions since this phone is finicky. Hard bricks are possible, so don't do anything hasty. There's an app in the Play store called phone info samsung by vndnguyen that helps with that. Install it and see what it says you have for bootloader and modem/baseband. Also check in Settings -> About and see what kernel version you have (the app might tell you that too, it has been a long time). Report that all back here and it will help with how to fix it.
Alternately if you don't want to mess with the app enter this in a terminal app or adb shell:
Code:
getprop ro.bootloader
getprop gsm.version.baseband
You won't find an Odin package for lollipop. Samsung never updated this device past kitkat. Anything lollipop or newer would be a custom rom, and those are all custom recovery flashable zips, not Odin.
jason2678 said:
Boot image not matching firmware on your phone can cause wifi to not work. The kernel doesn't have the what it needs to work with the radio you have installed. It is a fairly typical stock rom problem. Custom roms typically have broader support instead of being targeted at a specific firmware.
First step is to figure out what exactly you have on your phone now. Need to know bootloader, modem, and boot image versions since this phone is finicky. Hard bricks are possible, so don't do anything hasty. There's an app in the Play store called phone info samsung by vndnguyen that helps with that. Install it and see what it says you have for bootloader and modem/baseband. Also check in Settings -> About and see what kernel version you have (the app might tell you that too, it has been a long time). Report that all back here and it will help with how to fix it.
Alternately if you don't want to mess with the app enter this in a terminal app or adb shell:
Code:
getprop ro.bootloader
getprop gsm.version.baseband
You won't find an Odin package for lollipop. Samsung never updated this device past kitkat. Anything lollipop or newer would be a custom rom, and those are all custom recovery flashable zips, not Odin.
Click to expand...
Click to collapse
Thank You
jason2678 what you said makes perfect sense to me. like needing a VIN # for a 2002 Toyota to figure out what water pump or alternator because they used 6 different versions of each, LOL
so i would like to use 5.1 lollipop which is a custom ROM i believe, if you can suggest one i will defer to your judgement
but as a fallback suggest a kitkat ROM as well
bootloader I747UCUFNJ1
BASEBAND I747UCUFNJ1
KERNEL VERSION:
3.4.0-1514807
[email protected] #1
32-bit
modem msm8960
please and thank you
respectfully
123RobH
At NJ1 you're not on the latest bootloader and modem, but you're close enough. And your bootloader and modem match. I wouldn't mess with it. You'll be able to run all the latest custom ROMs on that, no problem.
If you want lollipop, look around the development section here. I'm not sure if you'll be able to track down a lollipop rom download linked to XDA. You might have to poke around old uploads for d2att on androidfilehost.com for 5.1.1 roms. I'm pretty partial to slimkat stable 9 on this phone, and it runs fine on NJ1 firmware too.
Oct-Os is probably the most actively supported rom currently. They've moved on to nougat these days. You'll be able to run it on NJ1 too. You might want to give it a shot.
Track down a rom and matching gapps. Then full wipe and flash them with TWRP recovery. If you run into any trouble or have any questions, just ask. I'm pretty certain once you get a custom rom on your phone your wifi problems will go away. Stick to lollipop, marshmallow, or nougat and you'll be fine. Even newer KitKat ROMs will be OK on NJ1.
This is really a big topic that no one asks, everyone just asks how to fix it but I want to know what exactly happens to Android system in deep that cause hard brick and unable to start the device. Previously when I had a Chinese phone, it was so simple to downgrade and upgrade stuff without bricking because there was no bootloader at all. Everytime I check it said "Unkonwn Bootloader". I'd be happy if someone explain or just drop links about the bootloader and why hard brick happens due to downgrade. I am thinking a way to fix the hard brick device in a way that will fix it all the time with just a simple procedure, doesn't matter if you had downgraded or rekt system stuff or you're on any Android version, it will be fixed. It sounds stupid but I think there must be a way, if we go more deeper into Android system, we can make it working.
I'll have a go at answering this...
It's generally not the downgrading of stock Motorola firmware that bricks a device, often times it's the usage of OTA updates following a downgrade that causes the hard brick.
From what I've seen of many hard bricks (on Moto G4/Plus, G5 Plus, Z Play, though probably a similar scenario on other devices from other manufacturers):
1)You have your system firmware and your bootloader. E.g. The C1:14 version bootloader comes with the Feb 2018 7.1.1 stock Nougat firmware/OTA update. Normally, they would be matching (so you'd have the 7.1.1 Feb 2018 firmware with the C1:14 bootloader). Using OTA updates would be no problem.
2)If you downgrade your stock firmware (custom ROMs usually are not applicable in this case, regardless of the custom ROM security patch/version), you may be able to flash older stock firmware but your bootloader cannot be downgraded. E.g. you flashed the August 2017 7.1.1 stock firmware on a device previously updated to Feb 2018 stock firmware. You'd have the August 2017 system firmware but a Feb 2018 bootloader. Your device may run okay and the flash may have gone okay besides some 'security version downgrade' errors with the bootloader and GPT.
3)So your downgraded device runs okay and you get an OTA prompt to the Sept 2017 security patch OTA. This is where the problems start. OTA updates appear to only be verified by your system version, and looking through the updater scripts for various OTA updates, they check if your system partition, OEM, boot (kernel) etc are fully stock and are of the correct build to flash to. Tellingly, the OTA script does not seem to check for your bootloader version , I think the OTA assumes your bootloader and the system are of the same matching versions/patch levels. As you've downgraded your device, this assumption does not hold. Should there be a check for the bootloader version if it was possible? Perhaps.
4)Your device reboots and begins flashing the Sept 2017 OTA. So far, the OTA is checking and verifies your device is running the August 2017 firmware, and begins patching. However, the OTA can patch your bootloader with older images without verification, which means it applies Sept 2017 images to a Feb 2018 bootloader, corrupting the bootloader and thus hard bricking your device.
(EDIT - reading this page, it suggests that there are multiple bootloaders in your device, each one verifying each other to ensure integrity. https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565 My guess is that applying the old OTA images to a newer bootloader changes the signature of the bootloader we see - e.g. changing the signature of the secondary bootloader/SBL or having an old aboot image in the newer bootloader - and so fails the upstream verification, hence a hard brick.)
I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?
However, with Qualcomm bootloaders, if the bootloader image is corrupted they appear to fall back to a emergency download mode (you can read more here: https://alephsecurity.com/vulns/aleph-2017028 ). To recover, you often need crytographically signed images from the appropriate OEM (Motorola in this case) to rescue a device in such a state. As I understand it, these images - including the often requested blankflashes - include methods to communicate with your device (via the sahara protocol) https://github.com/openpst/sahara and a programmer to verify your device and bootloader are suitable for repairing, before flashing a new bootloader: https://forum.xda-developers.com/showpost.php?p=62191317&postcount=2112 https://forum.xda-developers.com/showpost.php?p=63490742&postcount=17 We cannot make these, and any attempts to modify them would likely break the cryptographic signatures on the files, so would be rejected (else you could inject your own compromised bootloader, or downgraded bootloader as per the paper, which would be dangerous for security). This security issue is likely why OEMs do not release blankflashes or other such repair files.
If the blankflash is too old or older than the corrupted bootloader, the programmer appears to fail to rescue the device. Short of having the actual, signed files in a blankflash or similar, that are as new or newer than your current corrupted bootloader, it becomes very hard to rescue a device. That's likely why we've seen quite a few Z Play devices on 7.1.1 or 8.0 that downgraded and got corrupted by an OTA that are not rescuable at the moment - we simply do not have updated tools. Motorola (and likely other OEMs) seems to regard these blankflashes as internal development tools and as such won't give them out - all we have are leaks. I imagine Motorola's point of view also includes that since your bootloader was unlocked, you assume responsiblity for anything that happens.
If you do hard brick then I recall there are a few options:
a)Hope that a blankflash or updated MSM8953 programmer/signed images for Motorola devices is leaked. Must be as new or newer than your corrupted bootloader (recall you cannot downgrade bootloaders). No guarantee of being released if at all.
b)Hope that someone finds a JTAG or other board level repair.
c)Pay for a motherboard replacement (expensive, 60-80% of the device cost sometimes) - perhaps you may be covered by local consumer laws.
d)Buy a new device, forget about repairing this one.
As I mentioned above, hard bricks are very difficult to recover from without the correct tools. However, they are avoidable if users do not flash older stock firmware, only flashing the same stock firmware as they had on their device (matching their bootloader) or newer stock firmware. If they do downgrade, then not using OTA updates whatsoever may also save them from a hard brick (though in that case you must use the latest stock firmware to update with). Alternatively, if you unlocked your device bootloader, you could just use TWRP flashable stock ROMs and forget about using stock firmware at all - TWRP flashables in general should not affect the bootloader.
Any further comments or corrections welcome.
echo92 said:
I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?
.
Click to expand...
Click to collapse
Yes indeed it was a mediatek device and thank you so much for your answer, I really appreciate it.
So a patched bootloader will able to bypass the verification step and the update will be flashed easily but the problem is with the security. BTW, what kind of security concerns? Will my device become vulnerable to hackers and viruses?
And if the patching bootloader is a pain then is there any way to patch the OTA itself? A patched OTA which doesn't requires verification and won't cause hard bricking. So if a person who has downgraded to predecessor version and have a bootloader of successor version can get the successor version of Android through side loading the patched OTA.
I was thinking about the JTAG stuff but it's overall not economically feasible.
I think patched Ota update is a good way to get around but is it possible?
Manish355 said:
Yes indeed it was a mediatek device and thank you so much for your answer, I really appreciate it.
So a patched bootloader will able to bypass the verification step and the update will be flashed easily but the problem is with the security. BTW, what kind of security concerns? Will my device become vulnerable to hackers and viruses?
And if the patching bootloader is a pain then is there any way to patch the OTA itself? A patched OTA which doesn't requires verification and won't cause hard bricking. So if a person who has downgraded to predecessor version and have a bootloader of successor version can get the successor version of Android through side loading the patched OTA.
I was thinking about the JTAG stuff but it's overall not economically feasible.
I think patched Ota update is a good way to get around but is it possible?
Click to expand...
Click to collapse
Good questions.
1)In theory, a patched bootloader may let you bypass the verification step, though the upstream bootloaders (including those burned into your device's memory) may still stop that bootloader from running, as it fails the 'chain of trust' as Google puts it. https://source.android.com/security/verifiedboot/verified-boot
As for security concerns, well, who knows? If you could put a compromised bootloader onto your device with the correct authorisations, it could do anything. That's likely why blankflashes are not around, plus the fact they have to be signed by the issuing OEM to be valid. Else, that could be a potential vector to breaking security. If you can't trust the guardian of your device (which the bootloader can act as), what can you then trust about that device?
2)In theory, again, you could patch the OTA, but the OTA is signed, and thus any modification may break the signing. This would then cause rejection by the stock recovery https://source.android.com/devices/tech/ota/sign_builds
I have seen OTA updates modified to work with TWRP, though I think they may not update your bootloader (e.g. have a look here: https://forum.xda-developers.com/g5-plus/how-to/npn25-137-33-stock-firmware-t3577081/page12 ) However, in that case, you may be better off staying with TWRP flashables of the stock ROM and forget about using stock ROM firmware if you are worried about the bootloader.
So in summary, if you want to avoid a hard brick, some ways are:
1)Ensure you only flash the latest firmware onto your device that is as new or newer than your bootloader. If your bootloader is locked, that should apply automatically (as the bootloader will block downgrades).
2)If you do choose to flash older stock firmware that is older than your bootloader version, please do not use OTA updates. Only use newer stock firmware to update (and ensure it's the correct build for your region/software channel).
3)If you so wish and you have an unlocked bootloader, forget about using stock firmware, use the TWRP flashables of the stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/development/rom-nov-patch-npns26-118-22-2-8-t3717037) Of course, OTA updates are not usable.
echo92 said:
Good questions.
1)In theory, a patched bootloader may let you bypass the verification step, though the upstream bootloaders (including those burned into your device's memory) may still stop that bootloader from running, as it fails the 'chain of trust' as Google puts it. https://source.android.com/security/verifiedboot/verified-boot
As for security concerns, well, who knows? If you could put a compromised bootloader onto your device with the correct authorisations, it could do anything. That's likely why blankflashes are not around, plus the fact they have to be signed by the issuing OEM to be valid. Else, that could be a potential vector to breaking security. If you can't trust the guardian of your device (which the bootloader can act as), what can you then trust about that device?
2)In theory, again, you could patch the OTA, but the OTA is signed, and thus any modification may break the signing. This would then cause rejection by the stock recovery https://source.android.com/devices/tech/ota/sign_builds
I have seen OTA updates modified to work with TWRP, though I think they may not update your bootloader (e.g. have a look here: https://forum.xda-developers.com/g5-plus/how-to/npn25-137-33-stock-firmware-t3577081/page12 ) However, in that case, you may be better off staying with TWRP flashables of the stock ROM and forget about using stock ROM firmware if you are worried about the bootloader.
So in summary, if you want to avoid a hard brick, some ways are:
1)Ensure you only flash the latest firmware onto your device that is as new or newer than your bootloader. If your bootloader is locked, that should apply automatically (as the bootloader will block downgrades).
2)If you do choose to flash older stock firmware that is older than your bootloader version, please do not use OTA updates. Only use newer stock firmware to update (and ensure it's the correct build for your region/software channel).
3)If you so wish and you have an unlocked bootloader, forget about using stock firmware, use the TWRP flashables of the stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/development/rom-nov-patch-npns26-118-22-2-8-t3717037) Of course, OTA updates are not usable.
Click to expand...
Click to collapse
Wow, you're the man. I was expecting that because when I looked into the OTAs, I found it's hard to modify the OTA to work on signed bootloader. It's like a lock and key system that makes the OTA possible. Thanks for your help, it has saved me not of time.
BTW, the stock ROM (Oreo) replaces the build prop everytime I reboot? I am trying to modify the build prop but no results till now. Is it because of magisk? Because magisk is a systemless root so it prevents system modifications?
Manish355 said:
Wow, you're the man. I was expecting that because when I looked into the OTAs, I found it's hard to modify the OTA to work on signed bootloader. It's like a lock and key system that makes the OTA possible. Thanks for your help, it has saved me not of time.
BTW, the stock ROM (Oreo) replaces the build prop everytime I reboot? I am trying to modify the build prop but no results till now. Is it because of magisk? Because magisk is a systemless root so it prevents system modifications?
Click to expand...
Click to collapse
Hmm, if you're following this rooting guide, https://forum.xda-developers.com/moto-z-play/how-to/guide-how-to-magisk-root-xposed-oreo-8-t3743273 it could well be dm-verity which is still enabled on your device. As I understand it, dm-verity is there to prevent modifications to your system partition (which build.prop is part of) and other key partitions, or if it detects modifications, to stop your device from booting. Others have reported the same issue on other devices https://forum.xda-developers.com/mate-9/help/mount-writable-twrp-t3685867 https://source.android.com/security/verifiedboot/ I think dm-verity is strictly enforced on Nougat and I imagine the same applies to Oreo, if not more so.
However, looking at the magisk help documentation, attempting to disable dm-verity with the stock kernel (stock = the Motorola hudsoncm kernel in this case) can cause odd instabilities on devices https://www.didgeridoohan.com/magisk/MagiskIssues so you may have to look into flashing an Oreo based custom kernel, if one is available (which hopefully has the F2FS fix integrated, and has dm-verity disabled or not present) if you wish to modify your system. However, that custom kernel probably will have to wait for the Oreo stock kernel source to be released by Motorola, as you'll need the Motorola Oreo kernel source to build a compatible kernel for stock Oreo ROMs from what I understand.
echo92 said:
Hmm, if you're following this rooting guide, https://forum.xda-developers.com/moto-z-play/how-to/guide-how-to-magisk-root-xposed-oreo-8-t3743273 it could well be dm-verity which is still enabled on your device. As I understand it, dm-verity is there to prevent modifications to your system partition (which build.prop is part of) and other key partitions, or if it detects modifications, to stop your device from booting. Others have reported the same issue on other devices https://forum.xda-developers.com/mate-9/help/mount-writable-twrp-t3685867 https://source.android.com/security/verifiedboot/ I think dm-verity is strictly enforced on Nougat and I imagine the same applies to Oreo, if not more so.
However, looking at the magisk help documentation, attempting to disable dm-verity can cause odd instabilities on devices https://www.didgeridoohan.com/magisk/MagiskIssues so you may have to look into flashing an Oreo based custom kernel, if one is available (which hopefully has the F2FS fix integrated, and has dm-verity disabled or not present) if you wish to modify your system. However, that custom kernel probably will have to wait for the Oreo stock kernel source to be released by Motorola, as you'll need the Motorola Oreo kernel source to build a compatible kernel for stock Oreo ROMs from what I understand.
Click to expand...
Click to collapse
There's an option in magisk that says "Preserve AVB 2.0/dm-verity", should unchecking it will work?
Or rooting with SuperSU would work? I tried SuperSU 2.82, it all flashed but stuck on boot at the last. Do you know how can I root my device using SuperSU, safety net is not an issue.
Manish355 said:
There's an option in magisk that says "Preserve AVB 2.0/dm-verity", should unchecking it will work?
Click to expand...
Click to collapse
I honestly do not know, though it's possible unchecking that may cause a bootloop if magisk tries to disable dm-verity on the stock kernel. I'm hoping you could boot into recovery and enable dm-verity then re-flash magisk to get your device running if you do bootloop.
echo92 said:
I honestly do not know, though it's possible unchecking that may cause a bootloop if magisk tries to disable dm-verity on the stock kernel. I'm hoping you could boot into recovery and enable dm-verity then re-flash magisk to get your device running if you do bootloop.
Click to expand...
Click to collapse
Rooting with SuperSU would work? I tried SU 2.82 but my device got stuck at boot after long time and several bootloops. Do you know how to root using superSU? I don't mind safety net fail or pass, I don't use apps that requires safety net either.
Manish355 said:
Rooting with SuperSU would work? I tried SU 2.82 but my device got stuck at boot after long time and several bootloops. Do you know how to root using superSU? I don't mind safety net fail or pass, I don't use apps that requires safety net either.
Click to expand...
Click to collapse
I'm not familiar with rooting with SuperSU on the Z Play - for my G4 Plus, the easiest way was to flash a custom kernel (ElementalX courtesy of flar2 or vegito) which had dm-verity removed from the kernel. That way, when you flashed magisk or SuperSU, there was less risk of boot issues. There were dm-verity disablers but I recall they had to be modified for each new stock firmware and sometimes had boot issues if the patch didn't work properly.
I have absolutely no idea if this will work on the Oreo stock kernel, in theory you could unpack the kernel, disable dm-verity and re-pack the kernel: https://forum.xda-developers.com/showpost.php?p=69558535&postcount=7912
However, I think the most compatible and reliable path would be to compile a custom kernel, without dm-verity, from the Z Play Oreo kernel source, then flash that to your device then flash magisk/SuperSU.
echo92 said:
I'm not familiar with rooting with SuperSU on the Z Play - for my G4 Plus, the easiest way was to flash a custom kernel (ElementalX courtesy of flar2 or vegito) which had dm-verity removed from the kernel. That way, when you flashed magisk or SuperSU, there was less risk of boot issues. There were dm-verity disablers but I recall they had to be modified for each new stock firmware and sometimes had boot issues if the patch didn't work properly.
I have absolutely no idea if this will work on the Oreo stock kernel, in theory you could unpack the kernel, disable dm-verity and re-pack the kernel: https://forum.xda-developers.com/showpost.php?p=69558535&postcount=7912
However, I think the most compatible and reliable path would be to compile a custom kernel, without dm-verity, from the Z Play Oreo kernel source, then flash that to your device then flash magisk/SuperSU.
Click to expand...
Click to collapse
I haven't tried compiling a kernel, I am not a developer (I had ported ROMs for my old MTK device but none for this device, I am not very much familiar with snapdragon devices) so i think I should just flash a custom ROM, that would work, right?
Manish355 said:
I haven't tried compiling a kernel, I am not a developer (I had ported ROMs for my old MTK device but none for this device, I am not very much familiar with snapdragon devices) so i think I should just flash a custom ROM, that would work, right?
Click to expand...
Click to collapse
If you really want access to your /system partition and build.prop, custom ROMs are an option, yes, as their kernels shouldn't have dm-verity on and so are easier to root. Ensure you have the stock firmware to revert back to if you so wish and back up your data, as a custom ROM flash will usually mandate a data wipe/factory reset.
Alternatively, wait for the Z Play Oreo kernel source and for a developer to release a custom kernel built on that source.
echo92 said:
Alternatively, wait for the Z Play Oreo kernel source and for a developer to release a custom kernel built on that source.
Click to expand...
Click to collapse
Ya, this seems like a good option. BTW, unchecking the dm-verity in magisk won't do anything, after reboot it checks again. Thanks for the help.
Driver Installation
Does anyone know how to update the drivers to reflect that the device is a Moto phone? I bricked my device (exactly as described here; downgraded then OTA bricked). When I plug in to my computer it recognizes it as a USB driver Qualcomm HS-USB QDLoader 9008. Would it help any to download a driver to have it identify as a phone?
Tweedledope said:
Does anyone know how to update the drivers to reflect that the device is a Moto phone? I bricked my device (exactly as described here; downgraded then OTA bricked). When I plug in to my computer it recognizes it as a USB driver Qualcomm HS-USB QDLoader 9008. Would it help any to download a driver to have it identify as a phone?
Click to expand...
Click to collapse
Unfortunately, the only way is to somehow repair your bootloader as the bootloader is (part of ) what identifies your device to your computer as a phone. That Qualcomm HS-USB 9008 is your device in emergency mode - usually when your bootloader is corrupted (by a bad OTA update) or non-existent and now it's in a fail-safe boot state.
The only ways to get your device recognised again are to find a working blankflash to repair your device bootloader, try to boot from a cloned image of a working device (and then perform a firmware flash to repair the damage) or pay for a motherboard replacement.