corona Asset handling in Solar

Securing assets is a problem in Solar (especially for desktop builds) and we are often in breach of asset licensing agreements. I appreciate embedding encryption might be a big project so I propose that when a project is built that all of the assets get written to a BLOB. The API's would then use this BLOB. This shouldn't be too difficult a change as surely OOB files work in a similar way already?

The way I see it, it shouldn't be much more complicated than storing a table with a start byte index and byte length to "get" an asset from the blob to use in our apps.

All API's should function as expected and would require no code changes for developers.

This is something we would all really appreciate based on various discord discussions on the matter.

Dec 15 '20 00:12 marksolar2d

I couldn't agree more @mark-sgs

A couple of highlights based on some of the chats I've had with fellow Solar2D devs over the past few years.

This feature would be highly desirable because:

It simply makes the games/apps look more professional. I don't think I've played any non-Solar2D game on Windows in the past 20 years that left the assets out in the game folder, free to be copied via ctrl+c/v. Having all assets out in the open seems sloppy at best.
It will offer an additional level of security. Granted, it wouldn't be enough security to truly protect the assets from a skilled individual, but it would keep the script kiddies away, as well as "send a message" that the files aren't intended to be tampered with. It's like having a lock on your front door versus not having a door at all. People aren't allowed to enter your house whether you have a door or not, and a door won't stop a burglar, but it will at least signal normal people that you don't want them there.
It would prevent unintended (or untalented) tampering of the source files. I've played a few Solar2D made games on Windows. One of these games had gameplay related data (like a weapon's rate of fire, damage per shot, projectile size, etc.) stored inside JSON files, which meant that you could just open the JSON file and edit the values freely. With another game, the developers had created unlockable cosmetic content, but since these cosmetics were simply PNGs in the project folder, I could just change the filenames and instantly "unlock" the exclusive look for my character. Having the games be moddable is fine and all, but they shouldn't be this easy to edit.
Most 3rd party assets, like fonts and audio files, have strict license agreements that prohibit providing access to said assets for the end-users. By having some degree of protection, regardless of how weak or strong, would already make it legally possible to utilise said assets in our games/apps.

Simply having the files be inaccessible to the end-user without at least some knowhow, whether it'd be via BLOB or something else, is a direly needed feature for desktop builds.

Dec 15 '20 05:12 XeduR

The Discord comments mentioning zip files reminded me of this library. By the looks of it, you could use it to unify system.ResourceDirectory-based file accesses by mounting two "directories": the vanilla resource directory, then the archive with higher priority.

Comments in the source say "Extraction functions can only handle unencrypted, stored or deflated files.", so it wouldn't meet all expectations out of the box. I don't quite know how he's defining those terms, but I presume this is a limit on the archive itself, rather than per-file contents; it might reveal your file names, but they could be encrypted piecemeal. Another possibility would be to swap out the embedded zip library for one that does have encryption support.

Actually, if this direction is pursued, it would probably be worth shoring up the weird anomaly on Android, too. (Although this would involve AssetManager, instead.)

Dec 16 '20 00:12 ggcrunchy

Solar2D already employs similar format for storing Lua files, car. It lives in Rtt_Archive.cpp files or tools/car (I think it stands for Corona-ARchive). It is used to directly load Lua files from the archive file. Problems start with native Lua apis accessing files, like io.open(). On Android, some files can be read directly from APK, for example, while other files have to be extracted then given reference to user to be used.