Dismayed Windows App developers needed some assurances from Microsoft after news of the following incident got round. They got it.
“An enterprising coder by the name of Chris Walsh has fleshed out some hooks into unmanaged (read: native) Windows Phone 7 services,” Engadget reports, “It’s not what we’d call a ‘jailbreak’ – you’re not altering the security settings of the device in any way – you’re just taking advantage of undocumented services Microsoft has in place, though it’s still very cool.”
This doesn’t seem to be a new problem either. “We suspect most developers have gathered this since MIX earlier this year – many of them have been dealing with variations of the problem since the genesis of Microsoft’s .NET Framework – but we thought we’d throw out a note that word’s getting around on how easy it is to tear apart applications downloaded from the Windows Phone 7 Marketplace,” Engadget adds.
But Microsoft has come to the rescue with Runtime Intelligence for Windows Phone, which it now openly promotes to Windows Phone 7 developer at the Windows Team Blog.
“Microsoft and Pre-emptive Solutions have partnered to provide Runtime Intelligence for Windows Phone – FREE development tools and a managed service to monitor and protect Windows Phone 7 applications,” the blog details, “Application monitoring and analytics, number of application sessions, number of unique users, feature usage counts and duration, general system and stability statistics, application protection.”
And, here it comes:
“A commercial-grade SKU of Dotfuscator specifically targeting Windows Phone 7 including patented renaming, control flow, string encryption, and metadata removal obfuscation transforms.”
Sponsored Links:
Unlocked Cell Phones
Unlocked iPhone 4
“patented renaming”
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?
Google either already does this on their javascript programs, or they make really really ugly OO stuctures before their obfuscation step.
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:
::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
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.
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
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.
and where would the encryption key be stored?
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 ?