Username or EmailPassword
why patented?... ugh... seriously.
Oh, and obfuscation is stupid.
I will probably regret allowing myself to be goaded into a reply - but here goes.
PreEmptive does indeed have a patent on its renaming algorithm termed "overload induction" which extends typical renaming algorithms based on scope to leverage OO overloading patterns so that methods that have different signatures can be renamed to the same name.
As for obfuscation being "stupid" - i think that's kind of funny since we are using it on smartphones. In fact i just wrote a blog on the "dumbphone" as the first anthropomorphic retronym here - http://apps-are-people-too.blogspot.com/2010/11/phone-by-any-other-... Edited 2010-11-16 01:52 UTC
Wait, so using OO programming to rename stuff = a new/original idea somehow?
Are you making some really weird offtopic bridge to spam to your blog or am I missing something? Edited 2010-11-16 17:35 UTC
...between hardware/software providers and the app developers they serve? As long as the code cannot be used harmfully, they should just sit back and enjoy the myriads of apps that pop out of all the clever developers.
Heck, when I worked for DEC my boss, Gary, (RIP, one of the most amazing programmers who ever lived) figured out a way to identify undocumented functions in the FMS libraries that were extremely useful for fine-tuning our applications.
He documented them and we used them and altho' the FMS developers warned us that their stability could not be guaranteed, they never changed AND if they had, well, we'd change our code, or just never upgrade to the version that broke our code.
My LoonCAFE project supports highly evolved Code Obfuscation for applications... using an extremely simple method:
Automatic object/function/variable renaming and re-ordering per build. For debugging purposes, a program is being written to interpret back-traces for a given build.
Can be rather hard to figure out what d369_a41:phyt43->ji484(juj*, djd8&) is doing when the internal code is:
::_m89r = oopdd_1(djd8_0);
::asm("mov ax, CR0");
And even more difficult when it all changes order in memory with subsequent builds :-)
Not full proof, naturally...
They ported Perl to Windows Phone 7?
There are no news here. It has been trivial from the beginning of .NET to decompile and get the source code of any assembly (DLL, EXE...). It's fast and easy too. Microsoft never have hided that. De facto, every managed code is open source (which is very different of free software, of course). Any version of .NET on any platform is the same (Windows Mobile, XP, Vista, 7... Yeah, Mono too). If you can't decompile it, it is not managed code.
What's new, now? Security concerns? The source code to Linux is easy to get too (not as easy, but easy), and nobody complains about that. A lot of people even thinks of it as an advantage. Think about it: you can take a peek at the code of every app you use an really know if they are violating your privacy, or other nasty things.
Obfuscation? Microsoft is talking about that since, I dunno, 2003? The rule is: if you don't mind people looking at your source code, you do nothing. If you don't want people to do that, you obfuscate the code using any of the tools available (choose one). If you can't live with that, don't use .NET. Or renounce to distribute your software, because everything -.NET or not- can be decompiled; the code can get very messy, to the point to seem to be obfuscated, but that's all.
I'm not a programmer so I have to ask this stupid question. Will obfuscating the code affect its performance? From what little I dabbed into it I thought you wanted clean code for performance reasons.
You do want clean code for performance reasons. But not all aspects of clean code has a performance aspect.
The compiler will generate just as fast code if you use stupid names for classes, functions and variables. It's just harder for people to understand.
What about loading encrypted assemblies, as the assembly loader can load byte array (would require you to load all the assembly data in the memory though, and probably a clever way to store your encryption key). while I think the memory usage might be a little high (if you are using a mobile device), carefully splitting your implementation in multiple assembly might help mitigating the problem.
Obfuscation is one way to hide your implementation, but as there has always been a race between obfucator and de-obfuscator it seems like you will be loosing anyway as you cannot predict if the obfucator you bought would hold long enough, I would prefer encryption.
I would say probably into your licence key, or in a system string.
I agree that encryption would give a single weak point, but I would only be cracked by the motivated people. whereas right now disassembling is just a click away (or a few command away anyway). giving one extra step might discourage most of the hacker wannabe.
Even if I am sugesting a solution, I would say giving people a mean to see your code, might give them more confidence in it as they would be more sure that your application is doing what it is suppose to do.
What would be your solution anyway ?