Hi all,
I'm planning to root my encrypted Nexus 5 with Lollipop by the latest CF Auto Root. Is it still the case that encrypted phones will be wiped by CF Auto Root? Chainfire said that would no longer be the case on 11 October 2014 (head to his Google+ page for the post). I'm wondering if the latest CF Auto Root for Nexus 5 Lollipop will wipe my encrypted storage.
It would be great if Chainfire could answer my question.
Thanks!
yes, it will no longer touch the data.
See his October 10, 2014 post.
CF-Auto-Root
There have been a few changes to the CF-Auto-Root installer as well. One noteworthy one is that in preparation for L having encryption enabled by default, it no longer touches /data. This is both good and bad.
The good is that it doesn't need to know your decryption key, the process remains automatic, and encrypted phones are no longer wiped on usage of CF-Auto-Root.
The bad is that this means some /data cleanup code is run on first boot after rooting, which may trigger a (one) reboot in the process. I do not expect bootloops because of this, it works fine on all the devices I have tested it on, but you never know.
Additionally, because CF-Auto-Root cannot distinguish between a garbage and an encrypted partition, it no longer fixes OEM unlock issues. On several fastboot based devices, the OEM unlock command, instead of formatting /data and /cache, wipes them. Android will not automatically re-format them anymore (used to in 2.x days), which means that your device will forever bootloop until you manually format /data and /cache (which CF-Auto-Root did for you automatically in the past).
Last but not least, some changes have been made to allow the progress to be visible on some new Qualcomm based devices. While I would normally not waste words on something as trivial as this, I would like to point out that these devices no longer support fbdev to put content on screen, but instead use something called Qualcomm overlay. Nothing basically wrong with that either, aside from the absolutely horrid fact that the interface to this changes between different kernels in a completely incompatible way, pretty much requiring a userspace program to use the exact right version of kernel headers to do something as basic as putting anything onscreen. Making a non-kernel specific binary that support a wide range of devices is thus now nigh impossible unless some very ugly code and errorprone methods are employed. As such, I expect that ultimately there will be no visual progress for CF-Auto-Root anymore on Qualcomm based devices, as I certainly can't be bothered keeping track of these shenanigans.
Click to expand...
Click to collapse
Thanks. This is the post that I was referring to.
Has anyone with encrypted Nexus 5 tried it out yet?
matthew01202 said:
Thanks. This is the post that I was referring to.
Has anyone with encrypted Nexus 5 tried it out yet?
Click to expand...
Click to collapse
Encrypted Nexus 6 works fine. Didn't wipe anything. I'm sure it's the same for the N5.
Hello.. I have the Galaxy S6, Android 6.0.1 and it has the auto update for it's software so it's the latest available online.. The device is encrypted, and i want to decrypt it, but i couldn't find the Encryption settings at all, besides under Screen Lock and security / Protect encrypted data, Which as you probably know is not the solution..
How is it possible to decrypt my device?..
Thanks ahead and have a nice day!
Really? nothing?..
Jeff1976A1 said:
Hello.. I have the Galaxy S6, Android 6.0.1 and it has the auto update for it's software so it's the latest available online.. The device is encrypted, and i want to decrypt it, but i couldn't find the Encryption settings at all, besides under Screen Lock and security / Protect encrypted data, Which as you probably know is not the solution..
How is it possible to decrypt my device?..
Thanks ahead and have a nice day!
Click to expand...
Click to collapse
Really? nothing?..
Hi, I am using samsung galaxy s7 delivered with an android version before version 7 nougat.
At first I updated OTA. But yesterday I flashed android 7 (last version) via Odin and repartition option. So it should be a clean installation.
As I understood there is file based encryption instead of full encryption now. Bringing an option called direct boot.
As I read the secure startup option should not be available in android 7 (if updated with full wipe). But I also read that it was added again in a newer version of android 7.
I tought if direct boot (without secure startup option) is enabled the device will boot untill lock screen and some option like calls, notifications.. are available. But for example if there is a call, only the number not the name will be displayed because contacts are still encrypted. But when I tested it, the name is displayed. So I think there is no direct boot encryption in my device? Otherwise when I enable secure boot option I have to type in my password before there are notifications and calls.. available...
I want this: After restarting the galaxy s7 it should boot to lock screen. Some notifications and so on should be available (what I think this is direct boot), but my private datas should still be encrypted in a very secure way. After typing in my password all the other apps should be available. After locking the screen encryption protection should be there..
So how can I check if my galaxy s7 is using file based enryption? and why is there still the option "secure boot"? does it bring any advantage in how secure the encryption is? and why?
I am very confused. I would be so glad if anyone can help me! Thank you so much!
Kind regards alex
(please excuese the bad english, I hope everything is understandable...)
I have had my u11 going on 4 + years, and some things about it I understand quite well and other things not so much ,,with that being said I have 2 part question, is it possible to decrypt pie with twrp and if so how do you know its decrypted? What action or actions can be performed with a decrypted stock pie rom? Thanks for any and all replys.
Um by decrypted meaning usually removing the pin or password or pattern or whatever form of lock screen you have.
Having an unencrypted data partition allows you to make modifications to twrp without any issues but allows intruders for the same.
I have a port of TWRP like orangefox or blackhawk which allows decryption of the data partitiln by entering the lock screen password in twrp itself.
I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.
opticyclic said:
I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.
Click to expand...
Click to collapse
hello, i cannot find any info on this device, is the processor mtk, qcom, or exynos
To root a phone's Android it's never needed to unlock phone's bootloader: this is a fairy tale which is told hundreds of times here and elsewhere.
opticyclic said:
I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.
Click to expand...
Click to collapse
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Hardware backed Keystore
SELinux
Trusty
Android Verified Boot
All of these work together.
When the bootloader is locked, the boot image is verified (using a cryptographic hash signed by the hardware keystore, which is itself verified) to determine its integrity. This prevents persistent rootkits.
During run time, SELinux enforces access control over all processes, even those with root privileges.
Trusty is a completely separate and isolated secure environment that runs alongside the Android kernel and is used as a "trusted verifier"
And this isn't even getting into the security features implemented in the update process.
For this attack vector you're describing to work, you would have to have the OEM's private and proprietary key used to sign everything in the update package, otherwise an unsigned or incorrectly signed package will be rejected. And even if you did manage to sign the update package, you'd have to essentially reprogram the hardware keys to match, because even if the update flashed to the device, all the images would fail verification because of the hardware keystore authentication.
xXx yYy said:
To root a phone's Android it's never needed to unlock phone's bootloader: this is a fairy tale which is told hundreds of times here and elsewhere.
Click to expand...
Click to collapse
Source?
How do you get elevated permissions in a protected environment without compromising the boot image, which would make the device fail to boot?
V0latyle said:
Source?
How do you get elevated permissions in a protected environment without compromising the boot image, which would make the device fail to boot?
Click to expand...
Click to collapse
You probably don't know how rooting Android is accomplished: no elevated permissions are needed to run SU binary.
xXx yYy said:
You probably don't know how rooting Android is accomplished: no elevated permissions are needed to run SU binary.
Click to expand...
Click to collapse
Explain?
$cronos_ said:
hello, i cannot find any info on this device, is the processor mtk, qcom, or exynos
Click to expand...
Click to collapse
Samsung Galaxy A53 5G - Full phone specifications
www.gsmarena.com
Although it says exynos on that page, I believe this is a Snapdragon as it has the W suffix on the model and as I am in Canada it looks to be the US version.
PSA: There is No OEM Unlock on US Galaxy A53's
Whether you get a carrier version or the factory unlocked U1 model, OEM unlock does not exist on this phone. So those in the US that were thinking of doing custom roms with this cheap new Android device, look elsewhere.
forum.xda-developers.com
V0latyle said:
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Hardware backed Keystore
SELinux
Trusty
Android Verified Boot
All of these work together.
When the bootloader is locked, the boot image is verified (using a cryptographic hash signed by the hardware keystore, which is itself verified) to determine its integrity. This prevents persistent rootkits.
During run time, SELinux enforces access control over all processes, even those with root privileges.
Trusty is a completely separate and isolated secure environment that runs alongside the Android kernel and is used as a "trusted verifier"
And this isn't even getting into the security features implemented in the update process.
For this attack vector you're describing to work, you would have to have the OEM's private and proprietary key used to sign everything in the update package, otherwise an unsigned or incorrectly signed package will be rejected. And even if you did manage to sign the update package, you'd have to essentially reprogram the hardware keys to match, because even if the update flashed to the device, all the images would fail verification because of the hardware keystore authentication.
Click to expand...
Click to collapse
Thanks for the info.
@pndwal since you're much more knowledgeable on this topic than I, care to jump in here?
V0latyle said:
@pndwal since you're much more knowledgeable on this topic than I, care to jump in here?
Click to expand...
Click to collapse
Topic of temp root etc using vulns / exploits?; All I know is from reading...
This 'Deployment' developer doc was removed in January but mentioned Magisk deployment via exploits:
https://github.com/topjohnwu/Magisk...62964e41201b9f157923b/docs/deploy.md#exploits
I believe this temp MagiskSU from such a root shell can then often be used to flash/obtain full-fleged Magisk root...
Exploit / vulnerability based root certainly has benefits, one of which is ease of properly (and fully) bypassing device integrity attestations since kernel can be modified while bootloader remains locked... John commented here (and on future potential):
www.twitter.com/topjohnwu/status/1299903496028790785
... Doubt he'll be elaborating on this any more somehow...
There may not be many useful exploits for root due to security research, pen testing, patching, anti rollback etc... Here's a recent one that can be leveraged for Pixel 6; POC here:
https://github.com/polygraphene/DirtyPipe-Android
... This is already patched from 2022-04-05...
Could be used for Realme GT2 Pro, some Galaxy S22 models, others(?)... The process notes may be enlightening: https://github.com/polygraphene/DirtyPipe-Android/blob/master/TECHNICAL-DETAILS.md#exploit-process
XDA article re. 'infamous "Dirty Pipe" vulnerability can be exploited on the Samsung Galaxy S22 and the Google Pixel 6 Pro to gain root shell access':
https://www.xda-developers.com/tag/root-exploit/
This vuln caused a minor furore over Google anti-rollback w/ A13 update etc... Ex XDA editor Mishael commented:
www.twitter.com/MishaalRahman/status/1511036735433715719
Johns here:
www.twitter.com/topjohnwu/status/1511107456566390785
... I want "MagiPipe" One-Click Root app w/ the rainbow Magikarp icon!
Further:
www.twitter.com/topjohnwu/status/1559786740050644992
And Shawn Willden on patching, anti-rollback counters etc here:
www.twitter.com/shawnwillden/status/1559893884120928256
Older 'Linux Kernel bug dubbed 'Dirty Cow' can Root every version of Android' article by Mishael:
https://www.xda-developers.com/9-ye...-dirty-cow-can-root-every-version-of-android/
PW
V0latyle said:
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Click to expand...
Click to collapse
...
Please can you explain what you mean here?... I understood '(AOSP) is the bedrock of modern Android skins like One UI and MIUI'...
https://www.androidauthority.com/aosp-explained-1093505/
Is this wrong?...
Can't see how even heavy OEM Android OS skins would make a difference to OEM unlock (or even using a root kit hypothetically)... Aren't unlock options etc determined by OEMs and re-sellers?...
And user does have Samsung device anyway... PW
pndwal said:
...
Please can you explain what you mean here?... I understood '(AOSP) is the bedrock of modern Android skins like One UI and MIUI'...
https://www.androidauthority.com/aosp-explained-1093505/
Is this wrong?...
Can't see how even heavy OEM Android OS skins would make a difference to OEM unlock (or even using a root kit hypothetically)... Aren't unlock options etc determined by OEMs and re-sellers?...
And user does have Samsung device anyway... PW
Click to expand...
Click to collapse
What I mean is whether Samsung follows the same Android security model, with verified boot, dm-verity, and so on. They do have security features implemented to prevent unsigned binaries (even if the bootloader is unlocked) but they also add a lot of their own stuff like Knox and Vaultkeeper. Either way, it would be difficult for a rootkit to persist after reboot because of these security features.
My understanding of OneUI is that it's not just a reskin/overlay but it also changes a lot of the core components as well. I could be wrong.
V0latyle said:
What I mean is whether Samsung follows the same Android security model, with verified boot, dm-verity, and so on.
Click to expand...
Click to collapse
Of course they do... AVB (ie Verified Boot 2.0) is mandated for any Android 8+ certified implementation...
An AOSP-compatible device must conform to the list of requirements in the Compatibility Definition Document (CDD). An Android-compatible device must conform to the list of requirements in the CDD and Vendor Software Requirements (VSR) and tests such as those in the Vendor Test Suite (VTS) and Compatability Test Suite (CTS).
Click to expand...
Click to collapse
https://source.android.com/docs/core/architecture#hidl
Eg. CCD:
https://source.android.com/docs/compatibility/cdd
see 9.9.2. File Based Encryption:
[C-1-4] MUST support Verified Boot and ensure that DE keys are cryptographically bound to the device's hardware root of trust. etc...
https://source.android.com/docs/compatibility/8.0/android-8.0-cdd
device-mapper-verity (dm-verity) is simply a kernel feature used since A 4.4 to implement Verified Boot...
V0latyle said:
They do have security features implemented to prevent unsigned binaries (even if the bootloader is unlocked) but they also add a lot of their own stuff like Knox and Vaultkeeper.
Click to expand...
Click to collapse
Sure; and MIUI adds Xiaomi Security Centre...
OEMs can add what they like as long as they comply with the CDD and VSR incl VTS and CTS...
V0latyle said:
Either way, it would be difficult for a rootkit to persist after reboot because of these security features.
Click to expand...
Click to collapse
Well maybe...
I'm unaware of any special safeguards against root whether userspace based or exploit based personally...
V0latyle said:
My understanding of OneUI is that it's not just a reskin/overlay but it also changes a lot of the core components as well. I could be wrong.
Click to expand...
Click to collapse
Well Android skins are necessarily software tweaks that live on top of stock Android; "They often look very different and offer features that other skins don't. In other words, underneath all the additional design and functionality tweaks, the core version of Android is on all Android devices." More on this here:
https://www.androidauthority.com/android-skins-945375/
Also these can't change security requirements for API/SDK level compliance... There is lattitude for OEMs to use their own components, but this is of course costly; Eg OEMs are free to implement their own TEE OS instead of Google's Trusty TEE, but most use Trusty as it's free and works fine!... PW
All very interesting. Thanks.
I remember using Dirty Cow to root a previous device.
My first phone was the Samsung Galaxy Nexus and after that I used several Chinese brands and got root on everything.
Because of the popularity of Samsung I assumed that root would be available.