Sign in to follow this  
DrewGreen

asIBinaryStream read()

Recommended Posts

Hi, I've just started using AngelScript & so far I'm impressed with how painless the process has been. For the moment I'm using the tutorial sample as a reference. However I'd like to be able to protect scripts in my game from being easily modified, to prevent end-users from being able to cheat by simply changing what they do. I read the docs regarding SaveByteCode() and asIBinaryStream, but am unsure as to how to use these functions to save the bytecode out to disk. I understand that I need to call Read() and provide a pointer to a location in memory (and then use this to write the contents out to disk), but can't work out how to retrieve the correct size of the binary stream. Is what I'm asking possible, and if so, how can it be done?

Share this post


Link to post
Share on other sites
Actually, it's quite easy. AngelScript does all the hard work for you. :)

One example implementation would be:


class CBytecodeStream : public asIBinaryStream
{
public:
CBytecodeStream() {wpointer = 0;rpointer = 0;}

void Write(const void *ptr, asUINT size) {if( size == 0 ) return; buffer.resize(buffer.size() + size); memcpy(&buffer[wpointer], ptr, size); wpointer += size;}
void Read(void *ptr, asUINT size) {memcpy(ptr, &buffer[rpointer], size); rpointer += size;}

int rpointer;
int wpointer;
std::vector<asBYTE> buffer;
};

--------------------------------------

// Save the compiled byte code
CBytecodeStream stream;
engine->SaveByteCode("module name", &stream);

// Load the compiled byte code into the same module
engine->LoadByteCode("module name", &stream);


This example is taken from the test file /tests/test_feature/source/test_saveload.cpp. It saves the bytecode to a memory buffer, but it shouldn't be difficult for you to convert it to save to disk.

When loading the saved bytecode you have to make sure the script engine was configured in the exact same way as it was when the original bytecode was saved. But this shouldn't be a problem, unless you're using the dynamic configuration groups.

But you should know that using precompiled bytecode instead of scripts will only make it sligthly more difficult to modify them. It's basically just an obfuscation of the script code.

What you really need to protect from cheating is to use some method for validating that the scripts are the original ones. Calculating the checksum of the script and validating it against some safe source is what I recommend.

Regards,
Andreas

Share this post


Link to post
Share on other sites
Thanks very much! Even less pain than I thought. I hadn't actually looked in the test folder until now.. doh

I understand it's not very secure. I plan on merging them into my dodgy custom level data format - the idea being the scripts are lost to the human eye amidst an assortment of other confusing characters that make no sense when opened in Notepad. It's purely to stop the casual cheater rather than the one who knows how to use a hex editor :)

An editor is included in the game so they could just cheat that way I guess (though I assume the script compilation is one-way in terms of meaningful variable names?), but it's only made available after the game has been completed [lol]

Share this post


Link to post
Share on other sites
A good option would be to encrypt the byte code and then decrypt it before you load it. Even just a quick easily cracked encryption algorithm would substantially increase the amount of time/knowledge a person would need to modify the byte code.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this