The simple Cipher system is a library created by me to encode strings. And pretty much anything of worth in the trigger editor can be converted to and from a string.
Why not use Starcode?
I used to use starcode as my encryption library but I had a couple reasons why I wanted to make my own:
I cannot comprehend the coding behind it and I like knowing what my code does.
I didn't need anything as vast and complex as starcode.
If you want to go use starcode feel free, this is just an alternative.
Why use this?
It's relatively simple to use, just import the library, and use the functions as outlined under function documentation.
It's small and despite its name it is not an easy to crack cipher system.
Encrypts on a per player basis so no 2 players will have the same encryption. This prevents bank sharing.
Function Documentation
Function: Set Player Code (Player<integer>, Code<string>)
Allows you to set the code for a player, use prior to set player version# if both are used.
Function: Set Player Version# (Player<integer>, Version#<integer>)
Allows you to set a Version# for a player.
Warning: use after Set player Code if used, also will reset banks, you may want to use a system of checking their current version.
Library defaults to version 1
Check the check sum of a string to make sure that it wasn't modified.
Function: Remove Checksum(String<string>)
Removes the appended checksum from a string.
Installation
Open map editor
Open Map
Open Trigger Editor
Data->library->Import library
Select Simple Cipher System
*poof* it appears in your trigger editor
Known Issues
The alphabet key does not use the ~ \< characters
\ because it's the escape key
< because when combined with > can cause trouble displaying the output
~ because it is reserved for separating the checksum
So what security standards does this implement? What proof do you have that it is secure? What proof does your checksum algorithm have for having a low chance for collisions? How is cross-region support achieved?
I would not advise the use of any code system which does not use properly proved encryption and cryptographic hashes. After all what is the chances of you doing something better than technology proved by dozens of researchers and used commercially?
For example my Imperial Bank system uses SHA-1 160 bit cryptographic hashes (I am aware that they are "theoretically" insecure but for a SC2 bank it should be more than sufficient) and an AES based encryption algorithm with (160 bit keys with interpolated round number so not standard as the standard only defines 128, 192 and 256 bit keys). All you need to do is put the two together (so encryption key is based on the cryptographic hash) and you have a highly secure form of data encoding. A single bit change will result in a completely different string being generated.
@ImperialGood: Go
Security Standards: Mine. It's not easy to crack, but definitely possible. I'm not at the level of programming AES encryption systems (unlike someone), I'm a freshman in college, and I've literally taken one computer science class and that's it (and it was freshman year in highschool to boot). I just have fun programming in SC2. That being said, if you want to make a tutorial on creating your own AES system (or upload your's as a library), i'd be more than happy to try and learn from it how to program one.
Proof: None, however if they make it past blizzards bank signature, they're more than likely to make it past my coding like you said "for a SC2 bank it should be more than sufficient". Plus anyone who's willing to go that far for one map.
Collisions: ? If you mean getting confused with what is the original encrypted data and what isn't, that's the reason the ~ character was reserved for it.
Cross region support: Only publish to NA haven't finished a map worthy of being cross region published yet.
Chances: slim
Yes this bank could be coded way better, by people who are a lot smarter than me (hence we have starcode), however I wanted a code system i could use in my maps that I could understand. I don't like using code that I can't comprehend how it works. I have never claimed that this is the most secure system out there
It's small and despite its name it is not an easy to crack cipher system.
I say it isn't easy to crack (which admittedly it isn't), but it is possible to crack. So thank you for helping me to clear up that with anyone who may download it in the future. (Although pending that AES coding tutorial from you it could get way better). If you want to go cracking this library for me and then post what you did to crack it (and what you coded to crack it), and show how weak it is then by all means go for it, in fact I encourage it, I may not be aiming to try and get a degree in C.S. right now, but I definitely wouldn't mind learning more.
Edit: Before I forget to ask, are you related to DrSuperGood at all, you guys have the same avatar?
Edit: Before I forget to ask, are you related to DrSuperGood at all, you guys have the same avatar?
I am one the same. I am related to another person here though (not that it is hard to guess).
Quote:
That being said, if you want to make a tutorial on creating your own AES system (or upload your's as a library), i'd be more than happy to try and learn from it how to program one.
In theory there is no need for such a document seeing how all resources about AES and SHA, including official specification documents, are available online free of charge. SHA is nothing more than implementing pseudo code or porting a C implementation. AES is a lot more tricky as it is a lot more complex (specifically the finite field theory used for re-combination of block columns).
I will eventually upload it as a library (I need to remove my private keys from its workings) however currently there are no GUI interfaces for it so most people will probably have difficulty using it. There are also possible op-limit concerns (which apply for your system as well?) for larger data blocks.
Quote:
Collisions: ? If you mean getting confused with what is the original encrypted data and what isn't, that's the reason the ~ character was reserved for it.
I am referring to hash collisions where 2 different blocks of data generate the same hash value. In the case of cryptographic hashes such as MD5, SHA-1 etc it is important that this is as low as possible. If the probability of collision is practically impossible then you can use the hashes alone as a way to uniquely identify data (how Blizzard's CASC archive system operates that will replace MPQ with SC2 3.0). Since it gives a pretty unique identification with low correlation between input and output you can also use them to verify the integrity of data (since a single bit change will generate something completely different). You can think of them as sort of "checksums" however in theory a checksum means something completely different and far less secure. They are a very good base for an encryption key since a single bit change in input data will result in a completely different output and a single change during decryption will cause a hash mismatch error. By using this you can make every encrypted bit + hash depend on every decrypted bit. Since standard algorithms are easy to engineer, you make the connecting logic complicated adding constants, recombination of values and bit rotates when computing the keys (since the combinations in this step are practically infinite). Additionally you round to "next block" in output length to hide the physical length of the data contained with padding (a few characters do not mater).
Here is an example of one of the output strings I get using the above method. This alone is not sufficient to decrypt however since it also depends on an archive block and bank identifier. Remember that a single bit change will cause a completely different string.
Since I know the hash is always exactly 160 bits I do not need a "~ character" to tell when it starts/ends.
Quote:
and show how weak it is then by all means go for it
I am not trying to prove how weak it is. I am just stating that you have no evidence that it is strong. It could be very secure and practically impossible to crack or it could be very easy and people could crack it in under an hour (without resorting to reverse engineering) however you have no proof as to which it is. This is where standard algorithms like AES for encryption and SHA for cryptographic hashes are good because intelligent people (usually mathematicians) have already gone through all the effort to make those proofs for you so you know just how good the product is.
Let us not forget the cost/benefit analysis. All I'd have to do to use this is load it up into SC2. Hacking a bank I'd make wouldn't be that big of a deal. To use those other things you've mentioned I'd have to look them up, perhaps read tutorials on it, implement it, etc. Doesn't seem worth the time.
The SHA-1 was done for the bank import system so is multi-purpose (personally I would have used something stronger otherwise as SHA-1 is deemed insecure and stronger protection is not that much more expensive resource wise). I believe I made the first map that allowed you to import banks from another publisher without bypassing the signature system (the only form of protection the imported banks have so not something that could be ignored). My main gripe is that SC2 banks lack several useful natives for full automation.
The most complex part is packing the data in a pesudo struct for encryption, the system handles the rest. The main issue people would find with using it is that there are no GUI wrappers due to the extensive use of references (not supported by GUI). It would have been awesome if you could wrap custom types for GUI sigh.
I believe I made the first map that allowed you to import banks from another publisher without bypassing the signature system
The most complex part is packing the data in a pesudo struct for encryption, the system handles the rest. The main issue people would find with using it is that there are no GUI wrappers due to the extensive use of references (not supported by GUI). It would have been awesome if you could wrap custom types for GUI sigh.
How do you import other people's banks? This is the first time I've heard that you're able to do so. Coding maps with other map makers to make use of this would be a reason for me to use a standardized encryption library shared among mapmakers. (although in most cases it would be due to lack of room to publish maps on a main account and using a side account instead)
Also 0 collision chance. Although hypothetically 2 people could generate the same hash, but it also wouldn't be read properly when uploaded if they swapped strings.
I thought I included the forms of information manipulation in the OP I guess not. For the record it uses columnar transposition, the vigenere cipher, and the basic cesarean cipher, in the future i'll probably add in the bifid or trifid cipher.
The lack of gui for your library would be what would kill it for me (at least please tell me you have GUI string and code input similar to how starcode is coded mostly in galaxy but allows for gui input by users).
In 3 easy steps.
1. Copy the bank from the old author's folder to the new author's folder.
2. Open the bank file and copy out the signature string.
3. Start a game and when loaded enter the signature string into some text box (chat or dialog item).
You can then verify the standard bank signature StarCraft II applies and begin to load it. If you bypass standard bank signatures all you need to do is copy it between folders.
For cross-region support you need to store a list of "authenticated" accounts within the bank and use all of them as part of the key generation process. Performing a signature check when moving between regions then becomes optional if you have your own signature checks in place.
Quote:
Also 0 collision chance. Although hypothetically 2 people could generate the same hash, but it also wouldn't be read properly when uploaded if they swapped strings.
Then your hashing is not hashing since cryptographic hashing algorithms are meant to be deterministic for a given input. If you store it deterministically is another question however (eg you could xor it with an account specific hash and some constants after performing rotations).
The processes performed by something like AES encryption are documented here http://en.wikipedia.org/wiki/Advanced_Encryption_Standard. I imagine the main problem with string based algorithms is that string operations are usually of complexity O(n) as such for long codes you could easily hit the op-limit.
Quote:
The lack of gui for your library would be what would kill it for me (at least please tell me you have GUI string and code input similar to how starcode is coded mostly in galaxy but allows for gui input by users).
In 3 easy steps. 1. Copy the bank from the old author's folder to the new author's folder. 2. Open the bank file and copy out the signature string. 3. Start a game and when loaded enter the signature string into some text box (chat or dialog item).
You can then verify the standard bank signature StarCraft II applies and begin to load it. If you bypass standard bank signatures all you need to do is copy it between folders.
For cross-region support you need to store a list of "authenticated" accounts within the bank and use all of them as part of the key generation process. Performing a signature check when moving between regions then becomes optional if you have your own signature checks in place.
So without copy paste you can't access a different publishers bank? I can't specify for it to go into jimmy's storage and load his bank? That's actually a let down man.
Quote:
Then your hashing is not hashing since cryptographic hashing algorithms are meant to be deterministic for a given input. If you store it deterministically is another question however (eg you could xor it with an account specific hash and some constants after performing rotations).
The reason they may be the same (theoretically), is the initial setting of the encryption alphabet differs from player to player, resulting in the ability for 2 players to give out the same input, but receive different outputs.
ExampleofsameinputdifferentoutputplayerAalphabetkey=ABCDEFGHIJKLMNOPQRSTUVWXYZ(thisobviouslyisn't the full encryption alphabet)player B alphabet key = BCDEFGHIJKLMNOPQRSTUVWXYZAfunction encrypt:Input: Player A = 5Player B = 5Output:Player A = EPlayer B = FExample of different input same outputplayer A alphabet key = ABCDEFGHIJKLMNOPQRSTUVWXYZ (this obviously isn'tthefullencryptionalphabet)playerBalphabetkey=BCDEFGHIJKLMNOPQRSTUVWXYZAfunctionencrypt:PlayerA=6PlayerB=5Output:PlayerA=FPlayerB=F
Generating a hash from that f would be the same for both players, but it would have different values for each player also.
So without copy paste you can't access a different publishers bank? I can't specify for it to go into jimmy's storage and load his bank? That's actually a let down man.
There are a few noticeable missing natives with regards to banks.
Native to open banks stored for other authors in "read only".
Native to open banks stored for different accounts on the same system (regions).
Native to verify banks for a specific author and account handle.
Native to load and synchronize from disc a bank in multiplayer during a session, including new banks that were not on pre-load list (reload is not possible at all in multiplayer even if it sounds like it could be).
Native to delete a bank file completely.
Quote:
The reason they may be the same (theoretically), is the initial setting of the encryption alphabet differs from player to player, resulting in the ability for 2 players to give out the same input, but receive different outputs.
Generating a hash from that f would be the same for both players, but it would have different values for each player also.
I imagine this makes multi-region support difficult (so people can copy their banks from one region to another).
Lol willu, don't take anyone who bitches about encryption security/integrity seriously.
"Hurr durr, you need to use this leet CS encryption technique I know about!"
Something more complex than Caesar cipher (alphabet shift) or substitution shift can deter almost all SC2 players from hacking.
We're not dealing with top-notch hackers, and top-notch hackers aren't dealing with SC2 game data. Only a show-off would bitch about these encryption libraries.
Rollback Post to RevisionRollBack
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
Lol willu, don't take anyone who bitches about encryption security/integrity seriously.
"Hurr durr, you need to use this leet CS encryption technique I know about!"
Something more complex than Caesar cipher (alphabet shift) or substitution shift can deter almost all SC2 players from hacking.
We're not dealing with top-notch hackers, and top-notch hackers aren't dealing with SC2 game data. Only a show-off would bitch about these encryption libraries.
There is nothing showing off by using industry approved standards. SHA-1 Is used for the in-built bank signature system so many mappers depend upon. AES is used by major government organizations as well as for secure communication of sensitive information. Map makers need systems they can trust rather than ones which boast they are secure yet have no actual proof.
In the end the weakest point of the bank is the map itself since you can always reverse engineer it. It just needs to be impossible enough to modify to keep noobs out and deter people who do not want to go to the extremes of hacking the map script.
Simple string based cryptographic techniques have been criticized back in WC3 where many of them were cracked, to the point that some people made it their business to crack them without hacking the map. I personally cracked some after finding that their checksum was a sum of all elements and each character was only offset by a constant and shuffled in 4 odd arrangements.
After all what is the chances of you doing something better than technology proved by dozens of researchers and used commercially?
Ouch. Last time I looked up 'alternative' I saw that it said 'another available possibility' hense optional and the point being that this is not a hostile take over with another type of encryption system, I'm kinda getting where you are coming from when you talk about the potential security risks, but it's just Starcraft 2 data intended for fun (Arcade, Custom games, Etc.)and not essentially as big of a deal as you're making it sound. Like the almighty Vicboy said
Simple Cipher System
What is it?
The simple Cipher system is a library created by me to encode strings. And pretty much anything of worth in the trigger editor can be converted to and from a string.
Why not use Starcode?
I used to use starcode as my encryption library but I had a couple reasons why I wanted to make my own:
Why use this?
Function Documentation
Function: Set Player Code (Player<integer>, Code<string>)
Allows you to set the code for a player, use prior to set player version# if both are used.
Function: Set Player Version# (Player<integer>, Version#<integer>)
Allows you to set a Version# for a player.
Warning: use after Set player Code if used, also will reset banks, you may want to use a system of checking their current version.
Library defaults to version 1
Example Usage:
Function: Encrypt (Player<integer>, String<string>)
Encrypts a string based on the the player's key.
Function: Decrypt(Player<integer>, String<string>)
Decrypts a string based on the player's key.
Function: Add Checksum(Player<integer>, String<string>)
Adds a check sum to the string based on the player's key and the value of the string.
Condition: Verify Checksum(Player<integer>, String<string>)
Check the check sum of a string to make sure that it wasn't modified.
Function: Remove Checksum(String<string>)
Removes the appended checksum from a string.
Installation
Known Issues
The alphabet key does not use the ~ \< characters
\ because it's the escape key
< because when combined with > can cause trouble displaying the output
~ because it is reserved for separating the checksum
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Cool. I've been thinking about adding some bank stuff to a map, so I'll def try this out when I do.
So what security standards does this implement? What proof do you have that it is secure? What proof does your checksum algorithm have for having a low chance for collisions? How is cross-region support achieved?
I would not advise the use of any code system which does not use properly proved encryption and cryptographic hashes. After all what is the chances of you doing something better than technology proved by dozens of researchers and used commercially?
For example my Imperial Bank system uses SHA-1 160 bit cryptographic hashes (I am aware that they are "theoretically" insecure but for a SC2 bank it should be more than sufficient) and an AES based encryption algorithm with (160 bit keys with interpolated round number so not standard as the standard only defines 128, 192 and 256 bit keys). All you need to do is put the two together (so encryption key is based on the cryptographic hash) and you have a highly secure form of data encoding. A single bit change will result in a completely different string being generated.
@ImperialGood: Go
Security Standards: Mine. It's not easy to crack, but definitely possible. I'm not at the level of programming AES encryption systems (unlike someone), I'm a freshman in college, and I've literally taken one computer science class and that's it (and it was freshman year in highschool to boot). I just have fun programming in SC2. That being said, if you want to make a tutorial on creating your own AES system (or upload your's as a library), i'd be more than happy to try and learn from it how to program one.
Proof: None, however if they make it past blizzards bank signature, they're more than likely to make it past my coding like you said "for a SC2 bank it should be more than sufficient". Plus anyone who's willing to go that far for one map.
Collisions: ? If you mean getting confused with what is the original encrypted data and what isn't, that's the reason the ~ character was reserved for it.
Cross region support: Only publish to NA haven't finished a map worthy of being cross region published yet.
Chances: slim
Yes this bank could be coded way better, by people who are a lot smarter than me (hence we have starcode), however I wanted a code system i could use in my maps that I could understand. I don't like using code that I can't comprehend how it works. I have never claimed that this is the most secure system out there
I say it isn't easy to crack (which admittedly it isn't), but it is possible to crack. So thank you for helping me to clear up that with anyone who may download it in the future. (Although pending that AES coding tutorial from you it could get way better). If you want to go cracking this library for me and then post what you did to crack it (and what you coded to crack it), and show how weak it is then by all means go for it, in fact I encourage it, I may not be aiming to try and get a degree in C.S. right now, but I definitely wouldn't mind learning more.
Edit: Before I forget to ask, are you related to DrSuperGood at all, you guys have the same avatar?
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
I am one the same. I am related to another person here though (not that it is hard to guess).
In theory there is no need for such a document seeing how all resources about AES and SHA, including official specification documents, are available online free of charge. SHA is nothing more than implementing pseudo code or porting a C implementation. AES is a lot more tricky as it is a lot more complex (specifically the finite field theory used for re-combination of block columns).
I will eventually upload it as a library (I need to remove my private keys from its workings) however currently there are no GUI interfaces for it so most people will probably have difficulty using it. There are also possible op-limit concerns (which apply for your system as well?) for larger data blocks.
I am referring to hash collisions where 2 different blocks of data generate the same hash value. In the case of cryptographic hashes such as MD5, SHA-1 etc it is important that this is as low as possible. If the probability of collision is practically impossible then you can use the hashes alone as a way to uniquely identify data (how Blizzard's CASC archive system operates that will replace MPQ with SC2 3.0). Since it gives a pretty unique identification with low correlation between input and output you can also use them to verify the integrity of data (since a single bit change will generate something completely different). You can think of them as sort of "checksums" however in theory a checksum means something completely different and far less secure. They are a very good base for an encryption key since a single bit change in input data will result in a completely different output and a single change during decryption will cause a hash mismatch error. By using this you can make every encrypted bit + hash depend on every decrypted bit. Since standard algorithms are easy to engineer, you make the connecting logic complicated adding constants, recombination of values and bit rotates when computing the keys (since the combinations in this step are practically infinite). Additionally you round to "next block" in output length to hide the physical length of the data contained with padding (a few characters do not mater).
Here is an example of one of the output strings I get using the above method. This alone is not sufficient to decrypt however since it also depends on an archive block and bank identifier. Remember that a single bit change will cause a completely different string.
Since I know the hash is always exactly 160 bits I do not need a "~ character" to tell when it starts/ends.
I am not trying to prove how weak it is. I am just stating that you have no evidence that it is strong. It could be very secure and practically impossible to crack or it could be very easy and people could crack it in under an hour (without resorting to reverse engineering) however you have no proof as to which it is. This is where standard algorithms like AES for encryption and SHA for cryptographic hashes are good because intelligent people (usually mathematicians) have already gone through all the effort to make those proofs for you so you know just how good the product is.
Let us not forget the cost/benefit analysis. All I'd have to do to use this is load it up into SC2. Hacking a bank I'd make wouldn't be that big of a deal. To use those other things you've mentioned I'd have to look them up, perhaps read tutorials on it, implement it, etc. Doesn't seem worth the time.
The SHA-1 was done for the bank import system so is multi-purpose (personally I would have used something stronger otherwise as SHA-1 is deemed insecure and stronger protection is not that much more expensive resource wise). I believe I made the first map that allowed you to import banks from another publisher without bypassing the signature system (the only form of protection the imported banks have so not something that could be ignored). My main gripe is that SC2 banks lack several useful natives for full automation.
The most complex part is packing the data in a pesudo struct for encryption, the system handles the rest. The main issue people would find with using it is that there are no GUI wrappers due to the extensive use of references (not supported by GUI). It would have been awesome if you could wrap custom types for GUI sigh.
@ImperialGood: Go
Ah, you are DrSuperEvil's brother I remember seeing one of his posts about that.
How do you import other people's banks? This is the first time I've heard that you're able to do so. Coding maps with other map makers to make use of this would be a reason for me to use a standardized encryption library shared among mapmakers. (although in most cases it would be due to lack of room to publish maps on a main account and using a side account instead)
Also 0 collision chance. Although hypothetically 2 people could generate the same hash, but it also wouldn't be read properly when uploaded if they swapped strings.
I thought I included the forms of information manipulation in the OP I guess not. For the record it uses columnar transposition, the vigenere cipher, and the basic cesarean cipher, in the future i'll probably add in the bifid or trifid cipher.
The lack of gui for your library would be what would kill it for me (at least please tell me you have GUI string and code input similar to how starcode is coded mostly in galaxy but allows for gui input by users).
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Also updated the library, added a couple of new functions, nothing to worry about though if you just want the base system.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
In 3 easy steps. 1. Copy the bank from the old author's folder to the new author's folder. 2. Open the bank file and copy out the signature string. 3. Start a game and when loaded enter the signature string into some text box (chat or dialog item).
You can then verify the standard bank signature StarCraft II applies and begin to load it. If you bypass standard bank signatures all you need to do is copy it between folders.
For cross-region support you need to store a list of "authenticated" accounts within the bank and use all of them as part of the key generation process. Performing a signature check when moving between regions then becomes optional if you have your own signature checks in place.
Then your hashing is not hashing since cryptographic hashing algorithms are meant to be deterministic for a given input. If you store it deterministically is another question however (eg you could xor it with an account specific hash and some constants after performing rotations).
The processes performed by something like AES encryption are documented here http://en.wikipedia.org/wiki/Advanced_Encryption_Standard. I imagine the main problem with string based algorithms is that string operations are usually of complexity O(n) as such for long codes you could easily hit the op-limit.
Nope it is pure Galaxy. At the moment at least.
So without copy paste you can't access a different publishers bank? I can't specify for it to go into jimmy's storage and load his bank? That's actually a let down man.
The reason they may be the same (theoretically), is the initial setting of the encryption alphabet differs from player to player, resulting in the ability for 2 players to give out the same input, but receive different outputs.
Generating a hash from that f would be the same for both players, but it would have different values for each player also.
Damn
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
There are a few noticeable missing natives with regards to banks.
I imagine this makes multi-region support difficult (so people can copy their banks from one region to another).
It would. Also another reason in my map i'd include a region section with a region and handle key so it would upload correctly.
Hence my new set code for player function (which would make sense without it anyways.)
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Lol willu, don't take anyone who bitches about encryption security/integrity seriously.
"Hurr durr, you need to use this leet CS encryption technique I know about!"
Something more complex than Caesar cipher (alphabet shift) or substitution shift can deter almost all SC2 players from hacking.
We're not dealing with top-notch hackers, and top-notch hackers aren't dealing with SC2 game data. Only a show-off would bitch about these encryption libraries.
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
There is nothing showing off by using industry approved standards. SHA-1 Is used for the in-built bank signature system so many mappers depend upon. AES is used by major government organizations as well as for secure communication of sensitive information. Map makers need systems they can trust rather than ones which boast they are secure yet have no actual proof.
In the end the weakest point of the bank is the map itself since you can always reverse engineer it. It just needs to be impossible enough to modify to keep noobs out and deter people who do not want to go to the extremes of hacking the map script.
Simple string based cryptographic techniques have been criticized back in WC3 where many of them were cracked, to the point that some people made it their business to crack them without hacking the map. I personally cracked some after finding that their checksum was a sum of all elements and each character was only offset by a constant and shuffled in 4 odd arrangements.
Updated Library fixing some bugs.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
I want to kill you.
That's cool, are there any other alternative encryption system that do that for SC2?
Ouch. Last time I looked up 'alternative' I saw that it said 'another available possibility' hense optional and the point being that this is not a hostile take over with another type of encryption system, I'm kinda getting where you are coming from when you talk about the potential security risks, but it's just Starcraft 2 data intended for fun (Arcade, Custom games, Etc.)and not essentially as big of a deal as you're making it sound. Like the almighty Vicboy said
Issue? I think not.. But I will still bitch about it honestly, I'm kinda second guessing about it when I someone else's point though.
Will needs some guinea pigs.
Updated
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)