I have written a program that can go out and check file version info for a particular file. This needs to happen on a large scale basis, something like 8000 computers or so. The way I've been doing it up until now is mapping the shared path I need to a drive letter, checking the required file, and then unmapping the drive. Each one of these shared areas requires the same username and password to be entered for security purposes. As you would imagine, mapping and unmapping the drive in order to check file version info slows my program down. So, I was wondering, is there any special way that is more efficient, and quicker to do this?
Keep in mind, this does have to go across a network, so I don't think it will ever be lightning fast but if someone could provide some design pointers for a better solution I would be all ears.
Thanks and I appreciate it! Or if anyone has heard of libraries which simply this process that would be great if you could share them. At the moment this is written in C#, soon to be re-written in Java.
Related
I hope you're doing well in these complicated times, good containment all around :D
So I come to my problem, currently I'm working on a game in Java and I know that it's possible to modify the jar file of my game which annoys me a little bit because it can give cheating possibilities for malicious players... I had thought of a solution even if it's not infallible, it would be to make sure to check if the jar file has not been modified. But the problem is that I don't know how to check this, I had thought of a system that would check the point of the file even if I doubt it would be the best solution.
If you have any other ideas to secure my game I would be interested :D
It is possible to check if a JAR file on your machine has been modified. Simply compare a cryptographic hash of the current JAR file with a previously recorded hash for a pristine copy. (Or just do a byte-by-byte comparison with the pristine copy.)
But you can't do this for JAR file on the user's machine:
You can't login to the user's machine and access their file system to look at the JAR file. (Even if you could, there is no guarantee that you would see the file that the cheater is actually using.)
If your application (running on the user's machine) tries to report on the integrity of its JAR files, this can be defeated by the cheater. All they need to do is to modify the JAR file containing the reporting code to report a fake hash.
Basically, there is no reliable way to detect that a cheater is running a modified JAR ... apart from detecting the anomalous behavior of the cheat itself.
But think of it this way. If there was a good (reliable, no circumvention) mechanism for detect that a cheater is running a modified client, then cheats would not be a problem in the many online games that exist out there. And (by extension) there would be no way to defeat software license enforcement schemes ... because software vendors would use a similar mechanism.
So, my advice would be not waste too much time on this approach. It only works against people with limited technical expertise or limited motivation.
The only way to completely prevent cheats is to control the platform on which the client runs. That is usually impractical.
In regards to your question about other ideas, the best thing you can do is validate everything from the client. One thing you should always remember is that the client cannot be trusted because you cannot verify anything from it. All you can do is store the state on a remote server and when the client tells you something, validate it, and give a response if necessary or prevent the action if necessary.
You will need to somehow find out where the jar file is: Java - Search for files in a directory
Then you can check for the last modified date of the file: https://www.boraji.com/java-get-last-modified-date-of-a-file
However, I would not consider this a very powerful defense against cheating, because one can modify the jar file and remove the validation of the file date.
You will need to think about the kind of cheating that can occur and to come up with other security measures as well.
EDIT
As Dave Thompson pointed out, the modified timestamp can be changed as well, which makes the modification of the jar file unnecessary, even though reverse engineering is still needed by the hackers, because that's how they find out what the rules of the application are.
I'm not sure if this question is entirely appropriate for SO but it seemed to work better here than in SuperUser so apologies if its in the wrong place. Happy to move it if so.
I'm trying to figure out how I'd automate the input of data into a system that didn't accept data uploads, but rather used forms put up on a screen. Use cases are e.g. where an enterprise wide system does accept uploads but the user lacks admin rights to fill in data she is required to populate, or with very old and specialized legacy systems where the functionality just doesn't exist and a serial input-review-rollback-commit cycle is enforced.
I'm not a programmer by trade so this is partly thought experiment but also to answer a question that has arisen at a business that I'm involved in.
I'm reasonably familiar with python and java if libraries for keyboard emulation exist but would be happy interpreting a pseudo code response too.
Responses that point to existing providers of such functionality that is embeddable or that tell me if I'm barking up the wrong tree also gratefully accepted.
Once again apologies as I know this isnt intuitively the best spot for this. Please do point me to a better location if you know of one.
Thanks
Possible solutions exist but they're all pretty bad
Is it a desktop application or a web application? If it's a web application you can use ghost.py to automate the interaction and submission of new records/entries. This work will be a glorious bundle of fun for the lucky code jockey who draws the short straw.
If it's a desktop application, it will be a great deal more difficult. Is it on Windows? Linux? MacOSX? Is the software written in Java? Using the Swing toolkit? AWT? SWT?
If it is a native Windows application you might be able to use Autohotkey to automate desktop interaction. This can be as basic as automatic clicks in pre-recorded parts of the screen, automating TAB keypresses to move around the input cells and reading input text from a data file and writing that out into the input cells. This will be even more entertaining than the web-solution mentioned earlier: truly the necessary ingredients for an authentic war story worthy of the annals of internet lore.
This is likely to be a lot of intricate work, error-prone, and subject to failure in the future if the UI of the software is changed; and such changes are very likely. It would be a lot easier to help if you could add more detail to the question.
Before embarking down this road, if I were you I would beg and plead with the software vendor to either provide me with an upload API; I would even offer to pay the vendor to upload my data for me. I cannot imagine either of the solutions I mentioned will be any cheaper, unless the work time of your developers has no value.
Good luck.
I'm currently working on a project in which I need to keep the user's files encrypted. This part I've achieved easily by using Java's built-in cryptography library. Loading the file from the disk is done by reading the salt from an attached file, having the user input the password, and then generating the salted and hashed key, which is then quickly disposed. But when it comes to saving the files back to the disk, a problem arises because I need to keep the key in memory throughout the whole runtime, or have the user input the password every time I write the file to the disk. What would you recommend in order to keep my application as secure as possible.
To be as secure as possible then your user should enter the password again. However really you need to look at the use-case and decide what you are defending against.
For example if they have to enter the password again then they are more vulnerably to someone shoulder surfing or key loggers, etc but the increased risk is pretty small.
The password kept in memory is only vulnerable to processes already running on the machine the software is running on. That again is a pretty small risk as it would probably be easier just for them to put a key logger on.
So really in this sort of scenario the main risk factors are the people. Can someone trick the person entering the password into revealing it (i.e. spear fishing, fake login prompts, key loggers, shoulder surfing). Mitigating most of those risks is about training, not about technical issues at all.
Far too many people think that a technical silver bullet can solve all their security woes. It really can't, a system is only as secure as its weakest link and you need to think about the big picture as well as the small one.
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 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.)