Which Language? A Security Perspective

Achieve the highest level of application security with development languages that compile into native applications.

When it comes to application security, not all programming languages are created equal. Languages that compile to an intermediate format retain a significant amount of metadata which, if not obfuscated, can be reverse engineered with off-the-shelf hacking tools.

With over 20 years in Application Security, we at Digital.ai know if you can build an application to run natively, the security gains outweigh the flexibility of programs that compile to intermediate, bytecode, or interpretive applications. We understand that cannot be the case for every project, so we have solutions to cover most native and intermediate applications.

Flexibility

Digital.ai offers a host of application shielding, obfuscation, and anti-tamper techniques for apps written in just about every language and development environment available. In short, Digital.ai can protect apps written in:

• C
• C++
• Objective-C
• Swift
• Java
• Kotlin
• C#/Xamarin/.NET
• Flutter
• Unity
• JavaScript
• HTML5

Security

Generally speaking, the deepest protections can be applied to native code.  Here’s why:

• Some languages such as C# are compiled into an intermediate format. Intermediate formats retain a significant amount of metadata. This metadata can be used to more easily reverse-engineer the application. Application protection can obfuscate this metadata. However, native applications do not contain this detailed metadata to begin with, obviating the need for metadata obfuscation completely and thus reducing the attack surface. From this perspective native applications require fewer protections and can be protected more quickly and easily.
• At Digital.ai we understand that “in the real world” it is not reasonable to expect our customers to develop entire apps in C/C++. While the parts of the app that store sensitive data should ideally be written in native languages, the UI and interfaces with Android services, for example, will usually be written in Java/Kotlin. This makes sense and our protections can be applied to Java/Kotlin to a greater extent than they can for the highest level and ostensibly “most flexible” languages such as Flutter or Xamarin.
• Tools that threat actors avail themselves of, such as disassemblers and decompilers, are usually easier to use with higher-level languages and thus provide a quicker and easier means to attack.
• Decompiling an app built from a cross-platform language often produces code very similar to the original source. For native code, a lot of information is lost during compilation and machine code generation. This means that even when an app is unprotected, its decompiled code is more difficult to “read” by threat actors when it is written in native code.
• In addition, while it is easy to disassemble machine code to assembly, it is difficult to get decompiled source code that resembles the original code. Applying obfuscation on top of the native code can even completely prevent decompilation.

Following are examples of unprotected native code decompiled, alongside protected native code, decompiled.

Notice how much complexity can be easily added to a simple, toy application. Multiplying the complexity by applying such transformations to real apps makes the attacker’s job orders of magnitude harder.

Examples of higher-level languages

Following are examples of unprotected higher-level code, alongside protected higher-level code:

Even though the protected code is more complex than the unprotected code, beautifiers and decompilers can be used to get a little closer to the original control flow which makes the attacker’s job a little easier.

Conclusion

While Digital.ai can protect apps written in both higher-level languages that compile to native code as well as languages that compile to hybrid applications that contain both native and non-native code, the deepest and best protections are exclusive to apps written in languages that compile to native code. If a company is looking purely at using languages that produce apps that can feature the very best protections, refer to the hierarchy of languages in the diagram below. The language you choose should balance your developers’ needs and skills with the security that your apps require.

To learn more about how Digital.ai Application Security can help your organization cover both native and intermediate applications, visit our website.