Sorry, tried looking for existing thread, lucked out.
Just curious if anyone has tactics to protect a vulnerable game client that basically all anyone has to do is use a flash decompiler to modify hacks into it. Does anyone know how I can upload the "legit" Flash client online and then people can ONLY connect to it by playing on the website its uploaded to, or by using the URL inside of flash projector? If they download the client and try to load it as a file then it rejects, i think its called a "domain lock" or something like that. Or if I can figure out a way for the client to be uploaded to my site, but IMPOSSIBLE to download off of it (like they cant just press CTRL+S and save the file to their desktop), that would be cool too.
Or if anyone has other suggestions involving hardcode to be placed into the C# server or the AS3 client.
Just please help if you can, most likely with that first part of the paragraph, that part seems like a solid plan, as long as they cant download the client, they cant modify it so then I wouldnt even have to care if they can connect or not.
You're focusing on the wrong problem.
You can do a number of things to make life difficult for someone trying to use an unauthorized client. You could, for example, embed a cryptographic one-time use token in the client that's good only for a given session and make the client encrypt any communication with the server with it- until the person designs a mod that downloads the client every time and extracts the token.
You can use javascript to try and make it non-trivial to download the client- until the user writes a Tampermonkey script that disables your protections.
Ultimately, if the code is running client-side there is literally nothing you can do to completely guarantee a determined actor won't be modifying it or even building their own client to connect to your servers. What you should be doing instead is working on your server code to detect actions that an unmodified client would never send. Treat all clients as untrustworthy and validate the data you're receiving from them. Assume your server is going to be receiving inputs that are completely unreasonable and handle edge cases accordingly. (Also, don't immediately assume the unreasonable inputs you receive are deliberate cheating- they could just as easily be the result of bugs in the client or even faulty hardware on the user's end.)
Related
Alright, so I'm creating an application, and in it, the clients need to communicate with the server as soon as it launches. So I have two ideas for this. (A) I could have it so that the client sends a message to the server using TCP/IP to tell it what it needs, and the server sends that back over the connection, or the client just downloads a file from a web server.
Since both are transferring the same file over the network, both should be the same speed right? Well I don't know, that's why I'm asking. And I know that somebody will probably say "oh well try it yourself", and I'm sure I could if I got a runtime operation and used that with both, but I don't have my server set up yet, and I would change how it operates severely if I knew ahead of time.
So, is it faster to download from a web server, or contact a server and have it send the information over? And if there's any better idea as for getting info from the server, let me know!
Your two operations are; from a network perspective, identical:
Client establishes TCP socket to server
Client sends request for file
Server responds with file
Using HTTP as the format of the request doesn't change the nature of the operation. You do have to deal with the overhead of going through the web server logic, but that is almost certainly negligible in comparison to the actual network operation.
I have the following concern about security in server-client models...
Imagine the following:
I have an C# WinForms client that wants to communicate with a server (PHP GET-POST Requests, Socket or WebSocket in a Console App C# (Net Framework) running on a Debian under Mono, instead of using ASP.NET).
The first problem that arises is that whether the server (written in PHP or C #) must have some kind of control for the anonymous requests that the client generates, for this, we will have to use some type of token generated by the server to every request.
The problem isn't related to the token (my plan is to use HTTPS (PHP) or SSL / TLS + Certificates in WebSockets (C#) for client-server communications at the network level, to avoid Spoofing or MitM).
The problem arises when the server has to give to a "client" (we need to check its validity, that the main concern) a token to allow the client do requests. It would be very easy to any client to give a token from the server (How? Replicating (inverse ingeenering) a client that makes requests to the server to try to obtain valid tokens, at least, as I plan to implement it, hence the need for help).
In what I was thinking, is to generate a md5 or sha hash for the assembly file of the client. So, if anyone tries to replicate those steps, it will be difficult. Because he/she will need to modify the source code of the assembly or make a malicious assembly and obtain the same hash by collision (this is difficult).
I do not know how efficient is this system, so I need you to guide me a bit in this aspect.
I've been looking at OAuth, and I think that this type of implementation is not the one I'm looking for, because this kind of implementations is for the user level (to avoid that another user violates the main user data), not for the client (application).
So if someone can guide on this issue it would be of great help.
You can't authenticate the client, it is not possible. Anything in the client is known to the user (attacker), any secret, anything you have there. The only question is difficulty, but anything you do, it will not be very difficult.
Also in your hashing scheme, what would you do with the hash, send it to the server? Why would a different client have to match the hash, when it can send whatever it wants (ie. the correct hash, as sniffed from the network)?
So again, because the software needs to run on the client machine, anything that runs there or is sent on the network is disclosed to the user, and he can replicate it in a different client. It is not possible to securely prevent this. Also ssl/tls doesn't help here, if you control one of the endpoints (ie.the client).
Imagine if it was possible somehow, software piracy would not be a thing - but it very much is.
I have been looking but cannot find a good answer that can help me in my case. To explain the situation, I am creating a Unity3D game which will have a multiplayer system. In order to keep the player data as secure as possible (so people doesn't cheat easily), I decided to implement a Web API 2 service that connects to a SQL Server database. I designed the Web service in such a way that only if the request contains specific data the request is processed. What I am now having problem is to design a solution that will let me send/retrieve data from the web service. I implemented SHA-512 to send the password so packet sniffers wouldn't get it in plain text, and I am planning to implement HTTPS but Unity classes makes it very hard. I thought of implementing RijdnaelManaged as a more secure algorithm for the accounts but in Unity the code is easily reverse-engineered.
Would this model be secure enough to stop script kiddies from hacking player accounts?
HTTPS
I implemented SHA-512 to send the password so packet sniffers wouldn't get it in plain text,
That's not helping for as far as your webservice goes, it now uses the hash as its password, so anybody sniffing it will still capture it.
Use https, not http to get it right.
If you really cannot: build a system where the service first issues a challenge, and where the client then "signs" that challenge and sends the signature back. That's still by far not as good as https, but it'll prevent a few things (but not e.g. a man-in-the-middle attack).
Security
If you look at analyzing the risks, you need to take care to address users of your game as well as 3rd parties.
The 3rd parties, with good passwords (good luck with that) or proper 2 factor authentication, https etc. you can cover the bases rather well. Add in some security in the webservices and you should be a good way along the path.
But you also have to deal with users of the game. And that's harder than it might seem as they could run your game in a debugger and figure out how the game communicates with the server and what it sends when, what the effects are of that etc. Nw if you have a multi-player game typically that involves virtual goods and/or currency that can be obtained and/or traded. Devious players will try to get it the easy way, so you need to protect somehow against that as well.
The easiest to do that is to move the game logic into the server and use the client only for visualizing things - but that obviously means you make much more use of server resources ...
Trusting your client is running, unmodified, and you're talking to it: you can't ...
:)
I want to create a webpage with encrypted text on it which a C# program can decrypt. Could I do this?
I have a WebBrowser on a C# form which loads a page and displays a serial code. I don't want anyone to find out this code, therefore that's why I thought about encrypting it. Maybe there's a better way to do this?
Thanks! :)
Do you mean serial code literally, as in a key for some software that should only be viewable by the intended recipient? If this is the case then kudos for putting more thought and effort in, many places send these around unencrypted.
The answer really is that you need SSL. You need the end-user to be able to read it, so they must have all the information necessary to decrypt it. This means you need an encryption method which still works if someone is listening in (if no one is listening in, why are you encrypting it?), so you must either pre-exchange keys or some secret, use public key cryptography, or use something like D-H key exchange.
The only option that's secure if a third party could make changes to your communications as well as eavesdrop on them is if there is some authentication outside the system, or some transitive trust mechanism. Security certificates for SSL perform this exact function.
You could do this all yourself, but you would be reinventing a whole stack of technologies that's present in every web browser. Buy a cert, send the page over SSL.
So I'm working on a project for my internship and have hit a bit of a brick wall. Unfortunately, the only people I know who are qualified to help me at the office are on vacation at the moment, and Google has been unfortunately unhelpful (or my search skills inadequate), so I thought I'd ask here.
The project is basically to make a server to mimic one that the company (which makes phone apps) already has. What I need to do is have one of their apps send a request to my server (I will have to modify the app to do this, but don't know how), and have my server reply with an XML response that the app already knows how to process. (The main purpose is so that we can see how the app responds when the real server sends it an error by simulating it on my server.)
Now, I already have a few sample HTTP requests and their associated XML responses handy, taken from simulations with the app and the real server. The app is written in C#, and currently sends HTTP web requests to the real server's online location, which responds to these HTTP web requests with XML. My server, however, will not have an online location, so the app will have to be modified to work with sockets on a local host.
My questions:
1) My boss said to create an XML file to associate certain requests with certain XML responses, but I have no idea what he means or how to do this. (He said it could also be done with a .ini file.) Does anyone know?
2) Once I have this XML file that can make these associations, how can I incorporate it into my server so that my server can check the request it received against its table of valid requests and figure out which response to send back?
3) How can one modify the app from using HTTP web requests and responses to using sockets?
If you have any questions/clarifications that you need in order to better answer this, please don't hesitate to ask me.
Thanks!
What you're describing is a web service. Unfortunately, his advice to change a setting in an .ini file make it sound like they have a proprietary system for doing this, rather than using a standard ASMX (which requires IIS) or WCF (which can either run in IIS or as a standalone service, which it sounds like is what you'd want) service.
Without more information about what they're using, I don't know that you'll be able to get much help here.
In response to question #3:
HTTP is a protocol that already runs on a specific socket (normally using port 80).
An internet socket is an endpoint that is used to transport data between processes. If you want to run your own protocol, you will need to create a new socket (with TCP or UDP) on a specific port.
This will however require you to create your own client and server in order to exchange data between them.
To get started, here is a very simple client-server example in C# using a custom socket.
Good luck!
Ask your boss if this client communicates with soap, if so then just go to MSDN and find tutorials on implementing an ASMX webservice, follow the tutorial through and you'll have a shell to start with.
First I'd like to say that it sounds like you have some unclear requirements that you should probably clarify with your boss. If you're not exactly sure what he means you should find out because nothing sucks more than having to support someone's creative interpretation of requirements.
1) It sounds like your boss just wants a way to easily change associations for testing without having to rebuild the app so he's asking you to store those associations in an xml/ini file that can easily be modified. In c# you can easily go between XML and DataSet objects so this should be trivial. I would create the data structure in a DataSet first and then use the GetXml method of the DataSet to output the xml format.
2) In .NET you can store objects in Cache and create a Cache Dependency that is a file association. Thus whenever the file is modified the Cache is purged. Whenever your program handles a request it pulls the object from Cache, if the object isn't in Cache then you have a condition block rebuild it from the xml/ini file on disk. I would have that condition block call out to a function that then loads the above mentioned xml format into a dataset that is then stored in the Cache with a Cache Dependency.
3) If you are trying to test an applications i/o, modifying it to use a different transport layer sounds like a bad idea. If the app currently works over HTTP to send requests then just route the HTTP request. I would suspect that the app probably has a configuration somewhere defining the path of the webservice it currently calls out to, once you know what that path is you can either change it, or if that's not possible setup a DNS rule on the server running the app to route it to the location of your application. On windows this is as simple as adding a line to the hosts file.