Reverse engineering Android and iOS applications

[Halcyon]

I'm currently part of a design team creating a smart phone/tablet application (the function doesn't really matter for the purposes of this thread). The plan is to release them for both Android and Apple devices.

My question is, once the compiled application is obtained by the user to their device, how trivial would it be to reverse engineer the code to defeat restrictions/features locked down in the demo version (but available in the paid version)?

The answer will depend on how we implement "unlocking" of those features once the user purchases the full version. Do we bother releasing two different versions (a free cut-down version along with a paid one) or are we better off releasing one version only which is free, but allows you to enable features using unique unlock codes (for example).

[julianhigginson]

it depends on the details of what you're making, but you should assume that if your app is worth cracking, someone will do it, no matter what you do to stop it.

BUT chances are, the majority of users who would ever possibly be a paying customer for your app will normally only install programs from official app stores, which don't welcome people publishing cracked versions of paid apps. so... the crack shouldn't really cost you much in the way of lost sales. Most people installing the crack were never your customers anyway. (unless you are selling something with a internet based component, in which case a bunch of copies will cost you money... but then you should have user accounts and recurring subscription fees!)

you should be more worried if you make something cool and unique, that 2000 straight ripoffs in term of behaviour, look and name of your app  appear, crowding you out of search results and undercutting you on price.

[onesixright]

Is thus just for commercial reason? Or do you store some "high-end" data or patents that you need to protect?

For Android I have no idea (other then, hell yeah probably).

Binaries for iOS, you can reverse engineer, but who cares? Changing the code to by pass a trial is not that easy (maybe if you rooted your iOS device). I'm guessing thats not many user (in total iOS users) have it rooted. Apple has "in-app purchase" so you can get all (features) that (deactivate trial by paying). My personal experience, dont put 2 apps in the store. I hate it to have to buy different version of a same app (thats personal).

A wiser plan is to not overprice your product. Asking ridiculous prices is what make people try to crack stuff. Once again, for iOS very unlikely. They probably go look for a free version of something similar.

Let me emphasise again I'm point at circumventing a trial lock. If your "code" saves the world, cures cancer, etc. Or you need to protect a patent, thats another ball game. I'm pretty sure you can't really protect yourself, if (big) companies are out to steal your product, good luck protecting it.

Wiser is top make sure you
a) release a product that works (i.e. wel tested) from the get-go and
b) have it reasonable priced.

From a user perspective: The other day I was thinking about buying specific product. When I  saw the price, my jaw dropped. I looked into the trial version I found a flag that allowed me to use it without to much fuzz. I would have payed 200-ish USD, but not 800 USD for a tool I used 10x a year. I went looking because of the ridiculous price (since it was all the same home or business use).

[Halcyon]

Is thus just for commercial reason? Or do you store some "high-end" data or patents that you need to protect?

Nothing sensitive in need of any real protection.

Most people installing the crack were never your customers anyway.

Good point. Those with the knowledge and the time to sit through and bypass features can have it. It would cost them more in time than it would to have paid for the application in the first place.

[amyk]

Android is essentially Java. Very easy to decompile, mod, and recompile. (That's why there's a whole community that does this to provide "unofficial" apps with all the annoyances stripped out and often add other useful features too.)

[JPortici]

Do we bother releasing two different versions (a free cut-down version along with a paid one)

I would do this. If anything because all apps i've used that actually give something more in the paid version come in two separate apps. There must be a reason, right?
Otherwise the in-app purchases are mostly to remove ads..
Mantaining the two apps shouldn't be difficult, using conditional compiling you should be able to remove pieces of code and maybe change the appereance (like hiding or graying out buttons and stuff)

All apps i've developed (a few) were written with Basic 4 Android, which has a "Release (Obfuscated)" compilation options to make reverse engineering harder.

[onesixright]

Do we bother releasing two different versions (a free cut-down version along with a paid one)

I would do this. If anything because all apps i've used that actually give something more in the paid version come in two separate apps. There must be a reason, right?

Huh, yes, developers that don't know what they do?

Why on earth would you make 2 apps, especially if the eco-system has a good solution (in-app purchase). Me, as a developer would always choose to maintain one app, then two. So you find a bug, and you need redeploy two apps? Madness.

Unless you need the work of-course

// by the way no offence.

[JPortici]

None Taken
I'm not a software/app developer with formal training, i do hardware/firmware with the occasional app (and the apps are usually tied to the hardware so mostly free)
You may very well be right, but in his case i would still release two apps.
The project/source code can be the same, conditional compiling exclude the features that i want to be available on the paid version so it's only one app to mantain, really.

Instead if it was like the user can unlock specific features i would use in-app, of course

[BrianHG]

You can make a crucial point of function in your software processed online on your server, ie, it's missing from the AP.  This vastly increases traffic to your master server, but, you can make that point more secure than the released binaries at the user end.

Example, if you are making an online game, which can only be played online, there actually is no bypass crack on the user's ap itself as it doesn't have any of the mechanics for gameplay, just the drawing engine and graphics and sound.  The hackers needs to attack your server to enable gameplay.

[onesixright]

You can make a crucial point of function in your software processed online on your server, ie, it's missing from the AP.  This vastly increases traffic to your master server, but, you can make that point more secure than the released binaries at the user end.

Example, if you are making an online game, which can only be played online, there actually is no bypass crack on the user's ap itself as it doesn't have any of the mechanics for gameplay, just the drawing engine and graphics and sound.  The hackers needs to attack your server to enable gameplay.

Adding a ton of lag and connectivity issues...? Not sure if thats the way to go.


Sent from my iPhone using Tapatalk