Posts Tagged with reverse engineering
Awesome crash dialog from IDA :)

To bad it didn’t give me an option to debug it with IDA or something, huh?

Just let the thing crash...

Just let the thing crash...

Oh well, I love you IDA – thanks for the nice message right before you bring my machine to a grinding halt 🙂

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.

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.

Unpacking “netz .Net packer”

It’s actually pretty trivial to do this, though it seemed like something that could be mildly interesting to post on. While it’s written in C# .Net itself, it means we can pretty much see exactly whats going on – so it’s lends itself to be a pretty easy example for people who have never actually done any unpacking before. It also lets to understand the concept of unpacking from a programmers prospective of actually packing it.

A little backstory to this is, someone sent me a “hack” for diablo2 and said it wasn’t working for them. Why they sent me this? I have no idea, but I figured I’d just take a look at it and see what was going on. Turns out it was a password stealer for d2 written in .Net – pretty cool looking stuff. The funny part about it all was that since this was “packed” with netz the person who sent me it couldn’t use reflector on it (and succeed) – thus why they sent it to me I guess. Anyway, let’s get down to the actual meat of the post.

Identification of netz is pretty simple – if you open up the application in Reflector, you’ll see the namespace nets. Also it will almost always be accompanied by a zip.dll, which is used for decompressing the resource. Essentially the main function we want to look at is StartApp:

From here we can see that a resource of bytes is going to be loaded, and GetAssembly is called with it as an argument. Go dump the resource listed here into some directory, I named mine virgin.dump. GetAssembly is a pretty simple function that I’m not going to dive into, it essentially calls UnZip(byte[] data). This code is a little more interesting and is doing the most work we’re interested in, here is small snippet;

Ah, this looks familiar! In fact – thanks to Reflector it’s pretty much almost exactly Java code. All we need to do is inflate the resource and dump it to a file – there isn’t any encryption or anything special about it at all. Basically by looking at the code above, I through together a small little resource inflater:

Is this anything special? No, but it worked for me and my quick little need for it. Could you use a Generic .Net unpacker? Of course, I just did this since I wasn’t running Windows and didn’t want to fire up a VM instance just to debug and dump a little .Net application. 🙂

Adjacking… Where did my ad revenue go?
Make money, money...

Make money, money...

It’s been a while since I’ve posted any article, sadly between work, contracts after work, spam, having a life and volleyball I don’t have much time to spend on my blog. Research is still going strong – but very little has trickled out from me over the past few months.

Something I’d like to finally post has come to my attention. Approximately a year ago when I first started looking into the mobile ad networks, I thought of something sinister. While I never intend to do anything evil, since I’m always looking for ways to protect myself, my first thoughts always seem to be, “how do I abuse this?” It all started when people started trying to think of ways to monetize their application. Do we charge up front, or do we try to make a few bucks off a huge user-base using ads?

My first question is, how are the ads secured? Much like other applications that are tracked by application, most use a “application id” or “publisher id”. This is a super-secret code that is used for identifying traffic from you, right? Alright, well unlike a website advertisement, which has a referrer – mobile ads have no actual way to differentiate traffic other than this “unique” id.

So what? Whats the issue with that? Well, there is a big issue with this. There is a coined term, “adjacking”, that essentially means “falsified” clicks. Originally this term meant you hijacked the javascript of google adsense, and made a click anywhere on your website appear to be a click on your adsense ad. Though, I’m “word-jacking” this term, because I feel my definition is a little more appropriate. Essentially, with the ability to easily decompile/modify an apk file – someone can quiet easily steal your ad traffic, this hi-jacking your ads… Adjacking.

Is this something new? No – but beware of it. I’ve had this article lying around for a bit, more uninterested in publishing for the idea that people would actually attempt to do this if I brought it up. Upon first writing this, I quickly made a program that attempted to make a database of signatures of programs. This program downloaded legit (free) applications and grabbed the signature from the META-INF folder of the apk. Then it attempted to find versions available for download on the internet…. For the most part, the version where always the same – with a rare instance of someone resigning it with little modification to the file, often to help localize it. Though now, I’ve seen and heard of an increase of people downloading their application, replacing the ID in the apk, and replacing it with their own.

Keep your code secure!

Protection from adjacking?

What to do about this? Well, hopefully the ad networks figure something out, though I’m not sure they honestly care much. I’ve sent emails to a few of the big providers with no responses and a few “we’ll look into it” replies. I don’t see a big downside for them – maybe if more people complain they’ll get the hint. I’m sure right now they’ll just get the traffic, for traffic’s sake. Most applications that have been modified probably don’t drive in much or take away much from other people. Though if they do, they could “act” upon these and actually shut people down… Will the correct developer ever see this money? Probably not… Though if your try hard enough you might see something.

The sad part is, most of the people modifying the applications are now no better than a scripting kiddie. There are enough tools available now to make this an easy job. Maybe if people start looking into this, these people will be rooted out – since they must fill in “legit” information to open an account.

Anyways, I’ve been looking at some protection schemes for this, hopefully I’ll have time to post some soon. I’ll post a little tutorial on obfuscating (manually) your adsense/admob/blah code to protect yourself 🙂

Downloading market applications without the vending app
Mmmmm... Market Data...

Mmmmm... Market Data...

It turns out downloading a free application is actually pretty easy to reproduce. The things required by the google android servers are just four variables. The server needs to know your userId, authToken, deviceId and the applications assetId.
The userId is a unique number that is associated only with your gmail account, the one that is currently linked to the phone. I’m working on getting a generic way to grab this number, though I believe the request is buried in an ssl request to the google servers. So for now, you can obtain your own userId by doing a tcpdump of your market traffic, just do a download of an application and look for a “GET” request in wireshark. There does not appear to be a “hard” maximum character on this, I’ve seen userIds as low as 8 in length and as high as 13. A bad userId will return a 403 forbidden response.
The authToken is sent in cookie form to the server, to authenticate that the user is using a valid and non-expired token and well, is who they say they are! This is linked to the userId and must match the account that the userId is taken from. Expired tokens will return a 403 forbidden response.
The deviceId is simply your Android_ID, and is linked in anyway to the authtoken or user-id, so feel free to spoof this.
The assetId is a number (negative or positive) that identifies the current stream of the application you wish to download. More on this later when I cover how to get live market data. Note that this number is not always the same – it (appears) to change when something from the application is changed. Originally I referred to this in my research as a “cacheAppID” for just that purpose.

Hopefully someone will find this stuff useful 😉 Better than me just sitting on it forever!

PDFViewer (working) on JF 1.5 and other builds

So a few days ago I got an email concerning the HTC PDF viewer which apparently comes bundled with the HTC Sapphire. Saddly, there has not yet been a release of it for the HTC Dream. The original thread on xda-developers can be found here which essentially was what the person was directing me too. The problem with this apk seemed to be that it was “locked” to HTC only devices… But – the HTC Dream is an HTC device, right? Not according to this program…

What? HTC Dream IS HTC?!

What? HTC Dream IS HTC?!

Anyway – long story short, success! I’ve successfully patched the file so that it should be able to be loaded on any HTC Android device. Have a blast reading your pdfs now!



Required files for this to work;
FilePicker.apk must be pushed using adb (or shell) to /system/lib
FilePicker.apk must be pushed using adb (or shell) to /system/app

Note: To push the files to /system, you will need to remount it as rw with the following command:
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system

Finally — download and install (either through adb or your favorite package installer) the patched apk! You can download that here, PDFViewer.apk. This was tested on JF 1.5 and 1.45 and seems to work perfect. Please post your programs if any should arise.

Enjoy! 🙂

< 1