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.
Related
Seriously. Why don't we have sudo on Android? Is there some technical limitation I'm missing?
Well, the first thing I'm noticing, is we don't have su under /system/xbin.
So it seems step one would be to compile a compatible binary for the phone in question, and then a method to place su into /system/xbin.
You must be new. What phone you talking about
Sent from my HERO200 using XDA App
I'm a bit new here, but I'm pretty sure I used su. Did you root your phone? If you do, you'll have su. Rooting an evo 4g isn't hard; google it(can't post links; too new).
thatguythatdid said:
You must be new. What phone you talking about
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
You must be new (to Linux).
Evo 4G, rooted, swapped for Fresh, swapped to DC, swapped to CM6, swapped back to 100% unrooted stock (current status).
In a 'normal' Linux installation, you usually log in as a normal user. Su, ie 'Switch user' or more commonly old-school 'Super user' allows you to temporarily log in as another user (we're going for 'root' here) and utilize that user without logging out and in of the current shell.
Running as root all the time is bad for security, as any Linux user can tell you.
Clearly, I have no desire to run as root on my phone ALL the time.
Also, from a development standpoint, releasing apps that ONLY work on rooted phones is ridiculous - you cut out the vast majority of users.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Here's what I've come to this morning:
Well, su and sudo have to be compiled and compatible with the kernel. I was mistaken, in that I thought of Android similar to a normal Linux distribution (aka distro) - usually, you'll have many distros that utilize the same exact kernel, and this runs over a very large number of systems. Thinking deeper, however, I realized that even though most desktops are different, at the end of the day they are all x86 compatible - in other words, low level communication is the same between all major PCs.
On smartphones, however, you've got multiple architectures - I'm most familiar with ARM (Qualcomm) and OMAP (Texas Instruments). The kernels for the two will not be the same, unless we (the community) build a super-kernel that would run on both architectures (unlikely just from an efficiency standpoint). Android is just the framework that sits on TOP of the Linux Kernel.
In my particular case, the Evo 4G, it appears 'su' is not even on the phone. A quick 'adb shell ls -l -R -a > file_permissions.txt' show me, however, there is a hidden directory named 'sbin' on the phone, that is only accessible as root.
So my next step is to re-root my phone, flash the rooted 1.47 OTA image, and see what the hell is in that sbin directory.
The following step, I'm going to compile an ARM compatible copy of sudo, insert it into a non-rooted (stock) image, along with a proper /etc/sudoers file and see if I can develop a way to have a non-rooted image, with the ability to take root at will, on command (whether via su or sudo)
The purpose of this post is to find out if anyone's already attempted this, and if so, where they got stuck.
I have a /system/bin/su on my phone (G1 w/ CM6RC2). Any 'rooted' ROM should have the same. I don't understand why you think otherwise.
I'm the developer of QuickSSHd, an app that runs a secure shell daemon, either as root or not-root. I've also submitted (small) patches (and had them accepted) to the Superuser.apk and su.c that is used on most of the newer rooted ROMs. I've been using Linux for > 10 years.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Click to expand...
Click to collapse
We do have su on Android. And the su we have is done in a way that it's more like sudo as it prompts the user for allow/deny and remember. But no password is needed.
http://github.com/ChainsDD/android_packages_apps_Superuser
http://github.com/ChainsDD/android_packages_apps_Superuser/blob/eclair-froyo/su.c
If for some reason you want to compile sudo you'll run into issues that Android's libc doesn't include crypt for passwords as the user system is completely different on Android. I don't think anyone has tried as it would be rather pointless with the above Superuser.apk and su (usually /system/xbin/su or /system/bin/su)
[email protected] said:
I'm the developer of QuickSSHd, an app that runs a secure shell daemon, either as root or not-root. I've also submitted (small) patches (and had them accepted) to the Superuser.apk and su.c that is used on most of the newer rooted ROMs. I've been using Linux for > 10 years.
We do have su on Android. And the su we have is done in a way that it's more like sudo as it prompts the user for allow/deny and remember. But no password is needed.
http://github.com/ChainsDD/android_packages_apps_Superuser
http://github.com/ChainsDD/android_packages_apps_Superuser/blob/eclair-froyo/su.c
If for some reason you want to compile sudo you'll run into issues that Android's libc doesn't include crypt for passwords as the user system is completely different on Android. I don't think anyone has tried as it would be rather pointless with the above Superuser.apk and su (usually /system/xbin/su or /system/bin/su)
Click to expand...
Click to collapse
Very nice, thank you for the information, Kevin. Believe it or not, I wasn't able to find anything searching here nor via Google.
Very informotive post guys, thanks.
I must ask, where can I find more on how Android is built?
Wouldn't be simple to add the possibility to ask a password while calling su binary? You can tell me it's useless, but some people may don't want anybody to access superuser powers on his phone. It would be safier if in Superuser's preferences we could add a password protection, IMHO. Of course this MUST be an option, not an imposition. But I would appreciate it veeery much.
mike.sw said:
Very informotive post guys, thanks.
I must ask, where can I find more on how Android is built?
Click to expand...
Click to collapse
There is a 2 part video which may help.
Part one is here:
http://m.youtube.com/#/watch?desktop_uri=/watch?v=1_H4AlQaNa0&v=1_H4AlQaNa0&gl=GB
Cheers
Please use the Q&A Forum for questions &
Read the Forum Rules Ref Posting
Moving to Q&A
HUGE BUMP
This was a very valid question. While the wording was.. oblique at best, it does raise a point.
Why are we not using sudo instead of su? Or at least, password protecting su. I realize SuperSu offers this feature if you.. pay for it. Seems backwards.. paying for a linux.. cough. Nevermind.....
In any event, I would think password protecting your su binary would very serious security concern for everyone... unless there's something the Android API does via some.. sandboxing that makes it a non-issue.. (please correct me.)
Side note, admins of this site..
You realize you have 6 trackers for social bullsh and allow passwords for logins to be transmitted in plain text? Better fix it.. before someone gets naughty and follows those spider webs....
Long story short because android OS is not open source like linux. They is how cell company's still make dollars
---------- Post added at 01:19 PM ---------- Previous post was at 01:10 PM ----------
Not
Doward said:
You must be new (to Linux).
Evo 4G, rooted, swapped for Fresh, swapped to DC, swapped to CM6, swapped back to 100% unrooted stock (current status).
In a 'normal' Linux installation, you usually log in as a normal user. Su, ie 'Switch user' or more commonly old-school 'Super user' allows you to temporarily log in as another user (we're going for 'root' here) and utilize that user without logging out and in of the current shell.
Running as root all the time is bad for security, as any Linux user can tell you.
Clearly, I have no desire to run as root on my phone ALL the time.
Also, from a development standpoint, releasing apps that ONLY work on rooted phones is ridiculous - you cut out the vast majority of users.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Here's what I've come to this morning:
Well, su and sudo have to be compiled and compatible with the kernel. I was mistaken, in that I thought of Android similar to a normal Linux distribution (aka distro) - usually, you'll have many distros that utilize the same exact kernel, and this runs over a very large number of systems. Thinking deeper, however, I realized that even though most desktops are different, at the end of the day they are all x86 compatible - in other words, low level communication is the same between all major PCs.
On smartphones, however, you've got multiple architectures - I'm most familiar with ARM (Qualcomm) and OMAP (Texas Instruments). The kernels for the two will not be the same, unless we (the community) build a super-kernel that would run on both architectures (unlikely just from an efficiency standpoint). Android is just the framework that sits on TOP of the Linux Kernel.
In my particular case, the Evo 4G, it appears 'su' is not even on the phone. A quick 'adb shell ls -l -R -a > file_permissions.txt' show me, however, there is a hidden directory named 'sbin' on the phone, that is only accessible as root.
So my next step is to re-root my phone, flash the rooted 1.47 OTA image, and see what the hell is in that sbin directory.
The following step, I'm going to compile an ARM compatible copy of sudo, insert it into a non-rooted (stock) image, along with a proper /etc/sudoers file and see if I can develop a way to have a non-rooted image, with the ability to take root at will, on command (whether via su or sudo)
The purpose of this post is to find out if anyone's already attempted this, and if so, where they got stuck.
Click to expand...
Click to collapse
Hello everyone!
You may or may not know me, however I have secretly been working behind the scenes with ChiefzReloaded to learn how Android works. Together we have been trying to develop new ways to root the Slide, primarily because we both landed in a sticky situation that left us both without root and without a way to revert to root.
After many long hours of trying to restore my phone, I have now ported the exploid exploit to the MyTouch Slide! This means that you can gain root on any version of the Slide, INCLUDING the latest OTA! However, this isn't necessarily "easy" as in the One-Click Root program, but there are reasons for this. While Android is running we cannot write to /system and even if we force Linux to let us, the NAND protection will prevent Linux from completing the write!
To get started, please see the bottom of this post for the link and download it. You will want to download it to your computer and not your phone's SD card. Also, you will need the tools from the Android SDK. I would suggest extracting the file from my zip at the bottom of this page into the Android SDK's tools directory.
Extract the zip
Make sure your phone is in USB debugging mode AND you are in "Charge Only" mode.
Connect your phone to your computer.
Make sure you're in the same directory as where exploid is extracted before continuing to the next step.
Issue the following command: adb push exploid /sqlite_stmt_journals. Note: It MUST be in that directory - NO exceptions.
Run: adb shell
Run: cd /sqlite_stmt_journals
Run: chmod 0755 exploid
Run: ./exploid
Toggle your phone's Wifi (on or off, however you wish to do that).
Now (again) run: ./exploid (if prompted for a password enter: secretlol)
The next line should now begin with a pound (#) - if not, then something isn't setup right. Make sure to follow the directions verbatim. If you suspect you did follow them correctly, please reply to this post letting me know.
You should now be root! At this point you can do many things, but if you're looking to flash a custom ROM, continue to these instructions:
[NEW 10/18/2010:]
Steps 1-12 are intended to get you the ability to flash mtd0.img (which previously required using the SimpleRoot method) by gaining root inside of Android. By following the instructions in the rest of this section, it will allow you to flash a ROM or S-OFF your device:
The files you need are at: http://forum.xda-developers.com/showthread.php?t=703076- download both files linked in there (ESPRIMG.zip and SlideEng-package.zip)
Extract the contents of SlideEng-package.zip to a place of your choosing on your computer.
Place the entire (unextracted) ESPRIMG.zip on your SDcard.
Now push the files 'flash_image' and 'mtd0.img' that you just extracted from SlideEng-package.zip to /data/local using 'adb push'. (Noob? Instead of using 'adb push', install Droid Explorer and, using that utility, copy the 'flash_image' and 'mtd0.img' files to /data/local on your Slide)
Now I'm going to assume your phone is at root prompt (#) using steps 1-12. So now do (without typing the '#' symbols in front of both lines - they're just there to remind you that you need to be at a '#' prompt):
Code:
# cd /data/local
# chmod 04755 flash_image
# ./flash_image misc mtd0.img
Before you reboot make sure that the ESPRIMG.zip is on your SDcard!
Now turn off the phone.
Then press Volume-Down + Power.
The phone will power on and after about 5 minutes of verifying ESPRIMG.zip it will ask you if you want to flash it.
Press Volume-Up for 'YES' and wait until it finishes (ABSOLUTELY DO NOT POWER DOWN WHILE IT'S STILL FLASHING!!!).
Now when you go into recovery it should allow you to 'Apply update.zip from sdcard' (booting into Clockwork). If you don't have the Clockwork update.zip, here it is: http://www.4shared.com/file/OTRU7T3y/update_2.html (rename to update.zip after downloading since it's currently update_2.zip, then place it on your sdcard).
[/NEW 10/18/2010]
[NEW 12/30/2010]
Optional: Now that you're rooted you might want to disable all flash memory protections so you can permanently flash Clockworkmod (recovery - no more using an update.zip!) as well as other random things. Check here for details: http://forum.xda-developers.com/showthread.php?t=798168
[/NEW 12/30/2010]
CREDIT GOES TO:
[*] ChiefzReloaded! (For helping me learn the intricacies of Android and patiently answering all of my questions)
[*] 743C (For developing the original exploit)
Source code: (Yes, it's hackish. I was just trying to figure out why the system kept rebooting and haven't cleaned up the code since) download
DOWNLOAD:
http://www.4shared.com/file/CZsxSq-f/exploid.html
DONATE:
(Anything helps!)
(Some people may wonder why this is special compared to the One Click Root application. What's important is that One Click Root doesn't work on Slides running production/retail software, likely the same problem I had to fix to get exploid to work in my version.)
Thats whats up!!
If you be trollin then YOU BES TRAWLLIN
But if not then good job nb!
Sent from my T-Mobile myTouch 3G Slide using XDA App
Can you provide the source? No offense, but I tend not to run homebrew C programs that I didn't compile myself.
Thanks for all the work!
falken98 said:
Can you provide the source? No offense, but I tend not to run homebrew C programs that I didn't compile myself.
Thanks for all the work!
Click to expand...
Click to collapse
Sure, I was getting around to that - and I understand your concern. I'll post it in a second.
falken98 said:
Can you provide the source? No offense, but I tend not to run homebrew C programs that I didn't compile myself.
Thanks for all the work!
Click to expand...
Click to collapse
You think nb is distributing a virus disguised as a root method?
Waaaaaat
Sent from my T-Mobile myTouch 3G Slide using XDA App
r0man said:
You think nb is distributing a virus disguised as a root method?
Waaaaaat
Click to expand...
Click to collapse
It is a bit funny, but I do understand his concern. I've posted the source code into the original post. Compiling it should result in the same hash as the binary I posted.
Good to see this I suggested this in another thread glad to see it in use thanks a bunch
nbetcher said:
It is a bit funny, but I do understand his concern. I've posted the source code into the original post. Compiling it should result in the same hash as the binary I posted.
Click to expand...
Click to collapse
Ill take a look at it when I get home.
ilostchild said:
Good to see this I suggested this in another thread glad to see it in use thanks a bunch
Click to expand...
Click to collapse
I actually had to do a lot of work on it. It doesn't quite work the same as the original exploid simply because the original exploid crashes the entire system and reboots. This causes the rootshell to never be committed to NAND and thus you get no where. I had to keep playing with things until I found a different method that works. It took several hours of me being upset with it, but watched the latest Burn Notice, came back to it, and BAM I had a stroke of genius.
where is rootshell? i can't exicute rootshell nor can i "cp" any files from sdcard however i do have a # instead of a $
Armyjon88 said:
where is rootshell? i can't exicute rootshell nor can i "cp" any files from sdcard however i do have a # instead of a $
Click to expand...
Click to collapse
Ignore that portion of the instructions provided by the program. As I stated, this is not intended for non-developers at this point. The # is your indication that you're running as root.
I am headed to work, but I don't usually have much going on there - I will be setting up a much cleaner system/environment for non-developers to work with and perma-root their phones with over the next few hours. Stay tuned!
Sweet
Sent from my T-Mobile myTouch 3G Slide using XDA App
having # and running as root as stated before u can actually follow with eng and then custom recovery and ur choice's rom..pls correct me if im wrong..thanx
statuzz said:
having # and running as root as stated before u can actually follow with eng and then custom recovery and ur choice's rom..pls correct me if im wrong..thanx
Click to expand...
Click to collapse
i'm also wondering the same thing, because i got the exploid working, and i have the # in the shell, but when i go to follow the instructions to flash the eng-release, i can't cd to any different dirs, nor can i push any files to the phone. i have the ESPRIMG.zip copied to my sdcard, so could i just reboot into recovery and flash the nbh from there? any help is appreciated.
nbetcher said:
Ignore that portion of the instructions provided by the program. As I stated, this is not intended for non-developers at this point. The # is your indication that you're running as root.
I am headed to work, but I don't usually have much going on there - I will be setting up a much cleaner system/environment for non-developers to work with and perma-root their phones with over the next few hours. Stay tuned!
Click to expand...
Click to collapse
Let me know if you want to work together on some kind of one-click root app for the Slide. If the commands work through the terminal on the phone itself rather than via adb, I could probably make this into an app already, but since you're working on a more non-developer-friendly version, I'll just wait until that's out
televate said:
i'm also wondering the same thing, because i got the exploid working, and i have the # in the shell, but when i go to follow the instructions to flash the eng-release, i can't cd to any different dirs, nor can i push any files to the phone. i have the ESPRIMG.zip copied to my sdcard, so could i just reboot into recovery and flash the nbh from there? any help is appreciated.
Click to expand...
Click to collapse
I'm delaying the release of my non-developer program for another couple hours.
As far as what you said above, all you need to do after gaining the # prompt is (in a separate window):
adb push flash_image /data/local
adb push mtd0.img /data/local
(switch back to your # adb shell, then type
cd /data/local
chmod 04755 flash_image
./flash_image misc mtd0.img
Then reboot and apply the ESPRIMG.zip. All of these files are found on the same post that I referenced in my OP. These instructions are all in that same page.
televate said:
i'm also wondering the same thing, because i got the exploid working, and i have the # in the shell, but when i go to follow the instructions to flash the eng-release, i can't cd to any different dirs, nor can i push any files to the phone. i have the ESPRIMG.zip copied to my sdcard, so could i just reboot into recovery and flash the nbh from there? any help is appreciated.
Click to expand...
Click to collapse
Im also stuck since im not sure if you can update to eng from the ota..But first i want to personally thank the OP & CR for providing this.
This would be great for a One Click method
this would be nice to work into a one click root!
And This did work for me!
Does this root method gets /system moumted when android running?In short do we finaly get metamorph and root explorer working?
All you need to do is extract this and run the "runme.bat"
Code:
echo off
cls
echo *********************************
echo * Please plug the USB into Nook *
echo *********************************
pause
adb kill-server
adb devices
echo *******************
echo * Blocking Update *
echo *******************
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb push block-1.1.sh /system/media
adb shell sh /system/media/block-1.1.sh
ping -n 5 127.0.0.1 >NUL
echo Success
adb reboot
adb kill-server
echo *****************************
echo * You nook is rebooting *
echo * Disconnect the USB cable! *
echo * Wait until rebooted... *
echo * *
echo * BN 1.1 Update Blocked *
echo * *
echo *****************************
pause
exit
Download
Can you release an "Undo" script as well that undoes what this does?
I was under the impression that the otacert rename was a dud and the build.prop was very questionable???
found this and replied to the discussion on the subject.
IMO, Until the OTA is squashed we are going to have a repetitive debockle of blowing up everyones rooted work and would think addressing this would be of significant value:
-cut-n-paste-
I was wondering what you folks thought of this 'prevent' 1.1 hack??
http://forum.xda-developers.com/showthread.php?t=930477
seems reasonable to me, adding:
127.0.0.1 csqaint.barnesandnoble.com
(looks to be the primary check for updates?)
and
127.0.0.1 bncs.barnesandnoble.com
(just for good measure but might have unwanted consequences?)
to /etc/hosts file
I would personally like to be able to put an end to this 'forced' OTA update behind us and be able to sideload any updates from bn manually at our convienence in the future.
how bout u??????
In reviewing the script it appears to apply the build.prop spoof update?
I thought this was questionalble in overall effectiveness?? and even if it worked would have to be reapplied after every update from bn???
I noticed an interesting reply from ixampl as follows:
What I did when the first scare of an update arose was:
a) Checked in /data/data/com.bn.nook.devicemanager/databases/ for an sql file
b) Pulled the sql file.
c) Dump its contents with sqlite3.
d) In it there's an entry for OTAs... with value "auto"
e) Changed that value to "manual"
f) Pushed the modified database file to the device.
I never got any OTA updates. Still on first OS version.
This is exactly what I'm lookin for, a permenant block unless of course the database update got reversed back to auto?????
is this normal? i go into settings/device info/about your nook color. it still shows 1.0.1? where do i have to go to verify this is blocked?
C:\NC - Auto Config Script 1.0.1>adb push block-1.1.sh /system/media
32 KB/s (506 bytes in 0.015s)
C:\NC - Auto Config Script 1.0.1>adb shell sh /system/media/block-1.1.sh
cp: not found
sed: not found
sed: not found
sed: not found
sed: not found
john10101 said:
is this normal? i go into settings/device info/about your nook color. it still shows 1.0.1? where do i have to go to verify this is blocked?
C:\NC - Auto Config Script 1.0.1>adb push block-1.1.sh /system/media
32 KB/s (506 bytes in 0.015s)
C:\NC - Auto Config Script 1.0.1>adb shell sh /system/media/block-1.1.sh
cp: not found
sed: not found
sed: not found
sed: not found
sed: not found
Click to expand...
Click to collapse
You dont have busybox installed on the NC?
bonzer2u said:
In reviewing the script it appears to apply the build.prop spoof update?
I thought this was questionalble in overall effectiveness?? and even if it worked would have to be reapplied after every update from bn???
I noticed an interesting reply from ixampl as follows:
What I did when the first scare of an update arose was:
a) Checked in /data/data/com.bn.nook.devicemanager/databases/ for an sql file
b) Pulled the sql file.
c) Dump its contents with sqlite3.
d) In it there's an entry for OTAs... with value "auto"
e) Changed that value to "manual"
f) Pushed the modified database file to the device.
I never got any OTA updates. Still on first OS version.
This is exactly what I'm lookin for, a permenant block unless of course the database update got reversed back to auto?????
Click to expand...
Click to collapse
Can you elaborate a little further on what commands you used so I might be able to add it into a script.
i dont think so... what installs busybox?
No offense, but this isn't a worry any more anyway. We already have a CWM flashable update.zip that updates you to 1.1, but does not harm your root or installed aps. Why are people bothering with all this "blocking" nonsense?
From this thread:
http://forum.xda-developers.com/showthread.php?t=874871
Attached is a working sqlite3 binary. Copy it to /system/bin and you will be able to edit sqlite databases on the nook itself.
--------------------------------------------------------------------------------
Attached Files sqlite3.7z (11.9 KB, 56 views)
-----------------------------------------------------------------------------
And I found a sqlite3 sample that will need to be edited like somthing as follows:
In your terminal,
$ adb pull /data/data/com.bn.nook.devicemanager/databases/settings.db settings.db
$ sqlite3 settings.db
sqlite> update secure set value='manual' where name='an entry for OTAs???-Dont know the parameter here'
;
sqlite> .q
$ adb push /data/data/com.bn.nook.devicemanager/databases/settings.db settings.db
$ adb reboot
Hope this helps, I dont know the input name for placeholder.
xboxexpert said:
You dont have busybox installed on the NC?
Click to expand...
Click to collapse
Ok i installed busy box off the market, and ran the script!!! success. when i rebooted it told me that 1.1.0 has been installed. and it now shows 1.1.0 in the about.
i suggest noting busy box in the original post.
Divine_Madcat said:
No offense, but this isn't a worry any more anyway. We already have a CWM flashable update.zip that updates you to 1.1, but does not harm your root or installed aps. Why are people bothering with all this "blocking" nonsense?
Click to expand...
Click to collapse
not everyone wants to upgrade to 1.1, or has cwm installed.
john10101 said:
Ok i installed busy box off the market, and ran the script!!! success. when i rebooted it told me that 1.1.0 has been installed. and it now shows 1.1.0 in the about.
i suggest noting busy box in the original post.
Click to expand...
Click to collapse
It says 1.1 is installed but its really not. (Spoofed it)
john10101 said:
not everyone wants to upgrade to 1.1, or has cwm installed.
Click to expand...
Click to collapse
Uh... why? What is there about 1.1 not to want? And if you are ok with doing all of this to block an update, there is no reason not to have CWM (which is quite stable). Sorry, but this really is all just wasted effort..
Divine_Madcat said:
Uh... why? What is there about 1.1 not to want? And if you are ok with doing all of this to block an update, there is no reason not to have CWM (which is quite stable). Sorry, but this really is all just wasted effort..
Click to expand...
Click to collapse
Took me 2 seconds to throw together...took longer to upload then anything. Its just for people who want it. If you dont want it I dont want you to have it :/
xboxexpert said:
Took me 2 seconds to throw together...took longer to upload then anything. Its just for people who want it. If you dont want it I dont want you to have it :/
Click to expand...
Click to collapse
Don't get me wrong, im not knocking your work, just people's reasoning for wanting it done in the first place. I understand before the update.zip was developed, since it would break root and mess up your apps. But now, there is no reason not to take the update; thus the continued demand for this is puzzling.
If you really want the OTA update to stop, take a look at the updater-script inside the sideload_update.zip file from B&N. The first two lines read:
Code:
assert(getprop("ro.product.device") == "zoom2" ||
getprop("ro.build.product") == "zoom2");
I think those are set in the build.prop file. Change either ro.build.product or ro.product.device to something other than zoom2 (say zoom2a), and the rest of the script won't continue. This is what people are seeing when the file gets downloaded OTA and then disappears without being applied. If for some reason you must avoid it, make that change and you will stop the update cold. Not sure what the side effects of making the change are, but there would be an easy way to revert by undoing the edits, if you need to.
Wasn't this already available from another forum member?
http://forum.xda-developers.com/showthread.php?t=930382
Seems a lot easier to just copy and replace build.prop with a filemanager.
Divine_Madcat said:
Uh... why? What is there about 1.1 not to want? And if you are ok with doing all of this to block an update, there is no reason not to have CWM (which is quite stable). Sorry, but this really is all just wasted effort..
Click to expand...
Click to collapse
Yah go ahead and read thru the cwm thread and try to convince anyone in this forum that it is 100% stable. Not to suggest that anyones efforts are not welcome and appreciated but if you asked the actual devs involved I would bet they would not suggest so as well.
I for one have rooted twice (1.0 and 1.0.1) with autoroot and am 100% stable, never had a crash or the pleasure to have to restore/rebuild, not interested in the stock browser or anything else bn has to offer, quite happy and perhaps lucky with the way its workin now. I also dont appreciate being strong armed an update without a confirmation, hell even microbuddies doesnt have that kinda gawl.
I guess it will take one of the next of many 'future forced' updates from bn that bothches all the work that you have put into your NC and for whatever reason your recovery doesnt work and you are forced to rebuild from scratch before you realize that if you had a permenant block in place, you could have the time for outstanding efforts of the local devs to stabilize an upgrade path before you pulled the trigger?
The database hack appears to be best way to permanently kill OTA, no need for future updated spoof build.prop scripts (before you get hit) and no worries about being updated and possibly blown up while your sleepin and bn pushes an update out before you get the news.
or maybe its just me..........
Exactly! If you are not diligently checking the forum everyday, you wouldn't know BN is pushing out 1.1 update and you wouldn't know there is a pre-nootered 1.1 version available. BN will update you OTA before you know any better and screw up your rooted setup. Hence the need for a permanent update block.
Hey guys, I came up with a basic set of tools which I find useful. You may redistribute , include in any custom ROMs and/or distributions.
This includes:
Rewrite /default.prop for ADB
Install and deploy busybox in /system/xbin
install bash, ipctool, strace, tcpdump, and viewmem binaries.
To install, you must be rooted.
Unzip the attached file
place it on your nook.
cd to the folder you installed
Run the following
Code:
sh /sdcard/BHT/run.sh
Please note, I use Android Market app QuickSSH to get into my nook terminal, your results may very.. I hope someone else grabs these files and makes it all more user friendly. I've got too many other things going on.
I encourage other developers to include these valuable debugging tools in their packages.
You, sir, are a monster! You get my vote.
Sent from my Nexus S using xda premium
AdamOutler said:
Hey guys, I came up with a basic set of tools which I find useful. You may redistribute , include in any custom ROMs and/or distributions.
This includes:
Rewrite /default.prop for ADB
Install and deploy busybox in /system/xbin
install bash, ipctool, strace, tcpdump, and viewmem binaries.
To install, you must be rooted.
Unzip the attached file
place it on your nook.
cd to the folder you installed
Run the following
Code:
sh /sdcard/BHT/run.sh
Please note, I use Android Market app QuickSSH to get into my nook terminal, your results may very.. I hope someone else grabs these files and makes it all more user friendly. I've got too many other things going on.
I encourage other developers to include these valuable debugging tools in their packages.
Click to expand...
Click to collapse
I can turn this into an apk, if you don't mind. By turn on adb with this method, adb will be rooted and the device will still be allowed to sleep?
brianf21 said:
I can turn this into an apk, if you don't mind. By turn on adb with this method, adb will be rooted and the device will still be allowed to sleep?
Click to expand...
Click to collapse
By all means. Please do.
My vote too. I just hope after you win that you keep up the great work on the Nook Tablet. The last two weeks or so have looked very promising towards getting custom roms on here and a lot of that has to do with Adam's hard work along with a few others
Nearly all of these are already in snowball-mod, but I'll include ipctool, and viewmem for the next release.
cfoesch said:
Nearly all of these are already in snowball-mod, but I'll include ipctool, and viewmem for the next release.
Click to expand...
Click to collapse
How did you get default.prop reread into memory? The only think I can see is the 2nd init hijack? Am I missing something a lot easier?
brianf21 said:
How did you get default.prop reread into memory? The only think I can see is the 2nd init hijack? Am I missing something a lot easier?
Click to expand...
Click to collapse
Note, I said "nearly all". I don't really see though how changing /default.prop would keep over reboots... rootfs is stored in memory and recreated every time, isn't it?
I've added the binaries to NT Hidden Settings. I have not implemented /default.prop swap yet. I have to play with hijacking init before I do. Thanks again.
brianf21 said:
I've add the binaries to NT Hidden Settings. I have not implemented /default.prop swap yet. I have to play with hijacking init before I do. Thanks again.
Click to expand...
Click to collapse
cool. where are you hosting that binary? I currently have a mirror set up at nook1.adamoutler.com for easy access... When someone gets a new device, they need to download 3 things onto their device to make it a real tablet.. nook1=hidden settings, nook2=homecatcher, nook3=market.. I may change 3 to launcherpro, but hidden settings is the number1 tool required for the nook Tablet.
AdamOutler said:
cool. where are you hosting that binary? I currently have a mirror set up at nook1.adamoutler.com for easy access... When someone gets a new device, they need to download 3 things onto their device to make it a real tablet.. nook1=hidden settings, nook2=homecatcher, nook3=market.. I may change 3 to launcherpro, but hidden settings is the number1 tool required for the nook Tablet.
Click to expand...
Click to collapse
Homecatcher? I mean, I understand if you want to keep using the B&N store and stuff, but if you don't care about the B&N stuff, then the hacked SystemUI.apk is a way better option than Homecatcher.
But then, you're advancing "launcher pro", while I would more generally say "any non-B&N launcher"...
I added another option to nt hidden settings to run adb as root. It doesn't require a reboot and it automatically turns off auto mount. I am using nemith's adbd.
remount / as rw
stop adbd
replace /sbin/adbd
remount / as ro
setprop to turn off auto mount
start adbd as root
It's not persistent after reboot, but it works and doesn't kill the battery. I am not going to bother with hkvc's hijacking init method, because it looks like you, hkvc, bauwks, and nemith will be able to replace the os soon. Thanks.
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.