At first, I am not liable for any harm or damage that may happen to your device!
If you have su and didn't trigger knox, I CANNOT guarantee that running this script won't cause 0x1!
Requirements:
1) P905/viennalte/Qualcomm based model ONLY (won't work on Exynos devices. MIGHT work on other Qualcomm LTE deices from Note Pro and Tab Pro series or even S5 / Note 3 etc - feel free to repost but give credits AS THIS METHOD SEEMS TO BE COMPLETELY NEW! ) running 4.4.2 stock;
2) root access with SuperSU (using cf-root - credits to chainfire);
3) busybox installed (I do recommend this paid installer: https://play.google.com/store/apps/details?id=stericson.busybox.donate , MOST PROBABLY free version will be more than enough, too, but I haven't tested it as I have license...)
4) Android Terminal Emulator installed ( free at: https://play.google.com/store/apps/details?id=jackpal.androidterm )
Installation:
1) download file permissive_via_kmem.sh using below link and put it in the root of internal memory (so it will be placed in: /sdcard/permissive_via_kmem.sh)
2) run Android Terminal Emulator
3) at command line, type:
Code:
su -c /sdcard/permissive_via_kmem.sh
(give it an access if requested)
4) voila.
Alternative: if u have init.d support just put the file in /system/etc/init.d to make permissive on every boot
Additional info for advanced users:
1) samsung decided to compile kernels for newer 4.4.2 roms with a flag (a kernel variable) forcing selinux enforcing mode
2) as kernel itself cannot be modified after compiled, it was impossible to set permissive mode using shell or even by repacking kernel's ramdisk, at least on Qualcomm LTE devices
3) custom kernel can do the job, but samsung's sources are broken, at least for P905, and it refuses to boot at all...
4) however, there is a workaround...
5) we cannot change kernel binary to run with different flag out of the box BUT we can obtain it's placement (address) directly in kernel memory space on running kernel and write different value DIRECTLY into the memory, hacking the kernel to make it think that the flag was different
6) for this purpose i believe we have to disable restrictions to access kernel pointers (done via sysctl)...
7) ...then read the output of /proc/kallsyms which will provide a list of all kernel variables along with their addresses in kernel memory space...
8) ...filter out a boolean variable selinux_enforcing which is responsible for all the troubles...
9) ...and write raw 00 byte into the address where the variable value is stored, via /dev/kmem.
Download:
http://www12.zippyshare.com/v/89625246/file.html
Noob question
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
cavkic said:
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
Click to expand...
Click to collapse
Check this
Well, if i'd try to express it in a simple way, from the user's point of view permissive mode is equal to selinux turned off at all, except it is logging (and only logging...) all the warnings caused by security violations, which would result in an error in enforcing mode. Permissive mode let you avoid strict security policies defined by manufacturer (and NSA - yeah, the real spies - which is maintaining general selinux rules), but also gives the possibility of establishing possible issues which may appear after switching to "really secure" enforcing mode.
And if you are asking about the exact, disturbing (ofc if security is not your main priority...) effects of enforcing mode that may affect end-users, we may start from: troubles with write-access to some (mostly external, but i have personally fought with with an issue of non-writeable internal sdcard, too) medias (well, to be honest, I do hope that my discover will help in building 100% working custom recovery...), troubles with non-working system mods resulting from bad selinux file labels, troubles with wiping partitions (ie. wiping cache or even swapping modded system lib sometimes has to be followed by triggering restorecon command on that filesystem (restore selinux context), which is leading to ie. losing root access, which may be fixed by flashing supersu again, etc etc, non working apps (especially related to modifying sensitive system parameters or resources), unchangeable system properties, unreachable functionalities, blah blah blah.... This topic had been widely discussed on xda and over the internet.
On the contrary, if you like to use your device as-is and you're not interested in modding/tweaking it, you will probably not need this mod, as you will gain nothing - but lose a little bit of security... For heavy modders, although, it's a must-have.
Btw can anyone confirm if it's working? I assume that I was looking for solution for some time, made some other changes to the environment meanwhile, so I cannot be 100% sure that above script alone is absolutely enough (but in theory it should...), however, even if it is not, it's just a matter of 1-2 days to figure out what additional, previously-well-known steps, such as running "setenforce 0", may be required in addition.
And as a brief summary: YES, my selinux is now really Permissive, both when running getenforce command and in system settings!
Wysłane z mojego SM-P905 przy użyciu Tapatalka
After following all steps getenforce still returns enforcing and in system it also shows enforcing.
If I try running setenforce I get permission denied.
Ok, can you enter:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
into terminal and tell me what's the output and/or the enforcing state??
Wysłane z mojego SM-P905 przy użyciu Tapatalka
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
RaSand said:
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
Click to expand...
Click to collapse
I assume that you have ran the command as root (ie didnt forget about 'su' before the main command)...? Your logs show non-root mode, but ur saying about '#' mode at the end, guess you mean su... Assume that all we do here requires root shell first to be opened, and the output even if similiar, may vary in details between non-root and root mode, so don't forget to get privileges before running anything below...
If so, I guess default policy prevents writing to /dev/kmem in enforcing mode by setting its selinux context to a special one, dedicated only for /dev/kmem and /dev/mem.The working solution is to repack kernel (not same, but, indeed, a lot easier, than recompile - changes won't affect the kernel binary code, but it's ramdisk part, only) with modified policy defaults, which will treat /dev/kmem as a genuine device, not a "sensitive" one. I can provide the one repacked for my own purposes, however, befoure such an intrusion we may want to try other solutions I can think of (again, cannot test it as I ve added many different mods in many different places, I would need to go back to stock to test it, but I need my device 100% steady and configured for my job this week. Hope you'll help me in solving this out, it shouldnt take long...).
Notice: Again, ALL BELOW COMMANDS SHOULD BE RUN IN ROOT MODE. That means you shall enter "su" command alone before trying any of those steps, and the Terminal will switch to a root shell, which is confirmed by switching the last sign in the prompt from '$' to '#'.
Notice 2: if it is written - after some steps - to try switching to permissive mode again, it should be done by running the command from MY PREVIOUS POST only, as it is equal to longer version from the script, just closed within shorter one-liner command... the command should change the mode to permissive itself and no further steps are needed.
1) run following:
Code:
ls -lZ /dev/kmem >/sdcard/info.txt
and paste the exact output (which has been saved at /sdcard/info.txt) here so I can gather further info about issue. Dont make a test of the main script here as nothing has been changed. After that...
2) we can try to set different context (a default one for dev files) manually. Again, it might be impossible as of selinux policy, but worth trying. Enter as root:
Code:
busybox mount -o rw,remount /
chcon u:object_r:device:s0 /dev/kmem
if error, paste it here. If no error, test if permissive mode script is working.
3) we can try to modify selinux policy in temporary ramdisk file to prevent giving /dev/kmem a special context and then restore context of whole /dev to it's "defaults", however, those "defaults" would be our modified ones. Possible issues: not sure if the restoring default context will make use of modified policy or would it use only the policy loaded on-boot (and as the ramdisk is temporary, policy modifications will disappear too within reboot). After getting root, enter:
Code:
busybox mount -o rw,remount /
sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
setprop selinux.reload_policy 1
restorecon -R /dev >/dev/null 2>&1
after that - if no errors - check if the switching works.
4) if none of the above is working, guess we'll need to repack stock kernel with a ramdisk content modified in the same way as in step 3. When embedded in kernel, the changes to the policy rules will be seen every boot and they will affect /dev/kmem in a persistent manner. This will let you write to it for sure. I will provide a ready repacked boot.img, so we can avoid repacking at all. This however is not a very satisfying solution, as my goal was not only to achieve permissive mode, but to achieve it without any changes (even if they are much less disturbing than recompiling kernel from source) to boot partition. But hey, first check out on-the-fly solutions above, as they are much less intrusive to a device, coz won't require reflashing kernel/boot partition.
EDIT: remount command added to step 2, repeat if you had error with changing the context.
Thanks for your effort.
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
RaSand said:
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
Click to expand...
Click to collapse
Your errors are quite strange, as it seems that you don't even have permissions to check the simple content of a directory...
Try to run commands from step 1 - 3 again, but with slight modifications (below), so theyll run in separate, undoubtly-rooted shell... Test also with modded command (you can try it alone before in the very beginning...)
Also: please run 2 and 3 in reversed order, ie. first step 3 and if not working, without rebooting, run step 2...
Btw are you using SuperSu 1.99? If no - after trying all below options, upgrade SuperSu from the Play Store, run it to update the binaries, reboot. check commands again. If still the same, install update to /system using option from its menu (it will do some cleanup and ask to reboot, after that you have to run option again, this time it will perform installation, after which you have to reboot again - after boot run SuperSu and check if the option is greyed out, if yes, everything went fine) and check all steps once again...
Here we go.
Main command:
Code:
su -c printf '\x00' | dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
Step 1 v2:
Code:
su -c ls -lZ /dev | grep kmem >/sdcard/info.txt
Step 2 v2 (formerly step 3 ):
Code:
su -c busybox mount -o rw,remount /
su -c sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
su -c setprop selinux.reload_policy 1
sleep 3
su -c restorecon -R /dev
Notice: I am not sure if setprop selinux.reload_policy 1 is enough to force sammy's android (which is a really giant b***ch to hack when compared to any other android...) to reload the policy, this may really work, but only if the policy is reloaded on-line using new defaults. Later I will look for that information...
Step 3 v2 (formerly step 2 - please run directly after step 2v2, without rebooting...):
Code:
su -c busybox mount -o rw,remount /
su -c chcon u:object_r:device:s0 /dev/kmem
Notice: step 3 - when ran fine - might now print some errors that it cant access some stuff in /dev - this is absolutely ok. But formerly I disabled the output at all (not to confuse you with some strange errors), but it resulted in lack of possibility to find out if the command ran AT ALL or if it escaped because of no permissions on the very beginning.
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
RaSand said:
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
Click to expand...
Click to collapse
Stay cool. I am a (quite) young man, but I have patience, too ;]
No output when running *something* as su = faulty su installation (maybe)...
Please download SuperSu 1.99 (flashable cwm version) from here: http://forum.xda-developers.com/showthread.php?t=1538053 and put it somewhere on internal sdcard
Download my "almost-working" TWRP recovery image: http://www53.zippyshare.com/v/30690424/file.html
Put it in internal mem so its path will be /sdcard/twrp2.img
Run terminal emulator (CAREFULLY WITH THE PARTITION NUMBERS!)
Code:
su
dd if=/dev/block/mmcblk0p15 of=/sdcard/recovery.backup.img
sleep 1
dd if=/sdcard/twrp2.img of=/dev/block/mmcblk0p15
sleep 1
sync
reboot recovery
In recovery, flash downloaded supersu zip. Reboot.***
Try commands again.
Maybe your busybox is bad? Can you tell me the output of command busybox written alone without further params?
***(btw the recovery may be useful, but it is not-fully-working, however, it is working AT ALL... be aware of issues:
- it cannot write backups to exfat external cards, vfat/fat32 only
- it may mess the selinux context, especially for cache partition after wipe. solution: from twrp run advanced -> console (or terminal? dont remember) and run
restorecon -R /cache
- if u ever have a bootloop after flashing a (even reliable...) zip, you should get back to twrp, click mount menu, mount everything, switch to advanced -> console and run:
restorecon -R /system
restorecon -R /data
restorecon -R /cache
selinux contex will be fixed BUT it will mess context for su binary, so in the end flash supersu again and reboot, everything will be ok.
If you want to revert, just do:
dd if=/sdcard/recovery.backup.img of=/dev/block/mmcblk0p15
).
And last but not least, kernel which I have promised (BUT if you use it, I will lose my only tester heheee):
http://www46.zippyshare.com/v/63874309/file.html
Please be aware that there are some other tweaks included (like unsecure adb, faster filesystem mount options but with higher risk of data loss, etc).
Put b4.img to /sdcard/b4.img
Run:
Code:
su
dd if=/dev/block/mmcblk0p14 of=/sdcard/boot.backup.img
sleep 1
dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
sleep 1
sync
reboot
You can revert to stock by dd if=/sdcard/boot.backup.img of=/dev/block/mmcblk0p14 (or by flashing full stock by odin). Would be glad if you can confirm that mode is permissive using this repacked kernel (HOPE IT WILL!!!!) and after some time you'll flash the backup back, to help me solving the case, as i suppose that there IS possibility of permissive without the kernel flash and I need a tester ;} It would be reeeeeeaaaaaaaally nice...
BE AWARE THAT:
- it's for note pro 12.2 LTE ONLY!!!! also called viennalte or SM-P905... It WON'T work on other devices and it may damage them (for example, coz of different mmcblk numbers...)
- messing the mmcblk0pxx number may cause an unrecoverable harm to your device (especially if you overwrite bootloader partitions or your efs partitions where unique imei is stored), it's 14 for kernel (boot) and 15 for recovery
- your knox WILL be tripped (if it hasnt been tripped yet... but it's not very probable )
- on the very first boot screen, a warning messages may appear in the left-top corner, about some warranty stuff. Ignore them, they'll disappear after reverting boot/recovery to stock.
Regards.
Just done flashing twrp and supersu(now 1.99)
i will not give up that easy, don't worry.
Just to be on the safe side i downloaded b4. Maybe you should remove it for the moment.
Looks like fun being the most important part of the team.lol.
btw. Knox was tripped about 2 hours after i got the device
busybox is v1.22.1 (2014-01-25 17:27:18)
---------- Post added at 10:05 PM ---------- Previous post was at 09:15 PM ----------
This it what happened after the last command in step 2 was executed
Could not label /dev/cpuctl with ubject_r:cpuctl_device:s0: Operation not supported on transport endpoint
Could not access /dev/kmem: Operation not supported on transport endpoint
Could not access /dev/mem: Operation not supported on transport endpoint
Could not label /dev/pts with ubject_r:device:s0: Permission [email protected]:/ #
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
RaSand said:
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
Click to expand...
Click to collapse
Your two posts above confirm that SU version was not the issue, as it is still preventing from modyfing anything related to kmem, sorry for effort, attough hope you'll at least enjoy included, almost-working twrp, as it seems to be only one capable of flashing zips and doing backups and restoring them on p905 floating around (if you use exfat card for everyday use, my recommendation is to use another one, ie. 8 gig, which are cheap as hell, format it to fat32 (in android it's recognized as vfat) and use it for exclusively for backup purposes, at least until someone establishes a better solution. It's not that bad after all plus it gives you real possibility of experimenting with the device without need to worry about configuring it again from the beginning if something fail. Btw please be aware if in any case, after restoring backup/flashing zip/clearing cache you'll receive a bootloop AND/OR after booting you/apps won't be able to write to any part of internal memory (like /sdcard or /cache), just get back to twrp, use console and run restorecon commands for all partitions AND -as restorecon will break su - reflash su. ALSO - if anytime TWRP on exit will prompt you with a proposition of rooting the device itself - don't do that, the only proper way of fixing su is reflashing it from the genuine zip (or with odin, but avoid that as cf-root includes older version). Uh, isn't it a offtopic? Sorry..
The kerne IS stock (as to the binary part) but with modified ramdisk (repacked) including changed policy of accessing /dev/kmem. If you have kernel warranty bit warning on boot, you have flashed it succesfully ( the message will disappear when you flash back FULLY-stock kernel back - also, i dunno why but it says "kernel is not enforcing" but it's not YET true! It will say the same even if I repack kernel without any changes, so it's quite misleading...), although kernel version/compilation number nor any extra features will not change in the system coz the kernel base is absolutely the same (and it has to stay the same until Samsung release sources that work, coz current one won't).
To really, really confirm that you have flashed my kernel and that the policy of writing to memory has been removed, please open /file_contexts file (it lies in the very root of the filesystem) in any text editor within Android, and look for lines with /dev/kmem or /dev/mem. They should be commented out by "#" in the beginning - or deleted at all (dont remember which one method I did use...). If so, you can be sure that you have flashed repacked kernel succesfully (and also that I have uploaded the proper one, with changed policy...).
If you have checked above, you may be sure that after every boot to Android, now, the new policy (without restrictions to /dev/kmem, which were commented out/deleted) will be loaded. I don't think that restorecon -R /dev will be no longer necessary after that, as the /dev directory is virtual and created on every boot, so its previous, restricted security labels are not preserved between reboots and they are assigned according to current policy, only - but you can run it to check if you see any errors for /dev/kmem (and you should NOT see them... there might be other, like for /dev/cpuctl etc, but it doesnt matter...).
After that, there should be no further doubts that you have unlocked /dev/kmem for writing!
On this step you still need to run the command from my post on top of the topic, this one:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
setenforcing alone WILL NOT WORK EVEN NOW, only the script above helps. I guess you avoided that after flashing kernel, coz of misleading boot warning...
Then check enforcing status. Now it really should work.
If we achieve a success, I'd rather release a fully-featured-repacked-kernel, with built-in kmem script, so it will be permissive from the very beginning (PLUS it will be in a good mood to close possibility of further writing to /kmem after that one single write, as it is really serious security hole, to be honest, to let anyone write to any part of memory directly..., and also include init.d support out-of-the-box as well).
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
RaSand said:
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
Click to expand...
Click to collapse
good, thank you for testing and hope enforcing linux won't bother you again ;] you're probably a second man on the planet who is running your machine in permissive
and don't worry about anything, it's not a race or something. i am most thankful that you found a time to run all the suggested stuff, and for patience.
please however note that leaving open /dev/kmem shall be considered as a serious security hole! it allows root app to write ANYTHING to ANY part of memory. Well, that's was an obligatory warning, however, I was never scared too much with security issues and until now nothing bad happened so..
Let's summarize:
- now I am sure that my script is working BUT only after giving it possibility of writing to memory via /dev/kmem
- writing to /dev/kmem is possible only after changing the security policy, which lies in kernel's ramdisk
- the final appropach shall also CLOSE the access to /dev/kmem just after changing the selinux mode for security reason
- the aim is to make a complete modification which will make use of only one area of the device ie. system OR kernel, not both, as it is too intrusive:
- find a way to reload policy when device is on-line, so writing to /dev/kmem will be possible (it's a preferred method, no need to flash anything and no need to watch ugly warranty message - but I doubt if it's possible - it would be an equally dangerous security issue, there is no practical difference between letting write to memory and between letting to open the possibility of write to memory and then letting write to memory ... or
- implement the memory write technique straight in the kernel's ramdisk.
I will be back with new stuff, soon.
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
RaSand said:
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
Click to expand...
Click to collapse
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
esgie said:
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
Click to expand...
Click to collapse
Esgie, is there any further developments with this script? I've given it a shot and even after running the script, SELinux remains in Enforcing mode.
I see that you have the modified kernel for SELinux in permissive mode, but I really like the approach of having this script rather than using a modified kernel, so I'm wondering if in your process of getting the kernel to work, there might be something you've discovered that would make this script work as well.
Thanks.
Related
Hi All,
I am a little bit desperate (Linux Newbie, but nevertheless I had assumed a basic understanding up to now ... seems to be wrong ...!)
Here are my questions:
I am using Better Terminal Pro with the ASH shell which works fine.
I now want to start a script from the SDCARD but this doesn't work because of 'permissions denied'.
Busybox 'id' command shows the USERID uid=0 gid=0 groups =3001,3002,3003
Buysbox 'ls -al' command shows for file getip.sh:
"----rw-rw- 1 1000 1000 42 Sep 13 10:43 getip.sh
In my understanding
* chmod 777 getip.sh should have given EXECUTION rights to the script in any way (especially for the root user) but nothing has changed in the file attributes - although an error reply was missing (only prompt # came up)
* chown root.root getip.sh should have given access to the root user (me) but stderr denied with "Unable to chmod getip.sh: Operation not permitted"
* the root user should have access rights without any constraints to Linux ressources, but this seems not to be ...?
* I think in theory the root user is able to grant any right himself, so what do I have to do start the dammned script (sorry for my language ..., but I am testing for hours now ...)
Should I leave the PC and have a walk in the forest or what is going wrong?
What ist my basic misunderstanding? Is it generally impossible to start a scripts from the SDCARD as a terminal user with root privileges (for security reasons ???)
Where is the trick to succeed?
Why does GSCRIPT work on scripts stored on the SDCARD?
Any help is pretty much appreciated - thanx in advance!
Regards
make sure you put sh in front of it....
ex.
Code:
su
sh /sdcard/script.sh
Sogarth's webtop2sd will be released soon, you really should wait and install that instead of this! Thanks -The Management
No longer breaks on 1.83, thanks to Romracer
Update: This script worked on my phone. Mind you I was installing it from a fresh SBF flash, but it should work on your phone too. Absolutely no guarantees as usual.
Update 11th April 2011, 06:59 PM: Won't be getting CWM package because it'd be huuuuuuuuuge.
Update 28th April 2011. 16:38 PM: Removing BETA tag since there have been no issues with the script for quite some time.
First off I would like to thank Sogarth for making this script in the first place as well as Romracer for fixing it for 1.83. Since he is busy doing more important work I decided to do this little hack for those of us that updated to 1.5.7 and dont feel like flashing back to earlier versions to get full Ubuntu working.
Again, this is only necessary if you're already running 1.5.7 or 1.8.3.
Secondly, I am still working on this script so it may not work for you. If you have a problem you may post in the thread or PM me showing exactly the error message, word for word, that you receive.
Updates will be included in the OP from time to time as I fix errors.
Instructions:
1) install.bat (from your computer)
2) adb shell (get a shell on your phone)
3) su (get root on your phone in that shell)
4) . /data/local/tmp/install.sh (run the install script *on your phone* don't forget the "." and the space after the dot, or you will have to chmod 755 the shell script manually)
5) ?????
6) profit\
Noob instructions, written by Viamonte (I take no credit or responsibility):
Thanks again for all your help. Now the noob instructions:
"1-Download "Terminal Emulator" from the market, on your phone (or any other terminal), and the file anexed in this thread to your computer.
2-Connect the Atrix to the computer via USB, configuring the connection mode to "None" and enabling USB Debugging mode (Settings>Applications>Development>USB debugging)
3-Unzip the file you downloaded on your pc, and run Install.bat. This will push the script to your phone.
4-Go back to your phone and open the emulator you downloaded. Then type "su" (without quotes) and press enter. Then type ". /data/local/tmp/install.sh" (without quotes) and press enter again.
The script should begin running now. It will stop in two moments where you'll be instructed to get a cup of coffee, and may take several minutes to continue form this point. When finished, the Atrix will reboot.
To check if this worked, use the Webtop either on your multimidia dock or your lapdock and verify if new itens appeared on your task bar and on the right upper side of the screen"
0.3.1 release
0.2 release
0.1 first release
Changelog
0.3.1 fix to gconf file's mdate so it does what its supposed to do =)
0.3 Small typo fixes and cpp package install fix by romracer, now works on 1.83 =)
0.2 Fixed some typos in uninstall.sh and make sure the %gconf file wound up in the right spot.
0.1 - first version. NOT CWM install but ready to be packaged for that more or less
Nice, I'll give this a shot later.
Ill give it a shot when I get home!
Sent from Motorola Atrix on TELUS.
My phone is working perfectly, so why not ruin it?
I'm giving this a try right now!
1.4.57 - Rooted and gingerblurred with HDMI Mirroring and Webtop hack.
I'll update as progress goes along:
Edit 1:
Initial try gave me this
Checking device state...
Obtaining temporary root access...pushing shell scripts
A filesystem file already exists. Reset it? [n] y
Mounting the filesystem...
07.sh
--------------------------------------------
EXECUTION FAILED
Unable to mount the filesystem file. ERR 07
--------------------------------------------
Press any key to continue . . .
Edit 2:
Ok, it doesnt work with resetting it. How about removing?
Checking device state...
Obtaining temporary root access...pushing shell scripts
A filesystem file already exists. Reset it? [n] n
A filesystem file already exists. Delete it? [n] y
Deleting the filesystem file...
--------------------------------------
EXECUTION FAILED
Unable to delete the filesystem file.
--------------------------------------
Press any key to continue . . .
Edit 3:
Ok, only one option left then.
Checking device state...
Obtaining temporary root access...pushing shell scripts
A filesystem file already exists. Reset it? [n] n
A filesystem file already exists. Delete it? [n] n
--------------------------------------------------------------------------
EXECUTION FAILED
The filesystem file already exists, but no operations have been selected.
--------------------------------------------------------------------------
Press any key to continue . . .
=====================================================================
Edit 4:
Since execution is failing I'm trying to find the problem. Using ADB Shell i tried to manually run the shell scripts and stumbled here:
(I tried chmod 777 @ 02.sh to see if that was the problem, no change is results)
# ls -l
...
...
-rwsr-sr-x shell shell 87 2011-04-06 12:13 03.sh
-rwxrwxrwx shell shell 82 2011-04-06 12:11 02.sh
-rwsr-sr-x shell shell 251 2011-04-06 12:04 01.sh
# pwd
pwd
/data/tmp/shell
# /data/tmp/shell/02.sh
/data/tmp/shell/02.sh
/data/tmp/shell/02.sh: not found
I had the same issue as flybob when I tried to run the script.
Sent from my MB860 using XDA Premium App
Good effort, but 1.57 changes how we have to run commands as root. On a normal linux box, I'm sure your methods would work fine, but we're not dealing with a normal su binary. You should look into doing this as CWM as opposed to .bat files. I had a hell of a time getting around the restrictions since the psneuter exploit was closed.
Ah, I did not think about that Ririal, thanks for the info. I am not familiar with CWM though.
Why is the /tmp directory in /data ? That would certainly cause every script to fail.
I'll look at this some more tonight.
Ririal said:
Good effort, but 1.57 changes how we have to run commands as root. On a normal linux box, I'm sure your methods would work fine, but we're not dealing with a normal su binary. You should look into doing this as CWM as opposed to .bat files. I had a hell of a time getting around the restrictions since the psneuter exploit was closed.
Click to expand...
Click to collapse
How about a shell script that we can run in terminal emulator ? and the output goes to screen and a log file for debug !
molotof said:
How about a shell script that we can run in terminal emulator ? and the output goes to screen and a log file for debug !
Click to expand...
Click to collapse
most of the script is now run by shell scripts, no reason you couldn't run them in the terminal emulator, just get the order right. There are also a few lines I didn't translate to shell so you'd have to enter them by hand.
In any case I'll keep working on this until Sogarth releases his version with union mounts =D
You might be interested to know this;
# cd /tmp
cd /tmp
# pwd
pwd
/data/tmp
# ls -l /tmp
lrwxrwxrwx root root 2011-04-09 14:47 tmp -> /data/tmp
I'll happily help with the script, i know tons of linux and got my Atrix ready to be bricked
flybob said:
You might be interested to know this;
# cd /tmp
cd /tmp
# pwd
pwd
/data/tmp
# ls -l /tmp
lrwxrwxrwx root root 2011-04-09 14:47 tmp -> /data/tmp
I'll happily help with the script, i know tons of linux and got my Atrix ready to be bricked
Click to expand...
Click to collapse
That's just a symlinked directory. I won't make a difference if you call either.
Yes, just replied to the previous question
Why is the /tmp directory in /data ? That would certainly cause every script to fail.
I'll look at this some more tonight.
Click to expand...
Click to collapse
However, why doesn't the scripts run as wanted...?
# cat /tmp/shell/02.sh
cat /tmp/shell/02.sh
#!/bin/sh
/system/bin/su
/bin/rm /data/ubuntu.disk > /dev/null 2>&1 && echo PASS#
# ls -l /tmp/shell/02.sh
ls -l /tmp/shell/02.sh
-rwxrwxrwx shell shell 82 2011-04-06 12:11 02.sh
# /tmp/shell/02.sh
/tmp/shell/02.sh
/tmp/shell/02.sh: not found
flybob said:
Yes, just replied to the previous question
However, why doesn't the scripts run as wanted...?
# cat /tmp/shell/02.sh
cat /tmp/shell/02.sh
#!/bin/sh
/system/bin/su
/bin/rm /data/ubuntu.disk > /dev/null 2>&1 && echo PASS#
# ls -l /tmp/shell/02.sh
ls -l /tmp/shell/02.sh
-rwxrwxrwx shell shell 82 2011-04-06 12:11 02.sh
# /tmp/shell/02.sh
/tmp/shell/02.sh
/tmp/shell/02.sh: not found
Click to expand...
Click to collapse
Ah ok my mistake, you didn't quote anything I didn't realize that's what you were responding too
Likely noexec flag causing that issue.
Also, you can't invoke su from inside a shell script. It just doesn't work with this su binary.
yeah, I guess not. I hadn't realized that it wasn't a real 'su' before making this... too bad.
If anyone figures out how to get around that we'll be in business Unfortunately that's way beyond my expertise.
Okay, after fiddling a little bit and talking to a friend I may have solved some of the problems, mainly with the scripts executing and su working.
I will have to rewrite a bunch of things but should report back tonight.
the2dcour said:
Okay, after fiddling a little bit and talking to a friend I may have solved some of the problems, mainly with the scripts executing and su working.
I will have to rewrite a bunch of things but should report back tonight.
Click to expand...
Click to collapse
su -c "command"
You'll have to allow superuser on the phone for every single command.
PM'd you my error. I tried manually editing the permissions, but that didn't work.
Running on GladAtrix2 v3
USB debugging on; USB set to none
Checking device state...
Obtaining temporary root access...pushing shell scripts
-------------------------
EXECUTION FAILED
Unable to chmod scripts.
-------------------------
Press any key to continue . . .
Changed /sdcard-ext to /sdcard in script. Got this error
Checking device state...
Obtaining temporary root access...pushing shell scripts
-------------------------
EXECUTION FAILED
Unable to chmod scripts.
-------------------------
* server not running *
Press any key to continue . . .
Running BETA_ubuntu-1.0.6.4.zip. File extracts to BETA_ubuntu-1.0.6.2 directory. Ran ubuntu-1.5.7.bat
Moved BETA_ubuntu-1.0.6.2 to C:\ Same error
The only easy workaround to that I can see at the moment is to
Code:
adb shell
su
chmod 777 /path-to-scripts/*
ls -l /path-to-scripts/*
make sure all the files are executable (should say rwxrwxrwx)
then remove the bit of code from 1.5.7.bat
Code:
set retval=
for /f "tokens=*" %%l in ('%~dps0adb.exe shell "/bin/chmod 6755 /mnt/sdcard-ext/shell/* > /dev/null 2>&1 && echo PASS"') do set retval=%%l
if "%retval%" neq "PASS" set message=Unable to chmod scripts. && goto abort
If anyone can help me fix this problem I should be able to automate the chmod process using ririal's suggestion of su -c. The problem is that there are too many nested quotation marks in this section of the batch file, and I can't for the life of me figure out how to escape quotes so they pass through to adb:
Code:
set retval=
for /f "tokens=*" %%l in ('%~dps0adb.exe shell "/system/bin/su -c [U]'/bin/chmod 6755 /mnt/sdcard-ext/shell/*'[/U] > /dev/null 2>&1 && echo PASS"') do set retval=%%l
if "%retval%" neq "PASS" set message=Unable to chmod scripts. && goto abort
The underlined bit is where I need to escape either single or double quotes.
the2dcour said:
The only easy workaround to that I can see at the moment is to
Code:
adb shell
su
chmod 777 /path-to-scripts/*
ls -l /path-to-scripts/*
make sure all the files are executable (should say rwxrwxrwx)
then remove the bit of code from 1.5.7.bat
Code:
set retval=
for /f "tokens=*" %%l in ('%~dps0adb.exe shell "/bin/chmod 6755 /mnt/sdcard-ext/shell/* > /dev/null 2>&1 && echo PASS"') do set retval=%%l
if "%retval%" neq "PASS" set message=Unable to chmod scripts. && goto abort
If anyone can help me fix this problem I should be able to automate the chmod process using ririal's suggestion of su -c. The problem is that there are too many nested quotation marks in this section of the batch file, and I can't for the life of me figure out how to escape quotes so they pass through to adb:
Code:
set retval=
for /f "tokens=*" %%l in ('%~dps0adb.exe shell "/system/bin/su -c [U]'/bin/chmod 6755 /mnt/sdcard-ext/shell/*'[/U] > /dev/null 2>&1 && echo PASS"') do set retval=%%l
if "%retval%" neq "PASS" set message=Unable to chmod scripts. && goto abort
The underlined bit is where I need to escape either single or double quotes.
Click to expand...
Click to collapse
^ escapes batch, \ escapes shell. Hope this helps. If you zip up and send me the whole process in a single .sh file I can wrap it up in CWM for you.
** Update ****************
************************
Posted a .zip with scripts for both Windows and *nix users to automate the process.
Linux:
-----
Unzip the contents of the attached ICS404root.zip anywhere on your computer and run the script aptly named "runme_root_script.sh". It should take care of the rest. Make sure you have USB Debugging enabled and you put the phone in Camera mode, not mass storage device.
Windows:
---------
Unzip ICS404root.zip wherever you want and then run "rootscript.bat". Make sure you have USB Debugging enabled and you put the phone in Camera mode, not mass storage device.
*************************
*************************
Credit to miloj for finding this technique on the Transformer. (See the thread noted below and be sure to thank him!) I modified it to work on our devices.
http://forum.xda-developers.com/showthread.php?t=1704209
I'll put together a script to automate this process shortly, but if you're antsy like me, here's the lowdown:
1. Download the following files:
su: http://db.tt/ShPzea6I
debugfs: http://db.tt/bGFh43LZ
2. Save the two files downloaded above on /sdcard. (ie: mount your sdcard in windows and copy them over, or "adb push" them to /sdcard).
**Make sure you have your phone on Mount Camera mode, not as a mass storage device; otherwise, you won't be able to access your /sdcard directory via adb. **
3. In a linux terminal/Windows command prompt:
Code:
adb shell
[email protected]_maserati:/ $ cd /sdcard
[email protected]_maserati:/ $ cp su /data/local/12m/
[email protected]_maserati:/ $ cp debugfs /data/local/12m/
[email protected]_maserati:/ $ cd /data/local/12m
[email protected]_maserati:/ $ chmod 755 debugfs
[email protected]_maserati:/ $ chmod 755 su
[email protected]_maserati:/ $ mv batch batch.bak
[email protected]_maserati:/ $ ln -s /dev/block/mmcblk1p20 batch
[email protected]_maserati:/ $ exit
adb reboot
4. While you are waiting for the phone to reboot, type the following into your terminal/command window:
Code:
adb wait-for-device shell
5. Once you're back into the android shell:
Code:
[email protected]_maserati:/ $ cd /data/local/12m
[email protected]_maserati:/ $ rm batch
[email protected]_maserati:/ $ mv batch.bak batch
[email protected]_maserati:/ $ /data/local/12m/debugfs -w /dev/block/mmcblk1p20
(The following is entered at the "debugfs:" prompt)
debugfs: # cd xbin
debugfs: # write /data/local/12m/su su
debugfs: # set_inode_field su mode 0104755
debugfs: # set_inode_field su uid 0
debugfs: # set_inode_field su gid 0
debugfs: # quit
[email protected]_maserati:/ $ cd /data/local/12m
[email protected]_maserati:/ $ rm su
[email protected]_maserati:/ $ rm debugfs
[email protected]_maserati:/ $ exit
adb reboot
Done deal. Now you've got the "su" binary pushed to your /system partition and set with the proper permissions for execution. Download the Superuser app from the market and you're good to go. Make sure you update the su binary within the Superuser app as well to make sure you're up to date.
Awesome! Were you able to upgrade to the latest leak and not lose root? Btw, what carrier are you on? I figured out how to get tethering fully functional on rogers but the process requires root...
Sent from my XT894 running ICS
You bet. I had to fastboot the leaked .208 update over top of the .206 update yesterday because I messed up my /system partition; I had used the OTA Rootkeeper to keep root permissions when upgrading from .219 but had foolishly disabled it right before I bungled everything up.
So to sum it up, this method didn't require anything to be done before updating to the .208 leak; since it has nothing to do with the technical details of the kernel itself, I'm fairly certain it should work for the .200 or .206 leaks as well. Root permissions were obtained from a completely stock system.
I'm in Canada with Bell but it doesn't matter because I imported the phone from the US; Verizon is the only carrier that has this phone. At any rate, this method is pretty universal, it is preying on a vulnerability present in the stock init.rc file and I bet it would work on other phones such as the RAZR as well.
So we can confirm this is 100% working with Fastbooting back and moving to 208? If so I will probably jump on this immediately.
I am trying to do this method but I cant adb to detect my phone. Im on the .208 leak. Can anybody help?
Have you enabled USB Debugging in the Settings->Developer Options menu?
Rick#2 said:
Have you enabled USB Debugging in the Settings->Developer Options menu?
Click to expand...
Click to collapse
Yep.
Not able to reboot, trying manually...
Code:
debugfs: /data/local/12m/su: Permission denied
debugfs: su: File not found by ext2_lookup
debugfs: su: File not found by ext2_lookup
debugfs: su: File not found by ext2_lookup
Had to reboot manually twice. This is the only error message I received. Tried Superuser, but it stops.
I'm on .200 btw.
droidian1441 said:
Yep.
Click to expand...
Click to collapse
I'm having the same issue. I'm on the 208 leak. I start command prompt in windows then type "adb shell" and I get the "device not found" message. I enabled usb debugging and my phone is connected as mass storage.
Likewise, Reboot requires su access, manual only. When I go and run the write command in debugfs permission denied. Any ideas what would cause this? Based on the code shown in the first post, SU had been already acquired(# vs $), which makes me wonder here.
Die Bruine said:
Not able to reboot, trying manually...
Code:
debugfs: /data/local/12m/su: Permission denied
debugfs: su: File not found by ext2_lookup
debugfs: su: File not found by ext2_lookup
debugfs: su: File not found by ext2_lookup
Had to reboot manually twice. This is the only error message I received. Tried Superuser, but it stops.
I'm on .200 btw.
Click to expand...
Click to collapse
Looks like you're doing something wrong with the debugfs command; you don't want to enter /data/local/12m/su at that prompt.
Running su from any partition other than /system will lead to a permissions error, so you don't want to bother trying to execute it from the /data/local/12m location.
(The following is entered at the "debugfs:" prompt, ie: after executing /data/local/12m/debugfs -w /dev/block/mmcblk1p20; see step 5.)
Code:
debugfs: # cd xbin
debugfs: # write /data/local/12m/su su
debugfs: # set_inode_field su mode 0104755
debugfs: # set_inode_field su uid 0
debugfs: # set_inode_field su gid 0
debugfs: # quit
Grizzy3 said:
I'm having the same issue. I'm on the 208 leak. I start command prompt in windows then type "adb shell" and I get the "device not found" message. I enabled usb debugging and my phone is connected as mass storage.
Click to expand...
Click to collapse
Ive got the same situation over here. I can stick without root, just the fact that I would have it again would be just the single reason to do it. Lol.
Sent from my DROID4 using Tapatalk 2
Code:
debugfs 1.42 (29-Nov-2011)
debugfs: cd xbin
cd xbin
debugfs: write /data/local/12m/su su
write /data/local/12m/su su
/data/local/12m/su: Permission denied
Rick, that's what we're putting in. From the code you posted it shows that you had root access already. Do you have any other suggestions on this? Because that's the in and out I get.
---------- Post added at 04:57 AM ---------- Previous post was at 04:53 AM ----------
Problem resolved. Need to run the following code:
Code:
chmod 755 debugfs
chmod 755 su
Then continue with rooting.
gdeeble said:
From the code you posted it shows that you had root access already.
Click to expand...
Click to collapse
Not sure where you're making this assumption from. I just wrote the "#" symbol in there to signal where to start entering commands... though I suppose you're correct in pointing out that the "#" shows up on a root prompt. A smarter choice probably would have been "$".
Trust me, I'm not an idiot. I wouldn't have gone through the hassle of writing up the guide in the first post if it didn't work.
Didn't mean it that way, just looked like it already had root, which was what confused me. But thanks again for this. :-D
Tried it again. This time no errors and the phone rebooted. But now Superuser keeps on FC .
Reinstalled superuser, updated and busybox. Now rooted! Thnx.
BTW, you might wanna update the OP. Do not batch the commands under windows. I tried several times. I think there is something wrong with the timing. Manually entering all the commands in a shell works. But putting them in a batch will enter them too fast for ADB to handle (under Windows shell) I guess.
Die Bruine said:
BTW, you might wanna update the OP. Do not batch the commands under windows. I tried several times.
Click to expand...
Click to collapse
I don't know, it seemed to work fine for me with the script I made. Anyways, glad it worked out for you.
Now that we can re-root as well as (somewhat convolutedly) fastboot ourselves back on track, we're good to go.
droidian1441 said:
Ive got the same situation over here. I can stick without root, just the fact that I would have it again would be just the single reason to do it. Lol.
Sent from my DROID4 using Tapatalk 2
Click to expand...
Click to collapse
As stated in the guide, you need to be in camera mode not mass storage.
Sent from my DROID4 using XDA
I was trying to do it manually last night before the OP posted the batch file, and it was not working because I was in MTP instead of PTP. SO make sure you use PTP.
Put your phone in camera (PTP) mode for the USB connection and it should work fine. Also, after it completes, download Superuser from the market.
I ran Titanium Backup after everything and it told me it needed to fix my su binary permissions or something like that... I let it do its thing... Either way, IT WORKED!!!!!
I put it in camera mode and made sure usb debugging is enabled. Then I ran the script for windows. Still getting the device not found error throughout. Really don't know what's going on.
Hi folks,
here's an easy-to-install busybox for your Galaxy Tab 2. NOW with Cyanogen Mod support.
ChangeLog:
BusyBox 1.21.0-git Nano1 (2012-07-28): initial release
BusyBox 1.21.0-git Nano2 (2012-07-29): applied various patches:
BUGFIX: flush all open files after listing them (ls)
BUGFIX: when setting hostname from file p**** whole name
COMPAT: ps now accepts (= ignores) all options a POSIX ps should
allow passing -mthumb to make
ash applet now exports HOME
silently ignore processes from inittab with terminal names without matching device file
default behaviour of 'showkey' applet changed from displaying interpreted keycode to decimals
do not show a message when testing an uninitialized variable
changed some terms in top applet output (rss vs. vsz)
BusyBox 1.21.0-git Nano3 (2012-08-05): major fix
NEW: rfkill applet¹
several minor modifications to applet
BUGFIX fixed a bug in busyinstall that left system without 'sh' upon uninstall²
provide busybox-patches to the world
BusyBox 1.21.0-git Nano4 (2012-08-15): minor fix / cm 10 edition
updated to latest git (some bugfixes)
BUGFIX: reading profile now works
BUGFIX: adjusted shell paths
BUGFIX: history now works
BUGFIX: no longer replace reboot on stock rom³
NEW: Cyanogen Mod edition (tested on cm10)
¹ Either redo 'busyinstall install', or do 'ln -sf /system/bin/busybox /system/bin/rfkill'
² You can find the original sh in you CWM backup, or here: http://www.nanolx.org/downloads/P3110/original-sh
If you didn't get /system/bin/sh.orig after 'busyinstall install', use this file as /system/bin/sh.orig
³ push new busyinstall into tablet to ensure future install/uninstall is fine. then do 'mv /system/bin/reboot.orig /system/bin/reboot'
from within 'adb shell' as root to get original reboot back.
Prerequisites:
* root access on your Tablet
Download:
busybox (normal): http://www.nanolx.org/downloads/P3110/busybox-nano4
busybox (debug): http://www.nanolx.org/downloads/P3110/busybox_unstripped-nano4
busyinstall (installer/stock): http://www.nanolx.org/downloads/P3110/busyinstall
busyinstall (installer/cm10): http://www.nanolx.org/downloads/P3110/busyinstall-cm
profile (optional): http://www.nanolx.org/downloads/P3110/profile¹
busybox (patches): http://www.nanolx.org/downloads/index.php?dir=P3110/busybox-patches/
¹ profile is a generic file, read on each startup of busybox. Mine sets HOME to /,
and puts /system/xbin/ in front of /system/bin/ in PATH. You can also adjust the
prompt (PS1) or whatever here, it's valid for all users. You could check for
'$(id -u) == 0' to adjust prompt for root, if not 0, for ordinary user.
Ordinary user should get 'busybox (normal)', rather than 'busybox (debug)'.
NEW INSTALLATION (STOCK ROM):
Putting busybox on internal sd-storage:
Code:
adb push busybox /mnt/extSdCard/
adb push busyinstall /mnt/extSdCard/
replace "extSdCard" if you saved busybox somewhere else
Code:
adb shell
su
chmod 0777 /mnt/extSdCard/busybox
chmod 0777 /mnt/extSdCard/busyinstall
/mnt/extSdCard/busybox remount -o rw,remount /system
/mnt/extSdCard/busybox mv -f /mnt/extSdCard/busybox /system/bin/
/system/bin/busybox mv -f /mnt/extSdCard/busyinstall /system/bin
busyinstall install
NEW INSTALLATION (CYANOGEN ROM):
Putting busybox on device:
in Settings > Development > set 'root access' to 'apps + adb'
Code:
adb root
adb shell
busybox mount -o rw,remount /system
exit
adb push busybox /system/xbin/busybox.nano
adb push busyinstall /system/bin/busyinstall
adb push profile /system/etc/profile # optional, if downloaded profile
adb shell
chmod 0777 /system/bin/busyinstall
busyinstall install
UPDATE:
Just download busybox, busyinstall and replace the ones in /system/bin/ - it will instantly work:
Code:
adb push busybox /system/bin/
adb push busyinstall /system/bin/
adb shell
su
toolbox chmod 0777 /system/bin/busybox # if you use windows, the executable bit might be missing in the uploaded file
chmod 0777 /system/bin/busyinstall
UNINSTALLATION:
Code:
ab shell
su
busyinstall --
That's it!
I tested everything and it does work perfect, either way a backup (CWM) is always recommened, when working around with stuff down the stack.
Suggestions welcome.
Out of curiosity, what is the difference between what this does and what BusyBox (by Stericson) from the Play Store does?
Sent from my MB855 using Tapatalk 2
Jleeblanch said:
Out of curiosity, what is the difference between what this does and what BusyBox (by Stericson) from the Play Store does?
Sent from my MB855 using Tapatalk 2
Click to expand...
Click to collapse
mine is a newer version
has all features of busybox (stericsons free version does not have all applets in busybox enabled, eg. 'sh' applet is missing)
installation 100% GT-P3XXX optimized
As of now, mostly personal preference I'd say.
Edit: But I'm currently applying stuff from busybox-power (maemo) which adds serveral bugfixes and stuff to busybox.
OK, improved version of busybox available in post 1 (+ changelog)
OK, thanks for letting me know!
I actually haven't done much with my Tablet lately as I've been busy with my phone as that now has CM10 too
But once I get my phone all set I'll use your BusyBox and give it a go!
Also, you said your busybox version is newer...but busybox via my phone is version 1.20.2. Just letting you know!
Thanks for this btw, I'd rather have a modified version optimized for my tablet versus a more universal version so to speak. Plus, with your updated applets! Thanks!
Sent from my MB855 using Tapatalk 2
Jleeblanch said:
Also, you said your busybox version is newer...but busybox via my phone is version 1.20.2. Just letting you know!
Sent from my MB855 using Tapatalk 2
Click to expand...
Click to collapse
Oh, ... mine is 1.21.0-git - fixed the typo
First,thank you for your work,second I've a question: I've an p3100 (wifi+gsm) ,it rooted on stock 4.0.4 ,and no busybox installed.It has 16gb onboard ,and I don't have at the moment any external microsd in slot,I've ordered an 32gb,but it hasn't come yet.Can you please tell me if it's safe puting your files in /sdcad (not ExtSdCard like you wrote) and give the commands using ''sdcard'' word ?
For e.g:
db shell
su
/mnt/sdcard/busybox remount -o rw,remount /system
I need busybox to backup my /efs folder ,but I don't want to screw something,so please tell me if it is safe to use internal memory (sdcard) for busybox install?Also ,when I'll receive the microsd ,I will need to install again busybox with your original commands from this topic ?
Thanks a lot!!
Best Regards!
viasat said:
First,thank you for your work,second I've a question: I've an p3100 (wifi+gsm) ,it rooted on stock 4.0.4 ,and no busybox installed.It has 16gb onboard ,and I don't have at the moment any external microsd in slot,I've ordered an 32gb,but it hasn't come yet.Can you please tell me if it's safe puting your files in /sdcad (not ExtSdCard like you wrote) and give the commands using ''sdcard'' word ?
For e.g:
db shell
su
/mnt/sdcard/busybox remount -o rw,remount /system
I need busybox to backup my /efs folder ,but I don't want to screw something,so please tell me if it is safe to use internal memory (sdcard) for busybox install?Also ,when I'll receive the microsd ,I will need to install again busybox with your original commands from this topic ?
Thanks a lot!!
Best Regards!
Click to expand...
Click to collapse
Of course you can. It does not matter where you put busybox. All that matters is, that you adjust the commands to your path.
In your you would push the files using ADB, like
Code:
adb push busybox /mnt/sdcard
adb push busyinstall /mnt/sdcard
also you don't need to re-do this when you got your sd-card, because during the steps you move busybox/busyinstall into /system/bin/.
Edit: updated instructions to clarify this.
Ok,thank you for your time,everything it's clear now.I'll try later,when I'm going home.
Cheers!
---------- Post added at 07:04 PM ---------- Previous post was at 06:11 PM ----------
OK,first problem:when I try to execute the first comand,it gives me ''permission denied'',so after a little reading,because my kernel it's stock,I've installed Chainfire's ''adbd Insecure v1.0 '' http://forum.xda-developers.com/showthread.php?t=1687590 to give me rights.After that I've no more errors,but,when I execute first command in adb,it says nothing,just hanging,and adb doesn't come back to # symbol ,and because of that I can't execute the next command.Any ideea what I'm doing wrong?Thanks!
What command failed?
Gesendet von meinem GT-P3110 mit Tapatalk 2
I don't know how to explain,it not really failed, but when I type
/mnt/sdcard/busybox remount -o rw,remount /system the adb doesn't return anything back,and doesn't come back to # symbol ,it just staying,nothing more,no response.I was waiting 2 minutes,and nothing ,doesn't return to # .I can type the next command
/mnt/sdcard/busybox mv /mnt/sdcard/busybox /mnt/sdcard/busyinstall /system/bin/
it's the same,no output,nothing.
Can you please tell me what I'm doing wrong?
Thanks again!
Now I'm stuck,even with adbd insecure activate I cannot execute commands:
C:\Documents and Settings\X\Desktop\ADB>adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ # /mnt/sdcard/busybox remount -o rw,remount /system
/mnt/sdcard/busybox remount -o rw,remount /system
/system/bin/sh: /mnt/sdcard/busybox: cannot execute - Permission denied
126|[email protected]:/ # /mnt/sdcard/busybox mv /mnt/sdcard/busybox /mnt/sdcard/busy
install /system/bin/
dcard/busybox /mnt/sdcard/busyinstall /system/bin/ <
/system/bin/sh: /mnt/sdcard/busybox: cannot execute - Permission denied
126|[email protected]:/ #
Maybe I need first to install Stericsson's busybox from Market?At the moment,as I said before I don't have busybox installed at all,only su.
One more thing,every time when I save from your link busyinstall,no matter what browser,the file is saved as busyinstall.txt
It is normal ,or I need to rename it?
Thanks a lot!
Hmm... seems I forgot a little thing.
do this after you put busybox on tablet, before anything else:
Code:
adb shell
su
chmod 0777 /mnt/sdcard/busybox
then follow the rest of the instructions.
/goingtofixfirstpost
Same story,take a look:
[email protected]:/ # chmod 0777 /mnt/sdcard/busybox
chmod 0777 /mnt/sdcard/busybox
[email protected]:/ # chmod 0777 /mnt/sdcard/busyinstall
chmod 0777 /mnt/sdcard/busyinstall
[email protected]:/ # /mnt/sdcard/busybox remount -o rw,remount /system
/mnt/sdcard/busybox remount -o rw,remount /system
/system/bin/sh: /mnt/sdcard/busybox: cannot execute - Permission denied
126|[email protected]:/ #
Hmmm... > could you provide me the details of 'adb logcat'? Ensure to run those commands while logging.
Gesendet von meinem GT-P3110 mit Tapatalk 2
I don't know if this is what you want,but here we go:
I'm going to check your logs soon and report back.
Meanwhile I updated to Nano3 - see first post.
I got no clue why it does not work for you, but me.
What boot image and ROM are you using? Default boot/ROM, rooted boot/ROM, cyanogen?
I only tested default ROM with my boot. Currently testing cyanogenmod 10, but except some adjustments to busyinstall it will work there, too.
Sorry for the late reply,I'm on vacation until Sunday,and my acces to internet it's very limited here.Now,regarding my problem,first when I got the tablet it was on stock 4.0.3 ,wich I rooted manually to keep the counter to 0 (for warranity) ,and after that I updated to stock 4.0.4 using Mobile Odin Pro,with Everoot option ( it's rooting the rom on the fly) .So now I'm rooted on stock 4.0.4 ,stock recovery, and no busybox installed.I fell more secure and want to install your busybox version,because it's specialy designed for tab2,and it's has features from Maemo (I'm a big fan,I owned an N800,and I've also an N900 ).Maybe,if you have the time and the skills,you can pack it on an .apk version,if it's possible,of course.I will try more Sunday,when I'll be back home.Thanks again for your patience and help.Best Regards!
It will be great if we have a kernel (even stock) with CWM and this busybox...
I am also rooted with flash counter 0 and stock recovery.
Sent from my GT-P3110 using Tapatalk 2
Maybe some contributor creates a flashable zip (for CWM).
So... uploaded 1.20.1-Nano4. See first post for changes.
This time an addtional install-script for cyanogen mod was added, along some fixes.
ah... and: 100th post
Hello, everyone.
In order to avoid an XY problem, I would like to introduce the actual problem first.
I need to run a script each time network changes. Android automatically changes quite a few settings when network changes, and because I need to have some of them set to specific values, I need to tweak them each time something happens.
How would I like to proceed:
There is a sysprop setting that changes each time network changes: sys.radio.cellular.netId.
Naturally, I would like to hook my script to that property change.
Android init system seems to provide such an option: init.rc syntax allows to subscribe to a property change using the
Code:
on property:propname=*
syntax.
Seems easy:
Add a custom_network.rc
Bash:
on property:sys.radio.cellular.netId=*
start custom_network
service custom_network /bin/custom_network.sh
user root
seclabel u:r:magisk:s0
oneshot
Add a file /bin/custom_network.sh:
Bash:
#/system/bin/sh
echo "TODO"
The above is essentially following this guide: https://android.stackexchange.com/q...run-an-executable-on-boot-and-keep-it-running
So, I created a magisk module, added the files above to the $MODDIR/system/etc/init, and $MODDIR/system/bin directories.
Then I added the following lines to the customize.sh:
Bash:
set_perm $MODPATH/system/bin/custom_network.sh 0 0 0755
set_perm $MODPATH/bin/custom_network.sh 0 0 0755
chown 0.0 $MODPATH/system/etc/init/custom_network.rc
chmod 0644 $MODPATH/system/etc/init/custom_network.rc
chcon u:object_r:system_file:s0 $MODPATH/system/etc/init/custom_network.rc
However, this does not work. The service custom_network does not appear in the getprop | grep svc list, and cannot be started with setprop ctl.start "custom_network".
Is it true that in order for _any_ custom rc files, the system boot image must be patched?
If yes, is there a manual how to do so?
If no, then what am I doing wrong here?
Furthermore, if patching the boot image cannot be avoided, is there a manual on how to do this with minimal pain?
On the other hand, is there a way to avoid adding a custom init service entirely, and add a network listener by some other means?
Did you figure it out?
I don't believe init services get a stdout.
You need to write to either /dev/kmsg or logcat.
You can test your service with start custom_network.
You could also listen for uevents:
Code:
s=socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT);
Although I'm not sure what you're looking for is there.
I was mostly looking for feedback by someone also wanting to patch the init.rc: I'm still trying to understand the cascade of events causing adbd to be started twice in boot, to find and modify the rc script responsible for the first time it's started and use instead a patched adbd
csdvrx said:
I was mostly looking for feedback by someone also wanting to patch the init.rc: I'm still trying to understand the cascade of events causing adbd to be started twice in boot, to find and modify the rc script responsible for the first time it's started and use instead a patched adbd
Click to expand...
Click to collapse
have you figured it out ? i have the same issue , i am trying to create a file at /system/etc/init folder