Lua File Encyption + Security - Developers

Didn't RunString come with the C++ module stuff in GM12? Why was it removed? Or was it just something that would get the global RunString?

[QUOTE=Acecool;43629830]I'm not sure what you want me to add. I created a system which prevents cache from being created; similar to how this is being described. If it's coded similarly then well yeah. What I did was rewrote the net system to handle unlimited data per message sent, added secure message signing. I also created the fileio system which lets me package data together; meaning, I can turn entire directories of files into 1 file with proper load order. You do need RunString; but I have overridden RunString on both the client and the server. The server-side prevents anything from being executed as an exploit prevention technique. For client-side, it requires salt, pepper and other keys to run code. Those salt/pepper and hash data is based on time, and a few other details. So when the server sends it to the client to run, they have a few seconds to execute before that code is worthless. You may consider doing something similar. The only way for them to get the inbound code is by reading packets of encrypted Lua, using a DLL to inject into GMod and hook into RunString, but as nothing is returned, they'd have to copy the code, the salt and pepper and the hash, then they'd have to figure out the mechanism of running the code to decrypt it in order to actually read it. Hopefully they'd be VAC Banned before they'd figure it out. If you want to talk security, feel free to PM me.[/QUOTE] Detouring the original C version of RunString will reveal all of your unencrypted code. All of that work is completely useless because everyone has to eventually run unencrypted code through the original C RunString.

[QUOTE=Nexus435;43630769]Detouring the original C version of RunString will reveal all of your unencrypted code. All of that work is completely useless because everyone has to eventually run unencrypted code through the original C RunString.[/QUOTE] ^ This. The only true way to keep your code secure from the client would be to precompile it (and maybe encrypt if you feel the need) and send it to the client compiled. Although, that would require a client side module.

Put it simply: There will never be a way to hide your code from the client if the client has to run it. /thread.

It doesn't need to be 100% secure, doing so would just be an intellectual exercise. Practically all you need it to do is stop any old kid from stealing it. People who would put the effort into the decrypt it would probably be good enough/have enough time to make it themselves so doing so would be a waste of time. It is the lazy coders for darkrp servers and ttt which you are trying to turn away. They will copy and paste bits they find and ignore errors. They wouldn't go to the extent of decrypting it, so it acts as a deterrent.

What's the [B]big deal[/B] if someone has your clientside scripts? Seriously, I'd make a dump of my server's clientside crap -- I don't care.

How interested are people in encryption in general? Not encryption to secure scripts, just encryption for whatever use besides that. I'm working on a C++ module that will have different encryption types but I want to know if I'm just wasting my time if nobody is going to use it anyways. It would work like it does below. [lua]local encrypted = Crypo.Encrypt("AES", "whatever string") local decrypted = Crypo.Decrypt("AES", encrypted)[/lua]

[QUOTE=Linda;43632306]How interested are people in encryption in general? Not encryption to secure scripts, just encryption for whatever use besides that. I'm working on a C++ module that will have different encryption types but I want to know if I'm just wasting my time if nobody is going to use it anyways. It would work like it does below. [lua]local encrypted = Crypo.Encrypt("AES", "whatever string") local decrypted = Crypo.Decrypt("AES", encrypted)[/lua][/QUOTE] [url]http://facepunch.com/showthread.php?t=1300756[/url] (Different algorithms/purpose, but worth a look?)

In the end, all you can really do is minify your code to just make it more difficult to read. Unfortunately this would also make debugging a huge pain in the ass so... :suicide:

[QUOTE=Willox;43632322][url]http://facepunch.com/showthread.php?t=1300756[/url] (Different algorithms/purpose, but worth a look?)[/QUOTE] Definitely worth a look. Thank you.

[QUOTE=Nexus435;43630769]Detouring the original C version of RunString will reveal all of your unencrypted code. All of that work is completely useless because everyone has to eventually run unencrypted code through the original C RunString.[/QUOTE] It's not worthless; it is to stop the people not skilled enough in making what you've created. You're right on the bit where the client will eventually have to run it on the original function though; the goal is to hope to fool basic scripts / injects by overriding the primary function in addition to blocking people using packet sniffers and the life. [QUOTE=Walrus Viking;43632348]In the end, all you can really do is minify your code to just make it more difficult to read. Unfortunately this would also make debugging a huge pain in the ass so... :suicide:[/QUOTE] I've heard of minify; it's a Lua obfuscator which could be installed on the server, right? If this were to be bundled with my fileio system, then all files could be turned into 2, or 3. client+shared and shared+server OR client, shared, and server. When I post-process these two files ( how I currently do it, when I am uploading the scripts to production ) I remove comments, non-needed white-spaces, new lines, etc. Minifying would also obfuscate. The goal would be to have 2 servers; a local dedicated for development, and a production which would only have 2 or 3 Lua files depending on how you prefer delivery. If anyone is interested in this system, or OP if you want to incorporate this into your release, pm me. It's very straightforward to recursively grab all the files and there are bits that's coded into my autoloader which auto-interprets files based on naming techniques, folders they're in and can even process map folder content ( In terms of which Lua to run on a PER MAP BASIS ). [QUOTE=c-unit;43630981]^ This. The only true way to keep your code secure from the client would be to precompile it (and maybe encrypt if you feel the need) and send it to the client compiled. Although, that would require a client side module.[/QUOTE] You're right. I'm considering writing a client-side module which would do more than handle this. I have figured out a way to get more than 128 players on one server. Technically it's not on "one" server, but it's possible to network multiple servers together. Coupled with the finalized shrinking system I made, and if a guy I know will allow me to use his map-render code ( He gave me a copy of it, still needs to be optimized but I'd want to talk to him once I finish the optimizations ) it would make sense that 256, 512 or more players could have fun on one map. The client-module wouldn't be to network everything primarily, it'd be for the protection, with a few additional networking hooks so that the client could connect to all servers at the same time while remaining only on one. If one server disconnects, it could allow for seamless transitions to the next. Rescaling a map the size of EvoCity V33 down to 25% would allow 16 Evocities to be running at one time. If you wonder how I get to 16 times the size by going to 25% here's how ( Top down view ): 1/4 One map: [] Divide by 2: [][] [][] Divide by 4 [][][][] [][][][] [][][][] [][][][] I know how to solve the issue with resizing vehicles which was my last step. It involves taking a preset car and scaling it down without a body. Then using a clientside model to render on top of the body and then all the animations would be mimicked over. Tested and working theory. Downside is all cars would be the same physical size unless additional base models are made. Once one is made, only the physics scaling needs to be upped. It needs to accommodate car, box-truck, bus and maybe a few in-between sizes. If someone knows how to rescale vehicles properly, let me know. In terms of bypassing the map brush limit, that's where the intelligent map render system comes into play. A few WAYWOs ago, a guy posted a video of him rendering a map in a map; I got in touch with him and we shared a few things back and forth. He allowed me to look at, and run the code. It's not optimized, it was his proof of concept and this guy is a fantastic and very intelligent coder. When it's optimized, a single map the size of 16 EvoCities could be made with no detail. Brushes would only cover physics / collisions, doors and stuff like that. 16 smaller maps for each sub-section could be created which would have all of the brush details in it. The beauty of doing this is that even with a massive map, the client would only be concerned about rendering 1/16 in their area. Worst case we'd be traversing 4/16 of the chunks. Viewdistance would need to be accounted for, to properly traverse only what's relevant. This means rebuilding the bsp on the fly; once. When it is done once it's saved to a cache file to prevent having to re-sort all the data. Source Engine is capable of being made into an large-scale multiplayer game. [QUOTE=rbreslow;43631189]What's the [B]big deal[/B] if someone has your clientside scripts? Seriously, I'd make a dump of my server's clientside crap -- I don't care.[/QUOTE] The issue is that if you do things as they should be done, in my opinion, the server only manages data; and spawning of certain entities ( players, vehicles ). Everything graphical should be handled client-side. I currently do my coding like this; the server doesn't do much aside from data management, spawning vehicles, spawning players, anti-cheat system, database connections, networking the data and a few other things. The client renders clientside models, textures and more. I handle clientside models so that a maximum of 1 per model can be created ( and render that one many times for each time it occurs ) meaning there is no entity for each vehicle attachment, or weapon on the back. Less entities means less lag. Additionally, by allowing it to be run clientside, the client can control how much detail you show making for a smooth and seamless game. If done properly; client-side stuff can be the most important in terms of how the server / game-mode is run. Interpreting data can take a lot of processing power, it's why the client should handle it as most of it is rendering and if we don't need to bog a server down, especially with MMO in mind, this is why there is a need for a client/shared script protection system. I honestly wish Garry implemented it some other way such as finding a way to compile the code so that it doesn't need to be interpreted before being executed. If Garry or anyone else could figure this out, we'd be in business for a true protection system. I did add a lot of additional detail which may or may not have been necessary. If you took the time to read it, I hope I've offered some insight. If you want the short version--------------------------: The users I responded to are absolutely correct; the code will have to be run through the original RunString ( If the memory address / location of this primary function never changes, which is quite frequent with how applications are programmed then the injection would only need to target it and never worry about it changing. Smart applications actually create a new location for things to be stored on each start ) at some-point unless you have created a client-side DLL to interpret compiled code or something. Blocking code, redirecting RunString blocks basic attempts at finding the code, but the work is not for nothing. It'll stop people who'd otherwise be unable to develop it themselves and limits the theft to a class of people who'd have the know-how to actually develop the work themselves rather than just decompressing it with a utility, reading unencrypted packets when transferring the code, or injecting into Garry's Mod and risking a VAC or Garry Ban in order to create a plug for data to be read and saved somewhere when you join a server. The OPs work, and the work I've done are to stop 99% of the people that would be out to steal. Personally, I help users on a daily basis with coding questions and share a lot of my helper-functions, including server functions; any ti

[QUOTE=SomePerson_;43622712]I'm not relying on people not to write a decompiler, I'm actually expecting people to. I've had a file stealer for years, many many years, and many other people have had them too. The people who make them are usually smart enough [B]not to release them[/B], though.[/QUOTE] They've not been 'encrypted' for many many years, pretty much only since GM13. I'm sure it was easier to read previously? Anyway, you say years yet you registered just to view this thread? Who's alt you be I wonder.

[QUOTE=Pantho;43633195]They've not been 'encrypted' for many many years, pretty much only since GM13. I'm sure it was easier to read previously? Anyway, you say years yet you registered just to view this thread? Who's alt you be I wonder.[/QUOTE] Matt's third alt.

[QUOTE=Pantho;43633195]They've not been 'encrypted' for many many years, pretty much only since GM13. I'm sure it was easier to read previously? Anyway, you say years yet you registered just to view this thread? Who's alt you be I wonder.[/QUOTE] You're correct. In GMOD 12, and possibly other versions, the cache was plain-text as far as I recall. Gmod13 did "something" for it by compressing the data; but it's easy to get around. If it's possible, via LuaJIT or whatever else, to create compiled code out of Lua, ready to run, it could not only increase the speed of scripts being run as it cuts out the most costly step of interpretation before being executed; but it would be more "secure" as it's harder to actually decompile code vs decompressing.

[QUOTE=Acecool;43633415]You're correct. In GMOD 12, and possibly other versions, the cache was plain-text as far as I recall. Gmod13 did "something" for it by compressing the data; but it's easy to get around. If it's possible, via LuaJIT or whatever else, to create compiled code out of Lua, ready to run, it could not only increase the speed of scripts being run as it cuts out the most costly step of interpretation before being executed; but it would be more "secure" as it's harder to actually decompile code vs decompressing.[/QUOTE] I don't think speed is currently an issue -- this would just be a waste of time. The system we currently use doesn't have any major flaws.

[QUOTE=Acecool;43633415]You're correct. In GMOD 12, and possibly other versions, the cache was plain-text as far as I recall. Gmod13 did "something" for it by compressing the data; but it's easy to get around. If it's possible, via LuaJIT or whatever else, to create compiled code out of Lua, ready to run, it could not only increase the speed of scripts being run as it cuts out the most costly step of interpretation before being executed; but it would be more "secure" as it's harder to actually decompile code vs decompressing.[/QUOTE] The pros/cons of adding bytecode execution don't weigh out. It's not secure and it is very hard to make it secure, and it also still allows code to be stolen/decompiled/modified just with a tiny bit more work. Just takes an extra few minutes to run LuaDec on the bytecode. Moreover, nobody would see any speed benefits because LuaJIT compiles the bytecode once. (only speed gains would be insignificant startup times from interpreting Lua to LASM - not at runtime) It's really the same. The argument is: Decompress with a LZMA tool vs. use LuaDec to decompile Both take the same amount of time to do. Outcome: no speed gains, [i]less[/i] security Just obfuscate your code people. Bytecode doesn't provide any benefits we don't have now.