Archive for the android Category
Making smali a bit easier to read in Emacs

Oh that? Just some pretty colors while reversing...

Oh that? Just some pretty colors while reversing...

Spending a large amount of time using baksmali and reading through small files can be rather dull without the right tools. A while back I noticed a few people making color scheme files for vim, Notepad+ and other tools I didn’t use. So after reading up on a quick few tutorials I created a smali-mode for Emacs.

The code is up on my github, I haven’t actually touched it in a while until last night. I noticed a few other people actually pulled clones of it and made a few minor fixes! Some good fixes too, making the loading much faster and fixing some things I wasn’t too sure about myself for making an Emacs mode.

Anyway – hopefully other people find this useful and maybe more people will contribute to the project.

For people looking for the other color schemes here are some of those resources;

Jon Larimer’s vim scheme;

Lohan+’s Notepad+ color scheme; (Directions here)

Conquering the mysterious userId (Fixing Android Market downloading)

Originally I found the easiest way to download applications was just spoofing the final request. This worked – and worked well for the entire time I had been using it. Though it bugged me that I couldn’t find out where the actual userId was coming from. So I keep digging and digging and finally came up with the solution which is posted below. I never really shared this though, since as I said – other people just used the hack and didn’t seem to care much. The main concern people had was “how do I get it faster” – which to that I always replied “learn whats going on”. Plenty of people figured it out, though now, according to the the emails I’ve been getting recently and the ones on the Android-Market-Api Google Group, this stopped old hack has working. So, I guess it’s about time to spill the rest of the mysery.

The requests originally looked like this when being sniffed over the wire;

Though recently they started looking like this;

Well – this didn’t matter much to me since I don’t use that project, but I’ve helped enough people through side channels that I figured the information is as good as public. So I’ve decided to write up a little “what is actually going on”.

Just a little while ago I committed an updated market.proto with the necessary fields to request downloads from the Android Market. Essentially I’ve added the GetAssetRequest and the GetAssetRequest which was previously missing. I also fixed the unknown field which is known as the isSecure field. This boolean field lets the market know what type of request is coming in and which token will be used.

In the order versions of the vending apk, not everything was send over HTTPS. When most normal requests (get application info, queries, etc) where over unsecured HTTP, the GetAssetsRequest was considered “secure” and only went over HTTPS. This meant the isSecure field had to be set and a new authtoken would be used. Instead of the android service authtoken being sent, the androidsecure token would be sent. This is probably done so that if someone was sniffing requests, they couldn’t just reuse your android token and get away with it, though it may have been done for other reasons.

So what was the mystery of the userId? Well – it was never found on the device, because it was never actually stored on the device. It was only stored sometimes inside of URLS which had been cached or saved to databases. If properly using the protobuf, this relieves the person from needing to find these values, since the market themselves provide them! It was a bit annoying to figure this out finally, but also a huge relief since I wasn’t going crazy not finding the userId anymore.

So let’s sum this all up;

1. Get the android secure token for your account, use this as the authtoken for your next request
2. Build proper request protobuf; Use authtoken from above, set isSecure to true and add the assetId to a GetAssetRequest
3. Receive the GetAssetResponse and build an HTTP request from it using the; blobUrl as the URL and set a cookie using the downloadAuthCookieName/downloadAuthCookieValue pair.

Lastly, I’d like the apologize for the delay in this information. I feel a bit bad since I’ve known this for a while, but most people who ask me questions where just using the hack, which — until very recently worked fine. Also, it has always been possible to just reverse the apk yourself and figure out what was going on ;)

Quickly setting up an Android emulator for fuzzing/hacking

Normally I like spending time fuzzing/causing segfaults with real devices, not sure why – maybe it’s just because it just feels more gratifying. Though recently for a small project at work, I need to be able to do multiple devices for longer periods of time and swap out different modules relatively fast. This would be a huge problem – but I wanted to automate it and do the least amount of work possible. A challenge that comes up sometimes with the somewhat stock phones I use for testing, is that some compiled modules/elf binaries never worked that well. Sometimes due to carrier modifications, sometimes due to Cyanogen modifications other times just due to me being stupid and compiling things horribly wrong. Since I just got my desktop machine all set up, it seemed like the perfect time to try and automate this on a box I could just SSH into and let run all the time!

After a quick bit of Googling, I didn’t see many instructions on how to modify emulator images fast. Lots of people said, generate an emulator, then change the system.img by mounting it, then restart the emulator and make sure it doesn’t overwrite changes. That’s a pain though, I don’t want to mount anything! Though this did remind me of building the AOSP which can product the system.img — perfect!

After making all my changes, some Dalvik changes and some Webkit changes, kicked off a full build via the normal commands;

While waiting for the compilation to finish – I prepped a “target platform” to build an emulator image for. To quickly do this I just copied the android-15 directory under the platforms directory of the sdk. This will give us the proper structure and files required while keeping the normal platform for android-15 intact.

Awesome, we copied over the system.img too the nessicary directory, lets just edit a few files so I don’t forget what this when I build my emulators. Open up the file and edit the version number to something you can remember, I just changed mine to say 4.0.3-hacked;

Now I can just create an emulator like normal and fire it up;

Now it just time to attach your fuzzing and other automated tools to the emulator.

Welcome to ADB HELL!

A coworker just pointed out something that really made my day. Apparently if you type “adb hell” opposed to “adb shell”, it will give you an adb shell with hellish colors:

Welcome to hell... ADB HELL!

Welcome to hell... ADB HELL!

Thanks Google, I always enjoy your humor :)

For those interested, the code that does this can be found here:

Edit: Some people have been mentioning it didn’t work for them, so I found the commit so you know if you’ll have it or not. Thanks Daniel Sandler and Mike Lockwood for the Easter Egg!;a=commitdiff;h=9c73d17e870e448ea1f036bda70736ae0ae6bf2e

Detecting Android devices that are blocking ads

A friend of mine pointed me in the direction of an interesting app a few days ago. They had been using it for a while and just installed an ad-blocker, the type that just modifies your host file with a bunch of known ad providers. Then they’re new favorite application stopped working, complaining that the ads where blocked. This may not have been the first attempt to detect ad removal, but it was the first one that I’ve looked at or even heard of. It’s nothing fancy of course, but it’s actually a nifty idea. The way it has been implemented there are plenty of ways to get around it, but it’s definitely was a nifty piece of code. Quiet trivial to patch if someone wanted to, though I see no reason to not support the devs.

Anyway, I quickly just reversed the code, since most people don’t care for reading the output of dexdump;

Maybe some other dev’s will find this useful.

UPDATE: It would appear the code I reversed was posted on StackOverFlow. No sense in deleting this page though – next time I’ll just have to Google a little better! :)

Geinimi – Give me your rice… NOW!

So lately I’ve had the pleasure of reversing the latest Android threat, Geinimi, and boy – it sure is something else!

I don’t want to go too much into depth for it here as it’s already been torn apart and posted on my works blog. Our latest release has all the technical details outlined and a full teardown in pdf form.

Something I will post here is a nerfed script from Jaime Blasco, a newly found friend of mine who works for AlienVault. He posted a nifty nmap script for detecting Geinimi infected devices. His original script can be found on his blog post, though I’m done some minor improvements to it;

Essentially I’ve added the three extra ports that the main Geinimi service will bind too. The main port is still 5432, though it can attempt to connect on the other two ports. The other thing I’ve added was a check to the presumed command plugin that a Geinimi device may also have, which is bound on port 8791.

Hopefully everyone enjoys the teardown and maybe this script would be useful for anyone who is interested in auditing their network of multiple Android devices.

“Insecure” spyware and the ransomware counterparts

A few weeks back a company named DLP Mobile got some press about a “new spy app”, which well – it just very similar to all the other ones we’ve seen. It “hides” itself and forwards its text messages to other numbers. Very sneaky and genius, no? Wait, let me rephrase that, no – not very sneaky or genius :) Anyway, that’s not really what I want to blog about. Shortly after the application was removed from the Android Market by Google [link], another interesting one appeared – “Reveal: Anti SMS Spy”.

Not only has the company published a spyware application, but they decided to sell a program to remove it too. Interesting move by them, I guess? Seems like an attempt a FUD and trying to make some quick cash. While I have no idea the true intentions of the creators, I do find it interesting that the price of the application keep increasing that the price of the application kept increasing which each press grab. A nice little article actually brought this up again early this week at the Register.

On top of all this nice news – there where quiet a few tear downs of the application. A good one, written by Axelle Apvrille of Fortinet, highlights the “backdoor” inside it. It’s also interesting to note that this backdoor can be found in all variants/rebrands of the application, SMSNanny and SMSReplicator (non-secret). It reminds me of the old “Remote Administration Tools” like SubSeven which often contained “master passwords” for people to take over with.

I’d like to end this short post by quoting Axelle, as I feel she’s completely correct in this statement:

Seriously, it is very lucky SMS Replicator Secret is not remotely configurable, otherwise attackers could have randomly scanned the networks for infected phones and spy their incoming messages…

Wise words crypto girl, though sadly I fear that people making these applications for a quick buck will never want to take the time write secure programs.

Back to the basics

It’s been a fun and interesting ride on my Android reversing adventure. Nothing explicit to post now, but I just did want to touch on a few things I’ve seen over the past few days. I’ve been doing some research in the anti-piracy field and seen a few different interesting things. One interesting thing I came across is direct memory access, while it’s not possible to inject dalvik opcodes – we could in theory do this with root access. I know, not much help – huh? Still some pretty interesting things we might be able to do with the /proc/pid/mem address spaces if we did have root. An interesting application that uses this is GameCIH, interesting use-case and even more interesting UI for it! Either way I’ll hopefully post a few proof of concepts projects that I have been dabbling with off and on for a while.

Another thing I’ve come to realize as I delve more into Android protection schemes, is that your binaries are never truly protected. While I know it’s never safe to assume that your binaries are a safe asset, as they almost never are on any operating system – for some reason I was under the assumption that they would be more protected with user based permissions on Android. Though this just seems to not be true – as even “protected” applications have their /lib directory world-readable, and even loadable by any other application. This isn’t really a security break by any means, but something I found interesting as I look deeper into things.

On a side rant, I’ve become increasingly frustrated with the amount of people demanding support for open source code. It’s quiet annoying to see people ranting on and on about issues they have with code, when they honestly don’t take the time to debug any of their issues. I guess it boils down to the same issues you find day after day on a forum, people don’t want to search for an answer – they just want to be given the answer. It tends to get even more maddening when you know these people are just trying to turn a buck off the open source project and never even thank people for their help! Shuck — rant mode off for now.

A better note to end on though – I’ve gotten back into my Android Market (Vending) reversing roots. It’s been a little bit since I last looked at some of the dalvik code – but it appears Google has done some interesting things with it. The protobuf has evolved for sure, as well as the Market itself. There are suggestion feedback while searching, many more application shelfs for carriers and tons of extra fields I never really traversed. It’s an awesome thing to have seen evolve and exceptionally interesting to have worked on since day one. I’m sure I’ll be blogging more about it at time goes on. So stay tuned for it if your interested, as I’m sure I’ll be working on it all week. I’ve also just gotten my hands on a G2, so it’s the first time I’ve been using a non-rooted phone – another thing to distract me from doing work :) – hopefully I’ll be posting more on Market data though. It’s always been interesting stuff, I guess I’ll have to finally finish some of the projects of mine!

Detecting an emulator, and getting around detection

So recently I got an email asking about spoofing your Android ID, normally I just redirect people to my other articles, but I guess this one was different. The person specifically was looking to test applications on their emulator, and needed to avoid “emulator detection”. It didn’t seem like anything tricky – but I googled quick with not many results returned. The things that where returned where pretty… Well – overcomplicated. My first thought was that this should just be located in one of the many sqlite3 db’s – and it turns out it was. Simple little work around yet again, have to love those!

First off, lets see how most applications detect emulators. It’s done using a simple call to Secure.getString() using Secure.ANDROID_ID (previously this was done using System.getString() and System.ANDROID_ID, though these methods are now deprecated). The “detection” often relies on this returning null when it is read inside an emulator. With this said, below is a normal emulator detection snippet;

Very simple, doesn’t do anything to complicated, just checks for null being returned. So how can we get this to not return null in an emulator? Easy — just a simple sqlite3 insert command!

Open a shell to your emulator, and navigate to /data/data/, open up the db in sqlite3 and insert a value using ‘androidid’ as the key, like the following;

That’s all you need to do. Now all programs that use that method for detecting if it is an emulator will be returned the value you’ve entered as the Android_id.

getInstallerPackageName, take that Mr. Pirate!

I’ve been seeing posts lately in the wake of the LVL anti-piracy code being broken, with different methods on how to keep your Android package safe. Anti-piracy measures have always been fascinating to me, so I love diving into them and taking a look at what developers think are good and why. One of the latest crazes is using the PackageManager‘s “getInstallerPackageName” to verify whether or not the Market actually installed the apk file or not.

There are a few issues with this, though they are only minor issues depending on how you look at them;

    API call is a of the API Level 5, meaning it won’t reach all android users (Android 2.0 and up) – and “may not always work”
    It’s only a viable method if protecting for the Android Market
    It’s simply just something else for a pirate to patch, nothing too hard
    This prevents legitimate people from backing up the application, installing from without use of the Market, adb, etc.

It’s pretty self explanatory for the API level issue. If you want to target people below Android 2.0, then your can’t use this method to verify the installer source. It’s not going to be available, which may or may not be an issue depending on what other API’s you are targeting. On top of this though, it apparently doesn’t always work;

In a late edit, we removed a suggestion that you use a check that relies on GetInstallerPackageName when our of our senior engineers pointed out that this is undocumented, unsupported, and only happens to work by accident. –Tim (Securing Android LVL Applications – Android-Developers/Blogspot

Another issue that arrises from this method, is that it’s actually only set when being installed by the Android Market. If an application is not installed via the Market, attempting to retrieve this value will just return null. That’s ok right? Well, if you’d like to lock out customers who want to use this on multiple devices, or keep older versions of your application – then no it’s not. While this could be a small base of users, people may be purchasing your application and attempting to run it on a second Android device that doesn’t have access to the Market. Or possibly just using Astro File Manager to keep separate versions of your application – these would all be broken if you use this method, as once installing from anything but the Market happens, it will not return the correct value.

Ok, well if you don’t care about the rest of the cases so far and are willing to risk it, why bother? It may seem like your locking out a few legitimate users, but at this point you’ll probably lock out more legitimate users than you will pirates. Using any of the numerous tools out there, or even the ones bundling within the Android SDK can find you the function call to getInstallerPackageName, and quickly circumvent the check to see if what was returned was null or

So how can legitimate rooted users get around this annoyance? Well, I wouldn’t recommend it, but an easy way to get around this is simply editing your /data/system/packages.xml – inside this you will see the information for all the packages you have on your system. The actual important part you want to look at is the package header tag;

<package name=”” codePath=”/data/app/” flags=”0″ ts=”1283990162000″ version=”25″ userId=”10066″ installer=””>

The tag in bold is only apparent when it is installed via the Market. If you don’t have this in something that needs it… You could add it. If you want to change it to turn a different value, well here is where you can add it. Oh – and obviously this would require root.


After looking a little bit deeper into this, I remember the trusty old “pm” command – which actually works around almost all these issues. By doing the following simple command via ADB you can set the installer to anything;

pm install -i installername com.example.package

This will perform an install setting the “installer” to whatever you’ve chosen it to be. No reboot required, or root privileges needed – just access via ADB.

< 1 2 3 4 5 >