Extending the mobile security framework

- [Narrator] It's easy to understand the reasons why we might want our software vendors to take care when developing operating systems and system applications. Given the regular appearance of yet another public exposure of denial of service, ransomware, data breach, and so on. As developers, we're perhaps less used to being quite so rigorous in our own coding. Nevertheless, the kind of exploits found in operating systems and system applications can just as easily be found in our own code if we're not careful. The purpose of securing our apps is to protect them against those who would use them as carriers of malicious and possibly viral code by injecting unauthorized modifications, steal intellectual property by extracting and reusing code, invade someone's privacy, steal activation codes and credentials for financial gain, and cheat in competitive applications.

The Northwest University in Illinois has developed the framework for designing and implementing secure mobile apps. These are apps which, through various techniques, some easy and some not so, are difficult to reverse engineer and provide limited forensic information. We've already looked at a number of these techniques and used the tools or their equivalents for testing and decompiling. The framework also includes a number of obfuscation techniques. These are techniques to make life difficult for someone when they're trying to understand the code or recover sensitive information.

These have to be used with care because the downside is that ongoing maintenance, one of the biggest issues for software, can be made just as difficult when using these techniques. I'm not a great fan of obfuscation, but let's have a look at the techniques we can use. The first technique is called bytecode encryption. This involves encrypting data and class files and including new methods to decrypt them. The technique is fairly easy when dynamically loading files. But as the code needs to be decrypted to execute, it's a straightforward reverse engineering task to recover the encrypted code.

The next technique is dynamic loading where custom classes can be loaded from an external source in the form of a DEX file class using the standard DEX class loader function. This makes static analysis difficult as the code does not appear until runtime. However, there are risks when loading external files which can offset the value of dynamic loading in addition to making maintenance more complex. There is also a secure DEX class loader function which goes some way to mitigating the risks of unauthorized code injection and man-in-the-middle attacks.

I'll skip native code as an obfuscation technique because we'll look at that in more detail later in the course. The next approach to obfuscation is reflection. This is a coding technique which enables one class to be used to load and access methods and fields from another class using the built-in java.lang.reflection constructs. It's a powerful technique which can externally affect private members of a class and introduce new code at runtime, so it should be used with caution. The last obfuscation technique is lexical obfuscation.

This involves replacing meaningful names with machine-generated labels which give no indication of usage or purpose. The ProGuard feature included in Android Studio provides this form of protection at no cost to maintenance and should be invoked automatically on release code deployments. Let's extend the model to cover the standard Android design time features and techniques we'll look at to protect our apps. A more comprehensive model of security for Android apps would start with the inherited security that comes from the Android operating system, in particular the TEE, sandbox, permissions, and explicit intent features.

We can then look at three groups of techniques. The first is a set of static, dynamic, and network traffic forensic or decompilation techniques which enable us to identify through observation and testing what information we might be exposing. The second is the set of anti-tamper and anti-debug techniques that we can use at runtime to validate the integrity of the running environment. Then, there's a significant set of Android features which we can leverage at design and coding time to enhance security. With these, we can deliver highly secure Android apps.