I'm working on modifying the source code for qu1ckr00t, a PoC from a few years ago in which magisk was installed without a patched boot image. It relied, in part, on an exploit from cve-2019-2215.
I've been able to achieve most of the same preconditions as provided by the exploit from that time, disabling SELinux and bypassing DAC and CAP. Now, the system images (but no boot images) can be modified without issue.
But getting a core-mode installation of magisk up and running through init (on the back side of the boot process, without any boot image patch) has proved to be much more challenging.
Searching this issue has proved difficult because any search turns up so many generic installation hits.
Has there been any prior project on this forum that utilized a method of installing magisk without any patch to any bootable partitions (boot/recovery)?
Search for bootless Magisk. This is basically going to be the case for any root relying on a kernel exploit since dm-verity is still active. There is a MediaTek kernel exploit from a couple years ago that was able to get Magisk working without modifying the boot/recovery images, running off the data partition instead. This method of SU/Magisk will work for managing root access to apps, but most magisk modules will fail.
Amazing Temp Root for MediaTek ARMv8 [2020-08-24]
Software root method for MediaTek MT67xx, MT816x, and MT817x! So it's no big secret that not too long ago, I found a way to achieve temporary root on MediaTek chipsets. No preinstalled root solution or device unlock was needed. The tool I...
forum.xda-developers.com
I'm surprised there are still devices out there that haven't patched cve-2019-2215.
Finnzz said:
Search for bootless Magisk. This is basically going to be the case for any root relying on a kernel exploit since dm-verity is still active. There is a MediaTek kernel exploit from a couple years ago that was able to get Magisk working without modifying the boot/recovery images, running off the data partition instead. This method of SU/Magisk will work for managing root access to apps, but most magisk modules will fail.
Amazing Temp Root for MediaTek ARMv8 [2020-08-24]
Software root method for MediaTek MT67xx, MT816x, and MT817x! So it's no big secret that not too long ago, I found a way to achieve temporary root on MediaTek chipsets. No preinstalled root solution or device unlock was needed. The tool I...
forum.xda-developers.com
I'm surprised there are still devices out there that haven't patched cve-2019-2215.
Click to expand...
Click to collapse
please port it to kernel 4.4.147+
i'll leave kernel sources:https://www.mediafire.com/file/bhzm...e_A5_2019_Pie_kernel%284.4.147%29.tar.gz/file
phone is ZTE Blade A5 2019 on Android 9, bootloader not unlockable without the code that unisoc since don't answer won't provide, zte don't care and ban mails instead but calls me valued costumer, lol
Skorpion96 said:
please port it to kernel 4.4.147+
i'll leave kernel sources:https://www.mediafire.com/file/bhzm...e_A5_2019_Pie_kernel%284.4.147%29.tar.gz/file
phone is ZTE Blade A5 2019 on Android 9, bootloader not unlockable without the code that unisoc since don't answer won't provide, zte don't care and ban mails instead but calls me valued costumer, lol
Click to expand...
Click to collapse
That was just an example of Magisk being used without modifying the boot/recovery image.
That root method requires a MediaTek processor. You can't port a code dependant vulnerability if the code it exploits is completely unrelated, like that used by a different processor.
Finnzz said:
That was just an example of Magisk being used without modifying the boot/recovery image.
That root method requires a MediaTek processor. You can't port a code dependant vulnerability if the code it exploits is completely unrelated, like that used by a different processor.
Click to expand...
Click to collapse
ah, well, yes, i'm going crazy to root this phone, ofc i know that mtksu is an exploit for mtk. unfortunately i can't root this phone , now is a year and 1 month i'm trying
I extracted kallsyms from my kernel:https://www.mediafire.com/file/pbm0nvptr3w8eab/kallsyms-4.4.147%2B_%28armv7l%29.txt/file
Now what needs to be done is to port the 32 bit version of quickroot to this kernel:https://forum.xda-developers.com/t/root-with-cve-2019-2215.3979341/post-80830899
Related
Does anyone have a step by step guide as to how to root my Xperia ZR on a 4.4.2 firmware without custom recovery, full stock? I need root access for so many reasons but mainly because of the memory limitation..
Thank you!
Well, if there's a simple answer to your question: Nobody has found it yet! If you're talking about custom recovery with locked bootloader (where you can't flash custom kernel, meaning prerooted). SuperSU won't work either. If you unlock bootloader, then proceed to flashing prerooted ftfs. But that's more closely like flashing custom ROM than rooting the stock one.
Less simple answer would start with a story about SELinux:
SELinux - introduced in Android 4.2 - is essentially a set of kernel add-ons and tools that restricts pieces of software to run with only the bare minimum privilege set they require to function properly, and minimizes the damage a malicious program can do by tightly controlling security policy. Previously, SELinux operated in "permissive" mode in Android, but in 4.4 it has been switched to "enforcing" mode, meaning essentially that even if a piece of malware successfully intrudes, it won't be able to disable SELinux and do whatever it wants, even - theoretically - if it has administrative access.
With Google SELinux enforcing means that there is a "context" for every file (which is pretty much everything in Linux) similar to file permissions, but determines when, where and by whom data can be run and accessed. It's used to make Linux hyper-secure and makes it incredibly difficult to root a phone without having access to the bootloader to flash a su.apk. Even if they find a compromise in a "system" package, it won't give them the access to write to the root filesystem. Incredibly smart people will find some ways around it but it will get rid of most of the non-bootloader based roots on 4.4+. Basically it's a good thing for security and bad thing if you want to have admin privileges over your piece of android running hardware.
Hoping that wizards of reverse coding like @
DooMLoRD said:
http://dance.csc.ncsu.edu/papers/codespy14.pdf might find some related clues in in-depth analysis of PREC project, the malware detection and avoidance tool based on root exploit supported by high-level funding partners like IBM, Google, the U.S. Army, and the U.S. National Science Foundation.
Click to expand...
Click to collapse
Hope it helps.
EnzoDC said:
Does anyone have a step by step guide as to how to root my Xperia ZR on a 4.4.2 firmware without custom recovery, full stock? I need root access for so many reasons but mainly because of the memory limitation..
Thank you!
Click to expand...
Click to collapse
Yes, there is such a way
In short:
Backup TA
Unlock
Flash Cyanogen kernel
From recovery install SuperSu
Flash original kernel back
Restore TA (relock)
Result: full rooted locked stock
I've never owned a Nexus/Google phone, how long would you all guess it's going to take to root the Nexus 6?
Thanks! :fingers-crossed:
Kidding I hope
Pyros2008 said:
I've never owned a Nexus/Google phone, how long would you all guess it's going to take to root the Nexus 6?
Thanks! :fingers-crossed:
Click to expand...
Click to collapse
Before you even get it
Sent from my A0001 using XDA Free mobile app
Nope, the first time I rooted was a month ago, my Note 3. I take it the device can be rooted off the bat.. or there something else I am missing?
Give Chainfire a couple hours with the phone
Pretty sure the process will be similar to other Nexus devices... Fastboot oem unlock, etc, etc.
http://phandroid.com/2014/11/17/nexus-6-lollipop-root/
all hail king chainfire?
kgeissler said:
http://phandroid.com/2014/11/17/nexus-6-lollipop-root/
Click to expand...
Click to collapse
That has 6 nexus devices with root. Bit not the nexus 6.
I would make sure to wait until Google releases the factory image before rooting just in case something goes wrong
I'm pretty sure that the factory images have to be out as he has to create a modified kernel for the N6 for superuser to work on 5.0.
lordgodgeneral said:
I'm pretty sure that the factory images have to be out as he has to create a modified kernel for the N6 for superuser to work on 5.0.
Click to expand...
Click to collapse
I think he just patches the existing kernel so don't think he would need images. Think being the key word there as I don't know for sure how it works exactly.
You don't need a developer to root a nexus. Boot into the bootloader, connect to your computer, run: fastboot oem unlock, then install the recovery of your choice via fastboot (fastboot flash recovery blahxxx.img), then just flash whatever superuser you want (e.g. SuperSU)
Sent from my XT1053 using Tapatalk
bongostl said:
You don't need a developer to root a nexus. Boot into the bootloader, connect to your computer, run: fastboot oem unlock, then install the recovery of your choice via fastboot (fastboot flash recovery blahxxx.img), then just flash whatever superuser you want (e.g. SuperSU)
Sent from my XT1053 using Tapatalk
Click to expand...
Click to collapse
Sorry but this is no longer accurate. First off, there are no custom recoveries yet. Second, lollipop requires additional work arounds for root other than just flashing superuser.
akellar said:
Sorry but this is no longer accurate. First off, there are no custom recoveries yet. Second, lollipop requires additional work arounds for root other than just flashing superuser.
Click to expand...
Click to collapse
Hm? I'm running oneplus one with root on lollipop. All I had to do was just flash supersu in recovery.
Hopefully we can see a twrp on nexus 6 soon.
Sent from my A0001 using Tapatalk
zephiK said:
Hm? I'm running oneplus one with root on lollipop. All I had to do was just flash supersu in recovery.
Hopefully we can see a twrp on nexus 6 soon.
Sent from my A0001 using Tapatalk
Click to expand...
Click to collapse
It's likely not a complete build with the SELinux improvements that google made to the kernel. You need to modify the kernel on lollipop to have root so your one plus probably just has a ROM not a full image of the lollipop on it. Also as stated earlier you can't root anything without the factory image posted by google for the nexus. Then the developers can have at it. Until your happens we are just left waiting.
Pilz said:
It's likely not a complete build with the SELinux improvements that google made to the kernel. You need to modify the kernel on lollipop to have root so your one plus probably just has a ROM not a full image of the lollipop on it. Also as stated earlier you can't root anything without the factory image posted by google for the nexus. Then the developers can have at it. Until your happens we are just left waiting.
Click to expand...
Click to collapse
SELinux is currently permissive and yep its built off CM12 sources. But to answer OP's question, probably won't take too long but no ETAs.
zephiK said:
SELinux is currently permissive and yep its built off CM12 sources. But to answer OP's question, probably won't take too long but no ETAs.
Click to expand...
Click to collapse
Then that's why you can flash it in recovery. Normally you wouldn't be able to if it wasn't changed.
Chainfire said:
On LPX13D, SELinux, and root
As promised, here are some more details about the current situation.
Why it breaks
Google has really put some effort into better securing Android, and we've seen a lot of SELinux related commits to the AOSP tree over the past months. There is some disconnect between the AOSP tree and actual L preview builds, some things from AOSP are not in the L preview build, and vice versa. Ultimately, it's a pretty good bet these things will mostly align, though.
On most devices and firmwares, SuperSU's daemon is started by the install-recovery.sh service script that runs at system boot time, as user root with the init context. This is what the daemon needs to function.
Recently, they've started requiring all started services to run in their own SELinux context, instead of init. Developers and security guys following AOSP have known this was coming; AOSP builds have been logging complaints about this specific service not having its own context for a while now.
Now this script runs as root, but as the install_recovery context, which breaks SuperSU's operation, as it is a very restrictive context.
In the last AOSP build I have tried (a few weeks old), there were a fair number of other holes that we could use to launch the daemon. At first glance(!), it seems those have all been closed. An impressive feat by the guys working on this, if it proves true.
How to fix it
To fix root, all that really had to be done was ensure the daemon's startup script is run at boot as the root user with the init context.
There are multiple ways to do this, but unfortunately for now it seems that it does require a modified kernel package (changing the ramdisk).
In the modified kernel packages I've posted for the Nexus 5 and Nexus 7, the daemon's startup is fixed by commenting out the line in init.rc that forces the install-recovery.sh script to run as the install_recovery context, so now it runs as init again, and all is well.
Repercussions
As stated above, it seems for now that modifications to the kernel package are required to have root, we cannot attain it with only modifications to the system partition.
Combine that with a locked bootloader (and optionally dm-verity) and a device becomes nigh unrootable - exactly as intended by the security guys.
Exploit-based roots are already harder to do thanks to SELinux, and now because of the kernel requirements for persistent root, these exploits will need to be run at every boot. Exploits that make the system unstable (as many do) are thus out as well.
Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on. It is now thus more important than ever to buy unlocked devices if you want root.
It might also mean that every firmware update will require re-rooting, and OTA survival mode will be broken. For many (but far from all) devices we can probably automate patching the kernel package right in the SuperSU installer ZIP. We can try to keep it relatively easy, but updating stock firmwares while maintaining root is probably not going to work as easy and fast as it did until now.
Apps need updates
Unsurprisingly, with a new major Android release, apps will need updates. None more so than apps that go beyond the Android API, as root apps do, but even some non-root apps will be affected by the security changes.
As one example, someone posted in the SuperSU thread of a kernel flashing app that didn't work. From the logcat you could see that it was looking for partitions in /dev/block from its normal non-root user and non-init context. That used to be possible, but now it is restricted: normal apps no longer have read access there.
The solution for that app is actually quite simple: list the /dev/block contents using root instead. But simple solution or not, the app will still need to be updated.
By far most root apps should be updateable for L without too much issue. There are indeed exceptions that will need some special care, but those are rare.
Permissive vs enforcing
The kernel packages I posted for the Nexus 5 and 7 LPX13D firmware keep SELinux mostly set to enforcing. I say mostly, because SuperSU actually switches a small part of the system to permissive, so apps calling su can do most things without much interference. The details on this are lengthy (yes, your apps will be able to modify policies as well if needed, which should be rare), and I will document these for other developers after L retail release, assuming it will all still work at that time.
Alternatively, you can set the whole system to permissive or otherwise disable SELinux. There are other kernel packages released that indeed do this. The advantage here is that it instantly fixes some apps' issues, as the SELinux based restrictions have all gone the way of the dodo. The disadvantage here is that you've just shut down a major part of the security system of the device.
Some would argue that a device with an unlocked bootloader, root, encrypted modem firmwares of which nobody really knows what they're doing, etc, is inherently insecure, and thus disabling SELinux doesn't make much difference.
I personally disagree with this. While I do agree that these things weaken security down from the ideal level, I would still not disable more security features than I absolutely need to. Just because you cannot eliminate all attack vectors, is no reason to just completely give up on defending against them.
It is of course your own choice if you want to run a permissive system or not. I will strive to keep everything working in enforcing mode though, and I hope other root app developers will do the same - as stated earlier in the post, I believe this is still possible.
(everything in this post is subject to change for retail L release, obviously)
Click to expand...
Click to collapse
https://plus.google.com/+Chainfire/posts/VxjfYJnZAXP
http://www.xda-developers.com/android/supersu-beta-2-23-lollipop/
Pilz said:
Then that's why you can flash it in recovery. Normally you wouldn't be able to if it wasn't changed.
Click to expand...
Click to collapse
Good news everyone, starting one of the upcoming SuperSU updates, modified kernels will no longer be needed for root on Android 5.0 ... !
Click to expand...
Click to collapse
https://twitter.com/ChainfireXDA/status/535253476021116928
I know that we have root through the Sprint released ROM and we can achieve root as long as we are on the N920TUVU3DPG1, which I am and have done so using Jovy's ROM. However, my question is regarding the possibility to achieve root for stock odexed firmware. My problem is that I do not like all/some of the modifications that are done on the available ROMS. I prefer the stock look/functions for my phone. I mostly use root for recovery purposes (ie. Titanium, etc). Is there a possible way to achieve Stock Root under our current bootloader limitations without heavily modifying the ROM? I want to use Knox dependent apps (like S-Health) without having to worry about updates etc... If so, can someone here point me to the way to do it? From what I remember reading, leaving the phone on the initial Sprint ROM broke a lot of the functions like bluetooth, LTE and wifi and required a lot of behind the scene changes to make it work. I think that my limited knowledge would not allow me to do these twicks effectively. Thanks for any help.
Recently, Tab A6 T280 successfully rooted and the bootloader still tight locked. However, somebody did a reverse engineering on both kernel and recovery to extract out SHA keys and add it into TWRP and bypass bootloader. This is a major milestone that ALL Samsung phones and tablets can be rooted this way.
Nevertheless, a custom kernel with SELinux policy needs to be installed to achieve root.
mingkee said:
Recently, Tab A6 T280 successfully rooted and the bootloader still tight locked. However, somebody did a reverse engineering on both kernel and recovery to extract out SHA keys and add it into TWRP and bypass bootloader. This is a major milestone that ALL Samsung phones and tablets can be rooted this way.
Nevertheless, a custom kernel with SELinux policy needs to be installed to achieve root.
Click to expand...
Click to collapse
I hadn't read about that and this is an awesome news. Thanks for sharing. I am hopeful that it will come to our great phone since we have the most amazing developers here.
Hoping this is an easy question for someone to answer - I'll do my own research this weekend when I have time and delete the question then if no one has replied. Thanks...
Probably not. The reason I bought the international version was because the snapdragon US variants have locked bootloader's..
That's why you can't flash TWRP and such.
=·\
I got really sick, really fast, of rooting my T-Mobile S7. The only way to do it was with the special unlocked kernel, and SuperSU.
And let's be honest, SuperSU is nowhere near as useful as Magisk. At least if you're like me, and you prefer your phone to be capable of the features that root, and other various mods, available.
The US devices are cursed with the slow, and limited possibilities, that their hardware manufacturer's allow.
=·[
I tried forever to switch my S7 over to Magisk.
Even tried things like recompiling the the special "development kernel", as I think it's called, into an Odin file, by Magisk manager.
And all my attempts always either resulted in the device refusing to even start the boot process, or Odin refusing to allow me to flash the Magisk compiled version of the kernel.. [I was using the special Odin to flash the files, too.]
=·[
Not to say it cannot be done, but I have a feeling it's highly unlikely, unfortunately.
But if you do find a way to make it work on your Note 8, I would love to hear the process, so maybe I could revive my S7 from the sad, slow, state it's in, now.
=·]
Hey there,
So I need to know all the necessary steps to properly install Andronix and Termux (F-Droid) by unlocking the bootloader. Do you know where I can find all the information about that for Galaxy s10?
Depends on WHICH S10 you have. Snapdragon CPU versions cannot really be unlocked. Exynos can. This forum is full of threads on how to do the Exynos, of course... I have a Snapdragon so I haven't spent much time learning it...
Ok thanks I have a snapdragon also so I guess I will do something else
I hear you - I have Snapdragon too, so I gave up ROM and rooting on this phone. Honestly, I don't miss it. I used to ROM and root all my previous phones, but I don't see the need to do that anymore.
I want to ssh my network from my phone using a vpn to access my router so I can wake on lan my server
You should be able to do that without root from the phone - ssh doesn't require root to run, and it's just a secure terminal. You can get an app to do that (I see plenty on the play store). As for VPN, again, you don't need root on the phone to do that - I have used OVPN many times from my phone without issue (and without root).
schwinn8 said:
You should be able to do that without root from the phone - ssh doesn't require root to run, and it's just a secure terminal. You can get an app to do that (I see plenty on the play store). As for VPN, again, you don't need root on the phone to do that - I have used OVPN many times from my phone without issue (and without root).
Click to expand...
Click to collapse
Ok thanks
Why is everybody so convinced that rooting will only be possible with an unlocked bootloader? if there were to be a kernel exploit which would gain us access to the block devices i would say it's possible to downgrade the bootloader or anything which is accessible by block devices like the recovery partition. Am i missing something here?
DaanNL said:
Why is everybody so convinced that rooting will only be possible with an unlocked bootloader? if there were to be a kernel exploit which would gain us access to the block devices i would say it's possible to downgrade the bootloader or anything which is accessible by block devices like the recovery partition. Am i missing something here?
Click to expand...
Click to collapse
If you have a solution to root a galaxy s10 snapdragon cpu I will read your comments on it. But I think I believe that is because of the articles in the internet are only mentioning that I need to unlock the bootloader.
Indirectelex said:
If you have a solution to root a galaxy s10 snapdragon cpu I will read your comments on it. But I think I believe that is because of the articles in the internet are only mentioning that I need to unlock the bootloader.
Click to expand...
Click to collapse
Yes, everybody is so convinced that you need to unlock the bootloader and i wonder why.... we don't need odin to flash, afaik as we can find a kernel exploit which would gain us root access we could set properties to enable the oem unlock option.... making it available and usable could be a different case..... some requirements need to be met. If we could access block devices we should be able to install magisk and root the device.
Indirectelex said:
If you have a solution to root a galaxy s10 snapdragon cpu I will read your comments on it. But I think I believe that is because of the articles in the internet are only mentioning that I need to unlock the bootloader.
Click to expand...
Click to collapse
I think i'm getting somewhere, don't know for sure... at first i was only able to flash CSC and now i'm able to flash every slot.... do you have the same results in odin?
DaanNL said:
I think i'm getting somewhere, don't know for sure... at first i was only able to flash CSC and now i'm able to flash every slot.... do you have the same results in odin?
Click to expand...
Click to collapse
I cant do tests on my galaxy s10 but I will on a Moto z2
we are so ****ed with the cellphones
Yeah, I need one too! I got a Galaxy S10 Plus Snapdragon. It's it's been 2 years since I have it and I can't find nobody that can teach me how to root it!!!
Because it cannot be rooted. US carriers have made that happen, and the manufacturers have had to keep doing it.
Many have tried, and on older BLs it can be done, but once you update you are stuck on a newer BL and cannot downgrade. If you root with the older BL, you cannot upgrade the BL either, because that will relock it.
If someone comes up with a way to do it, I'm all ears, as are many others... but with higher level crypto being implemented for this protection (ie, you need to know the crypto key!), it likely won't happen.
I have an idea but i don't know if it's possible, i tried but it seems corepatch isn't working.
I see a lot of topics about what's needed to unlock the bootloader, but if i look in the source code what is required to unlock the bootloader there's a lot of ro. properties which we can't set because we are not root.
As LSPatch can now communicate with Shizuku and gain system level access we might be able to disable system app verification (platform certificate, by extending CorePatch or maybe someone can write a signature verification disabler for lsposed). Then create an app which doesn't check for all these properties and initiates an OEM unlock and install it as system user./