Protecting GBAL

Previous topic - Next topic

MrTAToad

I've been giving some thought to how to protect GBAL files, and whilst I what I propose wont change the format of GBAL it would require a few mods to the IDE

In addition, it wont stop people trying to convert back to C - although it would help if the conversion to GBAL had the ability to crunch the resulting code (although a lot can be done by the original coder).

Therefore, what I propose is :

All GBAL's should be place in one place within the GLBasic directory, with each given a separate directory.  This applies to both commercial and free ones as well,

Each directory would contain the GBAL file and a license information file (LIF) (the contents of which will be discussed later).

When the IDE starts it would scan the GBAL directory looking for new directories (and retrieving each LIF file as it goes along), and comparing this to a previous list.

Once this scanning has finished, and any new commercial GBAL's have been found, a window will display the list, and the user will be asked to authenticate them.

The authentication process could be done in several ways : When a user has entered a, say, serial code, this would communicate with another server which would note the number of users, GBAL serial code and GLBasic serial code.  This would allow easy detection of invalid multiple uses etc etc

The other way would be to create an encryption file (or modify the LIF file) that would contain the above mentioned information, but, of course, in a non-readable (and hopefully annoyingly difficult to decode).

Then, just before compilation, a check is made on all GBAL files - if they are not registered or invalid then they are ignored from the linking phase, creating an error.

This wont get around anyone doing all the compiling from the command line, but if anyone is that desperate, then you can't do that much about it.




Kitty Hello

Certificates might be the right way to go. the problem is, when you are really evil, you could legally buy a library, then spend a day to find out how to get the C++ code of it by breaking the compiler. And then another week to convert the C++ back to GLBasic so you can use the library w/o the certificate.

The main problem is, that the GCC _must_ be fed with C++ source files.

Hemlos

Quote from: Kitty Hello on 2009-Oct-14


The main problem is, that the GCC _must_ be fed with C++ source files.

I had a thought  :S

Maybe im off-base here, maybe not..i dont know gcc format well enough, but i will give the idea a voicing..

You know how you load an image into memory to be processed without an actual file, when you use GRABSPRITE?

Is this possible with c++ to force the gcc to process information stored in memory as opposed to an actual file???

If this were possible...you could encrypt the gbal, forward and backward to the memory, of course to protect the contents of the gbal.
Bing ChatGpt is pretty smart :O

MrTAToad

Would it be possible to create .lib (or possibly .o) files ?

Kitty Hello

.o/.lib files have no connection to the GLBasic interface then...

I just saw, that GCC can read from stdin files. That might be an option to consider!

Hemlos

Bing ChatGpt is pretty smart :O

MrTAToad

Quote.o/.lib files have no connection to the GLBasic interface then...
That should be no problem - if an easy way to add/remove .o/.lib files to the LNK section (so the user wont need to keep doing it), that could be a way.