Recent communications from Microsoft have resulted in a wave of interest (to put it mildly) in obfuscation. Obfuscation is not new; nor are most of the questions, concerns, and critiques that have started flying around the WP7 dev community – but some are (because there are some unique aspects to the wp7 environment).

I have included some resources and comments here – but also, please stay tuned as PreEmptive will be pushing out a collection of resources on this subject specifically targeting Windows Phone.

Quick resources available now:

Online Support: PreEmptive Solutions has two dedicated support forums for Windows Phone 7 developers. Like any forum, you can peruse it, post questions, and get/give answers. PreEmptive support is actively monitoring and contributing.

Obfuscation for Dotfuscator Windows Phone Edition

Instrumentation for Dotfuscator Windows Phone Edition

ISSA Journal: Assessing and Managing Security Risks Unique to Java and .NET (pdf). Tries to answer the questions “when and why should I worry?” and “then what can I do about it?” Specifically, this article “enumerates specific risks unique to managed code (.NET and Java), offers guidance on assessing organizational materiality of these risks, and lists broadly recognized risk mitigation technologies and practices.”

WP7 FAQ (short blog form)

Q: Why do I have to obfuscate my Windows Phone application? Has Microsoft dropped the ball?

Answer: You don’t have to – but if you want to prevent easy reverse engineering of your application, then you should. Managed code has always been easy to reverse engineer (see ISSA Article listed above), and WP7 is no better or worse. In fact, it may be helpful to compare Android’s policy and recommendations on obfuscation – see my earlier post on this for a detailed comparison.

Q: I just obfuscated my application and it’s broken! Is this a bug? Why can’t it just work like encryption?

Answer: Obfuscation is fundamentally different than encryption in that MEANING MATTERS.

Encryption is only half of the equation – the other half is DECRYPTION. Encryption algorithms do not need to preserve the meaning of content because the content will be DECRYPTED. Meaning is wiped out in the output (that is the intent of course) and a reconstituted at decryption time (that also means that encryption cannot be lossy).

Obfuscation is the entire equation – there is no “de-obfuscation” – in fact, that is its intent. Meaning must be preserved in the final output. When your program has tricky reflection, includes mixed-mode DLLs, incorporates 3rd party libraries, etc. – all of that must be accounted for. Some of this can be divined through static analysis – but some idioms/semantics cannot.

Q: I just want to keep Reflector from showing source code. Is that so hard?

Answer: That is actually easy. Turn-off renaming and turn-on “control flow.” The ISSA article defines these transforms, but the short answer is that renaming confuses humans and control flow confuses programs. Renaming is almost always the culprit when it comes to “breaking apps.”

Q: Where can I get the WP7-specific SKUs of Dotfuscator and Runtime Intelligence?

Answer: go to http://www.preemptive.com/windowsphone7.html On the right-hand side of the screen under “Get Started Now”, click on Contact Us Here and fill in the request form. BE SURE TO WRITE WP7 IN THE COMMENTS SECTION.

Q: Where can I go to learn about the latest resources to help me obfuscate my app?

Answer: Go to http://www.preemptive.com/windowsphone7.html - we will update this page regularly. Also, follow us on Twitter - @PreEmptive

I have been watching the growing “outrage” around the WP7 app reverse engineering controversy; outrage wrapped with an unmistakable implication that Microsoft has somehow dropped a ball and is trying to cover-up by recommending obfuscation to mitigate any risks.

I know that I have written that good developers should act like babies, but let’s take a reality check here.

First, let me say that reverse engineering managed code (and the risks that can stem from that) is not unique to .NET – it is common to all managed code platforms including Java (and Mono). For a solid overview on this topic, please see my 2009 article from the ISSA Journal: Assessing and Managing Security Risks Unique to Java and .NET (pdf).

The question is really how a WP7 developer’s experience compares to (for example) an Android developer’s (Google’s Android is Java and subject to all of the same issues and risks).

How many years has Android been out? Let’s compare Android’s policy and recommendation to Microsoft’s shall we? (click on image to enlarge)

Sources: Android policy and Windows Phone policy

This gets us to the real question that developers should be asking – how does Google’s ProGuard recommendation serve its developers as compared to Dotfuscator for Windows Phone? (again, click to enlarge)

Now call me crazy – but as far as I can tell, Microsoft has, in a few short weeks, served up a premier mobile development platform that is not only far more productive than any other, but includes dramatically superior monitoring, measurement, and protection technologies and services – this is not some defensive move to overcome some flaw or hole – it’s designed to further extend the unfair advantage Microsoft offers developers who target Windows Phone 7 first.

What am I missing here?

Web analytics, application performance monitoring, runtime debuggers, security logging, and customer experience improvement programs each have, at their core, some flavor of application monitoring and analytics. Yet, this common thread has been a purely abstract one as the underlying technologies and their respective suppliers have been (up until recently) wholly separate.

These analytic solutions have been able to succeed as silos with a narrow focus on specific stakeholder (owner) objectives because the stakeholders themselves have also been mostly separate. The combination of role, objectives, and scope allow each analytics “silo category” to effectively satisfy the parochial requirements of each “stakeholder category” in happy isolation

Mobile and cloud computing force application analytics convergence

The early crop of application monitoring solutions for mobile and cloud applications have been equally myopic with mobile analytics services providing marketing performance analysis akin to traditional web analytics (sort of a web clone for the phone) and cloud analytics providing metering akin to application performance monitoring solutions – but the silo walls are cracking.

Smartphone applications are often native or managed binaries (Java or .NET framework) rather than simply HTML and JavaScript. And, multi-tenant cloud platforms have multiple stakeholders from ISVs, corporate IT organizations, and the platform suppliers themselves.

Smart mobile and cloud applications promise to end the segregation of application analytic solutions and force a convergence of analytics technologies into a broader application analytics category.

The following table illustrates the multiple mobile and cloud application analytics stakeholders and their diverse sets of requirements.

When, as described above, marketing, development, and App store stakeholders each have “selfish interests” in concurrently monitoring the production application usage of smartphone applications, practical performance and operational considerations dictate an analytics platform whose runtime monitoring capabilities have the breadth to support these diverse constituencies and the analytic depth to support their specific use cases and requirements.

Example: Customer activity and experience

Web analytics focuses primarily on user actions (activity) and customer experience focuses on a user’s entire experience.

Experience and activity are tightly connected, but are in fact, distinct.
In the new mobile world, the distinction between user experience and user activity will become increasingly important as the requirements to manage and optimize each diverge.

The following table defines these two categories and highlights some of their material differences.

The table above shows how the mobile application combines the objectives (and therefore the requirements) of on-premise application monitoring and web analytics.

Refactoring the existing web analytics approach is not sufficient as the customer experience improvement requirements will not be fully met – as the following table illustrates.

Mobile analytic vendors are already emerging that effectively offer the monitoring and reporting analog to web analytics (web analytics clones for the phones). Similarly, cloud platform providers offer varying degrees of resource and application activity metering.

These emerging vertical categories are likely to persist, but they also highlight the practical requirement for a common platform able to efficiently integrate these splinter categories to provide a holistic view of applications that span physical network layers, diverse surfaces, and distributed computing services.

NEXT – APPLICATION ANALYTICS – WHAT DOES IT LOOK LIKE?

HINT

I don’t know any other way to say it. I mean it’s just plain common sense. When developers know how their applications are really being used “in the wild,” they will build better software, more efficiently, and with greater confidence. I guess the rub here is that, historically, it has been virtually impossible to get this kind of real-world (or runtime) intelligence into the hands of developers and architects when they need it most – when they are deciding what to do next.

This is why Agile and all of the other “user-centered” practices have come to rely so heavily on proxies for the end-user, e.g. the product owner, etc. Make no mistake, “user proxies” are compensating for an inherent weakness in most of today’s development practices – that is, a lack of a consistent, reliable, or scalable means to capture runtime intelligence. …but all is not lost.

Web site development – what can it teach us?

Let’s be honest – hardcore developers don’t consider website designers or the users of those “website builders” to be “real” developers. What do they know about algorithms, distributed architectures, or anything to do with the craft (dare I say art?) of engineering quality software? OK, but guess what? These “wannabe developers” focus on – and demand empirical evidence in support of – how their applications are really being used in the wild. In fact, the most remedial “drag and drop” web site developer not only expects to gather real-world usage statistics, they also know that this information will be a (the?) critical factor in future development iterations. They know that only a fool would build something with no way to measure BOTH adoption AND the business impact of that adoption.

Yes, that’s right; website developers actually correlate click-by-click behavior with financial results! Now riddle me this - how many non-web applications are developed with that kind of accountability built-in? The answer isn’t even 0 – it’s null.

You want the analytics? You can’t handle the analytics!

The website developer has even more to teach “real developers.” Website developers have long understood that analytics (when they are good) become, in their own right, bona fide assets – but, here’s the catch – this is only true when they are made public! Knowing something is popular makes it even more popular. So now comes the $64,000 question; if (and we already know it’s a big if) a development team is capturing usage information – how likely is it that they then turn around and share their results with their users, customers or sponsors? (Don’t laugh – it’s a serious question). Users want to benchmark themselves against their peers (usage patterns) and their applications against alternatives (the best tool for the job).

And now it gets a little awkward – if you don’t track usage, you can’t predict results, make corrections, or measure their impact. Developers that don’t incorporate real-world usage patterns into their development process are forced to treat this data as a potential liability. They must work to keep usage analytics confidential and cry foul when others ask to see that very information.

This cannot be healthy. The exclusion of runtime intelligence from traditional development methodologies not only handicaps development, it diminishes the value of their software to those that matter most – the users and sponsors who are denied empirical evidence of their application’s impact.

Open Analytics and CodePlex…

I am using the term “open analytics” here to mean usage analytics that are available simultaneously to all application stakeholders; developers, their sponsors, users, potential users, and (yes) potential competitors (I am not saying that this is an application whose source code is public – that would be open source – not open analytics).

As more and more projects opt-in to share their usage statistics with the rest of the CodePlex community, they will see their software improve in quality and users will have one more metric (in addition to downloads and page views) to help predict the value of CodePlex projects.

If your software is as good as you tell everyone it is – and if you want to make it even better – then open analytics should be a welcome addition to your development arsenal. …but if you secretly fear genuine accountability, well, I guess that’s another story.