

Phantom Android Apps: they don't copy your ideas, they steal your code - fredliu
http://www.anddoes.com/?p=94

======
wmf
The good thing about app stores is that if someone rips off your app you just
send a DMCA takedown notice to the app store and the app is gone.

~~~
fredliu
We are doing that, but another issues is you may not even be aware of the
existence of these "phantom apps", if the cloner can pay a little extra
efforts.

------
ww520
This really sucks.

The new Android License Server should help a bit. You embed your public key
inside the app and it checks against your private key on the License Server in
runtime. If someone merely changes the resources to claim an app as his own,
the users running the app would still check against your private key and
failed as non-paying users. Of course if the code containing the public key is
reverse-engineered and replaced with a new public key, you are still screwed.
Obfuscation would help in that case.

~~~
fredliu
Yes, this is possible, and was among one of our "solution list" (not
necessarily checking against google's server, but could be our own server),
but it's not much harder (if harder at all) to take out the authentication
code than just change a string name in the app...

~~~
ww520
One way to raise the bar is to download critical pieces of code from a trusted
code server in runtime. The client code authenticates first with the License
Server using its public key and gets back an authorization token, which
expires with time. It submits the token to download the code from the code
server, which checks the token against the License Server.

To raise the bar even higher, make the downloadable code expirable or
embedding the public key to re-authenticate once downloaded.

Of course a persistent cracker can still run a sniffer to capture the runtime
code, reverse engineering it, remove all the checks and stitch the code back
together. It just makes it harder.

------
stevenwei
Wow, that seems like it could be a huge problem if it catches on.

Is there no way to obfuscate code compiled for the Android platform before
shipping your app?

Also, I wonder if the Flash to iPhone apps will have the same issue -
decompiling Flash swfs is surprisingly effective.

~~~
fredliu
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...

~~~
ja27
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.

~~~
fragmede
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.

~~~
wtracy
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!

------
extension
Google should be able to detect this by looking for very similar byte code.
They could whitelist shared libraries, or rule them out with some other
heuristic. It wouldn't need to be perfect, just good enough to make the human
part of enforcement manageable.

~~~
stevenwei
Is Google remotely interested in policing the Android Market for cloned apps
though?

~~~
fredliu
Maybe they should. Despite its success in market share, Android is still a
"baby" in many ways, and still too young to "live on his own".

------
mkramlich
For all the downsides to iOS development, this is one area where an iOS
developer is better off than with Android. Harder to have your code pirated or
forked. (Not impossible, just harder.)

~~~
fredliu
Agreed, we still love Android, and it has higher market share now, but we are
seriously considering iOS now (although no widgets there...yet)

------
akshayubhat
On a side note, had this been a case with an MacOSX application or Windows
application, would you have petitioned Apple or MSFT?

~~~
flatulent1
Altering desktop apps seems like it wouldn't have as much impact since those
aren't being marketed through integrated app stores. It seems attempts at
selling counterfeit copies online is the biggest problem for those. They get
removed from Ebay generally, but have turned up on Craigslist occasionally.

Still, there are quite a few programs out there that use open-source in
violation of the GPL. In particular, there are quite a few video-conversion or
DVD apps using ffmpeg improperly on both Windows and OS X. (Use on Linux is
proper, and users get needed patches) Aside from denying users the ability to
make more changes with the relevant source, the apps are also generally poorly
maintained. Even some with frequent GUI updates have failed to stay current
with the core code. There have been several ffmpeg updates to address exploits
using malformed videos, but users of many of the utilities are still
vulnerable. The true open source projects are maintained very well, it's the
apps where people are out to make a quick buck with a GUI on some free code
and ignore the license that are the offenders. Projects such as VLC saw
immediate updates.

The many utilities that hide their use of ffmpeg and related open-source
generally don't get listed in the security alerts such as this.
<http://www.securityfocus.com/bid/15743>

Even Pre OS X Mac applications had many resources that were easily modified
With ResEdit and other tools. It would have been more work to alter code with
security features, but changing the about box, splash screens, icons, and
menu/dialog text was trivial and didn't require programming skills. Of course
the sort of resources modularity used it was made international localization
so easy.

I never did hear of any apps being hijacked, but those were comparatively
innocent times.

------
Estragon
What are some of the tools he mentions for pulling out and modifying the app's
resources?

~~~
dennisxl
xda-developers is a place to find and learn about those tools.

~~~
ashbrahma
One of the tools: <http://forum.xda-developers.com/showthread.php?t=514412>

