You can’t see me, I’m obfuscating (on Windows Phone)

November 17, 2010 4301 Views Sebastian Holst

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:

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)

Question: 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 blog here for a detailed comparison.

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

Question: 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.”

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

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

I have also posted on some related topics

The Secret to Effective In-App Protection

Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”

This raises the question – what constitutes “due care?” Obviously, no development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on how to best define “due care” for any given application/user scenario.

If you don’t follow application security closely, you might think of application obfuscation and symbol renaming as being synonymous – and with good reason. Many platforms and languages, like .NET, Java, and JavaScript have popular obfuscators that do little else--our own Dotfuscator Community Edition for .NET and ProGuard for Java are good examples. However, obfuscation is far more than symbol renaming – and in-app protection is far more than obfuscation. Much of this expansion has been driven by new security requirements, shifting attack vectors, the rise of mobile and IoT computing and, lastly, the growing recognition inside regulations and legislation of the exposure that can result from inadequately protected software.

PreEmptive has partnered with Microsoft for 16 years and we’ve been involved with .NET since before version 1.0 shipped. From that perspective, it’s hard for us to pinpoint a time where the energy and enthusiasm in the .NET community has been higher than it is now. Over the past few years, Microsoft has put together the annual .NET Conf, completely online with viewers, participants, and local events all over the world. The event is virtual and streamed live over three days.

The big news at this year's .NET Conf was the launch of .NET Core 3, the next step in the continued evolution of .NET. .NET Core 3 is a huge effort, with many moving parts, and Microsoft announced many related releases to support it. Highlights for us included:

Search for lockpicking and you’ll see that there’s no shortage of suppliers ready to serve locksmiths and hobbyists, each community having a perfectly legitimate need. Is there any reason to believe that burglars don’t shop the same sites?

Hackers are developers and they have a long history of enthusiastically embracing and adapting development (and DevOps) innovations to speed their work, extend their reach, and ship software – the only difference is that they’re more likely to use those development tools and platforms on YOUR software rather than on their own. Static code analysis tools, debuggers, and even public bug tracking databases are all go-to hacker resources.

Can you tell the difference? Exception or the norm?

Of course, everyone is “for security” in principle. The hard question that each organization has to answer for themselves is “how much is enough?” Over-engineering is (by definition) excessive, and over-engineering application security can, in fact, be devastating as overly-complex algorithms, architectures and processes can compromise user experience, degrade performance and slow development velocity. On the other hand, punishment is swift for organizations that cut corners and do not effectively secure their applications, their data and, most importantly their users and business stakeholders. Finding and maintaining that balance can be time consuming and, because you can never be sure you’ve gotten it exactly right, it can also be a thankless job.

You can’t see me, I’m obfuscating (on Windows Phone)

Quick resources available now:

WP7 FAQ (short blog form)

I have also posted on some related topics

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Highlights from .NET Conf 2019

Tools don’t hack apps, hackers do: Securing Android apps against Frida

Trusted Computing: Panacea or Magical Thinking?

Can you tell the difference? Exception or the norm?

Latest Blog Posts

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Highlights from .NET Conf 2019

Tools don’t hack apps, hackers do: Securing Android apps against Frida

Trusted Computing: Panacea or Magical Thinking?

Twitter