Android Question Use License Control

[Cleidson]

Hello everybody,

I have been working on a usage license model for an application that I have been developing and in all the scenarios that I studied to implement there is the possibility of defrauding the use of the application. Before I let you explain how I intend to market the application.

- I do not intend to store user data such as login, password and others on an external server.

- Pretend that the information the user registers is stored in the application itself and that the user can backup the database on the storage server of their choice.

- The only information I intend to collect is a GUID to control the license(s) of use.

I had designed to use the user's phone number and/or email as auxiliary variables for usage license control, but in several scenarios the user could be harmed or cheated out of the license.

The most worrying scenario is the fact that the application will have a 30-day trial license. So, as I cannot, due to Android's security rules, validate whether the phone number entered matches that of the device, nor whether the email address entered also matches the one registered in the Android accounts, the user who notices this situation can every 30 days uninstall the application and install it again and use the application for another 30 days using false information, as there is no way to validate this information. And so on.

Therefore, a possible solution would be to leave a marker on the device so that if the user uninstalled and reinstalled the application, it would check whether the application had already been installed and would not allow the trial license to be installed again. I thought about using a KVS for this, but I lack the technical knowledge on the subject, especially if it is allowed to leave this type of ballast on the device.

Does anyone have knowledge on the subject? Any ideas?

Thank you in advance for everyone's attention

 

[Brian Dean]

I don't like to see questions on the forum left unanswered, particularly when they are from newer users, so although I am not an expert on this topic I will try to tell you why your question has not had a response after nearly 24 hours.

Your question has been asked many, many times before. Essentially you are asking "How can I identify a specific device?". The answer most often given is to use the advertising id. This is the answer that Google appears to recommend here. But the advertising id can be changed. I don't know how to do that, but if I thought that it would save me money then I am sure that I could find out. If you want to try that path then here is a link.

Another identifier that is often mentioned is the MAC number. This might work in many cases but is not a watertight guarantee as it can change, and I am not sure if it is always accessible. Depending on your app it might be good enough. Search the forum and you will find out more but ignore older posts - things have changed.

In any case search the forum for "unique id" and similar terms - there are dozens of posts.

You ask specifically if it is possible "to leave a marker on the device". The answer is "Yes - you could write a marker file", but with recent Android versions you need the user's permission, so they know where the marker is stored and would be able to remove it (using a file manager app or by connecting to a PC). Again, not every user will know how to so this, so it will work sometimes.

The only way that I think a server-less registration system could work would be if your app generates as asset that the user would lose when they re-install. So a fitness app would lose your step-counter history, for example, or a game app would lose your high-score table.

 

[f0raster0]

Excellent response above!

I could suggest double-check if your licencia idea is the best option.
For example, I use a software for electronic design, I've purchased the license, and only when I want an update, I pay a smaller fee (lower than the original cost).
Maybe you could apply a similar model in your app: sell the app initially, and for updates, provide users with a coupon to purchase the new version then Google take care.

Edit: I just see this
https://www.b4x.com/android/forum/threads/revenuecat.162348/ maybe could work for you

 

[udg]

Hi all,
generally speaking, a well determined pirate given enough time will eventually break any protection scheme.
Honest people (there are many more we consider) don't deserve any protection sccheme.
So, we are left with those that could pay for your work but find it "smart" to use it for free and those that won't pay in any case.

Why the above considerations? Because often the time and effort spent to build protection is not justified by real revenues.

Amyway, following your requirements, you could try the following.

On first run afetr installation, app generates a simple text file with a single row like "secret_code: 1234" (where 1234 is randomly generated).
The file goes in the DirInternal folder along with the DB. Put in the DB the license expiring date
Secondly, the app encrypts the DB using the generated "secret" code.
On following runs, the text file is read to recover the secret code and decrypt the DB. So you know whether the license expired or not.

If the text file gets altered the DB can't be decrypted.
If the app is disinstalled and installed again it will produce a new secret code (and DB) making an eventual copy of the existing DB useless.
If the user keeps a copy of the old text file and old DB (to be used with the new install), they will generate the license expired message anyway.

What a pirate can do: find out how you encrypt/decrypt, use old text file to recover the secret key, decrypt the DB, alter the license key, encrypt the DB and use it along with the old text file.
So, your protection scheme is about how unusual and "difficult" is the encryption used.

Probably the above is just a partail response and not 100% correct. Afterall I devised it while replying to the original question here. Never built ot used anything similar before. I usually programm for SaaS (software as a service) so a remote server is part of the "protection".

Let me add that Google doesn't encourage the precise identification of a single user. I guess that depends mostly on EU GDPR and similar legislations.

udg

 

[Cleidson]

Brian Dean,
Firstly, thank you for the guidance. I've read a lot of questions on the subject, including best practices for Android unique identifiers. There are many identifiers that are prohibited from being collected for security reasons. However, the most appropriate solutions presented carry a certain risk in terms of the possibility of fraud, in the business model I intend. I'll look into the marker issue. I believe it is viable. And thanks for the explanations.

 

[Brian Dean]

I thought about using a KVS for this . . .

I forgot to mention this in my previous post. The KVS is stored in local storage so will be lost when your app is removed. You could consider Cloud KVS but, as the name implies, this uses a server and you have said that you do not want to do that. You might change your mind. Without knowing more about your plans - like how many users you might expect to have - it is hard to make any firm recommendation, I think.

 

[Cleidson]

Guys,
I want to thank you for your considerations. I read other posts and from what I can deduce there is no efficient way for what I need. But, I will consider the idea of UDG-USA. Thank you very much for your time.