Related
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
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
What does the manufacturer do to the phone to make it un-rootable?
This quote: "Strictly speaking, when we talk about a platform as open as the Android OS, it is almost impossible for a manufacturer to make an ‘un-rootable’ device."
would suggest that most likely the manufacturer is not making the phone un-rootable. So then that would leave the OS, but my 4.2.2 KitKat has and is rooted on other devices.
So who and what is at fault here? Seems to me that if it was software, that would be easy. Find an exploit and root. But if it was that easy then all phones/devices would be rootable.
That brings us back to hardware and the manufacturer.
RealRobD said:
What does the manufacturer do to the phone to make it un-rootable?
This quote: "Strictly speaking, when we talk about a platform as open as the Android OS, it is almost impossible for a manufacturer to make an ‘un-rootable’ device."
would suggest that most likely the manufacturer is not making the phone un-rootable. So then that would leave the OS, but my 4.2.2 KitKat has and is rooted on other devices.
So who and what is at fault here? Seems to me that if it was software, that would be easy. Find an exploit and root. But if it was that easy then all phones/devices would be rootable.
That brings us back to hardware and the manufacturer.
Click to expand...
Click to collapse
It is more a matter of the carriers trying their hardest to prevent us from being able to unlock/root the devices they offer and less a matter of the manufacturer trying to prevent it.. They do this for several reasons. But the main reasons are to prevent security breaches, to protect the information on their customer's devices, to prevent having to repair/replace devices that have been broken due to failed rooting/flashing/modifying attempts and to prevent us from using their devices on another carrier's network.
It is considered to be impossible to make devices that absolutely can't be rooted. They are all vulnerable in some manner, these vulnerabilities are called exploits, it's just a matter of finding the right exploit. When exploits are found, the manufacturer or carrier will patch the exploit and release an update for their devices to apply the patch.
The main thing they do to make devices unrootable is to use a locked bootloader, some even use specific hardware components to prevent unapproved software from booting.
It's a combination of things really, there is not necessarily one certain thing they do to keep us from rooting, because there are many different ways to unlock/root devices, they try their best to account for them all.
Sent from my SM-S767VL using Tapatalk
It is considered to be impossible to make devices that absolutely can't be rooted. They are all vulnerable in some manner, these vulnerabilities are called exploits, it's just a matter of finding the right exploit.
Click to expand...
Click to collapse
Can you direct me to the recommended newbie reading to get my learn on?
My Alcatel onetouch has stumped current one click methods, so it's time to learn and crack this puppy on my own.
RealRobD said:
Can you direct me to the recommended newbie reading to get my learn on?
My Alcatel onetouch has stumped current one click methods, so it's time to learn and crack this puppy on my own.
Click to expand...
Click to collapse
If all one click methods have failed, the only option left is to flash some kind of customized software or methods to modify parts of your boot and/or system partitions. Flashing custom software and modifying boot or system requires the device to have an unlocked bootloader.
This means that your first step is to determine whether or not your device has an unlocked bootloader. If it is unlocked, you can flash/modify the device, if it is locked, you can't flash/modify unless you find a method to unlock the bootloader, then you can flash/modify. Do some searches for methods to check your bootloader status.
If you find that the bootloader is unlocked, then you have a few choices:
1) if you can obtain a copy of your stock firmware then you can use the Magisk rooting method to modify the boot.img from your firmware to create a patched boot.img then flash that boot.img using the appropriate flash tool for your device brand.
2) if you can find a copy of TWRP custom recovery for your specific device model number you can flash the TWRP file using the appropriate flash tool for your device brand.
3) if there is no TWRP for your specific model number, you can build your own version of TWRP if the necessary resources are available for your specific model number.
4) if the necessary resources to build TWRP for your specific model number are not available, you can try finding a TWRP for a similar device with the same exact CPU that your device has and port that TWRP to be compatible with your own device.
Do your own searching and researching about each of these options, the more you read about them, the more you will understand.
Sent from my SM-S767VL using Tapatalk
Droidriven said:
If all one click methods have failed, the only option left is to flash some kind of customized software or methods to modify parts of your boot and/or system partitions. Flashing custom software and modifying boot or system requires the device to have an unlocked bootloader.
This means that your first step is to determine whether or not your device has an unlocked bootloader. If it is unlocked, you can flash/modify the device, if it is locked, you can't flash/modify unless you find a method to unlock the bootloader, then you can flash/modify. Do some searches for methods to check your bootloader status.
If you find that the bootloader is unlocked, then you have a few choices:
1) if you can obtain a copy of your stock firmware then you can use the Magisk rooting method to modify the boot.img from your firmware to create a patched boot.img then flash that boot.img using the appropriate flash tool for your device brand.
2) if you can find a copy of TWRP custom recovery for your specific device model number you can flash the TWRP file using the appropriate flash tool for your device brand.
3) if there is no TWRP for your specific model number, you can build your own version of TWRP if the necessary resources are available for your specific model number.
4) if the necessary resources to build TWRP for your specific model number are not available, you can try finding a TWRP for a similar device with the same exact CPU that your device has and port that TWRP to be compatible with your own device.
Do your own searching and researching about each of these options, the more you read about them, the more you will understand.
Sent from my SM-S767VL using Tapatalk
Click to expand...
Click to collapse
Can't get past "Waiting on devices" when using
Code:
fastboot oem device-info
.
Device manager shows the phone is connected just fine.
The phone has no manual way to set fast boot, whether it be the buttons or entering numbers on the keypad.
Device recognized.
Code:
fastboot devices
returns nothing. I guess that means it's not in fast boot mode.
Code:
adb reboot bootloader
and
Code:
adb reboot fastboot
only reboots the phone.
On the other hand,
Code:
adb reboot recovery
does work.
RealRobD said:
Can't get past "Waiting on devices" when using
Code:
fastboot oem device-info
.
Device manager shows the phone is connected just fine.
The phone has no manual way to set fast boot, whether it be the buttons or entering numbers on the keypad.
Device recognized.
Code:
fastboot devices
returns nothing. I guess that means it's not in fast boot mode.
Code:
adb reboot bootloader
and
Code:
adb reboot fastboot
only reboots the phone.
On the other hand,
Code:
adb reboot recovery
does work.
Click to expand...
Click to collapse
Your device probably doesn't even have fastboot mode, some carriers remove fastboot from their devices, especially MVNO(subcontracted) networks.
Sent from my SM-S767VL using Tapatalk
Yep, looks like no Fastboot onboard...
galaxys said:
Yep, looks like no Fastboot onboard...
Click to expand...
Click to collapse
If it's just software, why can't it be bypassed, cracked, hacked, blown up etc?
RealRobD said:
If it's just software, why can't it be bypassed, cracked, hacked, blown up etc?
Click to expand...
Click to collapse
If you're asking about what was said about not having fastboot, it is a lack of software, as in, the software is not even there.
If you're asking if the software can be bypassed, it can, the trick is to find the right exploit. That is the problem, a working exploit has not been discovered for this device.
Without fastboot, there is no way to flash custom files such as TWRP or patched boot.img. This means, the only chance of rooting the device is if one of the one-click universal rooting apps or universal PC rooting programs has an exploit that just happens to network on this device.
Sent from my SM-S767VL using Tapatalk
Droidriven said:
If you're asking about what was said about not having fastboot, it is a lack of software, as in, the software is not even there.
If you're asking if the software can be bypassed, it can, the trick is to find the right exploit. That is the problem, a working exploit has not been discovered for this device.
Without fastboot, there is no way to flash custom files such as TWRP or patched boot.img. This means, the only chance of rooting the device is if one of the one-click universal rooting apps or universal PC rooting programs has an exploit that just happens to network on this device.
Sent from my SM-S767VL using Tapatalk
Click to expand...
Click to collapse
Have any fastboot-less phones in the past been rooted?
If so, do you have any recommended reading as far as exploit hunting is concerned?
Hi everyone.
I'm thinking in buying a phone from CAT (CAT S42) and I'm not sure if I can unlock its bootloader. But I've seen on another forum that the CAT S31 has root available for it through Magisk, and I didn't see anyone mentioning having unlocked the bootloader. S42 has a MediaTek chipset and S31 has a Qualcomm chipset, if that helps.
So my question is: is unlocking bootloader MANDATORY to root a device? Can I just run a custom recovery, root the phone with that, and then the recovery gets overwritten on system boot? Or can I root through USB debugging without even needing custom recovery?
The CAT S31 I mentioned was rooted with Magisk, and as I said, I didn't see anyone talking about unlocked bootloader. But I also read Magisk changes the boot partition and the bootloader checks if it was modified. So I'm a bit confused with this too. It's also written that MiracleBox was used and I'm not sure that's the reason that I'm getting confused or not (I had never heard of this tool until now).
A set of software for obtaining ROOT privileges.
Driver_Qualcom_m.7z (9.27 MB) [link]
Enter HS QDSLoad 9008 mode from Vol + and Vol- off state and connect without releasing to USB
MiracleBox [link]
The Boot image is processed on the phone by the Magisk manager, then uploaded to the phone using Miracle again from the computer.
MagiskManager-v7.3.2.apk (2.71 MB) [link]
Just in case,
Backup firmware without / Data partition
Attached files
XposedInstaller_3.1.5-Magisk.apk (2.96 MB) [link]
Click to expand...
Click to collapse
How may they have done that?
I'm sorry, I don't understand a lot of the root requirements part, since I was lucky and my 1st phone had the bootloader unlocked alreaedy for some reason and the second was as easy as writting a single command. But about this phone there's almost nothing and I'd like to know the general about this. If it's really necessary to have the bootloader unlocked, for example. And if it's not, then what methods can I use with it still locked?
Thanks in advance for any help!
Hello DADi590,
Unfortunately I can't answer all of your questions about S42. I have one of them and I am also looking for and confused with root procedures. But I can tell you that unlock boot loader was just a matter of get developer options on (tapping version # 10 times), and inside you can toogle lock/unlock bootloader...
How to root it safely is what I do not know yet.
good luck!
@DADi590
Rooting the Android OS of a device in practice is nothing more than adding the su cmdlet known from Linux OS to the Android OS. To root Android OS in no case requires device's bootloader must get unlocked to do so.
FYI: The bootloader of an Android device is comparable to the BIOS of a Windows computer.
Actually, after some time I decided to leave CAT alone and buy a Blackview one. If I'd break the phone, at least it wouldn't be as expensive as the CAT S42 (I bought a BV9500 - not Pro or Plus, the normal one).
Since then (with help of adventures with a tablet of mine) I've learned some more things. One of them I was suspecting and was now confirmed (thank you @jwoegerbauer) which is to root the device, just a binary file is needed to be on the correct place: su. I didn't know it was on other Linux OSes though. Interesting!
So the idea is that just a recovery must be installed to root a device. That's it and nothing else, I believe. To install the recovery is the part where one might need to unlock the bootloader - or not, if the chipset manufacturer left a tool to write partitions directly, like MediaTek or Rockchip. On these 2 it's possible to write partitions directly with a locked bootloader (this means the bootloader on my 1st phone was and still is probably locked - like my BV9500 one is, and I flashed various partitions on it already, one of them, a TWRP recovery).
This explanation is for anyone else like me who would have this question. Bootloader is just to flash partitions and I think run modified ROMs too, but not too sure about that (I never use custom ROMs). [Btw, if I said something wrong, I'm happy to be corrected!]
armandrix said:
Hello DADi590,
Unfortunately I can't answer all of your questions about S42. I have one of them and I am also looking for and confused with root procedures. But I can tell you that unlock boot loader was just a matter of get developer options on (tapping version # 10 times), and inside you can toogle lock/unlock bootloader...
How to root it safely is what I do not know yet.
good luck!
Click to expand...
Click to collapse
I believe I asked this because I prefer that it's not required to unlock a bootloader to do stuff. If you screw the phone somehow with the bootloader locked and there's no tool to flash partitions on it and you must be on fastboot with an unlocked bootloader or whatever, you just bricked the phone. And I'd prefer that not to happen. That's why I chose to buy phones that don't need me to unlock the bootloader to do anything on them. That might mean I can't ever brick them (at least I never bricked my 1st phone with the various things I did on it which I later found out not being recommended at all XD).
I've unlocked the bootloader on my Cat S42. Can be done.
Hello guys, This is my first thread on XDA forum.
I just bought Xiaomi device (Poco X3 Pro Global) a few days ago.
So this is my first time to try custom rom, I searched what I'm trying to do, I'd like to make sure whether what I understand is correct or not since I'm totally new on custom rom.
the sources I mainly referred to:
source1
source2
Basic assumption:
1. Only flash custom rom without rooting
2. All unlocking bootloader and flashing custom rom process done perfectly, and all resouces (recovery, rom, ADB tool etc...) used during process are 100% clean and genuine.
3. No cold boot attack (source2) happens on me.
Q1. source1 is really helpful, but it's from 2012, is this still valid today?
Q2. source1 is posted on Galaxy Nexus forum, but is this applied to all android based devices, right?
Q3. This threat model assumes attacker has physical access to device, then I guess unlocking bootloader itself is 100% totally irrelevant to software level security risks like malware or OS vulnerability, is this right? (assuming no rooting and 100% genuine rom and resources)
Q4. From source1 you can choose between [device encryption] and [relocking bootloader] to protect security, which methods do you recommend using?
I feel I'm much more inclined to try device encryption method since I don't know if it's possible to relock bootloader safely after migrating from Global stock rom to xiaomi.eu rom. (Can anyone confirm this?) I fear it become bricked during relocking process.
Q5. So if I set device encryption with strong password and turn off USB debugging mode, I need not too worrysome?
Are there any other points in terms of security to bear in mind if you use device with unlocked bootloader?
Thank you for reading my thread
[INFO] Understanding the risks of having an unlocked bootloader
While unlocking the bootloader on a Galaxy Nexus unleashes the full potential of the bootloader, it also poses a security risk. Even with your lockscreen protected with a pattern/PIN/password, not having flashed a custom recovery, having an...
forum.xda-developers.com
jwoegerbauer said:
[INFO] Understanding the risks of having an unlocked bootloader
While unlocking the bootloader on a Galaxy Nexus unleashes the full potential of the bootloader, it also poses a security risk. Even with your lockscreen protected with a pattern/PIN/password, not having flashed a custom recovery, having an...
forum.xda-developers.com
Click to expand...
Click to collapse
that's what I linked in thread (source1)
Only a side-remark:
An Android Smartphone bootloader is processor-specific and every OEM has its own version of bootloader specific for the hardware present in its environment.
It's the primary task of every bootloader to verify the Android OS to be loaded is genuine means signed by OEM to ensure the Android OS ( it's by nature a Custom ROM ) works flawlessly as it can be expected by user. People who use a phone as a tool and not as a toy probably never come up with the idea to unlock the bootloader because they know about the strengths and weaknesses of the phone when they bought it, they can expect that OEM did their best with regards to a phone's performance - OEMs are certainly not dumber than generally claimed by the modder / hacker scene.
My POV: Unlocking a phone's bootloader is an unnecessary action at all. If people do so they indirectly admit that they have purchased a phone that does not meet their expectations - they have made a wrong purchase.
Thanks for comment.
I understand your POV.
I realized later Global rom can't do call recording, that's the main reason why I try to flash xiaomi.eu rom and other optimazations are second reason.
And this phone will be my main phone so I wanted to make sure about security risk before I will change rom.
cromcromc said:
Thanks for comment.
I understand your POV.
I realized later Global rom can't do call recording, that's the main reason why I try to flash xiaomi.eu rom and other optimazations are second reason.
And this phone will be my main phone so I wanted to make sure about security risk before I will change rom.
Click to expand...
Click to collapse
Having an unlocked bootloader doesn't need to be a risk whatsover as long as you're not flashing untrusted ROMS and other components to the device and critically control anything being flashed to the device. If you're flashing a signed ROM from the manufacturer as it sounds like is your plan, there is nothing to worry about. You can even lock the BL again after flashing & optimizing if you absolutely wish to although usually not recommended.