This topic deals specifically with root accessbility. For other topics, please consult the Chromecast FAQ thread or Search.
Are all Chromecasts rootable?
No, not anymore... again.
The HubCap exploit has been patched in firmware build 19084. This means yet again, only certain Chromecasts can have root. It didn't take long - only about a month from the exploit's release and 2-3 weeks from the source release before a patch arrived.
Quick reference
If your Chromecast is running...
Firmware build 12072 (this is the original firmware) - use FlashCast to flash Eureka-ROM to get root
Firmware build before 19084 - HubCap will flash Eureka-ROM to get you root.
After that, you can install Flashcast-AutoRoot to stay current with updates while preserving root (but you will lose the Eureka web panel and SSH, there is still telnet).
Firmware build 19084 or newer - sorry, no root for you.
If your Chromecast is on firmware build 19084 or newer, it is not rootable.
Root now or root later? Why do I need to root before setting up and using the device?
THERE IS NO OPTION TO ROOT LATER!
The current Chromecast setup app forces an update to the latest firmware during Setup - and the latest firmware patches both the original 12072 bootloader exploit and the pre-19084 HubCap exploit. This means once you set up a new Chromecast, it is not longer rootable.
If your new-in-box Chromecast is exploitable by either HubCap or FlashCast, you must apply Eureka-ROM using FlashCast or HubCap BEFORE connecting it to the Internet.
Do I even need root?
Initially there were more reasons to root, like the ability to send local files to Chromecast. However, new Google-approved apps like Avia, RealPlayer Cloud and Plex were released to bridge that gap.
Right now, functionality-wise, root brings you
DNS control (use non-Google DNS)
Telnet access
Other mods/enhancements the community may contribute
DNS control is important for people using Chromecast outside of the US, as many of the Chromecast services like Netflix and Hulu Plus are either unavailable or have restrictions on available content in other countries.
Why can't we get root another way?
While I'm not one to say never, because there are a lot of clever people out there but...
Unlike phones and tablets, Chromecast is quite the ornery Android device...
It has no Fastboot.
So we can't download a new ROM image that way.
It has no accessible recovery.
So we can't install stuff or access the filesystem with an update.zip
It has no image loader/flasher utility.
So we can't download a new ROM image that way either.
It has no interface (screen or input device).
This just makes it even more difficult to interact with it for hacking purposes.
ADB, Telnet and SSH are disabled by default.
No ways to peek or poke around there either.
The runtime filesystem is read-only.
So a clever app can't make changes either.
Google OTA updates are automatically downloaded and applied, updating the bootloader and ROM. Updated bootloader versions will only execute Google-signed code.
So once you get a Google OTA update, you lose the ability to update the ROM (without a new root method).
Long story short, to get root you need to access the filesystem or execute custom (not signed by Google) code.
But you can't access the filesystem.
And you can only execute custom code on the original bootloader (build 12072).
Use of the SDK to obtain root is against its terms of use so there is little traction on that front.
While the first exploit (that FlashCast uses) was found relatively quickly, it took nearly a year for the HubCap exploit to be found and perfected.
I had root with Eureka-ROM and now it appears I don't?
This can happen if the power is pulled or lost during an update.
You may still have the vulnerable bootloader and be able to get root back, depending on how long it has been since the attempted update.
Unplug Chromecast from power until you can re-flash the newest Eureka-ROM via OTG.
This is a good reason to use AC/wall power rather than USB on the TV, as the TV often cuts USB power when the TV is turned off.
For further details, see this post.
Well that pisses me off! Google is evil! I deserve root!! I'm buying something else!!!
Google never promised root. They just promised an SDK that was released February 3, 2014 here. Root capability just came as an unexpected (and perhaps unintended) gift for initial units.
Chromecast is not a phone or tablet. It's a $35 appliance to be connected to a TV. Hacking your TV might be fun, but Chromecast is not aimed at hackers. It's aimed at the normal people who just want to get Netflix, YouTube, etc on their TV and people who like the concept of using the Android or iOS device instead of adding yet another remote control to their pile.
Whether you buy Chromecast is your choice. Nobody said you had to buy every new device Google puts out. Google isn't Apple.
Also keep in mind, Chromecast is useless without content, which requires content providers. Content providers don't like the concept of root access to a device that plays their content. They fear it will allow their content to easily be pirated. That's why CinemaNow and other services don't allow rooted devices.
For the longevity of the device and continued usability for normal customers, it's in Google's best interest not to have widespread/publicized hacking of Chromecast. Long story short, even with thousands of rooted Chromecasts, we're still a minority compared to the millions of Chromecasts out in the market.
All currently sold chromecasts with firmware build 19084 or newer?
bhiga said:
If your Chromecast is running...
Firmware build 12072 (this is the original firmware) - use FlashCast to flash Eureka-ROM to get root
Firmware build before 19084 - HubCap will flash Eureka-ROM to get you root
Firmware build 19084 or newer - sorry, no root for you.
Click to expand...
Click to collapse
Thanks a lot for your helpful FAQ!
Are there still any chromecasts being sold with rootable firmware builds in 2016?
If this is not the case, when were the last chromecasts sold with firmware builds before 19084?
echo_21 said:
Are there still any chromecasts being sold with rootable firmware builds in 2016?
If this is not the case, when were the last chromecasts sold with firmware builds before 19084?
Click to expand...
Click to collapse
Glad it was helpful to you.
Google did a few big sales last year and I haven't seen any of the old ones on store shelves since.
I have seen some recertified ones online from Groupon but it's hit-or-miss whether it still has a rootable build on it.
According to the ones I have seen, the switchover happened between MFG DATE 9/2014 and MFG DATE 11/2014.
See the Rootable Serial Numbers thread for target serial numbers if you can find an unopened one with known serial number.
I never had the time (and the devices) to properly research this but there are a few things that other people might want to test (or already know the answers) and I think it might come very handy to the Note 3 community. There is a somehow similar thread for the S4 community here.
0) SUCCESS WITH KNOX / DOWNGRADING ON N900 !!!
On N900 (Exynos) there is now a solution (unfortunately for the moment only for Exynos models) - a special firmware leaked originally here:
http://sxtpdevelopers.com/samsung-note-3-knox-fix-qualcomm/
(it looks like a firmware reset/update for the EMMC, which results in the erase of the RPMB where Knox flag and downgrade restrictions are stored).
In this thread details on some of the people testing it can be found in those posts:
http://forum.xda-developers.com/showthread.php?p=52329946#post52329946
http://forum.xda-developers.com/showthread.php?p=52408318#post52408318
If the original site is taken down by Samsung you need to search after a file called BL_HA3GZS_CLEAR_WARRANTY_BIT.tar - the one I saw was 2334801 bytes in length (might be shown as a 2.23MB download in some chinese sites). There might be a problem finding it since Samsung might go after anybody hosting and distributing it.
1) Just rooting should not trip knox
The problem with rooting that makes knox 0x1 - originally Root De La Vega was developed for the AT&T very locked structure, and as such it was doing the rooting in a pretty convoluted way. However on other Note 3 versions the knox warranty flag is very clearly linked to just kernel and recovery, and not to system itself. In other words it SHOULD be possible (even after MJ3) to root and keep knox 0x0 on devices that are not "bootloader locked" by not touching kernel and recovery and only touching system - that is probably NOT going to work on AT&T (N900A) but it seems to work on N900W8 and IMHO it could also work on N9005 (and possibly N9000, but I know much less about that). If you want more proof look into the posts about N900W8 + different version (of more or less) stock-based ROMs (like xnote, but stock kernel and recovery).
So the bottom line on this is to verify on a knox 0x0 device with firmware MJ3 (or newer) that just writing a pre-rooted system would be allowed in download mode and would keep knox 0x0. And we would need a more clear confirmation for both N900W8 and N9005 (or any other models) - of course with some description of what was written and how
EDIT: some W8 users have provided extra details and so far it looks it might be more the bootloader itself and not so much in how/what is written, but more information is needed.
EDIT2: there is a thread with that kind of talk here:
http://forum.xda-developers.com/showthread.php?t=2627996
2) We should really test the "portability" of various bootloaders since this could solve a lot of things
First - here are two external (non-xda) pages with some very good development information regarding "bootloader hacking":
http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html
http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
On bootloader-confused devices (for instance Hong-Kong versions that got the KitKat bootloader from Polish/XEO KK and have to wait for Hong-Kong KitKat, or any device that seems to be bricked in the bootloader) it might be also interesting (for somebody VERY daring - remember that it could brick your phone even worse) to try to write the bootloader files (all 5 of them?) from the N900W8 and see if those are accepted (since once that would be the case downgrading would also become a possibility).
EDIT: the N900W8 is also reported (see here) to let you have a custom recovery and not trip knox, which is kind of weird but maybe this is the knox breakthrough that we were expecting
3) More info on STRAP flags (those listed in download mode)
STRAP flags - there are a number of places where the values listed in download mode are discussed, for instance:
http://forum.xda-developers.com/showthread.php?t=2567165
It seems that the values for S T R A and P flags could be versions of the 5 main bootloader-related files used in Qualcomm-based Note 3 devices, most likely:
S - SBL1
T - TZ
R - RPM
A - ABOOT
P - SDI (?)
My EU N9005 (I believe with MI7 or so bootloader) was something like S1, T1, R1, A1, P1 and also SECUREBOOT: ENABLE (CSB) (as it can be seen in the thread above) but is now P2 (which is very strange since I had all automatic and security updates disabled, but might be related to the fact that at some point I activated the reactivation flag linked to the Samsung account - disabling it does not return P back to 1 so this might not be it).
Also if you look around the values seem to be somehow consistent - with post-MJ3 bootloader most flags become 2 and with KitKat bootloader at least the A flag becomes 3.
It remains to be seen if this is the case and if it is any way relevant to hacking the bootloader system or knox (or is just for debug purposes - like when we see people with A3 complaining that they can't return to stock MJ7 or MK2).
4) More info on "microSD debricking and if this could let us re-write different bootloader files (and maybe we should encourage people to have their "debricking image" made in advance "just in case")
When the bootloader files become "bad" and you can not go in download mode (but probably sbl1 is still valid) it is still possible to recover things by forcing the boot process from microSD. That seems to require no extra hardware on Qualcomm models and one small contact for Exynos devices (where that is even documented in Samsung original documents like 13-58_SM-N900_Boot_Recovery_Guide_rev1.0.pdf).
There is a thread on this at:
http://forum.xda-developers.com/showthread.php?t=2625332
5) More info on how Samsung CAN reset knox
There are already two threads with something more than 5-6 first-hand reports from people that went with a Note 3 knox 0x1 into service and left with the same device (and motherboard and IMEI and in some cases all their programs and even their normal/old firmware) but with knox 0x0!
One thread in T-Mobile Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2637718
And a much larger one in International Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2504258
There is also already a "hardware+software solution" (expensive, aimed at specialized phone shops that also do phone unlocking and similar stuff) which claims to be able to reset the knox flag on Exynos devices:
http://forum.gsmhosting.com/vbb/f67...olution-solution-repair-rebuild-emmc-1769456/
http://forum.gsmhosting.com/vbb/f67...bit-0-solution-inside-first-ih-world-1776265/
http://forum.gsmhosting.com/vbb/f672/regarding-knox-s4-1775213/
6) Pre-production bootloaders before knox?
Here is an interesting thread apparently about a N9005 with no knox:
http://forum.xda-developers.com/showthread.php?t=2657631
I'm not too sure if this is helpful, but with the introduction of Kitkat, the SM-N900W8 has been able to flash a custom rom/kernel and recovery without tripping Knox. I am really not sure how this is possible, but my phone is living proof of it. To my understanding we are still using the old bootloader.
(reserved for the future, I just had a very large edit on the top post and not very much extra data can fit there)
Just a note @xclub_101...you cannot write older/different bootloaders using the debrick method. gTan64 and I originally pioneered that method on the Sprint S3, and it was then ported to the other qualcomm S3's, and eventually to other Samsung devices.
It does not work. The phone will only boot with a debrick sdcard when the bootloader written to the sdcard has the same version as the corrupt one on the device emmc.
And even if an older bootloader sdcard COULD boot the device, it wouldn't matter because you would still need to Odin flash a non-corrupt bootloader to the device after using the sdcard, and it would still reject a non-Knox bootloader because of that.
So unfortunately that section is incorrect.
I can downgrade P1 to P0. It is device and carrier specific. I'm not sure what the P flag is for. RPM, SBL1, and TZ were only items modified when downgraded. All signed releases. Looking for any more information regarding these flags.
CNexus said:
Just a note @xclub_101...you cannot write older/different bootloaders using the debrick method. gTan64 and I originally pioneered that method on the Sprint S3, and it was then ported to the other qualcomm S3's, and eventually to other Samsung devices.
It does not work. The phone will only boot with a debrick sdcard when the bootloader written to the sdcard has the same version as the corrupt one on the device emmc.
And even if an older bootloader sdcard COULD boot the device, it wouldn't matter because you would still need to Odin flash a non-corrupt bootloader to the device after using the sdcard, and it would still reject a non-Knox bootloader because of that.
So unfortunately that section is incorrect.
Click to expand...
Click to collapse
That is somehow true, but IMHO if all relevant partitions are wiped on the internal flash (from SBL1 to ABOOT) then all those will be read from microSD and have the code and signatures from there, and the "Odin mode" itself will be the version from microSD.
And here we have a number of interesting paths:
- the signature/hash on SBL1 itself is similar among Note 3 versions - that would result on all steps up to and including ABOOT being valid, so the "special Odin mode" will be entered; if the signature/hash on SBL1 is NOT similar between Note 3 families (or even before and after a major bootloader version) not even the "special Odin mode" will be started;
- if "special Odin mode" is started we can see another fork - if the "downgrade limitations" are part of the microSD code itself then you will be able to write any single firmware you were able to write when the internal SBL1/ABOOT was at the same version as the microSD SBL1/ABOOT - in other words you will be able to downgrade as far back as the microSD SBL1/ABOOT will let you!
- however there are some reports that the "downgrade restrictions" are actually stored in the internal flash in the "invisible/protected" regions there - and can be reset with special JTAG-like hardware:
http://forum.gsmhosting.com/vbb/f672/regarding-knox-s4-1775213/
Even in that last case there would still be a small chance that the "downgrade restrictions" might be skipped when booting from microSD since the internal flash could be considered at that point "less reliable" (or hopefully somebody at Samsung forgot to read that extra info on this special path - we can all hope )
So yes, I would still like to see more detailed tests on it with detailed reports on what is failing at what point! And especially on the microSD with the N900W8 "happy bootloader" or even with some much earlier "early development bootloader" (I have seen something like that mentioned somewhere)!
ryanbg said:
I can downgrade P1 to P0. It is device and carrier specific. I'm not sure what the P flag is for. RPM, SBL1, and TZ were only items modified when downgraded. All signed releases. Looking for any more information regarding these flags.
Click to expand...
Click to collapse
That was on the Verizon N900V? Does that allow you to do direct downgrades or you still need some tricks? Was it still booting with the downgraded versions?
xclub_101 said:
That was on the Verizon N900V? Does that allow you to do direct downgrades or you still need some tricks? Was it still booting with the downgraded versions?
Click to expand...
Click to collapse
Downgrading is limited to the flag fuse counter values. On MJE, I can downgrade to MI9 boot image and recovery. I was able to downgrade to some pre-release engineering SBL1, RPM, and TZ because they're signed and fuse counter is only 1 for those 3. It's very benign and basic to downgrade. Just use heimdall and try downgrading an individual image. If I figure out what P is, I'll be able to test if I can flash anything related to that flag. For some reason, I can downgrade to MI9 boot and recovery, but not the system.img. I'm just starting to learn a lot about the flags/fuse counters after dissecting aboot further. If you've got any more specific questions, feel free to PM me
For the past 2 weeks I've been following the topics on Knox reset on XDA. There is so much discussion but Samsung is not at all helping.
So I was thinking we can do something like Sony Phones
On Sony Phones the trim area i.e. TA.img is backed up to restore later to claim warranty, but this should be done only before the phone is ever unlocked.
So are there any files like TA.img on Note 3 we can backup while the Knox is still 0×0 , So that if and when there is a method to reset Knox we can be ready.
If we can do this, we can go ahead and root or mod our Note 3s
So is this possible ?
iamsuperuser said:
For the past 2 weeks I've been following the topics on Knox reset on XDA. There is so much discussion but Samsung is not at all helping.
So I was thinking we can do something like Sony Phones
On Sony Phones the trim area i.e. TA.img is backed up to restore later to claim warranty, but this should be done only before the phone is ever unlocked.
So are there any files like TA.img on Note 3 we can backup while the Knox is still 0×0 , So that if and when there is a method to reset Knox we can be ready.
If we can do this, we can go ahead and root or mod our Note 3s
So is this possible ?
Click to expand...
Click to collapse
I don't think that will be possible because knox flag is an e-fuse and not a software counter.
I may be wrong, though.
FeralFire said:
I don't think that will be possible because knox flag is an e-fuse and not a software counter.
I may be wrong, though.
Click to expand...
Click to collapse
I somehow might agree to you but there's one thing about Knox which is not understandable by any means, Knox was officially introduced in Note 3 (Android 4.3) however other samsung devices had never had any hint of Knox hardware or software wise so while the official android 4.3 started rolling for other devices ie galaxy s4, note 2 etc they also got Knox and once they're tripped they cannot be reseted however I belive this should not be the case as those devices never had such thing as Knox specifically in terms of hardware and this trick has been surely done by samsung software wise and the only way to reset Knox as f now is known by samsung as few people have reported they got their Knox reset from samsung service centers, so this is kind of strange and I still believe Knox can have something to be done with software n not hardware, though I aint sure about it.........
AndroidNoob22 said:
I somehow might agree to you but there's one thing about Knox which is not understandable by any means, Knox was officially introduced in Note 3 (Android 4.3) however other samsung devices had never had any hint of Knox hardware or software wise so while the official android 4.3 started rolling for other devices ie galaxy s4, note 2 etc they also got Knox and once they're tripped they cannot be reseted however I belive this should not be the case as those devices never had such thing as Knox specifically in terms of hardware and this trick has been surely done by samsung software wise and the only way to reset Knox as f now is known by samsung as few people have reported they got their Knox reset from samsung service centers, so this is kind of strange and I still believe Knox can have something to be done with software n not hardware, though I aint sure about it.........
Click to expand...
Click to collapse
It's implemented differently on different devices. From what I've read here and on other forums, this is why:
On Note 3 Snapdragon models, the warranty bits for the kernel and recovery are actual e-fuses stored in the QFUSE block of the Snapdragon MCU (SoC), so they're "hardware" and thus permanent. EDIT: Apparently it's not permanent, as many Snapdragon owners had the Knox flag reset during service.
On Note 3 Exynos models, they're stored in the RMPB partition on the eMMC and resettable via JTAG, as they're more or less "software," which is how it's likely implemented on the older pre-Knox devices. This is also why some European Note 3 owners got their broken Note 3s back from Samsung with the Knox flag reset back to 0x0. This isn't possible on the Snapdragon models.
siraltus said:
It's implemented differently on different devices. From what I've read here and on other forums, this is why:
On Note 3 Snapdragon models, the warranty bits for the kernel and recovery are actual e-fuses stored in the QFUSE block of the Snapdragon MCU (SoC), so they're "hardware" and thus permanent.
On Note 3 Exynos models, they're stored in the RMPB partition on the eMMC and resettable via JTAG, as they're more or less "software," which is how it's likely implemented on the older pre-Knox devices. This is also why some European Note 3 owners got their broken Note 3s back from Samsung with the Knox flag reset back to 0x0. This isn't possible on the Snapdragon models.
Click to expand...
Click to collapse
The part on Exynos models is probably right since now there is a device that claims to do that - see my link in the first post.
The part with Qualcomm models is not 100% so - there are TONS of reports from people with Qualcomm models (not only N9005 in EU but also ALL T-Mobile models) that had their knox fixed on the same motherboard (and in most cases with ALL their customized software left in place). See also my links in the first post.
xclub_101 said:
The part on Exynos models is probably right since now there is a device that claims to do that - see my link in the first post.
The part with Qualcomm models is not 100% so - there are TONS of reports from people with Qualcomm models (not only N9005 in EU but also ALL T-Mobile models) that had their knox fixed on the same motherboard (and in most cases with ALL their customized software left in place). See also my links in the first post.
Click to expand...
Click to collapse
Oh, really? Awesome then, I had no idea. There is hope for us Snapdragon owners after all.
My motherboard was replaced, that's the only way KNOX can be reset according to the UK service centre I used.
P flag appears to be tied to SBL1. Was able to downgrade SBL1 by itself via Heimdall. Not sure how and why. More research needs to be done.
ryanbg said:
P flag appears to be tied to SBL1. Was able to downgrade SBL1 by itself via Heimdall. Not sure how and why. More research needs to be done.
Click to expand...
Click to collapse
I don't believe that is true. I have compared my flags with other stock btu with the same bootloader and firmware all my flags other than that my P flag is still 0
Also OP needs to recheck the sources regarding knox reset these are for warranty bit on the s4 (android 4.2.2 and below) the supposed claim of knox reset only resets the flash counter. Similar to what triangle away has done in the past
Sent from my SM-N9005 using xda app-developers app
st3chn0 said:
Also OP needs to recheck the sources regarding knox reset these are for warranty bit on the s4 (android 4.2.2 and below) the supposed claim of knox reset only resets the flash counter. Similar to what triangle away has done in the past
Click to expand...
Click to collapse
I don't understand what you are saying, you claim that the two threads below are for S4?
One thread in T-Mobile Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2637718
And a much larger one in International Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2504258
xclub_101 said:
I don't understand what you are saying, you claim that the two threads below are for S4?
One thread in T-Mobile Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2637718
And a much larger one in International Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2504258
Click to expand...
Click to collapse
Sorry I meant the links pointing towards gsmhosting. Those are perfectly fine
Sent from my SM-N9005 using xda app-developers app
st3chn0 said:
Sorry I meant the links pointing towards gsmhosting. Those are perfectly fine
...
Click to expand...
Click to collapse
Those are 3 links since I also wanted to keep some of the "history" on how that was discovered/announced, but the 3rd link is from the guy that actually sells the box and from what I see is saying:
"What this mean ? After replacing or WIPING eMMC and burning old bootloader on device with (KNOX Warranty: 0x01 ) You will get device with unknoxed boot and KNOX Warranty bit 0x0"
And then there is a long list of Exynos devices that are supported, including
Samsung SM-N900 Galaxy Note 3
Samsung SM-N9000Q Galaxy Note 3
and then a separate (and partial) list of the Snapdragon models that are NOT supported.
I have not tested the box personally and that is why I wrote from the very beginning in my original post "claims to be able to reset the knox flag on Exynos devices".
And to finish with that box and the claims they still make on Snapdragon - if they get (in a very controlled and non-destructive) way to remove the downgrading restrictions from the bootloader I think it might still be an interesting achievement - since that way you could revert any device with knox 0x0 to MI7, root and then go to whatever 4.3 or 4.4 you want. But of course that even in that scenario you need that box And on the longer term IMHO that same box might be able to reset knox on Snapdragon - yes, part of knox is in the qfuses but the final flag seems to be computed from that and some part in RPMB (which explains how Samsung resets that flags) - the really difficult part will be to find the way how the above is computed!
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 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.
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