Database Users

nandroid before unlocking. possible?

I have my phone on the way and the first thing I would like to do is backup before unlocking anything so that I can always go back to original. Possible?

just an fyi: "unlocking" means making your phone work on any carrier that uses GSM technology (in the states it means opening up a phone that was once T-Mobile-only OR ATT-only to both att or t-mobile).
"rooting" (or if you're an iphone user, "jailbreaking") means gaining permissions to the underlying filesystem of the phone that the shipped phone usually locks you out of.
and sorry, no dice. you have to flash the recovery partition to do a nandroid backup.

Sorry for that. I meant unlocking, the bootloader to be exact. I do know it is possible to boot to a custom recovery without flashing it. What I want to know is if I can do that without unlocking the bootloader, or maybe some other method?

You can boot a custom recovery image without flashing it: fastboot boot recovery.img
You cannot do this until you've unlocked the bootloader, however.
The bootloader unlock process does not modify the boot, recovery, or system partitions, so you could still back them up as they originally were.
We had hoped to have an official factory image made available (perhaps through developer.htc.com) for restoring the device to it's original state, should you install a custom build that doesn't work, or otherwise want to get back to the original build. We're till working out the details on this.

Kernel/bootloader/recovery

Hi guys,
1. What is the advantage/disadvantage of flashing a custom kernel?
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
7. Difference between unlocking bootloader and rooting.
8. How to find out N7's latest stock kernel version.
Many thanx
Sent from my Nexus 7 using Tapatalk 4 Beta

valapsp said:
1. What is the advantage/disadvantage of flashing a custom kernel?
Click to expand...
Click to collapse
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
valapsp said:
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
Click to expand...
Click to collapse
I believe it does. I don't remember which one though, since I don't use CM.
valapsp said:
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
Click to expand...
Click to collapse
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
valapsp said:
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
Click to expand...
Click to collapse
I believe it contains stock ROM and kernel.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
valapsp said:
7. Difference between unlocking bootloader and rooting.
Click to expand...
Click to collapse
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
valapsp said:
8. How to find out N7's latest stock kernel version.
Click to expand...
Click to collapse
Google. Sorry, can't help you with this one.

That was a great answer @Rirere

Rirere said:
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
I believe it does. I don't remember which one though, since I don't use CM.
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
I believe it contains stock ROM and kernel.
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
Google. Sorry, can't help you with this one.
Click to expand...
Click to collapse
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.

valapsp said:
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.
Click to expand...
Click to collapse
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).

Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta

valapsp said:
Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.

kbeezie said:
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.
Click to expand...
Click to collapse
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img

valapsp said:
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img
Click to expand...
Click to collapse
bootloader img would be the original stock bootloader for the Nexus 7, chances are you never replaced it, you only unlocked it. There's usually no reason to replace the bootloader with a custom one since all you need to do is unlock it.
userdata.img would be the /data partition. The firmware download basically has a image for all of the partition in the original out-of-the-box stock state. Technically you don't even to flash it, as long as you wiped /data before rebooting (since that would be the same as a clean install if you instead flashed the system and boot partition).
Edit: If I were messing with it to get back stock rom (but not messing with recovery, cuz custom recovery is still handy to have), I would only flash the boot.img and system.img , then log into Recovery and wipe data (ie: factory reset which wipes cache and /data but doesn't touch /data/media), Then I would be able to reboot into a clean stock install of the rom.
(from there I could just make a backup from recovery so I wouldn't have to do a fastboot flash again).

kbeezie said:
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).
Click to expand...
Click to collapse
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.

@valapsp
Small but important clarification.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Essentially 100% of custom ROMs install a kernel. (Actually, a kernel plus a ramdisk packaged together as a single ("bootable image") file, typically named "boot.img".) So your preexisting boot image containing the kernel is always overwritten during a ROM installation. See next answer.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Almost, but not quite. If you want to use a different kernel than what ships with a given ROM, you flash it after you have installed the ROM, not beforehand. See prior answer.
One more thing. Since you are new to this stuff, I'll make a suggestion:
Learn how to create and restore full Nandroid backups (using the custom recovery) immediately. And get in the habit of copying them off your tablet to your PC. You will thank me later for this advice.
have fun

Rirere said:
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.
Click to expand...
Click to collapse
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.

GedBlake said:
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.
Click to expand...
Click to collapse
I believe you are correct! Theoretically, the script could rather easily check for added files by checksumming the entire /system partition before running the update (using a fast hash algorithm-- you're only looking for the presence of any changes, afterall). And I did have one OTA that went fine, other than losing root back on my Galaxy Nexus.
Again though, it's a classic case of should versus real life. Some root methods might alter things in /system without your knowing, or root actions might alter permissions. Either way, it's a tricky, nasty little game.
So far as recoveries go: yeah, OTAs have a nasty habit of trying to do that. Some of the more advanced recoveries can resist being overwritten though/slipstream a root ZIP into the update process.

GedBlake said:
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Click to expand...
Click to collapse
Typically the OTAs also update the boot image, so the boot partition (LNX) is also checked. The stock recoveries almost always use the same kernel (with a different ramdisk) as the boot image, so they are usually rewritten too.
Owners of tilapia N7 devices have reported successful flashing of everything but radio firmware images when they used a custom recovery to process the OTA bundle. Not a disaster, as their devices will still function with old radio firmware, but it puts them in an unusual position of being unable to use the OTA to subsequently update the radio, even if they restore the stock recovery (the system files and boot images will have been changed, so almost all of the checksums will fail). At that point, using fastboot is an alternate option, but then the newbs will need to read about OTA images, unpack them, yadda yadda yadda.
IMO it is just a dumb idea applying OTAs to anything but a pure stock device. And when I say pure stock, I mean including the stock recovery. The boot loader can be left unlocked, but that's about it.
There are a lot of ways to skin the cat, but IMO the best way to proceed is to operate with two parallel but independent tracks of Nandroid backups/restores: one track is a sequence of pure stock, and the other your customized ROM du jour.
Let's presume you have a Nandroid backup of the pure stock ROM. Make a backup of your current (customized) ROM & get it copied off the tablet (in the event of a disaster), restore the pure stock ROM nandroid backup, flash the stock recovery back to the tab, and then take the OTA.
At this point:
[ unlocked bootloader ] soft-boot (no flashing) a custom recovery using fastboot, and then make yet another Nandroid backup of the newly updated stock ROM including the recovery image. (This becomes the new baseline for future OTAs)
[ locked bootloader ] re-root with motochopper, capture the (new) stock recovery partition using 'dd', flash a custom recovery ('dd' or other method), make a Nandroid of this. (These two backups become the new baseline for future OTAs)
Then, repeat any rooting customizations (if you are a "lightly customized rooted stock" kinda person), and restore apps (Market apps only!) with TiBu.
This may seem like a great deal of work, but it is the only way to insure that you can revert to a prior starting position. Look: after going down a road like this you can even restore the old customized ROM backup to make TiBu app backups after the fact, simply because you can return to any point in time if you have made a backup (and kept a copy of it off the tablet).
Everybody makes mistakes - even the experts. But the lazier folks are (read: toolkit user) the more likely is a disaster. Everybody needs to make backups.

What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app

valapsp said:
What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).

kbeezie said:
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).
Click to expand...
Click to collapse
Thanks, and does backing up thru cwm also back up the build.prop?

valapsp said:
Thanks, and does backing up thru cwm also back up the build.prop?
Click to expand...
Click to collapse
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.

kbeezie said:
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.
Click to expand...
Click to collapse
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app

valapsp said:
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
If it's a backup done with 4EXT or TWRP most certainly since it's just a tarball package (or tar+gzipped if you enabled compression) and can be easily unpacked by tar, or any popular archive utility like 7Zip for windows. (restoration generally just looks at the file info to see what partition type it's supposed to be, formats the partition as such, and then just un-tars the content, with the permissions and such retained).
If it's older where it's an actual jaffs (may have spelled that wrong) disk image, I'm not sure off the top of my head how you would mount it as a disk , and then mount the ext4 or ext3 partition in order to get to it. I would assume ClockworkMod would have upgraded their backup method to the same as TWRP or 4EXT, but it's possible that they didn't for compatibility reasons.

[Q] q Looking for a little conceptual understanding regarding Loki

I've come most recently from a Galaxy S4 with a locked bootloader using safestrap, and before that from an S3 with an unlocked bootloader.
On the S3, with it's unlocked bootloader I flashed roms without really worrying that much about kernals or rom "bases"
When I used safestrap I understood it was really important that the rom I was flashing was based on the "base" I was locked into by virtue of the particular OTA I was on.
Now that I have my verizon G2 i've rooted the 12b ota with ioroot and i'm about to install a recovery using freegee, but before I go forward I'd like to understand a little bit more how careful do I have to be to find out what "base" the rom i'm about to flash was built on/for? can install a rom or restore a backup that is based on a different verizon ota then my own? I understand tha Loki is a "bypass" and not a bootloader unlock, but I'm not really sure what that means.
Please enlighten me.

Unlike an actual bootloader unlock, Loki is dependent upon the kernel.
When you boot the phone, the bootloader loads the kernel into the memory and then verifies it. In that order. If the signature verification is successful, the bootloader proceeds with the boot process. If it does not, the boot process is aborted and a security error is displayed.
The key to the Loki exploit is actually at the step where the kernel is loaded into the memory. The flaw in the bootloader is that it relies upon the boot image header to determine the location at which to load the kernel and the ramdisk in the memory. The signature verification occurs after this. The exploit works by using an address in the boot image header that actually overwrites the part of the bootloader in the memory that does the signature verification. Shellcode added by the user is loaded to where the ramdisk is expected to reside and patches up boot image header and loads the kernel and ramdisk into the memory at the correct location, and then returns a value that would indicate that signature verification was successful, and thus the bootloader proceeds with the boot process with the custom kernel.
All in all it's pretty simple, and quite brilliant.
If you are installing a custom ROM or kernel, all of boot images have this exploit written into them, otherwise they will not boot. As an end user, all you need to really worry about is things like checking integrity, as if you flash a damaged image it will not run the exploit as it is supposed to and fail to boot, you'll get a security error, and basically have no option other than to flash completely back to stock (or if you end up in fastboot, flash a good boot image and recovery that properly exploit the bootloader and can boot the ROM you have installed or recovery). It's not much different from an actual bootloader unlock to the user, as if you get a bad download and flash it you're going to have problems no matter what. Check your md5s always!
Perhaps worth noting is that this exploit has been patched in the official kit-kat releases. I do not know too much about the new bootloader, but I am told that it includes steps that verify it's own integrity so it will not boot if it is overwritten. Since the old bootloader won't boot official 4.4.2, there is currently no way to get both official 4.4.2 and a custom recovery.
Sent from my Nexus 7 using Tapatalk

Thanks
Thanks, but I'm still confused about the practical ramifications.
When I choose a rom to install does it need to specifically be built on the 12b ota? when I'm on a particular ota can I restore a backup that was had a different base? both of those things were things I couldn't do with safestrap, but I could on my bootloader-unlocked phones

Edited my first post with a little more info. Loki had to be updated for 12B. Most ROMs and kernels have been updated but some won't work. I would read the ROMs thread to make sure. I am on 12B currently and I have not run into any problems with it yet, but it never hurts to read the thread for the things you are flashing and seeing if others are having a problem. This is not like safestrap where you are limited to the stock kernel (or one specific kernel if you have kexec). Any kernel that is properly Loki'd will be bootable as long as you don't do something like try to boot an AOSP ROM on a stock kernel. There are a few incompatibilities between ROMs and kernels that arise from various ROMs moving away from AOSP but this has nothing to do with this specific exploit and would happen regardless of bootloader unlocking/hacking methods
Sent from my Nexus 7 using Tapatalk

had to give back note 7 so im resurrecting my note 3 thats still on mje/4.3

I was wondering if someone could give me a direct answer because i cant seem to find one sifting through the forums.
I originally rooted with root master back when i got the phone. it is still on mje/4.3 stock build. things look a little more complicated then i remember, since my phone hasn't seen an update in over 3 years. I originally froze the verizon ota updates with tibackup, along with all the other bloatware.
My main questions are:
1. I would like to get a 6.0 Rom that looks like the note 7 did, can i do it all with odin and just flash a bunch of files?
2. Do I need a custom recovery like twrp or cwm?
3. I've read about an activation lock but can't find it in my menus, did it not exist yet on 4.3?
If anyone can point me in the right direction I would appreciate it, I really dont wanna brick my phone.

I'm still on MJE firmware, but using an older CM13 (temasek) ROM. So it's marshmallow but no Touchwiz or other Samsung add-ons.
Here are the MJE-specific issues:
1) You can't boot N* or O* stock kernels because of differences in the way that DTB (device tree blobs) are packed into the boot image. I've played with re-packing the boot images, but the kernels seem to run off into the weeds after a few tens of seconds.
2) TowelRoot works on MI9 through NC2(leak) but I think not thereafter - if you wanted to avoid a bootloader firmware upgrade but re-flash via Odin the MJE firmware for "starting from scratch" purposes, you have a means to re-root that does not require a PC.
3) If you retain the MJE bootloader, use the TWRP (hltevzw) -4.3 recovery; the -4.4 recovery will not boot, presumably due to issues similar to (1) above.
4) Not specific to MJE - but important - is the fact that if you want to boot either a custom kernel or custom recovery, you need to unlock your bootloader first. You can unlock your bootloader from any rooted ROM, but be aware that flashing stock firmware with Odin thereafter will re-lock the bootloader.
If you were to "start from scratch" but upgrade to more recent stock software before rooting, be aware that there is no publicly available root for NC4 or NK1; you would need to install stock OB6 or OF1, and follow that by using those "yemen" rooting tools. (Are they safe to use? I don't know frankly)
I am assuming that the N* and O* series bootloaders are backwards compatible with regard to device tree booting issues (see #1 above), because the temasek CM13 roms (having a custom kernel) boot on both OF1- and (my) MJE- bootloader phone. I guess that means it uses a "4.3" DTB packing in the boot image.
You are probably going to want to use TiBu to make important backups, and also copy everything off the phone that is important to you. You should assume that if anything goes wrong, an Odin re-install and factory reset are in the device's future.
Having said all this, I'm not sure there is such a thing as a ROM which "looks like Note7" - this is an old phone with almost no ROM developers left. There might have been more, but the bootloader unlock was achieved 2+ years after the phone's release, and most of the active developers moved on to new phones before that happened.
good luck

Need help flashing ROM on I545

Hi it is the first time I am flashing Android ROM. I have done some reading already. Before I start, I still have a few questions and also want to make sure I am doing it right.
I own the Galaxy S4 Verizon I545. It is running Samsung ROM Android 4.4.2, Baseband I545VRUFNC5. My goal is to flash a new ROM with recent Android versions, hopefully 7.1.1 (but I would settle with Marshmallow if that is more stable), it can be close to AOSP, I don't need ROMs with extra features.
In my understanding, the bootloader is locked, it will only load signed kernels and recovery. And then the kernel would load the system. In order to flash the system, it is best to flash the recovery first with TWRP. TWRP is modded with loki hack so it would load with the locked bootloader.
So here are my questions:
1. Does it matter which firmware/baseband I am currently on? For some phones (LG G2) I heard newer firmware fixed the loki hack. Should I update to the latest Samsung rom or leave it at NC5?
2. I don't see many ROM posted for the i545, which one is the most recent and reasonable stable? The Cyanogen website is down, should I try LineageOS?
3. I see different instructions for flashing TWRP. Can I flash it with just Odin? Some instruction mentioned rooting the phone first with KingRoot or other root, and then use dd. Does the phone have to be rooted? (I prefer not to if it is not necessary)
4. If after I flashed recovery, it fails to boot into TWRP, what can I do to restore everything to default?
5. The kernel will be untouched in the process right? I am only flashing recovery and system ROM, and the kernel will work fine with the new system ROM?
Here are the step and software I plan to use:
0. reset the phone to factory
1. use Odin to flash TWRP 2.8.7
2. download a ROM compatible with I545 and place it on the phone
3. flash the system using TWRP
Any feedback would be appreciated.
PS: Also I have a LG G2 D801. I would flash that phone instead if it is easier. I just want to get started and learn some things along the way.

https://forum.xda-developers.com/galaxy-s4-verizon

Oh Sorry. Didn't notice there is another forum. Should I repost there?

Yes.

1. Yes, it does matter. As you said, newer firmwares have fixed the exploits which make the phone harder to hack.
2. Any ROM should support your phone. They are generally unified.
3. In the name of anything holy, do not root with KingRoot. If you want to root, then the only way to go is CF-Auto-Root.
Rooting is sometimes necessary because recovery won't always install with Odin.
4. Flash stock ROM.
5. Kernels are specific to ROMs. So no, the kernel won't be untouched.