so.. here's some stuff from the ue4 elemental demo:



What I want to say with this is that you can access everything thats loaded into the ram at runtime and monitor every single drawcall.

Edit: so as long as you don't encrypt your textures & meshes and decrypt them everytime you need the information by using vertex and pixel shaders you can't make your stuff unaccessible

Thanks that was alot of usefull information!

, yes the BSP and portals ( scene manager ), I was wondering if it could be used for preplaced models too, but its only for blocks right? I am working on a own realtime map editor (but no WED placed block support I think but it does have WED-like compiling) and its hard to get back to WED .

, so using a simple script made in e.g. visual studio is the only way to overhaul it? I need to change it for some program. For games I can live with it, but for programs its just really awkward.

, that sounds really handy. I don't mind if the best hackers out there can hack it, just as long as it protects against most c&p people I am happy .

Off-Topic2: Also possible with QuickBMS

It doesn't make a difference whether or not WRS unpackers exist, as already mentioned multiple times before in this thread you can "hack" any game and extract resources. They - the "hackers" - are not allowed to use your stuff anyway.

@Reconnoiter: The so called portals are generated automatically by the map compiler and used by the BSP tree but only for WED blocks, yes.

Just trying to keep the forum alive

First 4 bytes of a WRS telling you which WRS format it is.
A8 uses WRS4 (0x57 0x52 0x53 0x34), followed by 32 bytes for the name.
Now, thats the header of the file. How do we decrypt it?
After every 32 bytes, the name of the file follows.
Now we simply XOR all the data content by the value 0xAA for WRS4.
This works for every gamestudio WRS packer since A4.
The only thing changed was the XOR byte.
Pro: XOR is fast
Con: Why not change the XOR bytes with the current reading offset? Thats so easy to reverse..
Would take some more time to figure out...
Seriously, just pack a .exe in WRS and look at the first 2 bytes (always MZ, called PE Signature)
Now you can simply figure out which byte was used to xor (simple math)

@Superku, thanks for the info.
Its a shame it actually does not work for preplaced models/terrain. Could it in theory be possible?
Or are blocks just to different from models?

Because to make it effectively secure you need a key of the length of the content, and the key can't be ever shared with anyone you don't trust. This would essentially be a one time pad. It would also be useless, because you either share the key and obfuscate it in your binary somewhere but have it still accessible to unpack your data, or you don't and your users won't be able to play the game anymore.

It really boils down to the following: At some point you have to access the data on the client machine. So the application itself has to somehow be able to unpack them.

You can obfuscate it, or do hacks like having a slave .exe that launches your actual .exe and attaches itself as a silent debugger to it. Windows only allows one debugger attached per application, so it makes it harder for third party to attach a real debugger and watch the execution of your program.

Really, the only reason you probably want encryption and resource packs is for updates: Sign your resource packs cryptographically and check the signature at runtime. That way you can at least make sure that no one is supplying malicious updates to the user.

Well your completely right here.
But most people wont even try to decrypt the file when they notice that the encryption is not only xored by a byte or dword.
All Im saying is to make it a bit harder for those people out there
Btw, you can detach a debugger from a process.