Intrepidus Group

APKTool, make me a logcat sandwich

Posted: March 8, 2013 – 2:57 pm | Author: | Filed under: android, Mobile Device Management, Mobile Security, Reverse Engineering, Tools

I recently turned a few friends on to Zed Shaw’s “learn python the hard way” course and it reminded me how bad of a programmer I can be. In fact, I’m that guy how litters his code with print statements. So it’s probably no shock then that a lot of times when I’m trying to figure out what’s going on in an Android app we’re reversing, that I’ll want to drop in some print statements. I use to do this by adding a few lines of smali directly into a class file, but there were a few things I needed to deal with for that to work how I wanted it. For example, here is what the default “debug” log call looks like in smali.
invoke-static {v0, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I
If you were going to drop this line into the code somewhere, you would need to make sure both v0 and v1 are Strings. I would typically want “v1″ to be the string I wanted logged out, and “v0″ (in this example) to be the log “Tag” value so I knew where I was in the code when it was dumped to the log (I may have a dozen or so values getting logged out, so this helps to keep things straight when you see them in the logs). Setting up this Tag string and not stomping on things sometimes meant I needed to increase the local variable count and add some more lines for setting the string and then making sure I got the register/variables correct in that previous logging line. This worked alright if it wasn’t too late in the night or I had enough caffeine in me, but I typically would screw something up and would end up recompiling a bunch of times. I wanted an easier way and something that could deal with logging out things that weren’t already strings.

Thus I created this simple class file I can drop into the root of any application (yes, this is not as good as a real debugger using JDWP, but sometimes doing things quick and dirty gets the job done quicker for me). I wanted to stay with Android log utility syntax, but simplified a few things. I overloaded the logging object’s “d” method so that it could take just about any variable type I was dealing with. One handy example of this is a byte arrays (which is often what we find decryption keys stored in). The wrapper in IGLogger will convert the byte array into a hex string and dump that to the logs. All you need to add is one statement to the code. If “v0″ contained a byte array we wanted printed out, just drop this line of code.
invoke-static {v0}, Liglogger;->d([B)I
Since “iglogger.smali” is in the root of the recompiled APK, we can statically invoke it from any other class in the project. In this case, we need to tell the “d” method v0 is a byte array “[B” and sticking with the standard Android logging utility class, we’re returning an Integer (although I’ve thought about just making that a Void… I never check it). You may notice we’re not passing a log Tag variable with this statement. IGLogger supports that if you want, but we’ve added a trick to IGLogger that I find works pretty well. In IGLogger, we’ll create a new Throwable object, get the getStackTrace method to find out the last class and method we were in, and put that in our log Tag. If the APK is not obfuscated, this will even include a line number. This same trick allows for a very simple “hey, I got here and this is how” stack trace method to be dumped by placing this one line of code anywhere.
invoke-static {}, Liglogger;->d()I
You might have heard a lot of us here are fans of Virtuous Ten Studio for working with smali. I have a bunch of these IGLogger print statements in  Extras->Smali->CodeSnippets. Makes it really simple to just click and drop in a log statement.

But that wasn’t good enough for Niko here when we had a massively huge app that was obfuscated. He talked me into automating the process of logging out each class and method that was entered so we could watch the logs and know what code paths were being taken. I ended up rolling this into a Python script I had written to “fix strings” in decompiled Android apps. You are probably aware that proper Android apps will have their strings placed into XML files so that it’s easier to internationalize the application. While this might be nice for developers, it means when we’re reversing an application, we may end up with some strange hex value instead of a readable string. “” would loop through the decompiled code and add these strings back in as a comment tag when ever they showed up in the smali code. Your mileage may vary with how well this works, but in some apps, it helped us find things easier.

Adding on to that code base, I started to include some code to automatically add IGLogger statements around things I thought could be interesting. This includes a log statement after the “prologue” of any method. Also, any time we see two strings being compared, we’ll log both strings (this is always fun for watching a password being checked or when the app pulls up device info to see if it’s running on the right hardware). We plan to add a few more things for dumping Intent messages and URLs, but this is a start for now.

This of course will make the app run hella slow, fill up logcat, and in some cases break the application. I’ve tried to avoid that last one as best I can for now, but it is possible this script will massacre an APK so badly it will be unrunnable. If you run into that issue, you can turn off the lines that will add these automatic logging statements to the code (ie, JonestownThisAPK = False).

The last thing we added to the Python script was some searches to pull out info we may find interesting when assessing an APK file. We dump this into a file called “apk-ig-info.txt” and review it after decompiling the APK. Again, this is something we’re continuing to refine. You can find the code on the Intrepidus Group github repo:


Kony 2013 – A different kind of Android reversing

Posted: June 6, 2013 – 3:39 pm | Author: | Filed under: Uncategorized

We reverse engineer Android applications pretty much daily here at Intrepidus. We do it so much, in fact, that it almost becomes rote:

  1. Grab the APK
  2. Run it through apktool/dex2jar/apkanalyser/apkREthingDuJour
  3. Look at the files/smali/classes
  4. ???
  5. Profit!

It’s rare that we find something that breaks that process (I left out the MiTM of traffic, because I’m focusing strictly on the APK analysis for this post).

A recent engagement we did for a customer turned out to be one of those rare finds: an APK that was “weird”. While ethics preclude our talking about a customer’s application specifically, we were able to find other applications in the Google Play store that have the same behavior, and we can use them =)

For this post, we’re going to be looking at the Scottrade Mobile application (you can get the specific APK we used here). To begin with, we fire up the application on the device. A picture of the main activity is shown below:


Nothing unusual so far. We click on the Account icon at the top of the screen, and as expected a login activity is presented:




Fair enough. We click around a bit. Type some random strings into the account number, check the Remember Account No. checkbox, etc. All we’re looking to do right now is make sure that any client side storage options are being exercised – so that when we take a look at what data is persisted by the application, there will be something there.

Having walked through the app a bit, it’s time to check the file  system on the device. In this case, the application data is stored in /data/data/com.konylabs.Scottrade. We grab them using adb pull. Once we have the APK unpacked back into smali and java classes, and the local files on the device have been pulled out for examination, it’s time to move on to seeing how the application works.

The first stop we make is the AndroidManifest.xml file. This file is used by the APK to define the package characteristics – including all permissions used by the app, all the activities and service providers the application creates, etc. Basically this file contains a giant roadmap of the application. Here’s what the manifest for this application looks like:


Hrmm.. our first hint at oddness. There’s not much in this manifest – especially for an application that has as many components as this one does. We already know from walking through the application in run-time that there are many activities present, so how can there only be two defined in the manifest? Looking at the main activity (identified by the <action android:name=”android.intent.action.MAIN” /> intent-filter), we see that it maps back to the .Scottrade class. Since the package name is com.konylabs.Scottrade that means we need to look at the com.konylabs.Scottrade.Scottrade.smali file to examine what’s going on. Here’s what that file contains:



Again, more oddness. We’ve seen the main activity. We know it’s got a lot of stuff going on – stock trade graphs with information presumably obtained from the Internet, various images loaded, etc. In fact, the app looked a whole lot like the usual bunch of webviews strung together. So why aren’t we seeing any of that here?

The answer is in line 2:

.super Lcom/konylabs/android/KonyMain;

What this translates to in Java is a class inheritance. Inside the file would be something like the following:
public class Scottrade extends KonyMain {
    // code goes here


And if we look at the Scottrade.class file in JD-GUI, we see that’s exactly what happens (and in fact, not much else at all):




So, where does KonyMain live? It’s at That file is a whopping 5166 lines long! Using dex2jar on Windows 7, and JDK version 7, the KonyMain class file only has a single line of: // INTERNAL ERROR //

However, using dex2jar on Linux, with JDK version 6, we get a successful decompilation:



Again, this file is pretty huge, and not terribly helpful. At this point, it seems like we should look at what Kony Labs is. Turning to Google, we see that they are a mobile application company, and offer products that provide a framework for developers such that they can take code they write, and deploy it across multiple mobile platforms. So, what that means for us as reverse engineers is: we need to figure out how the Kony Labs framework is designed. Unfortunately, their application is not open source, nor is a  trial available. While looking for further information we ran across this site, explaining a bit about the Kony architecture. Specifically:

KonyOne, claims it does everything. Their Eclipse-based cross-platform IDE studio helps the creation of a single code base programmed in the Lua programming language (like JavaScript) from which Kony generates native code in 7 OSs OR HTML5 OR WAP/WML browser apps.

Hmm. That’s interesting. So, it would seem that Kony takes application code written by mobile developers, and throws it all into a Lua wrapper of some kind. Armed with that information, we started looking harder at the structure of the APK, and the files stored in the device file system.

First off, we looked at the device file system structure:



We see the usual things: cache for webviews, shared_prefs, databases. But files is odd. Looking in there, we see 3 files:


What is a .kds file? Running the file command on them says they’re Java Serialization data:
$ file *
dsAcceptDecline.kds: Java serialization data, version 5
dsAppVersion.kds: Java serialization data, version 5
dsShowStreaming.kds: Java serialization data, version 5

Examining the files in a hex editor doesn’t help much, but we can tell it’s got Java Hashtables, and binary objects in it:



Hrmm… OK. Ignore that for the moment, let’s see what else there is to find. Going back to the unpacked APK directory we obtained using APKTool, let’s check out the usual spots:

  • Anything good in /res/values/strings.xml?
    Nope: strings_xml
  • How about /assets?
    Aha! Something interesting here:


Knowing that Kony wraps everything up in a Lua wrapper, that konyappluabytecode.o.mp3 file looks somewhat suspect. Let’s take a look at the file header and see what it has to say:


As guessed: this is not your usual MP3 file at all! It’s a LUA bytecode dump! Here’s where things start getting really interesting.

It turns out, that the entire Android “application” is actually stored inside the konyappluabytecode.o.mp3 file. Running strings on that file shows evidence of this:


Unfortunately, the Lua bytecode isn’t readable natively, because it’s bytecode. Some  looking around revealed a few tools that can be used to disassemble Lua code, but the one that worked best for us was ChunkSpy. This handy tool is actually a Lua script, that can be used to convert binary Lua bytecode back into a verbose listing, similar to what you would expect to see in a standard binary debugger. Running the konyappluabytecode.o.mp3 file through ChunkSpy was simple enough, once we installed lua 5.1 onto a Linux system. The usage is shown below:



For our bytecode, all we had to do was run the following command:

ChunkSpy.lua -o out.txt konyappluabytecode.o.mp3

An example of what the output looks like is shown here:



Where things went from there is the subject of another post, coming soon…



Armor for Your Android Apps – ShmooCon follow-up

Posted: February 27, 2013 – 1:26 pm | Author: | Filed under: android, Conferences, Fun and Games, Mobile Security, Tools

Hopefully, everyone’s already decompressed from all the Shmoocon partying by now. I wanted to follow up on the IG Learner app that I presented during my “Armor for your Android Apps” talk and give out a couple of tips on how to approach cracking the challenges (which aren’t all that hard, really).
Before I dive into the meat of the lessons, I just wanted to point out that if you didn’t attend the conference but still want the app, you can get it from the Play Store:


So, you’ve got everything installed and running. At this point you have two options – take the easiest way and hit the walkthrough or try to dig through the lessons yourself. I intended for the walkthrough to serve as a helper thing, but if you’d like to just use it to run through the whole thing, sure, that’s an option, too. The link to the walkthrough is provided at the end of this post.

In if you want to do it yourself but are not sure where to start, here’s a few general tips:

1. You will end up using Android SDK / Android monitor (monitor.bat) very heavily. I am guessing that by now you have that installed on your system anyway.

2. Use dex2jar ( to convert APK’s Dalvik executables (*.dex) into their Java representation – since the code is not obfuscated, this will really help you understand the logic of the lessons.

3. Apktool ( – this command-line utility lets you decompile APKs and recompile them back. You’ll definitely need this on a few occasions.

4. Jarsigner – comes with Java SDK, is necessary to install an app on an Android device. Read here about signing of APKs:

5. Virtuous Ten Studio ( – Smali IDE, complete with syntax highlighting / automatic signing / APK upload. Awesomeness redefined. If you want to bypass 3) and 4) and not have to deal with it, go the VTS way. That said, I’d still recommend familiarizing yourself with the command line versions of the tools – just so that you understand better what’s happening behing the scenes.

6. Some knowledge of Java is definitely helpful for quick completion of challenges.

7. “adb shell pm list packages” gets you the list of packages installed on the phone. IG Learner is one of them.

Now, let’s go to some specific tips per lesson:

1. Lesson 1. This one is pretty self-explanatory. If you start the Android monitor and look at the log output,  you’ll see the answer to the challenge. Easy as that.

2. Lesson 2. Convert the APK into Java and try to figure out the filename that’s being created. Another hint: default directory for Android app file storage is /data/data/<packagename>/files.

3. You can figure out what the URI scheme is just by looking at the lesson screen and requesting a URI. Now try to look through decompiled code (Either Smali or the Java representation) to figure out what the lesson is expecting. Also, pay attention to extra activities in the app.

4. You should use a local proxy to intercept application traffic (Burp Suite maybe?) Keep in mind that you can’t man in the middle SSL traffic unless the SSL certificate presented by the remote server is verified. And for that (at least, for Lesson 4) you need to update your trusted CA store with the signing certificate of your local proxy. Once you export that certificate (there are multiple ways to do it, using Internet Exporer’s certificate export wizard is one of them), you should be able to import into into the trusted CA store by placing it in the root of /sdcard and importing it through the Android’s Trusted Credentials menu.

5. This lesson is a bit trickier. For one of the ways to solve this, I suggest looking through the Smali code and finding the pin for SSL certificate that you can get by running Moxie Marlinspike’s script on our certificate. Then you can replace this with your own intercepting proxy certificate’s pin, recompile the app, and push it back to the phone. You’re good to go.

6. Hard-coded keys are awful. Seriously. When you’re playing around with symmetric encryption as you’re trying to find the correct value of the encrypted string, make sure that you convert that to Base64 for readable output. The logging facilities are there to help you.
The encryption can be done in less than 10 lines of Java code. If you’re struggling with that, check out our GitHub repository for a helper Java class.

7. Content providers are advertised in the Manifest. Mercury ( is a great framework that lets you easily query those providers. This should be enough to successfully complete the challenge.

8. I’d recommend starting with decompilation of the app and looking at the Lesson8Activity. This may give you an idea of what the Intent handler is expecting. From there you can either download the Lesson8Aux app from the Play Store (, decompile it, modify it to throw the correct Intent to the application, or just use the “am” command to do just the same. Whichever is easier for you is fine, but I recommend going the auxiliary app way just to gain some more practice exercises decompiling and recompiling Smali code.

Oh, and yeah, the walkthrough (Huge thanks to our intern Nitin for putting it together!). Here it is:



Unhosing APKs

Posted: October 5, 2012 – 5:35 pm | Author: | Filed under: Uncategorized

Recently, there has been some discussion in the press about a tool named “HoseDex2Jar”, which claims to prevent wily hackers from being able to decompile Android APK files back into Java class files. Such a tool would be very useful; it is claimed. It is purported to prevent said hackers enacting their nefarious actions and protect assets within an Android applications developers are trying very hard to protect. In fact, the president of the company offering the service is quoted as saying, “We realized if there was a way to stop Dex2Jar, we would stop all Android decompilation.”.

While we think it’s great to see folks moving in a direction to raise the security bar for mobile applications, claims such as this are a bit misleading. To understand why, it’s important to realize that there are a couple of very different things meant by “decompiling” when it comes to the Android platform.

The HoseDex2Jar tool claims to prevent people from running the tool “dex2jar”, which is a utility that converts the Android APK “classes.dex” file back into Java classes. The java classes can then be turned back into readable Java code using any one of various Java decompilers available (there are both open source and commercial versions of such tools).

What the HoseDex2Jar tool does not claim to do, is prevent the conversion of the classes.dex file back into the Dalvik disassembly, called smali. While it can be handy to convert APK files back into Java classes – because Java can be easier to read than smali - we’ve found that using the smali code tends to be provide better results. That is because, the smali code is more accurate, and because it is essentially Dalvik disassembly,  it is almost always easier to manipulate and alter when attempting to develop a meaningful attack. When converting APKs back into Java, the decompilers need to make a lot of guesses about the code, which results in a distortion from the original application. It’s useful as a quick overview, but it’s generally not able to be altered, and then successfully recompiled back into a new APK. (We wrote about this a bit a couple years ago.)

Because HoseDex2Jar only prevents the flawed “to Java” version of Android decompilation, completely ignoring the much more accurate decompliation into smali code,  the claim that HoseDex2Jar prevents all Android decompilation is not only completely false, it’s almost useless as a security measure.

As an example of how futile this is, we used the HoseDex2Jar tool to “protect” a small app we wrote. We registered with the web service, and obtained our “hosed” APK back. Sure enough, running dex2jar on the hosed APK failed, with a Java null pointer error:

dex2jar info.dc585.SMSniffer-1-HOSED-MUST-RESIGN.apk -&gt; info.dc585.SMSniffer-1-HOSED-MUST-RESIGN-dex2jar.jar

at org.objectweb.asm.Type.getType(Unknown Source)
at com.googlecode.dex2jar.v3.V3ClassAdapter.visitField(
at com.googlecode.dex2jar.reader.DexFileReader.acceptField(
at com.googlecode.dex2jar.reader.DexFileReader.acceptClass(
at com.googlecode.dex2jar.reader.DexFileReader.accept(
at com.googlecode.dex2jar.v3.Dex2jar.doTranslate(

However, baksmali had no problems, nor did apktool.

apktool d -d info.dc585.SMSniffer-1-HOSED-MUST-RESIGN.apk
I: Baksmaling...
testI: Loading resource table...
I: Loaded.
I: Loading resource table from file: C:\Users\user1\apktool\framework\1.apk
I: Loaded.
I: Decoding file-resources...
I: Decoding values*/* XMLs...
I: Done.
I: Copying assets and libs...

More interestingly, simply using apktool to repackage the directory, without making a single change to smali files, is also successful:

apktool b -d info.dc585.SMSniffer-1-HOSED-MUST-RESIGN info.dc585.SMSniffer-1-DEHOSED.apk
I: Checking whether sources has changed...
I: Smaling...
I: Checking whether resources has changed...
I: Building resources...
I: Building apk file...

And guess what? After running the two very simple commands above, we can now simply use Dex2Jar again, despite the fact that this APK was initially hosed:

dex2jar.bat info.dc585.SMSniffer-1-DEHOSED.apk
7 [main] INFO - dex2jar info.dc585.SMSniffer-1-DEHOSED.apk -&gt; info.dc585.SMSniffer-1-DEHOSED.apk.dex2jar.jar


Edit: So, it turns out that unhosing is even easier than we initially thought: if you use versions of dex2jar <, the hosed APK is able to be decompiled back to Java classes as though no changes occurred at all. It appears that the company offering this service only tested their success on the current version, and not on prior incarnations.

Android’s BuildConfig.DEBUG

Posted: July 15, 2012 – 9:55 pm | Author: | Filed under: android, Mobile Security, Reverse Engineering, software security

Verbose logging in Android applications is both a problem we frequently see in production builds, as well as something we’ll try to enable if we’re pentesting an app. In revision 17 of Android’s SDK Tools and ADT, the release notes mentioned a feature which could help developers with this issue:

Added a feature that allows you to run some code only in debug mode. Builds now generate a class called BuildConfig containing a DEBUG constant that is automatically set according to your build type. You can check the (BuildConfig.DEBUG) constant in your code to run debug-only functions such as outputting debug logs.

There appeared to be a few bugs in this working as expected in the original releases (Issue 297940), but that appears to have been worked out now. Running a few tests with revision 20, here’s an example of how it could be used and what it looks like in a built APK.

In our java code for our sample application, we included the following line:

 Log.e("HelloJB", "I am in the Debug");
 Log.e("HelloJB", "I am NOT Debug");
Log.d("HelloJB", "Debug value is: " + BuildConfig.DEBUG);

We then cleaned, built, then exported our application as a signed package from Eclipse. As expected, logcat showed “I am NOT Debug” and “Debug value is: false”. However, decompiling the application using Dex2Jar showed that these values had been set at build time and not simply at execution. With the new update, the Dex2Jar output for those several lines was now just two:

Log.e("HelloJB", "I am NOT Debug");
Log.d("HelloJB", "Debug value is: false");

This looks like a pretty clean way to strip out any code you don’t want making it into your release builds (an issue we’ve seen many times in assessments).

Now for pentesters of Android applications, we often look to enable verbose application logging. I will typically look for a debug flag in the application and try setting it to TRUE at run-time or by recompiling the application. If a developer uses this method to remove debug logging though, this means switching setting the DEBUG boolean to true in the BuildConfig class on a released application will probably not make a difference. Instead, look for an empty logging class and add back in calls to Android’s log methods. There’s a few ways to skin that cat, but often some well placed smali code will do the trick. For example, if you see an empty d method taking two strings, try dropping in the following line to see the debug messages again.

invoke-static {p0, p1}, Landroid/util/Log;-&gt;d(Ljava/lang/String;Ljava/lang/String;)I

Google Wallet coming for iOS?

Posted: March 15, 2012 – 11:42 am | Author: , and | Filed under: android, iOS, Mobile Security, NFC, RFID

The list of two OS types in WalletShared: ANDROID and IOS (click to enlarge)

Let’s start by saying this is no smoking gun, but a pretty interesting case of information leakage through an application. For our regular blog readers, you’ll know we’ve been looking into NFC based applications over the past year. The jewel of all NFC apps is easily Google Wallet and thus we’ve spent a large amount of time trying to understand it. When you decompile an Android application, which isn’t obfuscated, you’re able to see the same class names, method names, variable names, and other identifiers as in the developer’s source code. In this case, Google Wallet includes a package called “wallet.proto” which contains parsers for any “Protocol Buffer” formatted data the application uses. While the name “Protocol Buffers” sounds generic, it’s actually Google’s well-documented mechanism for serializing data (think of it as their version of XML or PLists). If you followed the Google Wallet PIN hashing issue, you’ll remember that the PIN hash is stored in a protocol buffer.

The “WalletShared” protocol buffers package in the current version of Google Wallet contains hints of iOS within the parsers definitions. This includes defining the “DeviceContext -> HardwareType” field with only two values: “ANDROID” and “IOS”. iOS strings are also found in two additional protocol buffers called “IosDevice” and “IosWallet”. The classes only leak a little detail about the information being collected which include items named “appId”, “appVersion”, “walletUuid”, and a few “model” and “version” items.

Function names with "iOS" in the string

Function names with

Now you might ask why anything about an iOS application, written in Objective C, would get compiled into an Android application, written in Java. This could happen because of how a Protocol Buffer structured data definition file is created. A developer typically creates a “.proto” file, which is a programming language independent file which defines the data structure. This “.proto” file is then compiled using the “protoc” application and creates the appropriate files for the language you are programming in. Thus, it’s simple to use the same “.proto” file to create a Java object or an Objective C object if they are both going to use the same data structure. While Objective C is not in the official protocol buffers package, there is an add-on for that language available. Thus it is quite likely if there was a “shared” data structure which both clients and the server would need to parse, the same “.proto” file would be used regardless of the application’s programming language.

Of course, if Google is developing Google Wallet for iOS, it raises numerous questions. Since iOS devices do not currently include an NFC radio or secure element, is Google planning to release a case, or “sleeve,” with these components? Or do they know something about the next iPhone we don’t? And if the next iPhone does have NFC and a Secure Element, would Apple allow Google access to those components? In any case, if Google is working on developing their wallet for iOS, this could be a sign of strong commitment by Google to contactless payment technology. And that’s a win for everyone regardless of which device is in your pocket right now.

Decompiling Android Apps: undx, dex2jar, and smali

Posted: October 1, 2010 – 11:57 am | Author: | Filed under: android, Mobile Security, Tools

If you have ever needed to know what a Java application is really doing, you have probably played around with a Java decompiler at some point.  JAD will always have a special place in my heart for that, but I find myself giving JD-GUI the late night phone call now when I just need a quick peek into a JAR file. Maybe she’s not perfect, but most nights she gives me what I need.

Unfortunately in the mobile world, tools to decompile our “Java” applications aren’t quite as mature yet. If we’re looking at a Blackberry COD file, there’s coddec and some patches that can help us peek at the code. A while back we were looking for something that could do the same for Android applications and we came across Marc Schönefeld’s “undx” tool. You’re probably saying right now, “wait, Android applications aren’t Java, they’re Dalvik.” That’s true, but why can’t they be decompiled as well since it’s still bytecode and not machine code? Marc decided to take on that challenge. Feed undx an Android APK file and it will try to convert it to a JAR file (which you can then feed to JD-GUI or JAD).

While undx does an ok job on most APK files, we had a strange case on our hands a while back. It was using a few Dalvik opcodes which undx wasn’t expecting. Marc was awesome enough to have undx open sourced, so we were able to add those codes in and make a few minor tweaks that  helped us out. We’ve put our changes up at GitHub and hope others might find this build useful as well.

As Marc points out, undx is a first step at converting Dalvik to Java. It’s far from perfect or complete. Looking at the decompiled code will show you a number of functions which, well, don’t really function. Variables may have the wrong type, case statements may just fall through, and loops sometimes never break out. We’ve found that Dex2Jar does a much better job converting Dalvik to Java. We’ve placed few screenshot comparisons in our previous post. In some cases, Dex2Jar does a very impressive job. However, against larger or more complex applications, it can fail.

More and more, we’ve been finding that smali/baksmali gives us what we need: Dalvik in a readable format that we can alter, recompile, then test on a device. Its true that smali/baksmali has a different goal than undx and dex2jar (smali/baksmali is an assembler/disassembler), but it gives us what we need to do most of the time in a quick and easy way (especially when packaged with APKTool). We’ve written a few scripts that can work with the smali output and help us zero in on the code we’re interested in for an assessment, and then its ability to support changes to the application and quickly recompile is priceless. This is likely a tool we’ll be working with considerably going forward with Android.

-benn, quine, and mxs

Lock down your Android APK permissions

Posted: May 27, 2010 – 10:31 pm | Author: | Filed under: Mobile Security, Uncategorized

We’re not planning on becoming a “how to” blog anytime soon, but thought this could be interesting to a number of you with Android phones and a love of the 3rd party apps (Hi Pandora… you look mighty fine today). Android users are probably used to seeing a list of permissions an application desires just before you hit that big install button in the Android Market. Unfortunately there’s not much of a way to figure out why an application wants particular permissions, nor can you choose to grant an application some permissions and not other ones. (Like you can do on a RIM device.)  It’s just “here’s what the app wants”: install or don’t install. If you want a little more control on the permissions an application is granted, an awesome little tool called “apktool” can help you out.

Let us take the Bubble Burst Lite game as an example of a free app that I may want to try out, but don’t want to give too much access to my phone. In particular, I don’t want it reading my contacts or sending SMS messages to my friends about how badly I’ll crush them with my bubble popping skills. To lock this down, you will want to grab the com.androgames.BubbleBurst.apk file and install apktool (I’ll assume you already have adb installed by now).  Next, run the following command to extract the APK and “decode” the application.

apktool decode com.androgames.BubbleBurst.apk BubbleBurstLite

You will notice in the new directory that was just created there is an AndroidManifest.xml file which you can read in any text editor (while there are other tools that can extract this info from an apk, I’m a big fan of this tool and the format it uses). Next, you will see the “uses-permission” tags typically at the end of the file. In our case, the app is requesting four permissions: INTERNET, ACCESS_NETWORK_STATE, RECEIVE_SMS, and READ_CONTACTS.

XML Screenshot

Next, remove the tags for the permissions you don’t want the application to have. In my case, I’m going to remove the permissions for RECEIVE_SMS and READ_CONTACTS. You can also pull out things like the “SMSReceiver” tag a little higher up in the file. Save your changes, then head back to the command line to have apktool rebuild the application.
apktool build BubbleBurstLite

This step will create an “out.apk” file in the dist subfolder. But before you can install it on your phone, you must first sign the apk. In this example, I’ll just use my own self-signed key that I’ve previously created.

jarsigner -verbose -keystore my-release-key.keystore out.apk igkey

(Raj, a fellow Intrepidus Group colleague, made a good point to me at this step. If you sign all your apps with the same key, and developers knew that and coded for it, they could have permission to communicate with each other and share data… and possibly, one day rise up against you. Help do your part to keep Cyberdyne Systems at bay and sign each app with a unique key.)

Now back to our changes, plug in your device and finish things off with the “adp install out.apk” command. You will now notice when you view the application’s permission in the Settings->Applications->Manage Applications menu, the unwanted permissions are gone. Play away, secure in the knowledge that any bubble blasting smack is going to come from you and not from the application covertly sending SMS messages in the background.


This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24799 items have been purified.