CN113127367B - Defect detection method for Android dynamic permission application - Google Patents
Defect detection method for Android dynamic permission application Download PDFInfo
- Publication number
- CN113127367B CN113127367B CN202110472345.7A CN202110472345A CN113127367B CN 113127367 B CN113127367 B CN 113127367B CN 202110472345 A CN202110472345 A CN 202110472345A CN 113127367 B CN113127367 B CN 113127367B
- Authority
- CN
- China
- Prior art keywords
- dangerous
- authority
- file
- authorities
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 19
- 230000007547 defect Effects 0.000 title claims abstract description 17
- 238000000034 method Methods 0.000 claims abstract description 126
- 230000008569 process Effects 0.000 claims abstract description 7
- 238000010586 diagram Methods 0.000 claims description 20
- 239000008186 active pharmaceutical agent Substances 0.000 claims description 16
- 238000012545 processing Methods 0.000 description 8
- 230000003068 static effect Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 239000004071 soot Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention provides a defect detection method for Android dynamic permission application, which comprises the steps of firstly acquiring all dangerous permissions used by a program to be detected and a method for using each dangerous permission, searching a complete call link of each dangerous permission using method, judging whether each dangerous permission lacks permission statement, judging whether each dangerous permission lacks the steps of checking and applying permission, judging whether the dangerous permissions used by the dangerous permission using method are consistent with the permissions checked and applied in the application, and finally judging whether a developer processes the situation of evolution among different versions according to a file method permission map with evolution among different versions.
Description
Technical Field
The invention relates to the technical field of software reliability, in particular to a defect detection method for Android dynamic permission application.
Background
Along with the evolution of the Android system, privacy management is continuously enhanced in the release of new versions, the degree of freedom of the application program in terms of authority is constrained, a developer needs to manually adapt to the processing steps of dangerous authorities used by the application program, and the evolution conditions among different versions need to be completely adapted. Along with the introduction of a dynamic permission mechanism in Android 6.0 and the continuous evolution of subsequent versions, to the current Android 11, developers consider the characteristics of all versions and cannot adapt to all versions, if the adaptation of the developers is incomplete, the situation that the permission required by the application in running is not endowed is caused, and phenomena such as collapse, flash back, unavailable related functions and the like of some applications often occur, so that software defects are generated. Under the condition of insufficient testing of the Android application program, incomplete processing of dangerous authority processing steps and incomplete processing of dynamic authority evolution conditions can cause abnormality which is not wanted to be received by a developer and a user when the application is running, such as Java.lang.SecurityException. The code analysis tool Lint integrated by the Android Studio compiler itself can prompt a part of missing cases, but lacks an analysis strategy of a cross-method, lacks a case of whether the currently processed authority corresponds to the API requirement or not and lacks the processing of problems caused by the evolution of a dynamic authority mechanism version.
Class format files defined in DalivkVM virtual machines are byte codes generated after compiling Java Class files, each Class file corresponds to definition information of a unique Class or interface, the Class files are processed into Dex file analysis operation later, and attributes and methods in Java Class files and constant information in the Class files are stored in Class files. The format of the class file is more rigidly defined than a Java file that is easy for a program developer to read and write, thereby facilitating analysis by the program. Currently, soot, javassist and other popular tools can operate on class-form byte code files to generate, analyze and modify Java classes so as to complete a series of static analysis operations. The FlowDroid is created based on the root, and the analysis of the Android program is optimized, so that the life cycle can be simulated, and the complete function call graph of the Android program can be analyzed, so that the internal structure of the Android program can be analyzed by means of Java optimization frameworks such as FlowDroid, each Java sentence can be analyzed from the perspective of a single Java file, and the relation among each Java class, java method and constant can be analyzed from the perspective of the whole Android program.
The method has the advantages that the situation of missing the dynamic permission step in the Android application program is detected, a developer can be helped to process the risk in advance, the calling of the method in the program is analyzed in combination with the processing situation of the current application program, the missing processing type can be reminded according to each missing situation, the software developer can be further helped to avoid program crash during running, however, no tool is given for the situation that the dynamic permission processing step is incomplete at present, and an ideal and available solution is provided.
Disclosure of Invention
Aiming at the defects of the prior art, the invention provides a defect detection method for Android dynamic permission application, which comprises the following steps:
step 1: acquiring all dangerous authorities used by a program to be detected and a method for using each dangerous authority, storing the using method of the dangerous authorities into a file Dangerouse method set, and storing the dangerous authorities and the using method thereof into a file methodToPermissionMap;
step 2: searching a complete call link of each dangerous authority using method;
step 3: judging whether each dangerous authority in the methodtopermission map lacks an authority statement, and marking the using method of the lack statement authority as NotDeclare;
step 4: judging whether each dangerous authority in the method dToPermissionMap lacks the step of checking and applying the authority, and judging whether the dangerous authority used by the using method of the dangerous authority is consistent with the authority checked and applied in the application;
step 5: and judging whether a developer processes the situation that the evolution exists between different versions according to the file methodToPermissionMap evolving between different versions.
The step 3 comprises the following steps:
step 3.1: extracting the currently declared dangerous authority of the application, and storing the dangerous authority to a file declaredpermission;
step 3.2: traversing a file methodtopermission map, judging whether dangerous authorities exist in a declaredpermission file, and if not, marking a method for using the dangerous authorities as a missing authority statement, namely marking as NotDeclare.
The step 4 comprises the following steps:
step 4.1: an API set for checking and applying dangerous authorities is configured, an API for detecting whether authority is endowed is recorded in a file checkpermissionapis, and an API for requesting dangerous authorities is recorded in a file requestpermissionapis;
step 4.2: traversing complete call links of each dangerous authority using method, judging whether each call link contains an API in a file checkpermissionapis and a request permissionapis, if the call link does not contain the API in the file checkpermissionapis, marking the using method corresponding to the call link as an operation lacking authority detection, namely a NotChecked, and if the call link does not contain the API in the file requestpermissionapis, marking the using method corresponding to the call link as an operation lacking request authority, namely a notrequest;
step 4.3: positioning all APIs in a CheckPermisionAPIs file into a call link of a dangerous authority using method, constructing a data flow diagram starting from each API, and obtaining a flow diagram of a False branch of the API; positioning all APIs in the Request permission APIs file into a calling link of a dangerous authority using method, judging whether the APIs applying for dangerous authorities fall into a flow chart of a False branch, and if not, marking the using method corresponding to the APIs applying for dangerous authorities as a step of deleting the request authorities, namely marking as NotRequested;
step 4.4: judging whether the dangerous authority used by the using method of the dangerous authority is consistent with the dangerous authority checked and applied in the application.
The step 4.4 includes:
step 4.4.1: for the calling link of the unmarked using method which is left after the step 4.3 is executed, constructing a data flow diagram with the API for checking the dangerous authority as a starting point in the calling link of the using method, extracting all the dangerous authorities checked by the current application, and storing the dangerous authorities in a file CheckedPermisson set;
step 4.4.2: constructing a data flow diagram with an API (application program interface) for requesting dangerous rights as a starting point, extracting all dangerous rights requested by the current application, and storing the dangerous rights in a file request permission set;
step 4.4.3: acquiring dangerous authorities of each use method from a file methodtopermissionmap, storing the dangerous authorities in a file permissionneedledset, comparing the file permissionneedledset with a checkedpermissionsetet, and judging that dangerous authorities required by the use method to be detected are not checked if all the dangerous authorities in the file permissionneedledset are not in the file checkedpermissionsetet, namely, judging that the use method to be detected lacks the detection authorities, and marking the step as a NotChecked;
step 4.4.4: comparing the file Permisson needledSet with the Request dPermisson Set, if the dangerous authority in the file Permisson needledSet does not exist in the set Request dPermisson Set completely, judging that the dangerous authority required by the use method to be detected is not requested, namely, the step that the application authority is lost by the use method to be detected is marked as NotRequested.
The step 5 comprises the following steps:
step 5.1: extracting a configuration file of an application, reading a < use-sdk > tag related to a version number, obtaining a platform version specified by the current application, marking the platform version as an attribute targetSDKVMersion of the application, reading difference data among different versions according to the version number, obtaining evolution data under the current targetSDKVMersion version, and storing an evolution data set in a file Evoltionapp;
step 5.2: traversing all methods in the file methodtopermission map, judging whether each using method and the corresponding authority exist in the file evolutionappingmaps, if so, marking the using method as a method which possibly has dynamic authority version compatibility, and storing the method in the file evolution lists;
step 5.3: traversing the file EvolbacterionMethodLists obtained in the step 5.2, taking the use method of each dangerous authority as an end point, extracting a call link of the dangerous authority use method, constructing a complete data flow diagram, judging whether the attribute targetSDKVMsis is judged in the call link and the data flow diagram, judging whether the currently detected dangerous authority use method falls into a True branch of the attribute building.VERSION.SDK_INT, and judging that the compatibility problem between versions exists in the current application if the current authority use method does not exist or does not fall into the True branch, and marking the compatibility problem as NotCompatible.
The beneficial effects of the invention are as follows:
the invention provides a defect detection method for Android dynamic permission application, and the Android Studio itself integrates a code analysis function Lint, so that whether the application lacks the declared permission and whether the permission is checked in the same method can be judged, but in an actual application program, a plurality of false positive alarm information can appear, and misleading developers can deal with the situation. The invention is developed based on a static analysis tool FlowDroid, can process defect information for a developer with more information about dynamic rights, not only can prompt which rights are not correctly declared, but also can evaluate whether step defects exist according to the relation between classes and methods of application programs, and can output the situation of each defect to the developer more clearly, so that the risk existing in the project is known.
Drawings
FIG. 1 is a flow chart of a defect detection method of an Android dynamic permission application in the invention;
FIG. 2 is a flow chart of detecting whether a dangerous authority required by a program is declared or not in the present invention;
FIG. 3 is a flow chart of checking and requesting the dangerous rights required by the detection program and checking and requesting the right of the rights;
FIG. 4 is a flow chart of the present invention for checking whether the program handles the evolution between versions of dynamic rights aspects.
Detailed Description
The invention will be further described with reference to the accompanying drawings and examples of specific embodiments.
As shown in fig. 1, a defect detection method for Android dynamic permission application is implemented by Java programming, and includes:
step 1: acquiring all dangerous authorities used by a program to be detected and a method for using each dangerous authority, storing the using method of the dangerous authorities into a file Dangerouse method set, and storing the dangerous authorities and the using method thereof into a file methodToPermissionMap;
acquiring a method requiring dangerous authority used by a current application program in running and a corresponding dangerous authority, constructing a function call diagram of a program to be detected according to byte codes of the application program, firstly extracting the method called by the application when traversing the function call diagram, then judging whether the method called by the application requires dangerous authority, storing the using method of the dangerous authority into a file Dangerouse method set, and storing the dangerous authority and the using method thereof into a file MethodTOPermisson map;
step 2: searching a complete call link of each dangerous authority using method;
the method comprises the steps of backtracking all usage methods requiring dangerous authorities to find complete call links, defining starting points of all call links as DummyMain in static analysis, traversing the DangerousMethodset file obtained in the step 1, finding callers of the usage methods requiring dangerous authorities, backtracking continuously, and stopping backtracking until the last caller is DummyMain in the backtracking process, and storing the current method and the corresponding call links;
step 3: as shown in fig. 2, judging whether each dangerous authority in the methodtopermission map lacks an authority statement, and marking the using method of the lack statement authority as NotDeclare; comprising the following steps:
step 3.1: extracting the currently declared dangerous authority of the application, and storing the dangerous authority to a file declaredpermission; the concrete expression is as follows:
(1) Extracting a configuration file of an application, analyzing and acquiring all tags in the configuration file, identifying declaration tags of the dangerous authorities by using < use-permission >, traversing all the tags declared in the configuration file, and recording declaration tags of the dangerous authorities and the declared authorities;
(2) Traversing the obtained < use-permission > and the configured value, and traversing and extracting the authority value in the < use-permission > tag, so that all authority sets of the application statement can be obtained and stored in the file declaredpermission;
step 3.2: traversing a file methodtopermission map, judging whether dangerous authorities used by a current method exist in a declaredpermission file, and if the dangerous authorities do not exist, marking the method used by the dangerous authorities as a missing authority statement, namely marking as Notdeclare;
step 4: as shown in fig. 3, judging whether each dangerous authority in the methodtopermission map lacks the step of checking and applying the authority, and judging whether the dangerous authority used by the using method of the dangerous authority is consistent with the authority checked and applied in the application; comprising the following steps:
step 4.1: an API set for checking and applying dangerous authorities is configured, an API for detecting whether authority is endowed is recorded in a file checkpermissionapis, and an API for requesting dangerous authorities is recorded in a file requestpermissionapis;
step 4.2: traversing complete call links of each dangerous authority using method, judging whether each call link contains files of checkpermissionapis and APIs in the requestpermissionapis in the traversing process through traversing the call links of each method, if not, marking the use method corresponding to the call link as an operation lacking authority detection, namely a NotChecked, and if not, marking the use method corresponding to the call link as an operation lacking request authority, namely a notrequest;
step 4.3: positioning all APIs in a CheckPermisionAPIs file into a call link of a dangerous authority using method, constructing a data flow diagram starting from each API, and obtaining a flow diagram of a False branch of the API; positioning all APIs in the Request permission APIs file into a calling link of a dangerous authority using method, judging whether the APIs applying for dangerous authorities fall into a flow chart of a False branch, and if not, marking the using method corresponding to the APIs applying for dangerous authorities as a step of deleting the request authorities, namely marking as NotRequested;
step 4.4: judging whether the dangerous authority used by the using method of the dangerous authority is consistent with the dangerous authority checked and applied in the application; comprising the following steps:
step 4.4.1: for the calling link of the unmarked using method which is left after the step 4.3 is executed, constructing a data flow diagram with the API for checking the dangerous authority as a starting point in the calling link of the using method, extracting all the dangerous authorities checked by the current application, and storing the dangerous authorities in a file CheckedPermisson set;
step 4.4.2: constructing a data flow diagram with an API (application program interface) for requesting dangerous rights as a starting point, extracting all dangerous rights requested by the current application, and storing the dangerous rights in a file request permission set;
step 4.4.3: acquiring dangerous authorities of each use method from a file methodtopermissionmap, storing the dangerous authorities in a file permissionneedledset, comparing the file permissionneedledset with a checkedpermissionsetet, and judging that dangerous authorities required by the use method to be detected are not checked if all the dangerous authorities in the file permissionneedledset are not in the file checkedpermissionsetet, namely, judging that the use method to be detected lacks the detection authorities, and marking the step as a NotChecked;
step 4.4.4: comparing the file Permisson needledSet with the Request dPermisson Set, if the dangerous authorities in the file Permisson needledSet do not all exist in the set Request dPermisson Set, judging that the dangerous authorities required by the use method to be detected are not requested, namely, the step that the application authorities are lost by the use method to be detected is marked as NotRequested;
step 5: as shown in fig. 4, for a file MethodToPermissionsMap evolving between different versions, determining whether a developer has handled a situation where evolution between different versions exists; comprising the following steps:
step 5.1: extracting a configuration file of an application, reading a < use-sdk > tag related to a version number, obtaining a platform version appointed by the current application, marking the platform version as an attribute targetSDKVMsis of the application, reading difference data (such as addition and deletion of authorities, modification of authorities required by a using method and the like belong to an evolution data set) among different versions according to the version number, obtaining the evolution data under the current targetSDKVMsis version, and storing the evolution data set into a file evolutionn mobile map;
step 5.2: traversing all methods in the file methodtopermission map, judging whether each using method and the corresponding authority exist in the file evolutionappingmap, if so, namely, the current application uses the API or the authority related to dynamic authority evolution, marking the using method as a method which possibly has dynamic authority version compatibility, and storing the method into the file EvolutionMethodLists;
step 5.3: traversing the file EvolbacterionMethodLists obtained in the step 5.2, taking the use method of each dangerous authority as an end point, extracting a call link of the dangerous authority use method, constructing a complete data flow diagram, judging whether the attribute targetSDKVMsis is judged in the call link and the data flow diagram, judging whether the currently detected dangerous authority use method falls into a True branch of the attribute building.VERSION.SDK_INT, and judging that the compatibility problem between versions exists in the current application if the current authority use method does not exist or does not fall into the True branch, and marking the compatibility problem as NotCompatible.
And finally, packaging the evaluation result into the structured data, and for the same structured data, realizing two different presentation logics of xml and html, wherein the detection result can be presented to a tool user in various forms, and an application program developer can quickly locate a defective code block according to the output information prompted by the invention, eliminate errors and reduce the risk of abnormal running of the application program.
Claims (4)
1. The defect detection method for the Android dynamic permission application is characterized by comprising the following steps of:
step 1: acquiring all dangerous authorities used by a program to be detected and a method for using each dangerous authority, storing the using method of the dangerous authorities into a file Dangerouse method set, and storing the dangerous authorities and the using method thereof into a file methodToPermissionMap;
step 2: searching a complete call link of each dangerous authority using method;
step 3: judging whether each dangerous authority in the methodtopermission map lacks an authority statement, and marking the using method of the lack statement authority as NotDeclare;
step 4: judging whether each dangerous authority in the method dToPermissionMap lacks the step of checking and applying the authority, and judging whether the dangerous authority used by the using method of the dangerous authority is consistent with the authority checked and applied in the application;
step 5: judging whether a developer processes the situation of evolution between different versions according to the file methodToPermissionMap evolving between different versions;
the step 4 comprises the following steps:
step 4.1: an API set for checking and applying dangerous authorities is configured, an API for detecting whether authority is endowed is recorded in a file checkpermissionapis, and an API for requesting dangerous authorities is recorded in a file requestpermissionapis;
step 4.2: traversing complete call links of each dangerous authority using method, judging whether each call link contains an API in a file checkpermissionapis and a request permissionapis, if the call link does not contain the API in the file checkpermissionapis, marking the using method corresponding to the call link as an operation lacking authority detection, namely a NotChecked, and if the call link does not contain the API in the file requestpermissionapis, marking the using method corresponding to the call link as an operation lacking request authority, namely a notrequest;
step 4.3: positioning all APIs in a CheckPermisionAPIs file into a call link of a dangerous authority using method, constructing a data flow diagram starting from each API, and obtaining a flow diagram of a False branch of the API; positioning all APIs in the Request permission APIs file into a calling link of a dangerous authority using method, judging whether the APIs applying for dangerous authorities fall into a flow chart of a False branch, and if not, marking the using method corresponding to the APIs applying for dangerous authorities as a step of deleting the request authorities, namely marking as NotRequested;
step 4.4: judging whether the dangerous authority used by the using method of the dangerous authority is consistent with the dangerous authority checked and applied in the application.
2. The defect detection method of the Android dynamic permission application according to claim 1, wherein the step 3 includes:
step 3.1: extracting the currently declared dangerous authority of the application, and storing the dangerous authority to a file declaredpermission;
step 3.2: traversing a file methodtopermission map, judging whether dangerous authorities exist in a declaredpermission file, and if not, marking a method for using the dangerous authorities as a missing authority statement, namely marking as NotDeclare.
3. The defect detection method of the Android dynamic permission application according to claim 1, wherein the step 4.4 includes:
step 4.4.1: for the calling link of the unmarked using method which is left after the step 4.3 is executed, constructing a data flow diagram with the API for checking the dangerous authority as a starting point in the calling link of the using method, extracting all the dangerous authorities checked by the current application, and storing the dangerous authorities in a file CheckedPermisson set;
step 4.4.2: constructing a data flow diagram with an API (application program interface) for requesting dangerous rights as a starting point, extracting all dangerous rights requested by the current application, and storing the dangerous rights in a file request permission set;
step 4.4.3: acquiring dangerous authorities of each use method from a file methodtopermissionmap, storing the dangerous authorities in a file permissionneedledset, comparing the file permissionneedledset with a checkedpermissionsetet, and judging that dangerous authorities required by the use method to be detected are not checked if all the dangerous authorities in the file permissionneedledset are not in the file checkedpermissionsetet, namely, judging that the use method to be detected lacks the detection authorities, and marking the step as a NotChecked;
step 4.4.4: comparing the file Permisson needledSet with the Request dPermisson Set, if the dangerous authority in the file Permisson needledSet does not exist in the set Request dPermisson Set completely, judging that the dangerous authority required by the use method to be detected is not requested, namely, the step that the application authority is lost by the use method to be detected is marked as NotRequested.
4. The defect detection method of the Android dynamic permission application according to claim 1, wherein the step 5 includes:
step 5.1: extracting a configuration file of an application, reading a < use-sdk > tag related to a version number, obtaining a platform version specified by the current application, marking the platform version as an attribute targetSDKVMersion of the application, reading difference data among different versions according to the version number, obtaining evolution data under the current targetSDKVMersion version, and storing an evolution data set in a file Evoltionapp;
step 5.2: traversing all methods in the file methodtopermission map, judging whether each using method and the corresponding authority exist in the file evolutionappingmaps, if so, marking the using method as a method which possibly has dynamic authority version compatibility, and storing the method in the file evolution lists;
step 5.3: traversing the file EvolbacterionMethodLists obtained in the step 5.2, taking the use method of each dangerous authority as an end point, extracting a call link of the dangerous authority use method, constructing a complete data flow diagram, judging whether the attribute targetSDKVMsis is judged in the call link and the data flow diagram, judging whether the currently detected dangerous authority use method falls into a True branch of the attribute building.VERSION.SDK_INT, and judging that the compatibility problem between versions exists in the current application if the current authority use method does not exist or does not fall into the True branch, and marking the compatibility problem as NotCompatible.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110472345.7A CN113127367B (en) | 2021-04-29 | 2021-04-29 | Defect detection method for Android dynamic permission application |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110472345.7A CN113127367B (en) | 2021-04-29 | 2021-04-29 | Defect detection method for Android dynamic permission application |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113127367A CN113127367A (en) | 2021-07-16 |
| CN113127367B true CN113127367B (en) | 2024-01-12 |
Family
ID=76780601
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110472345.7A Active CN113127367B (en) | 2021-04-29 | 2021-04-29 | Defect detection method for Android dynamic permission application |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113127367B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114329595B (en) * | 2021-12-29 | 2023-12-19 | 北京荣耀终端有限公司 | Application program detection method, device, storage medium and program product |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102867143A (en) * | 2012-08-22 | 2013-01-09 | 中国科学技术大学 | Quick filtering method for malicious application programs |
| WO2014040461A1 (en) * | 2012-09-13 | 2014-03-20 | 中兴通讯股份有限公司 | Access control method and device |
| WO2015014185A1 (en) * | 2013-07-30 | 2015-02-05 | Tencent Technology (Shenzhen) Company Limited | Method, device and system for detecting malware in mobile terminal |
| WO2015109668A1 (en) * | 2014-01-26 | 2015-07-30 | 中兴通讯股份有限公司 | Application program management method, device, terminal, and computer storage medium |
| CN105117544A (en) * | 2015-08-21 | 2015-12-02 | 李涛 | Android platform App risk assessment method based on mobile cloud computing and Android platform App risk assessment device based on mobile cloud computing |
| WO2018072436A1 (en) * | 2016-10-21 | 2018-04-26 | 中兴通讯股份有限公司 | Privilege management method, device and terminal |
-
2021
- 2021-04-29 CN CN202110472345.7A patent/CN113127367B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102867143A (en) * | 2012-08-22 | 2013-01-09 | 中国科学技术大学 | Quick filtering method for malicious application programs |
| WO2014040461A1 (en) * | 2012-09-13 | 2014-03-20 | 中兴通讯股份有限公司 | Access control method and device |
| WO2015014185A1 (en) * | 2013-07-30 | 2015-02-05 | Tencent Technology (Shenzhen) Company Limited | Method, device and system for detecting malware in mobile terminal |
| WO2015109668A1 (en) * | 2014-01-26 | 2015-07-30 | 中兴通讯股份有限公司 | Application program management method, device, terminal, and computer storage medium |
| CN105117544A (en) * | 2015-08-21 | 2015-12-02 | 李涛 | Android platform App risk assessment method based on mobile cloud computing and Android platform App risk assessment device based on mobile cloud computing |
| WO2018072436A1 (en) * | 2016-10-21 | 2018-04-26 | 中兴通讯股份有限公司 | Privilege management method, device and terminal |
Non-Patent Citations (3)
| Title |
|---|
| Android平台隐私保护方法研究;洪双喜;《中国博士学位论文全文数据库信息科技辑》(第02期);I138-17 * |
| 张淼，邵帅，王浩宇编著.《移动终端安全》.北京邮电大学出版社,2019,89-92. * |
| 面向上下文的Android应用行为分析与表示技术研究;邱煜;《中国优秀硕士学位论文全文数据库 信息科技辑》(第01期);I138-448 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113127367A (en) | 2021-07-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108459954B (en) | Application program vulnerability detection method and device | |
| JP5208635B2 (en) | Information processing apparatus, information processing system, programming support method and program for supporting programming | |
| CN112181858B (en) | Automatic detection method for Java software project dependent conflict semantic consistency | |
| CN110543423A (en) | software dependence package capability detection method, system and medium | |
| CN107643893B (en) | Program detection method and device | |
| CN109614107B (en) | Integration method and device of software development kit | |
| CN111158741A (en) | Method and device for monitoring change of dependency relationship of business module on third-party class library | |
| CN113127367B (en) | Defect detection method for Android dynamic permission application | |
| CN112419057A (en) | Method, device, equipment and storage medium for generating and storing logs of intelligent contracts | |
| CN115391228A (en) | Precise test method, device, equipment and medium | |
| CN111913878A (en) | Program analysis result-based bytecode instrumentation method, device and storage medium | |
| CN111221721A (en) | Automatic recording and executing method and device for unit test cases | |
| CN111240719B (en) | Defect-driven third-party library version upgrade recommendation method | |
| CN112445706A (en) | Program abnormal code acquisition method and device, electronic equipment and storage medium | |
| CN111258562A (en) | Java code quality inspection method, device, equipment and storage medium | |
| CN116610568A (en) | Method, device, equipment and medium for identifying dependency relationship of codes | |
| CN113688031B (en) | Test positioning method based on byte code enhancement technology | |
| CN110321130B (en) | Non-repeatable compiling and positioning method based on system call log | |
| CN112148590B (en) | Method, device and equipment for determining code coverage rate | |
| CN111027073B (en) | Vulnerability detection method, device, equipment and storage medium | |
| CN114490413A (en) | Test data preparation method and device, storage medium and electronic equipment | |
| CN112286803A (en) | Test case detection method and device | |
| CN112631944A (en) | Source code detection method and device based on abstract syntax tree and computer storage medium | |
| CN111240728A (en) | Application program updating method, device, equipment and storage medium | |
| CN114048488B (en) | Vulnerability detection method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |