Script is nicer than GUI but so bare bones it's painful at times. Imagine if script had auto completion, meaningful namespaces and on the fly syntax checking! (lets hope Andromeda and the custom editors deliver)
With script you can initialize all your triggers and variables after map init (well most of them).
I've been thinking of a protocol aimed at addressing the problem of bank security. I present StarFriend. StarFriend is designed to ensure banks are generated during online gameplay and not edited afterwards. StarFriend is not an encryption protocol, but an integrity check producing a signature similar to the bank verify function, but unlike the bank's signature a StarFriend signature can only be generated during online gameplay with other players. This means a player can't make a hacked copy of the map and save their own changes locally.
The principle behind StarFriend is that no third party exists during gameplay to sign bank data. Thus players are free to alter banks after gameplay has ended. StarFriend asks players in the game to sign each others data. Thus the players in the game (your ‘friends’) vouch that the bank was generated during gameplay by signing it with their secret keys. This means that a potential cheaters needs to have compromised the accounts of a certain minimum number of players before they can break StarFriend. StarFriend addresses this problem through the use of session keys, keeping each individual player’s secret key safe. Since session keys expire after one use, even if it is stolen through the use of a memory editor, it becomes useless. Only players that collaborate with each other can break StarFriend by sharing their secret keys. In this case, when caught, all the cheaters are exposed from one offense.
In addition, StarFriend can facilitate a banning procedure that does not require the map to store any information about the offenders. If the protocol is implemented across many maps, an offense in one map can ban players across all the maps that use StarFriend without the need to cross communicate. It can prove to be an effective deterrent since cheating is difficult, can be traced and the offenders quickly banned without the need to update any data between maps.
StarFriend is not implemented yet and there are several difficulties that must be overcome before it can come into effect. This is an overview of the protocol.
Please refer to the figure for details.
1. An external server must assign each player who uses StarFriend a secret key. This key is only known to the server and the player and is never revealed. It will most likely exist in an encrypted form on the hardrive of the player, whose security is overseen by a third party program. The secret key is unique to each player and it is important that the owner of the StarCraft 2 account name is assigned the right key and its security protected. The secret key only has to be assigned once.
2. The third party program will then periodically create session keys signed with the player’s secret key. These are written to a bank file so that they may be accessible during gameplay. The game will never have access to the secret key and it is infeasible to guess the secret key from the session key. Only the player and the server know if the session keys are valid as this requires knowledge of the secret key.
3. During gameplay, the game will generate data to save into the bank. Once the bank file must be saved, a digest is generated.
4. The hash is signed by the session keys of the other players in the game to form the authentication certificate. This is the key step that ensures the bank file is valid, since outside of the game, the player won’t have access to the session keys of the other players. A copy of this certificate is also kept with each of the other players. These are all then saved to a bank and an external program sends these to the server. Alternatively, the entire bank may be sent to the server, so the server can gather information about the player’s session (also useful for tracking cheating).
5. The server will then verify the session keys of the other players to see that they are still valid. The server will also check if the session key has been used before. If the signatures are valid and match the certificates the other players sent (if they are sent), the server will sign the certificate with its own private key (known only to the server). The public key is stored in the map. The signed bank will then be returned to the owner, most likely done by a third party program. If the player is banned, the server will refuse to sign the bank, or sign it in a way so the map will know the player was banned and display the appropriate message.
6. When the player wishes to play again, the map will check with the server’s private key to see if the bank has been signed. If the signature is valid, the player is authenticated.
As can be seen, the only information the map needs to store is the public key of the server. The security of this system mainly relies on the integrity of the secret keys. It only works if the majority of people are non-cheaters and keep their keys safe. Since everyone in SC2 can have only one active username per account and the price of cheating is being banned, this is not hard to imagine.
As for the feasibility of this protocol to be used in game, several factors must be considered. First is the distribution of secret keys. These are player specific, so there must be some way to authenticate each player. One way might be through a chat bot, similar to how people sign up for accounts on IRC channels. The player could be given a password that allows them to connect to the web server to retrieve their secret key.
The generation of the session keys and server signing the certificate can be all handled seamlessly with an external program that modifies bank files. Since bank files are only loaded into the cache at map init, modifying them at runtime should not affect Warden. This program does not rely on modifying or reading any game memory. Writing the program itself is trivial.
The protocol will require several security algorithms, including a hash function, and assymetric key encryption. The computational cost must be taken into account. For the generation of the digest, sha-256 will most likely be applied on the contents of the bank. Verification of the certificate returned from the server will require assymetric key encryption. This will most likely be RSA, using a very small exponent (3) and a 1024-bit key if possible. Signing of the hash by the players can be done using AES-256, since the session keys are unknown to the other players and can be generated by the server if the seed for the key’s generation is also sent. Overall this might cause a bit of lag, but should be feasible.
Thus the only overhead for a player wishing to use StarFriend is registering for a key and having the program run in the background (which does not hack into the game). And all the map maker needs to have is the StarFriend library (yet to be written) along with the server’s public key.
tl;dr: StarFriend provides good security against tampering with banks. Requires running some programs in the background and can’t be implemented just yet due to problems of secret key distribution.
How can it possibly be save when this hash is stored INSIDE the bank?
UNLESS it doesn't only hash the stuff in the bank but also something from the map (like a unique ID).
Even if it hashes a unique ID, that can still be broken. Blizzard needs to sign the hashkey (only possible during online play) for it to be secure. Encryption is bullshit without a trusted signature.
If they can drink poisoned well water before the duel, the dragon always lives since he can drink well 5, drink anything the knight gives him and then drink well 6. The dragon doesn't know what the knight drank before the duel though, so there's no way to decide with certainty what drink the dragon should serve the knight.
If they can't drink poisoned well water before the duel, then the knight will always die from well 6 and the dragon's fate is undetermined.
No actually I never heard of either of those. I'm not a poison expert nor did I claim to be one. However in general i've never heard of poisoning someone with just plain poison to cure them. And I'm not saying it's impossible but i'm sure its not as common as you make it sound... But what I meant was that it's like saying you take poison ivy and cure it with more poison ivy.
Atropine toxicity is treated with physostigmine. Physostignmine is administered until symptoms of physostigmine toxicity start to show. If too much is given, it in turn is treated with atropine.
Atropine blocks acetycholine receptors, resulting in less acetylcholine activating its receptor. Deadly in large amounts. Physostigmine blocks acetylcholinesterase: an enzyme which destroys acetylcholine, resulting in too much acetylcholine activating its receptor. Deadly in large quantities. The effects are polar opposites, even when the intial intoxication is very large.
This is a classic textbook example though, it doesn't quite work this way for most things (but surprisingly a large amount of everyday toxins are cholinesterase inhibitors. But don't try this experiment at home!).
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.
What if a game company like Valve put resources (alot!) to develop a free popular SC2 map (lets say Valve Dota!) which mentions the company (or at least that the maker of the map is from Valve) that created it.
Would Blizzard remove that map under the no advertising rule?
EDIT: Hey! Who wants to play a little April Fools joke on Blizzard? *chuckle*
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).
Do you plan to publish on battle.net a game containing Muslims, Christians and pagans all on the same map (bonus points if they're duking it out)? Gooood luck.
In theory trigger[500] should not be any much larger than int[500], as it's only storing a reference to a trigger (which is say different from a record array, which actually allocates your struct). I don't see it as any big memory hogger. The 500 triggers that you assign to it on the other hand...
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 know. But, how would you retrieve the UI coordinates of the image bounds if it is different at each resolution? As far as I know, there is no way to retrieve in-game values of a dialog from a player's perspective.
Look at the map I posted (if you can). No matter what resolution you choose, if you clicked the targets accurately, the image of the cursor will always appear where you click. In essence, it estimates your resolution by sampling your clicks and adjusts accordingly. You can make it more accurate by rounding to the nearest valid resolution and also the number of checkpoints can be reduced to just 1.
As a side note, you mentioned mapping world coords to UI. This is actually possible to some extent. Early in beta I created a mouse tracker, which works by enabling mouse look to a small extent and moving a fake cursor on the screen based on how much the camera rotated. The fake cursor would then be projected from the UI down onto the world (it worked great back then, but was broken by a patch affecting retrieving yaw/pitch in late beta that was never fixed). The reverse should work without any flaws (although I never implemented camera roll to be taken into account).
This reminds me of a problem I had long ago, where the position reported by clicking on the UI was different than the one used by dialogs and depended on resolution.
Try creating invisible neutral units (with a large sight radius) at regular intervals in the area of the cone in front of your unit and testing whether the neutral unit has sight of your unit. This should allow you to determine the blind spots in the cone. Then for the units that have vision, replace them with a small visibilty modifier to fill the visible portions of the cone.
0
Script is nicer than GUI but so bare bones it's painful at times. Imagine if script had auto completion, meaningful namespaces and on the fly syntax checking! (lets hope Andromeda and the custom editors deliver)
With script you can initialize all your triggers and variables after map init (well most of them).
0
I've been thinking of a protocol aimed at addressing the problem of bank security. I present StarFriend. StarFriend is designed to ensure banks are generated during online gameplay and not edited afterwards. StarFriend is not an encryption protocol, but an integrity check producing a signature similar to the bank verify function, but unlike the bank's signature a StarFriend signature can only be generated during online gameplay with other players. This means a player can't make a hacked copy of the map and save their own changes locally.
The principle behind StarFriend is that no third party exists during gameplay to sign bank data. Thus players are free to alter banks after gameplay has ended. StarFriend asks players in the game to sign each others data. Thus the players in the game (your ‘friends’) vouch that the bank was generated during gameplay by signing it with their secret keys. This means that a potential cheaters needs to have compromised the accounts of a certain minimum number of players before they can break StarFriend. StarFriend addresses this problem through the use of session keys, keeping each individual player’s secret key safe. Since session keys expire after one use, even if it is stolen through the use of a memory editor, it becomes useless. Only players that collaborate with each other can break StarFriend by sharing their secret keys. In this case, when caught, all the cheaters are exposed from one offense.
In addition, StarFriend can facilitate a banning procedure that does not require the map to store any information about the offenders. If the protocol is implemented across many maps, an offense in one map can ban players across all the maps that use StarFriend without the need to cross communicate. It can prove to be an effective deterrent since cheating is difficult, can be traced and the offenders quickly banned without the need to update any data between maps.
StarFriend is not implemented yet and there are several difficulties that must be overcome before it can come into effect. This is an overview of the protocol.
Please refer to the figure for details.
1. An external server must assign each player who uses StarFriend a secret key. This key is only known to the server and the player and is never revealed. It will most likely exist in an encrypted form on the hardrive of the player, whose security is overseen by a third party program. The secret key is unique to each player and it is important that the owner of the StarCraft 2 account name is assigned the right key and its security protected. The secret key only has to be assigned once.
2. The third party program will then periodically create session keys signed with the player’s secret key. These are written to a bank file so that they may be accessible during gameplay. The game will never have access to the secret key and it is infeasible to guess the secret key from the session key. Only the player and the server know if the session keys are valid as this requires knowledge of the secret key.
3. During gameplay, the game will generate data to save into the bank. Once the bank file must be saved, a digest is generated.
4. The hash is signed by the session keys of the other players in the game to form the authentication certificate. This is the key step that ensures the bank file is valid, since outside of the game, the player won’t have access to the session keys of the other players. A copy of this certificate is also kept with each of the other players. These are all then saved to a bank and an external program sends these to the server. Alternatively, the entire bank may be sent to the server, so the server can gather information about the player’s session (also useful for tracking cheating).
5. The server will then verify the session keys of the other players to see that they are still valid. The server will also check if the session key has been used before. If the signatures are valid and match the certificates the other players sent (if they are sent), the server will sign the certificate with its own private key (known only to the server). The public key is stored in the map. The signed bank will then be returned to the owner, most likely done by a third party program. If the player is banned, the server will refuse to sign the bank, or sign it in a way so the map will know the player was banned and display the appropriate message.
6. When the player wishes to play again, the map will check with the server’s private key to see if the bank has been signed. If the signature is valid, the player is authenticated.
As can be seen, the only information the map needs to store is the public key of the server. The security of this system mainly relies on the integrity of the secret keys. It only works if the majority of people are non-cheaters and keep their keys safe. Since everyone in SC2 can have only one active username per account and the price of cheating is being banned, this is not hard to imagine.
As for the feasibility of this protocol to be used in game, several factors must be considered. First is the distribution of secret keys. These are player specific, so there must be some way to authenticate each player. One way might be through a chat bot, similar to how people sign up for accounts on IRC channels. The player could be given a password that allows them to connect to the web server to retrieve their secret key.
The generation of the session keys and server signing the certificate can be all handled seamlessly with an external program that modifies bank files. Since bank files are only loaded into the cache at map init, modifying them at runtime should not affect Warden. This program does not rely on modifying or reading any game memory. Writing the program itself is trivial.
The protocol will require several security algorithms, including a hash function, and assymetric key encryption. The computational cost must be taken into account. For the generation of the digest, sha-256 will most likely be applied on the contents of the bank. Verification of the certificate returned from the server will require assymetric key encryption. This will most likely be RSA, using a very small exponent (3) and a 1024-bit key if possible. Signing of the hash by the players can be done using AES-256, since the session keys are unknown to the other players and can be generated by the server if the seed for the key’s generation is also sent. Overall this might cause a bit of lag, but should be feasible.
Thus the only overhead for a player wishing to use StarFriend is registering for a key and having the program run in the background (which does not hack into the game). And all the map maker needs to have is the StarFriend library (yet to be written) along with the server’s public key.
tl;dr: StarFriend provides good security against tampering with banks. Requires running some programs in the background and can’t be implemented just yet due to problems of secret key distribution.
0
Even if it hashes a unique ID, that can still be broken. Blizzard needs to sign the hashkey (only possible during online play) for it to be secure. Encryption is bullshit without a trusted signature.
0
If they can drink poisoned well water before the duel, the dragon always lives since he can drink well 5, drink anything the knight gives him and then drink well 6. The dragon doesn't know what the knight drank before the duel though, so there's no way to decide with certainty what drink the dragon should serve the knight.
If they can't drink poisoned well water before the duel, then the knight will always die from well 6 and the dragon's fate is undetermined.
Atropine toxicity is treated with physostigmine. Physostignmine is administered until symptoms of physostigmine toxicity start to show. If too much is given, it in turn is treated with atropine.
Atropine blocks acetycholine receptors, resulting in less acetylcholine activating its receptor. Deadly in large amounts. Physostigmine blocks acetylcholinesterase: an enzyme which destroys acetylcholine, resulting in too much acetylcholine activating its receptor. Deadly in large quantities. The effects are polar opposites, even when the intial intoxication is very large.
This is a classic textbook example though, it doesn't quite work this way for most things (but surprisingly a large amount of everyday toxins are cholinesterase inhibitors. But don't try this experiment at home!).
0
@zeldarules28: Go
Have you tried setting camera distance to 0?
0
@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.
0
I've noticed since beta that ELIZA is at least partially coded for in the battle.net dll (or in one of the other dlls)
Does this mean that actors rotate properly now from actor messages? I believe there was a problem with the up vector being non-functional.
0
What if a game company like Valve put resources (alot!) to develop a free popular SC2 map (lets say Valve Dota!) which mentions the company (or at least that the maker of the map is from Valve) that created it.
Would Blizzard remove that map under the no advertising rule?
EDIT: Hey! Who wants to play a little April Fools joke on Blizzard? *chuckle*
0
@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).
0
@TwoDie: Go
Do you plan to publish on battle.net a game containing Muslims, Christians and pagans all on the same map (bonus points if they're duking it out)? Gooood luck.
0
In theory trigger[500] should not be any much larger than int[500], as it's only storing a reference to a trigger (which is say different from a record array, which actually allocates your struct). I don't see it as any big memory hogger. The 500 triggers that you assign to it on the other hand...
0
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.
0
Look at the map I posted (if you can). No matter what resolution you choose, if you clicked the targets accurately, the image of the cursor will always appear where you click. In essence, it estimates your resolution by sampling your clicks and adjusts accordingly. You can make it more accurate by rounding to the nearest valid resolution and also the number of checkpoints can be reduced to just 1.
As a side note, you mentioned mapping world coords to UI. This is actually possible to some extent. Early in beta I created a mouse tracker, which works by enabling mouse look to a small extent and moving a fake cursor on the screen based on how much the camera rotated. The fake cursor would then be projected from the UI down onto the world (it worked great back then, but was broken by a patch affecting retrieving yaw/pitch in late beta that was never fixed). The reverse should work without any flaws (although I never implemented camera roll to be taken into account).
0
@desiderius1: Go
This reminds me of a problem I had long ago, where the position reported by clicking on the UI was different than the one used by dialogs and depended on resolution.
My solution to it looked similar to the following MouseUIGameUI.SC2Map
0
@Shouchen: Go
Try creating invisible neutral units (with a large sight radius) at regular intervals in the area of the cone in front of your unit and testing whether the neutral unit has sight of your unit. This should allow you to determine the blind spots in the cone. Then for the units that have vision, replace them with a small visibilty modifier to fill the visible portions of the cone.