This is a flashable zip that enables init.d scripts to run depending on the root method you have installed.
To uninstall, just flash the zip again and it'll restore everything to how it was before
If magisk:
Boot scripts will be installed that will run all exectuable scripts in init.d as post-fs-data except any that end in '-ls' which will be run as late start. Also note that if you're trying to create the init.d folder, the original directory when using magisk is actually /sbin/.core/mirror/system/etc. It goes without saying that this could break safetynet (honestly though, just copy your script to /sbin/.core/img/.core/service.d or post-fs-data.d instead and set permissions to 0755 rather than creating an init.d directory - using the in-house magisk solution is always the better option. Magisk users have almost no reason to create an init.d directory)
The rest of this is for non-magisk/supersu installs
Otherwise: the boot img and part of the system will be modified to enable init.d support.
What it does:
Search for sysinit in any rc file. If found and seclabel is intact and equal to target seclabel for my init rc script, then that seclabel will be set to permissive in sepolicy if needbe instead of using my solution
If sysinit with seclabel isn't found, a custom rc file and system/bin/script file will be installed and sepolicy will be patched accordingly to add init.d support. Init.d scripts will be run the same way as with magisk installs above
Adds magiskpolicy to sbin. It's more up to date and complete than setools so why not?
If there is an error on unpacking your boot image, check the binary inclusion section here to see if your device needs one: https://github.com/osm0sis/AnyKernel3#-binary-inclusion
If it does, place it in addon/AnyKernel3/tools/arm (or x86 - whichever your architecture is - probably arm)
I am not responsible for any oddities that happen to your device because of this, use common sense. For example, if you know your device has a weird boot img, check first.
BACKUP BOOT AND SYSTEM PARTITIONS BEFORE FLASHING
Compatibility: Any device magisk is compatible with
Confirmed working (boot img method):
Nexus 5x
Verizon LG G2
Oneplus 3/3T
Oneplus 5T
Nexus 9
Redmi Note
Zuk Edge
Axon 7 (A2017U)
Nexus 5
SM-N900T
SM-T350
LeEco Pro 3
Confirm your device works and I'll add it to the list!
Special thanks to: @osm0sis, @CosmicDan, @Ricky Divjakovski, @JustArchi
Source: https://github.com/Zackptg5/Init.d-Injector
Download
Good stuff :good:
Good idea with the removal of other/old init.d capabilities. It's annoying that so many ROM's/kernels claim to have init.d but they're fake or hacky (well, I guess the sepolicy injection is pretty hacky too lol). You might also want to consider looking for install-recovery hijack method of init.d and disabling that too - shouldn't be too hard, just check if the file exists in known locations and grep for init.d. The harder part though is what to actually *do* if found - probably best to comment-out the line that contains "run-parts" and/or "init.d" rather than erase the whole file.
CosmicDan said:
Good stuff :good:
Good idea with the removal of other/old init.d capabilities. It's annoying that so many ROM's/kernels claim to have init.d but they're fake or hacky (well, I guess the sepolicy injection is pretty hacky too lol). You might also want to consider looking for install-recovery hijack method of init.d and disabling that too - shouldn't be too hard, just check if the file exists in known locations and grep for init.d. The harder part though is what to actually *do* if found - probably best to comment-out the line that contains "run-parts" and/or "init.d" rather than erase the whole file.
Click to expand...
Click to collapse
Good idea, I'll look into that. Thanks!
Will try this soon on Honor 8 Pro and report back.
Quick update to v1.1
Just bought a used nexus 9 and found that the boot partition layout for it and other nvidia tegra devices is different from typical android devices. So I added support for nvidia tegra devices
So github screwed with my EOL again and converted a few of the files to windows eol which broke everything. I just fixed it and reuploaded v1.1 with the fixes so just redownload it and flash away. Thanks to @dmgZero for finding the issue
Just updated to v1.2. I added support for pixels and nexus5x/6p avb-signing. I haven't been able to test it out myself as my bullhead doesn't even need signing to work so any feedback would be great. Also updated the OP on how to modify this for any weird boot imgs you may have
Edit: No point in spamming the thread with another post: updated to v1.3. Just adds capability to remove any init.d stuff present from install-recovery.sh. Thanks to @CosmicDan for pointing it out
Works fine on Redmi Note (a MediaTek Helio X20 device) running MIUI 9 (Android 6.0).
One tiny detail, maybe just do an mkdir /system/etc/init.d after the patch succeeds, if it doesn't already exist. I could imagine that some other zips could check for the existence of this folder for a simple way to determine if init.d is supported.
CosmicDan said:
Works fine on Redmi Note (a MediaTek Helio X20 device) running MIUI 9 (Android 6.0).
One tiny detail, maybe just do an mkdir /system/etc/init.d after the patch succeeds, if it doesn't already exist. I could imagine that some other zips could check for the existence of this folder for a simple way to determine if init.d is supported.
Click to expand...
Click to collapse
Sweet, I already have that in the sysinit script but it would make more sense to move that to the installer so I'll put that into the next version. Thanks!
Is that supposed to work systemlessly?
You should probably add Samsung to the weird/hexed/Satan kernels. Tried flashing your zip and recovery came back with Invalid Partition upon failure, my device is a Galaxy Note 5 running RR 7.1.2. I do love the idea and your work though bro. Thanks.
Metabolic12 said:
You should probably add Samsung to the weird/hexed/Satan kernels. Tried flashing your zip and recovery came back with Invalid Partition upon failure, my device is a Galaxy Note 5 running RR 7.1.2. I do love the idea and your work though bro. Thanks.
Click to expand...
Click to collapse
I tried to originally but it was basically impossible to detect all bootimg types and they need extract binaries which if I included them all, would make the zip over 70mb. I updated the op a few days ago with instructions on how to add support for weird boot imgs (it's basically adding a few files to the zip)
I completely understand, I wasn't gonna ask you to include my kernel regardless that's rather selfish, and I did follow your guide in the OP to get it to work. I was just suggesting maybe add Samsung kernels next to LG in your OP. Great work bro, thank you.
Zackptg5 said:
I tried to originally but it was basically impossible to detect all bootimg types and they need extract binaries which if I included them all, would make the zip over 70mb. I updated the op a few days ago with instructions on how to add support for weird boot imgs (it's basically adding a few files to the zip)
Click to expand...
Click to collapse
---------- Post added at 02:58 AM ---------- Previous post was at 02:51 AM ----------
I'm a retard, I read the OP wrong earlier. Disregard the adding Samsung part ha.
Zackptg5 said:
I tried to originally but it was basically impossible to detect all bootimg types and they need extract binaries which if I included them all, would make the zip over 70mb. I updated the op a few days ago with instructions on how to add support for weird boot imgs (it's basically adding a few files to the zip)
Click to expand...
Click to collapse
sscheib01 said:
Is that supposed to work systemlessly?
Click to expand...
Click to collapse
The boot img is not part of the system partition so that's systemless. However, it installs an addon.d script and modifies the sysinit and install_recovery files if present which are on the system. It won't break safetynet if that's what you're wondering
Zackptg5 said:
The boot img is not part of the system partition so that's systemless. However, it installs an addon.d script and modifies the sysinit and install_recovery files if present which are on the system. It won't break safetynet if that's what you're wondering
Click to expand...
Click to collapse
I thought *any* System modification trips the Safety net?
I use the Universal Safetynet Bypass module for Magisk so it doesn't bother me, but curious.
Sent from my Redmi Note 4 using Tapatalk
CosmicDan said:
I thought *any* System modification trips the Safety net?
I use the Universal Safetynet Bypass module for Magisk so it doesn't bother me, but curious.
Sent from my Redmi Note 4 using Tapatalk
Click to expand...
Click to collapse
That's what I thought initially too but I've found lots of system modifications doesn't break safetynet such as editing the hosts file. Modifications to the zygote such as xposed framework for sure break safetynet but I'm not sure exactly which system modifications would. Other than testing them myself, I'm not really sure what would break it. I've found that you can completely alter parts of the system like with arise sound systems which adds a whole slew of libs and other modifications and safetynet still won't break (I found through my work there that having the system mounted as rw via a boot script will trigger safetynet but you can even go so far as to mount it as rw, make your changes, and then remount it as ro before boot completes and safetynet will still pass). It's weird man
Zackptg5 said:
That's what I thought initially too but I've found lots of system modifications doesn't break safetynet such as editing the hosts file. Modifications to the zygote such as xposed framework for sure break safetynet but I'm not sure exactly which system modifications would. Other than testing them myself, I'm not really sure what would break it. I've found that you can completely alter parts of the system like with arise sound systems which adds a whole slew of libs and other modifications and safetynet still won't break (I found through my work there that having the system mounted as rw via a boot script will trigger safetynet but you can even go so far as to mount it as rw, make your changes, and then remount it as ro before boot completes and safetynet will still pass). It's weird man
Click to expand...
Click to collapse
Kind of makes sense actually.
Hosts is in etc right, nothing in there is executable. So I imagine any changes to etc won't trip it because nothing in there would mess with device security. Sound mods... Well yeah they ADD libs but they don't replace any do they? They just add sound filters through the mixer configs in etc.
So I guess it makes sense. Sysinit is just added to xbin or whatever and I guess that doesn't trip it. But if you replaced, say, dex2oat with a proxy script to intercept oat generation, then it would definitely trip it.
Sent from my Redmi Note 4 using Tapatalk
Is it really needed??
I want to flash Dolby Atmos for Redmi Note 4, but init.d support is needed as mentioned by developer.
I tried Dolby Atmos without it sound is loud and great
I can't understand, why init.d is still needed?
Can anyone explain here?
amit.tiger12 said:
Is it really needed??
I want to flash Dolby Atmos for Redmi Note 4, but init.d support is needed as mentioned by developer.
I tried Dolby Atmos without it sound is loud and great
I can't understand, why init.d is still needed?
Can anyone explain here?
Click to expand...
Click to collapse
If it's working, then you don't need it or already have it. Init.d support is needed for Dolby if you are not using magisk or supersu and you have selinux set to enforcing
Zackptg5 said:
If it's working, then you don't need it or already have it. Init.d support is needed for Dolby if you are not using magisk or supersu and you have selinux set to enforcing
Click to expand...
Click to collapse
That's with respect to Dolby, what does it provide as a general point of view? What is it's significance?
Explain if you've enough time or just throw a link, it will help out.
Related
Hi there
I got droidwall running on the SGY.
Please first read the whole post. I add changes at the end of it.
Here's what I did:
1. follow this great tut from irfanbagus. Thanks a lot irfanbagus!
2. After running "make bcm21553_totoro_05_defconfig", set this in .config:
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_NETFILTER_XT_MATCH_OWNER=y
and continue irfanbagus's steps
3. Install the new boot.img, e.g. via mai77's method as shown here
4. Profit! (as in: use droidwall )
Notes:
Alternatively the changes in .config could be set in cm21553_totoro_05_defconfig or via make menuconfig
If you don't have your boot.img as a normal file, run this in adb, then pull the file:
dd if=/dev/block/bml7 of=/data/local/boot.img
I was surprised that there was no such modified kernel till now. Maybe this is because the TARGET_REJECT option is essential but only XT_MATCH_OWNER is largely discussed when dealing with droidwall.
See attachment (mikstev_SGY_Kernel_netfilter_for_droidwall_boot.img.zip) for a boot.img with only these modifications.
Please test and report. I only tested blacklist/whitelist mode with Google Play blocked/allowed on Wifi connection, but it worked.
Edit 1: I've added the necessary (and probably some more) modules so that droidwall's logging works. Use the second attached file instead the first one.
Here are the changes I made, compared to normal .config:
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NETFILTER_XT_MATCH_OWNER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
I guess the first two aren't necessary but I didn't bother to check every single module if it's the correct one which droidwall needs for logging. However this shouldn't matter anyway. See mikstev_SGY_Kernel_netfilter_for_droidwall_with_log_boot.img.zip
Edit 2: Due to request I've added init.d support to the latest release. Thanks irfanbagus! See mikstev_SGY_Kernel_droidwall_initd_boot.img.zip
Edit 2.5: Seems only the following modules are required but that only as a side note:
CONFIG_NETFILTER_XT_MATCH_OWNER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
Edit 3: New method for adding init.d support to a (newest) boot.img, with kernel modules for droidwall (+logging) and init.d scripts to load these modules. Please read the readme, if you have questions, post here. Special thanks to irfanbagus See mikstev_add_initd_to_boot.img__kernel_modules_initd_scripts_for_droidwall.zip
Edit 4: Thanks to an idea by irfanbagus and another tutorial to include init.d support by kurotsugi, here's another release. Adding init.d support is now easier with kurotsugi's method plus there's a update.zip (modules_droidwall_signed.zip) which does the other steps for you (copying the modules, init.d scripts and applying the correct permissions for these files). NOTE: this update.zip is yet untested. If you test it please report. See mikstev_add_initd_to_boot.img__kernel_modules_initd_scripts_for_droidwall_v2.zip
Edit 5: The update.zip from edit 4 seems to work. If you're using a kernel with init.d support you only need to install the update.zip and it should work fine.
good job. i know droidwall depend on other kernel features beside CONFIG_NETFILTER_XT_MATCH_OWNER. since i don't have plan to use droidwall, i don't bother to find it.
Profit indeed! It works! Good job, mikstev! I was able to block dolphin HD on my phone just to test if it works and it did, much to my delight!
And to irfanbagus as well for that wonderful guide on how to compile a kernel.
Great job, guys!
Now let's hope that all the other kernel developers include this small bit of configuration in their builts
finally! ive been waiting for this for ages. thank you very muchhhh!
Sent from my GT-S5360 using xda premium
Logging doesn't work yet. I'll try the solution from highlandsun: http://forum.xda-developers.com/showpost.php?p=11110889&postcount=357 tonight and upload new kernel if successful.
No need for so much hassel
Just use "lbe privacy guard" (free in store) it has much more features than droidwall and it doesnt require any special kind of kernel.
Y u no press "thanks"!?
Sent from my GT-S5360 using XDA
Ok, logging works now, I'll upload the new kernel. See first post.
devilrulz4ever said:
No need for so much hassel
Just use "lbe privacy guard" (free in store) it has much more features than droidwall and it doesnt require any special kind of kernel.
Y u no press "thanks"!?
Sent from my GT-S5360 using XDA
Click to expand...
Click to collapse
It seems that there're at least some people who see this differently. Here're some of my reasons, why I prefer droidwall over LBE Privacy Guard:
- it's a good and easy to use firewall. Not more, nor less. That's what I want.
- no "hassel" (to use your words) with resticting internet access of "trusted" apps
- I did not find a way in LBE to block LBE from using internet. In the iptables rules created by Droidwall I can clearly see that droidwall is not allowed = blocked
@mikstev: I'm just curious...is it based on sgy's newest kernel?
I think so, the source code is the one mentioned in irfanbagus' post (update2) which I linked above.
nice...I can integrate dualboot and data-2sd mod into this kernel easily. thx
i got other option to make droidwall work.
on init.rc i added this line:
service netfilter /system/bin/iptables
disabled
oneshot
this also work with avast firewall..
gear12 said:
i got other option to make droidwall work.
on init.rc i added this line:
service netfilter /system/bin/iptables
disabled
oneshot
this also work with avast firewall..
Click to expand...
Click to collapse
Can anyone confirm this? I can't see how this could replace the missing kernel modules.
mikstev said:
Can anyone confirm this? I can't see how this could replace the missing kernel modules.
Click to expand...
Click to collapse
nope. iptables only a user space application that depend on kernel features. and you can't call iptables without command/params.
the firewall works great, also, I can see the logs but after disconnecting from the internet and a few minutes the log is empty again, is this normal or a bug?
off topic:
and can I make a request? can you make the your boot.img support init.d as well? please...
Adam_Blade said:
the firewall works great, also, I can see the logs but after disconnecting from the internet and a few minutes the log is empty again, is this normal or a bug?
Click to expand...
Click to collapse
Yep, I noticed this too. The droidwall source seems ok at first glance and I don't think it's related to the netfilter modules etc. My guess would be that it's dmesg's fault, maybe the log is truncated or something but this is just speculation. I'll investigate in this in a few days. Maybe someone else knows why this happens?
Adam_Blade said:
and can I make a request? can you make the your boot.img support init.d as well? please...
Click to expand...
Click to collapse
Sorry, I currently don't have the necessary skills, so if you're looking for a quick solution you might better ask someone else for help. (Especially since there're already kernels with this feature and including the modifications for netfilter/droidwall should be trivial). However as I wanted to build up my knowledge regarding android/kernel development anyway, I'll try to add this feature one time, but that surely would take >1 week.
Regarding dmesg: the buffer size is set by CONFIG_LOG_BUF_SHIFT=19 which means 2^19 Bytes = 512KiB. I'll check later if this relatively huge size is really used up.
@mikstev: make init.d support kernel is easy. we only have to add a few script inside init.rc file. we can do it easily by using dsixda's kitchen or put the script manually. you can see my modified init.rc here http://www.mediafire.com/?cc1kg8s7cx27onb
I believe the script that have to be added is
service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
disabled
oneshot
Just to get sure: the init.rc which needs to be modified is the one in the initial ramdisk and not in the kernel (zImage), right?
Hi guys!
As some of you must have noticed, latest Samsung GT-I9500 firmwares carry a kernel configuration supposed to prevent SETUID privilege elevation.
Stock unmodified firmware with root is my preferred setup but also a strong dependency for all my development, for me this change is a massive setback if not a dealbreaker.
While poking around I found in about an hour something weird that reveled being a vulnerability, so I created a little thing to make it useful for now.
README:
Stupid SU: Galaxy S4 root helper by François SIMOND aka @supercurio
Circumvent an extremely weak false-security "Anti Root" mechanism implemented
on latest Samsung Galaxy S4 devices (on both Exynos and Qualcomm versions)
Preventing proper root function on official firmware breaks all my Voodoo apps
requiring stock+root and is a move that's hostile to both users and developers.
Samsung security might be embarassed by this proof of concept, as it defeats
their mechanism in a single line... not even with complex ARM assembler
but *one* line of shell script.
However, the goal here is to show Superuser solutions developers how to
deal with those devices for now, and provide a working solution to people who
bought a Galaxy S4 expecting to root it cleanly and easily but cannot.
This proof of concept is slightly slowing down Superuser calls, but its
"plain text" implementation has the merit of showing how stupid this exploit is.
SELinux configuration stays unmodified and active.
Features:
- Detect and supports both SuperSU and Koush's Superuser
- Installs Super SU binary by default
Make sure you have one of those Superuser apps installed:
- https://play.google.com/store/apps/details?id=com.koushikdutta.superuser
- https://play.google.com/store/apps/details?id=eu.chainfire.supersu
Root feature doesn't rely on a "StupidSU kernel" which is only an installer.
Feel free to flash back Samsung's original boot.img from their official firmware
after booting at least once.
Important Note:
This "exploit" is so lame that it will be fixed in no time, making updated S4
a pain to root again.
I wish Samsung will reconsider their "Anti Root" approach, which is damageable
in every regard and defective by design as demonstrated here.
Also, I'm simply not interested developing for and promoting devices from
manufacturers hostile to developers: It's just a waste of valuable time.
Click to expand...
Click to collapse
INSTALL
1/ copy rooting/ directory in your initramfs
Make sure "root.sh" file is has an executable permission (chmod 744 recommended)
2/ Add those lines at init.universal5410.rc end:
# Stupid SU
service rooting /stupidsu/root.sh
class main
user root
group root
oneshot
3/ Assemble your initramfs with the associated Samsung official kernel binary
of choice in a regular boot image
4/ flash as boot.img
5/ At each boot, Superuser app are detected automatically and su binary adjusted
accordingly.
Click to expand...
Click to collapse
Source code
On GitHub
License
Kernels downloads, only for demo purposes of the concept, you can flash back original Samsung boot.img once rooted
GT-I9500 Stock + root StupidSU v4 UBUAMDE
GT-I9500 Stock + root StupidSU v4 XXUAMDK
GT-I9500 Stock + root StupidSU v4 XXUAME1
What's next
Owners of Qualcomm Galaxy S 4 devices experiencing the same dificulties with Samsung the anti root strategy might want to try this method, please let me know if you're ready for some experimentations.
Supercurio pleas add thraed t General section i think ther well bee lots of testers for i9505.thx for suport
Sent from my LG-P500 using xda app-developers app
Going to try this on latest LE1 stock kernel now .....thread is in correct section
edit: did not work on LE1 kernel. I will try once again. DId any one tried the MDK kernel..I am having again the problem with SU binaries installation..
Edit: Thanks bro. working on ME1 kernel now. Did mistake while doing tar. Appreciate it! Root is working fine but cant update the binaries of Supersu, still the root works fine.
Here comes the master welcome to SGS4 development forum mate.. (rahulzeven from twitter here )
So the BEST thing's just happened?!:laugh::good:
i repacked the kernel of Samsung-Updates.com-KERNEL-GT-I9500-XSE-I9500XXUAME1-1367637350 using supercurio method. Root works fine. All we need to is install it from ODIN and dont update the binaries of supersu.
Download Link
Edit: New file uploaded
grgsiocl said:
i repacked the kernel of Samsung-Updates.com-KERNEL-GT-I9500-XSE-I9500XXUAME1-1367637350 using supercurio method. Root works fine. All we need to is install it from ODIN and dont update the binaries of supersu.
Download Link
Click to expand...
Click to collapse
Thanks fo much! Will Titanium Backup work on this kernel?
Hope chainfire will start working on mobileOdin soon. So much easier to flash than.
... tapat*lked
GSeeker said:
Thanks fo much! Will Titanium Backup work on this kernel?
Click to expand...
Click to collapse
wrong file uploaded. Please download the same in 5 minutes. Uploading is on and the kernel date should be MAY 04
---------- Post added at 12:33 PM ---------- Previous post was at 12:28 PM ----------
GSeeker said:
Thanks fo much! Will Titanium Backup work on this kernel?
Click to expand...
Click to collapse
it should work as i dont use titanium backup and instead i use gobackup pro and it works fine anyway
MDK from OP working good, thanks
grgsiocl said:
i repacked the kernel of Samsung-Updates.com-KERNEL-GT-I9500-XSE-I9500XXUAME1-1367637350 using supercurio method. Root works fine. All we need to is install it from ODIN and dont update the binaries of supersu.
Download Link
Edit: New file uploaded
Click to expand...
Click to collapse
I'm trying to repack the kernel of korean gs4,
but I am a noob in kernel devs.
I can edit ramdisc, but fist trying in initramfs, zImage.
Is rooting directory means both root.sh and files(folder)?
and paste them on first class route?
hope you give some advices.. thanks
aslak89 said:
I'm trying to repack the kernel of korean gs4,
but I am a noob in kernel devs.
I can edit ramdisc, but fist trying in initramfs, zImage.
Is rooting directory means both root.sh and files(folder)?
and paste them on first class route?
hope you give some advices.. thanks
Click to expand...
Click to collapse
when you unpack the kernel you will have two folders one is ramdisk and other one is split_img (zimage). You need to copy the folder stupidsu folder in ramdisk and modify the init.universal5410.rc as per OP stated and repack the image
grgsiocl said:
when you unpack the kernel you will have two folders one is ramdisk and other one is split_img (zimage). You need to copy the folder stupidsu folder in ramdisk and modify the init.universal5410.rc as per OP stated and repack the image
Click to expand...
Click to collapse
then, is not necessary to recompile zImage?
ok I m going to try it right now, thank you grgsiocl
muhamet said:
Supercurio pleas add thraed t General section i think ther well bee lots of testers for i9505.thx for suport
Click to expand...
Click to collapse
Yes in fact I was hesitating, but as soon as someone is ready to assist me to try on a Qualcomm device (I9505 or T-Mobile Galaxy S4) I'll make a thread here too.
grgsiocl said:
Going to try this on latest LE1 stock kernel now .....thread is in correct section
edit: did not work on LE1 kernel. I will try once again. DId any one tried the MDK kernel..I am having again the problem with SU binaries installation..
Edit: Thanks bro. working on ME1 kernel now. Did mistake while doing tar. Appreciate it! Root is working fine but cant update the binaries of Supersu, still the root works fine.
Click to expand...
Click to collapse
Great then
aslak89 said:
then, is not necessary to recompile zImage?
ok I m going to try it right now, thank you grgsiocl
Click to expand...
Click to collapse
The point here is to have stock (unmodified Samsung binary) kernel running, with associated modules and no other modification.
Which gives you several usage options:
keep the StupidSU stock+root kernel (same kernel binary, same kernel modules, only very slightly initramfs scripts) that will auto-root depending on which Superuser APK you installed
you can flash back the official kernel and still enjoy root the same.
supercurio said:
The point here is to have stock (unmodified Samsung binary) kernel running, with associated modules and no other modification.
Which gives you several usage options:
keep the StupidSU stock+root kernel (same kernel binary, same kernel modules, only very slightly initramfs scripts) that will auto-root depending on which Superuser APK you installed
you can flash back the official kernel and still enjoy root the same.
Click to expand...
Click to collapse
Thank you for awsering
then I repacked my kernel but still not work.
copyed stupidsu and edited init.universal5410.rc in ramdisk and repacked boot.img.
I guess permission is the thing,
attach my shots
hope you loot at once.
Sent from my SHV-E300S using XDA Premium HD app
walda said:
Hope chainfire will start working on mobileOdin soon. So much easier to flash than.
... tapat*lked
Click to expand...
Click to collapse
He will after he will come back from his vacation.
I'll look into a fixed CF-Auto-Root for the I9505 as soon as I'm back on Sunday. I imagine that will be tested by Sunday evening, with a I9500 test version available sometime Monday. If all is well
In StupidSU environment and for this initial release Koush's Superuser app would
be preffered as SuperSU main UI refuses to launch because it cannot detect its
original su binary. Aside from that both work as expected.
Click to expand...
Click to collapse
This is because you're not installing the backup su binary. The UI app detects this is missing and triggers an update. Bug in StupidSU
aslak89 said:
Thank you for awsering
then I repacked my kernel but still not work.
copyed stupidsu and edited init.universal5410.rc in ramdisk and repacked boot.img.
I guess permission is the thing,
attach my shots
hope you loot at once.p
Click to expand...
Click to collapse
Alright I'm adding some logging in my scripts so you'll be able to see what's happening − or not
supercurio said:
Yes in fact I was hesitating, but as soon as someone is ready to assist me to try on a Qualcomm device (I9505 or T-Mobile Galaxy S4) I'll make a thread here too.
Click to expand...
Click to collapse
Brilliant news!!!! Thanks a LOT!!
Let's make it work!! It will be AWESOME if I could use latest STOCK Kernel in my ROM's......
I'll give you a hand
Hey guys I already posted this in a few kernel devs threads but I wanted to create this thread so I can share my info more easily with all the people out there.
What I found is some leftovers of knox on the ramdisk of nearly all the kernels out there - and possibilities to get rid of some more clutter.
There is this init.container.rc file which gets called from the init.rc who's job is to set up the mount points and some symlinks etc. for knox (just take a look at it). It also contains a service called "containersetup" and which's binary is located in /system/bin/containersetup.
I dont 100% know what this containersetup thingy does - but I just renamed the binary to stop it from running with no negative side-effects at all.
Disabling/removing the init.container.rc would also get rid of those reappearing data_1, data_2, data_3 etc. folders which get created by it.
---
This one is not particulary interesting for kernel devs I think, but I also found some other binaries that are or at least appear to be rather useless:
- there is "tima_dump_log" which creates some dumps related to tima on the data partition (possibly for the knox watchdog crap) - disabled that without side effects so far.
- there is "auditd" which is the audit daemon, which logs security related stuff (wether selinux allowed or disallowed stuff etc) - also disabled without side effects.
could possibly find some more.. (bootchecker, drsservice etc.. but not 100% sure on those)
P.S: Why don't you all include init.d support into the kernel? Just wondering, no attack (hard to tell in the internet hehe). Isn't that standard on linux kernel or is it a special feature which normally gets handled by the operating system / rom? (I know how to activate init.d support myself... well its not that hard.. but still wondering lol, because when switching kernels I always have to try and test if the kernel includes init.d support so scripts dont get run twice... some do some don't ...)
Just cooked my "own" custom version of faux123 v004 with the android image kitchen. (http://forum.xda-developers.com/showthread.php?t=2073775)
Removed the init.container.rc
Removed the call to init.container.rc inside init.rc
Edited the fstab.qcom to change system partitions mount flags to "ro,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic"
(you could also add init.d support to init.rc, but I already got that in my install-recovery.sh..)
--
Repacked everything together and flashed it onto my phone. This got rid of the container folders and data_1,data_2,data_3,mnt_1, etc. plus the mount "tweaks".
Unfortunately I cannot redistribute the kernel image with the modified ramdisk (its not my work, i just edited it a tiny bit...), but with the android image kitchen you can just do it yourself - until the kernel devs include this into their kernels as well. (might not be important to you guys, but I like my phone clutter free hehe)
---
ADD: By the way - this android image kitchen is awesome! I was trying to do this stuff with other versions of kernel repack tools - which are mostly made for linux. But the resulting kernels were not working. (the addresses used are not standard, and one would have had to edit the mkbootimg.c and recompile it himself to do it... but with this thing its just idiot-safe drag n drop. Just make sure you dont do any bullcrap on the ramdisk partition..
ADD2: Does anyone know how I could completely disable selinux (not just permissive, but completely turning it off)? I know it might missbehave, but I want to give it a try. The mount script already has the option to mount the firmware partition context free for the case that se-linux is disabled - so it must be possible somehow right? (what benefit does selinux give you anyway in permissive mode other than a possible nsa backdoor or smth?)
Awesome
Enviado do meu SM-N9005 através de Tapatalk
with selinux=permissive you can also deactivate the samsung drs service (this thing handles context labeling as it appears).
It consists of an app called "drsservice" and the binary /system/bin/drs. Can/could been disabled on selinux=enforcing too, but then you needed to do restorecon yourself on some occurences.
--
so on my device I disabled the following services/binaries (please lets try to find more together ...):
/system/bin/containersetup
/system/bin/auditd
/system/bin/tima_dump_log
/system/bin/kiesexe
/system/bin/drs
---
What I would like to manage (if possible) to disable the watchdog daemon and all that bullcrap that checks if the device was tempered (the watchdog daemon is related to knox right?)
zroice said:
Just cooked my "own" custom version of faux123 v004 with the android image kitchen. (http://forum.xda-developers.com/showthread.php?t=2073775)
Removed the init.container.rc
Removed the call to init.container.rc inside init.rc
Edited the fstab.qcom to change system partitions mount flags to "ro,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic"
(you could also add init.d support to init.rc, but I already got that in my install-recovery.sh..)
--
Repacked everything together and flashed it onto my phone. This got rid of the container folders and data_1,data_2,data_3,mnt_1, etc. plus the mount "tweaks".
Unfortunately I cannot redistribute the kernel image with the modified ramdisk (its not my work, i just edited it a tiny bit...), but with the android image kitchen you can just do it yourself - until the kernel devs include this into their kernels as well. (might not be important to you guys, but I like my phone clutter free hehe)
---
ADD: By the way - this android image kitchen is awesome! I was trying to do this stuff with other versions of kernel repack tools - which are mostly made for linux. But the resulting kernels were not working. (the addresses used are not standard, and one would have had to edit the mkbootimg.c and recompile it himself to do it... but with this thing its just idiot-safe drag n drop. Just make sure you dont do any bullcrap on the ramdisk partition..
ADD2: Does anyone know how I could completely disable selinux (not just permissive, but completely turning it off)? I know it might missbehave, but I want to give it a try. The mount script already has the option to mount the firmware partition context free for the case that se-linux is disabled - so it must be possible somehow right? (what benefit does selinux give you anyway in permissive mode other than a possible nsa backdoor or smth?)
Click to expand...
Click to collapse
I followed the link to the Android Image Kitchen and successfully followed your instructions from post #2 but I was wondering if you could please let me know of a good place to find some kernel tutorials for absolute beginners? Thank you for your information as well.
@zroice: Maybe you're already thinking about doing a free rom of Knox
Silverbolt said:
I followed the link to the Android Image Kitchen and successfully followed your instructions from post #2 but I was wondering if you could please let me know of a good place to find some kernel tutorials for absolute beginners? Thank you for your information as well.
Click to expand...
Click to collapse
not sure really, this was just basic scripting and editing the boot scripts, and I just found this out by playing around with the things.
I'm sure you will find a tutorial or smth on xda or google. I have yet to compile anything for android.. so I dont have a clue.
Just sharing my findings and hoping for some interesting replies what other people find out.
what about those data_x folders in a stock image?
Hi!
I've encountered these data_1 data_2 & data_3 on my stock note 3. Is there a way to remove them?
Ibe been looking for a way to remove these processes. I dont have any knox or container agents on my phone nor doea the kt747 kernel have selinux enforcing but I do see these leftovers running around. I found this thread by searching how to disable the tima log. There doeant seem to be much info about this available anywhere. I do se something else running that I suspect is a waste is called edmaudit. I suspect is enterprise device management. Not sure tho. I changed the permissions on the files you mentioned. I know its been a year but if you happen to have any new insight on thos I'd appreciate it.
So... here I will share 2 scripts I made to fix permissions for ViPER4Android running with enforced SELinux.
Why 2 scripts?
I like to keep everything open-source. Here I like to notice, Cyanogenmod is taking the wrong direction in my point of view. Every update takes out something of the customization possibilities of the user, so I am thinking of choosing new ROM. I faced real nightmare with SELinux permissions (well... SELinux is good, but Cyanogenmod doesn't provide any tool or way to manage those permissions). The more funny part is that with branch 13.0 of cyanogenmod there is no more init.d. Before someone corrects me - yeah... there is init.d, but SELinux blocks any script from executing at boot time, so don't use it. You will get your logs spammed by error messages. So... I've tried to enable init.d again, but there is no way to manage init.d to work as before. I've tried lots of different fixes from other posts, but nothing seems to work anymore, because of SELinux restrictions. I didn't managed to find any way to run scripts on boot time with root permissions in a suitable way... without messing with other system files or rebuilding build.img... so I came with those 2 solutions:
ViPER4Android (OpenSource) This is the solution I recommend to all of you. It is full open source. It doens't mess with you current system and it should work on any device/ROM. The zip file contains ViPER4Android app and driver, sepolicy-inject tool from setools-android so we can set permissions for ViPER4Android to work with enforced SELinux and Universal Init.d.
sepolicy-inject is open source equivalent to supolicy tool of Chainfire's SuperSU. I strongly recommend sepolicy-inject over supolicy, because every root closed source app should be threaten as security risk as the code can't be examined. I don't trust it esepcially when it is part of your android root manager
Universal init.d is just a application - it simulates init.d function. Imagine it like init.d on the user side... sadly enough you need to be pre-rooted to get it running.
ViPER4Android (Legacy) Maybe more of you will like this solution as it is more automated and it doesn't require any user action after installing the zip. This zip will do the same as the one above - it will install ViPER4Android removing all other DSP apps, but here come the difference - THIS SCRIPT WILL INSTALL CHAINFIRE'S SUPERSU in order to set SELinux policies for ViIPER4Android. Chainfire's SuperSU uses supolicy-tool - it let you manage SELinux policies on boot time. Chainfire's SuperSU will run everything in /system/su.d/ so again... you have init.d support - this is the real pain in the ass.
Before you download and flash, please read:
Both scripts WILL REMOVE other DSP apps from your device and will install ViPER4Android 2.4.0.1. I STRONGLY RECOMMEND TO USE SOLUTION 1 AS IT IS FULL OPEN SOURCE! Support open source software!!!
INSTRUCTIONS
ViPER4Android (OpenSource) - IN ORDER TO WORK, YOUR DEVICE MUST BE ROOTED! (Your device need to be rooted as Unversal Init.d needs root permissions in order to simulate init.d functionality)Download the .zip; Flash and reboot; Open Universal Init.d and grant root permission if asked; Reboot once more in case it don't work!
Sometimes Universal init.d is not fully initialized and needs some root permissions. That's why you need to reboot second time - then everything works. No further actions needed.
ViPER4Android (Legacy) - Just flash and reboot... but once more - SUPPORT OPEN SOURCE AND CHOOSE SOLUTION 1!!!!
For Samsung devices - if the scripts above doesn't work for you, check this post. Thx to Viper4713 for the instructions and voshchronos for solving the issue!!!
Hope to make someone happy
PS: If u want to make me happy with some beer, here you can donate a small amount. Thank you for your support.
Can i flash it on android one device running on 6.0.1
Yes. If you have any issues, please let me know!
rpangelov said:
Yes. If you have any issues, please let me know!
Click to expand...
Click to collapse
Hi, i tried to install the open source version on my kltedv running resurrection remix 6.0.1 however it is still not working. The init.d shows the kernel doesnt support init.d, and v4a drivers status is abnormal. It is also cause screen freeze and random restart. Any ideas? Your kind input would be very much appreciated. Thanks.
hiropandaz said:
Hi, i tried to install the open source version on my kltedv running resurrection remix 6.0.1 however it is still not working. The init.d shows the kernel doesnt support init.d, and v4a drivers status is abnormal. It is also cause screen freeze and random restart. Any ideas? Your kind input would be very much appreciated. Thanks.
Click to expand...
Click to collapse
I've just readed some info about the ROM you use. As it is based on Cyanogenmod I assume there is root manager builded in. Maybe it is disabled as CM root access is disabled by defaults? Look at: Settings -> Developer Options -> Root Access - turn in on by "Apps only".
Then just follow this steps:
1. Start Universal Init.d
2. Turn it off from the toggle button
3. Run test from the button on the bottom of Universal Init.d
4. If ask for root permissions, grant them!
5. Turn Universal Init.d ON from the toggle (step 2 you turned it off)
6. Restart your device and check once more!
If you still have any issues, please let me know!
Greetz,
Angelov
---------- Post added at 10:44 PM ---------- Previous post was at 10:42 PM ----------
rpangelov said:
I've just readed some info about the ROM you use. As it is based on Cyanogenmod I assume there is root manager builded in. Maybe it is disabled as CM root access is disabled by defaults? Look at: Settings -> Developer Options -> Root Access - turn in on by "Apps only".
Then just follow this steps:
1. Start Universal Init.d
2. Turn it off from the toggle button
3. Run test from the button on the bottom of Universal Init.d
4. If ask for root permissions, grant them!
5. Turn Universal Init.d ON from the toggle (step 2 you turned it off)
6. Restart your device and check once more!
If you still have any issues, please let me know!
Greetz,
Angelov
Click to expand...
Click to collapse
Hi Angelov, many thanks for your helpful instruction. I couldnt get it work with open source version. However it is working now after i install V4A legacy version. Many Thanks once again.
hiropandaz said:
---------- Post added at 10:44 PM ---------- Previous post was at 10:42 PM ----------
Hi Angelov, many thanks for your helpful instruction. I couldnt get it work with open source version. However it is working now after i install V4A legacy version. Many Thanks once again.
Click to expand...
Click to collapse
You are welcome! As I mentioned in the instructions - the legacy script will work always, but I don't like the implementation of it. I am working on new version of the opensource script, so there won't be any issues of that kind. When I am ready I will upload it here after updating my first post.
Greetz,
Angelov
This "universal" fix has been shared several months ago on XDA and a simple root shell is enough to use V4A in enforcing mode.
FYI init.d is deprecated now but it's not related to CM. Use su.d instead.
Primokorn said:
This "universal" fix has been shared several months ago on XDA and a simple root shell is enough to use V4A in enforcing mode.
FYI init.d is deprecated now but it's not related to CM. Use su.d instead.
Click to expand...
Click to collapse
Can you provide me a link to this universal fix you are talking about?
PS: init.d is deprecated in AOSP, i get that. Please read my first post once more, obviously isn't clear enough. Using su.d will result in using closed source tools to manage your Selinux policy's. As I mentioned it above - please support open source software. Every closed source root app has to be threaten as security risk. My opinion...
rpangelov said:
Can you provide me a link to this universal fix you are talking about?
PS: init.d is deprecated in AOSP, i get that. Please read my first post once more, obviously isn't clear enough. Using su.d will result in using closed source tools to manage your Selinux policy's. As I mentioned it above - please support open source software. Every closed source root app has to be threaten as security risk. My opinion...
Click to expand...
Click to collapse
Check the official V4A thread for instance. Others have opened threads in device specific forums or in the App & Games forum.
Have a look at this thread, it might interest you: http://forum.xda-developers.com/android/software-hacking/wip-selinux-capable-superuser-t3216394
FYI I do support open-source free/libre softwares, as much as I can.
Primokorn said:
Check the official V4A thread for instance. Others have opened threads in device specific forums or in the App & Games forum.
Have a look at this thread, it might interest you: http://forum.xda-developers.com/android/software-hacking/wip-selinux-capable-superuser-t3216394
FYI I do support open-source free/libre softwares, as much as I can.
Click to expand...
Click to collapse
I've seen phh's SuperUser but I didn't tried it - this is one of my tasks for this/next week.
As I've tried the most scripts, I didn't liked all the actions needed to be taken before running the .zip script in order to get viper working. I compile my own Cyanogenmod and I don't use gapps. Almost all apps I use on my device are opensource as I use F-droid as my only market (well... I need whatsapp, but I download it just from the website). Anyway... Cyanogenmod has it's own root manager builded in.... so why I need to install one more, which contains closed source tools in it? That is also the reason I don't advice people to use it... and I don't see that as solution to my problem. AOSP is opensource, but nowadays it is very dependent on some closed-source elements and I want to wipe them all out and use open source alternatives for. I hope you understand why using su.d isn't solution in this case. You just make your self and others dependent on one more closed source app, so I don't get where is the support for open source? I think that opensource script is good solution to the problem without using any closed source tool.
To make it easy as possible - just flash the .zip and you are ready to go, I included the latest version of Chainfire's SuperSu in the legacy script, so you don't need to install it before running the .zip. It looks easier to me....
Actually it is very stupid because the result of using the scripts (doesn't matter which one) you will end up with rooted device anyway (if it isnt already), but in order to get opensource script working your device has to be rooted before running the .zip, but if your device is already rooted, you just flash the zip and you are ready to go.
rpangelov said:
I've seen phh's SuperUser but I didn't tried it - this is one of my tasks for this/next week.
As I've tried the most scripts, I didn't liked all the actions needed to be taken before running the .zip script in order to get viper working. I compile my own Cyanogenmod and I don't use gapps. Almost all apps I use on my device are opensource as I use F-droid as my only market (well... I need whatsapp, but I download it just from the website). Anyway... Cyanogenmod has it's own root manager builded in.... so why I need to install one more, which contains closed source tools in it? That is also the reason I don't advice people to use it... and I don't see that as solution to my problem. AOSP is opensource, but nowadays it is very dependent on some closed-source elements and I want to wipe them all out and use open source alternatives for. I hope you understand why using su.d isn't solution in this case. You just make your self and others dependent on one more closed source app, so I don't get where is the support for open source? I think that opensource script is good solution to the problem without using any closed source tool.
To make it easy as possible - just flash the .zip and you are ready to go, I included the latest version of Chainfire's SuperSu in the legacy script, so you don't need to install it before running the .zip. It looks easier to me....
Actually it is very stupid because the result of using the scripts (doesn't matter which one) you will end up with rooted device anyway (if it isnt already), but in order to get opensource script working your device has to be rooted before running the .zip, but if your device is already rooted, you just flash the zip and you are ready to go.
Click to expand...
Click to collapse
I mentioned su.d because that's a solution with newer Android versions but I didn't say it's the best one. Using FLOSS softwares is a good move but you are using proprietary codes with CM.
Hi everyone, i flashed both of the zips with TWRP but i got an error code : 255. Any idea how to fix it ? Please help me. I'm using an x86 phone btw
trongtin64 said:
Hi everyone, i flashed both of the zips with TWRP but i got an error code : 255. Any idea how to fix it ? Please help me. I'm using an x86 phone btw
Click to expand...
Click to collapse
I think it's because your phone architecture... anyway - I will look at it today and I will let you know if I find a solution for your problem. Can you tell me which phone exactly you own ? Thank you.
Greetz, Angelov
rpangelov said:
I think it's because your phone architecture... anyway - I will look at it today and I will let you know if I find a solution for your problem. Can you tell me which phone exactly you own ? Thank you.
Greetz, Angelov
Click to expand...
Click to collapse
i'm using a zenfone 5 (A501CG) with resurrection remix mm 5.6.7
trongtin64 said:
i'm using a zenfone 5 (A501CG) with resurrection remix mm 5.6.7
Click to expand...
Click to collapse
You have a x86 architecture and this zip is probably for arm only. I guess you need the updater-binary for x86 and place it into the zip in META-INF/com/google/android.
Primokorn said:
You have a x86 architecture and this zip is probably for arm only. I guess you need the updater-binary for x86 and place it into the zip in META-INF/com/google/android.
Click to expand...
Click to collapse
Ok so i need an updater-binary for x86 right? Can i copy it from other zip to your zip? Will it work?
trongtin64 said:
Ok so i need an updater-binary for x86 right? Can i copy it from other zip to your zip? Will it work?
Click to expand...
Click to collapse
AFAIK you can use the one from a custom rom. You need a compatible custom recovery of course.
Primokorn said:
AFAIK you can use the one from a custom rom. You need a compatible custom recovery of course.
Click to expand...
Click to collapse
I'll use the one from my custom rom . Thank you for helping me :good:
It works great. thanks.
my bad for not following the instructions.
I repackaged the xposed zip to also install a patched system linker removing the pie requirement for binary execution. Just a cosmetic change cause modern binaries compiled for android meet the requirement anyways. I also can upload a tweaked kernel boot image if anyone is interested. You could also repackage the zip to install a tweaked build.prop or other patched binaries which could open some doorways for improvements to performance or device functionality. Install in TWRP recovery environment. Enjoy!
Does this zip contain only linker or something else ?
Can I use this in mediatek variant of e4 ?
EDIT: 4 views and only one thank . This is how XDA users being generous to someone's post right now . LOL Just pressed the download button and don't bother to press thanks button.
Francesco Franz said:
Does this zip contain only linker or something else ?
Can I use this in mediatek variant of e4 ?
EDIT: 4 views and only one thank . This is how XDA users being generous to someone's post right now . LOL Just pressed the download button and don't bother to press thanks button.
Click to expand...
Click to collapse
I didn't download it, but definitely thanked. Love seeing development for this phone. I installed regular Xposed and it worked ok. I was going to try it later when I further understood the benefits.
anthonykb said:
I repackaged the xposed zip to also install a patched system linker removing the pie requirement for binary execution. Just a cosmetic change cause modern binaries compiled for android meet the requirement anyways. I also can upload a tweaked kernel boot image if anyone is interested. You could also repackage the zip to install a tweaked build.prop or other patched binaries which could open some doorways for improvements to performance or device functionality. Install in TWRP recovery environment. Enjoy!
Click to expand...
Click to collapse
So what's the benefit to removing pie? Just curious because the regular Xposed 88.2 worked fine for me.
Update: ok I did some reading, and found that removing that requirement can prove useful in certain situations.
Because Google in the update from Android KitKat to Android Lollipop has introduced a new type of restriction that blocks the execution of non-PIE binary.
This block mainly forces the user to copy the binaries he wants to run in /system/bin, /system/xbin, or in /sbin.
This restriction stops executing some apps (also app no-root), this modified version removes that restriction.
Doesn't seem to be working on the xt1776 though the official zip doesn't work either.
wrong section mate,,,,move to guide section...