Loading from the encrypted data file

[SpiderPig]

I'm loading a few data files in c++ and have included these files in the publishing process (below) lod, data and strc are just binary files.

lua, mat, mdl, phy, shader, tex, ttf, wav, ogg, mpd, cfg, lod, dat, strc

Am I correct in saying that loading with ordinary commands like fopen_s() won't be able to access the encrypted files in data.zip?

I can think of a few workarounds, like not including those files in the data.zip and adding them manually after publishing (won't be encrypted but it's not really needed for these I guess), or maybe using the internal Leadwerks file commands?

 

Is there a way the publisher can change or retrieve the password used for encryption?

[gamecreator]

I believe Josh said in the past that the password is not available to anyone.  You can, however, zip your own files, with your own password and still use Leadwerks Loads on those (C code is available on the forums).  I don't know if fopen_s() or Leadwerks's ReadFile work on those.

[Josh]

ReadFile will work on your own zip files. If the encrypted zip files could be read that would kind of defeat the purpose of encryption. ?

[gamecreator]

Nice!  Bonus question: do the Stream write commands work?  In other words, could we write a save file or configuration settings to our own encrypted zip?  It sounds like we could.

[Josh]

In Steam you can specify a folder to sync. This is the easiest way to store settings online.

[gamecreator]

Users can turn off cloud syncing both by individual game settings and global Steam settings so I don't think that's a reliable way to store information.  I have no problem with creating my own file on the local drive but was just curious about the possible additional option.

[SpiderPig]

Thanks guys

[SpiderPig]

1 hour ago, Josh said:

ReadFile will work on your own zip files. If the encrypted zip files could be read that would kind of defeat the purpose of encryption. ?

So our own zips can't be read from, but the default data.zip can with our own files?

[Yue]

Only C++?, Not Lua?

[gamecreator]

9 hours ago, Josh said:

In Steam you can specify a folder to sync. This is the easiest way to store settings online.

I just realized that maybe you misread what I wrote.  I meant your Leadwerks StReam write commands.  In other words, if you can open a zipped file to read, can you open a zipped file to write to, for example with stream->WriteInt(2)?

[Josh]

To load a zip file, the engine does this:

static Package* Package::Load(const std::string& path, const std::string& password = "", const bool register = true);

Thereafter, if the register argument was true ReadFile() will be able to read any files from the package.

Exported zip packages created in the publish step use a different password for every single file and cannot be read from by anything except the engine, when it is loading assets. You cannot read the contents of one of these files with ReadFile(). If I gave away the secret code that generates the password, you could extract anyone's game contents.

The above will only work with C++, and this is unofficial functioning, since the default behavior just works without any fuss.

9 minutes ago, gamecreator said:

I just realized that maybe you misread what I wrote.  I meant your Leadwerks StReam write commands.  In other words, if you can open a zipped file to read, can you open a zipped file to write to, for example with stream->WriteInt(2)?

WriteFile does not work with Zip archives.

Why are you concerned with opening wav files using the C fopen_s() command? What are you trying to do with it?

[SpiderPig]

Quote

Why are you concerned with opening wav files using the C fopen_s() command? What are you trying to do with it?

I was using it to load binary files that had precompiled information for various parts of my game.  After adding those files into the package for publishing they couldn't load because I was using fopen_s() to load them.  (Plus the filepath was now different, being in data.zip)

 

1 hour ago, Josh said:

To load a zip file, the engine does this:

static Package* Package::Load(const std::string& path, const std::string& password = "", const bool register = true);

Thereafter, if the register argument was true ReadFile() will be able to read any files from the package.

Exported zip packages created in the publish step use a different password for every single file and cannot be read from by anything except the engine, when it is loading assets. You cannot read the contents of one of these files with ReadFile(). If I gave away the secret code that generates the password, you could extract anyone's game contents.

So a published game is loading its package with register set to false..?  Meaning I can't load my own extra files from data.zip using ReadFile() so I'll have to add those files after the publishing process as an extra folder or zip.

 

1 hour ago, Josh said:

If I gave away the secret code that generates the password, you could extract anyone's game contents.

Could a feature be added where we could use our own password?  And if our own isn't specified then the default secret one is used.  This would only be useful if it were possible then to load our own files from the package using ReadFile().

[Yue]

But let's face it, who cares about our assets?

 this happens, it's because our game is really famous, and in the end it would be good for you to modify it, okay?, as this system is fine, in the end I'll settle for changing the zip extension to pak, data, dll etc.

[Josh]

6 hours ago, SpiderPig said:

I was using it to load binary files that had precompiled information for various parts of my game.  After adding those files into the package for publishing they couldn't load because I was using fopen_s() to load them.  (Plus the filepath was now different, being in data.zip)

Why are these so important to hide?

6 hours ago, SpiderPig said:

Could a feature be added where we could use our own password?  And if our own isn't specified then the default secret one is used.  This would only be useful if it were possible then to load our own files from the package using ReadFile().

You can do that right now.. Create a zip file with a password and give this password to the Package Load function.

[SpiderPig]

7 hours ago, Yue said:

But let's face it, who cares about our assets?

 this happens, it's because our game is really famous, and in the end it would be good for you to modify it, okay?, as this system is fine, in the end I'll settle for changing the zip extension to pak, data, dll etc.

Encrypting assets is a good idea.  If you have a purchased asset in your game, you can't just upload it unencrypted.  Even if you don't mind it being used by someone else, the person who made it probably will

 

6 hours ago, Josh said:

Why are these so important to hide?

It's more for convenience than anything else.  Not having to copy over extra files and folders after clicking publish would be nice

[Yue]

3 minutes ago, SpiderPig said:

Encrypting assets is a good idea.  If you have a purchased asset in your game, you can't just upload it unencrypted.  Even if you don't mind it being used by someone else, the person who made it probably will

 

It's more for convenience than anything else.  Not having to copy over extra files and folders after clicking publish would be nice

I understand your point of view, but I don't even rock start games so much their efforts to encrypt their game resources, in the end many end up extracting those models for the benefit of the same game ("Modify") and this is allowed for the same users to make modifications to the same game, but this implies if our game becomes famous. 

[SpiderPig]

Ah you mean so users can create MODS for your game.  In that instance you could probably write your own publishing software, using the package system in C++.  Or just upload the game in it's raw project format.   Keeping in mind that all assets must be of your own making.

[Yue]

//Load any zip files in main directory
    Leadwerks::Directory* dir = Leadwerks::FileSystem::LoadDir(".");
    if (dir)
    {
        for (int i=0; i<dir->files.size(); i++)
        {
            std::string file = dir->files[i];
			std::string ext = Leadwerks::String::Lower(Leadwerks::FileSystem::ExtractExt(file));
            if (ext=="zip" || ext=="pak" || ext == "iso"  || ext=="dll" || ext=="lib" )
            {
                Leadwerks::Package::Load(file,"pass");
            }
        }
        delete dir;
    }

 

[SpiderPig]

Very nice ?

[SpiderPig]

I'm creating a password protected zip in C#.  What type of encryption does the engine use when loading a package?  I have a flag for AES I can set to 128 or 256 or off.  The zip file did load but no files could be read from it, and the passwordVerified flag was still false.

[Josh]

I do not know. It uses a crc table that is 256 elements in length to check if the password is valid.

[Josh]

It is very weird when I search for something and find myself asking the same question years ago:

https://www.gamedev.net/forums/topic/603062-minizip-encrypted-file-passwords/

Quote

I look through the crypt.h file which contains the decryption functions envoked by unzOpenCurrentFilePassword() and it appears to only support traditional zip password protection not the newer AES encryption version. 

/* crypt.h -- base code for crypt/uncrypt ZIPfile

Version 1.01e, February 12th, 2005

Copyright © 1998-2005 Gilles Vollant

This code is a modified version of crypting code in Infozip distribution

The encryption/decryption parts of this source code (as opposed to the
non-echoing password parts) were originally written in Europe. The
whole source package can be freely distributed, including from the USA.
(Prior to January 2000, re-export from the US was a violation of US law.)

This encryption code is a direct transcription of the algorithm from
Roger Schlafly, described by Phil Katz in the file appnote.txt. This
file (appnote.txt) is distributed with the PKZIP program (even in the
version without encryption capabilities).

If you don't need crypting in your application, just define symbols
NOCRYPT and NOUNCRYPT.

This code support the "Traditional PKWARE Encryption".

The new AES encryption added on Zip format by Winzip (see the page
http://www.winzip.com/aes_info.htm ) and PKWare PKZip 5.x Strong
Encryption is not supported.
*/