I have developed one j2ee web application and generated .war file of it.
I have to share this war file with clients.
My problem is:
I don't want to give .war file for permanent use. Instead of to give it for trial period let's say for 30 days, so that they can know the features of application.
How to give trial period logic.
If I write logic using DB, they can reinstall the whole war file after one month and everything will start working again.
Client can also change the timing of system and then my control will go off.
I cannot access internet from application because it will be deployed only on intranet.
Please help me in any possible way of achieving this.
Thanks in advance
You very probably cannot do this perfectly (ever heard about cracked games and rooted phones?).
So it's a matter of making it difficult enough for the user to bypass your license, so that they won't bother.
The basic, simple idea is:
- Create a license for each user using your private key, that will contain the license expiry date
- Check the license for validity in your application, using a corresponding public key (both integrity and expiry date)
This will make sure the user won't get another month by just reinstalling.
Second simple step would be to write the last seen system time each time you exit the application, then check the system time on startup to make sure user didn't set the clock back (beware of daylight savings time though!).
That might get you covered for the two basic tricks to bypass the trial period. For more motivated users, you'll then need to add in more checks.
Related
I develop applications in AndroidStudio. For the first time in my life, I faced a problem - I was asked to make the application possible for use only within ONE country. I've thought all my life that this is configurable via the Google Play Console, but I've been told that it's not. Maybe someone knows how to implement such a restriction using a code only? Mb some changes in a gradle files?
You can use Locale to get the current country of users.
val locale = context.resources.configuration.locales.get(0).country
And you can make a request to a server to know users' countries.
For example, you can try: https://ipinfo.io/country
This is not an all-time work solution, but it's worth trying.
I am working on a software license related task , the current validation method requires an online check, against the company server , but since the users can manipulate there system clocks and continue using the software in offline mode , i have been assigned to look for a way to do offline validation clock checks using java , I know there are no bullet proof ways to do this but can anyone please suggest a way to make it hard using an expired license in offline mode . thank you
Have the software know the earliest possible date (based on when that version went into production). If the clock is prior to that date, deny access until the online check succeeds. This requires storing this additional state (that the app is locked out) somewhere on the filesystem. You will probably want to have the app be "locked" if the file is missing to prevent someone from resetting the state simply by removing the file.
Also, when the license check succeeds (either online or offline), note the time. Deny any future access that is prior to that time and deny access until the online check succeeds. This forces time to march forward and if they mess up with their clock re-setting then they are locked out until they succeed with an online check.
When the license check succeeds online, store the server timestamp on the client (the timestamp that is used above to keep time moving forward).
Obviously, you will want to protect the contents of the file that persists this state, e.g., using encryption.
This is not fool-proof, but makes it harder for someone to use expired licenses by twiddling the clock.
Some relevant background:
My application is a Java app compiled into a .exe via JSmooth. The anticipated user base would likely be a few hundred users, but could grow well beyond that, as it's a community specific application.
How it works:
2 .jar files, one that preforms initial checks, another with the meat of the application.
Ideally, the init jar displays the splash, checks the version in desktop.txt against server.txt, if they differ, it prompts the user to update.
What I need to figure out:
1) What is a cheap, scalable hosting service that I could use as the file host for updates?
2) How can I create an "updater" to actually preform the jar replacement? My current solution is simply writing an updater in Java, but I was hoping for something like the installers people are more familiar with.
All of the research I've done has resulted in lackluster results, as 99% of hosting searches result in site hosting results. I just need an update repository with reasonable security. i.e., decent DDoS resistance and not left wide open to the Internet.
Edit: formatting
Easy to do and very foolish cheap with Amazon S3 or Joyent Manta as both support time-limited signed URLs and headers (which can contain a SHA-1 of the file) to check to see if the update is needed before downloading
On startup your app would check the update URL to see if it has changed. If it has changed, download the JARs. Do this before the app loads classes from those JARs. Updating the updater itself will be trickier so consider that an update might need a new update URL to prevent expiry.
I'm trying to find a solution to my problem, which is only applicable in our test environments. I'm working with systems
(banking) depending on each system being on the same specific date. The development we do is solely within system integrations.
In short: Our systems generate the data, which we then adapt between our systems. Naturally, we do not hold the source
codes to the systems we have.
To my specific problem: I have a system(A) running on JBoss: JBoss_4_2_3_GA on Java JRE build 1.6.0_32-b05. I've set up
a messaging broker in WebMethods(WM) listening to a specific port on this system. When users trigger certain events in system(A), JMS
topics are created and sent to a queue. WM then do a few validations and deliver the messages to system(B).
Everything was working properly, up until recently when we noticed that system(B) was expecting a timestamp field being
on the same date as the system itself were in (the functionality we built won’t otherwise work). The problem is that system(A) does not provide such a system date option,
and the timestamp in the messages are "real" timestamps from the operating system (Windows 2008 R2). So I require
a fake date (timestamp) applied in system(A) which would be on the same date as system(B).
The first solution to this problem was simply to disable the NTP sync and set a fake timestamp in Windows running
system(A), which would solve the date issue. But doing this, we noticed that our Windows group policies stopped working,
which affected normal logins to the server. So this was not a solution we could apply.
I know that others have posted this specific issue, and solutions such as using java date alternatives as Joda-Time etc.
I don't see how I can apply mentioned changes into my system(A) due to the lack of source code.
Help/suggestions would be greatfully appreciated. Right now I’m blindly focused into changing the timestamp in Java in system(A). Perhaps there are better alternatives such as just applying the fake date in WM? I just don’t know enough about WM to do this either.
Ok, I finally found a solution to my problem. Since the lack of source code, it was really a hard shot to do anything within the application (Java/JBoss). Searching arcoss forums, I found a nifty little tool (for Windows) called "RunAsDate". This tool does exactly what I need, as it intercepts the API calls to the OS related to dates and times and gives whatever date/timestamp the user chooses!
The best thing is that it doesn't make any changes to the system (dll's), and runs either from the simple GUI (in app package) or called from command line. Of course it will take arguments if required.
I hope others can find this as helpful as I do: http://www.nirsoft.net/utils/run_as_date.html
BR
/rash
I am creating a client program that talks to a server (which I programmed). I am making a little game for myself in which I roll a dice and the server does also. Whoever gets the higher numbers wins. However within my code, I send the server commands when the user presses a button, and then the server responds by sending back what it rolled, so it can be shown in the GUI window. However, I find this a very insecure method. For example, a person could just simply decompile the jar file, and make it so they always roll a 12. Since the only place that both rolls are together (the users and the servers) is the users screen, I have to evaluate the game from the client, obviously not very secure. I am trying to make my game more secure, and have found 2 options.
Obfuscators
Unless someone knows of a very easy one to use, I cannot figure out how to set any of them up, as they rarely come with a gui that I can easily "pop" my .jar file into
Binding to an .exe
I honestly dont know how secure this is. There are programs in which I can "bind" two things (mostly for making viruses which I am obviously not doing), into a single .exe file. I can bind my .jar into an .exe, but I still dont know if the .exe could be decompiled back into the .jar file and from there back into the .java code.
By the way, another security issue is that it connects to the server from my ip adress (which I do not want the client user to know about)
Never trust client input.
The only truly "secure" method is to have the server generate both its own roll and a roll for the client.
Of course, if the outcome of the comparison of the rolls has no impact beyond what the user sees (in other words, the client does not report back who won), then really, who cares? I could patch Solitaire to let me always win, but that's no fun.
If the code is on someone's computer, you should consider it compromised and exploited already. In the race between crackers and developers, the crackers always win because the crackers have everything they need. Jars can be (easily) decompiled and deobfuscated, .exes can be picked apart, and at extreme levels the OS can be modified to go behind your back - literally.
Instead, you should reconsider your architecture: do you really need the client to roll the dice? Could the server roll both?
Both obfuscation and compiling to a ".exe" can be defeated relatively easily. Hackers / crackers, and anti-virus security experts do this kind of thing every day.
Basically, you cannot trust any application that is running on any machine that could be controlled by someone you don't trust. In practice, this means anything that isn't in your (locked and firewalled) server room.
(Aside: even systems based on TPM are potentially vulnerable, since there have been successful attacks on TPM chips. And that wouldn't be practical anyway, since TPM is not available for securing application-level code. AFAIK, it is not even used at the OS level ... though I've heard that the next version of Windows is going to require hardware that is TPM encumbered.)