thx alot! I will try and see if I can get this working when I get some free time. I guess zip encryption is pretty crappy - it would offer some form of protection tho.

Hallo HeelX,
your code seems to be all right, I pretend you have to download the "zlib.dll" and include it to your project. The resource_xx dlls only work with existing zlib dlls.

Regards
Sinthoras

Ok, finally it works, so that I got my password.txt.

Questions:

1.) I need to enter that zipstring, but when my mainwdl is not encrypted, hwo do I have security that noone takes the decrypted strings, passes it through the system and gets the correct password string?!

2.) I've done a small app with dozens of bmap definitions and a lot of panels. So, I zipped all used TGAs into the resource.zip with the right password, but while compiling the engine complains that it doesnt find the related bitmaps. So I changed every bmap definition just with bmap and the name and then semicolon, in a small loader function which is called after opening the resource archive, the bitmaps are assigned with bmap_create, but this didnt worked because the bmaps werent defined as pointers. So.. I changed everything to bmap* pointers. Then, the compiler complained that I cant use bmap pointers to declare which bitmaps are used for panels, buttons and stuff.

Does anyone know a good solution for this?

[EDIT]

I found an ugly fix: You define every panel bmap with a dummy-bmap and then you bmap_create the panel bmap after adding the resources, but then you have to update the size_x and size_y parameters. The problem are especially for panels: buttons! Because the given button-bmap determines the size of the button and (as I know IMHO) you cant change bmap and size of a button yet. ARGH [EDIT2] And I dont want to create all my panels dynamically.

[EDIT3]

One feature request: please add a string to the add_zip_resource_PW function a second string parameter to allow multiple archives, for instance resource_models.zip and resource_sounds.zip, etc.

[1] simple solution - keep your password in dll, don't pass it via c-script (reserve space in dll code for it and write your password with hex editor or make util for that)

Concerning the first question:

That problem is solved by the two versions of the dlls. Being the developer, you take the "_dev.dll" with the encrypt and decrypt functions. You can write the password.txt file with easy call of them.
Now, in the release version, you only include the ->release.dll without these ones (especially the decrypt function).

The "hacker" only can view the uncrypted string in your main.wdl and doesn't have the possibility to write a password.txt file (because he/she only has the release version).

The only problem is that the "hacker" could copy your .zip file AND your release.dll and than has access to the data ingame. But it would be a very unconfortable way, he/she would have to call a function that creates the model out of the working space to another folder.
But the real .zip password wouldn't be shown at all.

@second string:
At the mom I don't have time to develope it. Maybe anotherone is able to? The source code is posted already..

Regards
Sinthoras

well , considering how every single game out there (even all the big commercial ones) get cracked by hackers , i dont see why such a level of security is needed for a low budget gamestudio title , i think having a password on there in the hidden txt files is way more than enough to keep the regular people from copying the game , which is all u really want.

Well, yes and no.

Most artwork done for a game is customized, especially models, sounds, fonts and panel stuff. I'm not so a artists, more a programmer, but especially when I'm doing an A6 app with some special code which is my own, because I built on myself. I do my things usually modular so that I can reuse stuff in later projects. I dont want other people to use my code when I dont want it. When I made some incredible piece of art, I want to protect it. I dont trust people I don't know. Especially when I release an unprotected 3DGS project here I'm sure that some ravens come and took my jewelry away. My code is my baby. And I love my baby. And if someone comes and wants to steal it.. well, he can be sure that he will be hauled over the coals, seriously.

Additionally, it would have positive side effects, too I could provide the user an option to select the texture quality by providing zips with levels with lower resolution textures or additional packages with additional content or stereo sounds with higher quality that mono sounds.. or else.

The zip file format is a common format. Zip file password cracking software is available, and it could be stated that a file in .zip file format is more easily cracked because that format is common. It also might be stated that a file in a newer Conitec .rsr file format is not so easily cracked because that format is less common, and there are far less cracks available for it. Thus, it might be useful to create a unique file format, and decompression/compression functionality using known compression algorithms, especially for those that are using any version lower than the Professional version. A utility with a GUI might be created to aid in the compression of project files to the hypothetical format. The source code for decompressing the files to the buffer, might probably be "closed source" and no functionality for decompressing the format to separate files would likely be created.

This was hinted at by Lion_Ts.

Quote:

---

And for last word, you may write your own archiving/encrypting methods, may be better than zlib. And use similar code to add buffers to engine file system.

---

While there are certainly those that are more able or willing to implement such a thing, I might be willing to take a "stab" at an implementation if there are no adequate volunteers and there is a fair amount of interest. Unfortunately, Conitec is all to clever, making it a requirement that I first "purchase" the SDK before I distribute such a "closed source" implementation.

I'm currently trying to compile it ^^

The implementation of a new compressing mode is a very interesting area .. maybe I'll try something (but I assume not as soon as appreciated)
The big problem with the SDK licence is that you cannot release any project without having one.
If you do, the cryption formula code has to be released, too, a matter that makes it absolutely senseless. The hackers only have to copy the code and crypt your string in the mainfile to get the password.

Means, anyone who wants to develop a new cryption method or even just wants to use the simple .zip one has to have the SDK licence.

Sure, if there would be anyone who has purchased it already and develops a new compressing UI and so on, the 'normal' users without can use that. But then it will cost money as well, because the developer has to earn the money for his licence ^^


[EDIT]
To all trying the posted code:
if you use version 6.4 and above, "add_buffer" requires a size parameter. "add_buffer(char* name,void* buffer,long size)"
You just have to add a little piece of code..
Code:

---

   add_buffer(filename_withoutpath, buf, size_buf);

---