KR20130116409A - Method and apparatus to evaluate required permissions for application - Google Patents

Method and apparatus to evaluate required permissions for application Download PDF

Info

Publication number
KR20130116409A
KR20130116409A KR1020120025228A KR20120025228A KR20130116409A KR 20130116409 A KR20130116409 A KR 20130116409A KR 1020120025228 A KR1020120025228 A KR 1020120025228A KR 20120025228 A KR20120025228 A KR 20120025228A KR 20130116409 A KR20130116409 A KR 20130116409A
Authority
KR
South Korea
Prior art keywords
application
authority
determined
function
source code
Prior art date
Application number
KR1020120025228A
Other languages
Korean (ko)
Other versions
KR101900047B1 (en
Inventor
박지순
김진영
윤용호
신준범
이광근
Original Assignee
삼성전자주식회사
서울대학교산학협력단
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사, 서울대학교산학협력단 filed Critical 삼성전자주식회사
Priority to KR1020120025228A priority Critical patent/KR101900047B1/en
Priority to PCT/KR2013/001969 priority patent/WO2013137616A1/en
Publication of KR20130116409A publication Critical patent/KR20130116409A/en
Application granted granted Critical
Publication of KR101900047B1 publication Critical patent/KR101900047B1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • 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/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • 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
    • G06F21/53—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 by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/75—Structural analysis for program understanding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)

Abstract

PURPOSE: A method for diagnosing authority required by application and a device thereof are provided to grasp authority needed when executing the application by static analyzing a source code without actually executing the application. CONSTITUTION: An application acquisition part (410) acquires the source code of an application from the application. A control flow analysis part (420) generates a function list including a function included in the source code. An authority diagnosis part (430) determines authority required by the function list when the application is executed at the device. The application acquisition part acquires additional information including authority information requested in advance. The authority diagnosis part compares the authority information, which is requested in advance, with the determined authority for outputting a compared result. [Reference numerals] (410) Application acquisition part; (420) Control flow analysis part; (430) Authority diagnosis part; (AA) Diagnosis result; (BB) Analysis result (function list)

Description

Method and Apparatus to Evaluate Required Permissions for Application}

The present invention relates to a method and apparatus for diagnosing a permission required by an application for a smart device, and to a method for diagnosing what permission is required when an application is executed on a smartphone through static analysis even if the application is not executed directly. .

The use of smart devices, such as smart phones, tablets, smart TVs, and electronic readers, is becoming common. Accordingly, the type and number of applications used in smart devices are rapidly increasing. Such applications use resources such as location information of the user (or device) to provide a more convenient and useful service to the user.

An application needs access to access device resources such as location information. In general, smart device applications can be classified into three types of platforms: Google's Android, Apple's iOS, and Microsoft's Windows. have. The following describes an application running on the Android platform as an example.

1 is a conceptual diagram showing an application running on the Android platform. Referring to Figure 1, in Android, the application runs in the Dalvik virtual machine. In general, one application is identified using one user ID and runs in one sandbox. In other words, two or more different applications cannot, in principle, run in one sandbox unless they share the same user ID.

By default, applications run inside their sandbox process without specifying any permissions, so they do not have access to systems or resources. However, if the permissions are properly declared through the application's manifest file, it becomes possible to access the resources.

That is, the application identified by the user ID 12345 is executed in the first sandbox 110, and the application identified by the user ID 54321 is executed in the second sandbox 120. Each application can access resources for which permissions are requested in each manifest file.

2A shows the structure of an application file and FIG. 2B shows a portion of an example manifest file. Referring to FIG. 2A, the application package includes source code files of resources.arcs and additional information such as AndroidManifest.xml. The resource.arsc file contains the source code of the application, and the AndroidManifest.xml file contains additional information such as authorization information and active process information. classes.dex is a file whose class files are converted to bytecode that can be run on the Dalvik virtual machine. The res folder contains uncompiled resource files. The META-INF folder contains application signature information.

2B is an example of an AndroidManifest.xml file. The manifest file may include various additional information such as Android version information, source code start position information, and authority information. In the <use-permission> section, the permission that the application wants to use is requested. That is, an application can use the authority requested in the manifest file included in the application or access a resource corresponding to the authority. In the application shown in the example of FIG. 2B, since the Internet access authority and the external storage write authority are requested (declared) in the manifest file, it is possible to write to the Internet access and the external storage medium.

3 illustrates an operation in which a user installs and executes an application 310 on the smart device 320. Referring to FIG. 3, the Android application is composed of additional information including source code and a manifest file, and displays the permission requested by the application at the time of installation (installation) and receives confirmation from the user. After installation, the application requests 332 a resource required for execution from the device, and the device checks 334 whether access rights for the resource are requested (declared) in the manifest file. If the permission is granted, the application allows access to the resource, and if the permission is not allowed (336).

The developer must explicitly request and list the permissions that the application requires in order for the application to work for its intended purpose. If an application attempts to perform an unauthorized operation, it will be rejected by the system, which may lead to an unexpected operation by the developer, an error / termination of the application, or a system crash. Therefore, the developer must request all the permissions required by the application.

However, it is not easy for a developer to know all the permissions required to run an application when developing the application. In many cases, for the sake of convenience at the time of development, you may exaggerate requests that are not necessary to run the application, or develop the application with all the privileges requested, and then delete the permissions that you do not need later. Even if the developer knows exactly what permissions are required to run the application, it is cumbersome to declare them in the manifest file.

In addition, on the Android platform, during the installation phase of the application, the screen displays the necessary permissions for the application to run, and the user confirms it. However, with the increasing number of applications requiring excessive rights, users frequently habitually agree or check the list of permissions displayed on the screen, instead of carefully checking them. In addition, the list of permissions displayed on the screen often does not match the permissions that the application has access to, so it is difficult for the user to know exactly what permissions the application actually uses. These problems may cause malfunctions of smart devices by malicious applications or leak sensitive information by applications.

In addition, to accurately determine the permissions used by an application, it is necessary to repeat the compilation or run time of the application during development.

The present invention is to solve the above problems by providing a method and apparatus for automatically diagnosing and informing the authority required by the application through static analysis of the application.

According to an embodiment of the present invention, a method for checking a permission required by an application running on a device includes: obtaining source code from the application; Generating a function list including at least one function included in the source code; And determining the permissions required by the function list when the application is run on the device.

The method may further include obtaining additional information including previously requested authority information, and comparing the previously requested authority information with the determined authority and outputting a comparison result.

The additional information may further include starting position information of the source code, and the function list may include a function determined to be executable based on a control flow of the source code from the starting position.

In addition, the function list is a function list that filters a function that is determined not to be called when the application is executed by determining a condition included in the function among functions determined to be executable, or virtually when the application is executed by determining the function type. It may be a list of functions that filter functions determined to not be called by a virtual call.

In addition, if the authority information requested in advance is included in the manifest file and the authority information requested in advance and the determined authority do not match, the method may further include generating a modified manifest file based on the determined authority. .

In addition, the authority diagnosis apparatus for checking the authority required by the application running on the device according to an embodiment of the present invention includes an application acquisition unit for obtaining a source code (source code) of the application from the application; A control flow analysis unit generating a function list including at least one function included in the source code; And an authority diagnosis unit that determines an authority required by the function list when the application is executed on the device.

According to another embodiment of the present invention, a method of checking an authority required by an application in a server includes: receiving an application from a developer device; Obtaining additional information including a source code of the application and authorization information requested in advance from the application; Generating a function list including at least one function included in the source code; Determining the authority required by the function list when the application is executed; And compares the requested authority information with the determined authority, and if the determined authority and the requested authority information match, register an application on the server, and if the determined authority and the requested authority information do not match, compare with the developer device. And notifying the result.

The method may further include modifying additional information based on the determined authority when the determined authority does not coincide with the previously requested authority information.

In addition, the server for confirming the authority required by the application according to another embodiment of the present invention includes an application receiving unit for receiving the application from the developer device; An application obtaining unit which obtains additional information including an application source code and authorization information requested in advance from the application; A control flow analysis unit generating a function list including at least one function included in the source code; Authorization diagnosis unit for determining the authority required by the function list when the application is executed; And an application registration unit that registers an application to the server, wherein the authority diagnosis unit notifies the developer device of the comparison result when the determined authority does not match the previously requested authority information, and the application registration unit requests the determined authority and the request in advance. If the credentials match, the application can be registered on the server.

According to another embodiment of the present invention, a method for checking a permission required by an application in a smart device includes calling at least one application installed in the smart device; Receiving a selection of at least one application among called applications; Obtaining additional information including a source code of the application and authorization information requested in advance from at least one selected application; Generating a function list including at least one function included in the source code; Determining the authority required by the function list when the application is executed; And comparing the requested authority information with the determined authority and displaying the comparison result on the screen of the smart device.

The method may further include transmitting the comparison result to the developer device or the application providing server.

In addition, the smart device for checking the authority required by the application according to another embodiment of the present invention calls the at least one application installed in the smart device, the application caller for receiving a selection of at least one application from the called application ; An application obtaining unit which obtains additional information including source code of the application and authorization information requested in advance from at least one selected application; A control flow analysis unit generating a function list including at least one function included in the source code; An authority diagnosis unit for determining an authority required by the function list when the application is executed and comparing the authority information with the authority requested in advance; And a display unit displaying the comparison result on the screen of the smart device.

The apparatus may further include a transmission unit transmitting the comparison result to the developer device or the application providing server.

In addition, the above-described problem solving means of the present invention can be implemented as a computer-readable recording medium recording a program for execution in a computer.

According to one embodiment of the present invention, it is possible to easily grasp the authority required when the application is executed through static analysis of the source code without actually executing the application. This enables application developers to develop applications by requesting only the necessary permissions, thereby preventing the leakage of sensitive information such as personal information and location information.

According to another embodiment of the present invention, the developer may request only the authority necessary for the execution of the application in the process of registering with the server providing the application, even if the developer extensively requests the necessary authority in the application development. Can be easily modified, or it can be automatically fixed on the server. In addition, the application providing server can provide the user with an application that has only the required permissions required to run the application, and the user can trust the content and download and use the application.

According to another embodiment of the present invention, the user can easily call the application installed on his smart device to effectively determine what permissions the application can use and what resources can be accessed. It also solves the problem of not being able to see the permissions required by the application only at installation, and not know what permissions or resources are actually accessed when running. In addition, by feeding back the diagnosis result to the developer or the application providing server or deleting the application according to the diagnosis result, excessive setting of unnecessary permissions for the execution of the application can be weakened.

1 is a conceptual diagram showing an application running on the Android platform.
2A shows the structure of an application file and FIG. 2B shows a portion of an example manifest file.
3 illustrates an operation in which a user installs and executes an application on a smart device.
4 is a diagram illustrating an apparatus for diagnosing a permission required by an application according to an embodiment of the present invention.
5 is a conceptual diagram illustrating a process of an authority diagnosis unit according to an embodiment of the present invention.
6 is a conceptual diagram illustrating an inclusion relationship of rights according to an embodiment of the present invention.
7 is a flowchart illustrating a method of diagnosing an authority required by an application according to an embodiment of the present invention.
8 is a block diagram of a server for statically diagnosing an authority required by an application according to another exemplary embodiment of the present invention.
9 is a flowchart illustrating a method for statically diagnosing an authority required by an application in a server according to another exemplary embodiment of the present invention.
10 is a diagram illustrating a smart device according to another embodiment of the present invention.
11 is a diagram illustrating an example of diagnosing an authority actually used by an application installed on a smart device according to another embodiment of the present invention.
12 is a flowchart illustrating a method of diagnosing a permission of an application installed in a smart device according to another embodiment of the present invention.

Hereinafter, with reference to the drawings will be described embodiments of the present invention;

4 is a diagram illustrating an apparatus 400 for diagnosing an authority required by an application according to an embodiment of the present invention. Referring to FIG. 4, the authority diagnosis apparatus 400 according to an embodiment of the present invention includes an application acquirer 410, a control flow analyzer 420, and an authority diagnosis unit 430.

In general, an application is provided in a package form that includes program source code of the application and additional information including the signature information, authentication information, and authorization information of the application. The application acquirer 410 may extract source code from the application package and additionally obtain additional information. In the application based on the Android platform shown in FIG. 2, the source code includes resources.arsc, and the additional information includes a folder such as an AndroidManifest.xml file, META-INF, etc. in which components of the application or input configuration required by the application are registered. can do.

The authority diagnosis apparatus 400 may obtain an application installed in the smart device from the storage space of the smart device. It can also receive applications from external servers connected via wired or wireless networks. In this case, the authority diagnosis apparatus 400 may further include an application receiver (not shown). In addition, those skilled in the art will understand that even if the developer's device is not a smart device, the application can be taken from the developer's device and the permission analysis device 400 can be used to analyze the permissions required by the smart device application. .

The application acquirer 410 may convert source code of the obtained application into assembly code suitable for a platform on which the application is executed. Alternatively, you can extract the translated source code from the application package into the appropriate assembly code. If the Android platform, the application acquisition unit 410 may obtain the source code of the application in the form of byte code of the Dalvik virtual machine.

The control flow analyzer 420 may analyze the source code or the assembly code of the application. (Hereinafter referred to as source code for convenience of explanation.) The source code includes a plurality of functions and / or instructions (collectively referred to as a function), each function is a library function of a virtual machine or device Can be called. Some library functions may require specific privileges.

The control flow analyzer 420 basically generates a list by extracting a function included in the source code. In addition, you can create a function list by filtering functions that are not called or not executed when the application is executed among functions included in the source code. Filtering tasks largely include control flow analysis, internal state tracking to eliminate dead code, and type analysis of functions to counteract virtual calls.

The control flow allows you to determine the order of execution between the functions that make up the source code and whether the function is called when the application is run. In addition, the control flow analysis unit 420 may use the additional information such as the manifest file to determine the starting point of the application, and analyze the execution order and call of the functions that can be reached from the starting position.

In addition, since it is difficult to accurately grasp the function executed without actually executing the application, the control flow analysis unit 420 includes all the actual execution results through static analysis and analyzes whether the functions included in the source code are actually called. In this case, the internal state can be tracked as well as the call path to improve the accuracy and efficiency of the analysis. That is, the control flow analysis checks the execution order and all possible paths in the execution of a program, but in general, the program source is a conditional jump such as goto, if-else, case, swich, for, while, or Because it contains a loop statement, in situations such as conditional jumps, there are functions that aren't actually executed or called when tracking values that a variable can have. It is desirable to exclude these functions from the scope of analysis. For example, in the case of condition 1, the source code includes a function for transmitting address book information, for condition 2, modifying the address book information, and for condition 3, initializing the address book information. Analyzing the flow confirms that the functions of the conditions 1, 2, and 3 are all executable, but if the part calling the function of the condition 3 through the tracking of the internal state cannot be actually executed, the control flow analysis unit 420 ) Can ignore these dead codes and analyze only the code in condition 1 and condition 2 as the actual calling function.

The source code can also include a function whose function is determined at runtime of the application. For example, if child classes B, C, and D inheriting class A with method M respectively redefine Method M, the code to which the method called AM () is transcribed is BM (), CM Which function () or DM () is determined at run time. The control flow analyzer 420 may perform a type analysis of a function including tracking of inheritance relations and casting of a function so as to correspond to such a virtual call. In the above example, assuming that the application is transferred to B.M () when the application is executed, the control flow analyzer 420 may analyze the functions of C.M () and D.M () by excluding the actual call function.

The authority diagnosis unit 430 may analyze library functions called by the functions based on the functions actually reached by the application based on the analysis result of the control flow analyzer 420. Among the library functions, you can print out the privileges they need for libraries that require specific privileges. The authority diagnosis unit 430 will be described in detail with reference to FIG. 5.

5 is a conceptual diagram illustrating a process of the authority diagnosis unit 430. Referring to FIG. 5, the control flow analysis unit 420 analyzes a function 520 actually reached by the control flow analysis unit 420 among all the functions 510 included in the application and provides it to the authority diagnosis unit 430. do. In the example of Figure 5, Function 04, 06, 09 are included in the source code of the application, but corresponds to a function that is not actually executed or called.

The authority diagnosis unit 430 may diagnose the library function 530 and the authority 540 called by the actual arrival functions based on the control flow analysis result. In the example of FIG. 5, the library functions Library A to F corresponding to Fuctions 01 to 03, 05, and 07 to 08 that are actually called are analyzed. Of these functions, except for Library D, which does not require special authority, the authority required by the remaining functions is diagnosed. The authority diagnosis result of the application illustrated in FIG. 5 may use the rights of the call (CALL_PHONE), the camera (CAMERA), the Internet (INTERNET), the log read (READ_LOGS), and the message send (SEND_SMS). On the other hand, the DIAGOSTIC and REBOOT permissions are set in the source code, but the permissions are not used to run the actual application.

In FIG. 5, all the functions 510 included in the application source code, the actual arrival function 520, the library function 530, and the authority 540 in the control flow analysis are all explained in a one-to-one correspondence. It is merely for convenience, and those skilled in the art will appreciate that a many-to-one / one-to-many correspondence between functions and functions, or functions and privileges, is possible.

6 is a conceptual diagram illustrating an inclusion relationship of rights according to an embodiment of the present invention. FIG. 6 illustrates the actual execution of the application derived through all rights 610 previously requested (declared) from the additional information, the rights 620 required by the functions included in the source code of the application, the control flow analysis and the right diagnosis. An inclusion relationship of authority 630 determined to be necessary is shown. All permissions 610 requested in the additional information may be permissions requested in the manifest file on the Android platform. In FIG. 6, the authority requested in the additional information includes the authority actually required for executing the application. However, in addition to the general case where developers set excessively the permissions required to run an application, there may also be a case in which a developer mistakenly misses the necessary permissions to execute an application. In this case, the authority diagnosis apparatus according to an embodiment of the present invention compares the authority 610 previously requested in the additional information with the authority list 630 determined to be necessary for the execution of the application, and as a result of the comparison, that is, unnecessary In addition to the permissions that have been granted, they can also tell you which permissions are required to run the application, but are missing from the additional information.

In the example of FIG. 6, the developer requests the telephone call (CALL_PHONE) and the emergency call (CALL_PRIVILEGED) permission at the time of development of the application line, but does not use the emergency call in the actual application. Also, the user has requested calendar, address book, call status, synchronization status, and log information read permission (READ_CALENDAR, READ_CONTACTS, READ_PHONE_STATE, READ_SYNC_STATE, READ_LOGS), but the permissions actually used are limited to the read log information. In addition, the request for reboot (REBOOT) and boot completion (RECEIVE_BOOT_COMPLETED) permission, but does not require any permission to run the actual application. The authority diagnosis unit 430 may output all of the results of the diagnosis, or may inform only the necessary authority list. In addition, the current additional information may inform the list of the right to be deleted and / or the right to be added. In addition, the additional information may be modified based on the diagnosis result, and the code corresponding to the permission setting part may be generated and provided in a form suitable for the platform on which the application is run.

7 is a flowchart illustrating a method of diagnosing an authority required by an application according to an embodiment of the present invention.

In operation 710, the application acquirer 410 may acquire additional information necessary for analyzing the source code and / or the application from the application. You can also convert your application's source code to assembly code that is appropriate for the platform on which your application runs. In operation 720, the control flow analyzer 420 may generate a function list including at least one function among functions constituting the source code. In addition, the start point of the application may be identified using additional information such as a manifest, and the control flow may be analyzed from the start point to analyze the execution order and call of functions that can be reached when the application is executed. You can also filter out functions that are not called by tracking the state inside the source code. In addition, by analyzing the form of the function can be filtered for the non-transcribed function by analyzing the function actually transferred during the virtual call (virtual call). In operation 730, an authorization for actually executing an application may be diagnosed based on the function list generated in operation 720 of the application. In addition to the above step, when receiving an application package from the outside, such as a server may further comprise the step of receiving an application. In addition, when the diagnostic result is to be output to the display device, the authority diagnosis result of the application may be displayed using the display unit of the device.

According to the embodiment of the present invention described above, it is possible to easily grasp the authority required when the application is executed through static analysis of the source code without actually executing the application. Through this, the application developer can develop an application by requesting only necessary permissions, thereby preventing the leakage of sensitive information such as personal information.

8 is a diagram of a server 800 for statically diagnosing the authority required by an application according to another embodiment of the present invention. In this embodiment, the server 800 includes an online market place and a store. The server 800 includes an application receiving unit 810, an application obtaining unit 820, a control flow analyzing unit 830, an authorization diagnosis unit 840, and an application registration unit 850. In connection with the server 800 according to the present embodiment, the same description as that described above will be omitted or abbreviated.

The application receiving unit 810 receives an application package from the application developer device 870. The application acquirer 820 obtains source code and additional information of the application from the received application. The additional information may include previously requested authority information, and the authority information may be included in the manifest file. The control flow analysis unit 830 analyzes the function included in the source code of the application and the control flow of the source code, and generates a function list including at least one of the functions included in the source code. The authority diagnosis unit 840 determines the authority required by the function list and compares the authority information requested in advance. As a result of the comparison, when the additional information is requested for authority not necessary for the execution of the application, the comparison result is provided to the application developer device 870. The application registration unit 850 may apply the application to a list of applications available to the consumer device 880 or a market place provided by the server 800 when the authority requested in the additional information and the authority list required for actual execution of the application match. Register.

In the present embodiment, the authority diagnosis unit 840 does not provide the diagnostic result to the application developer device 870 when the diagnostic result additional information is requested to be not required for execution of the application, and is included in the application additional information. The authorization information can be modified to provide the application package to the application register.

In addition, those skilled in the art can understand that if the permission is required for the execution of the application but the permission is not requested in the additional information, the developer device 870 can be notified of the permission or the additional information can be modified to include the corresponding permission. will be.

9 is a flowchart illustrating a method for statically diagnosing an authority required by an application in a server according to another exemplary embodiment of the present invention.

9, in operation 910, an application package is received from an application developer device. In step 920, source code and additional information are obtained from the application. In operation 930, a function list is generated based on the control flow analysis of the application. The authority necessary for the execution of the application is determined based on the function list generated in operation 940 and compared with the previously requested authority information included in the additional information. In step 950, if the authority required when the application is actually executed and the authority requested in the additional information match, step 960, and if not, proceed to step 970 or 980. In step 960, the application package is registered in the marketplace provided by the server and the process ends. In operation 970, the diagnosis result is transmitted to the developer device. In operation 980, the additional information is modified to include only the authority required to execute the application based on the diagnosis result, and then the modified application package is registered in the market place provided by the server.

According to another embodiment of the present invention described above, the developer may request only the authority necessary for the execution of the application in the process of registering with the server providing the application, even when the developer does not request the necessary authority in the application development extensively. You can easily modify the additional information or have it corrected automatically on the server. In addition, the application providing server can provide the user with an application that has only the required permissions required to run the application, and the user can trust the content and download and use the application.

10 is a diagram illustrating a smart device 1000 according to another embodiment of the present invention. The smart device 1000 according to the present exemplary embodiment includes an application caller 1010, an application acquirer 1020, a control flow analyzer 1030, an authority diagnosis unit 1040, and a display unit 1050. In the description of the present embodiment, description overlapping with the above embodiment will be omitted.

Referring to FIG. 10, the application caller 1010 calls at least one application installed in the smart device 1000. The application caller 1010 may call all applications installed in the smart device 1000, and may call all applications except for an application that has been diagnosed that the authority requested by the additional information and the authority that the application can actually use match. It may be.

For at least one called application, the application acquirer 1010 acquires source code and additional information, and the control flow analyzer 1020 analyzes the control flow of the application based on the obtained information to generate a function list. The authority diagnosis unit 1030 determines the authority actually used by the application based on the function list and diagnoses whether the authority requested in advance in the additional information matches. The above-described process may be performed for all called applications, respectively, or may be performed only for applications selected by a user among called applications. The display 1040 displays the diagnosis result on the display screen of the smart device.

FIG. 11 is a diagram illustrating an example of diagnosing an authority actually used by an application installed in the smart device 1000. Referring to FIG. 11, a plurality of applications, such as KAKAO Talk and ChatOn, are called 1110. If ChatOn is selected by the user, the diagnostic result is displayed through static analysis (1120). That is, it can be seen that CAMERA, FLASHLIGHT, and NFC are rights not actually used among the rights declared in the additional information. The user can feed back the diagnostic results to the developer or the application providing server, or delete the application.

Although not shown, a person of ordinary skill in the art may perform an authority diagnosis on all or a plurality of called applications 1110, add a diagnosis result to a list of the plurality of applications 1110, and display a detailed diagnosis when a specific application is selected by a user. It will be appreciated that it is also possible to display 1120 results.

12 is a flowchart illustrating a method of diagnosing a permission of an application installed in the smart device 1000 according to another embodiment of the present invention. Referring to FIG. 12, at least one application called to the device is called in step 1210. In operation 1220, an input for selecting an application to be authorized from among applications called by the user is received. In step 1230, the source code and additional information of the application are obtained. In step 1240, the control flow of the application is analyzed using the source code and the additional information, and a function list is generated. In operation 1250, the authority necessary for executing the application is diagnosed based on the function list, and in operation 1260, the diagnosis result is displayed on the display screen of the smart device 1000. In this embodiment, steps 1230 to 1250 may be performed repeatedly for all applications called in step 1210 or may be performed only for one or more selected applications among the called applications. In addition to the above step, it is also possible to feed back the diagnosis result to the developer device or the application providing server or to delete the application.

According to another embodiment of the present invention, the user can easily call the application installed on his smart device to effectively determine what permissions the application can use and what resources can be accessed. It also solves the problem of not being able to see the permissions required by the application only at installation, and not know what permissions or resources are actually accessed when running. In addition, by feeding back the diagnosis result to the developer or the application providing server or deleting the application according to the diagnosis result, excessive setting of unnecessary permissions for the execution of the application can be weakened.

The block diagrams disclosed herein may be construed to those skilled in the art to conceptually represent circuitry for implementing the principles of the present invention. Likewise, any flow chart, flow diagram, state transitions, pseudo code, etc., may be substantially represented in a computer-readable medium to provide a variety of different ways in which a computer or processor, whether explicitly shown or not, It will be appreciated by those skilled in the art. Therefore, the above-described embodiments of the present invention can be realized in a general-purpose digital computer that can be created as a program that can be executed by a computer and operates the program using a computer-readable recording medium. The computer-readable recording medium may include a storage medium such as a magnetic storage medium (eg, a ROM, a floppy disk, a hard disk, etc.) and an optical reading medium (eg, a CD-ROM, a DVD, etc.).

The functions of the various elements shown in the figures may be provided through use of dedicated hardware as well as hardware capable of executing the software in association with the appropriate software. When provided by a processor, such functionality may be provided by a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared. Also, the explicit use of the term " processor "or" control unit "should not be construed to refer exclusively to hardware capable of executing software and includes, without limitation, digital signal processor May implicitly include memory (ROM), random access memory (RAM), and non-volatile storage.

In the claims hereof, the elements depicted as means for performing a particular function encompass any way of performing a particular function, such elements being intended to encompass a combination of circuit elements that perform a particular function, Or any form of software, including firmware, microcode, etc., in combination with circuitry suitable for carrying out the software for the processor.

Reference throughout this specification to &quot; one embodiment &quot; of the principles of the invention and various modifications of such expression in connection with this embodiment means that a particular feature, structure, characteristic or the like is included in at least one embodiment of the principles of the invention it means. Thus, the appearances of the phrase &quot; in one embodiment &quot; and any other variation disclosed throughout this specification are not necessarily all referring to the same embodiment.

In this specification, the expression 'at least one of' in the case of 'at least one of A and B' means that only the selection of the first option (A) or only the selection of the second listed option (B) It is used to encompass the selection of options (A and B). As an additional example, in the case of 'at least one of A, B and C', only the selection of the first enumerated option (A) or only the selection of the second enumerated option (B) Only the selection of the first and second listed options A and B or only the selection of the second and third listed options B and C or the selection of all three options A, B, and C). Even if more items are listed, they can be clearly extended to those skilled in the art.

So far I looked at the center of the preferred embodiment for the present invention.

All embodiments and conditional examples disclosed throughout the specification are intended to help one of ordinary skill in the art to understand the principles and concepts of the present invention. It will be understood that modifications may be made without departing from the essential features of the invention. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

Claims (21)

In the method of checking the permissions required by the application running on the device,
Obtaining source code of the application from the application;
Generating a function list including at least one function included in the source code; And
Determining the permissions required by the function list when the application is run on the device. The method of claim 1,
The acquiring step may further include additional information including previously requested authority information.
And comparing the requested authority information with the determined authority and outputting a comparison result. 3. The method of claim 2,
The additional information further includes starting position information of the source code,
The function list includes a function determined to be executable based on a control flow of the source code from the start position. The method of claim 3,
The function list may be a function list of functions determined to be not called when the application is executed by determining a condition included in the function among the functions determined to be executable. The method of claim 3,
The function list may be a function list that is determined to be not called by a virtual call when the application is executed by determining the type of the function among the functions determined to be executable. How to. 3. The method of claim 2,
The previously requested authority information is included in the manifest file,
And generating a modified manifest file based on the determined authority when the previously requested authority information and the determined authority do not match. In the server how to check the permissions required by the application,
Receiving the application from a developer device;
Acquiring additional information from the application, the source code of the application and authorization information previously requested;
Generating a function list including at least one function included in the source code;
Determining the authority required by the function list when the application is executed; And
Comparing the previously requested authority information and the determined authority, if the determined authority and the previously requested authority information match, the application is registered in the server, and the determined authority and the previously requested authority information are If it does not match, notifying the developer device of the comparison result. The method of claim 7, wherein
And when the determined authority does not match the previously requested authority information, modifying the additional information based on the determined authority. In the smart device to check the permissions required by the application,
Invoking at least one application installed on the smart device;
Receiving a selection of at least one application among the called applications;
Acquiring additional information including source code of the application and authorization information requested in advance from the at least one selected application;
Generating a function list including at least one function included in the source code;
Determining the authority required by the function list when the application is executed; And
And comparing the requested authority information with the determined authority and displaying the comparison result on the screen of the smart device. 10. The method of claim 9,
Transmitting the result of the comparison to a developer device or an application providing server. In the authority diagnosis device for checking the authority required by the application running on the device,
An application obtaining unit obtaining source code of the application from the application;
A control flow analysis unit generating a function list including at least one function included in the source code; And
And an authorization checker for determining a permission required by the function list when the application is executed on the device. 12. The method of claim 11,
The application obtaining unit further obtains additional information including previously requested authority information,
And the authority diagnosis unit compares the previously requested authority information with the determined authority and outputs a comparison result. The method of claim 12,
The additional information further includes starting position information of the source code,
And the function list includes a function determined to be executable based on a control flow of the source code from the start position. The method of claim 13,
The function list may be a function list that filters a function that is determined not to be called when the application is executed by determining a condition included in the function among the functions that are determined to be executable. The method of claim 13,
The function list may be a function list that filters a function that is determined not to be called by a virtual call when the application is executed by determining the type of the function among the functions determined to be executable. Device. The method of claim 12,
The previously requested authority information is included in the manifest file,
The authority diagnosis unit generates a manifest file modified based on the determined authority when the previously requested authority information and the determined authority do not match. For servers that check the permissions required by an application,
An application receiving unit which receives the application from a developer device;
An application obtaining unit which obtains additional information including a source code of the application and authorization information requested in advance from the application;
A control flow analysis unit generating a function list including at least one function included in the source code; And
An authority diagnosis unit that determines an authority required by the function list when the application is executed; And
An application registration unit for registering the application with the server,
The authority diagnosis unit notifies the developer device of the comparison result when the determined authority and the previously requested authority information do not match.
And the application registration unit registers the application to the server if the determined authority matches the previously requested authority information. 18. The method of claim 17,
And the authority diagnosis unit modifies the additional information based on the determined authority when the determined authority and the previously requested authority information do not match. In the smart device to check the permissions required by the application,
An application caller which calls at least one application installed in the smart device and receives a selection of at least one application from the called applications;
An application obtaining unit which obtains additional information including source code of the application and authorization information requested in advance from the at least one selected application;
A control flow analysis unit generating a function list including at least one function included in the source code;
An authority diagnosis unit that determines the authority required by the function list when the application is executed, and compares the previously requested authority information with the determined authority; And
Smart device including a display unit for displaying the comparison result on the screen of the smart device. 20. The method of claim 19,
Smart device, characterized in that further comprising a transmission unit for transmitting the comparison result to a developer device or an application providing server. A computer-readable recording medium having recorded thereon a program for executing the method of any one of claims 1 to 10 on a computer.
KR1020120025228A 2012-03-12 2012-03-12 Method and Apparatus to Evaluate Required Permissions for Application KR101900047B1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020120025228A KR101900047B1 (en) 2012-03-12 2012-03-12 Method and Apparatus to Evaluate Required Permissions for Application
PCT/KR2013/001969 WO2013137616A1 (en) 2012-03-12 2013-03-12 Method and apparatus for evaluating required permissions for application

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020120025228A KR101900047B1 (en) 2012-03-12 2012-03-12 Method and Apparatus to Evaluate Required Permissions for Application

Publications (2)

Publication Number Publication Date
KR20130116409A true KR20130116409A (en) 2013-10-24
KR101900047B1 KR101900047B1 (en) 2018-09-18

Family

ID=49161453

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020120025228A KR101900047B1 (en) 2012-03-12 2012-03-12 Method and Apparatus to Evaluate Required Permissions for Application

Country Status (2)

Country Link
KR (1) KR101900047B1 (en)
WO (1) WO2013137616A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210025885A (en) * 2019-08-28 2021-03-10 한국과학기술원 Apparatus for minimal permission analysis of applications in software defined network and the method thereof
WO2022203349A1 (en) * 2021-03-24 2022-09-29 삼성전자 주식회사 Method for controlling rights of application and electronic device supporting same
WO2023043052A1 (en) * 2021-09-15 2023-03-23 삼성전자 주식회사 Electronic device for analyzing permission regarding installation file and operation method thereof
WO2023096107A1 (en) * 2021-11-23 2023-06-01 삼성전자주식회사 Method for application security, and electronic device for performing method

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9679162B2 (en) 2014-02-24 2017-06-13 Google Inc. Application permission settings
US10114973B2 (en) 2014-05-22 2018-10-30 Google Llc Protecting user privacy from intrusive mobile applications
KR102320149B1 (en) * 2015-02-16 2021-11-01 삼성전자주식회사 Electronic devcie for executing application and method for cotrolling thereof
EP3748494A1 (en) * 2019-06-06 2020-12-09 BlackBerry Limited A tool for analysing a software distribution package
CN111259374B (en) * 2020-01-08 2021-10-12 南京苏宁加电子商务有限公司 Authority abnormity detection method and device, computer equipment and storage medium

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6981281B1 (en) 2000-06-21 2005-12-27 Microsoft Corporation Filtering a permission set using permission requests associated with a code assembly
US7099663B2 (en) * 2001-05-31 2006-08-29 Qualcomm Inc. Safe application distribution and execution in a wireless environment
CN1556959A (en) 2001-08-13 2004-12-22 �����ɷ� Using permissions to allocate device resources to an application
US20060141985A1 (en) * 2004-12-23 2006-06-29 Motorola, Inc. Dynamic management for interface access permissions
JP4274227B2 (en) * 2006-10-26 2009-06-03 コニカミノルタビジネステクノロジーズ株式会社 Image processing apparatus and program
US7967215B2 (en) * 2008-04-18 2011-06-28 Vivotech Inc. Systems, methods, and computer program products for supporting multiple contactless applications using different security keys

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210025885A (en) * 2019-08-28 2021-03-10 한국과학기술원 Apparatus for minimal permission analysis of applications in software defined network and the method thereof
WO2022203349A1 (en) * 2021-03-24 2022-09-29 삼성전자 주식회사 Method for controlling rights of application and electronic device supporting same
WO2023043052A1 (en) * 2021-09-15 2023-03-23 삼성전자 주식회사 Electronic device for analyzing permission regarding installation file and operation method thereof
WO2023096107A1 (en) * 2021-11-23 2023-06-01 삼성전자주식회사 Method for application security, and electronic device for performing method

Also Published As

Publication number Publication date
WO2013137616A1 (en) 2013-09-19
KR101900047B1 (en) 2018-09-18

Similar Documents

Publication Publication Date Title
KR101900047B1 (en) Method and Apparatus to Evaluate Required Permissions for Application
KR102546601B1 (en) Method and apparatus for protecting kernel control-flow integrity using static binary instrumentaiton
US10509644B2 (en) Method and system for controlling integrated software components
EP2626803B1 (en) Information processing device and method for preventing unauthorized application cooperation
KR101456489B1 (en) Method and apparatus for managing access privileges in a CLDC OSGi environment
US9495543B2 (en) Method and apparatus providing privacy benchmarking for mobile application development
CN109002297B (en) Deployment method, device, equipment and storage medium of consensus mechanism
US20150332043A1 (en) Application analysis system for electronic devices
US11281763B2 (en) Integrated development environment information sharing for authentication provisioning
US20140137183A1 (en) Security system and method for the android operating system
US20140245448A1 (en) Apparatus and method for analyzing permission of application for mobile devices and detecting risk
AU2021206497B2 (en) Method and apparatus for authority control, computer device and storage medium
US8671416B2 (en) Dynamic service discovery
US8601439B2 (en) Networked program dependency compatibility analysis
US10078580B2 (en) Operations to avoid wrapped mobile application operational errors due to interference from wrapper logic components
US8959485B2 (en) Security protection domain-based testing framework
BR112016016288B1 (en) METHOD IMPLEMENTED BY COMPUTER, NON-TRANSITORY COMPUTER READABLE MEDIUM, AND COMPUTING DEVICE RELATED TO PRIVACY SETTING METADATA FOR APPLICATION DEVELOPERS
Xu Techniques and tools for analyzing and understanding android applications
US20230315620A1 (en) System and Method for Diagnosing a Computing Device in Safe Mode
Johnson et al. Dazed droids: A longitudinal study of android inter-app vulnerabilities
Seghir et al. Evicheck: Digital evidence for android
US10503929B2 (en) Visually configurable privacy enforcement
GB2471482A (en) Secure method of tracing software
JP5865180B2 (en) Portable communication terminal, data communication detection device, data communication detection method, and program
Mao et al. Automatic permission inference for hybrid mobile apps

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant