Module for protecting game assets
Monkey Forums/User Modules/Module for protecting game assets
| ||
| Hi all Does anyone know of or is planning to create a module which would protect game assets? Art, sound, level data etc...? This is something I am really interested in, and would pay for. |
| ||
| What targets? Fact is you never can really secure it. It's just a matter of effort. |
| ||
| i need it also for images... i think it is not really possible on all platforms monkey use native loader for gfx, sounds... for loading, you must decrypt to ram and then load it from ram using native command. And if used API can not load from ram, you have a problem. A simple solution is to decrypt to file... but this is unsafe! android: BitmapFactory.decodeStream(...) BitmapFactory.decodeByteArray(...) |
| ||
| @Xaron GLFW mainly, or targets specific to desktop apps. I agree, it may not even be worth protecting assets |
| ||
| at least people can make screenshots and rip graphics there, no matter how hard you protect it... |
| ||
| Something like a .pak format or .zip (which you can password protect) would be great for that kind of thing. I'm not sure if anyone is working on a zip loader for monkey tho, I asked a while go with no joy. |
| ||
| Zip file crypto was busted a long time ago and is totally insecure especially to known plaintext attacks (known jpg header data, etc etc) which will allow them to bruteforce the file in a big hurry. http://oldhome.schmorp.de/marc/fcrackzip.html This is one of those places where you are better off with roll your own, it is trivial to come up with a scheme that will require differential cryptanalysis to break (barring ram dumps) and very few people can do that. |
| ||
| I've never actually heard of a game's assets -- big or small -- being ripped and used to divert sales in any way. Is there really any point to this? |
| ||
| call me paranoid, but I would want to protect my assets, from casual observers. i'm all for it, one way now would be to create a base64 file format, but seeing how it would be quite large, the other option i was thinking about is a TAR based format, easier to implement as pure monkey than gzip. but gzip is available on every single platform, so it could be an option, too. |
| ||
| I feel that protecting assets is a waste of time, what exactly do you think people would do with your assets, are you worried they will use then in their own game ? if they do and you find out then take legal action. Personally I think having your assets open is the better option as it allows for modders to mod your game, and just look at how good mods can be for all the games that have them. |
| ||
| One reason is not just to protect them but also to have a neat folder, a game executable and a single big datafile always looks nicer to me than a folder with thousands of small files and nested folders in it. If you are targeting anything but PC or Mac though there is no real need as normal users wont even be able to look at your files. |
| ||
| I would like to also protect my assets, who saying that after a game is released all someone has to do is change the graphics and media then they can release a whole new game that competes with your own. It has been done before back in the Doom days when after doom was released loads of people changed the graphics, sounds etc to doom and released whole new games. |
| ||
| here are lot candy crush saga clones - with same graphics... here are also many android games that are converted to blackberry - but not from the authors... this are illegal copies all this come most time from china... if you can protect media, it is harder to clone game with same graphics or replace graphics... |
| ||
| I feel that protecting assets is a waste of time, what exactly do you think people would do with your assets, are you worried they will use then in their own game ? There have been a number of incidents where cloners ripped all the game assets and used those in their clones. Talk about lazy. Pretty sure these are on Android-- it's pretty easy to get access to the filesystem under Android and then they can use the assets on whatever platform. A lot of the people who do this are in China and so are effectively immune to lawsuit in the west. As for being a waste of time, for images at least the time required would be trivial. For sounds it would require a custom sound loader but perhaps it would be possible to extend or alter the Monkey sound loading code to do a pre-processing pass after initially loading the data. |
| ||
| Well yeah that actually sounds like a good reason for protecting assets, but I'm still not sure how this would really hurt the developer, given that China does not or are not allowed Play.google wallet access, so its not lost sales, because they cant buy from you anyway. Unless I am mistaken, people in China pirate so much because it's the only way they can actually get the content, they cant buy it, their only option is to pirate it, and if their pirated and modded versions are also being released only in china to the same people then I really cant see it being an issue for us. This Android stuff is new to me tho, so I fully expect there to be a lot of background on these activities that I don't know about , but from what I hear , it's a bit of a non issue. Check this Article out TLDR(Sold 140 copies, pirated 50,000 times. develper says hes not losing sales as a result cos the pirates are all in china.) ( http://kotaku.com/this-game-sold-144-copies-and-was-pirated-50-000-times-1198037914?utm_campaign=Socialflow_Kotaku_Facebook&utm_source=Kotaku_Facebook&utm_medium=Socialflow ) |
| ||
| I'm still not sure how this would really hurt the developer, given that China does not or are not allowed Play.google wallet access, so its not lost sales, because they cant buy from you anyway. Well, there are a bunch of claims of games being cloned and far exceeding the original in terms of downloads and sales. I can't speak to what they are allowed, but we both know that it's easy to evade strictures like that. Sold 140 copies, pirated 50,000 times. develper says hes not losing sales as a result cos the pirates are all in china. That's another issue and no, those guys aren't going to buy our apps anyway. I'd be more concerned with people who have cutouts and fake developer accounts outside of China. I can see what you're saying about modders. Since I am primarily developing for mobiles, modders aren't an advantage I enjoy and app cloning is something I worry about, perhaps too much. The fact remains that encrypted asset formats are pretty easy to implement, at least for graphics, and you could use the same techniques to do so with video and sound. You can also do it in ways that are fairly cryptographically robust with very little work-- all you have to do is make cracking it require more effort than it's worth. |
| ||
| This just gave me an idea but will require read pixel ,will try it out tomorrow. |
| ||
| Yeah, that's the idea and it's really simple. You could experiment with shuffling first rows of an image based on expansion of a key, then shuffling columns, etc. Do that several times and your image will be unrecognizable, but the transformation is reversible given the key. You can expand a key by using repeated search and replace of strings within the key. Say your key is "foofoofoo" and you search-and-replace "f" with "fof," then "o" with "fffo". If you have a couple of little rules like that and iterate them one after the other it will create a fractal expansion of the original key and you can use that for a pseudorandom string. Stripwise shuffling is not cryptographically sound for any really critical data but is a transposition cipher and as such is much more robust than a substitution cipher. You could probably also do it with grabimage but I'm not sure if that is truly crossplatform. |
| ||
| There is no such thing as a bullet proof encryption, even MD5 and Salted MD5 are easily cracked given the right tools. What your looking to do really is just make it annoying enough that most people wont bother even trying, or investing the time to get it done, but it will never be 100% protected. Which Brings me to another thought, shifting pixels in an image is a waste of time, if the whole point of these China rip offs is that they change the art, they are not going to care if your art assets are protected, they are simply going to screenshot your game in action and then rip the art the slightly harder way, or just reproduce it fully. Probably the most important thing you should want to protect is the code, and sadly its the one thing that you cant, you can make it harder for the human to read but it's still very easily read. I'm just not sure if this whole endevour is really worth the effort, I would also love to know of any examples of this actually happening in a western market, or is it just a "My friends aunties daughter's best pal told me!" ? |
| ||
| They are going to screenshot it on a tablet and one by one copy your sprites, save them to a file and use them in a rip? Sounds like the definition of too much effort but your mileage may vary... There is no such thing as a bullet proof encryption, even MD5 and Salted MD5 are easily cracked given the right tools. The whole point of encryption is making things secure (in all likelihood) until a certain amount of time is passed. Again though both of the items you mentioned were known-plaintext attacks or educated guess methods based on phrase dictionaries until fairly recently and are very common and well-understood. The likelihood that someone is going to perform differential cryptanalysis on someone's Match 3 game sprites is much less than the idea that they would perform a memory dump on an emulator or similar. http://arstechnica.com/security/2013/08/thereisnofatebutwhatwemake-turbo-charged-cracking-comes-to-long-passwords/ |
| ||
| scrambling image is not efficient - because such images have bad compression. it is better to load encrypted image to ram, then decrypt and load from ram. at least we need load compressed image (png, jpg) from ram function |
| ||
| That's a good point, scrambling would make the image impossible to compress. You could use some sort of unusual run-length encoding format and have the encryption happen within that. For sprite images on a transparent background that would work just fine but it would require you to write transparency in the process of converting it to an image. |
| ||
| For one of the projects on my plate, I plan on incorporating an image mangler similar to the one zoqfotpik described. The method is similar to the old reversible "glass block" masking methods used in Japan during the 90s. Images are split into grids of blocks, and then a cyclic key is applied to each block, flipping it horizontally and/or vertically. This same process is applied in reverse on the Monkey end by grabbing the image from the known block size, applying the transformations, and making multiple draw calls at runtime. The 4 least-significant bits in a char will be used to flip blocks, 2 at a time, or possibly flip-and-rotate a single block. This is so that blocks are more likely to be altered, and has the side effect of making capitalization pointless. For most people's purposes, this probably isn't super useful, but for a specific genre of game, this works well enough to prevent image dumping while at the same time preserving the alpha channel and not being a terrible drain on resources, since it's all done on the GPU. I personally believe that for most games, it's not worth trying to protect your game assets, unless your game assets are the main selling point of the game. For the vast majority of games, this doesn't apply. |
| ||
| It wont stop screenshots in. An emulator though |
| ||
| code in some fmodex and give everyone a headache. |
| ||
| Im gonna look and see what can be done |
   |