AutoPatcher For Game

09/30/2017 10:55 Goblousek#1
Hello how to i can setup my patcher for check new version of game files download and replace old files
09/30/2017 22:17 xShizoidx#2
You can create a version.txt at your local folder. You can also do the same on the FTP server. If there are deviations in the version number, you can compare the MD5 hashes of the files and download the files for which there are differences. If two files have the same MD5 hash, they are the same, otherwise not.
10/01/2017 01:07 warfley#3
Quote:
Originally Posted by xShizoidx View Post
You can create a version.txt at your local folder. You can also do the same on the FTP server. If there are deviations in the version number, you can compare the MD5 hashes of the files and download the files for which there are differences. If two files have the same MD5 hash, they are the same, otherwise not.
This is the right way, but i would recommend two things differently:
1. Don't use ftp, it's from the 80's and not really secure. Use either sftp or HTTP/2 (you could also use HTTP/1.1, but if you can, use HTTP/2)
2. Don't use MD5, this is also insecure. You can use SHA 256 or SHA 512 instead.

The second point is not so important, as you only need this checksum to check if the file changed, but don't start with using outdated software, it's not really hard to do it "the right way".

But the first point regarding ftp is important. An attacker could easily use the update function of your application to download and run malicious software on the target computer.

What i would do is distribute the files (zipped or uncompressed) over a HTTP server (Webspace) with a file containing the current version, and a summary of all files and their hash (e.g. SHA512). On startup of your program you download this version file (e.g. via curl) and read the version. Check if the version (number/identifier) matches your current version (or previous ones, but this is rather optional) if not start a separate program for updating.

The updater than downloads the list, iterates through all files, checks the hash, if it doesn't match the file, the downloader loads it, and replaces the existing one.
After that is done you start your main application again.

If you want to keep the updater updated, your main application could check (and download) the updater by adding a simple line with the updater hash to the version file.
10/01/2017 10:39 Underfisk#4
Also i advice you to pack your data in .dat or .py files to be secure and extract them, otherwise if you're planning to have some updates with some important data that is not encrypted and pack it on .zip or .rar it will be easy to be unpacked.
10/01/2017 11:55 xShizoidx#5
Quote:
Originally Posted by warfley View Post
2. Don't use MD5, this is also insecure. You can use SHA 256 or SHA 512 instead.
I know that MD5 is not secure when it comes to storing passwords. But since when is it unsafe to compare files only?
10/01/2017 15:47 warfley#6
Quote:
Originally Posted by xShizoidx View Post
I know that MD5 is not secure when it comes to storing passwords. But since when is it unsafe to compare files only?
Quote:
Originally Posted by Warfley
The second point is not so important, as you only need this checksum to check if the file changed, but don't start with using outdated software, it's not really hard to do it "the right way".
As I said, this is not really important, but using SHA should be the same workload as using MD5 (both should be just including a library, initialize the hash, update with data and than finalize the hash and get the data), and I think if you have both options, I would recommend using the not outdated software, so when he needs a cryptographically secure hash function (e.g. for passwords or for certificates) he already knows this.
MD5 is dead, and should better be forgotten.

Quote:
Originally Posted by Underfisk
Also i advice you to pack your data in .dat or .py files to be secure and extract them, otherwise if you're planning to have some updates with some important data that is not encrypted and pack it on .zip or .rar it will be easy to be unpacked.
Well this doesn't add any security. If he is using HTTP via TLS the data on the server is safe, and if he wants to protect it he could use basic authentication. While the data is transferred, using HTTPS or sFTP, the stream is encrypted, so adding another layer of encryption won't change much (it might even hurt the security). On the target machine it must be decryptable to be used, so the target machine knows the passphrase, and therefore it won't add security there either.
If you encrypt the data using an asynchronous algorithm like RSA you could ensure that the data is ensured to be from the right server, but sFTP and HTTPS do also take care of this using Certificates. As these Certificates can be proven with a trusted authority it's even more secure than everything he could implement by himself
10/01/2017 19:11 Underfisk#7
Quote:
Originally Posted by warfley View Post
As I said, this is not really important, but using SHA should be the same workload as using MD5 (both should be just including a library, initialize the hash, update with data and than finalize the hash and get the data), and I think if you have both options, I would recommend using the not outdated software, so when he needs a cryptographically secure hash function (e.g. for passwords or for certificates) he already knows this.
MD5 is dead, and should better be forgotten.



Well this doesn't add any security. If he is using HTTP via TLS the data on the server is safe, and if he wants to protect it he could use basic authentication. While the data is transferred, using HTTPS or sFTP, the stream is encrypted, so adding another layer of encryption won't change much (it might even hurt the security). On the target machine it must be decryptable to be used, so the target machine knows the passphrase, and therefore it won't add security there either.
If you encrypt the data using an asynchronous algorithm like RSA you could ensure that the data is ensured to be from the right server, but sFTP and HTTPS do also take care of this using Certificates. As these Certificates can be proven with a trusted authority it's even more secure than everything he could implement by himself
How said i was talking about protocols? You can use https and when you get the files into your pc and if you're using .rar or .zip or anything with protection i easy unpack it and doesnt matter what internet protocol you use!
10/01/2017 19:39 warfley#8
Quote:
Originally Posted by Underfisk View Post
How said i was talking about protocols? You can use https and when you get the files into your pc and if you're using .rar or .zip or anything with protection i easy unpack it and doesnt matter what internet protocol you use!
I just mentioned that you won't get any security out of this. On the server the data can be secured using basic authentication on HTTP or on sftp the default settings should do it. So no one without the passphrase can get it. The second voulnerable point might be the transfer, as an attacker who wants your precious data can eavesdrop your connection. But either sFTP as HTTPS prevent this by establishing a secure stream.
So the only possibility left to steal the data is on the target computer itself. As the target computer must have the passphrase to decrypt the data (otherwise the data itself would be useless). If the attacker has access to these files on your local machine, he should also have access to wherever the decryption password is stored (as this has to be stored to decrypt the data), so there you don't get any additional security. (This must not always hold true, for example on a *nix operating system you could have two users and messed up the permission settings of your folders, but this would require actively configuring your system to be insecure. This should be very unlikely)

So using a separate encryption does not add any security at any point of attack.

You could let the user type in the Passphrase, so only while he uses the computer you could access the data, but that would be a little bit counter intuitive regarding an automated updater
10/01/2017 22:41 Underfisk#9
Well even the best hard coded launchers such as blizz ones and some other ones, using .dat or other type of encrypted data they get extracted (not easy but they do) and yea https prevent's only the intervention on the data directly but its even possible to access it!
10/02/2017 01:40 warfley#10
Quote:
Originally Posted by Underfisk View Post
Well even the best hard coded launchers such as blizz ones and some other ones, using .dat or other type of encrypted data they get extracted (not easy but they do) and yea https prevent's only the intervention on the data directly but its even possible to access it!
Blizzards battle.net launcher uses afaik it's own protocoll (for updating) and therefore need to implement the security mesures by their own. You don't need to use https or sftp (which can diminish the overhead and gives them more flexibility) but instead you need to implement your own secure protocoll, and thats not trivial, and not a one man job (I dont know how many people work on the updater, but i would guess at least 6 fulltime developers).

But the folks at blizzard know what they are doing. If you are not an expert on cryptography you should rely on work by experts. For example one might think applying two time DES to an imput with 2 different passwords would strengthen the ecryption, but in fact 2 times DES is equal to only one encryption using a different passphrase (what really gets you more secure is using 3 Passwords, encrypt with pw1, decrypt with pw2 and encrypt again with pw3).

The problem is, 1 small mistake and all your security measures are useless. So if you are writing a protocoll just ask yourself the question: "Am I an expert on cryptography?" if the answer is yes, go ahead and implement your own encryption, if the answer is no, than just download the OpenSSL and use the TLS implementation which got tested by millions of users.

And with HTTPS or sFTP you dont even need to implement your own protocoll (which than uses OpenSSL internally). You just need to use the exsisting libraries like curl (or util apllications like wget), and don't even need to bother if you are using the SSL library correctly. This is basically idiot proove.
(Well untill you mess up the configurations on the host)
10/02/2017 08:07 Underfisk#11
Yup that's true but the security percentage are about 99% which means in 1% you can get a leak or someone mighty decrypt even the most secure protocol.
10/02/2017 10:52 florian0#12
No cipher is undecipherable. The security of a cipher is not defined by the obscurity of the algorithm. Its defined by the strength of the cryptographic function and the key. If you are one of the endpoints and the receiver of the message you have both, algorithm and key, which is the case for a patcher. In that case, the chances are a little higher than 1%. Lets say ... 100%.
10/03/2017 21:18 Dyck.#13
Quote:
Originally Posted by warfley View Post
2. Don't use MD5, this is also insecure. You can use SHA 256 or SHA 512 instead.
We're talking about a patcher. If he compares 1GB using SHA256/SHA512 his CPU will explode. MD5 is the right choice, CRC would be greater.

B2T: There are many tutorials here on elitepvpers about creating patchers, even already finished patchers are released here. Use the search-function.
01/19/2018 07:15 .Konst#14
Quote:
Originally Posted by warfley View Post
I just mentioned that you won't get any security out of this. On the server the data can be secured using basic authentication on HTTP or on sftp the default settings should do it. So no one without the passphrase can get it. The second voulnerable point might be the transfer, as an attacker who wants your precious data can eavesdrop your connection. But either sFTP as HTTPS prevent this by establishing a secure stream.
So the only possibility left to steal the data is on the target computer itself. As the target computer must have the passphrase to decrypt the data (otherwise the data itself would be useless). If the attacker has access to these files on your local machine, he should also have access to wherever the decryption password is stored (as this has to be stored to decrypt the data), so there you don't get any additional security. (This must not always hold true, for example on a *nix operating system you could have two users and messed up the permission settings of your folders, but this would require actively configuring your system to be insecure. This should be very unlikely)

So using a separate encryption does not add any security at any point of attack.

You could let the user type in the Passphrase, so only while he uses the computer you could access the data, but that would be a little bit counter intuitive regarding an automated updater
Haven't read any of the previous answers but it's recommended to use at least sha1 with file-hash comparing as md5's can match even with slight differences.
01/19/2018 07:38 Serraniel#15
Quote:
Originally Posted by .Konst View Post
Haven't read any of the previous answers but it's recommended to use at least sha1 with file-hash comparing as md5's can match even with slight differences.
Quote:
Originally Posted by warfley View Post
This is the right way, but i would recommend two things differently:
1. Don't use ftp, it's from the 80's and not really secure. Use either sftp or HTTP/2 (you could also use HTTP/1.1, but if you can, use HTTP/2)
2. Don't use MD5, this is also insecure. You can use SHA 256 or SHA 512 instead.

That was part of @[Only registered and activated users can see links. Click Here To Register...] īs first reply ;)