• Advertisement
Sign in to follow this  

The Value of "Obfuscators"?

This topic is 4267 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I recently posted about my intent to take a game I had started developing in C++ 6.0 and moving it over to .NET. One respondant brought up the point about the easy-decompilation nature of .NET assemblies. Can anybody speak to the value (or lack of value) of obfuscators? How good are they at preventing decompilation? What is the effectiveness of the "Dotfuscator" edition that comes pre-packaged with VS.NET versus a third-party obfuscator. Finally, if I want to be that protective of my source, should I bother with .NET, or stick with 6.0? Thanks.

Share this post


Link to post
Share on other sites
Advertisement
This only applies to C# code, afaik. With Visual Studio .NET (also called VS7.1, etc), you can still write unmanaged, non-.NET framework C++ code. This code will compile to a regular PE .exe format.

Are you thinking of moving from C++ to C#? Or just from VS6.0 to VS8.0 (the Express Edition or VS 2005 Standard or something (a good idea anyway since 6.0 is pre-standard C++)?

Share this post


Link to post
Share on other sites
Why are you so keen to protect your source code? Surely it is not going to be usable to anyone else because:

- They aren't going to be able to use it legally anyway because you'll retain its copyright
- Decompiled code won't contain comments or documentation
- Your data are all copyrighted anyway and it won't work without it
- They won't have documentation on your data formats etc

What exactly, is the advantage of someone being able to read your source code?

If it's to prevent unauthorised modification, it's flawed as well, because hackers will attack code even if it's native-compiled anyway. Unless you run on a platform with inherent DRM (Xbox live?), then you should expect your code to undergo unauthorised modifications.

They can still carry out various forms of multiplayer hacks, without modifying or viewing the code, notably in-memory modification of data which is essentially impossible to defend against.

Mark

Share this post


Link to post
Share on other sites
Quote:
Original post by markr
They can still carry out various forms of multiplayer hacks, without modifying or viewing the code, notably in-memory modification of data which is essentially impossible to defend against.

Actually, this is a Pro for using .NET, thanks to .NET including a level of memory protection.

I would suggest to the OP to get on MSDN and start reading. There are tons of articles on .NET, on its internals, on every-question-you-could-ever-have.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Are you thinking of moving from C++ to C#? Or just from VS6.0 to VS8.0 (the Express Edition or VS 2005 Standard or something (a good idea anyway since 6.0 is pre-standard C++)?


That's a whole separate issue (see my post called "MC++ vs. C#). I am very up in the air on that whole issue. I am, however, leaning toward a mix -- keeping performance-critical code and the more complex algorithms in C++, and moving some of the low-priority and utility items into C# for the easier programming. Either way, I'm planning on refactoring the entire program before I add the final set of features to it.

Share this post


Link to post
Share on other sites
Quote:
Original post by markr
Why are you so keen to protect your source code? Surely it is not going to be usable to anyone else because:

- They aren't going to be able to use it legally anyway because you'll retain its copyright
- Decompiled code won't contain comments or documentation
- Your data are all copyrighted anyway and it won't work without it
- They won't have documentation on your data formats etc



Good points. I also read on an older thread where someone said that unless you have a ground-breaking algorithm (which I don't, as far as I'm aware), there's really nothing that someone can't copy anyway -- even if by coding from scratch based on observation.

Marketing my game was never a consideration until several weeks ago (this has been an on-and-off project for me for 2 years). While I'm not new to programming, I am new to potential widespread distribution. As such, these are issues I am now considering. And since this has been my baby for 2 years, I'm probably overly protective about it. Even so, I'd rather at least have some level of protection and make it as difficult as possible to copy.

I guess in the end I just have to good graces of the majority of programmers -- who are far too busy with their own projects and innovations to worry about copying what's already been done.

Share this post


Link to post
Share on other sites
Hi,

I know good Obfuscators exist for Java. I realise you are now probably thinking "Java, does he have the mind worms? I'm asking about .NET!" but hold on there skippy!

Back to my point. Good Obfuscators for are Java are actually able to rearrange Bytecode improving its runtime effiency and memory footprint/size on disk.

I am not sure how similiar MSIL is to Bytecode, but I assume good .NET Obfuscators would be able to do similiar wonderful things.
My main point being using an Obfuscator can have other added benefits to just making your assemblies harder to reverse engineer.

If you are interested, purely for knowledge, I can find and paste some links to articles about the Java Obfuscators, as for .NET you are on your own there :P


- Chris

Share this post


Link to post
Share on other sites
Fact.
If someone would like to get and algorithm from an heavily encrypted and obfuscated machine code, with antidebug features, he would get it. If someone would like to modify such code, the worst thing you could do to him is forcing him to modify it into standalone version.

If you'd like to enforce something else you'd violate right of customer, and crash several other programs. (Some of them that unimportant like sheduler and possibly kernel...) It would be very likely your program would be unexecutable anyway, and possibly recognized as virus. Some kernels are attempting to verify the program, so antidebug features could do problems to them as well.

Fact about obfuscators in Java.
Sometimes they will mangle JIT so much it would badly compile the program, because it's unable to recognize that pattern anymore, sometimes if they are abusing some known bug they would create nonexecutable code (You'd find it few years later when that bug would be repaired.). Theirs main value is for 4KB code contest. You know that contest where contestants are stripping away the main method because they would save 4 bytes. (BTW Java programs could run without main method.)

And sometimes when you'd obfuscate your code, and then decompile, you'd see much more readable version of your source code... (Of course no comments, but if you didn't do them in first place...)

Share this post


Link to post
Share on other sites
I have said this on other forums and might as well say it here, you are not going to keep hackers from cracking your code. Doesn't matter what you do, with current technology the hackers will always win, you might slow them down and let them have some fun by giving them a challange but they will still crack it and they will release it on to the web.

So keep the honest folks honest and don't think about stopping hackers because you won't. So spendyour time on your program and not on anti-hacker code.

theTroll

Share this post


Link to post
Share on other sites
Quote:
Original post by markr
Why are you so keen to protect your source code? Surely it is not going to be usable to anyone else because:
- ...
- Decompiled code won't contain comments or documentation
Mark



if im not mistaken, the compiled .NET has the comments inside too

Share this post


Link to post
Share on other sites
Just did some reading and from what I read NO comments are including in the compiled version. I knew this to be true before .net stuff so I just thought I would check. The compiler ignores the comments unless it does an extraction for you to make your own documents, these documents have nothing to do with the binary you just made.

theTroll

Share this post


Link to post
Share on other sites
Quote:
Original post by Iftah
Quote:
Original post by markr
Why are you so keen to protect your source code? Surely it is not going to be usable to anyone else because:
- ...
- Decompiled code won't contain comments or documentation
Mark



if im not mistaken, the compiled .NET has the comments inside too


you are mistaken, not only are comments NOT included, they do not include YOUR source code at all. It includes the compiled IL code. A decompiler, like reflector simple names variables things like string1, string2, int1, int2, int3, etc... based on the instructions it sees.

Everyone at all interested if this topic should simply google for Lutz Roeder's .NET Reflector and download and use it (you load an assembly, and then browse to a class and click Disassemble from a menu option. You can read class headers (including attributes), functions, etc ... all of this information is simply a strait decompilation of the IL, with variable and internal names made up where they don't exist.

You can (and should) also use ILDASM at least once to see what is actually present in your file directly. This is a view of the source IL which Reflector is using the code dom and some smarts to decompile.

Share this post


Link to post
Share on other sites
my bad, sorry.

I remembered seeing comments inside the compiled code but I looked again and they are just "comments" of the type

// Code Size 24 (0x18)
or
// end of method CTilePicture::AddTileChangedHandler

no real comments in there.

ps. I did see source code (and variable names) in there and almost made a fool of me again, but turns out the smart ILDAsm knows to read the source files. Without the source file I couldnt find any source/variable-name/comment in there.

Share this post


Link to post
Share on other sites
I would just like to point out something which people may have been confused by from earlier posts:

Obfuscators DO NOT (typically) improve the runtime performance of your application.

.NET and Java applications are compiled by their JIT already, which does significant optimisations. An obfuscator will typically make changes which have little or no impact on this process (e.g. renaming methods, variables). Some obfuscators do a small amount of optimisation (inlining constants), but in reality, they're just pre-empting work which would be done by the JIT anyway. The end result is the same.

The reason that we use obfuscators for J2ME is because they improve the size of the .jar and *perhaps* the startup time. They normally should not have an effect on *runtime* performance, only download / startup time.

The obfuscator I use renames all your classes and members (vars and properties) to the shortest unique name it can if possible. This of course reduces the size of the binary but does not otherwise affect it.

By all means use an obfuscator for these reasons, but *DO NOT* assume that it makes your code much harder to reverse engineer.

Mark

Share this post


Link to post
Share on other sites
The point of obfuscators is to make certain important code (such as serial key checks) difficult to understand and/or remove or to make it difficult to write automated players or player assistant programs for a game ('aimbot' etc). If used properly, it's very effective at slowing down reverse engineers. It won't stop them, and it won't slow down the top experts much, but it will help limit the number of cheats, cracks, etc because most people won't have the skill or patience to reverse the obfuscated code.

Share this post


Link to post
Share on other sites
You are right the point of obfuscators is to make it harder to crack your code, the problem is it does not work. Any hakcer worth his salt is going to rip through your code with or without obfuscation. Yes it might stop people without as much skill but with the internet the crack that the hacker come up with is going to be in general circulation in days. So all you will be doing is making sure that only the good cracks make it out because the people without as much skill will not be cracking it.

In my younger days, a long long time ago, I used to crack software. Yes I know it was wrong, yes I am a bad person. To me the more work you put into keep me out the more fun it was and the harder I would work on it. We had small groups of crackers that would get the new software as soon as possible after it was released, it was part of the game to be the first on to release a crack, or cracked version. From what I have seen this has not changed. So in the end nothing you do with pure software is really going to slow down a decient hacker for more then a few minutes.

theTroll

Share this post


Link to post
Share on other sites
Quote:
Original post by TheTroll
You are right the point of obfuscators is to make it harder to crack your code, the problem is it does not work.[...]
Actually, it's very effective. Yes, any skilled reverse engineer can wade through the code eventually, but just look how well star force protected programs resist reversing. Yes, part of it is due to their entirely shady drivers of death, but it's also due to obfuscation. For .New programs, I can't say how effective it is, but for native x86 binaries it can be very effective because there are so many obscure and rarely-used instructions that can be used to emulate other instructions, and throwing in a virtual machine to handle part of the code (as any good obfuscator would do - you want obfuscation and virtualization together to be effective) makes it very time consuming to reverse. If you're a HUGELY popular program, your game will be cracked before it's out. If you're an indie, however, you won't be a huge target and obfuscation can deter the few that might consider trying to make cracks and/or cheats for your program.

Of all the possible protection methods, obfuscation is the best because it takes no programmer time (just buy an obfuscator) and yet provides an equal or greater level of deterence to any would-be crackers/cheaters/etc. It's not perfect, but it's the best there is (without delving into the dark side) especially in terms of the time consumed to effectiveness ratio.

Share this post


Link to post
Share on other sites
How many times have you cracked anything? It looks like you are talking pretty much without experience.

Starforce was cracked, and possibly there is even autocracker program that works on an old version. Of course the lastest info from cracker groups isn't easily available to prevent anticrackers work to be too easy. So you might believe a behaviour of obfuscating/encryption program that could be rejected by any self protecting OS is hard to crack, while there might be a small program that would make it in 15 minutes. (The next two days are spend by verification.)

Any copy protection system that installs itself as a hardware driver is violating some implied level of trust. The forced response of OS manufacturers would be 1. Alow to make a shit from theirs OS. 2. Prevent hardware driver maskarading type of protection to install itself. The long term benefical decision is of course the second one. I would be very uneasy if a strange interaction between the hardware driver, and a copy protection driver would singnificantly damage my OS. Things would really cease to be funny when a copy protection would disable part of functionality of the DVD burner.

Then there is the problem with cops. "Games are using copy protection, so they are protected enough..." Of course why bother with few (thousand) people without money, but if some software would be used by some institution against author will... ...and the author might have problem to do fast efficient action, because of a commonly shared strange idea of omnipotent copy protection. (Of course sometimes bootlegs are dealt with quickly, and sometimes you'd encounter...)

And here is a third problem. There are countries with customers right. There might be a law talking about copy of a something as volatile as a CD/DVD medium. I remember from programming a copy protection *1 program a few facts. It was a program for recovery of data from SEVERALLY damaged DVD (bulet hole level damaged). UV damage might be worse than bulet level damage, if not caught soon enough. A scratch made on the right place could be even worse. This takes me to the core of problem. The judge could decide you must provide your customers/people using your program, with a program that alow them to copy DVD with your program on a common computer with a DVD burner.

And a fourth problem. Copy protection preventing to run other legally owned programs...

I seen 24 karat gold DVD for 2$. With the right combination of offended customer, judge, and lawyers, the cost of CD with a software for copy protection could be not weight of a gold plate equal to weight of the CD, but rather equal to volume of that CD. So people should count twice, and be really careful before using any comercial copy protection.

*1 I used words copy protection in a meaning a something that would protect the copy, something that would alow recovering the data. It's funny how a meaning of words could change.

Share this post


Link to post
Share on other sites
Of course the above post is entirely off topic for this thread.

If OP would like to release something, he might consider to release it as a non comercial freeware. It's always nice to see your work used.

If that game isn't finished, I'd consider all that question as too much worry for nothing. Changing language at the end of a project is often bad idea, so if he is nearly done he might well continue in C++. If he is 2 years more until finish he might convert it into C# (or Java, or smalltalk, or OCaml, or whatever) and repeat this question after 2 years. C# virtual machine would be more common, and he might evade the two language communication problem. (Acording to people that worked/know something about JIT, it's impossible to drop interlanguage communication under 24 ops, and maintain safety.) Difference between 1.1 and 2.0 C# virtual machine would cause further problems, and I expect a lot of windoze users disabled automatical updates.

Share this post


Link to post
Share on other sites
Actually, you better use an obfuscator if you are worried about it. This is especially true if you spend 2+ yrs developing something that is original (or never been done before -in this case you may also think about getting a patent). At least it would give you some peace of mind that it would require them to spend more time and effort to reverse engineering it. If you are just developing the next FPS, then I think you are wasting your time with an obfuscator.

Share this post


Link to post
Share on other sites
If using an obfuscator gives you ANY peace of mind then you are fooling yourself.

theTroll

Share this post


Link to post
Share on other sites
Quote:
Original post by TheTroll
If using an obfuscator gives you ANY peace of mind then you are fooling yourself.[...]
It gives peace of mind because you know you didn't waste tons of time or put much effort into anything, but ended up with something as good as can be had anyways. It is logically impossible to secure code from an untrusted client, and thus all protection methods will fail against a determined attacker. Thus, spending a lot of time on protection is wasteful, but having some protection is good to thwart anybody that isn't an experienced reverser. Obfuscation provides exactly that - low-effort basic protection.

Share this post


Link to post
Share on other sites
I can tell you from personal experience that if you use the Remotesoft Protector (which is not an obfuscator, you would actually obfuscate then use protector) on your application than your code is gaurded better than a native C++ compilation. Using the framework you get the benefit of a lot of .NET memory protection which helps out a lot versus game hackers, which is great because using Protector really meant locking things down.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement