** 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?
Related
@muniz_ri is trying to help us get root for our AT&T SGH-i467 ni2 4.4.2
He has been successful at gaining root access on several other devices with a locked bootloader like our i467.
He has asked for an update.zip file from the recent ni2 4.4.2 update.
Does anyone here have that file that they can share?
If so please post a link to it or send a pm.
Thanks for your help.
https://www.dropbox.com/s/in9g36dh7algc7o/2400258.cfg?dl=0
Thanks @godzulu I have downloaded the file and forwarded it to @muniz_ri
dandroid7 said:
Thanks @godzulu I have downloaded the file and forwarded it to @muniz_ri
Click to expand...
Click to collapse
Fingers crossed! Go muniz!!!
@godzulu
Did you get this file from the cache/fota folder on your device after downloading the update?
Just trying to help @muniz_ri track where this file originated.
dandroid7 said:
@godzulu
Did you get this file from the cache/fota folder on your device after downloading the update?
Just trying to help @muniz_ri track where this file originated.
Click to expand...
Click to collapse
I posted this in another thread but it sums up what I have and what I need. I'm willing to help once I have these items:
"The kernel swap/towelroot method is exactly what I had in mind and I can create the NI2 stock, signed kernel using the MF1 kernel and NI2 OTA but I am missing the MF1-to-NI2 ota.zip (that file you linked to is the MF2 to NI2 ota). I can even work with the MF1 to MF2 ota if someone has that.
Also, even if I get the correct files and create the kernel there is a good chance that the device will not boot using the MF1 kernel and this is all for nothing but worth a shot."
Couldn't sleep tonight, so I made myself useful.
Downgraded to MF1, accepted OTA update, rooted, pulled it from /cache/fota. uploading now.
Attempting to patch without unrooting completed successfully but gave me a nice error message "System software not authorized by ATT has been found on your phone" - interestingly this increased my custom binary count by 1, even though I uploaded the signed, non-customized image available @ sammobile.com.
So now I'm using odin to revert to MF1 and sideload the update again (without root). Whee! Incidentally I did this all in Odin via vmware. My computer doesn't have the hdd space to handle linux and windows side by side anymore, so VMware comes in handy with a tiny tiny disk image
Hmm, for some reason I can't upgrade to 4.4.2 at all now.. looks like my sboot remains at NI2 version after using odin to downgrade (bootloaders tend not to be downgradable, so that's not too surprising)
However, any way I go about it, even just waiting for the OTA to come down from AT&T and installing it, I get the previously mentioned error message. System boots fine on MF1. Hmmm..! My wifey is gonna be pissed at me if I nuked her phone and didn't even get an update, haha
Anywho, here's the 2400258.cfg: https://drive.google.com/file/d/0B1FdfRFXDji6enVvbHNxU05IZkU/view?usp=sharing
Da_G said:
Anywho, here's the 2400258.cfg: https://drive.google.com/file/d/0B1FdfRFXDji6enVvbHNxU05IZkU/view?usp=sharing
Click to expand...
Click to collapse
Unfortunately, that's the same OTA update file that @godzulu already provided, but thanks for trying.
Maybe @muniz_ri could be a little more specific about exactly what needs to be done to collect what he is looking for?
ramjet73
@ramjet73:
Perhaps I uploaded the wrong file, or did you actually unzip it and check the contents?
The previously provided file was:
Code:
file_getprop("/system/build.prop", "ro.build.fingerprint") == "samsung/konalteatt/konalteatt:4.1.2/JZO54K/I467UCAMF2:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "samsung/konalteatt/konalteatt:4.4.2/KOT49H/I467UCUBNI2:user/release-keys" ||
abort("Package expects build fingerprint of samsung/konalteatt/konalteatt:4.1.2/JZO54K/I467UCAMF2:user/release-keys or samsung/konalteatt/konalteatt:4.4.2/KOT49H/I467UCUBNI2:user/release-keys; this device has " + getprop("ro.build.fingerprint") + ".");
The file I provided:
Code:
file_getprop("/system/build.prop", "ro.build.fingerprint") == "samsung/konalteatt/konalteatt:4.1.2/JZO54K/I467UCAMF1:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "samsung/konalteatt/konalteatt:4.4.2/KOT49H/I467UCUBNI2:user/release-keys" ||
abort("Package expects build fingerprint of samsung/konalteatt/konalteatt:4.1.2/JZO54K/I467UCAMF1:user/release-keys or samsung/konalteatt/konalteatt:4.4.2/KOT49H/I467UCUBNI2:user/release-keys; this device has " + getprop("ro.build.fingerprint") + ".");
You will note the first file contains a patchset against MF2, while the one I provided contains a patchset against MF1. So, this should be exactly what was asked for.
My mistake.
I didn't even download the file you linked and my comments were based on the file name being the same.
Thanks for clarifying that and again for collecting that file. :good:
ramjet73
No sweat, I hope it helps! I talked with @muniz_ri a bit about the process, I think it should work OK for most of us!
However, now that I have played with it some, I think it would not work for anyone who has tripped knox/custom binary count/custom system.
During the process of pulling the ota zip and attempting an upgrade, I tripped all 3 of those flags. Things I noted:
sboot is not downgradable once updated. (This is expected on a non dev device)
There is a blacklist that gets checked early in the boot cycle. One of the things checked is the flags mentioned above. It appears the kernel checks immediately on loading, and if it sees the flags tripped, it pops up a yellow triangle stating that non-approved by AT&T software has been detected, and stops booting.
Tonight I will fiddle with it to see if I can get a working image for those with custom/knox/etc. flags tripped, as I currently have a softbrick. Even just inserting the charger cable from power off, which would normally bring up the battery icon and show a charging animation, gives you the yellow triangle and warning msg. It stays on the screen for about 2 minutes then reboots in a loop. This tells me it's likely a flag being checked by the kernel.
I'm hoping I can flash the original stock firmware back to the device in bits (the full image won't take becuase it tries to overwrite sboot and sboot blocks it) to get phone function back. Time will tell
So, it sounds like you guys are learning some of the things needed that may potentially gets us rooted...
Thanks for working on this stuff with @muniz_ri. He doesn't even own this device, yet he is willing to help try to get us rooted.
Fingers crossed...
dandroid7 said:
So, it sounds like you guys are learning some of the things needed that may potentially gets us rooted...
Thanks for working on this stuff with @muniz_ri. He doesn't even own this device, yet he is willing to help try to get us rooted.
Fingers crossed...
Click to expand...
Click to collapse
I don't either, at least not the AT&T model, but I learned about the method using an older boot.img and Towelroot while rooting an AT&T S5 for a friend, and tried to help out in another thread but couldn't figure out how to get the signed boot.img for 4.4.2 on the sgh-i467 to restore the kernel after rooting.
If @muniz_ri can figure that part out you guys may still have a chance at root.
ramjet73
Pulling signed images is actually pretty darn simple:
using adb:
Code:
$ adb shell
$ su
#
# dd if=/dev/block/mmcblk0pXXXXXX of=/mnt/extSdCard/mmcblk0pXXXXXX
Substitue XXXXXX for the partitions you want to dump, in this case the various kernels (one for normal boot, one for recovery, etc.) are: mmcblk0p9, mmcblk0p10
you can rename mmcblk0p9 to kernel.img and mmcblk0p10 to recovery.img (assuming that's what they are, I haven't actually disassembled the kernel(s) yet.)
Then odin will accept those as flashable images. The same can be done for system.img, etc.
Of course, this assumes having root already. Since 4.4.2 isn't rootable directly...
You need a base boot.img (which is why muniz_ri wanted the patch set from the base firmware) - then apply the patch(es) contained in the OTA zip manually, et voila, signed 4.4.2 kernel.
I have quite a bit of experience with this from the Galaxy Note 1 i717, wrote a ton of kernels for it. Disassembly and rebuilding of a kernel's ramdisk is fun. I would already be on top of this if my laptop hadn't been stolen. I have to sit and wait while my ancient dell computer chugs away at things constantly, I love it
For the next few hours i'll be working on it. My wifey is a little pissed that I nuked her phone just before our trip out of state. Tomorrow.. lol
I love it when people talk like android ninjas.... it usually means good things are happening
Way to go @Da_G
Condolences to the wife's i467... may it be resurrected swiftly.
Da_G said:
Pulling signed images is actually pretty darn simple:
using adb:
Code:
$ adb shell
$ su
#
# dd if=/dev/block/mmcblk0pXXXXXX of=/mnt/extSdCard/mmcblk0pXXXXXX
Substitue XXXXXX for the partitions you want to dump, in this case the various kernels (one for normal boot, one for recovery, etc.) are: mmcblk0p9, mmcblk0p10
you can rename mmcblk0p9 to kernel.img and mmcblk0p10 to recovery.img (assuming that's what they are, I haven't actually disassembled the kernel(s) yet.)
Then odin will accept those as flashable images. The same can be done for system.img, etc.
Of course, this assumes having root already. Since 4.4.2 isn't rootable directly...
You need a base boot.img (which is why muniz_ri wanted the patch set from the base firmware) - then apply the patch(es) contained in the OTA zip manually, et voila, signed 4.4.2 kernel.
I have quite a bit of experience with this from the Galaxy Note 1 i717, wrote a ton of kernels for it. Disassembly and rebuilding of a kernel's ramdisk is fun. I would already be on top of this if my laptop hadn't been stolen. I have to sit and wait while my ancient dell computer chugs away at things constantly, I love it
For the next few hours i'll be working on it. My wifey is a little pissed that I nuked her phone just before our trip out of state. Tomorrow.. lol
Click to expand...
Click to collapse
lol, good luck. Just got home, will download and post as soon as i can Thanks for taking one for team!
Da_G said:
Hmm, for some reason I can't upgrade to 4.4.2 at all now.. looks like my sboot remains at NI2 version after using odin to downgrade (bootloaders tend not to be downgradable, so that's not too surprising)
However, any way I go about it, even just waiting for the OTA to come down from AT&T and installing it, I get the previously mentioned error message. System boots fine on MF1. Hmmm..! My wifey is gonna be pissed at me if I nuked her phone and didn't even get an update, haha
Anywho, here's the 2400258.cfg: https://drive.google.com/file/d/0B1FdfRFXDji6enVvbHNxU05IZkU/view?usp=sharing
Click to expand...
Click to collapse
@dandroid7
Here it is......this method has proven rather safe on many other devices, worst case is usually the device will not boot on the MF1 kernel. If that happens flash back the NI2 kernel and we say we tried. If it works I will post a guide for All. Proceed at your own risk!
From a device running unrooted NI2 follow these steps:
Edit: Failed!
1. Place your phone into "Download Mode."
2. Flash the I467_MF1_Stock_Kernel.tar.md5 using Odin's PDA slot(AP in Odin v3.09+).
3. Root using Towelroot-v3.apk(internet access not required).
4. Power off then boot into "Download Mode" again.
5. Flash the I467_NI2_Stock_Kernel.tar.md5 also in Odin's PDA slot(AP in Odin v3.09+).
6. Install SuperSU to manage root access. Done!
On it... will report back in a bit.
@muniz_ri
No dice amigo...
Flashed mf1 kernel.... upon reboot got a Samsung Galaxy Note 8 splash screen for a second or so... then the dreaded YELLOW TRIANGLE... "software not authorized" message
I even tried wiping cache just for the heck of it and rebooting... still yellow triangle.
I Flashed back the ni2 kernel and it booted right up.
After rebooting with ni2 kernel, I checked status on the following:
Current Binary is "Samsung Official"
System Status is "Official"
Knox Warranty Void "1"
RP SWREV "A2"
I tried doing this in both Odin v3.o7 and Odin v3.10
What does the brief Samsung splash screen tell us? I'm feeling like that's a clue about where in the process the device sees the replaced kernel... does that give you any other ideas?
I'm thinking this might help @Da_G get his wife's device up and running again cause he was stuck at the yellow triangle earlier today.
I'm really frustrated. I've been trying to update this Galaxy S3 for days now with no success. Currently I am running on Slimkat 7.0. It's sometimes slow and buggy and needs some updating.
For reference, this is the phone at its current state:
- Bootloader: i747ucalh9 (literally taken from the fail message when trying to update to any other bootloader)
- Modem/firmware (?): I747UCLH9
Here's what has happened, greatly summarized (note I'm using CM6.0.4.7 for all of these operations, and when I say "update", I mean "flash"):
- I tried updating to Slimkat 9 but received no signal. I gave up on it entirely for a while
- I tried installing various LP ROMs, including CM12.1.
- I had 12.1 running for a bit, but I had no connectivity. LTE, 3G,H+ nothing.
- I tried installing a newer modem (this thread. Finally at MJB, I could actually get connectivity in some of the newer ROMs (including Slimkat 9)... but it was very erratic. It would just randomly oscillate between LTE and 3G and H+. This also broke CM12.1 entirely.
- Again, the above problem was always present. Most of the LP ROMs would just bootloop me, though. The only one that worked was Cyanide L... which I didn't really like.
- I thought maybe the issue was the bootloader. My bootloader is still i747ucalh9. So I tried updating it to various bootloaders from here, but none of the updates will work. Literally, they give me error 6 or 7 and pretty much essentially tell me that I can't do it.
- So after repeating the cycle of "let me try to update this" several times and having the update fail on me, I'm still stuck at Slimkat 7 as the only thing that worked on LTE (note the past tense). Worse yet, I tried simply downgrading my modem to match my current bootloader version, but that made things worse than better. I am now stuck at 3G... which just recently went back to LTE. Talk about erratic.
- I also tried going full stock by flashing this: http://forum.xda-developers.com/showthread.php?t=2363882 But it expects 5 arguments for format, and got 3... or something. Failed hard.
So, I'm pretty much at the end of my rope here. I really might just go and grab a new phone at this point. I just really don't want to because this thing still works fine.... I guess I got unlucky and am at a version of the bootloader that is difficult to update from. I can't seem to go anywhere with this thing. Anyone have any ideas? Do I need to use a different recovery?
Thanks...
First and foremost, verify your bootloader. Install the Samsung phone info app, or in a terminal app or adb shell enter:
Code:
getprop ro.bootloader
If you're on any of the older bootloaders (the ones that do not end in MJB, NE4, or NJ1) there are two ways you can go (you probably will be given the age of your modem). If you're on any of the ones that end in MJB, NE4, or NJ1 you've got to be a lot more careful because downgrading them will hard brick your phone (Odin back to stock is not an option anymore).
Option 1: If you're on the older bootloaders, you can go to sammobile.com, grab the 4.1.1 firmware from there and flash it with Odin. Do not do this if your bootloader ends in MJB, NE4, or NJ1 (can't stress that enough). This will reset your phone completely to stock. You should now start getting OTA updates. They will be incremental updates, you'll have to take at least three or four to get up to date on bootloader and modem and they're big downloads. They will come every 24 hours, but you can cheat that by setting your system time forward 1 day to make them a little more rapid fire. This is a nice, safe way to get your firmware current. Once you're up to NJ1 firmware you can use Odin to flash a custom recovery and get back to custom ROMs; I'd recommend TWRP 2.8.6 if you're going to be flashing newer ROMs as CWM and Philz aren't as up to date and sometimes give problems with newer ROMs.
Option 2: I'm pretty sure your version of CWM is a big part of your problem. If you're going to be flashing lollipop you ought to update your recovery to TWRP 2.8.6; easiest way to get it is just use the Flashify app. I'd get that recovery up to date before messing with bootloaders too. Next get your firmware up to date. If your bootloader version is before MJB, then you have to start with MJB. Then update to NE4. Then update to NJ1. It has to be done incrementally, and the bootloader and modem must match on the newer firmwares, or you'll hard brick. This thread has recovery flashable MJB and NE4 bootloaders/modems; the bootloader and modem are packaged together in the same zip so you can't get out of sync. This thread has recovery flashable NJ1 bootloader/modem. This will get your firmware all up to date, and data should start behaving on newer kitkat and lollipop ROMs. This route is a lot more risky than the OTA route described above because of all the manual steps you have to take, but you could get it done quite a bit faster if you're confident in your abilities. Just read those linked threads very, very carefully and make certain you understand.
Good luck.
jason2678 said:
First and foremost, verify your bootloader. Install the Samsung phone info app, or in a terminal app or adb shell enter:
Code:
getprop ro.bootloader
If you're on any of the older bootloaders (the ones that do not end in MJB, NE4, or NJ1) there are two ways you can go (you probably will be given the age of your modem). If you're on any of the ones that end in MJB, NE4, or NJ1 you've got to be a lot more careful because downgrading them will hard brick your phone (Odin back to stock is not an option anymore).
Option 1: If you're on the older bootloaders, you can go to sammobile.com, grab the 4.1.1 firmware from there and flash it with Odin. Do not do this if your bootloader ends in MJB, NE4, or NJ1 (can't stress that enough). This will reset your phone completely to stock. You should now start getting OTA updates. They will be incremental updates, you'll have to take at least three or four to get up to date on bootloader and modem and they're big downloads. They will come every 24 hours, but you can cheat that by setting your system time forward 1 day to make them a little more rapid fire. This is a nice, safe way to get your firmware current. Once you're up to NJ1 firmware you can use Odin to flash a custom recovery and get back to custom ROMs; I'd recommend TWRP 2.8.6 if you're going to be flashing newer ROMs as CWM and Philz aren't as up to date and sometimes give problems with newer ROMs.
Option 2: I'm pretty sure your version of CWM is a big part of your problem. If you're going to be flashing lollipop you ought to update your recovery to TWRP 2.8.6; easiest way to get it is just use the Flashify app. I'd get that recovery up to date before messing with bootloaders too. Next get your firmware up to date. If your bootloader version is before MJB, then you have to start with MJB. Then update to NE4. Then update to NJ1. It has to be done incrementally, and the bootloader and modem must match on the newer firmwares, or you'll hard brick. This thread has recovery flashable MJB and NE4 bootloaders/modems; the bootloader and modem are packaged together in the same zip so you can't get out of sync. This thread has recovery flashable NJ1 bootloader/modem. This will get your firmware all up to date, and data should start behaving on newer kitkat and lollipop ROMs. This route is a lot more risky than the OTA route described above because of all the manual steps you have to take, but you could get it done quite a bit faster if you're confident in your abilities. Just read those linked threads very, very carefully and make certain you understand.
Good luck.
Click to expand...
Click to collapse
Thanks a lot for the help! I actually did/tried a majority of this an hour or two before you posted that, except the latest firmware update link you supplied. I knew it existed and I had seen that thread before, but I couldn't dig up the link again before I had to go to work. Thing is I kind of wanted to avoid Odin for some reason but I finally gave up and used it. And yeah I already knew my bootloader version. The phone told me when it failed to update the bootloader lol.
Here's what happened thus far:
- I used Odin to flash the sammobile 4.1.1. The flashing worked just fine, but booting into it did not. It hung on the Samsung logo. So, OTA updates were out the window.
- I have no idea why, so I just used Odin to flash TWRP onto it afterwards (from here)
- I tried one of the ROMS. Data still didn't work.
- I used the thread you linked to update to MJB bootloader and whatnot. The update went fine.
- Tried another few ROMs. Data worked, but LTE was still erratic.
- Updated to NE4 and then grabbed the deoxed stock ROM.
- The deoxed stock rom failed to boot (stuck at ATT globe logo). For some reason my phone can't use stock ROMs.
- So again used Odin to put TWRP onto the phone
- Installed various LP ROMS. Again the data was erratic and plus the battery life was horrid.
- Tried getting the ktoonsez kernel. My service was murdered.
- Gave up on LP. Tried Slim 9.0. Erratic data.
- Tried Liquidsmooth 4.4.4 instead.
Currently that's kind of where I'm at. The LTE data works fine (takes a bit to get up and running after reboot though) and thus far everything is okay (though that can quickly change considering I haven't done much of anything), so I don't even know if I want to mess with it anymore. It looks like this specific ROM includes a custom kernel. So I'm guessing it's an incompatibility between the kernel and the firmware version on the other ROMs. It seems like most of the LP roms have horrible battery life (back of my phone feels like a furnace on them), so I'm not even sure if I want to do that last firmware update to use them.
It'd be kind of nice to use the OTA but apparently my ability to go stock in any form or fashion is just totally borked.
Thanks for the post though, that's pretty gold. I'm sure someone in a situation like me where they have a super old firmware will find this thread of some use as it has actual instructions and links to what you need to do to get up and running. Before you posted that, I had to go digging around pretty much everywhere figuring out what and where was going wrong.
Glad you've got it mostly working.
You might have been able to get that stock ROM to boot if you had booted into the stock recovery and run a full wipe. Touchwiz ROMs can be tough to get running after being on AOSP. As a general progression try to format internal storage with TWRP (the wipe where you have to type "yes" to confirm), if that doesn't work try a wipe with Philz, and if that doesn't work nothing, not even Odin, is effective as a wipe in the stock recovery.
Thanks for typing all this out I believe it will help me put cm12.1 official on a friends phone.
Are these the steps?
1) verify latest software
2) twrp via Odin
Alt 2) root via apk then use rashr or similar to flash twrp
3)wipe
4)In twrp install official d2att from cm website
5) install current gapps
6) profit
I'm not new to this at all but I've never even touched an att gs3 and I know most devices have their quirks and I don't want to brick.
Also does towel root work on this? I don't mind Odin but I can do this on the fly I think if I can attain root.
Sent from my DROID RAZR M using XDA Free mobile app
mrkhigh said:
Thanks for typing all this out I believe it will help me put cm12.1 official on a friends phone.
Are these the steps?
1) verify latest software
2) twrp via Odin
Alt 2) root via apk then use rashr or similar to flash twrp
3)wipe
4)In twrp install official d2att from cm website
5) install current gapps
6) profit
I'm not new to this at all but I've never even touched an att gs3 and I know most devices have their quirks and I don't want to brick.
Also does towel root work on this? I don't mind Odin but I can do this on the fly I think if I can attain root.
Sent from my DROID RAZR M using XDA Free mobile app
Click to expand...
Click to collapse
Yep. You've got it. If you're on the latest and greatest firmware I think the towelroot exploit has been patched, unless geohot has retaken the lead in that arms race.
Easiest way to root on this phone since the bootloaders are unlocked is to just use Odin to flash a custom recovery then use the custom recovery to flash SuperSU. There's just a little trick to it. Store SuperSU.zip somewhere on your phone before flashing the custom recovery. Uncheck everything but f.reset time when you use Odin; don't let it auto reboot. Upon success pull battery. Replace battery and boot straight into recovery with vol up + home + power. If you mess up and boot into unrooted stock ROM with a custom recovery it will get overwritten with a stock recovery and you'll have to Odin custom recovery back onto it and try again.
I would do this to root your stock ROM just to execute this command in a terminal app or adb shell before any more serious flashing:
Code:
su
reboot nvbackup
That fixes a derp and gives you a working efs backup on a few backup partitions built into your phone instead of a blank one. Highly recommended before doing any ROM flashing. This will just look like a pretty normal reboot. You might see a quick flash of tiny blue text if you're watching for it.
Then you're ready to make a nandroid backup (just in case), wipe, and flash away. Take a look at LiquidSmooth if you're looking for a good lollipop ROM.
Nice... So the recovery partition gets rewritten every boot up until a custom ROM is installed and the efs can disappear... This is why you always ask questions.
Thanks for the suggestion on the ROM but I think I'll stick to official cm12.1 it's not my phone and that should be a nice readily updatable bland flavor of lollipop.
Sent from my DROID RAZR M using XDA Free mobile app
mrkhigh said:
Nice... So the recovery partition gets rewritten every boot up until a custom ROM is installed and the efs can disappear... This is why you always ask questions.
Click to expand...
Click to collapse
At the Android 4.3 update it was noticed that flashing a custom recovery would be overwritten by the stock recovery on the initial reboot unless following the method Jason described. Another solution was to delete two lib or .so files. On devices still on stock recovery, stock recovery does not overwrite itself.
There is a blank EFS partition on the device intended for a backup. The nvbackup command populates that partition with an image which will rebuild your EFS if it is lost during a modem update or ROM flash. The loss of EFS does happen. I believe wanam, of the xposed module fame, created an EFS backup tool for Samsung devices. I don't believe he updates it any longer because he rolled the functionality into a partition backup tool, the later is in the PlayStore listed under a different creator name, yet it's still him.
So I'm finally going to take the plunge, and update my boot loader/modem.. I never messed with it because all the Roms I used always worked.. I want to try lollipop, but due to old bootloader my phone won't boot with those Roms..
I'm on UCDLK3 bootloader/modem.. I know I have to upgrade to MJB, NE4, then NJ1 in that order in increments..
So my question: can I upgrade from LK3 straight to MJB with out any problems?? Or is there something I need to flash before I can get to MJB?? I think I can go straight to MJB, but better safe then sorry..
I know downgrading after upgrade most likely will brick.. Any information is appreciated... Oh, its an ATT I747..
coolwhipp420 said:
So I'm finally going to take the plunge, and update my boot loader/modem.. I never messed with it because all the Roms I used always worked.. I want to try lollipop, but due to old bootloader my phone won't boot with those Roms..
I'm on UCDLK3 bootloader/modem.. I know I have to upgrade to MJB, NE4, then NJ1 in that order in increments..
So my question: can I upgrade from LK3 straight to MJB with out any problems?? Or is there something I need to flash before I can get to MJB?? I think I can go straight to MJB, but better safe then sorry..
I know downgrading after upgrade most likely will brick.. Any information is appreciated... Oh, its an ATT I747..
Click to expand...
Click to collapse
Since you are on LK3 you may want to considr applying the free sim/carrier unlock method before upgrading; that is if you are on stock LK3 and you have not previously carrier unlocked your device.
There was an OTA release for the MG2 stock ROM, I believe that was 4.1.2. You may want to go to that before MJB. Did you make the nvbackup suggested by Jason?
Why would I do a carrier unlock, if I'm not switching carriers?? And if I do it, will I be able to use the same carrier?? Just seems like a waisted step for me.. But idk..
Jason's first post, option 2 is how I was planing to update.. And no, I haven't done the nvbackup yet.. How would I apply that backup if things go wrong? Not really sure what a nvbackup is..
Any information is appreciated..
coolwhipp420 said:
Why would I do a carrier unlock, if I'm not switching carriers?? And if I do it, will I be able to use the same carrier?? Just seems like a waisted step for me.. But idk..
Jason's first post, option 2 is how I was planing to update.. And no, I haven't done the nvbackup yet.. How would I apply that backup if things go wrong? Not really sure what a nvbackup is..
Any information is appreciated..
Click to expand...
Click to collapse
There is a command to manually trigger the restore routine. I think it's
Code:
reboot nvrestore
but don't hold me to that. I'd never execute that command except if in dire need. The problem with this phone is there is an automatic routine that can be triggered in the event of a bad flash that will overwrite your nvram with the backup, even if the backup is blank. I don't think the backup stores anything modem specific, but I've never been able to confirm that. So I've always done it again after updating modems (only had to once).
Having the phone sim unlocked can be nice if you plan on traveling internationally. Otherwise, potential future carrier hopping or added resale value are the only reasons to do it.
coolwhipp420 said:
Why would I do a carrier unlock, if I'm not switching carriers?? And if I do it, will I be able to use the same carrier?? Just seems like a waisted step for me.. But idk..
Jason's first post, option 2 is how I was planing to update.. And no, I haven't done the nvbackup yet.. How would I apply that backup if things go wrong? Not really sure what a nvbackup is..
Any information is appreciated..
Click to expand...
Click to collapse
If you will never be switching carriers, nor ever sell/give/trade the phone to someone who will switch, then it is an unecessary step to do the carrier unlock.
I see Jason beat me to answering both of your questions.
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!!!
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.