Geekly Articles each Day
📜 ⬆️ ⬇️

Security issues of Android applications: classification and analysis



Image : etnyk , CC BY-NC-ND 2.0

The use of smartphones in everyday life is not limited to voice calls and SMS. The ability to download and execute software, as well as mobile Internet access, has led to the emergence of a huge number of mobile applications. The functionality of a modern smartphone consists of browsers, social networking client programs, office applications and all kinds of services that work on the web. Android devices have taken up most of the smartphone market due to the open architecture of the Android platform and a convenient developer API. Currently, Android is the most popular mobile OS with a market share of more than 75%. The number of applications downloaded from the Google Play store in 2016 amounted to 65 billion [1] .
')
In parallel, there is a rapid growth in the number of malicious applications: in 2015, 2.3 million of them were detected [3] . In addition, about 60% of Android devices work on versions of the OS with known vulnerabilities, and they can potentially be attacked by attackers [6] . These threats, in turn, led to the development of remedies. The official Google Play store introduced application filtering using the Google Bouncer sandbox. Anti-virus companies began to release their products under Android (although, as shown in [8] , many of them themselves contain dangerous vulnerabilities). The number of scientific publications on this topic has also increased: one of the 2015 survey reviews on security solutions for Android [2] has more than 40 projects and does not mention all currently known research. Due to the fact that mobile devices are the source and storage of a large amount of sensitive data, the security problem of the Android OS and its applications is particularly acute.

The Android platform is free software, its source code is completely open. Device manufacturers independently develop the code base, creating specialized firmware in order to achieve greater functionality and better performance. A side effect of such activities are vulnerabilities and weaknesses in the implementation of algorithms that are absent in the main code base, but exist on many real devices. Malicious software uses these vulnerabilities to enhance rights and overcome defensive mechanisms. Identifying vulnerabilities in firmware in the absence of source codes is extremely difficult. The primary problem is the lack of a controlled execution environment, which is necessary for dynamic analysis.

Thus, a complete analysis of the security of a device requires the study of the properties of system and application software as a whole. This article provides a personal classification of Android security issues, as well as a list of requirements for the full-system analysis of the Android platform.

1. Android OS device


The Android OS is based on the Linux kernel with some architectural changes that were made by Google engineers. Applications for the Android operating system are developed in the Java language. Starting with Android 1.5, the Android NDK toolkit has been introduced, which allows you to develop application modules in C and C ++ and compile them into native code [4] . Applications are delivered in the form of files of the special format APK, which is a ZIP-archive with a certain directory structure and files. The app APK file contains:


Starting with Android 4.4, two application execution environments are supported: Dalvik VM and ART. It should be noted that the process of preparing the APK file has not changed, only the process of installing applications in the new ART runtime has changed. Starting with version 5.0, the ART runtime has become the default instead of Dalvik VM.

The Dalvik VM runtime for Java programs on Android is very different from the “regular” Java VM. First, when compiling a Java program, it is compiled into the bytecode of the Dalvik virtual machine, which is very different from the bytecode of the HotSpot virtual machine. The Dalvik virtual machine is a registered one, which makes its implementation on RISC architectures, often used in mobile devices, more efficient. Also, when developing Dalvik, memory limitations in mobile devices were taken into account. Starting with Android 2.2, the Dalvik runtime includes a JIT compiler that compiles hot chunks of Java code into native code [5] .

The standard Java libraries were either replaced with the refined libraries from the Apache Harmony package or rewritten. When you compile a Java program, you get a DEX (Dalvik Executable) file that contains the byte code for the Dalvik virtual machine. The file format was designed to reduce the memory footprint and differs significantly from the standard JAR format. To call modules implemented in native code from Java programs, the JNI interface is used. It should be noted that it is possible to load machine modules dynamically over the network using the DexClassLoader component.

2. Security issues


The parent process for all Android applications is the Zygote process. This process is an Android application framework, in which all the necessary libraries of the Android environment are already loaded, but the code of the application itself is missing. The launch of the Android application from the point of view of the operating system is as follows:

  1. Initially, the system calls the fork to create a descendant from the Zygote process (see Figure 1).
  2. In this new process, the file of the application being launched is opened (open system call).
  3. There is a reading of information about the class files (classes.dex) and resources from the application file. Sockets are opened for IPC.
  4. The mmap system call is made to map the application files to memory.
  5. The runtime environment sets up the required environment and executes the application (interprets the Dalvik byte code or transfers control to the functions in the executable code in the case of ART [7] ).

At the kernel level of the Android OS, each application is a separate process with unique user / group ID values ​​that are given to it during installation. Thus, each program works in its sandbox. Starting with version 4.3, in addition to this security policy, the use of the mandatory access control component SELinux has been added [10] .



Fig. 1. Run a new application in the Android OS

By default, an application is limited in its capabilities and cannot do anything to adversely affect another application or user: neither read user data, nor modify system applications; No access to the network. To gain access to various resources, the application accesses the Android OS services. Access permissions are set statically in the application manifest file and are issued to the application during its operation as needed. The system prompts the user for consent to grant these permissions during installation or during the application update. Responsibility for issuing access to an application lies with the user, he himself decides which application to give permission for certain actions, and which one does not give, during his installation. Using this approach, in which all permissions are issued at once when installing an application, has led to the fact that users began to distribute privileges to applications without thinking about the consequences. In turn, applications began to request more and more permissions as their functionality expanded. In Android 6 Marshmallow, this system is replaced by another: the application requests access to resources from the user during its operation, and the user can either allow access or deny it [11] .

The Android application consists of four types of components and does not contain a main () function or any other single entry point. Application components interact with each other using special messages called Intent.

Components called Activity define the user interface. Typically, a single Activity component is used to describe a single screen of an application. An activity can start another Activity by passing parameters using the Intent mechanism. During operation, only one Activity can operate and process user input, the rest for this time remain frozen or destroyed, depending on the selected application mode.

Components called Service [9] perform background processing. When an Activity needs to perform some operation, such as downloading a file or playing music, and continue working when the user has moved to another application or turned off the current one, the application starts a service whose purpose is to perform this operation. Developers can use Service as a daemon application that starts at system boot time. The Service component usually supports RPC (Remote Procedure Call), so other system components can access it.

The content provider component stores and exchanges data using the relational database interface. Each Content provider contains a unique URI for data and processes requests to it as SQL queues (Select, Insert, Delete).

Components of the Broadcast receiver act as mailboxes for messages from other applications.

Security issues arising in the Android OS were considered in [ 2 , 12 , 13 ], but the classification of problems into categories is given only in the article [2] . This classification is quite detailed and covers many security problems, but it has several significant flaws: some categories cover a wide area of ​​vulnerabilities, while others are quite specialized; these categories of vulnerabilities do not correlate with the software levels of the Android OS architecture; vulnerabilities from Internet sources are not covered, and vulnerabilities in protocols and equipment are poorly covered (paragraphs 2.7 and 2.8 in our classification). The following classification of vulnerabilities eliminates these shortcomings.

2.1. Vulnerabilities of the Linux kernel and its modules


This category of problems includes vulnerabilities that are inherent in all operating systems based on the same version of the Linux kernel as the Android operating system. Exploits that exploit vulnerabilities in the kernel can get user data or system administrator rights. Raising the privileges of the process to the rights of a system administrator, a malicious program can disable the Android security system, insert malicious code into existing programs, and install a rootkit. In addition, manufacturers of various devices add modules to the kernel for their devices; There may also be vulnerabilities in these modules. Examples of privilege elevation vulnerabilities are described in [ 14 , 15 , 16 , 64 ]. It is also worth noting that a vulnerability was recently discovered in the ashmem component for interprocess communication in Android [62] .

2.2. Vulnerabilities of device manufacturers' modifications and components


Recently, manufacturers of various mobile devices began to release their modified Android firmware. These firmware can contain various applications and services developed by the device manufacturer, which can often not be removed. For example, in October 2016, a hidden backdoor was discovered in Foxconn firmware [63] . An analysis of these services, given in articles [17] , shows that they contain from 65 to 85% of vulnerabilities found throughout the system. In addition, it is worth noting that vulnerabilities that were found and fixed in the main Android branch can remain in the device manufacturers for a long time [ 18 , 19 ].

2.3. Machine Code Module Vulnerabilities


Android applications support the launch of machine code via the JNI interface. This gives rise to another category of vulnerabilities associated with well-known vulnerabilities of memory leaks in low-level languages ​​(for example, in C and C ++) [20] . Since there are no restrictions at the Android OS process level, other than those imposed by the Linux kernel, third-party libraries in machine codes can use permissions issued to the entire application to perform malicious activity (see also the next category of vulnerabilities, Section 2.4). Also, application code modules in machine codes are used by the authors of malicious applications in order to circumvent the analysis and monitoring tools of the Android level. These modules can also use anti-analysis techniques used in normal programs.

2.4. Vulnerabilities of intercomponent interaction mechanisms


This category includes vulnerabilities associated with interactions between various application components. Since, at the operating system level, the application is limited to the process sandbox, it needs a mechanism to access the components of the Android OS to interact with them. This happens through the device / dev / Binder and various other Android OS services. As mentioned above, the parameters of this access are specified in the manifest file, as an XML file with permissions. The analysis given in [ 12 , 21 , 22 , 23 , 24 , 25 ] points to the shortcomings of this system of restrictions and shows ways to circumvent them. For example, an application can use the access rights of another application and get data through it through the ICC. There may also be vulnerabilities associated with third-party libraries. Third-party libraries used in the application receive the same set of restrictions as the application itself. Therefore, third-party libraries can use permissions issued to the entire application to commit malicious activity. Applications can also intercept system events sent via a broadcast request and store information about incoming calls and SMS.

2.5. Vulnerabilities in the applications themselves


Each application stores some user data. This data must be properly protected so that other applications cannot access it — but this protection is not always provided. For example, Skype in one version of the application saved the contact database in clear text on disk. Thus, contacts could be read by any other application that has access to the disk [26] . Applications can also use cryptographic libraries with errors [27] or some proprietary implementations. In addition, not all applications produce good user authentication and authorization. In addition, applications may allow SQL injections and are prone to XSS attacks. It is also worth noting that most of the developed applications are written in Java without using any protection for binary code, and Java byte-code, as is well known, is easy to disassemble and analyze. It is worth noting that this category of vulnerabilities also includes the well-known Mobile OWASP-10 list. Many such vulnerabilities are described in [ 28 , 29 ].

2.6. Vulnerabilities in embedded services and libraries


The standard set of libraries and services running on Android also contains vulnerabilities. For example, a Stagefright vulnerability was recently discovered in a library for displaying video in MMS messages, to which all versions of Android were exposed, starting with 2.2 [30] . A vulnerability was later discovered in the MediaServer component, which affects all versions of Android c 2.3 to 5.1 [31] . The article [13] shows the vulnerabilities of the Dalvik runtime: by running a large number of processes in the system, you can ensure that the subsequent process starts with administrator rights.

2.7. Internet sources


Android applications are distributed through a wide number of sources in addition to the official app store. Since Android applications are written mainly in Java, they can be easily redeveloped and repackaged using malicious code [ 32 , 33 ]. In addition, as shown in article [34] , the Bouncer application analysis sandbox used in the official catalog is easy to work around. Therefore, the official store itself also contains a large number of malicious programs. In addition, Android supports remote installation of applications through Google Play on devices associated with a Google account. Thus, if you hack a Google account for a device, you can install a malicious application from Google Play that the attacker previously uploaded there. At the same time, no confirmation of these actions is required on the mobile phone screen, as they are requested in the browser window and the application is installed on the phone in the background when accessing the Internet. This category of vulnerabilities also includes the use of social engineering, when they propose to install an application from an unauthorized source to continue work [35] .

2.8. Vulnerabilities of hardware and related modules and protocols


Mobile devices running Android OS have a wide range of equipment for interacting with the outside world. Corresponding vulnerabilities can be exploited in close proximity to the device or if there is physical access to the device.

Examples of such attacks include a Denial of Service attack on Wi-Fi Direct technology [36] , theft of credit card data using NFC [37] , remote code execution via Bluetooth [38] , installing a malicious application without the user's knowledge via adb with using the backup mechanism [39] . In [13] , vulnerabilities are shown that can be used to elevate application privileges using errors in the adb protocol implementation.

3. Tools for analyzing Android applications


Since the first Android phones were released, a large number of tools for analyzing Android applications have been written. The most comprehensive review of these tools is contained in articles [ 40 , 41 , 42 , 2 ]. In the first three sources, the tools are classified by type of analysis: static, dynamic, and their combination (mixed). The article [2] uses the classification of tools according to the stages of application deployment on an Android device. In our work, the classification by type of analysis is used.

Static analysis


Static analysis tools can be divided into the following categories:


One of the most popular tools for reverse engineering is Apktool [43] . It has the ability to decode application resources into approximately the original form, repacking applications back into APK / JAR files, debugging smali bytecode. Another well-known project smali / backsmali [44] is used to decompile and compile Dalvik byte-code in apktool. Also, the Dedexer tool [45] is often used to disassemble the Dalvik bytecode.

Radare2 [46] is an open source tool for disassembling, analyzing, debugging and modifying Android application binary files.

One of the most versatile tools for static analysis is Androguard [47] . It can disassemble and decompile the application back into Java source code. Having received two APK files, it can calculate their similarity coefficient for detecting repackaged applications or known malicious applications. Due to its flexibility, it is used in some mixed analysis tools.

A more complete list of static analysis tools can be found in the articles listed above. It should be noted that static analysis has a number of significant limitations associated with the fact that there is only an abstract view of the program. For example, static analysis becomes much more difficult if obfusting transformations are applied to the program. Depending on the complexity of obfuscation, some (and maybe all) static approaches may become completely useless. If the call to each method is done only indirectly, it is unlikely that a call graph of the program can be constructed. In Android, this transformation can be done using the Java Reflection API to call methods and create objects instead of using normal calls and instructions to create a new object. The market for solutions to protect the source code already has several products for obfuscating Android application files that can negate all the benefits of static analysis [ 48 , 49 ]. In more detail about techniques of counteraction to static analysis it is possible to read 50 .

Dynamic and mixed analysis tools


Dynamic analysis tools track the behavior of an unknown application at run time when it is run in a controlled sandbox to get a behavioral trace. To do this, the sandbox is instrumented at various levels of the architecture by sections of code that track the behavior of the application and the Android OS.



Fig. 2. Android Sandbox Architecture Levels

The Android sandbox architecture is an Android emulator (most often QEMU), within which the Android OS is running. Instrumentation is performed either at the emulator level, or at the Android OS level, or both there and there. The Android OS level is also divided into four sublevels:


Techniques used in dynamic application analysis:


Mixed analysis tools include tools that combine dynamic and static analysis techniques.

4. The ideal system for full-system analysis of the Android platform


Articles [ 40 , 41 , 42 , 2 ] contain more than 40 different tools for analyzing Android applications and analyzing Android OS as a whole. As noted in [ 34 , 60 , 61 ], existing dynamic analysis tools have a number of serious flaws. These shortcomings are inherent in the standard application analysis tool in the Google Play store - Google Bouncer, as a result of which malicious applications can be distributed through the official store without being detected.

Comparison of the capabilities of the approaches and systems in the publications reviewed allows us to formulate the requirements for an ideal analysis system for the Android platform, which is able to analyze the applications and all the layers of the system software. The system borrows some effective techniques from the works reviewed, combining them with the aim of overcoming shortcomings in existing solutions.



The system architecture is shown in Fig. 3. The main component is a full-system emulator that can download both Android OS firmware from real devices and the official Android image for the emulator. The emulator supports probros probing from a real device, as well as the execution of individual sections of code on real devices. Inside the emulator, there are modules that provide:


List of requirements for this system:

1. Support for downloading firmware from manufacturers of various devices


A significant disadvantage of all existing analysis tools of the Android OS and its applications is the impossibility of launching firmware from device manufacturers in available emulators. As was shown in Section 2.2, modified firmware from device manufacturers contain from 65 to 85% of vulnerabilities found throughout the system. At the moment there are no tools for analysis that would allow to run the firmware from manufacturers. All existing solutions work on a special build of Android for the GoldFish virtual platform.

2. The ability to execute individual pieces of machine code on a real device


According to information from the articles [ 34 , 61 ], there are ways to identify the work inside the emulator. As a rule, the execution of a QEMU emulator in the binary translation mode is detected, since most sandboxes are based on it. The methods are based on the different behavior of certain parts of the machine code in the emulator and on the real device. Since changing the mechanism of binary translation is a difficult task, the execution of individual pieces of machine code on a real device would be a good approach to countering these methods of detecting an emulator.

3. Forwarding data from the sensors of the equipment of real devices in the emulator


As described in [ 34 , 61 ], there are ways to determine an emulator based on data obtained from equipment sensors, such as an accelerometer, gyroscope, GPS, light sensor, and gravity. The output values ​​of these sensors are based on information gathered from the environment, and therefore, realistic emulation is a complex task. The presence of such sensors is the main difference between smartphones and desktop computers. The increasing number of sensors on smartphones provides new opportunities for identifying mobile devices.

4. Joint analysis at the level of Java-code and machine code


The difficulty for many systems for analyzing Android applications is that applications contain both modules in Dalvik bytecode and modules in machine codes. Of the existing solutions, support for analyzing all modules is implemented only in DroidScope [57] and CopperDroid [ 58 , 59 ]. An ideal analysis system should be able to track data flows and controls at the level of user and system code. For custom code, when possible, raise the presentation layer to Java code, which is a high-level development language. It is also necessary to ensure the “gluing together” of data flows and control when moving from machine code to Java and vice versa.

5. Support inter-component analysis


The article on CopperDroid [58] shows the implementation of support for the analysis of inter-component interactions both within the Android application and between different applications. This is done by intercepting data passing through a component of the binder kernel, since all interaction passes through it. The approach implemented in CopperDroid makes it possible not to modify the Android source code, which makes it possible to transfer it to new versions of the Android OS and the new ART launch environment with minimal changes.

6. Protection against static detection heuristics


As shown in [ [57] , 61 ], most sandboxes for analysis can be detected by simply checking the IMEI, IMSI, or firmware build numbers of the device. Also, the emulator can be detected by checking the routing table for standard values. From existing solutions, protection against detection by static heuristics is implemented only in the ApkAnalyzer project [65] .

7. Minimal changes to Android firmware


It is also worth noting that many dynamic analysis solutions are based on the instrumentation of the code of various components of the Android OS, in particular the Dalvik virtual machine. This complicates their continued support, as well as the migration to the new launch environment for ART applications. Many sandboxes are limited to analyzing the code of Java components, while more and more applications use components in machine code.

8. Support for full-system analysis of tagged data with control flow tracking.


It is worth noting that many of the dynamic analysis tools use the analysis of tagged data using the TaintDroid tool [56] . Successful ways to circumvent the analysis of this tool were shown in paper [60] . The following facts are the reason for the success of these attacks: 1) TaintDroid only tracks data flows and does not track control flows, 2) TaintDroid only tracks data flows at the Dalvik virtual machine level and passing through the JNI interface. Possible ways of resolving these deficiencies are described in [60] and provide guidance for further research.

9. Support for character execution and partial execution with specific values ​​using data obtained from static code analysis (concolic execution - mixed execution)


The article [51] describes the analysis environment that implements this approach. This environment combines the techniques of static analysis of the control flow graph of a program, symbolic execution of a program, and execution of a program with specific values. Approaches combining techniques of symbolic execution and execution of a program with specific meanings are described in [ 52 , 53 , 54 , 55 ]. The purpose of this method is to observe the execution paths that lead to program sections containing the “interesting” code. “Interesting” code is understood as such code, the execution of which depends on any external events that have occurred or on the settings of the system environment. For example, code classes in Android, dynamically loaded using the DexClassLoader component or calling "machine" methods through the JNI interface.

Conclusion


The security problems of the Android mobile OS exist at all levels of the platform and require a more comprehensive approach than the protection measures that can be observed now. In developing the classification of vulnerabilities presented in this article, it was noted that one of the main problems is significant market fragmentation, which does not allow for the timely delivery of security updates to all devices, as implemented in iOS.

At the same time, the existing means of protection, including antivirus and sandboxes, have many drawbacks and cannot fully protect the user. Although you can create a sandbox for a full-system analysis of the Android OS without the described disadvantages if you are guided by the list of requirements presented in this article.

Despite this pessimistic picture, there have recently been a number of positive movements towards improving the security of Android. In particular, Google has launched a security update release program: they come out every month and some vendors still add them to their firmware versions (devices supported by Google get these updates first). In addition, users can independently install on their devices a version of the Android OS CyanogenMod (now LineageOS), which supports these security updates. Also, the user can reduce the risks, if limited to a set of popular applications only from the official Google Play store. Vulnerabilities like RCE (remote code execution) are becoming increasingly rare, so malicious applications are delivered to phones via phishing sites more often.unofficial app stores or using social engineering. The average user of the Android OS, following certain safety practices, can be calm for your smartphone.

: (@ melon )


:


  1. statista.com/statistics/281106/number-of-android-app-downloads-from-google-play
  2. Tan DJJ et al. Securing Android: A Survey, Taxonomy, and Challenges // ACM Computing Surveys (CSUR). 2015. Vol. 47. â„– 4. P. 58.
  3. file.gdatasoftware.com/web/en/documents/whitepaper/G_DATA_Mobile_Malware_Report_H1_2016_EN.pdf
  4. developer.android.com/ndk/guides/stable_apis.html
  5. Dalvik VM Internals // sites.google.com/site/io/dalvik-vm-internals
  6. securityweek.com/overwhelming-majority-android-devices-dont-have-latest-security-patches
  7. Google I/O 2014 — The ART runtime // youtube.com/watch?v=EBlTzQsUoOw
  8. media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Huber-Rasthofer-Smartphone-Antivirus-And-Security-Applications-Under-Fire.pdf
  9. developer.android.com/guide/components/services.html
  10. source.android.com/devices/tech/security/selinux
  11. developer.android.com/preview/features/runtime-permissions.html
  12. Enck W., Ongtang M., McDaniel P. Understanding android security // IEEE security & privacy. 2009. № 1. P. 50—57.
  13. Shabtai A., Mimran D., Elovici Y. Evaluation of Security Solutions for Android Systems // arXiv preprint arXiv:1502.04870. — 2015.
  14. Hei X., Du X., Lin S. Two vulnerabilities in Android OS kernel // Communications (ICC), 2013 IEEE International Conference on. IEEE, 2013. P. 6123—6127.
  15. forum.xda-developers.com/showthread.php?t=2048511
  16. Zhou X. et al. Identity, location, disease and more: Inferring your secrets from android public resources // Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013. P. 1017—1028.
  17. Wu L. et al. The impact of vendor customizations on android security // Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013. P. 623—634.
  18. en.wikipedia.org/wiki/Stagefright_(bug)
  19. Zhou X. et al. The peril of fragmentation: Security hazards in android device driver customizations // Security and Privacy (SP), 2014 IEEE Symposium on. IEEE, 2014. P. 409—423.
  20. Sun M., Tan G. NativeGuard: Protecting android applications from third-party native libraries // Proceedings of the 2014 ACM conference on Security and privacy in wireless & mobile networks. ACM, 2014. P. 165—176.
  21. Octeau D. et al. Effective inter-component communication mapping in android with epicc: An essential step towards holistic security analysis // USENIX Security 2013.
  22. Chin E. et al. Analyzing inter-application communication in Android // Proceedings of the 9th international conference on Mobile systems, applications, and services. ACM, 2011.
  23. Felt AP et al. Permission Re-Delegation: Attacks and Defenses // USENIX Security Symposium. 2011.
  24. Bugiel S. et al. Xmandroid: A new android evolution to mitigate privilege escalation attacks // Technische Universität Darmstadt, Technical Report TR-2011-04.
  25. Bugiel S. et al. Towards Taming Privilege-Escalation Attacks on Android // NDSS. 2012.
  26. cvedetails.com/cve/CVE-2011-1717
  27. Fahl S. et al. Why Eve and Mallory love Android: An analysis of Android SSL (in) security // Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012. P. 50—61.
  28. owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
  29. Lu L. et al. Chex: statically vetting android apps for component hijacking vulnerabilities //Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012. P. 229—240.
  30. kb.cert.org/vuls/id/924951
  31. CVE-2015-3842 // cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3842
  32. Zhou Y. et al. Hey, You, Get Off of My Market: Detecting Malicious Apps in Official and Alternative Android Markets // NDSS. 2012.
  33. Nolan G. Decompiling android. – Apress, 2012.
  34. Petsas T. et al. Rage against the virtual machine: hindering dynamic analysis of android malware // Proceedings of the Seventh European Workshop on System Security. ACM, 2014. P. 5.
  35. Android Security Underpinnings // youtube.com/watch?v=NS46492qyJ8
  36. coresecurity.com/advisories/android-wifi-direct-denial-service
  37. securityaffairs.co/wordpress/37667/hacking/nfc-attack-credit-card.html
  38. zerodayinitiative.com/advisories/ZDI-15-092/
  39. securityfocus.com/archive/1/535980/30/150/threaded
  40. Neuner S. et al. Enter sandbox: Android sandbox comparison // arXiv preprint arXiv:1410.7749. 2014.
  41. Hoffmann J. From Mobile to Security: Towards Secure Smartphones: . – 2014.
  42. Faruki P. et al. Android Security: A Survey of Issues, Malware Penetration and Defenses.
  43. ibotpeaches.imtqy.com/Apktool
  44. github.com/JesusFreke/smali
  45. dedexer.sourceforge.net
  46. radare.org/r
  47. github.com/androguard/androguard
  48. dexprotector.com
  49. guardsquare.com/dexguard
  50. PANDORA applies non-deterministic obfuscation randomly to Android, Schulz P. Code protection in android // Insititute of Computer Science, Rheinische Friedrich-Wilhelms-Universität Bonn, Germany. 2012.
  51. SchĂĽtte J., Fedler R., Titze D. Condroid: Targeted dynamic analysis of android applications // in review. 2014.
  52. Sen K. DART: Directed Automated Random Testing // Haifa Verification Conference. 2009. Vol. 6405. P. 4.
  53. Sen K., Marinov D., Agha G. CUTE: a concolic unit testing engine for C. ACM, 2005. Vol. 30. № 5. P. 263—272.
  54. Godefroid P. Random testing for security: blackbox vs. whitebox fuzzing // Proceedings of the 2nd international workshop on Random testing: co-located with the 22nd IEEE/ACM International Conference on Automated Software Engineering (ASE 2007). ACM, 2007. P. 1.
  55. Jayaraman K. et al. jFuzz: A Concolic Whitebox Fuzzer for Java // NASA Formal Methods. 2009. P. 121—125.
  56. Enck W. et al. TaintDroid: an information-flow tracking system for realtime privacy monitoring in smartphones // ACM Transactions on Computer Systems (TOCS). 2014. Vol. 32. â„– 2. P. 5.
  57. Yan LK, Yin H. DroidScope: Seamlessly Reconstructing the OS and Dalvik Semantic Views for Dynamic Android Malware Analysis // USENIX Security Symposium. 2012. P. 569—584.
  58. Tam K. et al. CopperDroid: Automatic Reconstruction of Android Malware Behaviors // Proc. of the Symposium on Network and Distributed System Security (NDSS). 2015.
  59. copperdroid.isg.rhul.ac.uk/copperdroid
  60. Sarwar G. et al. On the Effectiveness of Dynamic Taint Analysis for Protecting against Private Information Leaks on Android-based Devices // SECRYPT. 2013. P. 461—468.
  61. Jing Y. et al. Morpheus: automatically generating heuristics to detect Android emulators // Proceedings of the 30th Annual Computer Security Applications Conference. ACM, 2014. P. 216—225.
  62. googleprojectzero.blogspot.ru/2016/12/bitunmap-attacking-android-ashmem.html
  63. bbqand0days.com/Pork-Explosion-Unleashed
  64. powerofcommunity.net/poc2016/x82.pdf
  65. apk-analyzer.net
  66. www.phdays.ru/program/fast-track/45984

Source: https://habr.com/ru/post/332904/

More articles:


All Articles