Android 6.0 Kernel root requirements. - Nexus 6 Developer Discussion [Developers Only]

Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.

chairshot215 said:
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
Click to expand...
Click to collapse
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Sent from my Nexus 6 using Tapatalk

buckmarble said:
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.
Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.

chairshot215 said:
Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.
Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.
Click to expand...
Click to collapse
to remove force encryption you need to change "forceencrypt" to "encryptable" in the fstab for userdata. This will not automagically decrypt you, so if you flashed factory images, you will be encrypted again. You will need to format data in TWRP to decrypt again.

I just pushed my anykernel to Github so could post but is pretty much what I had done. what I had done was working after either format data or performing a factory reset with 5.1.1. Starting to think maybe my factory image flash had gone wrong. Could just be a change I am not aware of but did not see the optimizing apps screen after wiping. What I had essentially done is after flashing factory image rebooted bootloader and before booting the first time flashed TWRP installed my Kernel, flashed SuperSu 5.1 and then did a full cache and data wipe.
Admittedly with anykernel I had started by downloading another Kernel, forget which one and then removed or adding what I believed should for my Kernel. So far besides the little encryption issue seems to be working out OK. Trying to keep the Kernel as effective as possible with the fewest possible trade off’s. Not much original work in the sense a lot has already been done but have done lots of testing for efficiency.
Anykernel
https://github.com/Starship-Android/anykernel

chairshot215 said:
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
Click to expand...
Click to collapse
buckmarble said:
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Click to expand...
Click to collapse
That is actually a *really bad hack*, since it disables selinux rather than manipulating the policy in an appropriate manner to make root usage possible.
The correct changes are actually *outside* of the kernel itself, in the sepolicy file in the ramdisk.
That sepolicy file is generated based primarily on what is in these repositories;
https://android.googlesource.com/platform/external/sepolicy/
https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/
You see, there are some interesting commits, like this; https://android.googlesource.com/pl...243e5cf4f8898b7acedc24efd58fdcd163e3048^!/#F0
What that one does, is it tells selinux to never allow the sepolicy to be reloaded from the system_server context.
Or this one here, which does the same for the init context;
https://android.googlesource.com/pl...cy/+/6d0e9c8f4ee4f326b2c2851fa2851193fec33a4e
But note: partially reverted here;
https://android.googlesource.com/pl...abd409af0e7d7fb908e5f04fa1ed946e2996dce^!/#F0
That partial reversion actually provides a very useful HINT about it;
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
# which can be configured on a device-by-device basis if needed.
In other words, add that line to this file;
https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/init.te
Then *init* will re-gain the ability to change and reload selinux policies.
HOWEVER, instead of doing that, you might consider going a little further, by enabling THIS in a sortof-user-build;
https://android.googlesource.com/platform/external/sepolicy/+/master/su.te
... and adding domain_auto_trans from untrusted_app to su, and various other adjustments/tweaks.
I think that there is a neverallow rule in there somewhere that will complain if you make that change, so you'll have to kill the neverallow rule... yep, app domain:
https://android.googlesource.com/platform/external/sepolicy/+/master/app.te#286
**note: a neverallow rule is NOT a runtime enforcement directive. selinux defaults to block until a positive allow rule is created. The neverallow rules are used to annoy you when you try to build an sepolicy from source that violates something.
What *I* would do first, is fix that neverallow rule in app, add the auto-transition to su, and run a make bootimg for *USERDEBUG*. You probably should also edit the fstab a bit while you are at it to kill the "verify" parameter from /system, and swap the "forceencrypt" to "encryptable" for /data.
ALL of the changes (besides removing the neverallow rule) can be made in the shamu device tree.
This should produce a boot.img that relaxes selinux a bit to allow su. And from there, the su binary can be root.root/6755, WITH the file context set to su_exec, and you should have root back.... note: su daemon should *NOT* be required with these changes. In fact, you could even proof of concept using "cp /system/bin/sh /system/bin/su; chown root.root /system/bin/su; chmod 6755 /system/bin/su; chcon su_exec /system/bin/su" <-- you will have to look more at the chcon first parameter though, I haven't actually had to use it though, so I'm not entirely sure of what it expects as input. Note the boldness of "proof of concept"... it would be very... unsafe... to actually keep it like that on any device that you actually need to trust.
phhusson's new fork of superuser *should* be able to handle the job, with only minor adjustments to su.c's su_main() function where it is deciding to run connect_daemon() or su_main_nodaemon(). It would need to run su_main_nodaemon() with these changes.

So I've actually been working on this myself, since it is impossible to trust chainfire or his new employer (who is systematically buying up ALL of the root provisioning software for Android), and I have come up with this as an interim step;
Code:
diff --git a/app.te b/app.te
index 40de074..98bb663 100644
--- a/app.te
+++ b/app.te
@@ -283,7 +283,7 @@ neverallow appdomain { domain -appdomain }:process
# Transition to a non-app domain.
# Exception for the shell domain and the su domain, can transition to runas,
# etc.
-neverallow { appdomain -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
+neverallow { appdomain -untrusted_app -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
{ transition dyntransition };
# Write to rootfs.
diff --git a/domain.te b/domain.te
index 0f6c6da..b1d7c41 100644
--- a/domain.te
+++ b/domain.te
@@ -396,7 +396,7 @@ neverallow domain { file_type fs_type dev_type }:{ lnk_file fifo_file sock_file
# Nobody should be able to execute su on user builds.
# On userdebug/eng builds, only dumpstate, shell, and
# su itself execute su.
-neverallow { domain userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
+neverallow { domain -init -untrusted_app userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
# Do not allow the introduction of new execmod rules. Text relocations
# and modification of executable pages are unsafe.
diff --git a/init.te b/init.te
index 41eafe2..e7dd87a 100644
--- a/init.te
+++ b/init.te
@@ -123,7 +123,7 @@ allow init security_file:dir { create setattr };
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
-# allow init kernel:security load_policy;
+allow init kernel:security load_policy;
# which can be configured on a device-by-device basis if needed.
r_dir_file(init, security_file)
@@ -283,4 +283,5 @@ neverallow init shell_data_file:lnk_file read;
neverallow init app_data_file:lnk_file read;
# init should never execute a program without changing to another domain.
-neverallow init { file_type fs_type }:file execute_no_trans;
+allow init { file_type fs_type }:file execute_no_trans;
+allow init kernel:security read_policy;
diff --git a/keystore.te b/keystore.te
index 83a0e85..d742d30 100644
--- a/keystore.te
+++ b/keystore.te
@@ -24,7 +24,7 @@ selinux_check_access(keystore)
###
neverallow { domain -keystore } keystore_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -keystore } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow { domain -keystore -init } keystore_data_file:dir *;
neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set *;
diff --git a/su.te b/su.te
index d4a488b..1d1f6da 100644
--- a/su.te
+++ b/su.te
@@ -7,6 +7,7 @@ userdebug_or_eng(`
# wrapped to ensure that it does not exist at all on -user builds.
type su, domain, mlstrustedsubject;
domain_auto_trans(shell, su_exec, su)
+ domain_auto_trans(untrusted_app, su_exec, su)
# Allow dumpstate to call su on userdebug / eng builds to collect
# additional information.
diff --git a/vold.te b/vold.te
index b22436f..fa1a879 100644
--- a/vold.te
+++ b/vold.te
@@ -164,7 +164,7 @@ allow vold self:capability sys_chroot;
allow vold storage_file:dir mounton;
neverallow { domain -vold } vold_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -vold } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -vold -init } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow { domain -vold -init } vold_data_file:dir *;
neverallow { domain -vold -init } vold_data_file:notdevfile_class_set *;
neverallow { domain -vold -init } restorecon_prop:property_service set;
Some of those are what reverse engineering I've managed to accomplish on the policy changes required for supersu, and some of them are working towards a better root control infrastructure.
In any case, if you patch platform/external/sepolicy with that, then run a "make bootimage", it *WILL* actually work with supersu.
** note: make sure that you repo init against the android-6.0.0_r1 release branch if you want it to actually be compatible with factory builds. Master has a LOT of MAJOR changes since then and it does not work.
Also note: don't forget to patch platform/device/moto/shamu/fstab.shamu to kill the verify and optionally forceencrypt parameters.

I'm just going to leave these two links right here....
https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser
That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!
Take THAT Coding Code Mobile Technology LLC!!!!!
And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.

doitright said:
I'm just going to leave these two links right here....
https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser
That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!
Take THAT Coding Code Mobile Technology LLC!!!!!
And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.
Click to expand...
Click to collapse
Thanks I have been bed ridden for a bit but will look over all these things. In short my last build I first flashed chainfires boot.img and rooted before flashing my Kernel. Was able to do this without putting my Kernel into permissive mode. Had also unpacked the chainfire boot.img and used a few things in my boot image and used Meld and made a few other edits based on chainfires boot.img. Still having an issue with encryption being forced that just has me baffled. Was otherwise a temporary quick fix for not having to put the Kernel into permissive mode.
Definitely appreciate all the feedback and am learning allot so thanks for that everyone.
Otherwise the Encryption is driving me mentally insane. Like straitjacket throwing myself around a small room with rubber walls and a door with a slot that keeps opening with a tray of drugs and food sliding in insane. It has become so frustrating.
this is the fstab I am using and see know issue. Have also tried Despair, Vortex and the fed_patcher patch not to mention Chainfires Kernel for Root and no matter how many times I wipe data or factory reset it is always encrypted. If it was not knowing the encryption is done via software would swear something is wrong with the phone. Have also changed up TWRP 3 times as noticed I no loner see updating apps but that is also the same in that encription is still forced
https://github.com/Chairshot215/anykernel/blob/master/ramdisk/fstab.shamu

The problem you are running into, is that recovery doesn't actually *format* the userdata partition, which means that a factory reset from recovery won't *remove* the encryption. The reason it doesn't format is to prevent the deletion of /data/media directory, which gets mapped to /sdcard.
What you need to do, is reboot to bootloader, and run "fastboot format userdata".
If you aren't permissive, then the big thing you must have taken from chainfire's boot.img, is the sepolicy file. He only actually changed two files; sepolicy and fstab.shamu.
The thing to be aware of, though, is that his supersu, despite running selinux enforcing, is actually putting a lot of domains into permissive. When you go through your kernel audit log, you should pay attention to the end of the audit log where it says "permissive=1" or "permissive=0". You will find a lot of "permissive=1". Using *my* sepolicy, which is NOT compatible with his supersu, you will find that ALL domains remain enforcing, yet we aren't increasing the authority of any domain besides the "su" domain, AND, there will actually be far fewer denials against root/su. On top of that, I actually block the su domain from messing with kernel security. In other words, we do NOT allow the su domain to change selinux to permissive, OR to reload the policy. Both of those ARE permitted in chainfire supersu, which is incredibly dangerous, given how root is typically used on Android.
To put that into perspective, the ability to change the enforcement status or reload the policy, makes it possible for a malicious application to modify the boot.img to disable dmverity on the system partition, and compromise the system partition. My approach makes it possible to maintain the integrity of the boot partition and therefore maintain dmverity on the system partition, while providing root access. This makes unauthorized changes to the system partition immediately obvious and ineffective, since dmverity will refuse to read changed data, instead returning an i/o error.
The verity keys are actually stored on the boot.img, which means that it is still possible to make *intentional* changes to the system partition (through regenerating the key), and prevent unauthorized changes.
I've been considering adding a new domain to the effect of "su_sensitive" that will enforce strong password input for every authorization request in order to grant kernel security permission, but it remains to be seen if this would even be helpful to anyone.

How do you even edit a kernel? If you could explain, please do so.

Related

[Q] Cyanogen: Set net.hostname at boot

Android 2.2 sets the default hostname to android_dfhjkahdjksf or something equally useless.
To override this in Cyanogen 6.1 you need to set the net.hostname property with setprop Eg:
# setprop net.hostname mickey
My problem is when I try to set this up at boot, something always overwrites my change with the default. I have tried putting it in my init.rc, /etc/init.d and /data/local/userinit.sh and it is always reset to default by the time the phone has booted.
Does anyone have any more ideas about how to permanently set the hostname? It would be a good option to have in cyanogenmod.
UP. I'm very interesting too.
The root filesystem is stored in the boot.img and is expanded to a ramdisk every time you reboot. For changes to be permenant, you need to extract the boot.img file, extract the kernel and ramdisk sections, modify the ramdisk image with your changes, then recombine the kernel and ramdisk to a new boot.img and reflash it. You'll probably need to do this on a linux machine that understands unix permissions and ramdisk/cpio filesystems as well as having a good knowledge of linux and unix commands. See this thread:
http://forum.xda-developers.com/showthread.php?t=551711
note: your kernel may use a different "--base 0x19200000" option when building the kernel boot image.
Is there not a way to add a correlating line to the build.prop file?
EDIT: This doesn't work - whatever is setting the net.hostname writes out after build.prop is read.
I'm looking...
I did a search in the /system/etc directory for any file doing setprop (I'm using a miui rom) and found the following script. I did the setprop for net.hostname in there and it too is being overwritten.
search command:
grep -H -r setprop /system/etc
/system/etc/init.goldfish.sh
I'm running out of ideas other than using autostart to set it after reboot.
EDIT2: doh. I think I already knew this but it dawned on me that the default net.hostname comes from concatenating the "android_id" (found in the secure database table) to the end of "android_".
So seems more likely to reset it after reboot using a script (gscript to launch it manually or use autostart to launch it automatically at the end of reboot cycle).
Property net.hostname originate from services.jar (ConnectivityServices.java):
Code:
// setup our unique device name
String id = Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID);
if (id != null && id.length() > 0) {
String name = new String("android_").concat(id);
SystemProperties.set("net.hostname", name);
}
Maybe CM guys would change this to add another "if /proc/sys/kernel/hostname is different than localhost, use it for net.hostname too" condition.
I'm not using CM so it is up to you guys to make a feature request.
Another approach would be to set service in init.rc that would start your net.hostname changing script on some property being set just after net.hostname is set. You could use also:
Code:
on property:net.hostname=android_blahblah
...but that wouldn't be so handy since you will have to change that line in init.rc every time you make a factory reset.
Really interesting, thx !
BlaY0 said:
Property net.hostname originate from services.jar (ConnectivityServices.java):
Code:
// setup our unique device name
String id = Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID);
if (id != null && id.length() > 0) {
String name = new String("android_").concat(id);
SystemProperties.set("net.hostname", name);
}
Maybe CM guys would change this to add another "if /proc/sys/kernel/hostname is different than localhost, use it for net.hostname too" condition.
I'm not using CM so it is up to you guys to make a feature request.
Another approach would be to set service in init.rc that would start your net.hostname changing script on some property being set just after net.hostname is set. You could use also:
Code:
on property:net.hostname=android_blahblah
...but that wouldn't be so handy since you will have to change that line in init.rc every time you make a factory reset.
Click to expand...
Click to collapse
Thanks a lot. I've been looking for this for the past hour or so. Traditional linux methods to set the hostname don't work... I think I'll add an option in cyanogenmod settings for this and submit it to Gerrit. Look for it to show up within the next day or two.
That's great m8! Cheers
Sent from my HTC Legend
underscores in hostnames are bad
The main thing I want to do is get rid of that underscore. Several of the places I hook up with with WiFi attempt to enter the hostname supplied during the DHCP conversation into a DNS. But underscore is illegal for this purpose.
Numbat.
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums
Moving to Q&A

[DEV only] Random Development thoughts

I have started this thread as a place to discuss random development thought that probably don't need their own threads, and as a place to discuss issues so other threads don't go too far off topic.
Table of Contents:
DBV for c6843: Posts 1 - 6
GPL: Post 7
F2FS: Post 8
wlan: post 9, 11 -
Optimisation Bookmark: post 10
Original Post 1:
First thought
@dbolivar Have you tried building you (DooMKernel) with CONFIG_DVB_CORE = y/m to see if you can get the TV function to work?
blueether said:
I have started this thread as a place to discuss random development thought that probably don't need their own threads, and as a place to discuss issues so other threads don't go too far off topic.
First thought
@dbolivar Have you tried building you (DooMKernel) with CONFIG_DVB_CORE = y/m to see if you can get the TV function to work?
Click to expand...
Click to collapse
Hi, good start. In fact I have, the differences in the kernel options between C6833 and C6843 (Brazilian model with digital TV) are:
Code:
47c47
< CONFIG_MACH_SONY_TOGARI_BRAZIL=y
---
> CONFIG_MACH_SONY_TOGARI_ROW=y
275d274
< CONFIG_ISDBT_TUNER_SMTEJ11X=y
325a325,327
> CONFIG_TOUCHSCREEN_CLEARPAD=y
> CONFIG_TOUCHSCREEN_CLEARPAD_I2C=y
> CONFIG_TOUCHSCREEN_CLEARPAD_RMI_DEV=y
Yes, I don't know why the Clearpad touchscreen is enabled for the C6833, but not for the C6843; I think it's just garbage (perhaps they made the togari defconfig based off honami, and corrected that when making the togari_brazil defconfig). It doesn't make any difference for me, disabling them keep the touchscreen (MAX1187) functions normal.
Well, back to the point: even when applying these differences to the ZU DooMKernel, the digital TV doesn't work. The app stays a long time in a black screen, and finally closes (FC). I investigated the kmsg and logcat, but nothing useful.
CONFIG_DVB_CORE is "m" by default. I tried insmod'ing every module in /system/lib/modules, but same result. I temporarily gave up, because I don't watch the crap they broadcast on the open TV here. But yeah, it would be good to have everything working...
dbolivar said:
Hi, good start. In fact I have, the differences in the kernel options between C6833 and C6843 (Brazilian model with digital TV) are:
Code:
47c47
< CONFIG_MACH_SONY_TOGARI_BRAZIL=y
---
> CONFIG_MACH_SONY_TOGARI_ROW=y
275d274
< CONFIG_ISDBT_TUNER_SMTEJ11X=y
325a325,327
> CONFIG_TOUCHSCREEN_CLEARPAD=y
> CONFIG_TOUCHSCREEN_CLEARPAD_I2C=y
> CONFIG_TOUCHSCREEN_CLEARPAD_RMI_DEV=y
Yes, I don't know why the Clearpad touchscreen is enabled for the C6833, but not for the C6843; I think it's just garbage (perhaps they made the togari defconfig based off honami, and corrected that when making the togari_brazil defconfig). It doesn't make any difference for me, disabling them keep the touchscreen (MAX1187) functions normal.
Well, back to the point: even when applying these differences to the ZU DooMKernel, the digital TV doesn't work. The app stays a long time in a black screen, and finally closes (FC). I investigated the kmsg and logcat, but nothing useful.
CONFIG_DVB_CORE is "m" by default. I tried insmod'ing every module in /system/lib/modules, but same result. I temporarily gave up, because I don't watch the crap they broadcast on the open TV here. But yeah, it would be good to have everything working...
Click to expand...
Click to collapse
I hadn't got around to diff'ing them I just noticed the DVB line and had a quick look at the brazil defconfig.
I guess there is a binary blob that is needed?
For some reason I have to include the clearpad stuff at the moment in the pimped kernel, I should dig to find out why so the kernel is a tad smaller.
blueether said:
I hadn't got around to diff'ing them I just noticed the DVB line and had a quick look at the brazil defconfig.
I guess there is a binary blob that is needed?
For some reason I have to include the clearpad stuff at the moment in the pimped kernel, I should dig to find out why so the kernel is a tad smaller.
Click to expand...
Click to collapse
Hmm very good insight about the binary blob... It's very possible. I have FTFs for the C6833 and C6843, I'll extract them and compare the file list.
I made it work!! Well, involves some manual steps, but it's a very good progress. I started by comparing the file listing in /system from stock C6833 and C6843 firmwares, and although there is no kernel blob, there ARE some files related to DTV, mostly dynamic libs (.so), some configuration, but most importantly, these two:
Code:
/system/bin/dtvsdserver
/system/bin/dtvserver
So, I insmod'ed every module related to DTV/DVB, and then started these guys... And the TV works! BUT, as soon as I quit the Mobile TV app, the process "dtvserver" is killed with a hangup signal, and opening the app again does not restart it, so I have to manually bring the dtvserver up first (otherwise the same previous issue happens, black screen and finally Mobile TV FC's).
I notice some DTV/DVB modules couldn't be insmod'ed:
Code:
insmod: init_module 'dib3000mc.ko' failed (No such file or directory)
insmod: init_module 'dib7000m.ko' failed (No such file or directory)
insmod: init_module 'dib7000p.ko' failed (No such file or directory)
insmod: init_module 'dib8000.ko' failed (No such file or directory)
insmod: init_module 'dib9000.ko' failed (No such file or directory)
insmod: init_module 'mpq-dmx-hw-plugin.ko' failed (No such file or directory)
insmod: init_module 'tuner-simple.ko' failed (No such file or directory)
But the modules are there, and they are the new ones... I don't get it why they can't be insmod'ed, perhaps something is missing from the kernel config? It could be one of the reasons.
Another thing I've been wondering, is why the DVB modules necessary for the Mobile TV are not loaded automatically, like the wlan module is, for instance. Perhaps a difference in the ramdisk? Something to investigate next.
dbolivar said:
I made it work!! Well, involves some manual steps...
Another thing I've been wondering, is why the DVB modules necessary for the Mobile TV are not loaded automatically, like the wlan module is, for instance. Perhaps a difference in the ramdisk? Something to investigate next.
Click to expand...
Click to collapse
Congrats on getting that far with the DTV, will make for a more complete device for the c6843 users that want to use custom ROMs
Any differences in udev or init.rc or whatever android uses?
Development using the GPL and GPL'd code
The GPL is a very powerful tool, as are the other OSS licences. One has to know how they are used and can/can't be enforced before publishing any code under these licences or modifying code that that been published under a OSS licence. Using a OSS licence brings with it risks and rewords, often these are one and the same.
When we do anything with Android [Linux] kernels we fall under the bounds of the GPL v2 that it is published under. Any modification to the kernel has to be published under the same licence, and we have to publish the newly modified source in a sate that can recreate the binary that you publish to the public/xda.
I'll leave you with this quote from http://programmers.stackexchange.com
...are you prepared to live by it, and let other people use what you've written, rather than just liking it because of what you can get out of it?
Click to expand...
Click to collapse
F2FS mount and sysfs options
Now that we have an F2FS-enabled firmware by default, I've been reading about the mount options and sysfs entries available. As many of us know, there are lots of tweaks out there for EXT4, but what about F2FS? Well, here is the official documentation from the Linux kernel:
https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
As for the mount options, I think only discard could be interesting (but it's questionable, some people say it's better to schedule a regular fstrim call instead). There are also some sysfs tunables which I think can have a noticeable impact in battery life, and performance. Testing them would require a lot of trial and error. I'm pasting them below for those who don't want to go through the full document:
Code:
================================================================================
SYSFS ENTRIES
================================================================================
Information about mounted f2f2 file systems can be found in
/sys/fs/f2fs. Each mounted filesystem will have a directory in
/sys/fs/f2fs based on its device name (i.e., /sys/fs/f2fs/sda).
The files in each per-device directory are shown in table below.
Files in /sys/fs/f2fs/<devname>
(see also Documentation/ABI/testing/sysfs-fs-f2fs)
..............................................................................
File Content
gc_max_sleep_time This tuning parameter controls the maximum sleep
time for the garbage collection thread. Time is
in milliseconds.
gc_min_sleep_time This tuning parameter controls the minimum sleep
time for the garbage collection thread. Time is
in milliseconds.
gc_no_gc_sleep_time This tuning parameter controls the default sleep
time for the garbage collection thread. Time is
in milliseconds.
gc_idle This parameter controls the selection of victim
policy for garbage collection. Setting gc_idle = 0
(default) will disable this option. Setting
gc_idle = 1 will select the Cost Benefit approach
& setting gc_idle = 2 will select the greedy aproach.
reclaim_segments This parameter controls the number of prefree
segments to be reclaimed. If the number of prefree
segments is larger than the number of segments
in the proportion to the percentage over total
volume size, f2fs tries to conduct checkpoint to
reclaim the prefree segments to free segments.
By default, 5% over total # of segments.
max_small_discards This parameter controls the number of discard
commands that consist small blocks less than 2MB.
The candidates to be discarded are cached until
checkpoint is triggered, and issued during the
checkpoint. By default, it is disabled with 0.
ipu_policy This parameter controls the policy of in-place
updates in f2fs. There are five policies:
0: F2FS_IPU_FORCE, 1: F2FS_IPU_SSR,
2: F2FS_IPU_UTIL, 3: F2FS_IPU_SSR_UTIL,
4: F2FS_IPU_DISABLE.
min_ipu_util This parameter controls the threshold to trigger
in-place-updates. The number indicates percentage
of the filesystem utilization, and used by
F2FS_IPU_UTIL and F2FS_IPU_SSR_UTIL policies.
max_victim_search This parameter controls the number of trials to
find a victim segment when conducting SSR and
cleaning operations. The default value is 4096
which covers 8GB block address range.
dir_level This parameter controls the directory level to
support large directory. If a directory has a
number of files, it can reduce the file lookup
latency by increasing this dir_level value.
Otherwise, it needs to decrease this value to
reduce the space overhead. The default value is 0.
ram_thresh This parameter controls the memory footprint used
by free nids and cached nat entries. By default,
10 is set, which indicates 10 MB / 1 GB RAM.
@blueether & @dbolivar :
our primary concern should be to get custom wlan (prima/pronto) drivers working on custom compiled kernel for stock ROMs.. once we have that there are a LOT of features which we can add!
so far I havent had much luck but you can find all my tests here
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_stock_4.3_wlan
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_stock_4.3_wlan_clean
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_z1_gpe_port_wlan
A bookmark
Worth the read @dbolivar
http://forum.xda-developers.com/showthread.php?t=2754997
DooMLoRD said:
@blueether & @dbolivar :
our primary concern should be to get custom wlan (prima/pronto) drivers working on custom compiled kernel for stock ROMs.. once we have that there are a LOT of features which we can add!
so far I havent had much luck but you can find all my tests here
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_stock_4.3_wlan
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_stock_4.3_wlan_clean
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_z1_gpe_port_wlan
Click to expand...
Click to collapse
I'm giving it a try - downloaded the latest sources from CodeAurora and applied to your kernel (adjusting Kconfigs, Makefiles and defconfig). The compilation stops here:
Code:
drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.c: In function ‘wlan_hdd_send_avoid_freq_event’:
drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.c:574:18: warning: assignment makes pointer from integer without a cast
error, forbidden warning: wlan_hdd_cfg80211.c:574
make[3]: *** [drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.o] Error 1
OK, so I edited wlan_hdd_cfg80211.c and changed line 574 to add an explicit cast:
Code:
vendor_event = (struct sk_buff *)cfg80211_vendor_event_alloc(pHddCtx->wiphy,
Then it passes by this point, but stops in following lines with similar errors (not even pasting here). What I noticed from these errors it that CodeAurora's sources seem to be incompatible with Sony's kernel, because for instance, the function cfg80211_vendor_event_alloc is not defined anywhere (ran a grep over all *.c and *.h files in the kernel).
Comparing with a CM11 kernel, this function is also not defined anywhere, but the prima sources are very different, they don't call it. So I thought: let's use CM11's prima sources.
Bingo!
Compiled fine, booted, and with the correspoding firmware in /system/etc/firmware/wlan/prima, WLAN came up normally after boot. :victory:
Now you mentioned something about CM11's prima sources, from what I understood they are not ideal. Is that true? Because there are CM11-based custom kernels which implement intelliplug (dependent on custom WLAN drivers), for instance.
Hope it works for you. In this case, I'll put together a more organized how-to of what I did.
dbolivar said:
I'm giving it a try - downloaded the latest sources from CodeAurora and applied to your kernel (adjusting Kconfigs, Makefiles and defconfig). The compilation stops here:
Code:
drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.c: In function ‘wlan_hdd_send_avoid_freq_event’:
drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.c:574:18: warning: assignment makes pointer from integer without a cast
error, forbidden warning: wlan_hdd_cfg80211.c:574
make[3]: *** [drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.o] Error 1
OK, so I edited wlan_hdd_cfg80211.c and changed line 574 to add an explicit cast:
Code:
vendor_event = (struct sk_buff *)cfg80211_vendor_event_alloc(pHddCtx->wiphy,
Then it passes by this point, but stops in following lines with similar errors (not even pasting here). What I noticed from these errors it that CodeAurora's sources seem to be incompatible with Sony's kernel, because for instance, the function cfg80211_vendor_event_alloc is not defined anywhere (ran a grep over all *.c and *.h files in the kernel).
Comparing with a CM11 kernel, this function is also not defined anywhere, but the prima sources are very different, they don't call it. So I thought: let's use CM11's prima sources.
Bingo!
Compiled fine, booted, and with the correspoding firmware in /system/etc/firmware/wlan/prima, WLAN came up normally after boot. :victory:
Now you mentioned something about CM11's prima sources, from what I understood they are not ideal. Is that true? Because there are CM11-based custom kernels which implement intelliplug (dependent on custom WLAN drivers), for instance.
Hope it works for you. In this case, I'll put together a more organized how-to of what I did.
Click to expand...
Click to collapse
great!
can you just fork my repo and shift to the branch which worked for you, then send pull request? i will investigate on the Z1...
and yes please do send the steps!
well if we get custom compiled WLAN modules properly working on custom compiled kernel for stock ROM then i can have features like intelli-plug, F2FS, AsyncFS and lots more on stock ROMs!
DooMLoRD said:
great!
can you just fork my repo and shift to the branch which worked for you, then send pull request? i will investigate on the Z1...
and yes please do send the steps!
well if we get custom compiled WLAN modules properly working on custom compiled kernel for stock ROM then i can have features like intelli-plug, F2FS, AsyncFS and lots more on stock ROMs!
Click to expand...
Click to collapse
Well I'm still learning my way around git & GitHub, so I think it will be faster if you just reproduce the steps below:
1) Copy Prima WLAN sources from CM11-based kernel:
I copied from SlimRom's kernel source. Put the sources under drivers/staging/prima.
2) Modify related Kconfig and Makefile:
drivers/staging/Kconfig
Code:
131,132d130
< source "drivers/staging/prima/Kconfig"
<
drivers/staging/Makefile
Code:
58,59d57
< obj-$(CONFIG_PRIMA_WLAN) += prima/
< obj-$(CONFIG_PRONTO_WLAN) += prima/
3) Modify defconfig:
I'm pasting every option related to WLAN. The Prima options should appear after a "make menuconfig".
Code:
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211=y
CONFIG_NL80211_TESTMODE=y
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_CFG80211_INTERNAL_REGDB=y
# CONFIG_CFG80211_WEXT is not set
# CONFIG_WIRELESS_EXT_SYSFS is not set
# CONFIG_LIB80211 is not set
# CONFIG_CFG80211_ALLOW_RECONNECT is not set
# CONFIG_MAC80211 is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_PM=y
CONFIG_RFKILL_LEDS=y
# CONFIG_RFKILL_INPUT is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_RFKILL_GPIO is not set
...
# CONFIG_WIFI_CONTROL_FUNC is not set
...
CONFIG_WLAN=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_LIBRA_SDIOIF is not set
# CONFIG_ATH6K_LEGACY_EXT is not set
CONFIG_WCNSS_CORE=y
CONFIG_WCNSS_CORE_PRONTO=y
CONFIG_WCNSS_MEM_PRE_ALLOC=y
CONFIG_WCNSS_REGISTER_DUMP_ON_BITE=y
# CONFIG_ATH_COMMON is not set
# CONFIG_BCMDHD is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_IWM is not set
# CONFIG_LIBERTAS is not set
# CONFIG_MWIFIEX is not set
...
#
# Qualcomm Atheros Prima WLAN module
#
CONFIG_PRIMA_WLAN=m
CONFIG_PRONTO_WLAN=y
# CONFIG_PRIMA_WLAN_BTAMP is not set
CONFIG_PRIMA_WLAN_LFR=y
CONFIG_PRIMA_WLAN_OKC=y
CONFIG_PRIMA_WLAN_11AC_HIGH_TP=y
CONFIG_WLAN_FEATURE_11W=y
CONFIG_QCOM_VOWIFI_11R=y
CONFIG_CONFIG_ENABLE_LINUX_REG=y
4) Include Prima WLAN firmware in kernel ZIP file:
Copy from a CM11-based firmware (I used PAC-Rom). Remember to set permissions as 644.
/system/etc/firmware/wlan/prima
Code:
WCNSS_cfg.dat
WCNSS_qcom_cfg.ini
WCNSS_qcom_wlan_nv.bin
5) Include wlan.ko in kernel ZIP file:
Actually I include every compiled kernel module, because we are using a different toolchain and they may benefit from it too. Remember that /system/lib/module/wlan.ko is a symlink, but in my test the target got updated accordingly.
dbolivar said:
Well I'm still learning my way around git & GitHub, so I think it will be faster if you just reproduce the steps below:
1) Copy Prima WLAN sources from CM11-based kernel:
I copied from SlimRom's kernel source. Put the sources under drivers/staging/prima.
2) Modify related Kconfig and Makefile:
drivers/staging/Kconfig
Code:
131,132d130
< source "drivers/staging/prima/Kconfig"
<
drivers/staging/Makefile
Code:
58,59d57
< obj-$(CONFIG_PRIMA_WLAN) += prima/
< obj-$(CONFIG_PRONTO_WLAN) += prima/
3) Modify defconfig:
I'm pasting every option related to WLAN. The Prima options should appear after a "make menuconfig".
Code:
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211=y
CONFIG_NL80211_TESTMODE=y
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_CFG80211_INTERNAL_REGDB=y
# CONFIG_CFG80211_WEXT is not set
# CONFIG_WIRELESS_EXT_SYSFS is not set
# CONFIG_LIB80211 is not set
# CONFIG_CFG80211_ALLOW_RECONNECT is not set
# CONFIG_MAC80211 is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_PM=y
CONFIG_RFKILL_LEDS=y
# CONFIG_RFKILL_INPUT is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_RFKILL_GPIO is not set
...
# CONFIG_WIFI_CONTROL_FUNC is not set
...
CONFIG_WLAN=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_LIBRA_SDIOIF is not set
# CONFIG_ATH6K_LEGACY_EXT is not set
CONFIG_WCNSS_CORE=y
CONFIG_WCNSS_CORE_PRONTO=y
CONFIG_WCNSS_MEM_PRE_ALLOC=y
CONFIG_WCNSS_REGISTER_DUMP_ON_BITE=y
# CONFIG_ATH_COMMON is not set
# CONFIG_BCMDHD is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_IWM is not set
# CONFIG_LIBERTAS is not set
# CONFIG_MWIFIEX is not set
...
#
# Qualcomm Atheros Prima WLAN module
#
CONFIG_PRIMA_WLAN=m
CONFIG_PRONTO_WLAN=y
# CONFIG_PRIMA_WLAN_BTAMP is not set
CONFIG_PRIMA_WLAN_LFR=y
CONFIG_PRIMA_WLAN_OKC=y
CONFIG_PRIMA_WLAN_11AC_HIGH_TP=y
CONFIG_WLAN_FEATURE_11W=y
CONFIG_QCOM_VOWIFI_11R=y
CONFIG_CONFIG_ENABLE_LINUX_REG=y
4) Include Prima WLAN firmware in kernel ZIP file:
Copy from a CM11-based firmware (I used PAC-Rom). Remember to set permissions as 644.
/system/etc/firmware/wlan/prima
Code:
WCNSS_cfg.dat
WCNSS_qcom_cfg.ini
WCNSS_qcom_wlan_nv.bin
5) Include wlan.ko in kernel ZIP file:
Actually I include every compiled kernel module, because we are using a different toolchain and they may benefit from it too. Remember that /system/lib/module/wlan.ko is a symlink, but in my test the target got updated accordingly.
Click to expand...
Click to collapse
which branch did u test this with?
also can you please upload the correct firmware (/system/etc/firmware/wlan/prima) which worked for you?
DooMLoRD said:
which branch did u test this with?
also can you please upload the correct firmware (/system/etc/firmware/wlan/prima) which worked for you?
Click to expand...
Click to collapse
The branch from your kernel was master_kk-4.4.2. The Prima WLAN sources were, as I mentioned, from SlimRom's kernel, branch kk4.4.
I'm attaching the firmware to this post.
blueether said:
A bookmark
Worth the read @dbolivar
http://forum.xda-developers.com/showthread.php?t=2754997
Click to expand...
Click to collapse
Wow this is very nice! Follows the same line of research I've been doing, but this is more "elegant" and in-depth, especially because of all the benchmarks and other comparisons he has done. I'll try this approach myself on my custom builds.
One thing I noticed is that we may still have to use the "hammer" approach with the find & replace of the "-O" flags in *.mk and Makefiles I've been doing, because some of them have these flags hardcoded (i.e. they don't take the value from core/combo/TARGET_linux-arm.mk or other base files). I'll tip JustArchi in his thread about it.
Hi guys, I posted this in the general android section and have had no answer, maybe some one here might know?
I'm trying to build AOSP using CM 11's device tree for togari/togari_gpe and have hit a brick wall after solving the first few make errors.
I have to errors, that I suspect are the same problem:
The first is if I just build with make I get this error:
Code:
Import includes file: out/target/product/togari/obj/SHARED_LIBRARIES/copybit.msm8974_intermediates/import_includes
Import includes file: out/target/product/togari/obj/SHARED_LIBRARIES/libmemalloc_intermediates/import_includes
target thumb C++: libqdutils <= hardware/qcom/display/msm8974/libqdutils/profiler.cpp
target thumb C++: libqdutils <= hardware/qcom/display/msm8974/libqdutils/mdp_version.cpp
target thumb C++: libqdutils <= hardware/qcom/display/msm8974/libqdutils/idle_invalidator.cpp
target thumb C++: libqdutils <= hardware/qcom/display/msm8974/libqdutils/comptype.cpp
hardware/qcom/display/msm8974/libqdutils/mdp_version.cpp:33:27: fatal error: linux/msm_mdp.h: No such file or directory
#include <linux/msm_mdp.h>
^
Import includes file: out/target/product/togari/obj/SHARED_LIBRARIES/gps.msm8974_intermediates/import_includes
compilation terminated.
make: *** [out/target/product/togari/obj/SHARED_LIBRARIES/libqdutils_intermediates/mdp_version.o] Error 1
make: *** Waiting for unfinished jobs....
and if I do make bootimage I get this:
Code:
make: *** No rule to make target `out/target/product/togari/kernel', needed by `out/target/product/togari/boot.img'. Stop.
I suspect that both stem from aosp not finding the kernel source?
kernel source is at ~/dev/aosp/kernel/sony/msm8974/ and I'm building in ~/dev/aosp
I'm also trying to build vanir aosp using the same device tree and kernel and make bootimage completes fine.
Any help would be great
Yo, @DooMLoRD, @blueether @dbolivar
You guys have probably registred that Geohot (iPhone, PS3 jailbreaker) has successfully rooted the Galaxy S5 (and can now claim the $18,000 bounty), but i just read that this one-click root tool should work on any device running a pre-June 3rd kernel, i.e Android 4.4.2. The question is, does it work on the Ultra? I'm aware that it's easy to root an UItra AS LONG as the bootloader is unlocked, but this thing circumvents that part, and roots it. I think.
Are there anyone here still left on 4.4.2 that can try?
More here: Click
LordManhattan said:
Yo, @DooMLoRD, @blueether @dbolivar
You guys have probably registred that Geohot (iPhone, PS3 jailbreaker) has successfully rooted the Galaxy S5 (and can now claim the $18,000 bounty), but i just read that this one-click root tool should work on any device running a pre-June 3rd kernel, i.e Android 4.4.2. The question is, does it work on the Ultra? I'm aware that it's easy to root an UItra AS LONG as the bootloader is unlocked, but this thing circumvents that part, and roots it. I think.
Are there anyone here still left on 4.4.2 that can try?
More here: Click
Click to expand...
Click to collapse
Can't say... Will have to test
Sent from my C6902 using XDA Free mobile app
DooMLoRD said:
Can't say... Will have to test
Sent from my C6902 using XDA Free mobile app
Click to expand...
Click to collapse
I made a thread here. It should work.
http://forum.xda-developers.com/showthread.php?t=2783982

[Root][4.4.2 ND7]GhettoRoot (Towelroot port) v0.3.2

GhettoRoot (Towelroot port) v0.3.0.1, v0.3.2 Testing (looking for new owner)
Code:
*** Disclaimer
This project is licensed under the GPLv3. Bundled third-party components
have different licenses, but these components are bundled or downloaded
as separate executables; all appropriate LICENSE files are included, along
with links to source code.
THIS UTILITY MAKES USE OF A KERNEL EXPLOIT TO GAIN ROOT PRIVILEGES
AND MAKE MODIFICATIONS TO YOUR DEVICE'S FILESYSTEM. IT WILL
PROBABLY WILL VOID YOUR WARRANTY. IF YOU DO NOT FOLLOW THE
INSTRUCTIONS, YOU COULD END UP WITH A BRICK. EVEN IF YOU DO
FOLLOW THE INSTRUCTIONS, YOU MIGHT END UP WITH A BRICK.
ROOTING IS A POTENTIALLY DANGEROUS PROCESS AND, WHILE I WILL TRY
TO HELP IF YOU HAVE TROUBLE, I CANNOT ACCEPT RESPONSIBILITY
FOR RANDOM MISFORTUNE, COSMIC RAYS, ETC.
Help Wanted
My activity with this project will be diminishing. As far as I know, everything as of now "just works" with the SCH-I605, and that's all I really wanted to accomplish from the start. I'm hoping someone will take it over -- ideally someone who'd be willing to look into fixing the code to support other devices. It's open-source, so you can start looking at it now and see if you're interested. Compiling is simple... Just install the NDK and use ndk-build, or 'make' in Linux.
If you'd like to take over the development, and you've worked on projects like this before, I'd greatly appreciate it; perhaps we can get a mod to transfer this thread to you, or you're free to start a new one. After a certain point, I'll stop monitoring threads and messages, so you're free to go ahead and take charge without waiting to hear from me, if you'd like.
Post elsewhere, if you'd like, to let people know that this code is available and might be adjustable for other devices. It really shouldn't be difficult for someone with a background with this stuff.
Problematic areas are likely the iov code (search "Not sure if this is entirely correct") and also the limit_offset stuff (search "ph->limit_offset != 0"), but I have no way of knowing for sure if there's anything wrong with limit_offset since I don't have an applicable Samsung device. There are scattered references to the sources I used to figure out some of this in the README and in ghettoroot.c itself.
That's all, folks. Thanks.
Introduction
This is an automatic root method for your Note 2 (or, potentially, other device) based on code for the CVE-2014-3153 exploit.Unlike towelroot, it is a tethered root in that it requires you to connect your device to a computer to perform the root. However, it only requires a computer the one time; root sticks.
This code appears to have been reverse-engineered from towelroot itself (but not the latest version), so Geohot gets the credit for this one. This is more like a bugfix which only works (for sure) with the Verizon Galaxy Note II so far. The changes from the towelroot-equivalent exploit code are incredibly minimal. Only a few lines of code need really be changed to get it working, but devices incompatible with towelroot are becoming ghetto, so there wasn't a lot of motivation for the problems to be investigated.
GhettoRoot attempts to walk you through the prerequisites for the rooting process and give you hints if there are problems; it does the dirty work itself.
Click to expand...
Click to collapse
Installation instructions
Please see the LICENSE file for details on copying and usage (GPLv3).
This software will attempt to root your device and might void its warranty.
Please BACK UP ANYTHING IMPORTANT before continuing.
Note: By default, v0.3.0.1 attempts to disable Knox and OTA update packages.
If you'd rather this not happen, scroll to CONFIGURATION.
Install USB drivers for your device if needed, for Windows.
Koush's drivers are a good bet. 'Download Windows Installer', and run:
https://github.com/koush/UniversalAdbDriver
Download the busybox-arm4vl binary. The installer will help you with this.
You can get it manually from http://www.busybox.net, specifically from
http://www.busybox.net/downloads/binaries/latest
Place the binary in the files/ folder. It will be automatically renamed
to 'busybox'.
Enable USB debugging. If necessary, go to 'About device' under Settings and tap
the Build number several times to enable the Developer options. Go back, and
go to Developer options, and enable USB debugging there.
Plug in your device to your computer.
Unlock your device's lockscreen if it is locked.
Manually choose a USB mode from the notification, or wait for the Installer mode
phase of USB to end, which takes about 30 seconds. If your device does not have
an Installer mode, skip this. If you're not sure, just wait the 30 seconds.
If/when a popup appears asking for authorization for your PC, allow it.
If a popup does not appear and has never appeared before, or you clicked Cancel,
or you're just having a lot of trouble, go to Developer option and toggle USB
debugging off and on again. Then, try again. You may need to disconnect and re-
connect your device or tap Revoke USB authorization if nothing seems to help.
On Linux or OS X, enter a terminal at the folder you extracted the zip file to,
and type chmod +x INSTALL.sh.
To run, execute INSTALL.cmd on Windows.
On Linux or OS X, type the following in the same terminal: ./INSTALL.sh
Follow the on-screen instructions.
Click to expand...
Click to collapse
Configuration
v0.3.2 config.txt details:
Code:
Open up config.txt, and customize as follows, adding or removing arguments
as you see fit. It should always start with ./root.sh
*** ENSURE THE CONTENTS OF config.txt IS A *SINGLE LINE*.
*** COMMENTS WITHIN config.txt ARE NOT PERMITTED.
Default: ./root.sh --root --deknox --deota --desurveillance
Former default: ./root.sh --root --disable-knox --disable-ota
Usage: ./root.sh [OPTION] [COMMAND]
With no arguments, --root is implied.
Main options
--root, --supersu Install SuperSU (permaroot)
--deknox Remove Knox (recommended)
--deota Remove OTA packages (recommended)
--debloat Remove Bloat (recommended)
--desurveillance Remove some surveillance (recommended)
--disable-ota Disable OTA update-related packages
--disable-knox Disable Knox packages
--really-remove Actually remove things instead of
putting them in $jaildir
--undo Try to undo the specified option.
If you had used --really-remove then
it won't work for deknox, debloat, deota.
Anti-convenience options
--no-mount-rw Don't mount / and /system read-write
--no-sepermissive Don't set SEAndroid to permissive
--no-chmod-scripts Don't chmod 0755 all scripts in
$TMPDIR
COMMAND: Command to be run after other options.
Arguments may follow.
If unspecified, will look for and run custom.sh.
ex. ./root.sh --root
./root.sh --root --undo
./root.sh --root --deknox --deota --debloat
./root.sh cp /sdcard/build.prop /system/build.prop
[/HIDE]
Thanks To/Credits
Code:
geohot for developing [URL="http://forum.xda-developers.com/showthread.php?t=2783157"][U]towelroot[/U][/URL], on which
this code is DIRECTLY based! Reverse-engineered/decompiled, but not by me.
I don't think anyone had a licensing claim on towelroot or this code so I made it GPLv3.
fi01 for his shared [URL="https://gist.github.com/fi01/a838dea63323c7c003cd"][U]exploit code[/U][/URL] on github:
tinyhack.com for the [URL="http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/"][U]helpful post on the Futex bug[/U][/URL]:
chainfire, for [URL="http://forum.xda-developers.com/showthread.php?t=1538053"][U]SuperSU[/U][/URL]!
THANK YOU for the lenient distribution policy.
NetworkingPro at xda-developers for the assistance to all. :)
Other folks at xda-developers for testing and offering support.
Google, of course, and the Android Open Source Project.
Changelog & Download
A note on v0.3.2 Testing:
Code:
WARNING: ESPECIALLY with this version, PLEASE make sure you have backups of
your important applications and their data!
Alternatively, you might be safer changing config.txt to the
old value as listed below.
Code:
This version is called 'Testing' because I haven't really had time to test it
fully, and there's a bunch of new stuff, namely the de* (*-removal) scripts.
I DON'T KNOW HOW WELL THE DE* CODE WORKS. You may want to give me some time
to see how my device holds up before testing yourself, or check out
files/root.sh to see what the new stuff does, but I do need other people to
test as well, so I've changed the config.txt to include the new features,
sans --debloat.
If you DO NOT want to try the new features, change config.txt to the following:
./root.sh --root --disable-knox --disable-ota
However, even the --disable-knox and --disable-ota code has changed.
Your mileage may vary!
Search files/root.sh for ### DEBLOAT, ### DEKNOX, ### DEOTA, ## DESURVEILLANCE,
etc. to see exactly what they do.
Code:
Current changelog: [U][B][URL="http://forum.xda-developers.com/devdb/project/dl/?id=8457"]v0.3.2 [I]Testing[/I][/URL][/B][/U] (2014/09/08)
[fixed?] drowsy attempt to fix a silly bug with default modstring
[new] new default config.txt: --deknox, --deota, --desurveillance
[new] --deknox, --deota, --debloat, --desurveillance, --really-remove,
--undo features added. See README.txt or search files/root.sh
for ### DEBLOAT, ### DEKNOX, ### DEOTA, ## DESURVEILLANCE,
etc. to see exactly what they do.
[change] starting to change verbage from 'phone' to 'device'
[note] v0.3.1 would have been too confusing, so straight to v0.3.2.
[U][B][URL="http://forum.xda-developers.com/devdb/project/dl/?id=8439"]Download v0.3.0.1[/URL][/B][/U] (2014/09/07)
[fixed] Issue with find.exe when other find executables are in PATH.
[URL="http://forum.xda-developers.com/devdb/project/dl/?id=8438"]v0.3.0 (2014/09/07)[/URL]
[new] License: this project is licensed under GPLv3.
[new] Added ADB binaries for Linux and Mac OS X.
[note] This means we have experimental & untested support for Intel Macs
[changed] Restructuring of post-root procedures:
No more hard-coded commands for installing SuperSU, etc.
These things are present in files/root.sh instead, and
may be freely edited.
[changed] Command-line parameters have DRASTICALLY changed.
See the README.txt.
[new] Added modstrings.txt, config.txt
[changed] Busybox no longer bundled due to licensing concerns;
curl added for downloading busybox, instead.
Older changelogs:
Code:
v0.2.2 (2014/09/04)
Fixed INSTALL.cmd hanging when launching ADB, or not running
properly as an administrator.
Further improved error handling, with more detailed steps for
troubleshooting, and retries.
User acknowledgment now required for certain tasks with (Y/N).
Fixed date on previous update being in the future... Hmm...
v0.2.1 (2014/09/03)
** pulled, did not fix adb hang issue after all **
v0.2 (2014/09/03)
Code cleaned up a bit, but still gives verbose debug messages
since they might be important. Can disable those with --brief.
Some error handling in the install script.
Everything is orchestrated from a single batch file ("one-click",
though multiple scripts are still used internally).
Should work properly with Windows and Linux, and come
bundled with ADB for Windows. Thanks, NetworkingPro!
v0.1 (2014/08/31)
Initial release.
LINK TO FORMER THREAD HERE
Apologies in advance for any kind of faux pas I've made or rule I've broken. There always seems to be something...
Code:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* GhettoRoot is free software: you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation, either version 3 of the License, or *
* (at your option) any later version. *
* *
* GhettoRoot is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU General Public License for more details. *
* *
* You should have received a copy of the GNU General Public License *
* along with GhettoRoot. If not, see <http://www.gnu.org/licenses/>. *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
hmmm
If I hadn't just killed my phone (perma red angry text of death) I would definitely help test. Of course you have me to thank as well. Why? Because I knew as soon as I broke my phone, or upgraded someone would come out with a root fix. So you're welcome. However there is still a good chance that the new "probably very used" replacement phone I get from Verizon will be 4.4.2 already so then I will try this out. Unless this is some sort of very cruel trick played on those of us that can't afford to upgrade our phones every other month, in which case shame on you, and I will still try it until I am blue in the face. And crying.
J_3dgar_H00v3r said:
If I hadn't just killed my phone (perma red angry text of death) I would definitely help test. Of course you have me to thank as well. Why? Because I knew as soon as I broke my phone, or upgraded someone would come out with a root fix. So you're welcome. However there is still a good chance that the new "probably very used" replacement phone I get from Verizon will be 4.4.2 already so then I will try this out. Unless this is some sort of very cruel trick played on those of us that can't afford to upgrade our phones every other month, in which case shame on you, and I will still try it until I am blue in the face. And crying.
Click to expand...
Click to collapse
Nope, not a trick! My username looks a bit dubious even to me, but it was randomly generated by KeePass.
I am getting, "error: device unauthorized. Please check the confirmation dialog on your device." I am not getting anything on my phone. Any thoughts?
Im testing this now. Will let you know in a few mins. So far, so good.
Edit: This worked like a champ for me. Root achieved. For anyone wanting to do this, please follow these steps:
Run clean.cmd
Run prepare.cmd
Run root.cmd
Do these in this order. I went ahead and added a pause to each batch (Except root.bat that already had one) to ensure everything was kicking off as expected. Sorry if this was outlined in the OP, but Im sort of a "D personality" and wont read a lot of fluff.
Thanks!
Seems to be running good here to ... some more fiddling and see how things go but I now have root on 4.4.2. Thanks
Update: no problems also Knox has NOT been tripped and no other issues.
Worked for me!
I tried this, and it worked like a charm. So far, no issues.
Thank you!!!
=D
i dont think i've been this excited since safestrap was in the works for the N2!!! cant wait to try this when i get home!!! thanks dev
I still don't have root. Not sure what went wrong. My phone restarted like it was supposed to but not root.
NetworkingPro said:
Im testing this now. Will let you know in a few mins. So far, so good.
Edit: This worked like a champ for me. Root achieved. For anyone wanting to do this, please follow these steps:
Run clean.cmd
Run prepare.cmd
Run root.cmd
Do these in this order. I went ahead and added a pause to each batch (Except root.bat that already had one) to ensure everything was kicking off as expected. Sorry if this was outlined in the OP, but Im sort of a "D personality" and wont read a lot of fluff.
Thanks!
Click to expand...
Click to collapse
Does clean.cmd wipe all data? I only ran root.cmd and the phone rebooted like it was supposed to, but Titanium Backup doesn't register my device as rooted.
Tkun said:
Does clean.cmd wipe all data? I only ran root.cmd and the phone rebooted like it was supposed to, but Titanium Backup doesn't register my device as rooted.
Click to expand...
Click to collapse
It just cleans up old root files that might have been part of previous root methods, or failed attempts.
NetworkingPro said:
It just cleans up old root files that might have been part of previous root methods, or failed attempts.
Click to expand...
Click to collapse
Thanks! Using your steps it worked and my phone is rooted!
Also, thanks OP for providing this solution! I was worried us 4.4.2 users would never again have root. I can finally backup and restore my apps again using Titanium Backup.
Tkun said:
Thanks! Using your steps it worked and my phone is rooted!
Also, thanks OP for providing this solution! I was worried us 4.4.2 users would never again have root. I can finally backup and restore my apps again using Titanium Backup.
Click to expand...
Click to collapse
Glad I could help, I went ahead and read through the source code before I did it, so had a pretty good idea of what it was doing.
---------- Post added at 10:38 PM ---------- Previous post was at 10:36 PM ----------
25yvdgpo06 said:
tl;dr: This is a modified version of [basically towelroot] to work with the Verizon Galaxy Note II (SCH-I605) VRUFND7 firmware.
Currently, a PC with the Prerequisites is required. If someone wants to package this into an APK, that's great and it may remove the PC requirement.
I'm too new to be allowed to post in the developer forums (which is probably for the best), and I don't consider myself much of a developer anyway, but with a couple sleepless nights, a little bit of determination, and a lot of sugar cereal (but not enough milk!!!!), I've modded some code based on Towelroot to get the CVE-2014-3153 exploit to work with our phone and its 3.0.31 kernel. Who knows - it might work with other phones, too, but this is the only one I have right now.
WARNINGS
YOUR MILEAGE MAY VARY. THIS WILL PROBABLY VOID YOUR WARRANTY. PLEASE BACK UP IMPORTANT FILES FIRST, JUST IN CASE AND AS A GOOD PRACTICE.
Your phone will reboot after rooting which could cause data loss if any apps are in the middle of writing data, so please close open apps and wait a few moments before rooting! If your phone is just starting up, give it some time to initialize before rooting. These recommendations should be followed prior to almost any automated reboot of your phone, but particularly when rooting.
This does not flash anything, so as far as I'm aware, it will not trip KNOX but I really don't know! It DOES try to disable KNOX, which might trip it. I don't know how any of that works.
There *shouldn't* be any problems with this, but if there are, keep in mind that you made the choice to try it, knowing it's relatively untested. As of first posting of the binary, I am the only person who has tested this.
PREREQUISITES
You will need access to a computer with the following things:
Android SDK
ADB in your PATH (in platform-tools at your Android SDK install path)
Your phone's USB drivers
USB debugging enabled
INSTRUCTIONS
Connect your phone to your computer.
Close any active applications on your phone so you don't lose data when your phone reboots. If your phone just started, give it time to initialize.
Once active apps are closed, wait 10-20 seconds or so for the phone to be done doing stuff.
With that out of the way, extract the zip file if you haven't already.
The procedure will execute immediately when running the scripts, so this is your last chance to back out! Do not proceed if you don't feel ready!
Run root.cmd on Windows, or root.sh on Linux and maybe OS X.
Allow your phone to reboot after the process, and enjoy root. Let me know if you got errors or it didn't work.
This has not happened to me (or anyone else to my knowledge, since I just released this), but if it goes into a loop trying to root and keeps failing, go ahead and CTRL-C to end it, and then close the command window. If worst comes to worst, shut off your phone or pull the battery.
QUESTIONS
Q. What's the difference between this and Towelroot, then?
A. There are a few modifications to the reverse-engineered source code of Towelroot, or at least I assume that's what the code is, since Towelroot isn't open source, as far as I know. There is a github link to that source at the top of ghettoroot.c, included in the zip file. You can do a diff comparing ghettoroot.c to the github code to see exactly what I changed.
Q. And this will get me rooted, even if I have a locked bootloader?
A. Yeah. It won't unlock your bootloader, though. If you find me some info on how the previous bootloader unlocks were found and/or what they involved, I might try to look into it...
Q. You mentioned command-line options. I tried out -? or --help and saw them but it's nearly impossible to read.
A. The help is a mess, but this usage message -- to be included in a future version -- should be more...useful.
The root.sh and root.cmd scripts should pass your arguments along to the ghettoroot binary, so where you see ghettoroot in the usage message, replace with ./root.sh (be sure to chmod +x it) or root.cmd.
Code:
Usage: ghettoroot METHOD ALIGN LIMIT_OFFSET HIT_IOV EXCLUDE_FEATURE
USERCMD USERARGV
All parameters are optional. The first non-number and following arguments
will be interpreted as the user command and user arguments.
ex. ghettoroot <-- runs with defaults, attempting to detect some settings
ghettoroot 0 1 0 4 0 <-- standard, default root for most phones.
ghettoroot mkdir /system/happyface <-- does everything, then that...
ghettoroot 0 1 0 4 7 cp /sdcard/build.prop /system/build.prop
^ copies a modified build.prop but does not permaroot, etc.
Formatting key: [Default value]PARAMETER NAME: value range: description
[0]METHOD: 0-sendmmsg, 1-recvmmsg, 2-sendmsg, 3-recvmsg:
This typically does not need to be changed.
[1]ALIGN: 0/1: attack all 8 IOVs hit with MAGIC
This behavior may/may not match up with original ALIGN behavior.
Currently, enabling this causes HIT_IOV to go unused.
[0]LIMIT_OFFSET: 0-8192: offset of addr_limit in thread_info, multiple of 4
If desperate, download manufacturer's kernel sources to check headers.
Rarely necessary, but 7380 is needed for newer Samsung phone models.
[4]HIT_IOV: 0-7: offset to rt_waiter in vulnerable futex_wait_requeue_pi.
see vulnerable futex_wait_requeue_pi function for your kernel if needed.
[0]EXCLUDE_FEATURE: 0-31: all features are enabled by default.
to disable, add up the numbers for any/all of the following features:
1 Install SuperSU
2 Disable Knox
4 Disable OTA Updates
8 SEAndroid Permissive (temporary)
16 Mount /, /system read-write (temporary)
Example values for EXCLUDE_FEATURE:
31 temp roots solely to run a user command, immediately after root.
Reboot is still required.
6 does *not* disable Knox or OTA, but installs SuperSU.
7 does *not* disable Knox or OTA updates, or install SuperSU.
Still remounts /, /system as rewrite and turns off SEAndroid.
Meant to be used with a user command, or else it is pointless.
USERCMD: Command to be run after all other enabled featuers, if any.
USERARGV: All further arguments are passed along to the user command.
I don't know how well any of those arguments are working. You shouldn't need any of them for this phone.
Q. I think ToiletRoot would have been a better name.
A. Hmm... Me too. Oh well.
CREDITS
GeoHot, developer of Towelroot, on which this is based, and without whom it would be impossible.
Chainfire, developer of SuperSU, which is bundled.
Somebody, developer/compiler of busybox, which is bundled. To be honest I don't know where it came from. It was lying around on my PC. I know, I know... just let me know if I really need to make my life revolve around fixing political issues like this and I will try.
fi01, person on Github sharing code publicly
Apologies in advance for some kind of faux pas I've made or rule I've broken. There always seems to be something(s).
Click to expand...
Click to collapse
Where did you pick this up at? I want to go ahead and rewrite it to be more efficient later tonight, but I kind of need to know where it came from?
---------- Post added at 10:39 PM ---------- Previous post was at 10:38 PM ----------
Oh well, screw it... I'll go ahead and clean it up later.
NetworkingPro said:
Glad I could help, I went ahead and read through the source code before I did it, so had a pretty good idea of what it was doing.
---------- Post added at 10:38 PM ---------- Previous post was at 10:36 PM ----------
Where did you pick this up at? I want to go ahead and rewrite it to be more efficient later tonight, but I kind of need to know where it came from?
---------- Post added at 10:39 PM ---------- Previous post was at 10:38 PM ----------
Oh well, screw it... I'll go ahead and clean it up later.
Click to expand...
Click to collapse
It is the first link at the top of ghettoroot.c, fi01's cube-towel.c page. (Every page linked in ghettoroot.c was helpful.)
I am planning to clean it up a bit myself this evening, but if someone wants to repackage the entire thing and re-post to a new thread, go for it! Or you can wait until I clean things up a little bit and then do it... Or just not. Whatever you want to do. I'm not very concerned about who gets credit for what, though a mention of my randomly-generated name might be nice.
Thanks to those who've helped others so far, and those who've shared success/failure.
EDIT: Wanted to point out that there were very few changes from fi01's original cube-towel.c code that were necessary to get the exploit itself to work. The rest is fluffy stuff, in addition to execution of useful commands once root was gained rather than being a proof-of-concept alone.
Here is *exactly* what was changed in the exploit code. Very minimal, you will see.
Setting of processor affinity added as recommended at tinyhack.com's "Exploiting the Futex Bug and uncovering Towelroot" post, and called in main():
Code:
void setaffinity()
{
pid_t pid = syscall(__NR_getpid);
int mask=1;
int syscallres = syscall(__NR_sched_setaffinity, pid, sizeof(mask), &mask);
if (syscallres)
{
printf("Error in the syscall setaffinity: mask=%d=0x%x err=%d=0x%x", mask, mask, errno, errno);
sleep(2);
printf("This could be bad, but what the heck... We'll try continuing anyway.");
sleep(2);
}
}
Change to IOV code, also using tinyhack.com recommendations:
From:
Code:
if (ph->l2 == 0) {
for (i = 0; i < 8; i++) {
msg_iov[i].iov_base = (void *)MAGIC;
msg_iov[i].iov_len = MAGIC_ALT;
}
}
else {
for (i = 0; i < 8; i++) {
msg_iov[i].iov_base = (void *)MAGIC;
msg_iov[i].iov_len = 0x10;
}
}
To:
Code:
// tbh i'm not really sure how this is supposed to look or work
// but it is working with note 2 as is with modstring 0 1 0 4
// and that is all i care about right now.
// see http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
for (i = 0; i < 8; i++) {
iov[i].iov_base = (void *)MAGIC;
if (ph->align == 0) {
if (i==ph->hit_iov) {
iov[i].iov_len = MAGIC_ALT;
}
else {
iov[i].iov_len = 0x10;
}
}
else {
iov[i].iov_len = MAGIC_ALT;
}
}
When searching through task structures for a credential to overwrite (to get us root), verify that the credential is in kernel address space, the same way the other pointers are verified. Otherwise, we're not in the right place in memory yet...
From:
Code:
if (task->cpu_timers[0].next == task->cpu_timers[0].prev && (unsigned long)task->cpu_timers[0].next > KERNEL_START
&& task->cpu_timers[1].next == task->cpu_timers[1].prev && (unsigned long)task->cpu_timers[1].next > KERNEL_START
&& task->cpu_timers[2].next == task->cpu_timers[2].prev && (unsigned long)task->cpu_timers[2].next > KERNEL_START
&& task->real_cred == task->cred) {
To:
Code:
if (task->cpu_timers[0].next == task->cpu_timers[0].prev && (unsigned long)task->cpu_timers[0].next > KERNEL_START
&& task->cpu_timers[1].next == task->cpu_timers[1].prev && (unsigned long)task->cpu_timers[1].next > KERNEL_START
&& task->cpu_timers[2].next == task->cpu_timers[2].prev && (unsigned long)task->cpu_timers[2].next > KERNEL_START
&& task->real_cred == task->cred && (unsigned long)task->cred > KERNEL_START) {
That's all that needed to be changed, keeping in mind none of us have seen the actual towelroot source code so some of these things may not even be necessary or may already be present there, leaving it up in the air why towelroot doesn't work for us. I would guess the IOVs were the issue, somehow, but at least with this code, the credential needed to be checked to be in kernel space as well. Did not test without setaffinity.
Droc1983 said:
I still don't have root. Not sure what went wrong. My phone restarted like it was supposed to but not root.
Click to expand...
Click to collapse
I had to Uninstall towel root apk. Now I have root access. Thank you.
My apologies...
alkitchen said:
I am getting, "error: device unauthorized. Please check the confirmation dialog on your device." I am not getting anything on my phone. Any thoughts?
Click to expand...
Click to collapse
My apologies, disregard my post... I ran it again this evening and it WORKED!! Thanks so much.
Now to try Safestrap...
25yvdgpo06 said:
It is the first link at the top of ghettoroot.c, fi01's cube-towel.c page. (Every page linked in ghettoroot.c was helpful.)
I am planning to clean it up a bit myself this evening, but if someone wants to repackage the entire thing and re-post to a new thread, go for it! Or you can wait until I clean things up a little bit and then do it... Or just not. Whatever you want to do. I'm not very concerned about who gets credit for what, though a mention of my randomly-generated name might be nice.
Thanks to those who've helped others so far, and those who've shared success/failure.
EDIT: Wanted to point out that there were very few changes from fi01's original cube-towel.c code that were necessary to get the exploit itself to work. The rest is fluffy stuff, in addition to execution of useful commands once root was gained rather than being a proof-of-concept alone.
Here is *exactly* what was changed in the exploit code. Very minimal, you will see.
Setting of processor affinity added as recommended at tinyhack.com's "Exploiting the Futex Bug and uncovering Towelroot" post, and called in main():
Code:
void setaffinity()
{
pid_t pid = syscall(__NR_getpid);
int mask=1;
int syscallres = syscall(__NR_sched_setaffinity, pid, sizeof(mask), &mask);
if (syscallres)
{
printf("Error in the syscall setaffinity: mask=%d=0x%x err=%d=0x%x", mask, mask, errno, errno);
sleep(2);
printf("This could be bad, but what the heck... We'll try continuing anyway.");
sleep(2);
}
}
Change to IOV code, also using tinyhack.com recommendations:
From:
Code:
if (ph->l2 == 0) {
for (i = 0; i < 8; i++) {
msg_iov[i].iov_base = (void *)MAGIC;
msg_iov[i].iov_len = MAGIC_ALT;
}
}
else {
for (i = 0; i < 8; i++) {
msg_iov[i].iov_base = (void *)MAGIC;
msg_iov[i].iov_len = 0x10;
}
}
To:
Code:
// tbh i'm not really sure how this is supposed to look or work
// but it is working with note 2 as is with modstring 0 1 0 4
// and that is all i care about right now.
// see http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
for (i = 0; i < 8; i++) {
iov[i].iov_base = (void *)MAGIC;
if (ph->align == 0) {
if (i==ph->hit_iov) {
iov[i].iov_len = MAGIC_ALT;
}
else {
iov[i].iov_len = 0x10;
}
}
else {
iov[i].iov_len = MAGIC_ALT;
}
}
When searching through task structures for a credential to overwrite (to get us root), verify that the credential is in kernel address space, the same way the other pointers are verified. Otherwise, we're not in the right place in memory yet...
From:
Code:
if (task->cpu_timers[0].next == task->cpu_timers[0].prev && (unsigned long)task->cpu_timers[0].next > KERNEL_START
&& task->cpu_timers[1].next == task->cpu_timers[1].prev && (unsigned long)task->cpu_timers[1].next > KERNEL_START
&& task->cpu_timers[2].next == task->cpu_timers[2].prev && (unsigned long)task->cpu_timers[2].next > KERNEL_START
&& task->real_cred == task->cred) {
To:
Code:
if (task->cpu_timers[0].next == task->cpu_timers[0].prev && (unsigned long)task->cpu_timers[0].next > KERNEL_START
&& task->cpu_timers[1].next == task->cpu_timers[1].prev && (unsigned long)task->cpu_timers[1].next > KERNEL_START
&& task->cpu_timers[2].next == task->cpu_timers[2].prev && (unsigned long)task->cpu_timers[2].next > KERNEL_START
&& task->real_cred == task->cred && (unsigned long)task->cred > KERNEL_START) {
That's all that needed to be changed, keeping in mind none of us have seen the actual towelroot source code so some of these things may not even be necessary or may already be present there, leaving it up in the air why towelroot doesn't work for us. I would guess the IOVs were the issue, somehow, but at least with this code, the credential needed to be checked to be in kernel space as well. Did not test without setaffinity.
Click to expand...
Click to collapse
I'll wait til you clean it up and then repackage. I don't care about credit either. I'll pm you my gtalk shortly.
I would like to try this. I have downloaded the SDK, however I do not have any idea what the ADB step means. Basically, I have no idea what I am doing and would appreciate a little help as far as making sure I have everything that needs downloaded. Thanks.
edit: Got it figured out!
Having trouble with safestrap. I installed apk and ran install recovery and grant root access but it says recovery not installed in the app.
Not working...
I'm seeing:
Unable to chmod /data/local/tmp/busybox: no such file or directory
sh: /data/local/tmp/busybox: not found
Could not find/unzip SuperSU: Success
Please place an UPDATE-SU-*.zip file in the mail folder before running the install script
Click to expand...
Click to collapse
Any help would be appreciated.

SELinux Policy to allow System Applications to use iptables

I am trying to build a custom ROM for Android that has a built in firewall. In doing this I want to allow my Settings app to block different apps from using mobile data and/or wifi.
My approach so far has been to add new selinux policy rules to allow system level apps to interact with iptables. I have tried multiple different policies, but here is what I currently have.
file_contexts
Code:
/system/bin/iptables u:object_r:iptables_exec:s0
system_app.te
Code:
type iptables_exec;
allow system_app iptables_exec:file { rx_file_perms };
I didn't define a new "domain" for iptables and I wasn't sure if I needed to declare the system_app domain again, or if this would just be appended to that.
Thanks in advance for any help. If anyone has any pointers on where to look to get a better understanding of SELinux inside of android, please let me know.

Selinux contexts on unlabeled target in cm-12.1

Hi all I am working on a port of cyanogenmod 12.1 for the Huawei y6 and would like some advice.
It seems that when /mnt/shell/emulated is created it is not labeled with any selinux context and it then switches to fuse context after being mounted.
When booting in permissive mode this poses no problems however when booting in enforcing mode I was getting avc denied for the sdcardd domain trying to unmount and mounton for an unlabeled context which then results in an infinte boot because zygote refuses to start without emulated storage.
I worked around this by adding a seunion in my boardconfig with the following.
Code:
allow sdcardd unlabeled:dir mounton;
allow sdcardd unlabeled:filesystem { mount unmount };
My concern is if this would result in any security flaws or issues, the worst I can think of is if a process runs as sdcardd and mounts a filesystem containing malicous code that it can then execute. However this would appear to be only able to happen with root access in the first place which would negate the need to exploit it in the first place.
Can I please have some thoughts on if it is a potential risk and also if so how can I safely resolve the mount on boot issue.
Thanks in advance guys.

Categories

Resources