MASTG-KNOW-0006: Binary Protection Mechanisms

Detecting the presence of binary protection mechanisms heavily depend on the language used for developing the application.

In general all binaries should be tested, which includes both the main app executable as well as all libraries/dependencies. However, on Android we will focus on native libraries since the main executables are considered safe as we will see next.

Android optimizes its Dalvik bytecode from the app DEX files (e.g. classes.dex) and generates a new file containing the native code, usually with an .odex, .oat extension. This Android compiled binary (see "Compiled App Binary" in Exploring the App Package) is wrapped using the ELF format which is the format used by Linux and Android to package assembly code.

The app's NDK native libraries (see "Native Libraries" in Exploring the App Package) also use the ELF format.

PIE (Position Independent Executable):
- Since Android 7.0 (API level 24), PIC compilation is enabled by default for the main executables.
- With Android 5.0 (API level 21), support for non-PIE enabled native libraries was dropped and since then, PIE is enforced by the linker.
Memory management:
- Garbage Collection will simply run for the main binaries and there's nothing to be checked on the binaries themselves.
- Garbage Collection does not apply to Android native libraries. The developer is responsible for doing proper manual memory management. See "Memory Corruption Bugs".
Stack Smashing Protection:
- Android apps get compiled to Dalvik bytecode which is considered memory safe (at least for mitigating buffer overflows). Other frameworks such as Flutter will not compile using stack canaries because of the way their language, in this case Dart, mitigates buffer overflows.
- It must be enabled for Android native libraries but it might be difficult to fully determine it.
  - NDK libraries should have it enabled since the compiler does it by default.
  - Other custom C/C++ libraries might not have it enabled.

Learn more: