I think , even with java you cannot access the files inside the zip without using ZipStreams ( i have gone through on android, it was not even encrypted) which extracts the zip file before doing anything , so for encrypting zipping will be the best choice if you have paid assets but also there would be possible performance issue & increased loading time , though you need to pack them again after the game finishes but if the game is actually not responding , your files are endangered because your project as decrypted them ,
So , I donot really know if you can attach your assets to an asset pack git private project & do runtimeOnly 'project:assets3.2' I didn’t try this , but I know that , some IDEs like IDEA can extract your libraries in a form of jar files (artifiacts) , should you try this & report ?
EDIT if you are building a game on android studio then you can use the Play ASSET Delivery API ( obb files) , that will do everything for you.
In a jar: anyone that knows a jar is a zip can access it
In a j3o: only folks who know what a j3o is and how to access that in a JME application can access it. (A significantly smaller set of people than the above.)
Rename extension to .foo but it’s still a .j3o: only highly motivated folks who bother to look deeply enough to figure out that it is the same can access it.
…now we are already in the realm of “JME developer” level person.
.j3o/.foo with custom control: only a JME developer who knows how to link in your .jars into their custom app can access your assets
literally any other protection you can think of short of decription in the shader: a JME developer who knows how to run your application within their application and/or hook into your application (add a key mapping in input manager for example) can access and dump anything they want. (And note that decryption in the shader is only a ‘takes a little longer to figure out’ style stumbling block)
How much effort do you want to expend to work towards diminishing returns. Already a j3o cuts out most of the world’s population.
I remembered now my old development days , I was using windows & wrapping jar files to .exe with launch4j , but I thought now , what if you can do this with encrypted or encoded exe instead , I donot know really if something like that exists (it would be the same as running .sh with restricted permissions) ,
EDIT : Back in 2018 , I have coded an Electronic Test project , it was in swing , I was training on data hiding , AES , cryptography & java File IOs , so , in the password file , I encrypted it using AES but it was plain txt file , other data are hidden by a powershell script & changed the folder names to something like .~name when my java code is not using it , i remember this cannot be opened by the windows file manager , also you have the opportunity to work around for a powershell script to overcome this part by some permissions , but it can be opened in Linux .
I thought the whole purpose of java modules was to give you the control of what is viewable from a user aspect?
If its not a public class in a public module wouldn’t it be unusable by others trying to hack?
Strong encapsulation—The packages in a module are accessible to other modules only if the module explicitly exports them. Even then, another module cannot use those packages unless it explicitly states that it requires the other module’s capabilities. This improves platform security because fewer classes are accessible to potential attackers. You may find that considering modularity helps you come up with cleaner, more logical designs.
No, that’s not quite the case… if you have modular code and you’re running your JVM with the standard module options, then yes, you can do some code hiding (though I look at this as more of a software design benefit than a security benefit - if someone untrusted is able to execute code unsandboxed in-process with your code you’re already in trouble). When someone else is running the JVM, it’s easy to bypass module protections and open up whatever you want to.