The library approach to release a free and paid version - android

I am going to release multiple versions of an app to the Android market / Google Play Store. Now I am looking into the best way to do this.
I've read a lot of questions here about how this is achieved in the easiest way.
I do not want to create application version specific activities, because this could easily lead to code inconsistencies between the different versions. So I want to use the library approach. This also seems to be the easiest way, instead of all the examples I've seen which require hefty amounts of ANT scripting etc
For argument's sake I am going to have:
com.app.library
com.app.free
com.app.paid
com.app.paidmore
My idea is to base code in the library on the package name.
Parts of my activities would not show, or disable functionality based only on package name.
What are the downsides to this approach? I can't seem to find any, but I am curious about the opinions. Ofcourse all application versions would in a sense contain all functionality, but the functionality is disabled on the fly by code. I think it would be a lot of work to modify the code to hack the app to obtain full functionality, but am I right?
This approach seems wrong, in that it would be very easy to modify the apk and distribute it in the modified way.

What are the downsides to this approach?
Your app winds up bigger than it needs to be (e.g., paid functionality residing on a free user's device). And, as you note, it puts all the functionality on the user's device.
I think it would be a lot of work to modify the code to hack the app to obtain full functionality, but am I right?
If it takes more than five minutes, the script kiddie is typing too slow. Decompile, search-and-replace your package name, recompile.
This approach seems wrong, in that it would be very easy to modify the apk and distribute it in the modified way.
That approach actually might take more time -- to perhaps ten whole minutes -- as it may take longer for the script kiddie to figure out exactly what resource needs changing.
Of course, the script kiddies can just grab your paidmore version and attack that, so the fact that your free and paid apps happen to have paidmore functionality is not much of a problem. So, the biggest difference IMHO is APK size, and only you'll know how much that differs between the versions and whether or not it's a problem.

Related

multiplatform or android platform alone and desktop alone for Kotlin

i am trying to make a project that is designed for a business and a customer where the business will be on the desktop side and the customer will be on the android side.
i was wondering since both the platforms will have unique UI(tabs/services/actions... etc.) that serves their needs:
should i use Kotlin multiplatform and use as much shared code as possible or build a standalone app that works separately on each platform and then share information by servers?
are there even other ways to accomplish my goal?
so far here are the most important pros and cons of multiplatform:
+reduce time consumed
+ability to share code which reduce bugs and possible errors.
still in alpha version (experimental) which means not enough libraries in support .
to be honest the only thing that is stopping me from choosing multiplatform is the "experimental " warning sign and if i chose to make desktop app alone might as well make android/IOS app altogether( since the sharing code ability between android and IOS is very much reliable) and in that way i would have gained an extra platform for my phone app in return for the added time of development
i really need an answer from any experienced Kotlin developer and thank you in advance :)
What the KMP thought for is sharing business logic between platforms.
If you have different business logic(business/customer sides) not sure how much you’ll be able to share, but the least you can do is data objects: you can share same objects between business/client/server to make sure your json parsing is stable and doesn’t require changes in many places.
You’ll be able to share a lot of stuff if you choose to share android business logic with iOS, but note that there’re some pitfalls you need to learn, so I’d say you’ll spend 2x time for two platforms in first 1-3 month (same time as if you would do for two separate apps), and then your’ll be able to make two apps with average speed of 1.5x time.
Don’t forget that all UI part will take same time as for a separate app, so it won’t be “free”
Still if your project is big enough, it should pay off.
What’s about KMP being experimental: as for me it’s already stable enough and I’m using it in my current project for sharing code between ios/android/server.
It’s in active development phase so most of problems you face will be fixed fast, or you’ll get a workaround on the youtrack
For the JVM part you almost loose nothing: you had to use Native frameworks but if you need to using jvm dependencies in the shared module, you had to provide alternative code for an each other platform(ios, etc) using expect/actual
It has some limitations for iOS platform. The main one, I think, is that you had to work with a specific memory model: you can’t modify objects from different threads, but if you choose your architecture wisely it won’t be a big problem.
I think your decision should depend on how much logic code you need to share between different platforms, and if there's a lot - KMP is a good solution.

Need some information about reverse engineering and decompile (android app - jdk)

I'm new to android and I don't know much about software engineering. I wanna know about things should be done to make it harder to decompile an app. I made some research about it and I ran into this debugger JEB which seems like it can monitor some stuff while app running. Yet I don't know the advantages of using it since I don't get the critical points of an android app which is being monitored by JEB. for example:
enter image description here
appearantly the right side shows local variables. what does x / xh means for an int? or for the string value "secretKey" is the value of string seriously? if it is then all variables in my code are at risk!!!??
I think maybe one of the attempts is to make a lot of fake variables in code so that the real ones can't be seen easily. Does it make sense? And are there other leaks that I should try to prevent for example about this JEB? Does proguard have anything to do with this? As I said I donno much about soft-eng and I didn't get to understand what proguard actually does.
And another thing I've seen is https://ibotpeaches.github.io/Apktool. How to make it more mixed up for such tool to handle?
The last question, I code in java and don't think yet I have the opportunity to start native coding but for future; I've seen people say its safer to code natively. Is it by itself? or there are more libraries to keep more safety? or its because of the final apk structure?
sorry if some words look dumb. thanks in advance
You should not try to prevent reverse engineering, because doing so is largely futile. Instead, you should design your app to minimize the effect that reverse engineering would have (i.e. you should not include secret data like keys or passwords in the app).
The amount of effort that people are willing to put into reverse engineering your app depends on how important and popular it is, while obfuscation increases the effort required to reverse engineer the app. However, if your app becomes popular, no amount of obfuscation will stop people, while if it languishes in obscurity, nobody's going to bother to look at it, even if you post the source code on Github. Also, in rare cases, adding obfuscation will make people crack it just for the challenge.
Apart from that, there is the risk that obfuscation will give you a false sense of security. Anyone can devise a system that they themselves cannot break, but if you aren't an expert at reverse engineering, the measures you come up with are unlikely to stop those who are. It is best to instead assume that everything in your app is public information and design accordingly.
You can protect your code by using some powerful obfuscator tool like: Bg+Anti Decompile/Reverse Java
It has a lot of protection options:
Hide string value (helpful when you keep some sensitive info in java source, ex: "Hello world" ->ߤª )
Obfuscate with unicode characters
Hide packagename
Add fakecode to trap the decompiler tools
Check resource-string (helpful when someone try to edit the resources of your APK)
....

Android shared library integrity protection

Is there a way to somehow 'protect' a native shared library (.so) for the Android platform against binary changing?
E.g. someone could overwrite a JMP instruction with a NOP after reverse engineering the application, and distribute that library to rooted devices.
Is there anything someone can do?
What I'm looking for here is ideas about implementing a series of checks (e.g. encryption, checksumming etc).
Of course since the platform does not look like it offers support for this (correct me if I'm wrong) it would have to be all 'client-side'. Thus the whole thing is a bit futile, but at least will hinder reverse engineering some.
Yes there are things you can do, and they will make it very challenging for the Reverse Engineer, but I doubt you'd be able to do anything that would stop Chris Eagle.
The best way to protect from modification is to take a SHA-2 of the .so after you compile it, and rehash each time at runtime, matching it against the known value. This check will be enforced on the client side, so a skilled RE could just modify the binary to ignore the check. It does make it a bit harder though. If you put checks all throughout your code and use different checking techniques then it extends the amount of work the RE has to do. Do know however that Microsoft has poured millions of dollars into anti-RE techniques and there are still pirated copies of Office and Windows out there. You'll never stop them all. My personal philosophy (now that I've studied RE myself) is that it is ultimately too much of a pain to try and stop them. Just make a good app, make it cheap, and people will buy. The miscreants that steal your stuff wouldn't have bought it anyway.
If your app calls home you could also submit the hash to the server for verification. Of course and RE can still bypass this but it is one more thing to do.

How to go from cracked APK to java code? 1-click tool cracked my app

So I published my android app, I proguarded it, applied LVL and even changed some of the LVL code but offcourse, I found it cracked somewhere using a tool called Lucky Patcher. I am not going to ask how can I protect against 1 click tools like that, as I guess there is no single answer ( unless you have an idea and can point me toward).
I need to ask you to help figure out how my code was cracked. I understand that this tool takes APK file and removes licensing. Now given that, how can I take this APK file and reverse engineer it back to Java files to see how the tool cracked my code (so I fix it)
Please help me
Thanks
After Proguard, there's no way to decompile your code into humanly-readable Java.
While it makes the reverse engineering process more difficult, it's not impossible for a clever reverser to figure out the hidden algorithm.
As for tools,
Use android-apktool to decompile to smali and extract all the encoded xml resources.
Use dex2jar to translate Dalvik into jar
and finally jd-gui to see the resulting reversed java code
There's a lot of info here on how to go from a DEX file back to Java source. Also, have you looked at this blog post which addresses many of the ways to protect your source?
piracy is a big issue , and i don't think that any platform or OS can be fully protected from it .
however , google already made some tutorials regarding protection against it , for example:
http://www.google.com/events/io/2011/sessions/evading-pirates-and-stopping-vampires-using-license-verification-library-in-app-billing-and-app-engine.html
also:
http://android-developers.blogspot.co.il/2010/09/securing-android-lvl-applications.html
i think that you can also put some sophisticated obstacles using C instead of java.
also , as google suggests, consider using a different approach : make the core features free , and make the rest purchaseable via in-app billing . you can also add ads and a feature to remove them by in-app billing as well .
I was thinking about this and it seems like if you really wanted to secure your application from hackers there is really only 1 way to do it. You can implement all kinds of fancy methods of insuring your application is licensed and paid for as described in the google article but all it takes is a good hacker to decompile your application and find where the code is and then comment it out or change a function to always return true.
Instead, implement some portion of your application that is required for use in jni/ndk, and check for validation in that code. It doesn't have to be extremely complicated code but you can't just put something like a function (eg. checkValidity) as a user could easily comment the java call that calls into the ndk. Instead you should make some call to your ndk to actually do something that is non-trivial for your application to run -- something the user can't just comment out or switch out with a defined function that does the same thing. From within the ndk code do the verification of your application's integrity/licensing and if it fails kill the application or whatever you need to do.
In order to bypass this the hacker would need to re-implement the ndk code or reverse engineer it.. Which should be much more complicated and not worth while.
This obviously isn't a simple solution and still won't guarantee your application never gets hacked, but it should be much harder to break than the other methods..
I personally think that Obfuscation {Proguard, Dexguard} and native {.so} are pretty effective way to go if used properly.
It definitely deters less experienced 'players' and definitely complicates the life of even experienced 'players'
Don't simply copy/paste the Google android example codes....

How do you release two versions of an app on the Market?

I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.
This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/
People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.

Categories

Resources