Even if you obfuscate your code, the resources can still be decoded from the application package and are thus subject to manipulation. It is often enough to just modify a few strings in the xml files to steal an app and rebrand it as yours.

Hmm, that seems to be easy enough to get around - just run a compiler that turns the xml into javacode that creates the same gui.

It will properly be faster to run as well.

There's always some way to do it, but in general, java itself is pretty easy to be reverse engineered (although DVM has a different bytecode format than the "real java").

Another problem for obfuscation is, the time spent on protecting the app, should have been used to improve the apps. I don't think iOS devs spent too much time on obfuscate their code...

I was amazed how easily Java bytecode can be 'decompiled' back to source. At work we once lost the source for some changes, but still had the binary. I decompiled it and with the exception of about 2 comments (and the change we were looking for), the source was identical to the last version in source control.

It's always made me wary of shipping anything that I'd consider 'secret sauce' (code that solves hard problems) in Java out of concern that our competitors could so easily see exactly how we do it. Similarly, I've been afraid of a competitor or even customer decompiling our stuff and finding either sloppy code or finding security issues.

Yes, I realize all of this is somewhat possible with C/C++ and other languages, and that there are obfuscators, but it is surprisingly easy with Java.

Java decompiling includes variable names (and comments)? That is terrifying. (Assuming you're sane and your variables aren't named a01, a02..a99, b01....)

I'm familiar with decompiling C, but in C, you're left guessing variable names. (Not that variable names 'secret-ify' the sauce at all, but it goes to time spent.) Bin-patching C programs is surprisingly 'easy' to learn these days if you're rather technically inclined.

I don't remember off the top of my head whether local variables within a function will have their names preserved (probably not) but all class variables and methods will have their names preserved, unless you use an obfuscater.

I haven't played around with Java decompilers, but I have sat down with a hex editor before and played with Java class files, and I could see all the strings!

I've done manipulations of binary executables myself (on Windows). For release level software, where debug info such as symbol names is totally no where to be found, all you can use is a disassembler and a hex editor. A slight mistake in changing the bits and bytes in the binary will just crash the software without telling you what the problem is.

I actually really admire those who can make sense of obfuscated native binary code without debug info.. but decompiling java code using "off-the-shelf" tools is totally different.. the difference is like playing mozart on piano v.s. ... on your ipod.....

No, I'm saying there were only about 2 comments in the whole class to begin with, so those would obviously be lost. I don't remember having any issue with any variable names, even locals, so it's possible that I had to patch those up if there were any.

Good point. Ideally, it could be done automatically by the build tools during the packaging process.

Absolutely, and that's what we as Android devs are hoping for. or if Google won't provide system level support, maybe someone can provide a solution, and even make a business out of it? maybe that's some YC11's material~ ;)

Regarding decompiling Flash-to-iPhone apps, CS5's iPhone app packaging feature produces binary executables[1], not embedded SWFs - so they should not be vulnerable to decompiling.

1: From Adobe's FAQ at http://bit.ly/cxpzFe

"Is the Flash Player runtime bundled along with the application?

No. iPhone applications built with Flash Platform tools are compiled into standard, native iPhone executable packages and there is no runtime interpreter that could be used to run Flash byte-code within the application."