• No results found

Protecting Your Application

Hiding the Map of Your Code

Some mobile platforms are programmed using managed code (Java or .NET), comprised of byte code executed by a virtual machine rather than directly on the CPU. The binary formats for these platforms include metadata that lays out the class hierarchy and gives the name and type of every class, variable, method and parameter. Metadata helps the virtual machine to implement some of the language features (e.g. reflection). However, metadata is also very helpful to a hacker trying to reverse engineer the code. Decompiler programs, freely avail- able, regenerate the source code from the byte code, and make reverse engineering easy.

Application Security

The Android platform has the option of using the Java Native Interface (JNI) to access functions written in C and compiled as native code. Native code is much more difficult to reverse engineer than Java and is recommended for any part of the application where security is of prime importance.

“gcc” is the compiler normally used to build native code for Android, its twin-sister “clang” is used for iOS. The default set- ting for these compilers is to prepare every function to be ex- ported from a shared object, and add it to the dynamic symbol table in the binary. The dynamic symbol table is different from the symbol table used for debugging and is much harder to strip after compilation. Dumping the dynamic symbols can give a hacker a very helpful index of every function in the native code. Using the –f visibility compiler switch2 correctly is

an easy way to make it harder to understand the code. Compiled Objective-C code contains machine code and a lot of metadata which can provide an attacker with informa- tion about names and the call structure of the application. Currently, there are tools and scripts to read this metadata and guide hackers, but there are no tools to hide it. The most common way to build a GUI for iOS is by using Objective-C, but the most secure approach is to minimise its use and switch to plain C or C++ for everything beyond the GUI.

Hiding Control-Flow

Even if all the names are hidden, a good hacker can still figure out how the software works. Commercial managed-code protec- tion tools are able to deliberately obfuscate the path through the code by re-coding operations and breaking up blocks of instructions, which makes de-compilation much more difficult. With a good protection tool in place, an attempt to de-compile

Application Security

a protected binary will end in either a crashed de-compiler or invalid source code.

De-compiling native code is more difficult but can still be done. Even without a tool, it does not take much practice to be able to follow the control-flow in the assembler code generated by a compiler. Applications with a strong security requirement will need an obfuscation tool for the native code as well as the managed code.

Protecting Network Communications

Network communications are vulnerable to snooping and injection attacks. Apps can be installed and inspected in emulators or simulators. Network analysers are freely available and able to monitor, intercept, change and redirect network traffic. Some governments monitor electronic communications for censured topics. Protect all communications using HTTPS instead of HTTP. Downloads of javascript libraries from public sources, like map libraries, should use HTTPS, as hackers, using MATE attacks, can inject malicious code into the download if HTTP is used. Downloads of static content, like pictures, from public sources, should use HTTPS, as hackers could replace images with malicious content. One way to step up transport security is to use asymmetric encryption between the server and the mobile app (using public/private key pairs) to provide end-to-end security. Mobile apps should validate that the hostname or common name of the HTTPS server they connect to is the correct, expected one. For sensitive corporate data and applications, install Virtual Private Network (VPN) servers, and install VPN clients on the mobile devices. VPNs generally provide strong authentication, and secure transport above and beyond HTTPS.

Application Security

Protect Against Tampering

You can protect the code base further by actively detecting attempts to tamper with the application and respond to those attacks. Cryptography code should always use standard, relatively secure cipher algorithms (e.g. AES, ECC), but what happens if an attacker can find the encryption keys in your binary or in memory at runtime? That might result in the attacker unlocking the door to something valuable. Even if you use public key cryptography and only half of the key-pair is exposed, you still need to consider what would happen if an attacker swapped that key for one where he already knew the other half. You need a technique to detect when your code has been tampered. Tools are available that encrypt/decrypt code on the fly, run checksums against the code to detect tamper- ing, and react when the code has changed.

Communications can be monitored and hacked between the mobile app and backend services. Even when using HTTPS, an intercepting web proxy (like Paros) can be setup on a WiFi con- nection that will inspect encrypted traffic. Attackers can then tamper with the data in transit, for profit or fun. So if really sensitive data is being sent via HTTPS, consider encrypting/ decrypting application data between the mobile application and the server, so that network sniffers will only ever see encrypted data.

Application Security

Protecting Cryptographic Algorithms

An active anti-tampering tool can help detect or prevent some attacks on crypto keys, but it will not allow the keys to remain hidden permanently. White-box cryptography aims to imple- ment the standard cipher algorithms in a way that allows the keys to remain hidden. Some versions of white-box cryptogra- phy use complex mathematical approaches to obtain the same numerical results in a way that is difficult to reverse engineer. Others embed keys into look-up tables and state machines that are difficult to reverse engineer. White-box cryptography will definitely be needed if you are going to write DRM code or need highly-secure data storage.