Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • 0

Loading from the encrypted data file


Go to solution Solved by Josh,

Question

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 post
Share on other sites

21 answers to this question

Recommended Posts

  • 0

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.

Link to post
Share on other sites
  • 0
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 post
Share on other sites
  • 0

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
Link to post
Share on other sites
  • 0
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 post
Share on other sites
  • 0

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 post
Share on other sites
  • 0
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
Link to post
Share on other sites
  • 0
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 post
Share on other sites
  • 0
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 post
Share on other sites
  • 0
//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 post
Share on other sites
  • 0

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
Link to post
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
Answer this question...

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

×
×
  • Create New...