StarBankis a free Starcraft II bank file editor designed for customized maps. The program detects bank files automatically and allows convenient editing of bank-file contents. It allows instant access to a map's map-file, cache-folder, bank-file, bank-folder or trigger (Galaxyscript) file.
As a map developer, you have only one option when it comes to saving and recalling information between game sessions- banks. Bank files are great for the majority of players, and allow them to experience progression over many game sessions. But ponder this situation- You've just finished creating the best RPG ever, complete with features so great that you would rise to "#1 Top Played" in a day. You launch the map, and it explodes, launching you into "internet legend" status. But then, out of the darkness, comes a single bad apple- a player, intent on ruining your day, and the day of every player who loves your fantastic map. That's right- it's a hacker. And he has his greedy little eyes set on your map, ready to pounce- will you be ready?
So, silly introduction aside, bank security is important for any map that includes banks. While it's certainly more important for maps that offer more important features through banks, like levels in an RPG, it's something that everyone should consider. Here's the overriding principle when it comes to bank security, though:
I will not be discussing detailed instructions on how to use these tools, but instead discuss bank security in more general terms. This tutorial may be a useful read for anyone who is interested in protecting their banks, but it will not provide you with line-by-line instructions. That said, there's 2 big areas we're going to be dealing with today- Securing your bank files, and obfuscating your map data.
The first thing you should do to protect your bank is make it impossible to simply pop open the bank file, edit it, and save it. And luckily for you, it's actually easy to do this. You have two methods, each of which I'll into detail in below:
If your map has a bank, it should use bank signatures. The only exception to this is if you want people to edit their banks for some reason, but this is not normally the case. Bank signatures are incredibly easy to implement- it requires you to add only one action to turn the feature on, and a single condition to check for hacking. Here's how it works, should you choose to turn on the feature:
Pros: Not quite as easy to add, but will prevent any hackers who are not smart and dedicated. Also lowers file size
Cons: Dedicated hackers can locate your encryption within the map file itself, if they're smart
As you can probably tell, it's pretty easy to see exactly what each of those numbers represents, and change those values. If a hacker manages to break your signature (which, again, is definitely possible), he can easily modify whichever values he wants. Say I want to change my high score- I'll just replace 1000 with 10000. Encryption takes all of those values, squashes them together into one much smaller value, and then scambles them to be unreadable. Here's an example of that same bank, but encrypted:
So what would happen if I wanted to change my high score now? I wouldn't know what to change, because my entire bank has been squished down to just "a843j-6anf1!", and I have no idea what that means. How do we do this to our banks? You could create your own encryption/compression script, but that's a lot of unnecessary work. S3rius created an awesome library called Starcode, which you can use to encrypt your bank files. I'm not going to cover the actual details of how to use starcode (An example map is included at the link earlier).
But there is one weakness that we can encounter when using encryption. We need to have an encryption key to decode our bank. Think of the old encrypted messages used in wars- you needed to have the encrypted message itself as well as the cipher that told you how to read it. The cipher, in our case, is called our encryption key. If our hacker learns what our encryption key is, then he can easily decrypt our values, rewrite them, and then re-encrypt them.
That's where the problem lies...Unfortunately for us, we need our encryption key to be inside the map. Hackers can download the map off battle net (even if it's locked, there are ways around it), view your mapscript, and find your encryption key. We can't prevent this from happening, but we can try to make it as painful as possible for hackers by obfuscating our map data.
We've already dealt with bank security- that keeps our banks safe and difficult to edit. But all of that falls apart if the hacker can discover our encryption key. Like I said earlier, it's impossible to prevent that from happening, but we can make it as hard as possible to do. One way we can do this is to obfuscate our mapscript file. Obfuscation takes our mapscript file and rewrites the entire thing to make it unreadable, but still functional. For example, your variables would be named "iiIillIllI and illliiilliii" instead of "player_life and player_health", making them unreadable to humans. Zeedu has a mapscript obfuscator available here (Make sure you keep a backup of your maps before obfuscating it!). You can obfuscate your map using this tool, making it impossible to open in the editor and impossible to read.
On top of what's discussed here, feel free to think outside of the box- it can't hurt! What if you encrypt your bank more than once, using different pieces of data to do it? What if you include a 'checker' function inside your map that checks your banks to see if a player's stats are suspiciously high. What if you assign players a randomized ID number and use pieces of that number to encrypt their banks?
Hopefully this tutorial was useful for providing you with a better idea of how to secure your bank files. As I mentioned several times, there is no way to totally secure your bank files. The best you can do is encrypt them well, and then obfuscate your map data to help hide your encryption key. If you do this, the vast majority of potential hackers will likely be dissuaded. And as always, feel free to send me a PM if you have any comments, questions, or suggestions ;)
A futile effort since whole maps can be cracked like raw eggs... No matter how you rename stuff it all breaks down to the programming language used in the game. With the triggers used to create and interpret the banks at hand it is only 30 mins work to make a code generator.
This was requested since years and we did never really get an answer. Not only that it prevents hacking, it also makes a lot more conceptional sense to link banks to your account rather than your hard drive. This would make it possible to switch computers/format your HDD without losing any progress.
It'll never happen, as much as they love their players, they won't store data on their servers because if one of their employees accidentally wipe their hard drives, then they are liable for the lost data. The only data they'll risk it for is the official ladder.
I find this whole situation funny because map makers want to protect their precious banks. I'm not trolling here, be honest do you think the mapping community has a problem with people cracking banks? I say not, I say less 2% would use the program to generate a signature. Thats a lot of effort alone, if you encrypt it how many people would go out of their way to crack the encryption? Probably less than .1%, if that.
Honestly the take away from this is that if your just tracking gameplay stats that has no impact on gameplay then use the blizzard signature. If you have gameplay impacting data in banks that you want to sacrely protect then I would go beyond with the options above. The take away from this is that there is a few slim chance people want to crack your bank, and even then its not worth going through the effort just to add some digits to your stats, if I detected someone modifying their banks than I would just ID ban them if I felt like it, which probablybwouodnt happen anyways.
What you say is mostly true, this is useless if you`re only storing/recording game statistics.Nonetheless, for games which will heavily rely on banks for gameplay will be threaten by outside modifications; e.g. levels, unlocks, standings, etc.As OP said, more-or-less dedicated hack edits will happen so a detective ban system should still be used but at least the occurrence will be smaller.
Im running into an annoying problem where my bank is completely empty every time I restart my map. To clarify the issue, I can confirm that I am saving the bank, and later within the map I am checking if those values that I just saved are still indeed there; and they are. I can also confirm that the values are indeed in my BANK_NAME.SC2Bank file. However when I launch my game, I am getting a 0 sections counted when I try to debug why there is nothing in the bank.
Edit: Another weird bug I am seeing is that every time I save the bank, it creates a whole new XML file with only the properties I saved from that session and does not keep the values that were inserted from a previous run from the map. This makes me think that somehow I am deleting the file right at the beginning of loading my map or something.
Unforunately I cannot test this map now because I am at work. That said, I have no qualms with opening up the editor to take screenshots. If it is any interest I can publish the map as public / unlocked. I do not care much about sharing code since this was a retrofit on an existing map made back in 2010, you will just have to bare with some of the leftover variables / triggers have not been removed, but that shouldnt be a problem since none of the code touches it.
Figured out the problem. It was because my literal string had an underscore in the name, and was not translating into the Bank File that was being created for saving and loading. The reason I was able to access the data in the same game run I was still using was because under the hood blizzard is caching the Bank I have already loaded.
3a8082e126