Questions on the state of d2vzw devices running NE1 - Verizon Samsung Galaxy S III

I'm not sure if these questions have been answered before, but I can't find any information on them, so here I am.
1. How exactly is the bootloader "locked"? Is the kernel the only thing that can't be changed?
2. Is kexec possible on NE1?
I know that bootloaders were bypassed on some Motorola Droid devices via kexec. There was even an in-the-works kexec project for our device on an older firmware (that was abandoned only because someone figured out how to unlock the bootloader, or something along those lines). I also realize this is a biggish project, and most people still using the d2vzw didn't ever take the NE1 OTA and are able to flash custom kernels/ROMs. Knowing this, it could be possible that no one really wants to try, either because of time, apathy, etc. But I digress.
Sent from my SCH-I535 using Tapatalk

AluminumTank said:
I'm not sure if these questions have been answered before, but I can't find any information on them, so here I am.
1. How exactly is the bootloader "locked"? Is the kernel the only thing that can't be changed?
2. Is kexec possible on NE1?
I know that bootloaders were bypassed on some Motorola Droid devices via kexec. There was even an in-the-works kexec project for our device on an older firmware (that was abandoned only because someone figured out how to unlock the bootloader, or something along those lines). I also realize this is a biggish project, and most people still using the d2vzw didn't ever take the NE1 OTA and are able to flash custom kernels/ROMs. Knowing this, it could be possible that no one really wants to try, either because of time, apathy, etc. But I digress.
Sent from my SCH-I535 using Tapatalk
Click to expand...
Click to collapse
These questions have been beat into the ground, but I'll be happy to answer them again because they are interesting questions. Good ideas and discussion points anyway.
1) So the bootloader is locked by a series of signed boot sequences. These things can be easily researched on the internet in detail, but a general understanding of how the phone boots is helpful to understanding how this process works. Also every phone is unique, and every carrier has different implementations.
Samsung is especially a hugsePITA when it comes to these things. They allow no easy way to gain root access on your phone in any way. In comparison to HTC for instance, they allow nothing in terms of granting administrator access to anyone. HTC at least as an option for S-off, which allows full administrative usage for the device and turns off all boot checking features. This can't be patched in an easy way, and for an update to change this feature it would have to change the devices system information on an unreasonable level. All Samsung has to do is simply patch whatever vulnerability we find, because there is no way to turn S-off on a samsung phone, so all we do is look for bootchain exploits. If that makes any sense? Basically, samsung sucks, and that's the main reason I will never buy their phones ever again.
2) Any part of the boot sequence can be changed, but the signature affecting these things aren't really easy to trick. Kexec was a very easy exploit to use when it first came out, but the modules for it has thus been changed to disallow the command for kexec to load an insecure kernel. It simply can't work the same anymore since samsung released changes to their boot chain. This method won't be used on any future devices. Most recently we had the original root method and loki for the S4, which both affect the aboot sequence, and safestrap which is basically a modified recovery that uses the stock kernel to run a custom rom. Here's an example:
boot => sbl1 => sbl2 => sbl3 => whatever is here ==> maybe something else here ==> aboot => recovery mode or download mode or kernel => system rom
aboot = African canadian sock monkey exploit (basically an unlocked aboot file) and Loki exploits
recovery mode = safestrap exploit (tricks the kernel to boot a modified rom, but it has to work with the kernel)
As you can see in the chain, break any one of those sequences and it doesn't matter what follows, the phone is unlocked, problem is we've broken the chain about 2-3 times. Every time we find a vulnerability, the it gets patched and it makes it that much harder to find another exploit. Samsung does so much work patching the unlocking mechanism that it simply isn't even worth the effort to unlock it in the first place. We actually didn't even unlock the S3 in the first place. The aboot file was given to us by a Samsung employee and distributed quickly. This aboot file allowed us to change the kernel and recovery at will, without worrying about signature verifcation since the aboot file never asked for it. It was a full unlock for the phone. Once an update happened, it erased the modified boot image and disabled the unlocked bootloader.
This problem is unique to samsung btw, other phones aren't nearly as difficult to figure out and test.

BadUsername said:
These questions have been beat into the ground, but I'll be happy to answer them again because they are interesting questions. Good ideas and discussion points anyway.
1) So the bootloader is locked by a series of signed boot sequences. These things can be easily researched on the internet in detail, but a general understanding of how the phone boots is helpful to understanding how this process works. Also every phone is unique, and every carrier has different implementations.
Samsung is especially a hugsePITA when it comes to these things. They allow no easy way to gain root access on your phone in any way. In comparison to HTC for instance, they allow nothing in terms of granting administrator access to anyone. HTC at least as an option for S-off, which allows full administrative usage for the device and turns off all boot checking features. This can't be patched in an easy way, and for an update to change this feature it would have to change the devices system information on an unreasonable level. All Samsung has to do is simply patch whatever vulnerability we find, because there is no way to turn S-off on a samsung phone, so all we do is look for bootchain exploits. If that makes any sense? Basically, samsung sucks, and that's the main reason I will never buy their phones ever again.
2) Any part of the boot sequence can be changed, but the signature affecting these things aren't really easy to trick. Kexec was a very easy exploit to use when it first came out, but the modules for it has thus been changed to disallow the command for kexec to load an insecure kernel. It simply can't work the same anymore since samsung released changes to their boot chain. This method won't be used on any future devices. Most recently we had the original root method and loki for the S4, which both affect the aboot sequence, and safestrap which is basically a modified recovery that uses the stock kernel to run a custom rom. Here's an example:
boot => sbl1 => sbl2 => sbl3 => whatever is here ==> maybe something else here ==> aboot => recovery mode or download mode or kernel => system rom
aboot = African canadian sock monkey exploit (basically an unlocked aboot file) and Loki exploits
recovery mode = safestrap exploit (tricks the kernel to boot a modified rom, but it has to work with the kernel)
As you can see in the chain, break any one of those sequences and it doesn't matter what follows, the phone is unlocked, problem is we've broken the chain about 2-3 times. Every time we find a vulnerability, the it gets patched and it makes it that much harder to find another exploit. Samsung does so much work patching the unlocking mechanism that it simply isn't even worth the effort to unlock it in the first place. We actually didn't even unlock the S3 in the first place. The aboot file was given to us by a Samsung employee and distributed quickly. This aboot file allowed us to change the kernel and recovery at will, without worrying about signature verifcation since the aboot file never asked for it. It was a full unlock for the phone. Once an update happened, it erased the modified boot image and disabled the unlocked bootloader.
This problem is unique to samsung btw, other phones aren't nearly as difficult to figure out and test.
Click to expand...
Click to collapse
Thanks for the info. This is very informative. I had already in my own mind decided that Samsung sucked, but hearing someone else say it is refreshing!
Sent from my SCH-I535 using Tapatalk

Related

[Q] Insecure aBoot question.

I've been around the Android dev community and have been rooting phones / flashing roms for a while now, but I am not adept to the specifics in regards to the s3. I just came over to Verizon in march and prior to that I have always delt with HTC phones on sprint, which obviously are totally different than Samsung. two questions:
1.) I used Beans method to unlock and root with casual. He mentions that the tool flashes an insecure aBoot in order to run the exploit. Since I'm still on the stock rooted rom, would I need to flash a secure aboot? This probably sounds silly but I just don't know if the insecure aBoot is "still there" so to speak.
2.) Same question applies to the bootchain. I've looked around and cannot find the MF1 bootchain anywhere. From my understanding you don't need to do this, but I'd like to.
Again, I apologize as I am previously an HTC man and don't have a very good understanding of Samsung yet.:good:
AZ FadeOut said:
I've been around the Android dev community and have been rooting phones / flashing roms for a while now, but I am not adept to the specifics in regards to the s3. I just came over to Verizon in march and prior to that I have always delt with HTC phones on sprint, which obviously are totally different than Samsung. two questions:
1.) I used Beans method to unlock and root with casual. He mentions that the tool flashes an insecure aBoot in order to run the exploit. Since I'm still on the stock rooted rom, would I need to flash a secure aboot? This probably sounds silly but I just don't know if the insecure aBoot is "still there" so to speak.
2.) Same question applies to the bootchain. I've looked around and cannot find the MF1 bootchain anywhere. From my understanding you don't need to do this, but I'd like to.
Again, I apologize as I am previously an HTC man and don't have a very good understanding of Samsung yet.:good:
Click to expand...
Click to collapse
1. The insecure aboot is needed to root and unlock your phone with the casual method, you can double check you're unlocked with ez unlock v1.2. It should still be applied.
2. The Bootchain is not very important to restore, and I'm not sure if casual automatically changes it back after the process. You can flash the mb1 Bootchain and be close enough or pm darkmenace and request the mf1 Bootchain. Keeping your Bootchain shouldn't give you any issues.
Sent from my SCH-I535 using Tapatalk 2

[Q] About bootloader versions

Hey guys,
I've been playing around with the firmware on my Moto G and I didn't understand some things related to bootloader/partition table version and I hope someone more knowledgeable can explain me some things, in a more technical way if possible. Links to documentation are also appreciated!
So, apparently you have to keep an eye on bootloader, partition table, and OS versions so they match. You also cannot easily downgrade bootloader versions.
Also, I saw that you can brick your device if you try to flash 5.0.1 ota, then go back to 4.4.2 and flash 4.4.4 ota because of mismatched bootloader versions and will have to wait for official motorola 5.0.1 images.
My first question is why does this happen? If I get stuck on a particular bootloader version (in this case 5.0.1 GPE, right?) why can't I just boot the corresponding OS, why does the device brick (is it incompatible bootloader and partition table, so the bootloader can't find stage 2)?
Second question, apparently you CAN downgrade the bootloader versions, but have to follow some specific steps and use specific files. Why is that? What checks does the devices makes when upgrading bootloaders and what kind of files allow me to downgrade while passing those checks?
Third, why can't you boot older android versions with newer bootloaders? Doesn't the bootloader just initialize some devices and loads the kernel, can't you modify and older kernel to boot with the new bootloader or chainload and older kernel from a newer one? Also why does the boot processes change so frequently when it should be something very stable?
Fourth, what is the rationale behind not allowing you to freely switch bootloader versions?
Well, thats it. Sorry for the long post and thanks to anyone that can help me . Maybe I should post this in android development instead?
I follow .
I believe on Nexus hardware changing Bootloader is an easier process as those devices are deliberately Developer friendly. Motorola are open enough to allow unlocking, but as you have discovered, flashing an older Bootloader is a messy and dangerous process. Perhaps if enough people petitioned for a change, things might be different.
The Bootloader and Kernel are interrelated and that is why newer Bootloader versions break compatibility with previous iterations of Android (each with a unique Kernel.)
It's possible Kernel DEVs could offer a solution, but I suspect the reality is so few people care. The majority of users will get OTA Updates and never go back.
Uh, bump?
Anyone can tell me if there is a more appropriate place to ask question like these?
I hope it will give you some reference in these topics.
http://elinux.org/Android_Booting
http://androidforums.com/threads/android-partitions-kernels-explained.278898/
aryal.subasha said:
I hope it will give you some reference in these topics.
http://elinux.org/Android_Booting
http://androidforums.com/threads/android-partitions-kernels-explained.278898/
Click to expand...
Click to collapse
Thanks, but I already found those in Google and they aren't very useful. Too superficial and both focus on what happens AFTER the kernel is loaded, I'm interested more in the bootloader, how it verifies the signatures, etc.
Anyone?

Why it's not possible to have custom bootloaders?

Many devs are trying to exploit BL locked device to allow custom recoveries and ROMs, but why we can't simply flash a patched BL thorough JTAG to unlock the phone?
honam1021 said:
Many devs are trying to exploit BL locked device to allow custom recoveries and ROMs, but why we can't simply flash a patched BL thorough JTAG to unlock the phone?
Click to expand...
Click to collapse
Some bootloaders are quite hard to crack and in most cases damn near impossible. It's also not worth bricking a device to find an exploit. As with exploits a lot of times the carriers especially VZW are finding ways to patch those same exploits. It's not always worth someone's time
Sent from my Nexus 5
honam1021 said:
Many devs are trying to exploit BL locked device to allow custom recoveries and ROMs, but why we can't simply flash a patched BL thorough JTAG to unlock the phone?
Click to expand...
Click to collapse
Adding on to what ShapesBlue stated very well, it's not so simple developing the patched bootloader can take a considerable amount of time. Additionally many devices now have multi-stage security measures to make doing this difficult, if one stage doesn't have the correct expected img signature the device will fail to boot.

Which files are checked by "locked" bootloaders? Want to root locked phone.

Which files are checked by "locked" bootloaders? Want to root locked phone.
//Skip to the last paragraph if you don't care about the context of the question
Hi, I'm looking to get a few applications requiring root onto a device with a locked bootloader. I'm a programmer, but not an android programmer, and my linux skills are only mediocre. Until recently I had an S5 active (also locked) using TWRP and a custom ROM, but the "waterproof" feature didn't work when I fell in a river with it. I've long since forgotten how I managed to get it working, it involved reading threads here for about 2 days until I figured out enough to get it working.
The only specific items I want to install that require root are a whitelist-style firewall and xprivacy. My plan of attack, unless I find anything more promising, is don't immediately allow the new phone (CAT S60) to get updates, get temporary root with dirtycow, then attempt to modify something that is both A) running in root context and B) the bootloader won't complain about. The problem is that I have no idea which things the bootloader is checking.
What I can't figure out is which files are actually "verified" by the bootloader on Android? Just the initramfs? The entire root partition (i.e. everything outside userspace) as well? Is it a short enough checksum that it could be defeated by padding the image until it reaches the same checksum?
yeah let us know if you can get it to root , lot of people are banging their head over this on this forum
aff3p said:
//Skip to the last paragraph if you don't care about the context of the question
Hi, I'm looking to get a few applications requiring root onto a device with a locked bootloader. I'm a programmer, but not an android programmer, and my linux skills are only mediocre. Until recently I had an S5 active (also locked) using TWRP and a custom ROM, but the "waterproof" feature didn't work when I fell in a river with it. I've long since forgotten how I managed to get it working, it involved reading threads here for about 2 days until I figured out enough to get it working.
The only specific items I want to install that require root are a whitelist-style firewall and xprivacy. My plan of attack, unless I find anything more promising, is don't immediately allow the new phone (CAT S60) to get updates, get temporary root with dirtycow, then attempt to modify something that is both A) running in root context and B) the bootloader won't complain about. The problem is that I have no idea which things the bootloader is checking.
What I can't figure out is which files are actually "verified" by the bootloader on Android? Just the initramfs? The entire root partition (i.e. everything outside userspace) as well? Is it a short enough checksum that it could be defeated by padding the image until it reaches the same checksum?
Click to expand...
Click to collapse
I believe it checks the entire /system partition during boot just before/as the kernel loads it to verify whether /system has been modified.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

[UNLOCK] Bootloader Unlock Package

Introduction
This is the bootloader unlock from ZTE. It was provided to me in private email by a ZTE engineer.
Warning
This package is for the USA version of the Axon 7 Mini (tulip) running 7.1.1 b14 firmware. If you are running any other device or firmware version, it may not work.
Note
After some testing, it appears that the Axon 7 Mini is not locked in any way. In other words, apparently neither this package nor tuliptool's unlock are required to flash custom ROMs. The only apparent advantage to flashing this is to get access to fastboot, which provides a way to flash a custom boot and recovery (among other things).
Flashing Instructions
Place axon_mini_unlock.zip on the root of your sdcard.
Reboot into recovery.
Select "Apply update from SD card".
Select axon_mini_unlock.zip.
Usage Instructions
After the package is flashed, you may boot into the bootloader:
adb reboot bootloader
Once in the bootloader, you will see an on-screen menu. Additionally, you may access the typical fastboot commands:
fastboot oem device-info
fastboot oem unlock
fastboot flash ...
... etc ...
Download
axon_mini_unlock.zip
md5: ea8f1a21c8a46b3045d00f17a37fe359
So, after this is done, I can flash TWRP through fastboot and tuliptool is no longer necessary, correct?
Yes, that is correct.
JoeGatto said:
So, after this is done, I can flash TWRP through fastboot and tuliptool is no longer necessary, correct?
Click to expand...
Click to collapse
This package is for the USA version of the Axon 7 Mini (tulip) running 7.1.1 b14 firmware. If you are running any other device or firmware version, it may not work.
Click to expand...
Click to collapse
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
After some testing, it appears that the Axon 7 Mini is not locked in any way. In other words, apparently neither this package nor tuliptool are required to flash custom ROMs. The only apparent advantage to flashing this is to get access to fastboot.
Click to expand...
Click to collapse
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
trpn111 said:
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
Click to expand...
Click to collapse
Yeah...verdandi is stuck on Marshmellow. But since it has different hardware it could brick if this is tried.
The ZTE engineer is USA based, he is not on the China development team (read: probably a support engineer). He said: "I attached the unlock update zip package, please try it. It is based on B14 build."
Sorry, that's all I have to go by for "official" information.
I do not want to be responsible for anyone bricking their device, so I cannot claim that this bootloader will work with anything other than a tulip device running 7.1.1 b14.
If you want to try and report back, I'm sure others will appreciate it. But I can't be responsible for the results.
trpn111 said:
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
Click to expand...
Click to collapse
Oh, and here is some more information to help you decide...
The volume key combo to enter EDL is handled by aboot (bootloader, eg. the thing we are flashing). This means even if you aren't currently able to use the key combo, you should be able to use it with the new aboot here. And if you can get to EDL, you can never really brick the device.
The volume key combo is detected very early in the aboot code. Like, first thing after basic platform init. So even if this isn't compatible with your device, it's likely we could restore the old aboot (assuming you back it up first, of course).
I'm convinced that the tulip is not locked based on my investigation today. So I have no idea if this aboot is properly signed. If your device is locked and this aboot is not signed properly, the lower boot loader won't load it. I'm not quite sure if that kicks you into EDL or not.
Not sure if that makes the decision easier or harder...
How did you come to the conclusion that tulip is not locked to begin with? If we don't need tuliptool or this aboot, how can I check verdandi if the device is the same 'locked but not really locked' state?
I will have a read about backing up aboot and see what I come up with concerning getting into edl.
So here's the deal...
I initially assumed the bootloader was locked because... well... it's supposed to be. So I found the place in aboot code where it checks the lock flag in the devinfo partition. I used the firehose to write unlocked to that flag. Then I built TWRP, flashed it and it booted. So I assumed everything was working just as I expected.
Today, I flashed the aboot with fastboot support and ran "fastboot oem device-info". It said that my device was locked. So I went to look and, sure enough, my devinfo partition flag was still set. Hmm, that's odd.
So I wrote locked back to the flag. TWRP still booted. Now things are looking pretty suspicious.
But maybe the new aboot doesn't even support locking? So I flashed the original b14 version of aboot and TWRP still booted.
That's pretty hard evidence that aboot is ignoring the lock flag. I don't know what they did -- whether they just removed the code that reads the lock flag or introduced a bug or what.
This does not necessarily mean that the lower layers are unlocked. That is, the lower boot loader may still required a properly signed aboot. I don't know, and I'm not ready to brick my device trying to find out.
trpn111 said:
How did you come to the conclusion that tulip is not locked to begin with? If we don't need tuliptool or this aboot, how can I check verdandi if the device is the same 'locked but not really locked' state?
I will have a read about backing up aboot and see what I come up with concerning getting into edl.
Click to expand...
Click to collapse
Hmm... Looks like this package incompatible with ZTE/P852A11/tulip.
Got error while trying to flash it by stock recovery. Error message says that it is for A12 version of tulip.
Ah, yes, you have the euro model. See the "calling all mini owners" thread, posts #76 and #77.
maestromony said:
Hmm... Looks like this package incompatible with ZTE/P852A11/tulip.
Got error while trying to flash it by stock recovery. Error message says that it is for A12 version of tulip.
Click to expand...
Click to collapse
i get a message saying "cant update from sd card?"
yeshivabachur said:
i get a message saying "cant update from sd card?"
Click to expand...
Click to collapse
Make sure battery level is at least 30% before applying any update. It's a standard protection feature.
JoeGatto said:
Make sure battery level is at least 30% before applying any update. It's a standard protection feature.
Click to expand...
Click to collapse
My battery was 80%+ mine still said can't update from sdcard
Aries2010 said:
My battery was 80%+ mine still said can't update from sdcard
Click to expand...
Click to collapse
Try turning on the OEM unlock setting in developer settings.
JoeGatto said:
Try turning on the OEM unlock setting in developer settings.
Click to expand...
Click to collapse
Thank you so much that worked I appreciate the it . Now I have one more question I have been searching for a way to root stock rom but I can't find any instructions on it. Could you walk me through it or post a link for me if possible? I have the USA mini 7 with B14 firmware
Aries2010 said:
Thank you so much that worked I appreciate the it . Now I have one more question I have been searching for a way to root stock rom but I can't find any instructions on it. Could you walk me through it or post a link for me if possible? I have the USA mini 7 with B14 firmware
Click to expand...
Click to collapse
Rooting the stock ROM will require that you remove verity, so that the OS won't refuse to boot once you've made any changes to the system partition. You'll need to use tuliptool to flash a new boot image, which you can find in this section of the forum. Then, you could either install TWRP through fastboot or using tuliptool.
JoeGatto said:
Rooting the stock ROM will require that you remove verity, so that the OS won't refuse to boot once you've made any changes to the system partition. You'll need to use tuliptool to flash a new boot image, which you can find in this section of the forum. Then, you could either install TWRP through fastboot or using tuliptool.
Click to expand...
Click to collapse
Thank you sir I appreciate it I shall try it tomorrow.
here's a stupid question.... I have only dealt with Samsung devices so, I have trouble understanding any other kind of process that is not Samsung. If a new update comes out while my device is bootloader unlocked can i update it? or will it brick my device?
The "standard" (not Samsung) method of updating via OTA is to ship:
1. Full images of any firmware partitions (rpm, tz, aboot, etc.)
2. Full image of boot.
3. A delta (patch) to system.
Also note that custom recoveries generally do not work with vendor OTA's.
This means that if you wish to apply an OTA, you must first have stock recovery and a completely pristine, unmodified system partition. The rest doesn't matter.
yeshivabachur said:
here's a stupid question.... I have only dealt with Samsung devices so, I have trouble understanding any other kind of process that is not Samsung. If a new update comes out while my device is bootloader unlocked can i update it? or will it brick my device?
Click to expand...
Click to collapse

Categories

Resources