NOTE: This thread is for the discussion of kernel development. If you don't recompile kernels, please don't post/reply.
After a couple years playing with nexus devices, I'm coming back over to Samsung (until I get bored) and I'm seeing that no one has managed to root a Note 5 device without a recompiled kernel. Why? Because using the stock kernel seems to result in just boot loops.
From what I've been able to observe, the custom kernels all have one thing in common in regards to allowing root to work: They are all changing sepolicy to run permissive instead of making modifications to allow 'su' to work in enforcing mode.
Why?
I have to be honest in saying that I haven't studied how @Chainfire had managed to get su working on the nexus devices while retaining sepolicy in enforcing mode, but it seems that this would be a far better solution than just neutering sepolicy all together.
Has anyone yet attempting to get a sepolicy enforcing kernel working with root? If so, are you willing to share what you tried and how things worked out?
My end-goal is probably to throw together a "as stock as possible" kernel that's root-able. If at all possible, I'm hoping that just some modifications to the ramdisk would be enough to get things working. However, I'd like to take advantage of any previous work done (if any) to get this working.
Thanks
Gary
Edit:
FOR CLARIFICATION. THIS THREAD IS NOT FOR GENERAL USER DISCUSSION. THIS IS FOR DEVELOPERS TO DISCUSS SELINUX, THE NOTE 5 KERNEL, AND METHODS BY WHICH ROOT CAN BE ACHIEVED WITHOUT CHANGING SELINUX TO PERMISSIVE.
Reminder,
Read the OP and stay on topic.
Thanks.
The_Merovingian
Forum Moderator
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
DAGr8 said:
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
Click to expand...
Click to collapse
I'm in the process of trying to modify the sepolicy in the stock boot image ramdisk to see if that allows root to work with the stock kernel (modified ramdisk.)
Wish me luck.
Dammit - all of my tools are out of date. Have to recompile mkbootimg, unpackbootimg, etc.
Okay, so I'm finding out all kinds of Fun Things that Samsung has done with this device...
First, at least some versions of this phone (mine is a 920i) have something in the stock firmware kernel(?) that restores factory recovery on first boot. This is my first sammy device in several years, but I seem to remember reading that other samsung devices have done this as well. (This is the reason that people are having to not allow ODIN to auto-reboot the phone.)
What's really pissing me off, however, is that if I allow TWRP to modify the system partition (based on the prompt on the initial boot) and don't actually make any system changes, the normal stock kernel won't boot... it gets stuck in a boot loop. (pre-bootanimation)
This is similar to the reports people are having of boot loops if they install root without changing the kernel. I'm starting to think it has nothing to do with actually being rooted, but that ANY system partition change is causing the bootloop. (Surprise!)
So, I decided to try something a bit different: I restored stock firmware (tar.md5 via odin) and after the reboot, I went back into ODIN mode. This time, I flashed TWRP and rebooted immediately back into ODIN and a flashed kernel with a modified sepolicy in the ramdisk. I then booted normally. My kernel loaded. I used adb to reboot to recovery. TWRP loaded. From TWRP, reboot normally.. it worked. Good start. adb reboot recovery, and this time I uncheck the option to "only mount system R/O." (It's in the "mount" section of TWRP.) Reboot system... and... BOOTLOOP.
(This has nothing to do with root. I'm not installing root... )
Time to start digging in the kernel ramdisk to try and figure this one out...
Tried the same as above, but with Philz compiled by @arter97. This time, I was stuck in a bootloop after the first time recovery ran. I'm guessing that this particular recovery will ALWAYS touch the system partition without first asking? Not sure... Philz did ask if I wanted to install root when I chose the option to reboot, but I declined.
Note to self:
http://forum.xda-developers.com/showpost.php?p=61542104&postcount=433
Just remove support_scfs,verify from the fstab and altering system will work.
Click to expand...
Click to collapse
I have NFC what "support_scfs" is, but I'll have to spend some time with google to figure it out. Perhaps a bit of SourceDiving. Won't have a chance to test this until tomorrow evening.
I love replying to myself. The truth is, I'm probably one of the few people who could stand talking to me. Of course, even I feel like killing me every now and then. It gets complicated.
Oh.. anyway.. I got it. A stock kernel with a modified ramdisk running selinux in enforcing mode and root-able. I want to spend a day running tests, but will post results of the results in about 20 hours. (assuming I get to sleep tonight...)
As well as gaining the enforcing selinux security (somewhat degraded by being rootable), this also ensures all hardware is working even if samsung "cheats" in posting source code.
(see attached screenshot... it's really the stock kernel and still enforcing SE for Android. )
Edit:
Then again, there's no harm in posting the boot image now. This is from a n920i device using the N920IDVU1AOH6 firmware. I'm attaching a file that can be unzipped and flashed with ODIN (AP slot.) Someone fluent should be able to pull the boot image out of the tarball and flash it directly with TWRP or even via 'dd' (assuming you're already rooted.)
(If you try to flash the .zip file directly, you deserve whatever horrible things happen to your phone.)
THIS IS NOT A RELEASE. THIS IS FOR DEVELOPERS WHO KNOW WHAT THEY ARE DOING TO FIND FLAWS WITH IN REGARDS TO ROOT AND SELINUX. I can't claim this would work for any device without the above mentioned firmware. If you don't know exactly how to recover from Bad Things, don't even download the attachment.
No support. No help. If you have to ask how to flash this or anything of the sort, this isn't for you.
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
garyd9 said:
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
Click to expand...
Click to collapse
Please, publish original boot.img from N920IDVU1AOH6
svadev said:
Please, publish original boot.img from N920IDVU1AOH6
Click to expand...
Click to collapse
Did you not bother to read any of the posts in this thread? There are known locations for stock images. This thread isn't one of them.
Read the very first line in the first post.
I made it for my SM-N9208, and it is really works with supersu 2.50 .
Thanks!
garyd9 said:
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
Click to expand...
Click to collapse
Hi
Could you please post a more detailed guide ? I want to do it myself for my n920c.
Thanks
geek78 said:
Could you please post a more detailed guide ? I want to do it myself for my n920c.
Click to expand...
Click to collapse
yeah. well, at least assuming you know how to unpack and repack boot images... (Because this stuff is very experimental at this point, and still very much a work in progress, you should have a certain level of proficiency before mucking with it. I can't and won't hold anyone's hand for this stuff at this point.)
you need to unpack the boot image. Get the boot.img and unpack. Open the ramdisk. In the ramdisk is a file called 'sepolicy.'
Start with this post to figure out how to change it:
http://forum.xda-developers.com/showpost.php?p=63190351&postcount=2071
Find the reply to that post from Chainfire to see how it can be done without a "reference" device.
You'll also have to change the proper fstab as I documented already in this thread.
Then pack up the ramdisk and repack the boot image.
Thanks. Perfect !
DAGr8 said:
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
Click to expand...
Click to collapse
I'm trying to place your name. Do I know you from SGS2 days or Note2 days?
Anyway, I'm not happy with settling. Never have been...
Edit:
Note or Note 2. Must have been Note2. You were doing smali edits for enabling tablet mode. That was pre-xposed days.
Edit 2:
To answer the question: enforcing selinux adds a layer of security on the device and blocks many security infractions. Basically, if you haven't been given permission to do something, you can't do it. Even as root. In theory, selinux could block the stagefright security issues. When a device is in "permissive" mode, selinux is there, but isn't actually blocking anything. It just logs violations and then ignores them.
In other words, permissive mode completely negates having the se extensions at all. Permissive was a mode that devs could run in to see what might break and what might not.
"root" access is, of course, a hole in the scheme. Chainfire, with supersu, has done quite a bit to ensure that the hole is controlled, but it's still a hole. However, a rooted device with an enforcing selinux kernel is still significantly more secure than a non-rooted permissive selinux kernel.
Another edit:
Here's some links:
https://su.chainfire.eu/#selinux
http://linux.die.net/man/8/selinux
<sarcasm> Wow, I almost forgot how much JOY and FUN it is working with Samsung sh!t kernels. </sarcasm>
So, in testing this (yes, I really DO test things.. imagine that) I found that my device wasn't going into deep sleep. Wow. How interesting. Oh, and not a single wakelock. WTF?!
Instead of google'ing first, I reverted to being a kernel dev (that is now trying to debug a kernel that he hasn't even compiled.) The first thing a kernel dev looks at: "dmesg" So, I copy dmesg to a file and transfer it my PC. (BTW, Notepad++ is God's gift to windows editors.) I search for various strings like "error" and "fail" and "suspend." What I end up seeing is a crapload of messages like this:
Code:
[0: system_server: 3858] PM: Device 0:0:0:x failed to suspend: error -5
(replace x with 1, 2, or 3)
Huh? So, before I dive into the code (because I really don't believe that samsung actually shares the kernel code that they use for themselves), I decided to google around a bit. I finally had enough search terms to hopefully narrow down the search results.
Guess what I found? People having the exact same problem on another samsung device: the S6 (and edge.) Here's the best of the threads:
http://forum.xda-developers.com/galaxy-s6-edge/help/deep-sleep-t3079705
It gets into some interesting detail around page 4 and 5. You'll have to skip past all the clueless people preaching about turning off wifi, downloading snake oil, and worshipping recycled NiCad batteries.
To make a long story short, the stock kernel (or perhaps the bootloader? That shouldn't be possible...) marks a few block devices as read-only if you're using a modified device. (If it's rooted, it's modified. If KNOX is tripped, it's modified, etc.) The kernel from Sammy is trying to flush caches to those devices (which is ironic when you consider they are marked read-only) before going into the suspend. The flush fails, so the entire suspend process fails. It seems that on the SGS6, there were only two devices like this. On the Note5, it seems to be 3 (everything except sda)
In that thread, @HomerSp not only tracked down the problem there, but also (thankfully) figured out that writes to a file in the /sys tree could work around the issue. Thankfully, because the entire point of THIS thread is to use the stock compiled kernel (with a modified ramdisk) to make life Happy. With 3 writes to the /sys tree, magically the device goes to sleep.
(Yes, I'll be taking care of it... and documenting it better...)
What a pain... for some reason, I couldn't write to the cache_type files from within the init.rc structure. No clue why not. Ended up having to add a "service" to the init structure
Anyway...
If you're following along at home, add the following lines to the bottom of init.rc:
Code:
service fix_cache_types /system/bin/sh /sbin/fix_cache_types.sh
class core
user root
oneshot
Then add a new file in the ramdisk's sbin directory called (I bet you guessed this already): fix_cache_types.sh
That file should have perms of 0750 and contain the following:
Code:
#!/system/bin/sh
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:1/cache_type
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:2/cache_type
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:3/cache_type
If you're using the same kernel as I am (n920i), I've attached an updated image. Same rules, conditions, instructions as the last one I posted earlier in this thread. Except this one lets the device take naps. It helps the battery life.
Tomorrow (or Sunday) I'll see if this all works with xposed or not. (I seem to remember something about xposed not working with selinux enforcing kernels, but I could be wrong.) After that, if nothing prevents it (or me), I'll repackage this stuff again, and also throw together an n920c kernel (based on N920CXXU1AOH6) for general use.
BTW, at least on my n920i, I've confirmed that I don't reboot when getting a call (or making one), that NFC works, that bluetooth works, that I can wirelessly charge and quick charge. I'm trying to ensure all the "common" complaints with non-stock boot images are non-issues before giving this out... The whole purpose of using the stock kernel is to retain enforcing selinux and retain completely functional hardware.
garyd9 said:
yeah. well, at least assuming you know how to unpack and repack boot images... (Because this stuff is very experimental at this point, and still very much a work in progress, you should have a certain level of proficiency before mucking with it. I can't and won't hold anyone's hand for this stuff at this point.)
you need to unpack the boot image. Get the boot.img and unpack. Open the ramdisk. In the ramdisk is a file called 'sepolicy.'
Start with this post to figure out how to change it:
http://forum.xda-developers.com/showpost.php?p=63190351&postcount=2071
Find the reply to that post from Chainfire to see how it can be done without a "reference" device.
You'll also have to change the proper fstab as I documented already in this thread.
Then pack up the ramdisk and repack the boot image.
Click to expand...
Click to collapse
Hi
I have unpacked my boot.img. So I can see my sepolicy file in ramdisk/, I have patched it with my rooted Nubia Z9 but I don't understand next steps. Do you have time to explain a little more ?
For the fstab mods I have done it in fstab.samsungexynos7420 and fstab.samsungexynos7420.fwup. Is it ok ?
Thanks.
garyd9 said:
No support. No help. If you have to ask how to flash this or anything of the sort, this isn't for you.
Click to expand...
Click to collapse
garyd9 said:
I can't and won't hold anyone's hand for this stuff at this point.)
Click to expand...
Click to collapse
garyd9 said:
Same rules, conditions, instructions as the last one I posted earlier in this thread.
Click to expand...
Click to collapse
geek78 said:
Do you have time to explain a little more ?
Click to expand...
Click to collapse
Need I say more?
Related
http://forum.xda-developers.com/showthread.php?t=2578566
I don't know if you guys know about this... This allows unsigned kernel modules to be loaded on the equivalent of MI1. If anyone wants to take the steps described by the OP and build for NC5, this would open the ability to work on Kexec and AOSP via Safestrap (with the actual AOSP Kernel!).
npjohnson said:
http://forum.xda-developers.com/showthread.php?t=2578566
I don't know if you guys know about this... This allows unsigned kernel modules to be loaded on the equivalent of MI1. If anyone wants to take the steps described by the OP and build for NC5, then work on Kexec and AOSP via Safestrap (with the actual AOSP Kernel!).
Click to expand...
Click to collapse
So are you basically making this thread not to offer anything new, just to tell people to do more work for you?
Most of the S4 devs already saw that 8 months ago and did what they could with it...
scryan said:
So are you basically making this thread not to offer anything new, just to tell people to do more work for you?
Most of the S4 devs already saw that and did what they could with it...
Click to expand...
Click to collapse
Wow. Way to overreact dude. NO I am not telling you or anyone to do work for me. The ATT and Verizon forums find different things, and therefore, sometimes there is a delay in the info being transferred back and forth. Did anywhere in my post did I say/insinuate that I was forcing people to do work for me? NO, I did not, I just shared some info from the other forum, and you replied by complaining about me cross posting. Thanks for that.
I know that they have probably seen the initial post, but there are some helpful posts later in the thread that seemed interesting about building for later firmwares.
I then even proceeded to try and have been debugging it for the last hour or so...
Update
I tried to follow the steps in the OP of the mentioned thread, but loading an unsigned test module on NC5 fails, although BypassKSLM is loading... More work required.
I think that the fix should be somewhere in the:
if (krsp->ret == 0) {
pr_warn("TIMA: lkmauth--verification succeeded.\n");
ret = 0; /* ret should already be 0 before the assignment. */
As I failed to get ret=0 before assignment.
npjohnson said:
Wow. Way to overreact dude. NO I am not telling you or anyone to do work for me. The ATT and Verizon forums find different things, and therefore, sometimes there is a delay in the info being transferred back and forth. Did anywhere in my post did I say/insinuate that I was forcing people to do work for me? NO, I did not, I just shared some info from the other forum, and you replied by complaining about me cross posting. Thanks for that.
I know that they have probably seen the initial post, but there are some helpful posts later in the thread that seemed interesting about building for later firmwares.
I then even proceeded to try and have been debugging it for the last hour or so...
Click to expand...
Click to collapse
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
jeboo said:
I got this idea after reading about CVE-2013-6282 and seeing the source for it.
Click to expand...
Click to collapse
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Surge1223 said:
This depends on whether or not you are able to root using saferoot or not (since its dependent on the get/put_user exploit) and whether your stock kernel was compiled with support for loading modules. You can check your kernel source config file to see.
Click to expand...
Click to collapse
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
scryan said:
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
Click to expand...
Click to collapse
My apologies for the misunderstanding on the NC5 part, I am using Surges Downgrade to 4.3, which (4.3) still has the get_user put_user exploit. Still NC5 BL, but 4.3 on /system. Plus if we got kexec working on downgraded 4.3, it wouldn't matter that it was 4.3 because we could just load a 4.4 kernel and rom.
My goal was to try to revive (restart from scratch) the project and see where it got to. I currently got a test module loading (what others have already gotten to), now I want to take my own crack at kexec. It probably won't bear fruit, it could though, and thats the idea... but regardless it is a good learning process.
Plus kexec isn't out only option... It works well with safestrap, but there are many other pieces that when put together can function alike kexec, one being ksplice.
npjohnson said:
My apologies for the misunderstanding on the NC5 part, I am using Surges Downgrade to 4.3, which (4.3) still has the get_user put_user exploit. Still NC5 BL, but 4.3 on /system. Plus if we got kexec working on downgraded 4.3, it wouldn't matter that it was 4.3 because we could just load a 4.4 kernel and rom.
My goal was to try to revive (restart from scratch) the project and see where it got to. I currently got a test module loading (what others have already gotten to), now I want to take my own crack at kexec. It probably won't bear fruit, it could though, and thats the idea... but regardless it is a good learning process.
Click to expand...
Click to collapse
I think part of the issue was something along the lines that the kernel is checked and if it does not pass the phone is shutdown/crippled/set into some mode.
Kexec may be slightly more relevant now that there is some access to the trusted zone, but I really have no idea what I am talking about on that one.
But before you worry too much about "Kexec" make sure you are aware of and understand checks on the kernels validity, if they are performed by the tz, and what/how much access to the tz there is now with Dan's latest... at least that my 2 cents.
It seemed the whole kexec thing kind of dead ended because the issue is a bit deeper then just getting a working kexec module and loading a new kernel.
scryan said:
I think part of the issue was something along the lines that the kernel is checked and if it does not pass the phone is shutdown/crippled/set into some mode.
Kexec may be slightly more relevant now that there is some access to the trusted zone, but I really have no idea what I am talking about on that one.
But before you worry too much about "Kexec" make sure you are aware of and understand checks on the kernels validity, if they are performed by the tz, and what/how much access to the tz there is now with Dan's latest... at least that my 2 cents.
It seemed the whole kexec thing kind of dead ended because the issue is a bit deeper then just getting a working kexec module and loading a new kernel.
Click to expand...
Click to collapse
I know. The main reason I posted this was to work in tandem with Dan's new TZ Exploit. It allows running unsigned code at TZ level, and the possibility of turning off TIMA almost altogether, with TIMA disabled, and low level unsigned code, writing a kexec module would the be the next step.
scryan said:
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
Click to expand...
Click to collapse
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Surge1223 said:
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Click to expand...
Click to collapse
I lack the knowledge to even attempt this but I do hope another tries at least. I miss aosp. I'm coming from a HTC with s-off and I'm not used to the restrictions placed on such a locked down phone. I do hope that some work around for running an unsecured kernel will be found at least. Thanks for the information and hopefully it will be put to good use
Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
Surge1223 said:
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Click to expand...
Click to collapse
I though about TowelRoots ability to do the same as get_put, but understanding exactly how it (TR) works is tough due to llvm-obfuscator. After reading a theoretical writeup of TR, I found this:
Source: http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
I thought that due ti the nature of the Futex bug that our best bet was a 4.3 downgrade... though what you are saying makes sense... So, your saying that the memory address to be written to 0x0 has merely changed location? (Im probably misunderstanding you...) I thought that they they had moved that flag out of memory to prevent writing...
How are you decompressing zimage? I tried using instructions like these https://github.com/xiaolu/galaxys2_kernel_repack (obviously changed for our model), but I am having some issues..
npjohnson said:
I though about TowelRoots ability to do the same as get_put, but understanding exactly how it (TR) works is tough due to llvm-obfuscator. After reading a theoretical writeup of TR, I found this:
Source: http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
I thought that due ti the nature of the Futex bug that our best bet was a 4.3 downgrade... though what you are saying makes sense... So, your saying that the memory address to be written to 0x0 has merely changed location? (Im probably misunderstanding you...) I thought that they they had moved that flag out of memory to prevent writing...
How are you decompressing zimage? I tried using instructions like these https://github.com/xiaolu/galaxys2_kernel_repack (obviously changed for our model), but I am having some issues..
Click to expand...
Click to collapse
Do you have the kernel compiled?
Surge1223 said:
Do you have the kernel compiled?
Click to expand...
Click to collapse
I am doing what you were talking about first to learn... Im doing it from an MK2 JB device. So I have the kernel compiled for that one. But I haven't begun on my NC5 KK device yet. We don't have kernel source for NC5 yet, do we?
npjohnson said:
I am doing what you were talking about first to learn... Im doing it from an MK2 JB device. So I have the kernel compiled for that one. But I haven't begun on my NC5 KK device yet. We don't have kernel source for NC5 yet, do we?
Click to expand...
Click to collapse
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SCH-I545
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
sokrboot said:
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
Click to expand...
Click to collapse
I'll let someone more experienced explain any relevance, if there is any, but as far as the "fast reboot" or "hot reboot" option in your power menu... its a method of rebooting that only restarts the GUI.
http://www.xda-developers.com/windows-mobile/reboot-the-shell-only-with-hot-reboot-for-android/
sokrboot said:
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
Click to expand...
Click to collapse
Fastboot and fast reboot are in no way related, or even similar.
RuggedHunter said:
I'll let someone more experienced explain any relevance, if there is any, but as far as the "fast reboot" or "hot reboot" option in your power menu... its a method of rebooting that only restarts the GUI.
http://www.xda-developers.com/windows-mobile/reboot-the-shell-only-with-hot-reboot-for-android/
Click to expand...
Click to collapse
@RuggedHunter thanks for replying with helpful information, I appreciate it.
Surge1223 said:
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SCH-I545
Click to expand...
Click to collapse
Kernel Compiled
Don't forget to hit the thanks button.
http://superstarmobility.weebly.com/
New thread: http://forum.xda-developers.com/android/development/twrp-m1-lg-k7-t3462130.
(Above TWRP can be flashed with Flashify from Playstore)
Instructions from video:
With phone powered off, hold POWER and VOLUME DOWN buttons until LG logo shows. Release POWER then quickly press and hold again until factory reset menu comes up. Select YES and you will be booted into recovery instead of a factory reset ; )
Thanks @czarsuperstar!
V2 with the proper cmd line from m1 aka LG K7
Reserved.
This the real deal?
goitalone said:
This the real deal?
Click to expand...
Click to collapse
Of course. You looked at the video?
goitalone said:
This the real deal?
Click to expand...
Click to collapse
I've used it and can confirm, first tested it with fastboot without flashing of course(use adb to get to the bootloader: adb reboot bootloader , then fastboot:fastboot boot "twrp.img file, tested then rebooted into bootloader, then flashed via fastboot:fastboot flash "twrp.img file") instructions are for any random person that come by i know you know how to do all this
concerned xda citizen
what are the boardconfig.mk file contents that you used to compile this recovery?
the fact youre using a ghetto hacked twrp that works is fine, but id prefer an actual device specific twrp version that will reliably work - theres no telling what this twrp can do to your device, and the fact youre using another devices ramdisk scares the hell out of me.
ramdisks arent something you play around with - you can seriously ruin someones device like that.
also requesting the twrp fstab file youve used.
youre literally just throwing files at users that have perviously bricked their devices and not explaining in detail what they consist of.
if you seriously damage any of these user's device partitions by overwriting the wrong partition, are you going to pay for the devices when theyre hardbricked and no longer responsive to the oem flashing?
not once have a even seen a warning on these files yet youre just posting forum to forum; not to mention youre inexperienced at rom/kernel/recovery compiling for the fact you think its okay to just throw a different devices ramdisk in there " because it just works." when we have readily available source for our device.
legally- youre held responsible for these files youre distributing.
and to those just flashing this twrp file to their device, yes its reversible - but would you want to find out it doesnt work when its too late? IE backing up partitions in the wrong order, and restoring them into the wrong partitions? the video shows it backs up and restores, but is it doing so in the right order? in the right places. i may be ranting but id rather be careful/safe then sorry.
not one detail of this compile/build has been released, just a link that is claimed to work.
"left sock fits on right, doesnt feel right - but my feet aren't cold!" is how this feels to me.
i was sketched to even test this twrp version considering you need to tell the factory reset "yes, i want to wipe" twice, in order to boot to twrp.
idk about you but ive never seen any recovery warrant those options. normally twrp would just boot upon button combo - which is why im sharing this post. recoveries arent supposed to be functioning that way.
NASSTYROME said:
what are the boardconfig.mk file contents that you used to compile this recovery?
the fact youre using a ghetto hacked twrp that works is fine, but id prefer an actual device specific twrp version that will reliably work - theres no telling what this twrp can do to your device, and the fact youre using another devices ramdisk scares the hell out of me.
ramdisks arent something you play around with - you can seriously ruin someones device like that.
also requesting the twrp fstab file youve used.
youre literally just throwing files at users that have perviously bricked their devices and not explaining in detail what they consist of.
if you seriously damage any of these user's device partitions by overwriting the wrong partition, are you going to pay for the devices when theyre hardbricked and no longer responsive to the oem flashing?
not once have a even seen a warning on these files yet youre just posting forum to forum; not to mention youre inexperienced at rom/kernel/recovery compiling for the fact you think its okay to just throw a different devices ramdisk in there " because it just works." when we have readily available source for our device.
legally- youre held responsible for these files youre distributing.
and to those just flashing this twrp file to their device, yes its reversible - but would you want to find out it doesnt work when its too late? IE backing up partitions in the wrong order, and restoring them into the wrong partitions? the video shows it backs up and restores, but is it doing so in the right order? in the right places. i may be ranting but id rather be careful/safe then sorry.
not one detail of this compile/build has been released, just a link that is claimed to work.
"left sock fits on right, doesnt feel right - but my feet aren't cold!" is how this feels to me.
i was sketched to even test this twrp version considering you need to tell the factory reset "yes, i want to wipe" twice, in order to boot to twrp.
idk about you but ive never seen any recovery warrant those options. normally twrp would just boot upon button combo - which is why im sharing this post. recoveries arent supposed to be functioning that way.
Click to expand...
Click to collapse
The first twrp was from a htc phone. This is from lg leon lte. Same manufacturer. I used my boot.img dumped on my sdcard and used the ramdisk from Twrp Leon aka c50 the leon twrp is missing the options seen on this one. Don't use it. But I'm working on cm_m1 so continue to use the old one and when your phone can't come on have fun getting in recovery. Make it better.
Recovery log
Make a log.
NASSTYROME said:
what are the boardconfig.mk file contents that you used to compile this recovery?
the fact youre using a ghetto hacked twrp that works is fine, but id prefer an actual device specific twrp version that will reliably work - theres no telling what this twrp can do to your device, and the fact youre using another devices ramdisk scares the hell out of me.
ramdisks arent something you play around with - you can seriously ruin someones device like that.
also requesting the twrp fstab file youve used.
youre literally just throwing files at users that have perviously bricked their devices and not explaining in detail what they consist of.
if you seriously damage any of these user's device partitions by overwriting the wrong partition, are you going to pay for the devices when theyre hardbricked and no longer responsive to the oem flashing?
not once have a even seen a warning on these files yet youre just posting forum to forum; not to mention youre inexperienced at rom/kernel/recovery compiling for the fact you think its okay to just throw a different devices ramdisk in there " because it just works." when we have readily available source for our device.
legally- youre held responsible for these files youre distributing.
and to those just flashing this twrp file to their device, yes its reversible - but would you want to find out it doesnt work when its too late? IE backing up partitions in the wrong order, and restoring them into the wrong partitions? the video shows it backs up and restores, but is it doing so in the right order? in the right places. i may be ranting but id rather be careful/safe then sorry.
not one detail of this compile/build has been released, just a link that is claimed to work.
"left sock fits on right, doesnt feel right - but my feet aren't cold!" is how this feels to me.
i was sketched to even test this twrp version considering you need to tell the factory reset "yes, i want to wipe" twice, in order to boot to twrp.
idk about you but ive never seen any recovery warrant those options. normally twrp would just boot upon button combo - which is why im sharing this post. recoveries arent supposed to be functioning that way.
Click to expand...
Click to collapse
Check out the LG L70 it's the same way to get in recovery. This must be your first LG phone.
i dont care whether its the same way to enter recovery, my care is youre using another phone's ramdisk in this device.
"I used my boot.img dumped on my sdcard and used the ramdisk from Twrp Leon aka c50 the leon"
post twrp.fstab and boardconfig.mk youve used for this "twrp" build.
this must be your first posting for development on an unsupported device.
as for anyone using another device's files when we have access to source of our own device - i wouldnt trust them to build anything, let alone CM. thats just pure shortcutting and laziness .. and at what expense?
as for twrp making this official, they wont - as you cannot provide SOURCE.
So, now, hopefully you've compiled TWRP for your device and gotten it working. Now, you'd like to know how to get TWRP officially supported for your device so that it can be installed automatically with GooManager. In order for us to add "official support" for your device we'll need the following:
1) Device configuration files to compile TWRP from source for your device. This means that you cannot have repacked a recovery.img by hand to get it working. We need to be able to compile it from source so that we can easily release future updates.
2) A copy of a build prop for your device (it's in /system/build.prop) so that we can add the correct device information to GooManager
3) We'll build a copy of TWRP and send it to you for validation. Once you've validated that we can build a working image for your device, we'll add it to GooManager.
Go spam the other thread. Over 200 downloads and no problems but there was problems right away with the first version. For your info download Twrp c50 from the Twrp site examine it and ask why it's incomplete. That's why I linked the video of the Twrp from the site and same problems. Bye and leave me be. Hd2 check it out. Czarsuperstar's HTC HD2 android custom roms. Check it out and leave me alone. Thanks for your concern. Oh and for your info we have the same keyboard configuration as the LG Leon. There's a device tree. Google it. Google is your friend bro.
NASSTYROME said:
i dont care whether its the same way to enter recovery, my care is youre using another phone's ramdisk in this device.
"I used my boot.img dumped on my sdcard and used the ramdisk from Twrp Leon aka c50 the leon"
post twrp.fstab and boardconfig.mk youve used for this "twrp" build.
this must be your first posting for development on an unsupported device.
as for anyone using another device's files when we have access to source of our own device - i wouldnt trust them to build anything, let alone CM. thats just pure shortcutting and laziness .. and at what expense?
as for twrp making this official, they wont - as you cannot provide SOURCE.
So, now, hopefully you've compiled TWRP for your device and gotten it working. Now, you'd like to know how to get TWRP officially supported for your device so that it can be installed automatically with GooManager. In order for us to add "official support" for your device we'll need the following:
1) Device configuration files to compile TWRP from source for your device. This means that you cannot have repacked a recovery.img by hand to get it working. We need to be able to compile it from source so that we can easily release future updates.
2) A copy of a build prop for your device (it's in /system/build.prop) so that we can add the correct device information to GooManager
3) We'll build a copy of TWRP and send it to you for validation. Once you've validated that we can build a working image for your device, we'll add it to GooManager.
Click to expand...
Click to collapse
not saying a official twrp isn't preferable, but man you got to learn how to talk to people, you were just short of cursing the dude out, and as far as the recovery the thing is solid(tested backup, flash and restore/ anyhow we got LGUP if you **** up so its not a huge deal), but anyone on this site shouldn't take someones word for things like recovery's and you should always test boot before you flash, also you don't seem to understand the first rule of xda-whatever happens to your device is on you, been that way since the og day's- talking politely to others is the way to go about things, people wont listen if you combative.
Kernel
Im building the kernel from source right now check out the video on Twitter. Anyone that wants to join the development I am down with it.
Didn't work, after selecting yes twice, my phone just starts like normal, doesn't go to TWRP or factory restore, it is there though because I can boot to it from the flashify app, ah well.
wait...my bad, I was highlighting the wrong one, lol, works great, thanks
Assuming it ever worked right it should work better now because you can always get to it.
As for concerns about the ramdisk I don't see any issues with that, it's just being used to boot and run recovery on if I'm not mistaken and apparently where the buttons get enabled so a necessity.
Considering many phones have such hacked together recoverys and many more have no custom recovery I'm thankful to have it particularly since most of my work is done away from my pc.
callihn said:
Assuming it ever worked right it should work better now because you can always get to it.
As for concerns about the ramdisk I don't see any issues with that, it's just being used to boot and run recovery on if I'm not mistaken and apparently where the buttons get enabled so a necessity.
Considering many phones have such hacked together recoverys and many more have no custom recovery I'm thankful to have it particularly since most of my work is done away from my pc.
Click to expand...
Click to collapse
Thanks for report. The other Twrp w/o the button combo was from a HTC phone lol and I am getting blasted. HTC or LG? LG K7. ... LG.
[email protected] said:
Thanks for report. The other Twrp w/o the button combo was from a HTC phone lol and I am getting blasted. HTC or LG? LG K7. ... LG.
Click to expand...
Click to collapse
Right and that's why the buttons didn't work. Great job! Best discovery yet for this phone, so happy that we can restore now withoit adb and withoit having to worry about debugging getting turn off, very essential find. Don't let those that don't understand get you down.
callihn said:
Right and that's why the buttons didn't work. Great job! Best discovery yet for this phone, so happy that we can restore now withoit adb and withoit having to worry about debugging getting turn off, very essential find. Don't let those that don't understand get you down.
Click to expand...
Click to collapse
I'm working on building it from source but keep getting errors and I'm trying it with another device that has Twrp (Moto E 2015) and followed the directions to the T and no luck. So I am trying......... Will let everyone know how it's going.
[email protected] said:
Im building the kernel from source right now check out the video on Twitter. Anyone that wants to join the development I am down with it.
Click to expand...
Click to collapse
kernel??????????????????????????
im down!
Read First: This method is relatively drastic, and will hurt device performance some. You should only use this as a last resort, if the more basic methods of fixing a soft brick didn't work (e.g, factory reset, flash stock firmware, etc.)
*Update 8/22: Android O is working with 4 Cores now! Big thank you to @xls654 for finding out how to get Android O to work.
*Petition:
I made a petition for Google to officially release and sign modified boot.imgs, so that people with locked bootloaders can fix their devices too. Check it out here. (I apologize for dumbing it down so much, I wanted to make sure everyone could understand it)
*Changelog:
8/25 - EX kernel for Android O added.
8/22 - Android O DPR6 boot.img and source added.
8/16 - Started making this fix open-source, source code section added in OP. Also uploaded modified Franco and Flash kernel & source.
8/10 - Added PA 7.2.2 and DarkROM boot images.
8/08, 2nd change - Uploaded modified boot.img for firmware 48C.
8/08 - Updated EX kernel to version 4.1.2. This updated zip adds the CPU utilization patch to the init.elemntalx.rc, instead of removing the old init.angler.rc and copying the new init over. That should mean more compatibility with Roms/kernels that modify the init.angler.rc. I also modified the camera-daemon to use cpus 0-3 instead of 0-2, so hopefully this should make the a camera bit faster too.
8/07 - Added boot.img that only uses 1 core. Someone suggested I make a boot.img that only uses 1 core, just to see if it works for devices that didn't work with the 4 Core fix.
7/30 - Added universal EX zip, this zip should modify your kernel to use only 4 cores, and it should modify it to utilize all 4 cores. You can flash this over most ROMs and it should work. Also added a donation url, and this changelog.
7/29, 2nd change - Added Pure Nexus and PA dev version boot images, modified to use 4 cores, and utilize all 4.
7/29 - Updated this fix to greatly improve performance. Before this fix, the device was only using 1 core for foreground tasks, now it will use all 4 cores. Also revamped OP.
7/21 - Fix created, stock boot.img, TWRP image, and EX kernel modified to use 4 cores.
*What this fix does, and how to apply it:
The problem:
The problem with most of the devices in a BLOD, is that a hardware failure related to the BIG cluster has occurred. This fix remedies the problem by disabling the BIG cores. Unfortunately, this does mean that you will take a performance hit. However, I am continually working on ways to improve the device's performance.
The update: If anyone remembers device performance with the first fix, it was hurt a lot, however, after finding out that the device was only using 1 core for all foreground tasks, I modified the ramdisk to utilize all 4 cores more effectively, and it helps a lot.
Requirements: For this fix to work, you need:
A brain
A computer
A bootlooping 6P with an unlocked bootloader/OEM unlocking enabled
The modified files of your choice
Fastboot on your computer (preferably installed system wide). If you do not know what this is, or do not have it, look at this post. Answer yes to all of the prompts to install it.
How to apply the fix:
Boot your phone into bootloader (hold power and volume down).
Connect your phone to the computer.
Go to the folder where you have the modified files, then hold shift and right click in a blank space, click on "open command prompt here" in the menu that pops up.
In the command prompt: type "fastboot flash boot [name of the file here]" and then press enter. If you're flashing TWRP, replace boot with recovery. (Linux users, make sure you're running as root)
Edit: With the new EX zip, you shouldn't need to flash the boot.img anymore, you can just flash twrp, and then flash EX in twrp.
Boot up your phone, and hopefully it should work!
*If your phone is bootloader locked/OEM locked:
You can try to get your phone to boot long enough to enable OEM unlocking. Some users have reported success by freezing their phone for a bit, then booting it. Others have let their battery drain all the way, and then tried to boot their phone, but the most successful method seems to be heating up your phone (a lot).
If you do attempt any of these methods, make sure you have time and patience, as it will take a long time.
To enable OEM unlocking and unlock bootloader:
Go to settings.
Go to developer options, if you do not see that, go to "about phone", scroll to build number, and then tap it 7 times. You should now see developer options in settings.
Once you're in developer options, click on "OEM unlocking" and accept the prompt.
Now reboot your phone to bootloader, connect your phone to the computer, and type "fastboot flashing unlock" Your bootloader should now be unlocked.
*Downloads:
Boot.img from stock 6.17, 8.0 firmware: Download | Mirror. This Image is the from the first official release of Android O, and is modified to use 4 cores. It also disables forced encryption as a bonus. Thank you to @xls654 for figuring out how to get Android O to work.
Boot.img from stock 48C, 7.1.2 firmware: Download | Mirror. This Image is modified to use only 4 cores, and is modified to utilize the 4 cores more effectively. I have had multiple people say that first boot takes a while after flashing this, so just wait about 20 minutes before you declare something is wrong with it.
Boot.img from stock 48B, 7.1.2 firmware: Download |Mirror. This Image is modified to use only 4 cores, and is modified to utilize the 4 cores more effectively. I have had multiple people say that first boot takes a while after flashing this, so just wait about 20 minutes before you declare something is wrong with it.
TWRP version 3.1.1: Download | Mirror. This TWRP image is modified to use only 4 cores.
EX kernel version 5.03: Download | Mirror. EX kernel 5.03 works with android 8.0.0. This zip applies the 4 cores patch, but you will need to flash it over an already modified boot.img to work.
Elemental X kernel version 4.12, universal zip: Download | Mirror. This zip is EX kernel, modified to use only 4 cores. Update: I modified it to apply the CPU utilization patch too, so now this is a universal zip, flash it over almost any ROM, and you should now have the BIG cores disabled fix, and the little core utilization fix.
Flash kernel version 2.5: Download | Mirror. This zip is modified to use only 4 cores, and utilize all 4. Works with android 7.1.2. You can flash this over almost any ROM, including stock, and it should boot again.
Franco kernel r55: Download | Mirror. This zip is modified to use only 4 cores, and utilize all 4. Works with android 7.1.2. You can flash this over almost any ROM, including stock, and it should boot again.
You will most likely not need these images. It will be much easier, and much more universal to flash one of the custom kernel zips above ^^^
PA boot.img from PA version 7.2.2, build 8/10: Download | Mirror. Uses only 4 cores, and has core utilization patch.
PA boot.img from PA version 7.2.1: Download | Mirror. Boot.img from PA dev preview 7.2.1, uses only 4 cores, and is modified to utilize 4 cores more effectively. Flash it after you flash the PA zip, either with fastboot, or TWRP image flash.
Pure Nexus boot.img from Pure Nexus 7/25 build Download | Mirror. This image is modified to use only 4 cores, and it has a tweak to utilize the 4 cores more effectively. Flash it after you flash Pure Nexus, either with fastboot, or TWRP image flash.
DarkROM boot.img from 7/21 build: Download | Mirror. This image is modified to use only 4 cores, and has the utilization patch.
Boot.img modified to use only 1 Core. Some people were reporting that the 4 core images weren't working for them, someone suggested that I make a 1 core version to see if that helps at all. Edit: seems not to help unfortunately. Here it is: Download | Mirror
Unfortunately, I have not been able to get Android O working yet, but I am working on it right now.
If you have a favorite custom ROM or kernel you want to ported over to use 4 cores, let me know, and I'll put it up.
*Source code:
Flash kernel: source | Flash ramdisk/AK2: source.
Franco kernel: source | Franco ramdisk/AK2: source.
Android O boot.img: source.
p-0000000000000000000000000000007 (sorry that was my kitten)
*Tested custom ROMS/kernels
I have used Pure Nexus by flashing the modified EX zip over it, it has notably better performance than the stock ROM, and very good battery life. It's a clean, stable ROM, with plenty of good features that are actually useful.
I have also used Paranoid android dev preview, very good performance, definitely my favorite as of now. Battery life leaves something to be desired, but I have not tried a custom kernel yet. Also, 7.2.1 seemed smoother to me than 7.2.2.
If you have a custom ROM/kernel that worked for you, let me know and I'll put it up here.
*To improve performance slightly:
Flash a custom kernel. I will upload more kernels as I test more, so stay tuned.
Overclock the little cores. It can slightly help offset the lost performance, on my 6P, I have mine overclocked to 1632MHz, and it works perfectly for me. Edit: I actually recommend not overclocking. Many people have reported their Little cores failing, so I would go for longevity on this device, and keep it at stock clocks, or even underclock it. The speed difference you get from overclocking is negligible anyways.
Disable animations in developer options. Seriously, as soon as I found out about this tweak, I've used it on ever single device I've owned, it helps a ton.
Turn resolution down to 1080p. On a small screen, the difference in between 1080p and 1440p is not very noticable. To do this, first get root access, then download a terminal emulator. In the terminal, type "su" and grant it root access, then type "wm size 1080x1920", and finally, change the density "wm density 400". Personally, I like my density at 400, but you can expieriment with it. Lower density=Smaller items and text, Higher density=Bigger items and text. Also @Adithya FRK mentioned that you also want to put density in build.prop so apps display correctly. Change ro.sf.lcd_density=560 to your density, if you changed it.
*Credits:
@rchtk, His post here gave me the idea for how to modify the images.
@flar2, He built the Elemental X kernel for this device, I merely made a small modification to his kernel to use 4 cores. In no way am I trying to steal and/or discredit his work.
The TWRP development team, they built the TWRP recovery for this device, I merely made a small modification to their recovery to use 4 cores. In no way am I trying to steal and/or discredit their work.
@tr1gg3r.man, He made the the PA kernel, I just added a couple modifications. In no way am I trying to steal and/or discredit his work.
@BeansTown106, He made the Pure Nexus kernel, I just added a couple modifications. In no way am I trying to steal and/or discredit his work.
@Dark_Eyes_, He made the DarkROM kernel, I just added a couple modifications to it. In no way am I trying to steal and/or discredit his work.
@[U][COLOR="Purple"]The Flash[/COLOR][/U], He made The Flash kernel, I just made a couple modifications to it. In no way am I trying to steal and/or discredit his work. His posts have also helped me a lot with learning how to build a kernel from source, understanding how to use git more, etc. I recommend you check them out if you are interested in getting started with android development.
@[B]franciscofranco[/B], He made Franco kernel, I just made a couple modifications to it. In no way am I trying to steal and/or discredit his work.
@xls654, He found out how to get Android O working with 4 cores.
FAQs
What's the password for TWRP/Why is TWRP asking for a password? - In android 7.0, Google added forced encryption to the data partition. To get around this, click cancel when TWRP asks you for a password, and then factory reset the device. Then you can flash EX kernel/Magisk to disable forced encryption.
Why am I getting an error when I try to flash the images? - Your bootloader is probably not unlocked, try running the command "fastboot flashing unlock", If you get an error there too, then you will have to enable OEM unlocking before you can continue.
It's not working for me, how do I fix it? - My only advice for that is: "Flash the stock firmware for whatever version image you're trying to flash, then reflash the images again" If you're stuck on the boot animation, wait at least 20 minutes before you declare it's not working. If none of that works, chances are your device may have a different problem.
Does EX kernel have the new speed fix? - Yep, you can flash this over just about any ROM, and it should patch it to use only 4 cores, and use them well.
I would like to help as many people as I can, however, I am much more likely to be able to easily help you/reply to your post if you clearly state your problem and the steps you attempted to fix it. I will be much less likely to reply to posts such as "omggg i flashed the image and my phone won't boot helppp" Please read through post first, I did not spend time typing up this OP for no one to read it. If I can see that you read through the OP and have attempted all the steps, then I will be much more willing to help you.
I set up donations on my profile, for those of you who want to donate. I have spent countless hours modifying, flashing, testing, and helping, don't get me wrong, I love doing this and helping y'all out, but donations really keep me motivated to keep going, and donations also will help me fund new equipment and devices that will help further my android development. Every single donation is appreciated Donate to me here!
If this guide helped you, please click thanks, it means a lot to me
flashed modded TWRP then flashed modded EX Kernel and I'm back up and running... thanks so much!!
How the fuuuuuuuu man you save me, how do you make this.
Really work for my Nexus 6p thank you man, is there any way to send a cup of coffe.
worked for my brick - can enter TWRP again
Hello man is there any way to can use this with Android O ????
You are god!
Enviado desde mi ONEPLUS A3000 mediante Tapatalk
Today it suddenly happened to my device too. I flashed your img and the device booted again, thank you! However, seeing you disabled some cores, would it be caused by a bad core in the device? So, a hardware failure? Or is the boot.img simply corrupted in some sort of way? I'm trying to pinpoint the issue here.
edit: flashed the stock boot.img and the device was back into loop. So it's probably is a hardware defect.
@nabears101 you are AMAZING! Outstanding job.
My phone has life again (even though I already bought a OP5 to replace it)
NeoS said:
Today it suddenly happened to my device too. I flashed your img and the device booted again, thank you! However, seeing you disabled some cores, would it be caused by a bad core in the device? So, a hardware failure? Or is the boot.img simply corrupted in some sort of way? I'm trying to pinpoint the issue here.
edit: flashed the stock boot.img and the device was back into loop. So it's probably is a hardware defect.
Click to expand...
Click to collapse
That would be my guess, I'm trying to figure out if there's a way to debug the bootloader so I can pinpoint the problem with the BIG cores.
javitomen said:
Hello man is there any way to can use this with Android O ????
Click to expand...
Click to collapse
I'll go ahead and upload a version for android O later today
javitomen said:
How the fuuuuuuuu man you save me, how do you make this.
Really work for my Nexus 6p thank you man, is there any way to send a cup of coffe.
Click to expand...
Click to collapse
To anyone who wants to make a boot.img with 4 cores: It's actually fairly simple, you need to get abootimg tools on linux. Then unpack the boot.img with abootimg -x (name of your boot.img) Once the image is extracted, there should be a file named bootimg.cfg, edit that file and put in maxcpus=4 in the line that starts with cmdline =. Then repack the image with abootimg --create myboot.img -f bootimg.cfg -k zImage -r initrd.img And viola! You have a (half) working kernel.
XCnathan32 said:
I'll go ahead and upload a version for android O later today
Click to expand...
Click to collapse
Thanks man you dont know how thankfull i am, i hope your release of the android O to test it, thanks again for your work :good:
javitomen said:
Thanks man you dont know how thankfull i am, i hope your release of the android O to test it, thanks again for your work :good:
Click to expand...
Click to collapse
Just uploaded boot.img and EX Kernel for Android O, check OP. And no problem, I'm always happy to help a fellow android fan.
XCnathan32 said:
I'll go ahead and upload a version for android O later today
Click to expand...
Click to collapse
XCnathan32 said:
Just uploaded boot.img and EX Kernel for Android O, check OP. And no problem, I'm always happy to help a fellow android fan.
Click to expand...
Click to collapse
Hi man i just flash it, but after Android logo just return bobootloader
javitomen said:
Hi man i just flash it, but after Android logo just return bobootloader
Click to expand...
Click to collapse
Oops I'm getting that problem too, working on it now...
XCnathan32 said:
Oops I'm getting that problem too, working on it now...
Click to expand...
Click to collapse
lol thanks man, i hope you can fix it
I don't have this bootloop issue but it is extremely reassuring to know there is a fix even though it means limiting performance and such an easy fix too. Making the modifications seems very easy which makes me wonder why it's taken so long for someone to do a modification like this.
NeoS said:
Today it suddenly happened to my device too. I flashed your img and the device booted again, thank you! However, seeing you disabled some cores, would it be caused by a bad core in the device? So, a hardware failure? Or is the boot.img simply corrupted in some sort of way? I'm trying to pinpoint the issue here.
edit: flashed the stock boot.img and the device was back into loop. So it's probably is a hardware defect.
Click to expand...
Click to collapse
If you're interested, I made a post here https://forum.xda-developers.com/nexus-6p/help/dev-help-debugging-ramoops-bootlooping-t3640826 that semi-identifies the problem, I'm trying to get help on how to fix it.
I'm still downloading your imgs but the response of people to this thread/guide is already making me feel like I've arrived at the end of the Amazing Race (filled with awful challenges of unlocking, rooting, flashing, discharging, waiting, and just. literally. staring.)
Thank you, BLOD SLAYER!
XCnathan32 said:
Oops I'm getting that problem too, working on it now...
Click to expand...
Click to collapse
Hi man, did you found the fix for Android O?
Device: LG V30+
No matter which ROM I try, device encryption (from settings) fails every time. The process does nothing, it just shows the Android logo and reboots. It works on stock firmware (I think, just an option to require password upon boot) but I need encryption on a ROM without Google apps.
I've been trying to get this thing set up all day, if anyone can help I will be beyond thankful.
Averie said:
Device: LG V30+
No matter which ROM I try, device encryption (from settings) fails every time. The process does nothing, it just shows the Android logo and reboots. It works on stock firmware (I think, just an option to require password upon boot) but I need encryption on a ROM without Google apps.
I've been trying to get this thing set up all day, if anyone can help I will be beyond thankful.
Click to expand...
Click to collapse
Which ROMs? On AOSP based ones encrpytion is (for now) completly disabled, because it ****ed with TWRP (even though only encryptable, twrp couldnt mount /data anymore)
an option would be to modify the fstab
(/systen/vendor/etc/fstab.joan or so), commit that removed it is here: https://github.com/SGCMarkus/androi...mmit/e285c593f249e48d1b3a8048a1d173cc2a6f21a0
just add that back (after mounting system as read/write), and then reboot after saving
SGCMarkus said:
Which ROMs? On AOSP based ones encrpytion is (for now) completly disabled, because it ****ed with TWRP (even though only encryptable, twrp couldnt mount /data anymore)
an option would be to modify the fstab
(/systen/vendor/etc/fstab.joan or so)
just add that back (after mounting system as read/write), and then reboot after saving
Click to expand...
Click to collapse
Ohh OK, that makes sense now. The ROMs were a few you have listed, Lineage, AospExtended, RR, etc.
Thank you for clarifying!
Question, how would I go about modifying the fstab? I'll try it myself but I've never done this before.
Averie said:
Ohh OK, that makes sense now. The ROMs were a few you have listed, Lineage, AospExtended, RR, etc.
Thank you for clarifying!
Question, how would I go about modifying the fstab? I'll try it myself but I've never done this before.
Click to expand...
Click to collapse
for modifying it
spaces matter (the amount doesnt though), same for new lines
and to make it writeable
either go to twrp and mount system as rw (you could adb pull it, then edit it on pc (just not with windows editor) and push it back to the old location, overrides it)
or remount system (adb remount)
and then edit it with some text editor on your phone (from a root file explorer most likely)
how it should look like, check the commit from the link in my previous post
SGCMarkus said:
for modifying it
spaces matter (the amount doesnt though), same for new lines
and to make it writeable
either go to twrp and mount system as rw (you could adb pull it, then edit it on pc (just not with windows editor) and push it back to the old location, overrides it)
or remount system (adb remount)
and then edit it with some text editor on your phone (from a root file explorer most likely)
how it should look like, check the commit from the link in my previous post
Click to expand...
Click to collapse
It works
Thank you so much, I appreciate your work.
SGCMarkus said:
Which ROMs? On AOSP based ones encrpytion is (for now) completly disabled, because it ****ed with TWRP (even though only encryptable, twrp couldnt mount /data anymore)
an option would be to modify the fstab
(/systen/vendor/etc/fstab.joan or so), commit that removed it is here: https://github.com/SGCMarkus/androi...mmit/e285c593f249e48d1b3a8048a1d173cc2a6f21a0
just add that back (after mounting system as read/write), and then reboot after saving
Click to expand...
Click to collapse
This does not seem to be working on LG v30 H932 LineageOS 16 lineage-16.0-20190610-UNOFFICIAL-h932.zip
It hangs at 00:00 time left and never finishes encrypting. If I reboot the phone tells me that data is corrupted.
ShapeShifter499 said:
This does not seem to be working on LG v30 H932 LineageOS 16 lineage-16.0-20190610-UNOFFICIAL-h932.zip
It hangs at 00:00 time left and never finishes encrypting. If I reboot the phone tells me that data is corrupted.
Click to expand...
Click to collapse
See the age of the thread? It was for Oreo (encryption still worked there). Not for Pie, that has broken encryption on AOSP (idk if the pie blobs for los17 or so help with that)
SGCMarkus said:
See the age of the thread? It was for Oreo (encryption still worked there). Not for Pie, that has broken encryption on AOSP (idk if the pie blobs for los17 or so help with that)
Click to expand...
Click to collapse
I'm sorry, but not all the information for this device is terribly organized. It was hard for me to figure out that it was broken and not just "user error" by myself. It took you to tell me this, thank you!
Do you happen to have a idea exactly what is crashing or going wrong when encryption is triggered? I'm not that familiar with the lower level hardware and software so I'm not sure how the newer blobs would help.
ShapeShifter499 said:
This does not seem to be working on LG v30 H932 LineageOS 16 lineage-16.0-20190610-UNOFFICIAL-h932.zip
It hangs at 00:00 time left and never finishes encrypting. If I reboot the phone tells me that data is corrupted.
Click to expand...
Click to collapse
ShapeShifter499 said:
I'm sorry, but not all the information for this device is terribly organized. It was hard for me to figure out that it was broken and not just "user error" by myself. It took you to tell me this, thank you!
Do you happen to have a idea exactly what is crashing or going wrong when encryption is triggered? I'm not that familiar with the lower level hardware and software so I'm not sure how the newer blobs would help.
Click to expand...
Click to collapse
Were you on stock Oreo or stock Pie before installing LOS-16?
ChazzMatt said:
Were you on stock Oreo or stock Pie before installing LOS-16?
Click to expand...
Click to collapse
I was in talks with SGCMarkus on Telegram and others. It's been determined to be a SELinux policy issue. It encrypts fine with SELinux set to permissive but not enforcing. I'm trying to sort out the issue but hopefully some others are also working on it now that I have found the issue and reported it in the Telegram channel.
ChazzMatt said:
Were you on stock Oreo or stock Pie before installing LOS-16?
Click to expand...
Click to collapse
ShapeShifter499 said:
I was in talks with SGCMarkus on Telegram and others. It's been determined to be a SELinux policy issue. It encrypts fine with SELinux set to permissive but not enforcing. I'm trying to sort out the issue but hopefully some others are also working on it now that I have found the issue and reported it in the Telegram channel.
Click to expand...
Click to collapse
You're still not answering the question. And reporting in actual ROM thread is still best.
So I assume you installed stock Pie and didn't read the MANY warnings about needing permissive kernel if you go back to LOS-16 ROMs. Also that LOS-17 ROMs are still unfinished work in progress with bugs.
This is Root Sticky Guide. Read post #2:
https://forum.xda-developers.com/lg-v30/how-to/root-v30-t3927154
ShapeShifter499 said:
I'm sorry, but not all the information for this device is terribly organized. It was hard for me to figure out that it was broken and not just "user error" by myself. It took you to tell me this, thank you!
Click to expand...
Click to collapse
It's organized quite well. There's a Root Sticky Guide that tells everything you need to know about custom ROMs.
Seems you ignored that.
It's also linked in HUGE hyperlink in the WTF instructions (near top of that post), pointing to that Guide if you missed it for some reason. You ignored that, also.
It's also linked in post #1 every KDZ Pie thread I maintain.
If the ROM threads themselves don't contain such information -- or at least links to such information -- that's the fault of the ROM maintainers. But
* Sticky Guide
* HUGE Link in bootloader unlock/root instructions
* Link in post #1 of Pie KDZ threads
is quite good organization of material.
ChazzMatt said:
You're still not answering the question. And reporting in actual ROM thread is still best.
So I assume you installed stock Pie and didn't read the MANY warnings about needing permissive kernel if you go back to LOS-16 ROMs. Also that LOS-17 ROMs are still unfinished work in progress with bugs.
This is Root Sticky Guide. Read post #2:
https://forum.xda-developers.com/lg-v30/how-to/root-v30-t3927154
It's organized quite well. There's a Root Sticky Guide that tells everything you need to know about custom ROMs.
Seems you ignored that.
It's also linked in HUGE hyperlink in the WTF instructions (near top of that post), pointing to that Guide if you missed it for some reason. You ignored that, also.
It's also linked in post #1 every KDZ Pie thread I maintain.
If the ROM threads themselves don't contain such information -- or at least links to such information -- that's the fault of the ROM maintainers. But
* Sticky Guide
* HUGE Link in bootloader unlock/root instructions
* Link in post #1 of Pie KDZ threads
is quite good organization of material.
Click to expand...
Click to collapse
I've already been compiling my own LineageOS. It's been determined that due to the issues I've been experiencing that the previous owner must have installed PIE at some point. The seller then seems to have gone back to stock Android 7 Nougat which didn't help the permissive issue. I personally never have installed stock Android 9 PIE. I brought this phone used from a seller on Amazon, there was no way for me to know before receiving the device whether or not the device had been upgraded to PIE before.
However according to SGCMarkus, encryption was never reported working for anyone regardless of if they had the permissive issue or not. I know why, there are no SELinux permissions set up for it. From what I can tell his sources doesn't have them. So even if you didn't have a permissive issue from upgrading to PIE, encryption wouldn't have worked.
ShapeShifter499 said:
I know why, there are no SELinux permissions set up for it. From what I can tell his sources doesn't have them. So even if you didn't have a permissive issue from upgrading to PIE, encryption wouldn't have worked.
Click to expand...
Click to collapse
Well that's interesting.
ChazzMatt said:
Well that's interesting.
Click to expand...
Click to collapse
https://github.com/ShapeShifter499/...mon/blob/lineage-16.0/sepolicy/vendor/vold.te
This needs to be added to a new build in order to allow things to work for encryption. Otherwise the phone attempts the encryption but hangs after rebooting because it's unable to double check that the encryption was successful due to SELinux blocking Vold.
I might have found a quick and dirty Method to Port TWRP to the newest 7.2 shield experience. It's not guaranteed, but it's a chance im going to try. But as I didn't upgraded my own shield yet, I need some files from someone who has rooted his shield already.
1. Is an recovery.img
2. The build.prop
If I can get hands on these files I might be able to bring up a testing version asap
Enough. Seriously.....
Keep it clean, and on-topic... The rules are there for a reason. Don't remember them? HERE you go.
Adromir said:
I might have found a quick and dirty Method to Port TWRP to the newest 7.2 shield experience. It's not guaranteed, but it's a chance im going to try. But as I didn't upgraded my own shield yet, I need some files from someone who has rooted his shield already.
1. Is an recovery.img
2. The build.prop
If I can get hands on these files I might be able to bring up a testing version asap
Click to expand...
Click to collapse
If you want the files
Then can you please update your Sheild tv to the latest firmware for us 7.2.2
An back up the recovery.img
An back up your build.prob
Because I can't help you! I refuse!
Thx again have a great day
i hope you can port the twrp to nvidia sheild tv thx
Foster_e (Shield TV 2015 16GB) - 7.2.2 (30.7.130.7)
recovery.img + build.prop
https://drive.google.com/open?id=18E_u8as1E9dstmRtRwPb97hALdmsrdsc
The recovery is dumped directly from
Code:
/dev/block/platform/sdhci-tegra.3/by-name/SOS -> /dev/block/mmcblk0p16
No offense but quick and dirty does not do it on the new kernel.
You can port as much as you like and it might work for the older models but certainly not for the 2017 model.
And if you have no clue how to get the required files by simply exctracting the firmware files that you can download then I wonder how you will be able to actually modify the recovery image.
People with quite some experience tried and failed, so unless you compile TWRP from source he proper way it won't work (at least not on the 2017).
And even if compiled correctly there is no garantee it will be usable with the secure boot restrictions still in place.
You need a fully rooted device to fully use TWRP and you can not root the 7.2 in the simple way anymore.
Fully rooted the normal TWRP will work just fine.
Downunder35m said:
No offense but quick and dirty does not do it on the new kernel.
You can port as much as you like and it might work for the older models but certainly not for the 2017 model.
And if you have no clue how to get the required files by simply exctracting the firmware files that you can download then I wonder how you will be able to actually modify the recovery image.
People with quite some experience tried and failed, so unless you compile TWRP from source he proper way it won't work (at least not on the 2017).
And even if compiled correctly there is no garantee it will be usable with the secure boot restrictions still in place.
You need a fully rooted device to fully use TWRP and you can not root the 7.2 in the simple way anymore.
Fully rooted the normal TWRP will work just fine.
Click to expand...
Click to collapse
So if I understand you correctly the only way that a recent version of TWRP would work on 7.21 and above are if you have a "rooted" developer image? I have stayed with 7.1 (rooted with a flashed TWRP recovery) My expectation is that Ill stay with it until a stable version is released.
Odd thing is every OTA notification I get refuses to install. It just boots to TWRP without updating. I even opted in for the 7.2.2 beta updates and the shield refuses to update. Kinda thankful as others seem to have so many issues, just not worth it until 7.3 is released perhaps?
Any decent update is worth applying.
But if you ask if it is worth it for those really needing full root access then the answer is no.
The cummunity behind the shield might not be as big as behing Samsung devices but I am sure something will be figured out sooner or later.
@Downunder35m : As I mentioned in a deleted Post, I know how to get these Files from the recovery images. But they are Still 7.2.1 and as 7.2.2 already I didn't see a point in starting with already Outdated Files.
What kind of Things have you been trying already? My Approach was, that maybe TWRP hangs itself, because it can't find the Vendor and system Partition. After unpacking the recovery.img i found out, that the partitions still get mounted, but not over over the fstab anymore but single commands in some init scripts. So my Idea was to patch the kernel of the recovery image with a proper fstab and then use that to build a twrp around it, with the modified boot image. But sadly the resulting TWRP exceeded the Partitionsize. But i didn't set up the Source Tree to compile correctly, because I assumed that with such a breaking approach nvidia did at least moved onward to Android 8.1 ..
A real life job sadly limits my time far more than what I would like.
So maybe my failures are of use to you...
Lets start with the basics:
(All for the 2017 model!)
Firstly, the bootloader has changed and now enforces basically everything Google has on offer.
This means you can not just boot into a custom recovery because the bootloader does not accept it as genuine.
Lets say you get around this problem by, dor example, compiling TWRP from source and with the not yet realesed NVidia 7.2 sources.
There might be other ways but right now I think we can't get around compiling it from scratch.
Once you are able to somehow properly boot into TWRP there is more problems:
A lot if not all special rights and permissions are now handled almost exclusively by the DTB, or to be precise the DTS, which is compiled during boot.
By default TWRP does not make any use of the DTB but instead relies only on the FSTAB configuration.
And since TWRP is not an authorised service, task or app the bootloader won't provide the required rights.
The system partition stays invisible, the vendor part locked and since TWRP is required to copy or store at least some things somewhere this is detected as a possible intrusion.
As that the bootloader now marks the entire system as compromised - the dreaded corrupted system message appears and the system fails to boot.
You could tweak the init files, get the complete FSTAB info from the plat - and nonplat_file_contexts and even fiddle with the rest.
Then you get this happy feeling of a booting TWRP, pull a backup and think all is fine.
That it until you try to reboot and nothing works anymore.
The backup is useless as firstly you can not write it back and secondly it will be encrypted or otherwise corrupt.
To be able to use TWRP ADBD must be able to run in root mode, this is not possible by default on a user or release build, which NVidia now provides as a "developer" firmware.
A bootloader set to enforce all SeLinux and DM-Verity funtions will not allow any vital modifications to any vital part of the system.
In theory you must first at least free the bootloader (we can not do that) or destroy the safety, like by using a modified DTB.
Then you must make sure that you modifiy the prop files so full ADB and ADBD rights are available where they are needed.
After that TRWP will run just fine but it creates a cricle that first needs to be broken somehow
No root rights means no TWRP, no TWRP means no mods to the system.
Magisk currently fails to help us as it does not make use of DTB features at this stage.
And if you ask me then messing with the DTB can backfire badly.
Unlike normal firmwares we won't get a DTB partition included in the boot image or kernel image.
So once the dTB is stuffed too much it will be hard to impossible to install a genuine or custom firmware.
Once Pie comes out this will be worse.
Here the DTB too will be protected and generated/checked during boot.
Unless NVidia wakes up and removes these restrictions from the developer firmwares we will be locked out until someone finds a way to restore full root rights.
Right now I am hopin they will still release the full sources one day.
With a massive effors one could then just compile a normal userdebug firmware and all is fine once more.
Any luck yet? I upgraded one of my Shield TV to 7.2.2 from 7.2.1 dev root and want to install Magisk....
Thanks!
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
UPDATE: Boots but not working correctly so removed links
leezaal said:
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
https://www.androidfilehost.com/?fid=6006931924117905072
---------- Post added at 07:06 PM ---------- Previous post was at 07:05 PM ----------
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
https://www.androidfilehost.com/?fid=6006931924117905072
Click to expand...
Click to collapse
Every time i open recovery it works, but after trying to reboot it bootloops at nvidia. I flash-all and it works again until i enter recovery (then botloops again on reboot). Am i missing something? (shield 2017 7.2.3 dev edition)
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1BCfXg9pUpFm_3sPXp_nEwBlkNU9nelkg/view?usp=sharing
rootfan said:
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1REnehReTaA5BamUBDe8XmBMyZG6zQkFB/view?usp=sharing
Click to expand...
Click to collapse
there is always the bug for 4k screen display?
rootfan said:
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1REnehReTaA5BamUBDe8XmBMyZG6zQkFB/view?usp=sharing
Click to expand...
Click to collapse
Many thanks i renamed this to recovery.img and renamed magisk boot img to boot.img reflashed both as part of the whole 7.2.3 dev OS shield tv 2017 image.
booted into TWRP via adb from my pc it loads up fine on my LG 43" 4k tv no problem rebooted and got back into 7.2.3 also without any issues
UPDATE: TWRP will not let me wipe system / data or anything else or mount any partitions in order to wipe before trying to install anything making this sadly kinda useless right now
twrp seems complicated to be functional lately, the same on my mi max 3, but orange Fox might be better on Shield
leezaal said:
UPDATE: TWRP will not let me wipe system / data or anything else or mount any partitions in order to wipe before trying to install anything making this sadly kinda useless right now
Click to expand...
Click to collapse
Well that makes sense because I was overwriting the emmc fstab with the sata one. I've updated my original post with a link to a new twrp that should have this problem fixed. If you're still having issues please click on the menu button to the right of the home button in twrp and tell me what the log says. Do this when first booting into twrp before doing anything else. It should say something like the following with no mounting complaints if everything is working right.
Shield Debug: Hardware variant is darcy
Shield Debug: Using emmc fstab
Shield Debug: Found required fstab
rootfan said:
Well that makes sense because I was overwriting the emmc fstab with the sata one. I've updated my original post with a link to a new twrp that should have this problem fixed. If you're still having issues please click on the menu button to the right of the home button in twrp and tell me what the log says. Do this when first booting into twrp before doing anything else. It should say something like the following with no mounting complaints if everything is working right.
Shield Debug: Hardware variant is darcy
Shield Debug: Using emmc fstab
Shield Debug: Found required fstab
Click to expand...
Click to collapse
Thanks for the great feedback will DL the updated TWRP and give it a go will report back shortly
UPDATE: 100% working ! Amazing work all partitions mount etc no problem FULLY working TWRP on my 4k TV too