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.
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?
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.
Indirect is proud to present you with ADB Hijacker
Note: This modification will remove any custom clrbootcount.sh scripts
Alright, what this application does, is hijacks adb using a root version instead which means from now on, you can do "adb remount" and things like that. This comes with all the needed files within the app and it also extracts them so no worries!
After you run the app once and click that magical button then you can reboot and you will have adb autostart as root so you can even uninstall the app afterwards. As of now, we do not have automount killed. However: I learned that adb stays on even while in usb mode.
Download Link:
Here
Screenshots: Uploading
Benefits and change log:
Benefits:
Code:
You can now rerun the rooting script to apply whatever modifications you missed out on
You can now apply any mod using adb instead of file explorer
You can remount your system by just using "adb remount" instead of using a file explorer
Changelog:
Code:
2.0: Included needed files for extract / included busybox installer
1.0: Initial Release
Credits:
Code:
brianf21 for showing me how to extract files from an apk so now you can install directly from the app and nothing else is needed except root.
Nemith for the adb daemon
Myself for the app, hijack method, and testing
puellanivis from IRC for being terrible at communication and also help with a few of the commands
This one is mine as well.
damn you, I am taking this one for video! click comment for video
Firstly,
Thanks Indirect, you make my Nook a joy to use. Many thanks also to Albertwertz - your Youtube videos are helping a noob like me get up to speed with this Android experience.
Can't post this in the Developer thread (still under 10 posts) but there seems to be a problem running the nookandzergy.bat file whilst running the ADB Hijacker. I'm getting a dos error:
"Your device was found to be rooted. Which is bothersome. However: I will see if you happen to have the proper modification installed to continue to use this script:"
followed by
"goto was not expected at this time".
Having a quick look at the bat file I can't see where %adbr% is being set to "yes".
Update: After making sure adb hijack was running, I tweaked the batch file, forcing adbr=yes. The script then worked and allowed me to replace the SystemUI.apk to remove the B&N Home button. Not sure how Indirect intends to set the variable properly, but by adding:
set adbr=yes
above the line:
if %adbr%==yes goto N1
Allowed by to re-run the rest of the root process
Another thing I did notice when testing the script was that by selecting "N" to the "Do you want to replace the systemUI to have a perm back / menu button on status bar and have the N button goto home on first click?" question the script errors with a -N7 not found.
I am having the same problem. I followed the video that albert posted and even opened up the cmd line to double check my adb remout. Everything worked fine till i get:
"Your device was found to be rooted. Which is bothersome. However: I will see if you happen to have the proper modification installed to continue to use this script:"
followed by
"goto was not expected at this time".
I don't know if Nook&Zergy is setup to support the adbd hijack yet. But that is the most likely answer. Or in particular, you might not have the newest N&Z as well.
I also wanted to momentarily divert the thread, and mention that snowball-mod already includes this adb-hijack, so it is unnecessary to run it on snowball-mod. (However, Indirect worked with me to ensure that it wouldn't hose anything if you did.)
Before I ran nz, i downloaded the latest from Indirect's original root thread. If the updated one isn't using that link, then where do I find it?
Indirect and I were up kinda late last night working on this and he made several modification on my nook zergy extraction that he may have forgotten to make when he remade his and uploaded it for everyone. Here is a link to the mod he made of the latest nook zerg on my pc. This may have something that the new one doesnt that he forgot to do. I am sure he will fix the code soon, but until then, download and try this: http://dl.dropbox.com/u/24100179/Nookie/NookandZergy.bat
this is the nook zergy bat file he modified. copy it and replace the bat file in your new nook zergy extraction and see if it runs right with this app
This is only temporary, dont use this after he fixes it
That did the trick! Thanks Albert!
I just got my nook & I don't understand the programming that you are talking about. But if you both were up late working on the root script (assuming). Just an FYI once I finished w/ the driver loads & started loading the root script, my device wouldn't show up, did a factory reset 3 times, as well as removing any usb traces etc... finally got it to take & all the red stopped & never loaded in the gapps, launchers etc... I reloaded it again & it says that I am rooted, but having a heck of a time w/ Titanium doesn't want to accept any of the
devicemanager .apk stuff. Sorry for no tech terms, Indirect & Albert Thank you so much for making this easy. Loved the video, really helped a ton. Just wanted to say thanks & let you know of the glitch.
I got it loaded now it is not recognizing the sd card 4 Titanium. I have done several of your factory reset, as well as the b&n reset still nada even put in 4 different cards. Happy New Year & Thanks for any help
TRI
did this today, easy, took 5 minutes. Grateful for all this
I'm a little bit confused, my nook updated to 1.41, i've tried downloading adb hijacker to my nook, but it won't open, what am I doing wrong?
Edit: What exactly do I need to do to block the updates and allow my nook to use the android market again?
I'm a pathetic no0b, and I tried downloading the ADB hijacker to my nook, but it won't open. What do I need to do to fix this?
Thank you.
ETA the Nook updated the other day.
Indirect said:
Indirect is proud to present you with ADB Hijacker
Note: This modification will remove any custom clrbootcount.sh scripts
Alright, what this application does, is hijacks adb using a root version instead which means from now on, you can do "adb remount" and things like that. This comes with all the needed files within the app and it also extracts them so no worries!
After you run the app once and click that magical button then you can reboot and you will have adb autostart as root so you can even uninstall the app afterwards. As of now, we do not have automount killed. However: I learned that adb stays on even while in usb mode.
Download Link:
Here
Screenshots: Uploading
Click to expand...
Click to collapse
absolutely awesome!
Guys, this doesn't stop updates or is usable on the 1.4.1 update..it's a 1.4.0 modification that hijacks the adb daemon on the device.
Ok, but what do we do if we didn't get to it in time and the stupid thing updated to 1.4.1? Do we have to return the thing to factory settings and lose all our content?
I'm sorry for asking dumb no0b questions, but if there is a guide for what to do in this situation, I can't seem to find it here.
Thanks for all you do, all the experts here!
ETA I found what I was looking for, in the "Nook general" forum. sorry to waste space on this thread.
My mistake, I thought I would be able to apply the update that stops the ota's through this. Which thread has the method to allow me access to market again? (effectivly null n' voiding the 1.41)
nearlyno0b said:
Ok, but what do we do if we didn't get to it in time and the stupid thing updated to 1.4.1? Do we have to return the thing to factory settings and lose all our content?
I'm sorry for asking dumb no0b questions, but if there is a guide for what to do in this situation, I can't seem to find it here.
Thanks for all you do, all the experts here!
ETA I found what I was looking for, in the "Nook general" forum. sorry to waste space on this thread.
Click to expand...
Click to collapse
^^^^^ Quoted for the sake of others ^^^^^
arkraven000 said:
My mistake, I thought I would be able to apply the update that stops the ota's through this. Which thread has the method to allow me access to market again? (effectivly null n' voiding the 1.41)
Click to expand...
Click to collapse
Below is a link to the information as to how to remove B&N 1.4.1 update and restore 1.4.0:
[Stock Firmware]Restore Barnes & Nobel Nook 1.4.0 from SDCard
ENJOY!
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.