Question

Apps downloaded from the Windows Store are installed in this location:

C:\Program Files\WindowsApps

If you look inside this folder you can access each application’s .exe and use reflector to decompile them.

Currently, my Windows RT application sends a password over SSL to a WCF service to ensure that only people using my app can access my database (via the service).

If my code can be read by anybody, how can I ensure that only people using my Windows 8 app are accessing the service?

Thanks!

Answer 1

In the very general sense, it is impossible. If ever you create anything that is placed on the customer’s computer, eventually you will stumble upon someone that will manage to decipher your code and understand how to call your service. You may obfuscate it into insane levels, but still it has to be executable by the processor, so the processor has to understand it. And if it does, then potentially anyone knowing assembly can understand it too. You may smartly obfuscate it so that it will be very time-consuming to cleanup the code from unimportant trash, but still, at some point of time someone will read it.

One of common defenses is in trying to detect who* is actually trying to use your service. This is why all the “portals” require you to “register”. This way, the application identity is marginalized and it is the user who provides login, password, PGP keys, etc is checked and verified whether he/she is allowed to actually run your service.

Also, on the OS/framework layer, there are several ways to selectively provide “licenses” to your customers and then in your application you may use keys/hashes from the licenses to authenticate in your service. This may partially remove from the user the burden of remebering the passwords etc, or it may provide an additional authentication factor, or it may simply be a yes-no flag that allows to run the app or not. Still, it will not guard your code against being read. Licenses just help in verifying if the software copy is legit and if belongs to that specific user/computer.

You may act selectively only against ‘reflectoring’ (or dotpeeking, or ildasming, or …). Those tools really make the decompilation easy (although the original reflector is now paid software). So, the simpliest form would be to use obfuscator that will make the decompilation impossible or harder – that cuts some percentage of the potential code-readers and you can assume scriptkiddies are gone. You may ignore obfuscators and you may write the service connector in native code (C++, not C++/cli). That will make the code completely un-reflectorable and un-ildasmable, and that will cut off another large percentage of people, but with some will still be left (me and thousands of others, but that’s much less than millions).

While this does not give you definitive answer, I wanted to show you that you can only get some “level of hardness”, but you cannot make it totally safe from being read. This is why you should focus on making the service access in that way, that showing your code to a stranger on the street does not compromise your security.

Now gettint to your problem: the core thing seems to lie not in the fact that your app uses some secret algorithms, but rather – that you have hardcoded the password in. You see, there’s with this approach, they do not need to read your code at all. They just need to listen what data your app sends over the sockets..

Another issue is that everyone uses the same keyphrase.

A hardcoded magic string may be some sort of validation, but never authentication. If you want the app to be register-free, make the registration silent and automatic at first run? Of course, you will just bounce the problem: anyone could read the code and learn how to autoregister, and then they will make a clone.. But, again, like I’ve said: you never know who’s on the other side. Is it your app, or is it an ideal-clone of it? Or maybe is it a clone that uses your own hacked-a-bit libraries to connect to you? If it looks like a duck, and quacks like a duck, it is a duck..