I want to make a executable jar which can run in only one machine.once it is run in any machine it can not be run in another machine.
Means i want to make one license per user type application.
I want to make this application using Java.
Any help on this would be appreciated.
Thanks in advance.
Yes, it's easy. Just grab your hardware informations and generate a hash. This will be synched on each start with a server. It will return a hash which can only be decrypted with the hardware. Then you can create a flag which is available by runtime that it'S "licensed"
Another option:
Remember that JAR files are actually ZIP files, with a different extension. You can store other resource files inside a JAR file, and I believe there is a Java API for retrieving those resource files (I don't remember how that API works). So:
When your customer orders a copy of your application, make them supply hardware information (perhaps give them a little application which harvests the data). Build a JAR for them which contains a resource file, with a hash of the hardware information in that file. When the application starts, retrieve the hardware information and hash it, and compare with the hash in the bundled resource file. If they don't match, exit.
Related
I've used Commons IO to write a program that copy files and other things. But I want to copy a file to a local ip address \\10.x.x.x, but the user doesn't have rights to do the copy, so I need to put an ID and password to access it. However I cannot find a way I can do that.
To move file I use :
FileUtils.moveFileToDirectory(fichier, destDir,true);
But my directory is something like \\10.x.x.x\files and only a few users can write in that directory so I have an ID & password that let you move files there. I want that even if the users don't have rights to move files to that directory my program can do it.
It is not really the way Windows security works. If you really want to do it that way, you will have to use Java Native Interface or Java Native Access, and manage to call the WNetAddConnection function from Mpr.dll (and do not forget to call WNetCancelConnection when done).
But you would have to store a password in your program, which is poor security practice.
The standard way to do that would be to start a service that would run under a user that has access to the desired directory, and have your program to communicate with it using whatever you want, the simplest way being probably TCP/IP. But unless you have special requirement for that I would not recommend to use Jave for those kinds of program.
A more Java alternative would be to start a Tomcat service on server machine running under a user having access to the directory. That way you just have to develop a standard Java Web Application able to upload files that would save the files to the proper directory. But it would be a traditionnal and portable Java application with no need for JNI nor JNA.
If cannot use a Tomcat and do not want to invest to much on it, you could split the program in pieces :
one client program that copies files on a directory (on server machine) with File creation rights for everybody - can decays to the copy utility if nothing more has to be done or can easily written in Java
one server program that will run on server machine under a user that has full write permissions on target directory. This one can also be easily written in Java
you can easily install the server program as a service on the server machine with sc and srvany according to this answer on ServerFault
If you use a client program, you could easily add a digital signature file with each copied file, but as I said above, it is poor security practice and add little if any security. At least the program should be executable and not readable, and the sources should be kept hidden. It is better to log the users that copied the file and ask them what happened is you find a problem.
I want to make setup file for java swing application .
I am creating the setup by writing the script file and selecting the source file as jar and other necessary resources .
Now i want to make my jar disable to extraction .
Is there any way from which i make sure so that no can access the resources from my jar file either the class files or images etc.
thanks in advance
You can make it harder to get your resources, but you can't make it impossible. That's not a Java problem, by the way, but a general one of distributed software. In order to access your resources, your program (or in the case of Java the runtime environment) must be able to unpack them. Even when you encrypt them somehow, the program needs to include the decryption key and the decryption algorithms. A determined user can find these through reverse engineering, and use them to get your resources.
You could try obfuscating your codes.
This is the one I have used for obfuscate.
http://www.zelix.com/klassmaster/
You could find more tools for that.
You can use java webstart, your jars will be kept in cache so very its hard to access.
Java Web Start Guide
I have a small java utility application which performs tasks on remote computers. This app will provide user with a dropdown/combobox where they can enter ip address or hostnames for the computers they wish to connect to. It would be nice if the users could have a history of items/hosts they had connected in the dropdown.
I thought that I can create a file inside the distributable jar and use it to maintain the history. But writing to a file inside the jar seems to be impossible? The alternate approaches would be to use text files, databases etc located outside the jar. But this is not quite I would like to do as my utility app is only one file and I would like it to be completely independent of any external files. Also its not nice to have a text file stick around your jar file or create a text file each time your app is run.
Considering this case what options can I use? Are there any apis that can help in storing or keeping history?
Why don't you store this info with an hidden file in the user home directory? Many application do the same thing.
You can get the user home directory in this way
String userhome = System.getProperty("user.home");
I'd recommend keeping some .dat file somewhere associated with the JAR. Could be in same directory, or in the user's home (as #dash1e recommends) to avoid any permissions issues. I think you'll find that's the simplest solution.
Another option would be to use a Java-based database solution which could be bundled into your JAR (see Apache Derby, et al). Note that this would create files somewhere, but you wouldn't have to worry about the file-level management, as you'd just be interacting with it as a database.
One final option, if you really insist on avoiding having to maintain your own file, would be to use the Java Preferences API which provides an OS-agnostic way of storing data on the system in some obfuscated location. This is arguably a bit of a misuse of the goal of this API, but would accomplish what you're asking for.
We have to make a Java application demo available on Internet using JWS. It goes pretty well; all that's missing is making working directory files available for the application.
We know about the getResource() way... The problem is that we have different plugins for the same application and each one require different files (and often different versions of the same files) in their working directory to work properly. So we just change the working directory when we want the application to have a different behavior.
Currently, the demo is packaged in a signed jar file and it loads correctly until it requires a file from the working directory. Obviously, the Internet users of this demo don't have the files ready. We need a way to make these files available to the WebStart application (read/write access) in its working directory.
We've thought of some things, like having the application download the files itself when it starts, or package them in the jar and extract them on startup.
Looking for advices and/or new ideas. I'll continue working on this... I'll update if I ever find something reliable.
Thank you very much!
I said I would share what I found in my research for something that would fit my needs. Here's what I have so far.
I have found that the concept of current working directory (CWD) does not really make sense in the context of a Java Web Start (JWS) application. This had for effect that I stopped trying to find the CWD of a JWS and started looking for other options.
I have found that (no, I didn't know that) you can refer (using getResource()) to a file in the root directory of a JAR file by simply adding a '/' in front of its name. ("/log4j.properties", for example.) The impact of this is that I can now take any file which is only referred to in a read-only manner in the root of that JAR file (which is really only a ZIP file). You can refer to any file in the root of the JAR file using AnyClass.class.getResourceAsStream. That rules out the problem with read-only files required to run the application, at the cost of a switch in the code telling whether the application is run from a valid CWD or from a JWS context. (You can very simply set a property in the JNLP file of the JWS application and check if that property is set or not to know where to look for the file.)
For write-only files (log files in my case), I used the property , adding a directory with the name of the application: <user.home>/.appname and added log files to it.
Read/write files (which I don't have in my case) would probably simply go at the same place than write-only files. The software could deal with uploading them somewhere if needed, once modified, I guess.
That's the way I deal with the problem for now.
Note there is a service you can explicitly ask for, to get file access to the computer (unless you go all the way and ask for full access (which requires signed jar files)).
Then you need to determine where these files need to go - basically you have no idea what is where and whether you may actually write anywhere. You can create tmp-files but those go away.
Would a file system abstraction talking to the JNLP-server do so you store the users data on the server?
I am developing a Java Desktop Application. This app needs a configuration to be started. For this, I want to supply a defaultConfig.properties or defaultConfig.xml file with the application so that If user doesn't select any configuration, then the application will start with the help of defaultConfig file.
But I am afraid of my application crash if the user accidentally edit the defaultConfig file. So Is there any mechanism through which I can check before the start of the application that whether the config file has changed or not.
How other applications (out in the market) deal with this type of situation in which their application depends on a configuration file?
If the user edited the config file accidentally or intentionally, then the application won't run in future unless he re-installs the application.
I agree with David in that using a MD5 hash is a good and simple way to accomplish what you want.
Basically you would use the MD5 hashing code provided by the JDK (or somewhere else) to generate a hash-code based on the default data in Config.xml, and save that hash-code to a file (or hardcode it into the function that does the checking). Then each time your application starts load the hash-code that you saved to the file, and then load the Config.xml file and again generate a hash-code from it, compare the saved hash-code to the one generated from the loaded config file, if they are the same then the data has not changed, if they are different, then the data has been modified.
However as others are suggesting if the file should not be editable by the user then you should consider storing the configuration in a manner that the user can not easily edit. The easiest thing I can think of would be to wrap the Output Stream that you are using to write the Config.xml file in a GZIP Output Stream. Not only will this make it difficult for the user to edit the configuration file, but it will also cause the Config.xml file to take up less space.
I am not at all sure that this is a good approach but if you want to go ahead with this you can compute a hash of the configuration file (say md5) and recompute and compare every time the app starts.
Come to think of it, if the user is forbidden to edit a file why expose it? Stick it in a jar file for example, far away from the user's eyes.
If the default configuration is not supposed to be edited, perhaps you don't really want to store it in a file in the first place? Could you not store the default values of the configuration in the code directly?
Remove write permissions for the file. This way the user gets a warning before trying to change the file.
Add a hash or checksum and verify this before loading file
For added security, you can replace the simple hash with a cryptographic signature.
From I have found online so far there seems to be different approaches code wise. none appear to be a 100 hundred percent fix, ex:
The DirectoryWatcher implements
AbstractResourceWatcher to monitor a
specified directory.
Code found here twit88.com develop-a-java-file-watcher
one problem encountered was If I copy
a large file from a remote network
source to the local directory being
monitored, that file will still show
up in the directory listing, but
before the network copy has completed.
If I try to do almost anything non
trivial to the file at that moment
like move it to another directory or
open it for writing, an exception will
be thrown because really the file is
not yet completely there and the OS
still has a write lock on it.
found on the same site, further below.
How the program works It accepts a ResourceListener class, which is FileListener. If a change is detected in the program a onAdd, onChange, or onDelete event will be thrown and passing the file to.
will keep searching for more solutions.