Related
One click root with impactor now works. Works on <4.3. No need for unlocked bootloader. Does not wipe data.
http://www.saurik.com/id/17
Copy over the superuser.apk and the such binary onto your phone, then use the MV command to move it to /system/app and /system/xbin respectively.
Beamed from my Grouper
Mach3.2 said:
Copy over the superuser.apk and the such binary onto your phone, then use the MV command to move it to /system/app and /system/xbin respectively.
Beamed from my Grouper
Click to expand...
Click to collapse
What should the permissions on each be?
EDIT: Can you alternatively only push the su binary and download superuser from gplay?
krackers said:
What should the permissions on each be?
EDIT: Can you alternatively only push the su binary and download superuser from gplay?
Click to expand...
Click to collapse
If the binary is wrong, the one from play store may not work.
Permission should be rw-r-r(0644) for the su.apk and rwsr-sr-x(0645) for the su binary.
Beamed from my Maguro.
I tried it myself and while it appears that commands do run, they don't appear to work. I think it might have to do with running as system vs running as root. Why else would saurik use an indirect method of gaining root (using ro.kernel.quemu) as opposed to directly pushing the su binaries.
krackers said:
I tried it myself and while it appears that commands do run, they don't appear to work. I think it might have to do with running as system vs running as root. Why else would saurik use an indirect method of gaining root (using ro.kernel.quemu) as opposed to directly pushing the su binaries.
Click to expand...
Click to collapse
This is correct: sometime in the Android 4.1 release cycle, they removed the ability to use /data/local.prop as an attack vector to go from system->root. The signature bug lets you modify the code of any APK, but the most powerful user an app can ever run as is system, not root.
However, in an update to Impactor today, I've added a system->root escalation. This allows one-click rooting, and even though the system->root I'm using has already been patched in AOSP (the idea was not to waste something to go along with a shell->system that is already long burned) it works on my 4.2.2 Nexus 4 (and so I'd imagine will also work fine on a Galaxy Nexus) as Android sucks at getting patches to real devices ;P.
Using Impactor on my Panasonic Eluga dl01 does somehow not work.
(Android 4.0.4)
I get following error message:
/data/local/tmp/impactor-6[3]: /data/local/tmp/impactor-4: Operation not permitted
I also tried and played around with the command line in Impactor.
"adb devices" won't list my phone
But when I use the adb from the current Android SDK I just installed, it will display my phone with "adb devices".
I also downloaded a ICS 4.04 root zip file with a script and adb files inside. When using that adb version, my phone won't be displayed too. Now when I run adb from the android SDK, it will say something like "server is outdated" then something like "kill and restart with new server" --> "adb devices" lists my phone correctly again.
May be the adb version used in Impactor is outdated and responsible for the error message?
I would really appreciate any help with this topic, because the Panasonic Eluga phone was never rooted until now and no known root method is available. I always kinda hoped that someone would use the masterkey thing to make a universal rooting tool
saurik said:
This is correct: sometime in the Android 4.1 release cycle, they removed the ability to use /data/local.prop as an attack vector to go from system->root. The signature bug lets you modify the code of any APK, but the most powerful user an app can ever run as is system, not root.
However, in an update to Impactor today, I've added a system->root escalation. This allows one-click rooting, and even though the system->root I'm using has already been patched in AOSP (the idea was not to waste something to go along with a shell->system that is already long burned) it works on my 4.2.2 Nexus 4 (and so I'd imagine will also work fine on a Galaxy Nexus) as Android sucks at getting patches to real devices ;P.
Click to expand...
Click to collapse
Do you need to have an unlocked bootloader for the root exploit to work? I am hoping to get root without having to wipe the device by unlocking.
To the poster above me: Try using a different computer and if that doesn't work, switch operating systems.
krackers said:
Do you need to have an unlocked bootloader for the root exploit to work? I am hoping to get root without having to wipe the device by unlocking.
Click to expand...
Click to collapse
That's the whole point in securing Android, not that people have easier ways instead of unlocking a device.
Tested and works great. I now have root. Yay!
Does it show any of the problems that chainfire's superSU 1.41 shows?
Sent from my Galaxy Nexus using xda app-developers app
The root exploit only places the su binary and sets the right permissions. You can use any root manager you want (I used clockworkmod's superuser app).
mercuriussan said:
Using Impactor on my Panasonic Eluga dl01 does somehow not work.
(Android 4.0.4)
Click to expand...
Click to collapse
The feature of installing su will not work on every device: a lot of emphasis is put on "rooting" Android devices, but on many devices even root can't do things like modify the files in /system; I'd use the term "jailbreak" as to being what people really want to do with their device, but Android people seem to have that term ;P. What this means is that you really need a kernel exploit, not just a shell->system->root escalation.
mercuriussan said:
I get following error message:
/data/local/tmp/impactor-6[3]: /data/local/tmp/impactor-4: Operation not permitted
Click to expand...
Click to collapse
This error message actually indicates that Impactor succeeded in obtaining root control over your phone. However, when it tried to then, as root, remount /system writable so it could copy the su binary in place, it wasn't allowed to do so. A future version of Impactor will make it easier to drop to a root shell so you can test things out manually, but this means that while you can run code as root, you won't be able to install su.
However, if you have the time to play with it, get a copy of busybox and use adb to push it to /data/local/tmp (this is also something Impactor should help you do, but does not yet). (You will also need to make it executable, don't forget: "chmod 755 /data/local/tmp/busybox".) Then run the suggested Impactor command involving telnetd. Finally, via a shell, run "/data/local/tmp/busybox telnet 127.0.0.1 8899": you are now root.
You can verify that you are root because you will now have a # as a prompt instead of a $. Then run "mount -o remount,rw '' /system" (<- note, that's two single quotation marks as an argument between remount,rw and /system). This is the command that should fail with the "Operation not permitted" message. You are, however, root, so maybe there's something you want to do on the device at that point ;P.
mercuriussan said:
I also tried and played around with the command line in Impactor.
"adb devices" won't list my phone
But when I use the adb from the current Android SDK I just installed, it will display my phone with "adb devices".
Click to expand...
Click to collapse
The "Open Shell" in Impactor connects you to the device via adb: if you run adb on the device and ask for a list of devices attached to the device--something I didn't even realize was possible until you pointed it out here ;P I tested it, though, and wow: that actually is possible--you will get a blank list. However, suffice it to say that if you were able to type that at all, it can see your device.
Thanks for the suggestion, I'll try my luck in finding some exploit I can use...
So since Google patched this in 4.3, does this mean almost all devices before 4.2.2 can be rooted with this method?
bmg1001 said:
So since Google patched this in 4.3, does this mean almost all devices before 4.2.2 can be rooted with this method?
Click to expand...
Click to collapse
Yup - assuming they haven't been patched against the methods used (most haven't been).
Very interesting read. Thanks saurik & OP.
Eluga DL1
Hi there,
this post is in some ways a duplicate but different people seem to follow this thread because it is directly involving sauriks impactor.
Is there anything available that i can throw at Elugas 4.0.4 kernel to get r/w on the system partition?
I will try everything that is suggested to me.
So, by going into the settings menu of the FTV and toggling the ADB Debug flag, this allows for installing via a push from ADB.
The text that is displayed when changing this value also says that by enabling the setting, it allows for package installs from unknown sources.
Is this not quite the case though?
Using ES File Manager, when selecting an apk package located in the downloads folder on the device, the message shown in the attached screenshot appears.
Since there's no way to do so from the front-end, I am assuming that we will need root to change the flag to truly allow installing from any source?
Any possible way to do this without root?
mkhopper said:
So, by going into the settings menu of the FTV and toggling the ADB Debug flag, this allows for installing via a push from ADB.
The text that is displayed when changing this value also says that by enabling the setting, it allows for package installs from unknown sources.
Is this not quite the case though?
Using ES File Manager, when selecting an apk package located in the downloads folder on the device, the message shown in the attached screenshot appears.
Since there's no way to do so from the front-end, I am assuming that we will need root to change the flag to truly allow installing from any source?
Any possible way to do this without root?
Click to expand...
Click to collapse
Yeah, this isn't currently possible for the public. There is a root exploit(s) already developed but they have not been released yet. The developer, jcase, said he will release an exploit on the same day the upcoming Fire TV update is pushed (the exploit will not be compatible with the update so if you want it you'll need to follow the instructions in the other thread for blocking OTA updates).
mkhopper said:
Any possible way to do this without root?
Click to expand...
Click to collapse
Are you having issues with ADB? We can probably help you get those resolved.
Chahk said:
Are you having issues with ADB? We can probably help you get those resolved.
Click to expand...
Click to collapse
Thanks, but no. I use the automatic tool to push packages with no problems. I was just looking for other methods of package installation that could be done directly while on the FTV.
mkhopper said:
Thanks, but no. I use the automatic tool to push packages with no problems. I was just looking for other methods of package installation that could be done directly while on the FTV.
Click to expand...
Click to collapse
Not at this time. Amazon disabled side-loading of APKs from the device itself. Root would be the only way to get around that.
mkhopper said:
Thanks, but no. I use the automatic tool to push packages with no problems. I was just looking for other methods of package installation that could be done directly while on the FTV.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=2715315
Sent from my MZ617 using XDA Premium 4 mobile app
Kramar111 said:
http://forum.xda-developers.com/showthread.php?t=2715315
Click to expand...
Click to collapse
several days ago it occurred to me to alternatively use sshd for terminal access, because:
-a) I feel a little unsafe leaving adb wifi enabled all the time (ok it's only a small thing to turn it on and off, but still) - and for security reasons there is no way to enable/disable it programmatically e.g. from a script/shell/terminal/app (well theoretically this is not exactly true, but practically it is)
-2) some people (i.e. me) would like to do shell/terminal remotely sometimes, rather than on the AFTV (and other people don't have/want a keyboard)
ssh access makes a great alternative to Term.apk, but the problem is:
- Term.apk and/or (pick your favorite android ssh server) don't have permission to run e.g. "pm install foo.apk" - it will fail. (btw 'pm' is a great command, take a look sometime at all the options. it shares a lot of functions as the adb command itself. 'am' is another fun command...)
- so, the hilarious workaround of enabling adb wifi, "adb connect", and then finally "adb shell" or "adb install" etc., is still required. (b/c the adb user is in the 'shell' group, among others - giving it permission to run /system/bin/pm) - oh well.
for random reference:
Code:
127|[email protected]:/ $ id
uid=2000(shell) gid=2000(shell) groups=1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
[email protected]:/ $ exit
[email protected]:/ $ id
uid=10009(app_9) gid=10009(app_9) groups=1015(sdcard_rw),1028,3003(inet),50009(app_40009)
(also note it appears the adb shell user might possibly have 'mount' abilities, but since the /dev/block/sd* nodes permissions' are really locked up, who knows...)
A bash exploit has been discovered that may give hope to rootless devices. In theory, install an apk with a vulnerable bash binary and run a script to gain root.
Keep an eye on this one
jocala said:
A bash exploit has been discovered that may give hope to rootless devices. In theory, install an apk with a vulnerable bash binary and run a script to gain root.
Keep an eye on this one
Click to expand...
Click to collapse
This has nothing to do with gaining root. The only way you gain root is by having a binary that already runs as root that has an exploit or finding an exploit in the kernel. Installing an apk with bash in it won't magically make bash run as root.
rbox said:
This has nothing to do with gaining root. The only way you gain root is by having a binary that already runs as root that has an exploit or finding an exploit in the kernel. Installing an apk with bash in it won't magically make bash run as root.
Click to expand...
Click to collapse
Sorry, you're mistaken. It has everything to do with gaining root, that's why this is marked as a urgent remote vulnerability. You exploit a bug in bash to gain a # prompt, at least in theory. It also applies to ssh.
Will it apply to the various android bash binaries? I have no idea.
jocala said:
Sorry, you're mistaken. It has everything to do with gaining root, that's why this is marked as a urgent remote vulnerability. You exploit a bug in bash to gain a # prompt, at least in theory. It also applies to ssh.
Will it apply to the various android bash binaries? I have no idea.
Click to expand...
Click to collapse
No, there is no magic. The entry says
"use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables"
This means if a service or application which was running as another user (lets say root) and you provided it environment variables that exploited this vulnerability, then you could make it do stuff as root. But you'll only be able to make it do something that user could already do. Since there is no way to make a bash binary run as root in the first place, you aren't magically going to get root.
rbox said:
No, there is no magic. The entry says
"use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables"
This means if a service or application which was running as another user (lets say root) and you provided it environment variables that exploited this vulnerability, then you could make it do stuff as root. But you'll only be able to make it do something that user could already do. Since there is no way to make a bash binary run as root in the first place, you aren't magically going to get root.
Click to expand...
Click to collapse
Here's more info:
http://www.csoonline.com/article/26...ity/remote-exploit-in-bash-cve-2014-6271.html
This has to do with Privilege Escalation -- it has nothing to do with a binary that already has root privileges. That's why security mavens are so freaked by this possible exploit. Lots of devices routinely run bash with non-root access; the possible exploit is to make bash crash, leaving you at a # prompt.
More info:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
jocala said:
Here's more info:
http://www.csoonline.com/article/26...ity/remote-exploit-in-bash-cve-2014-6271.html
This has to do with Privilege Escalation -- it has nothing to do with a binary that already has root privileges. That's why security mavens are so freaked by this possible exploit. Lots of devices routinely run bash with non-root access; the possible exploit is to make bash crash, leaving you at a # prompt.
Click to expand...
Click to collapse
I see nothing in there to indicate anything remotely related to privilege escalation. You can't gain root from thin air. If that were the case, it would be a kernel bug. This is just a vulnerability that can make the bash shell do something other than the script it's running says it should do. But it can't gain the ability to become a root shell.
A good example of a way to exploit this is passing in a specially crafted header into a cgi script, causing it to send that in to a bash shell, which would then be running arbitrary commands as the user of the cgi script. Similar to SQL injection where you cause the SQL server to run arbitrary commands.
Hi XDA,
I am fairly new at the flashing community and I need a quick guide on how to grant Superuser permissions without having to install SuperSU or Superuser managing application. I do not need the application manager to grant which applications gains permissions. I just need all applications to gain Superuser access rights all the time on my devices. I'm aware that my devices will be at security risk and vulnerable and maybe I should just hide the Superuser managing application and allow applications to gain access all the time, but I would like to know which files to flash to allow Superuser access. I do not need SuperSU or Superuser managing applications on my devices if I am going to allow all apps to gain Superuser access at all times. I know this might upset people but I would just like to learn it.
Sample Device Usage:
Nexus 7 (2013) Android Lollipop 5.0.2
Using WugFresh Root Toolkit to automate flash and root but I need it to root without installing SuperSU or Superuser Manager.
(Please excuse me if I used the wrong terminologies and caused confusion!)
Thanks!
You're drunk, go home.
Antitype said:
Hi XDA,
I am fairly new at the flashing community and I need a quick guide on how to grant Superuser permissions without having to install SuperSU or Superuser managing application. I do not need the application manager to grant which applications gains permissions. I just need all applications to gain Superuser access rights all the time on my devices. I'm aware that my devices will be at security risk and vulnerable and maybe I should just hide the Superuser managing application and allow applications to gain access all the time, but I would like to know which files to flash to allow Superuser access. I do not need SuperSU or Superuser managing applications on my devices if I am going to allow all apps to gain Superuser access at all times. I know this might upset people but I would just like to learn it.
Sample Device Usage:
Nexus 7 (2013) Android Lollipop 5.0.2
Using WugFresh Root Toolkit to automate flash and root but I need it to root without installing SuperSU or Superuser Manager.
(Please excuse me if I used the wrong terminologies and caused confusion!)
Thanks!
Click to expand...
Click to collapse
That's not how it works. You're not on Windows anymore.
Just hide the app and be done.
What you are asking can probably be done, but it will never be done, because of the security risks.
You can set SuperSU to grant without a pop-up.
I think I already know the answer but you'll never know.....
I am looking into options to use LOS17 in combination with LOS recovery because then it is possible to have OTA updates even when storage is encrypted.
Though, I would like to have the option to use a script so I can remove some system apps, add some stuff to build.prop and remove some temporary files after every OTA.
As far as I know the only way this is possible is to add an a script to /system/addon.d.
Therefor I have tried using adb to push a file, though when phone is not rooted, it is not possible to use adb root and then adb remount rw and adb push.
So here the questons;
- Is is possible to add a script to /system/addon.d, though without root and without TWRP?
- When not; is there another way to run a script after every OTA without root and without TWRP?
Setup:
LOS 17.1 without root, encrypted and locked bootloader
I will answer myself as it seems OR a stupid question OR something else....
But, as already expected, without root en with a locked bootloader, the recovery is the only place where you can do something root-related when the recovery is giving this option ofcourse. LOS recovery, automatic OTA updates and additional scripts is therefor not possible because you can not place or modify stuff in /system (as it should be out of security concerns on non-rooted devices).
Though, @nvertigo67 posted a nice post about this topic. After reading I realised that, as I want to be in control of my phone AND I want to pay something back to our great dev's, I will definitely stick with TWRP and flashing and running scripts myself.
How to install LOS with TWRP, encrypt en relock bootloader can be found here.
Topic closed for me.
I messed it up myself with my modified build.prop settings:
By design adb root command works in development builds only (i.e. eng and userdebug which have ro.debuggable=1 by default). So to enable the adb root command the ro.debuggable=1 line must be in build.prop, which I have set to 0 for CTS reasons.
Unfortunately it seems my banking app is looking for this parm because when set to 1 the app is giving an error message on startup.
So no adb root for me as long as I want to use the banking app.