# A Multi-Tier Security Analysis of Official Car Management Apps for Android
## 5 Low-Level Static Analysis
### Shared Library Analysis  
This stage of analysis pertains to the shared libraries (with the extension.so) an app may employ. These libraries are usually written in C and compiled with the Android native development kit (NDK) toolset [100]. Android exploits this logic for achieving better performance and reusing existing C libraries, without translating them to Java. Such libraries are loaded into memory at runtime. Security and privacy issues with the use of shared libraries have been already tracked down and clearly pinpointed in the Android literature [101; 102; 103].  
To investigate if and to what degree this issue applies to the examined apps, we present the number of potentially vulnerable shared libraries per app in Figure 2. Again, we only consider high severity potential vulnerabilities, which pertain to four exploit mitigation techniques, namely, no-execute (NX), position-independent executable (PIE), Stack Canary, and relocation read-only (RELRO). These countermeasures, more accurately referred to as memory corruption mitigation techniques, are specific to C language, and if neglected may leave room for memory-based exploits, which inexorably migrate to the affected Android app. As seen from Figure 2, 27 out of the 31 analysed apps were found to incorporate shared libraries that overlook at least two of the above mentioned remedies. Actually, two of them have libraries that disregard all four of them, while 12 all but one. Moreover, apps belonging to certain manufacturer groups, i.e., PSA and Tata, demonstrate an identical pattern.  
An OS that endorses the NX bit--a feature of the memory management unit of some CPUs--may tag specific sections of the memory as non-executable, meaning that the CPU will deny to execute any code residing in that region. If the NX bit is not set on the library, an attacker may be able to mount a buffer overflow. That is, frequently, such attacks place code in a program's data region or stack, and subsequently jump to it. However, if all writable addresses are non-executable (through the -_z noexecstack_ compiler flag), such an attack is blocked. As observed from Figure 2, a couple of apps were found to incorporate libraries that allow for executable writable addresses in memory.  
PIIEs on the other hand are executable binaries which are made from position-independent codes (PICs). The latter are used by shared libraries for loading their code into memory at runtime, without overlapping with other shared libraries that already exist there. Actually, this is a common mechanism to harden Executable and Linkable Format (ELF) binaries.  
As seen from the same figure, 27 apps incorporate shared libraries which were built without enabling the position independent code flag (_f PIC_). This could be exploited by an attacker, forcing the app to jump to a specific part of the memory that contains malicious code.  
The use of Stack Canaries is a well-known defense against memory corruption attacks; it is a value placed on the stack with the intention to be overwritten by a stack buffer that overflows to the return address. If this protection is disabled, the app is prone to stack buffer overflow attacks, say, those that aim to overwrite certain parts of memory with malicious code. Our results show that 14 apps embrace shared libraries which neglect this defence.  
Relocation Read-Only (RELRO) is another mechanism to harden ELF binaries by rendering some binary sections read-only. Precisely, RELRO ensures that the Global Offset Table (GOT)--a lookup table used by a dynamically linked ELF binary to dynamically resolve functions that are located in shared libraries--cannot be overwritten. An example of such an attack is given in [104]. With reference to Figure 2, at least one library in each app does not make use of the RELRO defence.