I'm aware suggestions on this topic come up constantly, and are regularly denied... But this one is a little bit different.
This suggestion would accomplish two things:
1: Decrease the size of .dmb's by a considerable amount.
2: Help improve the security of .dmb's against decompilers and advanced memory editing.
Explanation:
Back when I was looking at the 4k competitions and things like that, I got used to writing code using only single letters for any objects, procs, or anything that wasn't a string. Then I realized, this would be great if I could find/replace all the object types like this in a normal project to decrease size. Unfortunately there are far too many instances of that object to be able to just do that... But if it was implemented IN the compiler...
What would be done:
When you compile a game into a .dmb it would do exactly what I just mentioned:
Loop through every single object type and variable name, and replace them with A, B, C, etc... Then once you ran outta letters you would go to AA, AB, AC, etc. And if you ended up using all those, then AAA, AAB, AAC, etc.
Of course you wouldn't be able to do anything with strings in this... But still. It would make it much harder for someone using a memory editor to have any concept of what proc does what, and in turn makes something that would only take 5-10 minutes to do before take hours (in a large game). And for people who decompile .dmbs... well all they'd get is a whole bunch of gibberish. The only indication they would have of what did what would be strings.
ID:132946
 Jul 21 2009, 3:02 pm
|
|
|
Jul 21 2009, 3:32 pm
|
|
Nikodimus
 |
Compiled code ignores variable name length. X will take up the same space as ABCDEFGHIJKLMNOP once you compile. Using variables that are as short as possible and failing co comment your source code reduces the readability of the source code, but does nothing for decompilation difficulty or memory editing since var length and comments are ignored in the finished executable.
|
Obfuscation of variable names does not stop decompilation, all I would have to do is not use the variable names and it would automatically generate new names for them based on context.
| |
Slurm wrote:
Obfuscation of variable names does not stop decompilation, all I would have to do is not use the variable names and it would automatically generate new names for them based on context. "IT would generate new names based on context"... What exactly is that supposed to mean? It can't be implying that it would generate relevant variable names to their intention because the decompiler has absolutely no way of understanding that... I don't get your point. | |
1. .DMB size is little bigger than all your .dm codes, however if there is map, it might take big part of .dmb. I've never seen huge .dmb so it's nothing to worry about, would be nice if resources had some compression. In ALL games (not only BYOND) graphics and sounds and way much more space than coding/programming does
2. If dreamseeker.exe can read the code, and debug, means someone else is able to make decompiler too. To prevent memory editing they would need to encode every value in the memory, that would take a lot more CPU, while it already not too fast | |
Most commercial grade disassemblers don't grant you nice variable names, but they are still very powerful and useful tools. I think you must bear in mind that if an individual has the intellect to properly use (and in the current environment, develop too) a DM de-compiler, they probably also have the intellect to read obfuscated code.
| |
Variable names are only stored in one place, so they have minimal impact on the size of compiled code; you would save a few bytes at most. In fact replacing them would actually make the datum.vars list unusable, breaking games that rely on that mechanism. As Slurm said, a decompiler probably wouldn't give you some of the var names anyway, but it doesn't matter because you could study the decompiled code and get a sense of what they all do. Munging the var names ultimately wouldn't help code security.
In princple though I don't have any objection to improving .dmb security in a meaningful way. There's no reason for instance a .dmb couldn't be encrypted. Encrypting .rsc files to improve their security even by just a little bit is already on the to-do list. Lummox JR | |
This is the first word on this topic I've heard from the BYODN staff that was positive.
Yay Lummox. *Clap* Unfortunately since I was misinformed on how decompilers work and the memory editing thing, it still wont protect against memory editing. :( | |
AJX wrote:
"IT would generate new names based on context"... What exactly is that supposed to mean? It can't be implying that it would generate relevant variable names to their intention because the decompiler has absolutely no way of understanding that... I don't get your point. Analaysis of how the variable is used can net a relevant name, it may not be entirely accurate, but it usually is. | |
Slurm wrote:
AJX wrote: You confuse me. I can't imagine a situation where any program, even one that is ONLY meant to analyze programming (not decompile stuff) could even begin to produce a relevant name for a variable... The most I could see is giving it a name based on the data it holds. I.E: String1, String2, LargeInt1, etc... Can anyone verify or deny this? | |
Falacy wrote:
Easy way to prevent memory editing: don't let random noobtards host :( Noobtards == 99% of the population. :( :( | |
AJX wrote:
You confuse me. I can't imagine a situation where any program, even one that is ONLY meant to analyze programming (not decompile stuff) could even begin to produce a relevant name for a variable... The most I could see is giving it a name based on the data it holds. I.E: String1, String2, LargeInt1, etc... I don't think he's saying a decompiler can do that, although in a game environment I don't think it's outside the realm of possibility for a decompiler to make educated guesses. More likely what he means is that names like var1, etc. are going to be generated, and the programmer can replace them with something more descriptive based on an analysis of what they do. In BYOND's case the var names for objs and mobs and such will be preserved anyway, and I believe globals and proc arguments as well. Really about the only place a var name would have to be reconstructed would be a local var. Lummox JR | |
Educated guesses can be also more easily made once it takes into account where else the variables appear, so, if it appears in a statpanel beside the word gold, or banked cash or something, it would infer obviously that it is the value that is stored by that variable.
It would do a whole-code overlook rather than just what the verb itself does, and would look into where else the verb is used as well to determine its meaning. | |
Well, the DMB has a map descriptor section, as you only have one map (new features notwithstanding).
| |
Lummox JR wrote:
In BYOND's case the var names for objs and mobs and such will be preserved anyway, and I believe globals and proc arguments as well. Really about the only place a var name would have to be reconstructed would be a local var. Even the local variable names are preserved (currently, anyway); the major issue that prevents "perfect" decompilation is that none of the variable types are recoverable. | |