Linked by fran on Mon 15th Nov 2010 23:36 UTC
Windows Dismayed Windows App developers needed some assurances from Microsoft after news of the following incident got round. They got it.
Order by: Score:
by intangible on Tue 16th Nov 2010 00:22 UTC
Member since:

"patented renaming"

why patented?... ugh... seriously.

Oh, and obfuscation is stupid.

Reply Score: 3

RE: what?
by sholst on Tue 16th Nov 2010 01:33 UTC in reply to "what?"
sholst Member since:

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 -

Edited 2010-11-16 01:52 UTC

Reply Score: 1

RE[2]: what?
by TheGZeus on Tue 16th Nov 2010 16:52 UTC in reply to "RE: what?"
TheGZeus Member since:

Wait, so using OO programming to rename stuff = a new/original idea somehow?

Reply Score: 2

RE[2]: what?
by Carewolf on Tue 16th Nov 2010 17:11 UTC in reply to "RE: what?"
Carewolf Member since:

Google either already does this on their javascript programs, or they make really really ugly OO stuctures before their obfuscation step.

Reply Score: 1

RE[2]: what?
by righard on Tue 16th Nov 2010 17:34 UTC in reply to "RE: what?"
righard Member since:

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

Reply Score: 2

Why is everything a constant battle...
by Tuishimi on Tue 16th Nov 2010 01:21 UTC
Member since:

...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.

Reply Score: 7

Code Obfuscation Done Right...
by looncraz on Tue 16th Nov 2010 14:24 UTC
Member since:

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...

--The loon

Reply Score: 2

by fretinator on Tue 16th Nov 2010 14:28 UTC
Member since:

They ported Perl to Windows Phone 7?

Reply Score: 8

Old news
by Driht on Tue 16th Nov 2010 18:25 UTC
Member since:

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.

Reply Score: 2

RE: Old news
by japh on Wed 17th Nov 2010 12:54 UTC in reply to "Old news"
japh Member since:

De facto, every managed code is open source (which is very different of free software, of course).

And your definition is also very different from this:
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

Reply Score: 1

Will this affect the code?
by TaterSalad on Tue 16th Nov 2010 22:19 UTC
Member since:

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.

Reply Score: 2

RE: Will this affect the code?
by japh on Wed 17th Nov 2010 13:02 UTC in reply to "Will this affect the code?"
japh Member since:

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.

Reply Score: 1

Loading Encrypted assembly
by dvhh on Wed 17th Nov 2010 00:46 UTC
Member since:

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.

Reply Score: 2

RE: Loading Encrypted assembly
by Soulbender on Wed 17th Nov 2010 01:02 UTC in reply to "Loading Encrypted assembly"
Soulbender Member since:

I would prefer encryption.

and where would the encryption key be stored?

Reply Score: 2

RE[2]: Loading Encrypted assembly
by dvhh on Wed 17th Nov 2010 02:42 UTC in reply to "RE: Loading Encrypted assembly"
dvhh Member since:

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 ?

Reply Score: 2