http://www.sc2mapster.com/maps/kyrptlib/
Hi:
After several fight with the "debug" function, I am finally done with my first lib.
With KryptLib u can encrypt string using a 16byte ASCII string.
16 byte password is a MUST.
The input data will be hashed with Hashlib 2.0.0.
A random salt 7-14 byte will be added.
After decryption, I use sha256 to validate the data.
The usage is really easy, because there is no init function.
The Program will auto init.
Exemple:
Variable-Setinput="Ich bin-gluecklich"//notice that password has 16 charsVariable-Setpassword="ICH23EDe3d7890hg"Variable-Setoutput=(<KryptCode>EncryptString(input,password))Variable-Setoutput=(<KryptCode>DecryptString(output,password))
If you don't know what it's for then you probably also don't need it ;)
It's used to encrypt or decrypt a string so another person can't read it anymore. You can store these strings in banks to make it harder for others to cheat your bank file.
Agreed, what is this for? What use could symmetric key encryption possible offer in an insecure session? If anything, using encryption in an insecure implementation just advertises it to hackers as a simple challenge.
EDIT: Now that I think about it, it is possible to have a secure two-way communication if PGP can be implemented and if Mapster is willing to host the accompanying web application. It does require some competence with the user though. I'll do some testing soon and report if it's feasible.
I'm not sure what you mean by 'sending a message to a friend". What I'm suggesting is that using a special scheme (assuming the hackers have not broken into the memory of the game) you can save data to the bank and be sure that it was generated during online gameplay and not during any other time unless the hackers had several players collaborate with them.
It involves on trusting that most players are legit and you have only a few hackers who would have difficulty convincing other's to colloborate with them. The implementation of the scheme has a lot of difficulties though (but as far as I know it's the only method I can think of that is fairly secure).
All the map needs to store is the public key of the server and each player to store and guard their respective password protected encryption keys which they use to sign data being generated at runtime.
Why this works? For instance, let's say Blizzard's bank verify works as follows: when you are on battle.net and save a bank, Blizzard generates a hash := hash(hash(UniqueMapId/Name) . hash(<Bank Data>)) and signs it with its private key. Now it becomes nearly impossible for the player to edit the bank after the map closes, since the signature is specific to that map and signed. You would need Blizzard's private key to effect any changes.
I don't know if this is how the verify function works, but I suspect it simply generates a hash key based on bank data alone (someone could check that).
Without a trusted party to sign the data, there is no way to know that it was generated within a legit game. Someone has to sign it and that leaves only the players. If every player in a game signs each other's banks and there are five players, you have five players that verify the game is legit. A hacker would need to compromise at least five accounts (or whatever the minimum is set to) to edit their data and call it legit.
Once you assign the keys (the biggest downside of this approach), you can't expect to store the public key of every player within the map. Instead a third party (your web server) will house them all and sign the data if all the signatures are valid. Thus the map need only hold the public key of the server.
Indeed if the server is the only entity that holds the public key of each player, then you can replace PGP signing with a symmetric key. Thus this eliminates the need to compute private key encryption in galaxy (which is not feasible). Public key encryption is feasible (I think) if the exponent is small (assuming RSA), so this method as a whole is computationally viable.
The verification with the server will either require the person saving the data to upload their bank file to the server for signing or have a program run in the background that will automatically do this. The latter method is simple to implement, won't step on Warden's shoes and is not too inconvenient. Distributing the private keys is the main hurdle as one must insure that each player receive their own key and verify that they own their respective battle.net accounts (this might require a chat bot).
Players can opt to cheat by collaborating and sharing their private keys, signing arbitrary data (if say you have five hackers working together). However, since the bank data must be uploaded to a server for signing, its contents can be read and cheating could be spotted. Cheaters can have their accounts banned. Banning is simple, since all the server has to do is refuse to sign the players' banks or sign it with a special key that indicates the player has been banned. This eliminates the need to store a 'banlist' anywhere in the map/banks. If multiple maps adopt this policy, then cheating in one map will result in being banned in all maps. Thus cheating is strongly discouraged.
I'm currently working on a system that allows a web service to process bank files, (much like SotIS) i came into the project behind previous people, and the current banks are encrypted with this library, I'm having trouble figuring out how to backwards engineer a decrypt-er, using just the Salt/Password i should be able to do this, but I'm still having difficulties. If you are still working on this, or have any pointers for me, let me know, i've been putting together a custom AES/SHA256 CTR system, but with no success decrypting the code.
http://www.sc2mapster.com/maps/kyrptlib/
Hi:
After several fight with the "debug" function, I am finally done with my first lib.
With KryptLib u can encrypt string using a 16byte ASCII string.
16 byte password is a MUST.
The input data will be hashed with Hashlib 2.0.0.
A random salt 7-14 byte will be added.
After decryption, I use sha256 to validate the data.
The usage is really easy, because there is no init function.
The Program will auto init.
Exemple:
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
http://en.wikipedia.org/wiki/Sha256
http://www.sc2mapster.com/maps/kyrptlib/
What is this for?
@gorang: Go
If you don't know what it's for then you probably also don't need it ;)
It's used to encrypt or decrypt a string so another person can't read it anymore. You can store these strings in banks to make it harder for others to cheat your bank file.
@gorang: Go http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
http://en.wikipedia.org/wiki/Sha256
Agreed, what is this for? What use could symmetric key encryption possible offer in an insecure session? If anything, using encryption in an insecure implementation just advertises it to hackers as a simple challenge.
EDIT: Now that I think about it, it is possible to have a secure two-way communication if PGP can be implemented and if Mapster is willing to host the accompanying web application. It does require some competence with the user though. I'll do some testing soon and report if it's feasible.
@SexLethal: Go tell me if u can use a map to send message to a friend. that is all i need to know.
@avogatro: Go
I'm not sure what you mean by 'sending a message to a friend". What I'm suggesting is that using a special scheme (assuming the hackers have not broken into the memory of the game) you can save data to the bank and be sure that it was generated during online gameplay and not during any other time unless the hackers had several players collaborate with them.
It involves on trusting that most players are legit and you have only a few hackers who would have difficulty convincing other's to colloborate with them. The implementation of the scheme has a lot of difficulties though (but as far as I know it's the only method I can think of that is fairly secure).
@SexLethal: Go
u want me save data of all player on all players sc2bank? using a random id for each player?
so that if a conflict happend, we can ban a player?
with confict i mean if someone have after 1 day suddenly 1000 kill more. the date should always be saved for each tag.
Well the concept could be used to be backstab people. because the map dont know who he should trust more.
It could help if u only save a few value, and have big space for that kind of thing.
and if i can hack the map to have read and write access. i can always generate a new id.
@avogatro: Go
No that's not it at all...
All the map needs to store is the public key of the server and each player to store and guard their respective password protected encryption keys which they use to sign data being generated at runtime.
Why this works? For instance, let's say Blizzard's bank verify works as follows: when you are on battle.net and save a bank, Blizzard generates a hash := hash(hash(UniqueMapId/Name) . hash(<Bank Data>)) and signs it with its private key. Now it becomes nearly impossible for the player to edit the bank after the map closes, since the signature is specific to that map and signed. You would need Blizzard's private key to effect any changes.
I don't know if this is how the verify function works, but I suspect it simply generates a hash key based on bank data alone (someone could check that).
Without a trusted party to sign the data, there is no way to know that it was generated within a legit game. Someone has to sign it and that leaves only the players. If every player in a game signs each other's banks and there are five players, you have five players that verify the game is legit. A hacker would need to compromise at least five accounts (or whatever the minimum is set to) to edit their data and call it legit.
Once you assign the keys (the biggest downside of this approach), you can't expect to store the public key of every player within the map. Instead a third party (your web server) will house them all and sign the data if all the signatures are valid. Thus the map need only hold the public key of the server.
Indeed if the server is the only entity that holds the public key of each player, then you can replace PGP signing with a symmetric key. Thus this eliminates the need to compute private key encryption in galaxy (which is not feasible). Public key encryption is feasible (I think) if the exponent is small (assuming RSA), so this method as a whole is computationally viable.
The verification with the server will either require the person saving the data to upload their bank file to the server for signing or have a program run in the background that will automatically do this. The latter method is simple to implement, won't step on Warden's shoes and is not too inconvenient. Distributing the private keys is the main hurdle as one must insure that each player receive their own key and verify that they own their respective battle.net accounts (this might require a chat bot).
Players can opt to cheat by collaborating and sharing their private keys, signing arbitrary data (if say you have five hackers working together). However, since the bank data must be uploaded to a server for signing, its contents can be read and cheating could be spotted. Cheaters can have their accounts banned. Banning is simple, since all the server has to do is refuse to sign the players' banks or sign it with a special key that indicates the player has been banned. This eliminates the need to store a 'banlist' anywhere in the map/banks. If multiple maps adopt this policy, then cheating in one map will result in being banned in all maps. Thus cheating is strongly discouraged.
@SexLethal: Go
if my map can communicate with a chat bot. i will not use a bank, just store all the score on the bot. and migrate all the check function on it.
The problem is u cant trust the player and u can't trust the message from the map u want me store the publickey on bot as identity validator?
But u can't communcate with a chatbot, sry
I'm currently working on a system that allows a web service to process bank files, (much like SotIS) i came into the project behind previous people, and the current banks are encrypted with this library, I'm having trouble figuring out how to backwards engineer a decrypt-er, using just the Salt/Password i should be able to do this, but I'm still having difficulties. If you are still working on this, or have any pointers for me, let me know, i've been putting together a custom AES/SHA256 CTR system, but with no success decrypting the code.