So I am creating a JApplet Game, and I am saving the users info to a .txt file in the APPDATA. Is there a safer way to save their info, that won't allow them to edit it to cheat?
Basically, the only way to prevent cheating is to have a server under your control calculate the score and otherwise enforce game rules. If you were writing a peer-to-peer game, there might be some protocol to allow users to determine if another player was cheating without involving you. ACM sigecom regularly publishes research about such protocols. However, because of the restrictions of the applet security model, users would need to grant your applet special permission for it to talk directly to other users anyway.
Speaking of that, I would advise against "saving the user's info to a .txt file". %APPDATA% is Windows-only, thus breaking "write once run anywhere"; and the default applet sandbox does not allow reading or writing local files, so you'd have to sign the applet and convince your users that it was special enough to merit such elevated privileges.
However, you do have a few options for applet/server communication:
REST calls using java.net.URL
SOAP calls (there are several libraries for this)
RMI (only if the server is written in Java)
Your own custom protocol over TCP
Applets can't read and write cookies directly, but JavaScript can, and JavaScript can call methods on applets. One last way to pass information from the server to the applet (but not back out) is through PARAM tags. You could even pass initial game-state data signed by the server's private key and base64 encoded in a PARAM tag; which would prevent anyone from "editing" it, although I can't think of any way to completely prevent cheating if something about the game-state is supposed to be hidden from the player but known within the applet code.
Related
I made a Java (on IntelliJ IDEA) application and I want to give it to someone via USB or Dropbox.
However I don't want him to give it to someone else, like you know, he downloaded the file, so he can copy/paste it to his USB and give it to more people.
Is there any way to prevent the application from being copied after I give him the application? At first I thought of making a login window, but then I thought "hey, if he knows the password to login to application, he can just give the application to someone and give him the password as well", so login window is not an option (I think?). Can I disable the copy/cut functions with If statements after being copied once?
Or I can only prevent it by linking my application with a database and generating unique passwords to activate my application? Like for example, someone requested to use my application, so I will give him the application but he won't be able to run it. Then I generate a password and sent him the password. However that password can only be used once so if he will try to use the same password on 2 different PCs, it will give him an error. Is there any guide/tutorial/tips of making something like that on Java?
You could create some kind of "activation code" for your software that is generated based on some information about the hardware it's running on. I've seen some people using, for example, the MAC address, that you can obtain in a platform-independent way in Java.
However, keep in mind that those techniques will only work against the most basic users. MAC addresses can be easily changed by anyone that knows how to use Google and even if you use something incredibly complicated instead of MAC addresses, Java programs are dead simple to decompile and once the attacker knows what function is checking if the program is correctly activated, he/she can easily replace it. Yes, you can obfuscate your bytecode, but it only makes the task a little harder, not impossible.
You can do what you suggested and use passwords that can only be used once, but then your program needs to know that it has been activated, by storing that information somewhere (a file or something like that). And once the user knows where that information is stored, it can be replicated on other computers.
Unfortunately, once the user has your program, you have no control over what he/she can do. You can make sure that the user is not going to do stuff he/she is not supposed to do with your program by not giving him/her the program at all. You can, for example, expose your program's features through the web. But, as you said, nothing stops an user from sharing login credentials with another person. Yes, you could check if the user is accessing the page from a different IP address, but then a legitimate user could have problems when, for example, accessing your program from a different wifi network. And in this case, your protection not only fails in solving the problem, but also becomes annoying to a honest user.
In summary, brilliant engineers at huge software companies have been working on protections for their software for years and I'm yet to see a software that cannot be illegally activated given enough time and effort.
I want to prevent decompiling for my game client.
Is there a option I can some how protect the .jar file with .htaccess or any other method so the client (Browsing user, that loads the client via a applet) won't be able to get the file & decompile it.
I always wondered if there is a solution for this, is there? Maybe creating a crypt code, and whenever the server tries to get the client jar, it will send a crypt code via GET, if the crypt code matches, it will load the client from that page, I don't know, there should be a solution ?
Thanks!
For a browser to execute an applet, it needs to download the jar file containing the applet code. An if it downloads it, it's available for decompilation. To protect you against that, you can obfuscate the byte-code, or not use an applet at all, and simply use a traditional web application, where the code is at server-side, and the client only see HTML and JavaScript code.
No. You could stop the browser getting the file, but then it would be unable to run it.
Maybe creating a crypt code, and whenever the server tries to get the client jar, it will send a crypt code via GET, if the crypt code matches, it will load the client from that page,
The user could see the code and still get the file.
There is nothing you can do to prevent the user getting hold of the unencrypted bytecodes.
NOTHING.
The user's machine needs the applet's bytecodes in unencrypted form in order to execute them. Since a user (with sufficient knowledge) has totally control over what his machine does, you can assume that control will extend to allowing him / her to intercept the bytecodes at some point where they have been decrypted.
And if the user can intercept the applet's bytecodes, then he / she can change them to defeat any clever stuff you put into the code. And that includes changing the bytecodes to defeat any measure that you use to detect changes to the bytecodes.
"just make it so they have to use it in the browser then check if they are accessing it from our url" Could that work?
Nope. The user can modify the applet to remove that check.
"you could also make php create a session variable with a hash in and check if that hah is present and matches our hashing algorithm"
Nope. The user can modify the applet to remove that check too.
I don't know, there should be a solution ?
Unfortunately, there is no practical solution ... apart from running everything that needs protecting on the server side.
By the way, this problem is not unique to Java. Someone with the technical knowledge and the motivation can defeat any tamper protection measures in Javascript too, or even in native code plugins that you get the user to install (if he is foolish enough).
I am writing a web based version control system and when a user checks out a code file it is automatically copied to a shared network folder that they have access to. I would then like to automatically open that file on their computer with whatever their default program is for that file type. I do not want the user to have to download and then open the file as it needs to all be automated.
I tried writing a java applet but am hitting some road blocks and before I go further would like to know what people think would be the easiest or best way of implementing this functionality. I would prefer the user to not have to install a piece of software prior to using the system. That was my purpose in initially trying an applet.
I appreciate any advice or recommendations.
I decided to go with writing a client-side protocol handler that I could invoke by redirecting the browser to "myprotocol:data". Unfortunately it involves some client-side setup as they need the protocol handler but it is very simple, basic, and lightweight as well as event driven so no listener is necessary.
I am working on a project in java and I was hoping to be able to collect statistics from the client and a possible problem that I fear will occur is the manipulation of the variables used for collection which will lead to illegitimate statistics. Is it in any way possible to prevent the manipulation of variables or is it always possible?
For example: I want to log the actions made per hour from the client. The variable acting as a counter for the amount of actions performed is manipulated and a much larger amount is added to the counter. This data is then uploaded to the server (Of course using a multi-tier architecture to prevent even more possible problems) and considered 'legit.'
Is there any way to prevent this?
Depending on how the data is uploaded, there are various ways to secure the information.
If you are uploading some kind of text or data file, using basic encryption, even a ZIP with a password, should be sufficient to stop casual users from changing the information.
Your application could also simply use RMI or a web service to upload the information, never giving the user the change to manipulate the data.
All of this of course assumes that the application itself gathers the information - if users have the opportunity to enter the data, there's no real way of preventing them from giving you bogus information.
Without knowing if this is a desktop or web application, I'm going to suggest you encrypt your upload files somehow. It doesn't have to be complicated, just enough so someone can't edit it in a text editor.
Just remember that if something runs on the client machine, it can be manipulated. Java is not a secure language, nothing is, for that matter, and while you can do many things to secure applications, there's always someone just a little smarter out there that can crack it.
If I was doing this, I'd do the accumulation of the statistics on a secured machine. Have the primary data gathering code send "event" message to the accumulator, and have the accumulator keep a log of the raw events and their arrival timestamps. This won't prevent people manipulating the stats, but it could make it easier to detect suspicious patterns after the fact.
Building on that idea, you could arrange that event generator application (on the user's computer) uses some kind of handshaking involving a shared secret or public/private key encryption. I don't think you can fully secure this, but security-by-obscurity could be enough to deal with attempts to cheat by people without the skills to reverse engineer the code.
But like Ewald says, any algorithmic process can be reverse engineered by someone who has sufficient control of the hardware it runs on. If the process needs to use a "secret" to operate, then that secret can be revealed.
I've found plenty in javascript etc, and for desktop-based ones in Java, but none for web-based java. Any ideas?
For comprehensive access to the Java Sound API, look to the javax.sound.sampled package.
See the Sound Trail of the Java Tutorial for details on how to use the API.
To record sound, the applet would need to be digitally signed (by you) and trusted (by the end user - when prompted at start-up).
Daniel made a good point about sound in web pages. Users generally hate it. Make sure your applet does not attempt to play any sound until requested by the user. Set the volume to a relatively low one.
I believe you can create an applet, which then is embedded into web page. And applets are capable of playing whatever you want, even without authorisation from the user (as far as I remember, it is allowed by JVM sandbox). Applet class even has dedicated method for this: Applet.newAudioClip .