Jump to content

Loading from the encrypted data file


SpiderPig
 Share

Go to solution Solved by Josh,

Recommended Posts

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?

  • Upvote 1
Link to comment
Share on other sites

  • Solution

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. ?

  • Like 1
  • Upvote 1

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

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)?

Link to comment
Share on other sites

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?

  • Upvote 1

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

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().

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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.

  • Thanks 1

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

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 :D

  • Like 1
Link to comment
Share on other sites

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 :D

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. 

 

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

//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;
    }

image.thumb.png.0f66dd5b712404b5a1140d847edbef26.png

 

:D

  • Like 1

 

 

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

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.
*/

 

  • Haha 1
  • Confused 1

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...