Dismayed Windows App developers needed some assurances from Microsoft after news of the following incident got round. They got it.
Post a Comment
Member since:
2005-07-06
Member since:2010-11-16
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
Member since:2010-05-19
Member since:2005-09-08
Member since:2007-12-26
Member since:
2005-07-06
...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.
Member since:
2005-07-24
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:
::ohj_09(yhyhn_->PostMessage(oopdd(juj_0)));
::_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...
--The loon
Member since:
2005-07-06
Member since:
2010-08-16
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.
Member since:2005-11-11
And your definition is also very different from this: http://www.opensource.org/osd.html
You're going to confuse a lot of people if you call it "open source" when it is just about having the ability (but not permission) to generate some code from bytecode.
Edited 2010-11-17 12:54 UTC
Member since:
2005-07-06
Member since:2005-11-11
Member since:
2006-03-20
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.
Member since:2005-08-18
Member since:2006-03-20
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 ?