Leadwerks Asset Protection

[nate066]

I noticed when i download games from the asset store all the lua scripts and sounds are visible and un-encrypted/compiled. If your game uses lua its a huge problem because someone can modify the lua code a hack the game very easily. Leadwerks should compile the lua scripts so they cant be read or modified easily. Sounds,images could use a light encryption but its not that important but being able to modify lua scripts is a huge issue even if your using a c++ and lua combination. Is there any plans to fix these issues

[Josh]

In the next build, you can compile Lua scripts into precompiled bytecode. LuaJIT needs to be downloaded separately and the process done with the command line, but it works and will be automated later on.

 

Encrypted zip files are presently supported.

[nate066]

In the next build, you can compile Lua scripts into precompiled bytecode. LuaJIT needs to be downloaded separately and the process done with the command line, but it works and will be automated later on.

 

Encrypted zip files are presently supported.

 

Awesome but i have a few questions.

 

your refer "next build" is the next build leadwerks 3.1 or is it the next update of the current leadwerks release.

 

What exactly do you mean by encrypted zip files? Do these files allow you to run the application without the user entering a password or are they just regular zip files that protect the contents inside until the password is entered?

[Guppy]

Sounds,images could use a light encryption but its not that important but being able to modify lua scripts is a huge issue even if your using a c++ and lua combination. Is there any plans to fix these issues

 

Your basic premise is flawed ( as many companies have discovered, and decided to ignore ) - You want your end user to not be able to view the data[1] but be able to view the data[2].

 

In order to achive [2] you automatically open up for [1] - why?

Well in order to decrypt your data for you application to present it your application needs the key - that means that your user have access to the key.

 

And yes this may be out of scope of the average user, but though the magic of the internet all it takes is one user who can figure it out.

 

if your worried about file altering being used for cheating, you could simply use the "streaming update" trick - basically you roll out updates on per file / data chunk basis form minor updates. This requires you to check the files /data chunks and submit their check sum to the server to see if an update is available. Anyone who has a bad checksum ( ie one that matches no version ) gets marked in the black list table. Every few weeks you go through the black list table and do a "ban wave" for breaking the EULA.

 

The reason you wait a few weeks is to make sure you catch all offenders.

 

Do note that this will be defeated in time as well (when people realize why they get banned) by intercepting your check sum calls and returning "proper" values - The trick to counter this is to update the exec to alter the offset often enough that it becomes too annoying for the cheat/bot author to keep publishing.

 

But even this is a loosing battle ( just ask blizzard ) - the more people playing your game the more likely one of them will be more clever than you and beat you at the cheat anti-cheat battle. At this point you need to tell your lawyer to "go get them", see: http://en.wikipedia.org/wiki/MDY_Industries,_LLC_v._Blizzard_Entertainment,_Inc.

 

The idea here being to hit the so hard nobody want's to risk it again

[Roland]

If the user wants to hack the game, why not let him?

[Guppy]

If the user wants to hack the game, why not let him?

 

While I agree with in principle that user modifiable content is a bonus for any game, there are some aspects that the user should not be able to modify since it would ruin competitive game play (mostly applies to multiplayer).

[nate066]

If the user wants to hack the game, why not let him?

if you have a multiplayer game there is several reasons not to let him hack the game.

 

1. People will leave if your game has hackers

2. the scoreboard would mean nothing as all the scores would be hacked

3. you get a bad reputaion of allowing hackers to hack your game

 

Your basic premise is flawed ( as many companies have discovered, and decided to ignore ) - You want your end user to not be able to view the data[1] but be able to view the data[2].

 

In order to achive [2] you automatically open up for [1] - why?

Well in order to decrypt your data for you application to present it your application needs the key - that means that your user have access to the key.

 

And yes this may be out of scope of the average user, but though the magic of the internet all it takes is one user who can figure it out.

 

if your worried about file altering being used for cheating, you could simply use the "streaming update" trick - basically you roll out updates on per file / data chunk basis form minor updates. This requires you to check the files /data chunks and submit their check sum to the server to see if an update is available. Anyone who has a bad checksum ( ie one that matches no version ) gets marked in the black list table. Every few weeks you go through the black list table and do a "ban wave" for breaking the EULA.

 

The reason you wait a few weeks is to make sure you catch all offenders.

 

Do note that this will be defeated in time as well (when people realize why they get banned) by intercepting your check sum calls and returning "proper" values - The trick to counter this is to update the exec to alter the offset often enough that it becomes too annoying for the cheat/bot author to keep publishing.

 

But even this is a loosing battle ( just ask blizzard ) - the more people playing your game the more likely one of them will be more clever than you and beat you at the cheat anti-cheat battle. At this point you need to tell your lawyer to "go get them", see: http://en.wikipedia.org/wiki/MDY_Industries,_LLC_v._Blizzard_Entertainment,_Inc.

 

The idea here being to hit the so hard nobody want's to risk it again

 

I think your right but in addition to checksum checking its still a good idea to compile lua files with luaJit as it just adds one more layer of defence but i think your right for anything but code it wont stop people if they want it. I think the fact that leadwerks will support precompiled lua files has satisfied my need for content protection. Can't wait til we get the update that allows support for pre-compiled lua files.

[Roland]

For a multiplayer game I can understand why protection can be important. For a single player not.

[Flexman]

If the user wants to hack the game, why not let him?

 

It depends what they do with it at that point. I work with a "White Hat" hacker and have an appreciation that no matter what you do there's someone smarter with a better tool. I didn't know you can just plug a device into firewire or a USB port and break into any locked system as you have direct access to system memory via high speed interfaces. What an awesome hardware design!

 

My first commercial game product was the result of reverse engineering which predates but would now fall foul of the DMCA. But there's so much more potential for monetary losses/gains now micro-transactions are here to stay.

 

Game assets need to be protected to some degree, not least because there's always some nut-job willing to upload and sell them on an asset store to unsuspecting game developers who then become victims.

[Roland]

Guys. I have no problem to change my mind when convinced with good arguments. So I do

[Flexman]

Guys. I have no problem to change my mind when convinced with good arguments. So I do

 

I guess it's not so much about that as how to protect them in Leadwerks. There's value to be had in open source games from the asset store. I learned a lot about writing better LUA from having someone look at my code and giving me feed back (er fixing it - cheers Mac). So there is a benefit to sharing too.

 

Asset vendors such as Pure3D or Dexsoft require some kind of asset protection in their license terms. Password protected ZIP files satisfy this requirement for LE projects.

 

It would be nice to have an all in one process to build and package everything.

[Josh]

FYI Zip files are unlikely to ever work on Android, since it does not support a file system.

[propjohn]

FYI Zip files are unlikely to ever work on Android, since it does not support a file system.

Maybe I'm not parsing this right, could you clarify? Android most certainly does have a file system, just not one that end-users have easy access to.

[Josh]

Android has a zip file associated with an application (APK file) and a removable SD memory drive the application may or may not have access to. The APK file itself can't have files in directories, can't have files with the same names (but different extensions) and there's a lot of other odd requirements and forbidden file extensions.

 

In order to use a compressed zip file with Android, the zip file have to get extracted from the APK into memory, then each file you want would be extracted from that. Moving the entire game's contents into memory is not a good idea, on any platform.

 

So I wouldn't say it supports a file system, by my definition of what that implies.

[Ywa]

If it's about protecting multiplayer games, why not do a consistency check? (CRC32 or whatever) You could even make a server configuration option to allow modded clients or not. So people can still make mods to use when the server allows it (e.g. when playing with friends).

[Dude]

For a multiplayer game I can understand why protection can be important. For a single player not.

 

Hello, I'm new here, but not new in gaming.

 

Hacked friendly single player games? I think it's bad idea. It's bad for gameplay nor immersion. For me, games where you can even put cheat codes are boring after very short time. It happpens, where gameplay is just too hard or bad balanced and you need some help with code. I never finished single player game on cheats - what's the point? Good designed game not need cheats and in multi this is out of discussion.