Hey guys, i know there are many ways to root different devices.
however when the hackers hack the new devices, how do they root them?
leonwu127 said:
Hey guys, i know there are many ways to root different devices.
however when the hackers hack the new devices, how do they root them?
Click to expand...
Click to collapse
Rooting in itself, is gaining administrator access to the device. Also known as su, sudo, root.
Phone manufacturers and carriers don't want you doing that, partially because of security, but really mainly cause they dont want you to be able to remove all the bloatware and skins they use to make a few bucks out of you.
So they put blocks on every way you could use to gain administrator access. The "general" way is that you look for exploits, anything they overlooked. its really a cat and mouse game, some care more than others; and are harder to crack than others.
Basically what they do is put you on a limited user account on the system, kinda like those guest accounts on a computer, or the limited accounts you give your kid. The most common ways are exploiting the built in system update with a fake verification certificate to *update* your system, with a change that upgrades you to admin. A lot of phones to additional verification on boot, and will on reboot kill this. On these occasions you have something called temp-root. when you have root you can override any part of the system. If you use your temp root to override the part of the system that kills invalid updates, you gain a "full-root".
Root only lets you change the core system files, not install a new ROM, for this you need to change the recovery, and to change the recovery, you need to unlock the bootloader, which carrier's and manufacturers like to block as well, but thats another story for another time.
thank xlexi,
i have read some files which mention that making ro.secure=0 in default.prop is the main purpose of rooting.
as u said, the fake "update" would change the ro.secure and delete the checking invalid update system.
is that right?
Now days many manufacturers actually promotes the use of custom images, using open bootloaders. This is of course a nice strategy to compete with other manufacturers locking their devices. Still there's a conflict between the music industry and the consumers. To use Digital Rights Management (DRM), the phone must be tamper proof, but we consumers want to be able to "own" the device we bought. To mention an example solving this, Sony Xperias are shipped with a locked bootloader, possible to unlock by the end users, but at the same time erasing all the DRM information. I believe this is a good compromise, and I guess many other manufacturers are using similar solutions.
If the bootloader is open, rooting the device is trivial and no need of "hacking". The generic way of modifying such a device, is just to reflash it with whatever you'd like, everything from an insecure image (i.e. ro.secure=0) to a complete custom ROM. This is using the open bootloader supported by the manufacturer. Using ro.secure=0 is not really recommended more then a means to become root so you can add su, busybox etc. Once this is done, it's best to reset ro.secure=1 again, I would say. No need to have the device too insecure.
In the case with the locked bootloader, the flashable image must be cryptographically signed to be accepted by the device, and such a signature can only be generated by the manufacturer. To hack such a device, some exploit must be used. This is seldom a problem, but makes the rooting procedure specific for that phone model, not being able to use the standard tools such as fastboot etc.
leonwu127 said:
thank xlexi,
i have read some files which mention that making ro.secure=0 in default.prop is the main purpose of rooting.
as u said, the fake "update" would change the ro.secure and delete the checking invalid update system.
is that right?
Click to expand...
Click to collapse
That is correct
Hi. May I ask for your opinion about this ???
Root Access is not properly configured or was not granted.
Super User Applications Status:
Superuser application - version 3.0 - is installed!
SuperSU application - is NOT installed.
The SuperSU application is an alternative application for managing root access.
System File Properties for Root Access:
Standard Location
Check Command: ls -l /system/bin/su:
Result: ls: /system/bin/su: No such file or directory
Analysis: File /system/bin/su does not exist.
Standard Location
Check Command: ls -l /system/xbin/su:
Result: -rwsr-sr-x 1 0 0 64412 Jul 17 08:48 /system/xbin/su
Analysis: Setuid attribute present BUT root user ownership NOT present. Root access is NOT correctly configured for this file!
Alternative Location
Check Command: ls -l /sbin/su:
Result: ls: /sbin/su: Permission denied
Analysis: File system permissions restricted and denied access.
Alternative Location
Check Command: ls -l /system/xbin/sudo:
Result: ls: /system/xbin/sudo: No such file or directory
Analysis: File /system/xbin/sudo does not exist.
Root User ID and Group ID Status:
SU binary not found or not operating properly
System Environment PATH: /bin /usr/bin /usr/sbin /system/_install/sbin /sbin /vendor/bin /system/sbin /system/bin /system/xbin
ADB Shell Default User:
ADB shell setting for standard access, stored in default.prop, is configured as: root user - ro.secure=0
Click to expand...
Click to collapse
This is what I get from my tablet. When using ADB and I type adb shell ... I'll get the # sign. But I'm not rooted - according to this.
Any recomendation/idea what's happening there ???
Thank you in advance.
zholy said:
Hi. May I ask for your opinion about this ???
This is what I get from my tablet. When using ADB and I type adb shell ... I'll get the # sign. But I'm not rooted - according to this.
Any recomendation/idea what's happening there ???
Thank you in advance.
Click to expand...
Click to collapse
The "ls" command producing the root user id numeric. I guess this is confusing the script above, not realising "0" is the same as "root". My guess is that rooted app's works just fine on your device, using the Super User app.
kuisma said:
The "ls" command producing the root user id numeric. I guess this is confusing the script above, not realising "0" is the same as "root". My guess is that rooted app's works just fine on your device, using the Super User app.
Click to expand...
Click to collapse
Well, notg exactly. I can install SuperUSer app from PLAY ... but then I can't instal BUsyBox because it doesn't have root access. Neither Titanium Backup doesn't work ...
Any advice, what to do / what to check whether it's correct ???
Thanks in advance
zholy said:
Well, notg exactly. I can install SuperUSer app from PLAY ... but then I can't instal BUsyBox because it doesn't have root access. Neither Titanium Backup doesn't work ...
Any advice, what to do / what to check whether it's correct ???
Thanks in advance
Click to expand...
Click to collapse
Have you tried if /system/xbin/su actually works? Tried it from the shell?
Related
Okay I posted this also in the Themes forum for Nexus but I wanted to see if anyone could assist. Someone in the theme forum asked about the bootanimation.zip that shows us the cool animation during boot, while reading this it reminded me of the behold 2. See below
What are the permissions for bootanimation.zip if they were left open to non root then this may-b a way to get root with unlocking the bootloader. This would be the same approach that was used to root the behold 2 where the "try3" file was renamed to play_logo . play_logo then was used to root and after root was opened it would make play_logo_real play which was the boot animation. I may be wrong but couldnt this be a possibility. Thanks, any help is appreciated. Im wondering if Zinx could chime in...
How are you going to write to the bootanimation.zip without root? Further, do you intend to replace the recovery or update custom roms? I am just trying to figure out the purpose of root and flashing other customized images.
seraph1024 said:
How are you going to write to the bootanimation.zip without root? Further, do you intend to replace the recovery or update custom roms? I am just trying to figure out the purpose of root and flashing other customized images.
Click to expand...
Click to collapse
You can always write if I am not mistaken using the low-level write dd if/of command. We would use the bootanimation.zip to run the root command. An example is in the Samsung Behold 2 it was done as follows:
Example
echo "#!/system/bin/sh
/data/local/try3 /system/bin/sh
mount -o rw,remount /dev/st9 /system
cat /system/bin/sh > /system/bin/su
chmod 04755 /system/bin/su
/system/bin/playlogo_real" > /system/bin/playlogo
Click to expand...
Click to collapse
This is how it was done. I am wondering if the same can be done on the nexus using bootanimation.zip as it executed at startup. We would basically modify the bootanimation.zip to the above and add a line for it to execute the boot image. By gaining root this way we would still be able to put on a custom recovery and roms without unlocking the bootloader in theroy. The try3 file was created by Zinx and used by Maxisma to bring root to the behold 2. I am pretty sure this may work on the Nexus 1. I hope this helps.
Ok. I don't have a locked phone that I can play with at the moment. I'll make up a package for you tomorrow. Can you test it for me?
seraph1024 said:
Ok. I don't have a locked phone that I can play with at the moment. I'll make up a package for you tomorrow. Can you test it for me?
Click to expand...
Click to collapse
Okay XDA is back up. Yes I can test. Oh man if this works there will be absolutely no need to unlock the boot loader... Thanks
seraph1024 said:
Ok. I don't have a locked phone that I can play with at the moment. I'll make up a package for you tomorrow. Can you test it for me?
Click to expand...
Click to collapse
Hey Seraph1024 take a look at this. Its too big for XDA so I put it up on pastebin. http://pastebin.com/f62780d32 Its what is contained in the try3 file. Zinx used it in flashrec
No joy.
Code:
$ getprop | grep product.model
[ro.product.model]: [Nexus One]
$ pwd
/data/local
$ ls -al try3
-rwxrwxrwx 1 0 0 74512 Jan 25 13:26 try3
$ id
uid=2000(shell) gid=2000(shell)
$ ./try3 /system/bin/sh
[1] Killed ./try3 /system/bin/sh
$ id
uid=2000(shell) gid=2000(shell)
Exploit does not work.
I was that close to rooting today until i saw this now its made me double think again lol I've been waitin for a custom rom by cyanogen until i rooted, and since its pretty much almost here i was going to root. bah guess i'll wait until CM gets released!
flak0 said:
You can always write if I am not mistaken using the low-level write dd if/of command.
Click to expand...
Click to collapse
You can't on this phone. There are two ARM cores - one running the low-level stuff (bootloader, radio) and the other running Linux.
Without the engineering bootloader (or some exploit) we don't have access to the baseband ARM core, and therefore don't have access to its MMU, which is programmed to deny read/write access to protected areas of the flash - such as the bootloader and splash screens. Even with root, Linux can't access that stuff.
It's going to be really hard to find a kernel exploit for the N1 to get root. Most exploits involve mapping memory to the zero page and then triggering a null pointer de-reference bug in the kernel. But the N1's kernel won't allow such mappings.... I believe the minimum address for mmap on the N1 is around 64k. (It's in the kernel config.)
This is a tough nut to crack.
The behold root was done that way because there's no way to flash the partitons on it.
You still need root in the first place to write to that file. The droid guys have been looking a while for a new root exploit but didnt find one. The problem is that all known exploits have been closed in 2.1.
We need to wait for someone to find a new one that works. Then this would be a real posibility, and there' no need to hijack playlogo.
for what its worth, if you need a lab rat i do not have my phone rooted yet and i am willing to test some things if anyone needs...
i dont plan on rooting it until the ball really gets rolling with everything and until I am 100% satisified with the phones performance
kam187 said:
You still need root in the first place to write to that file.
Click to expand...
Click to collapse
That's what I though. And like it was posted earlier, I don't think there is a exploit since this phone is done differently. I am busy for the next couple of days but if anyone want to "try", I'll make up something but I really doubt any of the old stuff will work on this phone.
I'm posting this here for visibility for Fascinate users and ROM developers. In the following thread you can find all the information, as well as how to download and apply the patch files:
http://forum.xda-developers.com/showthread.php?t=977154
I'm sure it will be incorporated into the major ROM's soon. However, if you install apps from unverified sources, or regularly try out new apps from the market, you shouldn't wait.
Patching via CWM:
imnuts said:
Here are two zips if people want them and don't feel like going to another thread/page/topic/whatever.
DroidDreamMalwarePatch_pre-edify.zip
DroidDreamMalwarePatch_edify.zip
Click to expand...
Click to collapse
Patching via ADB or terminal emulator:
Alternatively, probably the quickest way (and if you copy and paste, the most fool-proof) if you are rooted and know how to use ADB, is to open up a command prompt or a terminal emulator on the phone to access the adb shell. If on a PC, type:
Code:
adb shell su
Then type the following lines, omitting the $ and # (if you are on a terminal emulator, start here):
Code:
$ su
# mount -o rw,remount /dev/block/stl9 /system
# touch /system/bin/profile
# chmod 444 /system/bin/profile
You are now protected from the current iteration of DroidDream Malware. Consider installing a security program like LookOut to protect against future vulnerabilities.
Original Post:
Rodderik said:
[Patch][Rom]Malware Exploit for all pre-Gingerbread phones
Who is affected? All phones pre-gingerbread
Who should act? Users and developers using pre-gingerbread roms
How do I fix? Flash attached .zip at the bottom of this post or use one of the alternate methods down there
What if I think I was infected? Completely wipe your device, format sdard, go back to stock and re-apply rom, then flash the attached .zip (before installing any apps)
Why should I care? read below...
http://www.androidpolice.com/2011/0...your-phone-steal-your-data-and-open-backdoor/
Link to publishers apps here. I just randomly stumbled into one of the apps, recognized it and noticed that the publisher wasn’t who it was supposed to be.
Super Guitar Solo for example is originally Guitar Solo Lite. I downloaded two of the apps and extracted the APK’s, they both contain what seems to be the "rageagainstthecage" root exploit – binary contains string "CVE-2010-EASY Android local root exploit (C) 2010 by 743C". Don’t know what the apps actually do, but can’t be good.
I appreciate being able to publish an update to an app and the update going live instantly, but this is a bit scary. Some sort of moderation, or at least quicker reaction to malware complaints would be nice.
EDIT: After some dexing and jaxing, the apps seem to be at least posting the IMEI and IMSI codes to http://184.105.245.17:8080/GMServer/GMServlet, which seems to be located in Fremont, CA.
I asked our resident hacker to take a look at the code himself, and he’s verified it does indeed root the user’s device via rageagainstthecage or exploid. But that’s just the tip of the iceberg: it does more than just yank IMEI and IMSI. There’s another APK hidden inside the code, and it steals nearly everything it can: product ID, model, partner (provider?), language, country, and userID. But that’s all child’s play; the true pièce de résistance is that it has the ability to download more code. In other words, there’s no way to know what the app does after it’s installed, and the possibilities are nearly endless.
Click to expand...
Click to collapse
The offending apps from publisher Myournet:
* Falling Down
* Super Guitar Solo
* Super History Eraser
* Photo Editor
* Super Ringtone Maker
* Super Sex Positions
* Hot Sexy Videos
* Chess
* ????_Falldown
* Hilton Sex Sound
* Screaming Sexy Japanese Girls
* Falling Ball Dodge
* Scientific Calculator
* Dice Roller
* ????
* Advanced Currency Converter
* App Uninstaller
* ????_PewPew
* Funny Paint
* Spider Man
* ???
Click to expand...
Click to collapse
http://www.androidpolice.com/2011/0...-android-nightmare-and-weve-got-more-details/
Now, on to some more details of the virus. We should point out that this vulnerability was patched with Gingerbread, meaning any device running Android 2.3+ should be fine. In other words, if you’re looking to play the blame game (which I’m not, but having read all the comments on the original post, many people are), then there’s plenty to go around. The hole was fixed by Google, but it’s relatively useless since many phones aren’t yet running a version of Android that is protected. It’s noteworthy that some manufacturers released updates that patched the exploit for devices without updating to Gingerbread; unfortunately, it appears that minority is quite a small one.
Perhaps most important is the question of what infected users can do about their situation; unfortunately, the answer is not much of anything. Because the virus opens up a backdoor and can bring in new code at any time, the only way to really rid an infected device of any damage is to completely wipe the device – not exactly the optimal solution, but it looks like the only one available, at least for now.
Finally, Justin notes that ROM developers working with pre-Gingerbread versions of Android can prevent the virus from backdooring in code by putting a dummy file at /system/bin/profile.
Click to expand...
Click to collapse
As you can see androidpolice.com reports on this backdoor and roots and steals personal information. The apps are removed from the market but that doesn't mean they got them all. Attached is a flashable fix as suggested by androidpolice.com
So users can flash this .zip or simply create a blank file called profile and place it in /system/bin/ (developers are encouraged to include this file in future releases. A blank file is not going to affect performance at all)
Alternate methods:
Using 'adb shell' or terminal emulator (should work on any ROOTED phone) as suggest by xaueious here
Code:
$ su
su
# remount rw
Remounting /system (/dev/stl9) in read/write mode
# touch /system/bin/profile
# chmod 644 /system/bin/profile
#
Alternate 2:
Download blank profile file from here (or create one and name it profile)
Use a program like Root Explorer to copy it to /system/bin/
Then longpress on it and check the permissions should be read/write for user, read for group, and read for others.
Alternate 3:
cyansmoker has put together an apk for the patch here https://market.android.com/details?id=com.voilaweb.mobile.droiddreamkiller
Thanks for pointing this out photoframd and androidpolice.com for investigating and reporting!
UPDATE: I renamed the .zip file and reuploaded it (350 hits wow). Also in the edify scripted version I added 644 permissions to the file (but if you already flashed it then it should have defaulted to that). I also added a pre-edify version of the patch thanks to xaueious for people using a recovery that does not yet understand edify.
Click to expand...
Click to collapse
Thanks
Sent from my Rocking dj05, themed superdark w/o swype mod, voodoo 5, with custom boot and shutdown.. With premium xda app.
I would also recommend installing the free Lookout Mobile Security app. I find it to be very non-intrusive on my phone, no negligible battery drain or performance issues. Just scans any app you install, looking for bad stuff. Also does weekly full system scans, contact backup, and provides phone lock/alarm/location tracking features in case you lose it. Premium version has even more bells and whistles.
Posted from my EB01 SuperClean Fascinate with Voodoo
This has been stuck for the time being as it seems to be affected a BOATLOAD of users. Thanks for the linkage!
Here are two zips if people want them and don't feel like going to another thread/page/topic/whatever.
adb shell busybox touch /system/bin/profile
is all you need. Most fascinate kernels (of recent) have a bug, and /system is mounted as r/w.
So everyone should flash this no matter what rom you are using? Should we flash the new cwr also?
sorry delete
jcase said:
adb shell busybox touch /system/bin/profile
is all you need. Most fascinate kernels (of recent) have a bug, and /system is mounted as r/w.
Click to expand...
Click to collapse
adb shell chmod 644 /system/bin/profile
also?
NOsquid said:
adb shell chmod 644 /system/bin/profile
also?
Click to expand...
Click to collapse
This would probably be a good thing. Basically locks the file from being written to, right? Should I add it to the first post?
lasportsfan said:
So everyone should flash this no matter what rom you are using? Should we flash the new cwr also?
Click to expand...
Click to collapse
Yes.
All this is is a quick fix that will create a blank file. The current iteration of the malware checks to see if it already exists. This file fools it into thinking it already exists, so it moves on.
As you might guess, the author needs to only update his code to bypass this, in order for this to be an issue again.
And now that this is out, someone else will probably try it. Someone who is a little more thorough.
Moral of the story?
Be careful.
Consider running something like LookOut.
Backup your important data regularly.
As far as CWM goes, is there some kind of connection to the malware thing? Or just in general?
(If just in general, it's better to ask elsewhere as to not derail the thread).
Otherwise, I don't believe the newest (orange) clockwork recovery from ROM manager is fully compatible yet. Last I heard, it still had some bad binaries and 1 bad mounting point. Stick with the Red from JT's thread (which is the same bundled into SuperClean). Other than a couple superficial bugs that don't hurt anything, it works wonderfully and has more features than the orange CWM currently has.
GizmoDroid said:
This would probably be a good thing. Basically locks the file from being written to, right? Should I add it to the first post?
Click to expand...
Click to collapse
I dunno, it was in Rodderik's post but jcase didn't mention it. He's smarter than me, that's why I asked...
444 or 000 would be safer as that would prevent the file from being overwritten at all. 444 for read-only, 000 for no access.
If I never downloaded any of the apps in the list and have lookout on my phone is this neccesary to download or should i not be worried?
italysfinest327 said:
If I never downloaded any of the apps in the list and have lookout on my phone is this neccesary to download or should i not be worried?
Click to expand...
Click to collapse
Who should act? Users and developers using pre-gingerbread roms
Click to expand...
Click to collapse
I'd say that means you should be worried. Those apps listed are just the ones that were found on the market with them from one publisher. Just how virus's can get put into any application on a PC, the same can be done on phones.
Remember folks, our phones are just as exploitable as any other computer, so be careful!
good thing the patch came out!
imnuts said:
444 or 000 would be safer as that would prevent the file from being overwritten at all. 444 for read-only, 000 for no access.
Click to expand...
Click to collapse
Not sure whether Android interprets permissions differently from desktop Linux, but even if a file is 000 the owner can delete it on Debian. And root definitely can. If the file needs to be there for the root exploit to work, then this prevents it, but if they can run the root exploit and get root while this file is there then changing permissions on it will do nothing.
iofthestorm said:
Not sure whether Android interprets permissions differently from desktop Linux, but even if a file is 000 the owner can delete it on Debian. And root definitely can. If the file needs to be there for the root exploit to work, then this prevents it, but if they can run the root exploit and get root while this file is there then changing permissions on it will do nothing.
Click to expand...
Click to collapse
This is just another reason why I see this as a quick fix for what will need to have a much better one in the future.
If anyone hears of a more robust solution (besides using LookOut), let us know!
I navigated through Root Explorer to system/bin/profile and found a file there that reports
"01 Aug 08 06:00:00 rwxr-xr-x 0 bytes".
The 2008 date has me worried, although the 0 bytes means it is empty. Does anybody know if this is put there by FrankenClean 2.8 as a fix for this issue, or am I the only one on SuperClean seeing this (which would be bad!)
SupraLance said:
I navigated through Root Explorer to system/bin/profile and found a file there that reports
"01 Aug 08 06:00:00 rwxr-xr-x 0 bytes".
The 2008 date has me worried, although the 0 bytes means it is empty. Does anybody know if this is put there by FrankenClean 2.8 as a fix for this issue, or am I the only one on SuperClean seeing this (which would be bad!)
Click to expand...
Click to collapse
It is included in SC2.8. The 0 bytes is the best indicator that you are clean, since this patch is merely an empty file.
If you were infected, that file would actually have code in it.
For CWM 2.5.x.x DJ05, which one do you flash? or both?
DroidDreamMalwarePatch_pre-edify.zip
DroidDreamMalwarePatch_edify.zip
Thanks and sorry for the trouble, just wanted to be sure.
Hello
To be honest im beginning to wonder why I even bothered rooting my S3 seems to cause more hassle than its worth.
The only reason I rooted it was so that I can use the Vodooo Sim Unlocker App on my handset. I bought it on ebay and rooted the phone and used Vodoo to unlock the network lock all worked fine for a while until last week when I was on holiday I got an OTA update ...so I installed it since then when I start my mobile its asking for the Sim network pin code.
I am trying to get Three to provide this but they say the previous owner (off ebay)has to approve this or they cant do it.
I think that the root access on my mobile is fooked so I downloade dan app called Root Checker Pro results are below:
===========================================================
Root Access is not properly configured or was not granted.
Super User Applications Status:
Superuser application - version 3.1.3 - is installed!
SuperSU application - version 0.91 - is installed!
System File Properties for Root Access:
Standard Location
Check Command: ls -l /system/xbin/su:
Result: -rwxr-xr-x root shell 91980 2008-08-01 13:00 su
Analysis: Setuid attribute NOT present BUT root user ownership is present. Root access is NOT correctly configured for this file!
Standard Location
Check Command: ls -l /system/bin/su:
Result: /system/bin/su: No such file or directory
Analysis: File /system/bin/su does not exist.
Alternative Location
Check Command: ls -l /sbin/su:
Result: /sbin/su: Permission denied
Analysis: File system permissions restricted and denied access.
Alternative Location
Check Command: ls -l /system/xbin/sudo:
Result: /system/xbin/sudo: No such file or directory
Analysis: File /system/xbin/sudo does not exist.
Root User ID and Group ID Status:
SU binary not found or not operating properly
System Environment PATH: /sbin /vendor/bin /system/sbin /system/bin /system/xbin
ADB Shell Default User:
ADB shell setting for standard access, stored in default.prop, is configured as: shell (non root) user - ro.secure=1
===========================================
I have tried to re-root my device by using the same method that worked the first time i.e http://reviews.cnet.co.uk/mobile-phones/how-to-root-your-samsung-galaxy-s3-50008588/ but this does not work now any tips what I can do?
Get your info/rooting methods from xda only, everyone else in the world is stupid.
Flash cf-root and stop blaming root for user error, tbh your post was a case of tl;dr but from what I've experienced its user error 99.9% of the time.
Sent from my GT-I9300 using xda premium
Like I said It was working fine before the OTA update so that was my fault for downloading the upgrade...right ok thanks for your help...
slinkydonkey said:
Like I said It was working fine before the OTA update so that was my fault for downloading the upgrade...right ok thanks for your help...
Click to expand...
Click to collapse
Obviously the OTA broke root access, that's what happens.
Use Odin to flash cf-root 6.4 and Bob's your uncle.
Sent from my GT-I9300 using xda premium
nodstuff said:
Obviously the OTA broke root access, that's what happens.
Use Odin to flash cf-root 6.4 and Bob's your uncle.
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
Ok ill try it again tonight I was going to ask you to send me a link the the official XDA developers way of doing it but might be a bit tricky on a mobile so ill take a look around but im sure ive already tried this but ill try again tonight thanks
im assuming i cant just use? http://forum.xda-developers.com/showthread.php?t=1703488
If you couldn't be arsed learning what you are doing and why, and also learning so that you never get stuck in a situation like this again then work away with the toolkit.
Personally I think its the wrong way to do it.
Find the cf-root thread and do it that way if you want to learn how to do something.
Sent from my GT-I9300 using xda premium
nodstuff said:
If you couldn't be arsed learning what you are doing and why, and also learning so that you never get stuck in a situation like this again then work away with the toolkit.
Personally I think its the wrong way to do it.
Find the cf-root thread and do it that way if you want to learn how to do something.
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
ok ill search it out but to be honest I have enough learning IT at work
slinkydonkey said:
ok ill search it out but to be honest I have enough learning IT at work
Click to expand...
Click to collapse
Well, if you want something easy to use and doesnt require learning then get an iphone Or dont mod your gs3.
If you only rooted to unlock wouldnt it have just made more sense (and less hassle if you don't know what you're doing) just to buy an unlock code for 10 bucks and be done than trying to dive in the deep end without knowing how to doggy paddle to accomplish the same thing?
plus with odin it couldnt be anymore simple especially for an IT guy.
get odin
get the cf root tar
boot the phone in download mode
point odin to the tar file and flash
it's pretty darn simple actually
graffixnyc said:
Well, if you want something easy to use and doesnt require learning then get an iphone Or dont mod your gs3.
If you only rooted to unlock wouldnt it have just made more sense (and less hassle if you don't know what you're doing) just to buy an unlock code for 10 bucks and be done than trying to dive in the deep end without knowing how to doggy paddle to accomplish the same thing?
plus with odin it couldnt be anymore simple especially for an IT guy.
get odin
get the cf root tar
boot the phone in download mode
point odin to the tar file and flash
it's pretty darn simple actually
Click to expand...
Click to collapse
Your right to a point I should of just bought an unlocked S3 off ebay thats my fault ..I had tried the odin method yesterday it didnt work then but today it has so im happy now ive run Vodooo and my mobile is working again. I use the S3 for my small business and partiuclar apps like Barclays app does not work on Rooted phones so maybe I should of get an iphone haha but im not that stupid .. :laugh:
I have just updated my Prime and I did not have rooted it with ICS. Is possible to root JB without previous rooting?
No. You must back up root using OTA Rootkeeper in order to regain root in JB. There is no known exploit for JB yet.
without restoring root with ota rootkeeper, try http://matthill.eu/mobile/root-trans...lybean-update/ and follow the instructions, follow the links for the files you need
tonesy said:
without restoring root with ota rootkeeper, try http://matthill.eu/mobile/root-trans...lybean-update/ and follow the instructions, follow the links for the files you need
Click to expand...
Click to collapse
lol, must be a joke.... dead link.
I have been actively pursuing this. Without bootloader unlock i dont beleive so.
If you Unlock the Bootloader or already have an Unlocked Bootloader, you can get root.
I haven't seen any exploits posted for the Prime in JB yet, so this may be your only way for now.
hx4700 Killer said:
lol, must be a joke.... dead link.
I have been actively pursuing this. Without bootloader unlock i dont beleive so.
Click to expand...
Click to collapse
He posted a bad link but doesnt work if you have no root access at all. This is just a "regain root if you have partial root" guide:
http://matthill.eu/?s=jelly+bean
Thread moved
Thread moved. This is clearly belonging into Q&A. Please post in correct Sub-Forum.
peace
jotha - forum moderator
Does any one know if one person with development capabilty is trying to find a way to root JB ?
I talked to bin4ry about his root method in hopes of working with him on modifications for the prime but he is telling me his mod is making the change he is exploiting according to what I am seeing but possibly ASUS disabled the emulator mode in this version of the OS. This is what would give you root access via ADB so changes can be made.
I couldnt get out of him what exactly his "restore timing exploit" is but I understand everthing after that
Outside of anything coming up I would say if you must have it now and don't mind voiding your warranty then use the unlocker tool and follow one of many guides on here to do it from an unlocked device.
Perhaps we can turn this thread into, or possibly start a new one about the different things people(devs and/or the technically savy) are finding in the quest for an exploit...
We could start with a list of what is known. Of particular interest would be the differences between the complete stock (me btw), was rooted but lost it, was rooted and kept it, and of course anybody who has managed to root it by messing around but not taken notes along the way.
here's what I have found.
from the PC, creating an adb shell allows me to ls /data/local/tmp/ but from a tablet's terminal emulator (shell?) I cant.
Typing id from both it becomes obvious why
From adb shell I get
Code:
uid=2000(shell) gid=2000(shell) groups=1003(graphics),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)
from the tablet I get
Code:
uid=10126(u0_a126) gid=10126(u0_a126) groups=1015(sdcard_rw), 1028(sdcard_r),
3003(inet)
I was getting excited last night (burnt the midnight oil) trying what I thought might be a possible exploit with an android supplied command called "run-as". Its limitaions became obvious when I looked at the source code for it. You need an application pakage that is debugable and it cd's to its directory to run the command and a bunch of other things, so I compiled it on C4droid using just the main functions setresuid() and setresgid() but they both failed no matter what value was plugged into them based on UID and GID found here
http://forum.xda-developers.com/showthread.php?t=442557
I have yet to exhaust this avenue. I might be able to create an empty package and sign it as a system app, make it debugable and see what that yeilds but its looking like a convoluted process, espicially considering that run as may not work as intended on prime's JB
PS I want to state that I know precious little about linux and even less about the android layer above it...
Just as an FYI the way bin4rys tool is supposed to work is an exploit in which it makes a symlink to /data/local.prop and injects ro.kernel.qemu=1 in to local.prop then reboots.
This is supposed to put the device in emulator mode and when you connect with adb shell you get a root shell prompt. All the rest is fairly straightforward/standard. Remount file system as RW, install SU and superuser.apk with their permissions set properly in the proper places then break the symlink to local.prop and reboot.
What would help a lot is if someone who is already rooted can make the attempt, set qemu = 1 in the relinked local.prop then adb shell connect to see if you get a root prompt. Trying to confirm that emulator mode is enabled and you get root access as shell to see if this is even worth pursuing.
I would just use the unlocker tool but I am 2 weeks in to ownership of a new unit.
yes I have seen that typing adb root gives the message
Code:
adbd cannot run as root in production builds
it would indeed be interesting to see if changing "qemu" flags it as a non-production build. My sgs is rooted with CM10 nightlies might try toggling the value on that and see what adb says
Run-as
abazz said:
I was getting excited last night (burnt the midnight oil) trying what I thought might be a possible exploit with an android supplied command called "run-as". Its limitaions became obvious when I looked at the source code for it. You need an application pakage that is debugable and it cd's to its directory to run the command and a bunch of other things, so I compiled it on C4droid using just the main functions setresuid() and setresgid() but they both failed no matter what value was plugged into them based on UID and GID found here
http://forum.xda-developers.com/showthread.php?t=442557
Click to expand...
Click to collapse
Yes. I noticed the permissions on that file as well. I'm not an android person, so I don't know how that end works, but the permissions do look correct (setuid root, and runnable as group shell [which we get via adb, but not locally on terminal].
Based on the little bit that I have read, it seems that it may be getting the permissions assigned to the apk and running the command line with those permissions.
If that is correct, then running it via something with c4droid probably won't work, as it's permissions are whatever group it (c4droid?) was assigned at install.
So, how do does one / can one specify that the package is supposed to be root (uid 0). I'd guess (from a standard UNIX security perspective) that you can't just push arbitrary apps to the machine with 'run me as root' permissions. Otherwise, this would be a completely non-issue. But, is there a package which is pre-installed that we can exploit the permissions of to do this? I don't know yet.
Also, if my readings / assumptions were correct above, we probably don't want to do a setreuid(), but rather call bash/busybox as the 'command' issued in the name of the apk (since it would then run as root, or the uid of the package). Either that, or a system command(s) to chown/chmod the su binary that we can upload via adb (but which comes in as shell.shell).
Did you find the source for run-as somewhere? It would be interesting to look at to see if such a thing is possible. Failing that, it would be interesting to see if there were any sorts of buffer overflows that could be run against it. I've never tried such on arm7, but I've done it under UNIX on x86 and Sparc.
Thanks
Schemm
elschemm said:
Yes. I noticed the permissions on that file as well. I'm not an android person, so I don't know how that end works, but the permissions do look correct (setuid root, and runnable as group shell [which we get via adb, but not locally on terminal].
Based on the little bit that I have read, it seems that it may be getting the permissions assigned to the apk and running the command line with those permissions.
If that is correct, then running it via something with c4droid probably won't work, as it's permissions are whatever group it (c4droid?) was assigned at install.
Click to expand...
Click to collapse
Yes you are correct. setresuid() function will not give you permissions greater than the process its running in
So, how do does one / can one specify that the package is supposed to be root (uid 0). I'd guess (from a standard UNIX security perspective) that you can't just push arbitrary apps to the machine with 'run me as root' permissions. Otherwise, this would be a completely non-issue. But, is there a package which is pre-installed that we can exploit the permissions of to do this? I don't know yet.
Click to expand...
Click to collapse
Its worse than that, the package also has to be debuggable
There is some info out there on how to sing a package with the appropriate system permissions so it would be interesting to actually do this and see what, if anything can be done.
I downloaded the asus unlock package and passed it through the apk tool to see what it does, as it obviously would need root access. As root access is all i require the code it shows is irrelevant really, its the fact that it gains root access with its signature and also the uid that is set in the manifest android.sharedUserID="adroid.uid.system". This and, most importantly android.permission.MOUNT_UNMOUNT_FILESYSTEMS. WIthoput these things we cant change anything in the directories we need
Also, if my readings / assumptions were correct above, we probably don't want to do a setreuid(), but rather call bash/busybox as the 'command' issued in the name of the apk (since it would then run as root, or the uid of the package). Either that, or a system command(s) to chown/chmod the su binary that we can upload via adb (but which comes in as shell.shell).
Click to expand...
Click to collapse
Yes thats what we would do from the run-as command. What I was attempting to see was if I could get a root uid by creating a c program that uses the setresuid() function call thereby bypassing the need to have an appropriate package installed. As it didn't work I'm having dounts whether it would work even if the right package was there. run-as did make reference to package.h which I haven't looked at, so unless there are some system parameters that package.c extracts from the apk I dont really see how this will work...
Did you find the source for run-as somewhere? It would be interesting to look at to see if such a thing is possible. Failing that, it would be interesting to see if there were any sorts of buffer overflows that could be run against it. I've never tried such on arm7, but I've done it under UNIX on x86 and Sparc.
Thanks
Schemm
Click to expand...
Click to collapse
Yeah found the source here
I also searched for linux exploits, there are massive lists of them, most of them patched by now but I assume the linux base in JB would be somewhat different to whats getting around on X86 systems
On anather note I have tried bin4ry's "root many" method , using the restore timing exploit but had no luck.
HX... I looked through the scripts and all the misc files in bin4ry's zip package and could not find anything remotely indicating an injection of the qemu value. It make a symbolic link to the build.prop in com.android.settings...../file99, which was succesfull after pressing restore but thats about it. perhaps I should fire up ubuntu and try the linux script instead of the windows .bat file
Interestingly, this guys root method for the Razr M makes use of Run-as if you look at the batch file.
He is essentially doing a "fake package" install then runs an exe that is some sort of exploit. Finally he uses run-as against what I have to assume is the bug report feature of the droid and asks you to trigger a bug report with a button sequence.
So it seems he is getting something that has root privileges (bug report) to do something that grants SU and also implimenting run-as
http://forum.xda-developers.com/showthread.php?p=32889627#post32889627
I fear that remained a few developers interested in finding a way to root transformer prime with jelly bean, because all of them had tablet already rooted with ics and managed in mantaining rooting across upgrade.
Hi,
I tried to upgrade the busybox with different manner (busybox, busybox installer, manual installation from xda), but no one works properly.
Each time i broke the original Archos busibox, so i lose the adb shell.
Can someone explain to me the good way to upgrade the busybox?
Thanks.
SirOch
Hi,
Nobody to explain a clean upgrade of the busybox?
cheers
SirOch said:
Hi,
Nobody to explain a clean upgrade of the busybox?
cheers
Click to expand...
Click to collapse
Google? also XDA has a great search feature have you tried that? :silly: Any particular reason why you want/need to upgrade busybox?
Hi,
As i said, i tried the different busybox installers and the installation was ok, but i each time, i lost the shell from adb.
That's just my problem.
So i just want to understand why the upgrade of the busybox broke the original archos busybox?
Moreover some application need to have other busybox installed.
Regards.
David
SirOch said:
Hi,
As i said, i tried the different busybox installers and the installation was ok, but i each time, i lost the shell from adb.
That's just my problem.
So i just want to understand why the upgrade of the busybox broke the original archos busybox?
Moreover some application need to have other busybox installed.
Regards.
David
Click to expand...
Click to collapse
Ahhh right, the quest for knowledge Your problem is as much to do with adb ( /sbin/adbd to be precise ) as it is to do with busybox, firstly you've probably wiped out the symlinks in /bin, especially /bin/sh which is the location that adbd on archos looks to run the when you do adb shell from your desktop. This is not the default location which just about every other android OEM adheares ,that is /system/bin/sh.
If you are going to upgrade the archos busybox be aware that a large number of symlinks back to /bin/busybox exist not only in /bin but also in /usr/bin /usr/sbin
Archos for reasons I still haven't fathomed, really went to town on restructuring and customized Android on the platform level.
A little tip if you've got more question, to save you bumping threads , which really does upset some folks round here... you'll probably get more more if you add more details, such as error messages etc. Saying " i lost the shell from adb." doesn't really help anyone who might be able to offer assistance. There about 10 different ways adb can fail to connect, Did the device disappear from the list or report as offline. or even come up with the message "- exec '/bin/sh' failed: No such file or directory (2) -".??
Hopefully that's helped.
Hi SirOrch,
i don't know why you loose your adb shell, but concerning busybox... the things on Archos tablets are like this:
Basically on a non rooted device we got a squashfs image mounted read only.
This image contains the stock busybox compiled by Archos (sharing system's uclibc) with limited functionality,
but containing enough tools to handle the daily job.
The path to this busybox is "hard-coded" as well. It's location is /bin which is the second entry in the path environment.
You might check that by typing printenv in your console.
The first entry should be /data/local/bin on your device.
So if you like to replace stock busybox with an advanced one, you should make sure that it will be installed to /data/local/bin.
Often there's no need to use all this apk Android Market stuff to get a proper busybox installation.
Sometimes it's little better to really understand what's happening under the hood.
Most busybox app's are statically linked, because with a static binary you don't have to take care of the device's libc or uclibc.
So you might easily extract on of the apk's or get one from xda-developers.
There are many floating around in the end.
If got one push it to /data/local/bin with adb.
You might need softlinks in this directory as well. This could be done by hand as well.
Anyway if you are a lazy person, who doesn't care about what's happening, go to the market install busybox.
Then check at /data/local/bin if it is there.
If it got installed elsewhere, some commands will still use stock busybox.
Extended commands might then use the installed one.
So check it out...
EDIT:
... aaaargh again simultaneous posting.
scholbert
Hi gentlemen,
Thanks for your help and sorry to forget to give you the error message i had:
the message was : - exec '/bin/sh' failed: No such file or directory (2) -
After investigation i found my mistake:
- In manual mode, i forget to change the ownership of busybox to root in /bin.
- when i tried to use any application from the market, the busybox was well updated in /system/xbin but the application also delete the busybox in /bin and don't change the symlinks in /bin. That's explain why adb shell won't work.
Regards.
SirOch