47
Indie developer has a plan to keep parts of his game secret, even from data-miners
(www.gamefile.news)
Welcome to the game development community! This is a place to talk about and post anything related to the field of game development.
Anti viruses won't care as it won't be injecting executable code. But the whole idea won't work. To decrypt AES you need some sort of a secret key or certificate. So the game will have to have it bundled. Thus anyone with enough skill will be able to extract such key or certificate and decode resources themselves. Encryption will not provide any protection.
Stuff like this isn't there to stop people with lots of resources. It's to stop people who are lazy, will see encryption and go, eh, I guess I'm not doing that after all.
It's the baseline, make it annoying enough that most people won't even bother wasting their time.
I bet you that the whole thing will be decrypted and sent to torrents during the first hour of the game's release just to teach its developer a lesson.
How do you know parts of the encrypted stuff isn't executable code? Like is he has secret levels with secret functionalities then part of whats encrypted might get executed, or interpreted and executed or something like that.
If he's going out of his way to hide and encrypt secrets, I wouldn't be surprised if parts of his gameloop are obfuscated as well. And if Anti viruses detect high levels of obfuscation, that just raises flags as probabilistic malware
Modern CPUs and operating systems have distinction between data and code in memory. Usually only privileged processes have the right to make data executable. If you load some random stuff into memory and tell your CPU to execute it as a code, you'll get nuked by OS.
Not true. Only kernel can mark memory page as executable, but any process can request to kernel to do so. This is why JIT compilers work.
It sort of looked like you'd construct the key by input. Like an old school password entry screen or something. I wonder if you could correct horse battery stapler it enough to have a respectable key length.
The only way is to hold that secret key on your server until the day of content release. But that is basically a lite version of always online DRM.
Yeah, that's the only real solution.
When I first started working on malware for my offensive cybersec job, I felt pretty at loss about how the fuck are you supposed to execute anything, if you simply have to 1) allocate memory with READ_WRITE_EXECUTE, and then 2) execute the memory.
I thought that's something that legit programs don't have any reason to do - why would you ever need to allocate RWX memory? I've never done that in my entire programming career, and every bit of your code is already loaded into memory once you start the program - at a special, protected part of memory. There's no reason to ever allocate anything manually. And I spent a lot of time trying to figure out how to deal with this issue when writing malware, since I kind of expected that once you try to allocate RWX memory manually, and god-forbid execute it the AV will simply not allow it and flag it as highly suspicious.
Well. It turned out that actually almost everything I've ever written does use this call. A lot. That's when I learned what "JIT compilation" means, and that I've really misunderstood the basic concepts of C#.
So, surprisingly, most of programs you run (that are in C#) actually inject executable code at runtime. Although, I'm not sure if Unity actually doesn't compile into something that's not JIT C#. I guess only if you use ILL2CPP?
If the Dev were to take, for example the x,y position of the player and convert that to a key, then there would not be any bundled key. This could allow specific conditions to be met without specifying the key or solution. Truthfully though, I don't know much about AES to know if that's possible.
You still need
As I said, I bet everything will be decrypted within an hour of release.