« Posts by ChainsDD

I updated to 3.0.1 binary and lost root, HELP!

While I was away in Italy, I was spending as much time as I could trying to find a fix for the issues that people were having with Superuser 3.0.5. One of the fixes involved a new binary that sets it’s own UID to that of the Superuser app before opening the database to prevent the WAL files belonging to root. This fix worked great and I am indebted to HomerSP for finding it. When I got home I set about updating my normal build machine to compile a new binary for release. I updated my AOSP trees agains the new repo that was put online while I was gone, compiled 3.0.1, and put it out there. That’s when things went wrong. I started getting reports that after people updated to 3.0.1, they lost root. Terrible thing is that it works great on all of my devices, as usual. I think the problem is that at some point the generic gingerbread AOSP tree went from compiling for arm generic to compiling for ARMv7-a, and su 3.0.1 is now compiled for ARMv7-a. There are many devices out there that use the older ARMv6 (ARM11) architecture, and all of the issues that have been reported to me that include what device they’re on happen to be ARMv6…

I’m trying to get a couple testers to help me make sure that this is the problem, but if no one comes forward willing to help in the next couple hours, I’m just going to have to pull the trigger and release a new binary compiled against arm generic. If you have a device that has an ARMv6 (ARM11) chipset, please email me at superuser.android@gmail.com to help me find the solution. You will need to have ADB up and running, and adb needs to give you a root prompt (#) when you run ‘adb shell’.

Thank you for your patience.

Update: The issue has been fixed and new versions of the su binary have been uploaded to here and ROM Manager. I know ROM Manager won’t help those of you with broken root, just download the update.zip from here, put it on your sdcard, reboot into recovery and install it.

Update 2: Another update, another binary. The code in 3.0.3 is the same as the code in 3.0.2, and 3.0.1 in fact, just built a different way. This version has been tested and verified to work on both ARMv7 and ARMv6 devices. Both

Status Update

I know there are bugs in the latest version of Superuser (3.0.5), and I’ll do my best to explain what is happening to you. Before that I need to make sure that you all understand that I am the only developer of Superuser (no team, just me), I work full time in the Air Force (Superuser is simply a hobby for me), and I am currently out of the country working.

Now let me say that the current version of Superuser works flawlessly on every device that I have on my test bench, which consists of:

  • Nexus S – CM7.0.1
  • Nexus One – stock rooted Froyo
  • MyTouch 3G – old version of CM based on Donut
  • MDP8660 – stock rooted Gingerbread
  • Xoom – stock rooted 3.2
  • Nook color – CM7 nightly

I do extensive testing of each version on every device that I have before release. That being said, there are thousands of combinations of devices and ROM, which makes ensuring compatibility with every one of them impossible.

The issues that people are having are, for the most part, down to using an outdated binary. With the last couple versions, I tried to remove the requirement to have the latest binary, since there are so many people out there that either have some form of write protection on their system partition at runtime (S-ON), or have the su binary installed in /sbin. Both of these things make it impossible for me to update the binary.

S-ON is easy, since those users can simply download the latest version through ROM Manager, or from this site and flash via recovery mode. This will install the latest binary, and fix the problems.

People with the su binary located in /sbin have a much tougher time. I’ve found that these are mostly Samsung users (with the notable exception of the Nexus S). I don’t know why it’s done this way, and if anybody does know, please let me know, but for some reason kernel and ROM devs for these devices put su in /sbin. /sbin is part of the boot.img, and therefore any modifications to that directory will be erased on boot.

The issues that people are having are caused by a binary that leaves the permissions.sqlite database open while it sends the intent for the prompt. This used to be ok, but sometime in Gingerbread, android started using WAL for SQLite, which causes the app to not be able to open the database if the binary has it open. The 3.0 binary is very good about handling the database, and has no issues if the app has the database open at the same time it needs to read from it. the 2.x binary is not so good about it. The fix that I have worked out for this, and am in the process of trying to implement is to have a service that will update the permissions.sqlite database as necessary, and if it fails to open the database, it will schedule itself to start again until it can gain access to the database.

The other issue I’ve seen is that on some devices, the WAL bits of the database are having their owner changed to root (0), the main database still belongs to the Superuser app, but the parts that are used by WAL belong to root, which makes it impossible for it to be opened by the app. This issue is being a lot harder to track down, because it seems very intermittent and there are so many users that are incapable of helping to track it down for whatever reason, but I am trying to find it.

As I said above, I do everything I can to make sure that things are working, but I can’t test on every device. So what I’ve decided to do is to create a Superuser tester program. I’ve created a form on Google Docs that you can sign up to receive test versions of Superuser before I publish them. There are three levels of testers; Alpha, Beta, and RC. Each will get test versions at different times and have different “responsibilities”. Hopefully I can get plenty of people to sign up and we can make the Superuser experience better for everybody. Please sign up here. Might take me a couple days to get things rolling with the program, but if you sign up, expect a test version soon.

I appreciate everybody’s patience as I get very little time lately to work on these things. Unfortunately I already offered my country 4 more years, so Superuser won’t be a full time job anytime soon. Just know that I am looking into your issues as I can. If you’re a better coder than me, with more time, please feel free to fork the project from my github and submit a pull request for any bugs you can fix.

Initial impressions of 3.0

Last night I released Superuser 3.0 final. After being in development for so long, you’d expect it to be bug free, but that’s never the case, is it? Nice thing about it is that here in the first few hours of the launch it seems that most of the problems aren’t anything I did. Here’s a rundown of what I’ve seen so far:

1) Signature error when updating from the Market – This is a common thing that’s been happening since I released Superuser to the market. All apps must be signed before being uploaded to the Market, so when I decided to put Superuser up on the Market, I generated a key, signed it, and uploaded the key to my github repository and the CyanogenMod repos. Once an app has been uploaded to the Market with a particular key, it can never be changed. So if the Market is telling you that the package is incorrectly signed, it’s because the Superuser that is included in your ROM is not signed with my keys (which are, again, publicly available). You can’t update an app if it’s signatures don’t match. Not the end of the world though, there are a couple ways to fix it. First thing you can do is try the Superuser Update Fixer from the Market. It doesn’t always work, but what it tries to do is fix the wrong signatures by replacing the Superuser.apk that’s installed on your system partition with one that’s signed with the proper keys. If that fails, you can try updating Superuser through ROM Manager. I’ll keep Superuser updated in both the Market and ROM Manager, so you’ll get the latest either way. The benefit of using ROM Manager is that it will also update the binary to the latest version without you needing to do anything.

2) Binary updater fails to update binary – This usually happens because for Superuser can’t write to the system partition where the binary is installed. This can happen for a couple reasons. First, and most common, is that your device has S-ON which prevents the system partition from being written to at runtime. Even if a remount succeeds, and the system thinks that the partition is mounted as rw, you can’t write to it. There are different solutions for different devices, but the easiest usually involves simply updating Superuser through ROM Manager. If you were able to flash a custom ROM, you’ll be able to update Superuser through ROM Manager. The other reason that updating the binary fails is that your ROM Dev did something silly like putting the su binary in /sbin. I have not found a reason why this would be done, but I’ve seen it many times. The problem with putting su in /sbin is that even though you may be able to modify it at runtime, the changes will not stick over a reboot. This is because /sbin is part of boot.img, which gets unpacked and loaded at boot. The other problem with having the su binary there is that it’s almost always the first entry in the PATH. If you’re unfamiliar with the PATH, it’s a list of places that the system will look for a program, once it finds one it stops looking. Superuser will not try to update su if it’s found to be in /sbin because the change will not persist. The fix for this is not quite so easy as before and you’ll likely have to change ROM, and let the developer of whatever you were using know that they’re doing it wrong.

3) No paid app support in your country – This one I can’t do much about currently. I do have plans to introduce other options for buying Elite, but it’s break time for me. In the future I intend to have PayPal and in-app billing suport, but that’s further down the road with no ETA. You may have the option of using an app like Market Enabler to trick the market into thinking that you’re somewhere else. I have no idea if that’ll work or not, but it doesn’t hurt to try.

4) Not in CM7 yet – This could take a little bit. The problem here is that since CM7 is built from source entirely, Superuser is also built on their computers against the AOSP tree. The Superuser source is one package for all all versions of Android from 1.6 all the way to 3.2, and it’s got references in it to Honeycomb specific things. This will break the build against a Gingerbread source tree since it won’t be able to find those Honeycomb specific references. I will get something put together to submit to the CyanogenMod team, but it’s gonna take me a couple days.

I hope that things will continue to run as smoothly as they have been, but that’s probably asking a whole lot. If you find issues not mentioned above, let me know. The best way is through email, at superuser.android@gmail.com, that way I can easily get back to you and sort it out. I’m gonna take a little bit of time off to relax, then I have another couple of projects that I’d like to explore. I will continue to work on Superuser and continue to implement new features as I come up with them, as well as implementing all of the other features that I have planned for Elite.

Thanks for all of your feedback, and enjoy!

Top 9 Root Apps

I asked on twitter what your favorite root apps are, and here are the results, with their market links.

9. ShootMe (free) – Shake or shout to take a screen shot of your phone. It can use the light sensor on your phone if it’s there, and even record video screencasts on some high-end phones.

8. Screenshot ER 2 ($1.49) – Shake, delay or notification icon capture. Also works on Honeycomb.

7. drocap2 (free) – Shake, delay or notification capture, like ER, only this one is free.

6. Terminal Emulator (free) – Terminal for your phone. Full access to the linux command line, if you know how to use it.

5. AdFree Android (free) – Block adds in the browser and apps with an updated hosts file. Please buy apps to support devs if you’re gonna use this.

4. SetCPU ($1.99) – Control the minimum and maximum frequencies of your phones CPU, as well as which governor controls them.

3. ROM Manager (free) A must have app for anyone who likes to change ROMs regularly. Easily download and flash a new ROM, or backup your current ROM. Buy the Premium version ($5.86) for even more ROMs and features.

2. Root Explorer (~$3.88) – A great file explorer for full access to the entire filesystem on your phone.

1. Titanium Backup (free) – The ultimate backup utility for your phone. Can backup data from any app, plus loads more. The Pro version (~$6.00) adds more great features and supports a great dev.

So there you have it. Top 9 root apps voted for by you. Try ‘em all out. Enjoy!

A Word About Superuser and Security

It has recently come to my attention that there are people out there that believe that Superuser in the wrong hands can be a dangerous thing. A quote from my @DroidSecurity on twitter (edit: @AVGFree agreed with this tweet shortly after DroidSecurity posted it):

@TeamAndIRC @ChainsDD @AVGFree : SuperUser is not considered bad , but rather can be dangerous in a non-techie hands , The Antivirus team

Now I may be arguing semantics here, but I have to disagree with this. The discussion came up because I asked AVG to reconsider their app flagging Superuser as a risk. While I can’t argue that a rooted phone can be a risk, Superuser itself is not. In fact, once a phone is rooted, Superuser is one of the few things that provides any sort of protection. Without it, any app would be able to use root at will and unchecked. Superuser gives the user a notification when an app is using the root user, and gives them a way to look back at what has used it and when. Similar to UAC on windows computers, it forces the user to consider what they are doing before they alter their system.

Regarding AVG, there are two situations in which their app would detect Superuser being installed. The first is that the user has rooted his phone. In this situation, Superuser.apk is installed in /system/app. In this case, there isn’t really anything that AVG can do about it. In order for it to remove the risk, it would have to remount the system partition (and it would have to use Superuser to achieve that), and manually remove the apk. Instead it displays the system’s uninstall window, which naturally fails to uninstall the app, and goes back to scanning, once again finding the “infected” Superuser thus starting the process all over again. Infinite loop?

The second situation is that the user does not have a rooted phone and they download Superuser from the market. In this case, Superuser is completely useless to them, as Superuser has no way of allowing other apps to use the root user without already having the su binary installed in a directory in the PATH. and since none of these directories are writeable at runtime, there is no way to do that. Superuser does not use any of the exploits that are widely available (Gingerbreak, Rageagainstthecage). Superuser will not root your phone by itself, it needs outside methods for it to do anything at all. This becomes a false positive for AVG, as Superuser cannot do any harm to the user or his phone.

This brings into question the method that AVG uses to find “infected” apps. This post did not start off to be a post slamming AVG, but I got really frustrated when, while researching for this post (installing AVG and trying it out), I found that AVG also flags Superuser Elite as “infected.” This made me realize AVG may be using some kind of sophisticated scanning, but more likely they are simply using a list of package names that they have deemed to be “infected.” I had planned to baksmali their app and dig around to see just how their “scanner” worked, but it seemed much easier to do it this way:

  1. Fire up Eclipse and make a new android app with the package name “com.noshufou.android.su.helloworld”.
  2. Do not change anything in the app.
  3. Install the app on my phone that is running AVG.

Result? Popup window on the phone telling me that this “Hello, World!” app is infected. Seems as though Google has some serious problems if a basic “Hello, World!” is a virus. More likely is that AVG is looking at nothing more than the package name and determining that the app is a threat simply because it has “com.noshufou.android.su” in the package name. I would have attempted making an app that has one of the exploits in it, but with a different package name to see if it gets caught, but that’s not something I have time for. I do encourage my readers to try this though. It would be interesting to see if AVG, or any of the Android “antivirus” apps, can detect a true threat.

At the end of the day, I hope this article encourages companies like AVG to implement true threat scanning, if they haven’t already, or stop posing as antivirus. A blacklist based on package name is not antivirus and provides the user with a dangerous sense of false security. I also welcome AVG or any other maker of an antivirus program for Android to come forward with a response to this telling the users how their app actually protects their phone.


Upcoming Developers Features

I need to get some feedback from developers who’s apps use Superuser. I’ve got some features planned that may make life a little easier for you, but I want to see what you guys think.

The first proposed feature will be a ContentProvider that allows read only access to what permissions are granted and logs. I’m still looking at security implications so I may decide to restrict it so that an app can only access information about itself. This will also depend on whether or not the ContentProvider has access to information about the app making the query. I just came up with this idea this morning so I still need to do some more research to flesh it out. The other side of the ContentProvider is that I will be able to use it internally and maybe rid myself of all the problems I’ve had with Superuser on newer systems with WAL.

The other feature I’m looking at is exposing an intent to allow apps to pre-request Superuser permissions. It’ll be as simple as sending the intent with the required information, possibly as little as the command you want to run, and Superuser will display the prompt and return to you whether or not the user allowed it. Obviously you’d have to check that the intent is available before you do it, but it could eliminate problems that happen if you don’t gracefully handle denied su attempts.

Let me know if you guys would use these features. Also let me know if there are other things that, as a developer, you’d like to see.

Leave your thoughts in the comments.

Who likes preferences?

Past couple days work for you to enjoy. Most of these preferences are already functional. The rest will be soon. I’m still debating on whether to put elite options here in this preference screen, or their own. What do you think? Let me know in the comments.

P.S. That first screenshot isn’t doctored in any way. I actually have a phone that has a screen with those dimensions. It’s a pain to talk on tho ;-)

Today’s progress

Took the day off from my regular job today to get some work done on Superuser 3. I didn’t get as much done as I would have liked, but I did complete one whole activity… Superuser 3 now has a much better way of updating the su binary, and it’s a lot more verbose than 2.x’s updater. Check out the screens below to see what I mean. For those of you who haven’t seen the new interface (which I think, outside of a select few, is pretty much everybody…), I included a couple more screenshots showing the direction the app is going.

**Edit: Forgot to mention that anyone looking to test out the latest version can download the source from my github and build it. I won’t be giving instructions on how to do that, so if you can’t figure it out for yourself, don’t try it. The code for the app and the binary are there, but I’d recommend only building and installing the apk. That way you can test out the new updater activity for me :-)

Superuser Update Fixer

Hello SU minions! We’ve got good news for you today! For anybody that’s ever had a problem updating SU, the update fixer is now available at the top of the page. You will need to download this app if you are having issues with SU installing.

So now that this  issue has been resolved, ChainsDD is going to be devoting most of his time directly to Elite! We are very excited to have this being worked on right now. I know it’s been a process, and most of you have been great about it. But as you know, you can’t rush a genius, so please continue to have some patience. ChainsDD is trying to sort through the numerous requests he has received about things that some of you would like to see on Elite. He’s trying to implement what he can, but he likes to be thorough and tries really hard to release a good product that he can be proud of.

Please do not ask for an ETA. From now on, those that ask are going to be told in one years time. lol I’m sorry, but he’s working on it for hours upon hours a day, and doing everything he can to get it ready for release. We don’t know when it will be done. There’s the coding to do, the bug fixes to take care of, the testing, etc. For those of you that have sent me literally hundreds of emails (from the same people, over and over again) asking for an ETA, WE DON’T KNOW. As soon as it’s ready, it will be available. But the more time we have to spend sorting through emails and such, all saying the same thing, is the less time he has to develop. So please know that anyone who asks again, will have their message immediately deleted and will not receive a response.

I am not trying to sound bitchy. I promise you. It’s just frustrating because if I am sorting through hundreds of emails with the same question over and over again, then it takes me that much longer to get back to those that have legit issues that they need help with.

So, Elite is in the works. It’s his priority now and he will have it out as soon as possible.

You guys are all incredible and I look forward to being able to post the update saying Elite is available.

Welcome to the new AndroidSU.com

Hi guys! So here’s the new home for Superuser for android.  Come on in, no need to wipe your feet or take off your shoes, everyone gets to be comfortable here. So here’s where we are going to feature news and downloads for Superuser. Down the road somewhere, I (MrsChains) might just decide to get a little busier and perhaps set up a wiki. Not sure yet, but just maybe. So if you want to keep your foot in the door, here you go. Just subscribe to the page, and we will update as we can.

So pull up a seat, grab a beer, and settle in. Welcome to the new AndroidSU.com