Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!






Your AIR for Android app is open source - like it or not!

  Posted by johnhattan, 11 May 2011 · 2,432 views

First off, I’m not posting this with the hopes of inviting malice. I’m posting this to inform you that anything you thought regarding code security in AIR for Android apps is probably illusory, and that you (and hopefully also Adobe) need to take some extra steps if you don’t want your assets stolen.

That being said, here’s how to take apart an AIR for Android app you’ve downloaded from the Android Market.
  • Get the free Astro file manager from the Android Market.
  • Run Astro.
  • From the app menu, choose “tools” and then “Application Manager/Backup”.
  • Choose any app you’ve installed on your Android device. You can choose any app you want, but AIR apps are particularly egregious in their lack of security.
  • The application will be copied from internal storage and will be copied to your backup folder (most likely on your SD card) as an APK file.
  • While still in Astro, navigate over to that backed up APK file and click on it. Choose “send to”, and send it to your desktop machine via email or Dropbox.
  • Now that the APK is on your desktop computer, rename the APK extension to ZIP and open it with your favorite ZIP-reading program.
  • In the “assets” folder within the ZIP, you should find a file with the extension SWF. Yes, this is the same SWF that was created with Flash/Flex. The AIR Android packager doesn’t do anything to the file at all. It just copies it into the right spot in the APK ZIP-file so the AIR runtime can run it.
  • Copy that SWF out of the ZIP file, and you’re done.
At this point, you can do whatever you want with it. You can download the Adobe AIR SDK and Android SDK, re-package the SWF into a new APK, and upload it to the Android Market under your own name. You can decompile the SWF with a tool like Sothink SWF Decompiler (which worked great on all the examples I tried), then change up the game enough to pretend it’s an entirely different game. You can put the SWF on your website. Or you can just browse through all the author’s source code and copy out his code/graphics/sound assets into your game!

Note that there are tools like secureSWF (which I reviewed here) that are very effective at munging ActionScript bytecode into something that can’t be meaningfully decompiled, but that would only prevent people from decompiling and/or reading and/or recompiling your source code into a new SWF. There’s still nothing preventing me from making a new APK out of your game's SWF.

also note that exactly ZERO of the AIR for Android apps I tried actually had obfuscated their bytecode with a third-party tool . A couple of you guys have atrocious naming conventions :)

Fact is, if you are going with Adobe and Android’s recommended sequence to make an AIR for Android APK file with the aim of putting your app on the market, you are essentially open-sourcing your app. Unless you go with some further security (and I don’t even know what further security you could implement beyond obfuscating bytecode), you are leaving your app wide open for IP theft.

And I’m not doing this with the aim of convincing every 13 year-old creep with a decompiler to start stealing apps and republishing ‘em under his own name. It’s more like discovering that every door-keypad at the Pentagon opened with the combination 1-2-3-4-5. Would publishing such information be inviting terrorism or would it be informing the Pentagon that their security is worthless and needs updating ASAP?

Also I’m posting this because I’m angry. And I’m angry because I brought this up during a Q&A at an Adobe conference when AIR was announced as “Apollo” in 2007. The Q&A went something like this:

Me: If your compiling step is just zipping up all of the web-app’s assets with an XML manifest file and some icons, what’s to prevent me from unzipping that file, making changes, and re-deploying it.

AIR guy: We’re planning some security stuff.

Turns out the “security stuff” was apparently their app signing process. And the ONLY thing that prevents me from doing is me making changes within the AIR file itself. I can’t open an AIR (or APK) file and make changes to the file itself, as the certificate file would no longer match file checksums for the AIR/APK file. I’m still free to open, decompile, read, write, update, steal, and rebuild the app under my own name.

They’ve had four years to fix this.

Finally, a note about the iPhone. While an iPhone IPA file is also a renamed ZIP and IPA files are also easy to retrieve, the contents of AIR for iOS files beyond icon PNG files and a manifest XML weren't in a readily decompile-able format. Looks like the Adobe AOT compiler really works.https://blogger.googleusercontent.com/tracker/5927544581291786949-3240684431859205391?l=thecodezone.blogspot.com

Source




I can think of at least a dozen ways that I could prevent someone from "stealing" my app, secure sharedobjects, encryption keys for SQLite databases, encrypted modules run from memory, runtime shared libraries, etc... not to mention dozens of ways to implement an activation process which prevents access to your application files until it is completed. Just because you don't know what you're doing doesn't mean that no one else does. Instead of spending all of your time talking trash why don't you learn how to program creatively.
As I mentioned, I took several AIR-authored APK's, decompiled them, and found no evidence of these techniques. And that includes top-shelf stuff. I'm not "talking trash". I'm informing people of something they might not know. Lighten up.
Thanks John for your post. I am developing an AIR for Android app and am trying to figure out the best way to protect the swf files. Ideally I would like them to be completely hidden. Protected swfs may stop hackers decompiling them (but probably not when decompilers are upgraded). But this does not prevent all the swfs and other assets being copied out and put in a new project and recompiled using eclipse. The hacker would not need to do any hacking to accomplish this - just rename .apk to .zip and copy out all the swfs and other assets, then recompile the apk using eclipse with a new certificate - as John as described. Justin - do you have any tips/advice of how to hide the swf(s) or prevent them from being accessed/copied. Or if you have any other ideas, please elaborate on them. The main hurdle I am facing is that the first swf that AIR loads, needs to be a swf and so it can be decompiled - so any encryption methods contained with it could be compromised. Any further input would be appreciated.

"Native" apps on Android are written using Java.  Java, is very much like AS or AIR based applications.  It's interpreted, and easily decompiled. Just like SWF, there are lots of techniques to protect the code, like obfuscation - but essentially the same problem that exists for "native" apps on android, exists on AIR.  Not to mention the HTML5 based apps.  Any language that is interpreted, has this problem.  On Android, apps are compiled to dex code, not byte code - which makes it a little harder, but there are tools out there to reverse engineer DEX code back to java code.

 

See article: http://geeknizer.com/decompile-reverse-engineer-android-apk/

 

However, as Justin points out, there are ways to strengthen the code (in AIR), so that it cannot be easily ripped off.  

 

I can understand your point about app venders are not taking advantage of this from your own testing.  That's more of a developer education problem I think.  It's good your calling this out, hopefully devs will take better procautions on securing their code.

Recent Entries

Recent Comments

PARTNERS