MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Obfuscating Code and Protecting Intellectual Property
Back in Chapter 1, in the section “Playing in Your Own Room: The App Container,” we saw how apps
written in HTML, CSS, and JavaScript exist on a consumer’s device as source files, which the app host
loads and executes. By now you’ve probably realized that for as much as Windows tries to hide app
packages from casual access, all that code is there on their device where a determined user can gain
access to it. In other words, assume your code is just as visible in an app package as it is on the web
through a browser’s View Source command.
It’s certainly possible—and common, in fact—to draw on web services that aren’t so exposed for
much of an app’s functionality, in the same way that web apps take advantage of server-side processing.
Still, there will be parts of an app that must exist and run on the client, so you are always running the
risk of someone taking advantage of your generosity!
Ever since developers started playing with Windows 8 apps written in HTML, CSS, and JavaScript,
they’ve been asking about how to protect their code. In fact, developers using C# and Visual Basic ask
similar questions because although those languages are compiled to IL (intermediate language), plenty
of decompilers exist to produce source code from that IL just as other tools circumvent JavaScript
minification. Neither JavaScript nor .NET languages are particularly good at hiding their details.
Code written in C++, being compiled down to machine code, is significantly harder to
reverse-engineer, although it’s still not impossible for someone to undertake such a task (in which case
you have to ask why they aren’t just writing their own code to begin with!). Nevertheless, it’s the best
protection you can provide for code that lives on the client machine. The only real way to protect an
algorithm is to keep it on a remote server.
If the rest of the app is written in a language other than C++, especially JavaScript, know that it’s a
straightforward manner to also reverse-engineer the interface to a component. The issue here, then, is
whether a malicious party could use the knowledge of a component’s interface to employ that
component in their own apps. The short answer is yes, because your code might show them exactly
how. In such cases, a more flexible and nearly watertight solution would be for the component vendor
to individually manage licenses to app developers. The component would have some kind of
initialization call to enable the rest of its functionality. Within that call, it would compare details of the
app package obtained through the Windows.ApplicationModel.PackageId class against a known and
secure registry of its own, knowing that the uniqueness of app identity is enforced by the Windows
Store. Here are some options for validation:
• Check with an online service This would require network connectivity, which might not be a
problem in various scenarios. Just remember to encrypt the data you send over the network to
avoid snooping with a tool like Fiddler!
• Check against information encrypted and compiled into the component itself That is, the
component is compiled for each licensee uniquely. This is the most difficult to hack.
752