Archive for the android Category
InsomniDroid – great presentation on Android Reversing Tools

Recently, Axelle from Fortinet aka Crypto Girl, presented a well done paper at InsomniHack 2012 – which she just posted on her twitter account. It does a very good job at outlining the basics of how to get into Android reversing and the Android reverse engineer tools. Since she works in the AV industry, it’s based on that view – a defensive analyst looking at malware. She does a great job describing the contents of an APK, how to read specific files (AndroidManifest.xml, etc) – giving multiple ways too. It’s nice to see how different people tackle these types of issues.

It’s also a nice thing to see someone outline all the different applicable tools. I haven’t seen anyone outside of a few Google people mention dexdump in a long time – definitely an underrated tool! It was interesting to see the list of tools she listed for decompiling the apk, specifically ded. I mention ded specifically since I’ve never actually seen anyone use it or mention it outside of the academic work done around it. Dex2jar was obviously mentioned, it’s quiet possibly the most (over)used tool out there. Personally I’m not that big of a fan of the project, though it definitely has some great use cases and people seem to love it.

Axelle did a great job providing a tutorial with a clean step by step of what to look for when tackling malware. Great steps provided about which tool to use, how to identify interesting points and then a nice little “ops! the tool broke, lets switch to the next one!” which can often happen due to the early stages of development for most of these tools. She also provides a slide on how synthetic access is created when inner classes access private members of their enclosing classes. It’s an interesting concept that seems to be lost on many beginner reversers in the Android world.

There are even a few slides on anti-emulator code, which has always been an interesting thing to me. She mentions how the Honeynet challenge implemented a few tricks and how one could either (1) modify the application or (2) modify the emulator. I’ve seen a few other people mention “hiding the emulator”, which has sent me into an interesting little tangent of research. Hopefully I’ll have time to add that into an expect Blackhat/Defcon presentation I’m working on. Personally I’m not a fan of the simplistic approach of just changing the application or the emulator imei – there have to be a ton of easier ways for an attacker to find the emulator and the defender to hide it.

Another awesome aspect of this presentation is how Axelle really did try to provide information about every tool. I’ve seen many people mention the use of Androguard, but not what features they use. I’ve personally messed around with it a bit, but haven’t found the urge to use it more often in my day to day work. I keep coming back to thinking, awesome features and implementation, though it’s just so much information I haven’t found it useful. One of Axelle’s slides I think sums it up pretty well;

Uhmm -- maybe?

Enough about the presentation – you should read it yourself. The PDF is available from Fortinets’s site (local mirror)

As a last side note — it’s extremely refreshing to see an Android presentation that does not include this “presentation filler” known as the “Android Architecture” picture ๐Ÿ™‚

Edit: I forgot to link the crackme challenge which Axelle also provided at InsomniHack – which is also called InsomniDroid. It’s published over at if anyway wants to take the challenge. It was a fun quick little challenge, available here.

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.

< 1 2 3 4 5 >