Related
I've been trying to fix this problem for a long while, especially since I would like to install busybox on my Hero. I currently have root access (as can be seen through root explorer), and I have no trouble flashing to custom roms and things like that, but when on the base, rooted HTC Hero it seems the only command that doesn't work in the console is 'adb remount'.
The only time I have ever had it work was when I stumbled upon a guide on how to do it (I have since lost the link), but there was something in the update.zip file included with the guide that completely disabled wifi and left GPS perpetually on, which to mean is not worth it just to have remount access.
I know mostly everyone on this forum has no trouble getting remount access, since every thread seems to use it, but how do I get access?
Thank you!
I'm having the same problem, albeit on a Sprint Hero. I'm definitely rooted. I flashed multiple ROMs before using a Nand backup to revert to stock... and since then I've used shell to uninstall some stock apps. But I get 'permission denied' anytime i try the remount command. It's frustrating.
Did you modify your boot.img file so that ro.secure is now = 0?
On GSM Hero, you need to do that if you want to use ADB in root mode. I don't know exactly what would need to be done on your CDMA phone, but on the GSM, you need to extract the boot.img ramdisk, and then edit init.rc (see http://forum.xda-developers.com/showthread.php?t=443041&page=2)
Try running this command-
Code:
getprop ro.secure
and see if you get a 1 or a 0. If it's a 1, then ADB should not see the device as rooted, so find out about editing the boot.img file. If a 0, I don't know what's going on.
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.
How to enable ADB on ALLWINNER A13 9" - 4.2.2 - Windows 7 - error:device not found
Hi folks, my target is to do a full backup of my android tablet device without rooting nor installing app's on the device. It can be done just by the ADB tool and the simple command
Code:
adb backup -apk -shared -all
.
Basic information
PC: Windows 7, pro. USB 2.0 port. ADB Driver "Drivers-AllwinnerA10-32bits\32Bit_Win_7_Vista_XP" from 2011. ADB Platform-Tool, Android Debug Bridge version 1.0.31. Logged in as normal User, not Admin. The development kit is not installed, I just downloaded the Platform-Tool, unzipped it and started "adb" - I just want to make a f***ing backup :crying:
Tablet:
ALLWINNER A13 9". Android Version 4.2.2. USB Debugging enabled. Detail Info's:
Model number: JL902
Kernel Version: 3.4.0+ [email protected] #1 Mon 25.11.2013
Build-Number: full_gs702c-userdebug 4.2.2 JDQ39 eng.root.20131207
NOT ROOTED.
Problem:
I do not get a connection from the PC to the tablet. Also no RSA Key question comes up at the tablet. The adb tool just throws an error :"device not found". I tried several things, log in as Admin, "adb wait-for-device", plugging and unplugging ... nothing helped. The adb tool works fine, I tested it with a Samsung Galaxy S2. I'm not quite sure about the adb USB driver on windows, but there is no exclamation mark nor other problems reported. So this should be fine.
Anyone any hint, tip or solution? Would be great - gathering for hours with this problem - searching forum 'n stuff....
Thanks in advance
Juha
Try with uberizer or MTKDroid tools. Just connect and select adb terminal.
kramkumar said:
Try with uberizer or MTKDroid tools. Just connect and select adb terminal.
Click to expand...
Click to collapse
Thx 4 the hint, tried uberizer:
Code:
ERROR No useable device has been found
I think since in Android 4.2.2 the RSA Key authentication was introduced, something is wrong with the connection. Because I would expect the RSA Key question on the tablet, but the tablet does not show this dialog.
By the way, I recognized that the USB driver for the ADB interface is titled "Drivers-AllwinnerA10" but the tablet has a A13 core. But I do not find another driver at the moment and the vendor ID -VID_10D6&PID_0C02&REV_0202&MI_01- fits (otherwise, windows wouldn't install it anyway). Does it make sense to search for another driver?
hi from messing with various drivers and android devices i have found that installing PDA net for windows (theirs and android version too but not needed) once pdanet installs let the drivers for your phone be installed, if by any chance you have drivers already installed what you can do is go to device manager, click on your device uninstall the drivers, unplug your phone and then open pdaNET a window will come up waiting for you to connect your phone and the driver installation process will begin.
The program downloads the correct driver for mostly any model phone you have and works flawlessly with ADB, if by any chance this helped just give me a thanks !
abstractVoid said:
The program downloads the correct driver for mostly any model phone you have and works flawlessly with ADB, if by any chance this helped just give me a thanks !
Click to expand...
Click to collapse
Thanks for the tip. It really installed an USB driver as you said (I've deinstalled the other driver before). But sadly the result is the same. I can't access the ADB interface - same error "Device not found".
At this point I want to say thanks to all viewers of this thread, it seems really to be not an easy task. I'm still open minded in any direction and would be happy for any suggestion what I might try.
Even a hint, how I could reduce the possibilities for the root of my problem. I'm still not quite sure, if the driver is the problem or even if the tablet itself has some kind of software defect on this kernel version - By the way, does anyone have the same kernel version (posted at the beginning - 3.4.0+ [email protected] --- repeated for your convenience) of Jelly Bean (4.2.2)? Do you have experience with the ADB interface then?
How may I isolate the real problem? Any idea wellcome :cyclops:
I have nearly an identical tablet except mine has the PnP code of Vendor 10D6/Device 0C01 and it shows as P706 on the USB description.
I installed PDAnet, that actually was able to upload the Android version of PDAnet to the tablet, so I think that's a definite for the driver working. But I'm also having trouble getting ADB to list the device and I'm using the latest ADB from the SDK. Since ADB tries to setup a network server, I'm wondering if the ADB driver on windows has to be tethered as a NIC somehow?, just a theory.
I'm using a fresh install of XP and can do a complete rollback, so I'm certain it's not the OS.
There's also another quirk about this tablet. I wanted to do a backup of the firmware from this device. Techknow's utilities use ADB to issue several shell commands to copy "partitions" to the SD card, I thought I might as well try to do that manually only to find what would've been copied as /dev/block/nanda, nandb, etc. is named /dev/block/acta, actb, etc. instead. But lack of "root" means I can't read any of those partitions or even copy su into /sbin.
Uberizer isn't any good since as far as I can see that also uses ADB. Any known issues with versions of ADB? or even any other tools which do similar to ADB?, or even a way to "root" these devices just by Terminal and SD?
Regards
Ah, okey, soz I got the USB thing a bit mixed up. My tablet does have the same code, I assume the 0C01 is when it's in recovery mode (power on with volume + pressed)
I also realised the driver that was working wasn't one from PDAnet.
I've updated the working 32-bit driver with the version of ADB I'm using and included it in the attachment. Maybe you can try that and see if you have any progress.
I'll keep posted on this thread.
SOLVED!
Copy .android from the attachment into your %USERPROFILE% directory (i.e. C:\Document and Settings\<user> on XP or C:\Users\<user> on Windows 7)
You can check what the user directory is by DIR %USERPROFILE% in the "DOS" command line (%USERPROFILE% is case sensitive).
ADB should list your device when you do adb devices in the "DOS" command line.
Basically, adb_usb.ini with a custom identifier was missing.
Regards,
qUE
Right, I've made up a pack to automate putting SU on the device and setting up permissions on SU and BUSYBOX.
!!! This is only for the VID_10D6&PID_0C02 device, your mileage may very with other devices. !!!
DRIVER directory should contain the USB driver you need, otherwise try installing PDAnet and tell it to replace the driver.
Install USB driver, run SUME.BAT
to hopefully backup all the needed stock firmware to SD;
adb shell
su
cat /dev/block/acta > /mnt/sd-ext/acta.img
cat /dev/block/actb > /mnt/sd-ext/misc.img
cat /dev/block/actc > /mnt/sd-ext/system.img
exit
exit
adb kill-server
qUE
Confirmed solved
qUE-ARM said:
SOLVED!
Copy .android from the attachment into your %USERPROFILE% directory (i.e. C:\Document and Settings\<user> on XP or C:\Users\<user> on Windows 7)
<SNIP>
Basically, adb_usb.ini with a custom identifier was missing.
Click to expand...
Click to collapse
CONFIRMED SOLVED
Yes, that was it! I copied the adb_usb.ini file into the .android user directory (which only contains these ascii chars "0x10D6" - no CR no LF or anything else) and it worked out !!!
Thank you (Thanks meter will follow ) Some interesting things I discovered now:
There was no RSA-Key question at all on the tablet!!!
as I did the full backup with "adb backup -apk -shared -all" I was asked on the tablet to confirm this
So obviously something strange is going on here. Since it is claimed everywhere the with Android 4.2.2 the ADB interface should be generally RSA-Key protected. Okay, might be that I misunderstood something here :silly:
At least this problem is solved and I appreciated every comment in this thread. One question would be final to answer:
Who should have brought the adb_usb.ini to my PC. The ADB driver ? The ADB Platform-Tool package? So, whom to blame here - NO - just kidding :laugh:
I did briefly try the platform-tools (since I didn't mind the OS being trashed), they didn't add any adb_usb.ini and there isn't any real indication the file was needed/didn't exist, they could've simply put a note on the ADB utility when it didn't find any devices.
I'm not sure what ADB backup does. As far as I know the mounted partition images are differently named to various backup tutorials, so I get the feeling ADB backup just simply copies the user data and not much else. I recommend doing the backup I mentioned as well, it'll at least capture a copy of the boot partition, which if the device doesn't have that you'll probably need to revert to using live suite or some other firmware utility to restore it. Getting the firmware for that is another story, read a fair amount of posts here and other places on the net that don't sound fun.
I personally still can't get superuser to behave for using su on the terminal/term.apk (I want to remove useless "system" apps and make sure the device isn't talking back to anyone, i.e. google), but I'll keep tinkering.
My main aim for getting one of these tablets was to boot other firmware from the SD slot, but it looks as if the u-boot process is locked to internal NAND. So might have to modify it by adding "fatload mmc" to the script.
qUE
Quick Update;
Right the permissions thing turned out to be an issue with Superuser, dunno why. So replace the su binary from SuperSU (http://forum.xda-developers.com/showthread.php?t=1538053) into my SUME pack and install the Superuser.apk by;
adb root
adb shell mount -o rw,remount /system
adb push Superuser.apk /system/app
as for stripping back the Applications, I've got it down to this as bare bones
adb pull /system/app backup\system\app
to backup system applications before you do anything
I found if you do delete any applications and then android gets stuck at the logo, just adb push them back and it'll boot without reboot when you've got the chain right.
minimum applications needed for boot are;
DefaultContainerService.apk
DefaultContainerService.odex
SystemUI.apk
SystemUI.odex
Launcher2.apk
Launcher2.odex
Settings.apk
Settings.odex
SettingsProvider.apk
SettingsProvider.odex
ActSensorCalib.apk
InputDevices.apk
InputDevices.odex
FusedLocation.apk
FusedLocation.odex
LatinIME.apk
LatinIME.odex
PackageInstaller.apk
PackageInstaller.odex
ApplicationsProvider.apk
ApplicationsProvider.odex
A few odds and sods missing will make settings close, but it's trivial stuff. Personally don't like the sound of Fused Location, but it won't boot without it and I haven't seen any dodgey traffic from it (yet).
I recommend installing Droidwall with adb push /system/app, before installing games.
And modifying /etc/hosts with 127.0.0.1 to certain you know whos and advertisers.
Some of my personal choice replacement applications (so far);
Total Commander over ES file explorer.
Opera Classic over the inbuilt browser (although I'm still trying to remove the default search engine).
qUE
More update;
Discovered some new things;
BACKUP FILES WITH "ADB PULL" BEFORE MODIFYING ANY FILES!!!
I think performancepolicy.apk needs to be added to the bare bones application list, afaics from looking inside the package it sets system performance stuff, so likely throttling to preserve battery power.
bin_cfg.xml in /misc which can be modified by
adb shell mount -o rw,remount /misc
then adb pull, edit and push the file back
the line in there for "backlight_brightness" 780;1020;780 can be changed to 240;1020;240 which dims the backlight substantially saving battery power. not sure if 240 is the absolute minimum, but 120 seems to be too low afaics. interestingly information on the settings is in the files named _userview.xml
build.prop in /system which can be modified by
adb shell mount -o rw,remount /system
then adb pull, edit and push the file back
and then chmod 644 /system/build.prop
the lines in there for ro.wifi.signal.level.# can all be set to 0, this theoretically cuts the wifi power usage to less than 1mW, again saving battery. if android doesn't boot fully on reboot it's because chmod hasn't been set, you should be able to adb back in and correct.
please be careful modifying either file as both seem to have safety limits imposed on certain device components (i.e. battery temprature), messing with those can make the tablet stop working.
qUE
Let me start by first saying that "adb root" is not related to or the same thing as running adb shell then su. adb root is a way to run adb directly in root mode enabling to be able to push/pull files directly to /system, or other write protected directories. So please, lets not get into the whole "just copy to sdcard, mount system and cp file with adb shell." This is not what I am trying to accomplish. Now that that's out of the way, here is my situation. HTC10 Viper 4.4.0 US unlocked firmware. Generally speaking, in the past you could modify the boot.img and edit default.prop and set ro.debuggable=1 and/or ro.secure=0 and repack and flash. Problem solved. This does not seem to be the case now, with this device. I also tried compiling from source adbd from aosp, modified to ignore ro.secure etc... Packed it in the boot.img and reflashed. I get the same results. I get a message on boot about slow charging, and debugging mode is not running on the phone. Tried stopping and starting it, same thing. Can anyone please help me figure out what is going on? I assume HTC has some built in security check that disallows this modification, but im not sure. Thank you in advance.
Hi,
i tried to block OS Updates by changing ro.build.version.number in build.prop as mentioned here: http://www.aftvnews.com/how-to-bloc...k-by-setting-a-custom-fire-os-version-number/
Pulled the stock build.prop to my windows PC, edited it with notepad++ and copied back to my FireTV Stick´s /system folder. Rebooted and its stuck at boot now. After the Splash screen (white amazon text) its showing a blank screen.
Well, later in the comments of the aftvnews guide i found out i had to change permission of build.prop for it to work so i tried via adb but got an Error: Read-only file system.
Long story short:
Is there a way to get my FireTV Stick running again or is it bricked?
Edit: Is it possible to flash one of these bin files found here:http://www.aftvnews.com/amazon-fire-tv-fire-tv-stick-software-update-history/ ?
If you were editing the build.prop file you must of been rooted, why don't you just push the unedited build.prop from your pc to your stick? Assuming you had adb enabled and can connect through adb.
Try with USB plugged in and the easiest way to do it would be adblink.
Ive noticed an older version has options to mount the system rw if rooted, I think it was a couple of version ago.
I tried pushing the file back on the Stick but always getting Read-only filesystem error. Remounting /system didnt work also: Permission denied. Then tried adbLink 2.04, says filesystem mounted r/w but i am still unable to push build.prop (same error as always: Read-only filesystem)
Pushing with adbLink seems to not work either, although adbLink saying pushing file was successfull.
Root seems to be broken somehow? running su command in adb shell only gives me "1|[email protected]" , shouldnt it be "[email protected]"?
Run the windows version of Kingo root with USB plugged in. Try a few times if it fails.
Also give king root pc version a go.
Unfortunately no luck either. Even after 20+ runs.
Can't understand how that has happened of you had root, yoi should still be able to adb su into it.
Sorry I couldn't help