KR101900047B1 - 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
KR101900047B1
KR101900047B1 KR1020120025228A KR20120025228A KR101900047B1 KR 101900047 B1 KR101900047 B1 KR 101900047B1 KR 1020120025228 A KR1020120025228 A KR 1020120025228A KR 20120025228 A KR20120025228 A KR 20120025228A KR 101900047 B1 KR101900047 B1 KR 101900047B1
Authority
KR
South Korea
Prior art keywords
application
authority
source code
function
determined
Prior art date
Application number
KR1020120025228A
Other languages
Korean (ko)
Other versions
KR20130116409A (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
Publication of KR20130116409A publication Critical patent/KR20130116409A/en
Application granted granted Critical
Publication of KR101900047B1 publication Critical patent/KR101900047B1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51Monitoring 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring 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/53Monitoring 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators

Abstract

The present invention relates to a method and apparatus for diagnosing privileges required by smart device applications.
The present invention can be used to obtain the source code of an application from an application, generate a function list containing at least one function contained in the source code, A method, apparatus and recording medium for judging.

Description

METHOD AND APPARATUS FOR DIAGNOSING PERMISSIONS REQUIRED BY APPLICATIONS [0001]

The present invention relates to a method and an apparatus for diagnosing privileges required by a smart device application, and more particularly, to a method for diagnosing what authority is required when an application is executed on a smart phone through static analysis .

The use of smart devices such as smart phones, tablets, smart TVs, and electronic readers (eg kindle fire) is becoming commonplace. As a result, the types and number of applications used in smart devices are rapidly increasing. These applications use resources such as location information of users (or devices) to provide users with more convenient and useful services.

An application needs access to access device resources such as location information. In general, applications for smart devices are largely classified as running on three different platforms: Google, Google Android, Apple's iOS, and Microsoft's Windows. have. Hereinafter, an application running on the Android platform will be described as an example.

1 is a conceptual diagram illustrating an application running on an Android platform. Referring to Figure 1, an application on Android is run in a Dalvik virtual machine. Typically, an application is identified using a single user ID and is run in a single sandbox. That is, two or more different applications, in principle, can not be executed in one sandbox unless they share the same user ID.

By default, applications run inside the sandbox process without any permissions, so they can not access the system or resources. However, it is possible to access the resource if the appropriate manifest file is declared in the application's manifest file.

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

2A shows a structure of an application file, and FIG. 2B shows a part of an exemplary manifest file. 2A, an application package includes a source code file of resources.arcs and additional information such as AndroidManifest.xml. The resource.arsc file contains the application's source code, and the AndroidManifest.xml file contains additional information such as privilege information and active process information. classes.dex is a file whose class files are formatted into bytecode that can be run in the Dalvik virtual machine. The res folder contains uncompiled resource files, and 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> entry, the permission that the application wants to use is requested. That is, the application can use the requested rights in the manifest file contained in the application, or access the resources corresponding to the rights. The application shown in the example of FIG. 2B is requested (declared) to the Internet access authority and the external storage apparatus write right in the manifest file, so that it is possible to write to the Internet connection and an external storage medium.

3 shows an operation in which a user installs and executes the application 310 in the smart device 320. Fig. Referring to FIG. 3, the Android application includes additional information including a source code and a manifest file. At the time of installation, the Android application refers to the additional information, displays the authority requested by the application, and receives confirmation from the user. After installation, the application requests 332 the resources needed for execution (332), and the device checks (334) whether the access rights for the resource are requested (declared) in the manifest file. If so, it allows access to the application's resources, and if not, does not allow it (336).

Developers must explicitly request and explicitly list the privileges required by the application in order for the application to work properly with the intent of the development. If an application tries to perform an unauthorized operation, it will be rejected by the system, causing the developer to perform unintended actions, or to cause an error / termination of the application or a system crash. Therefore, the developer must request all the privileges required by the application.

However, it is not easy for a developer to understand all the privileges required to run an application during application development. In many cases, you may want to exaggerate the privileges that are not required to run the application for ease of development at the time of development, or you may want to develop the application with all privileges required and remove privileges that are deemed unnecessary later. Furthermore, even if a developer knows exactly what permissions are required to execute an application, it is a cumbersome task to explicitly declare those permissions in a manifest file.

In addition, on the Android platform, the user is prompted for permission to run the application during the application's installation phase. However, as the number of applications requiring excessive privilege increases, users often habitually agree or confirm without carefully checking the permission list displayed on the screen. In many cases, the list of permissions displayed on the screen and the permissions that the application actually accesses are often incompatible, making it difficult for the user to know exactly what permissions the application is actually using. These problems can lead to malfunctions of smart devices caused by malicious applications or leakage of sensitive information by applications.

Also, in order to accurately understand the privileges used by an application, it is necessary to repeatedly test the compile or runtime of the application at the development stage.

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

A method for verifying a privilege required by an application executing in a device according to an embodiment of the present invention includes: obtaining a source code from an application; Generating a function list including at least one function included in the source code; And determining the privileges required by the function list when the application is executed in the device.

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

The additional information may further include start 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 a start position.

The function list may be a list of functions that have been filtered out of the functions judged to be executable by judging the conditions included in the functions and not being called when the application is executed, It may be a list of functions that have been filtered by a function that is not called by a call (vitual call).

The method may further include generating a modified manifest file based on the determined authority if the previously requested authority information is included in the manifest file and the previously determined authority information does not match the previously determined authority .

In addition, an authorization diagnosing apparatus for confirming an authorization required by an application executing in a device according to an embodiment of the present invention includes an application acquiring unit for acquiring a source code of the application from an application; A control flow analyzing unit for generating a function list including at least one function included in the source code; And an authorization diagnostic unit that determines the authorization required by the function list when the application is executed in the device.

A method for verifying the authorization required by an application in a server according to another embodiment of the present invention includes: receiving an application from a developer device; Obtaining additional information including an application's source code and pre-requested privilege information from an application; Generating a function list including at least one function included in the source code; Determining an authority required by the function list when the application is executed; And comparing the previously determined rights information with the determined authority, registering the application in the server if the determined authority and previously requested authority information match, and if the determined authority does not match the previously requested authority information, And notifying the result.

And modifying the additional information based on the determined authority if the determined authority does not match the previously requested authority information.

Further, a server for confirming a permission required by an application according to another embodiment of the present invention includes an application receiving unit for receiving an application from a developer device; An application acquiring unit for acquiring additional information including source code of an application and previously requested permission information from an application; A control flow analyzing unit for generating a function list including at least one function included in the source code; An authorization diagnostic unit for determining authorization required for the function list when the application is executed; And an application registration unit for registering the application with the server, and the authority diagnosis unit notifies the comparison result to the developer device if the judged authority does not match the previously requested authority information, If the authorization information matches, the application can be registered in the server.

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

And transmitting the comparison result to the developer device or the application providing server.

In addition, the smart device that confirms the authority required by the application according to another embodiment of the present invention may call at least one application installed in the smart device, and may receive at least one application selected from the called applications, ; An application acquiring unit for acquiring additional information including a source code of an application and previously requested privilege information from at least one selected application; A control flow analyzing unit for generating a function list including at least one function included in the source code; An authority diagnosing unit for determining an authority required by the function list when the application is executed, and comparing the previously requested authority information with the determined authority; And a display unit for displaying the comparison result on the screen of the smart device.

And a transmitting unit for transmitting the comparison result to the developer device or the application providing server.

The above-mentioned object of the present invention can also be achieved by a computer-readable recording medium storing a program for execution on a computer.

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

According to another embodiment of the present invention, even if a developer requests a broader request without requesting the necessary authority in application development, it is possible that, in registering with the server providing the application, Can be easily modified or automatically modified by the server. In addition, the application providing server can provide the user with only the application that is required to execute the application, and the user can trust the same to download and use the application.

According to another embodiment of the present invention, a user has an effect of calling an application installed in his / her smart device and easily grasping what privilege an application actually uses and what resources it can access. It also has the effect of solving the problem of not knowing what privileges an application requires, and when it is executed, which privileges are used or resources are accessed only at installation time. Further, it is possible to weaken the phenomenon of excessively setting unnecessary privileges to the execution of the application by feeding back the diagnosis result to the developer or application providing server or deleting the application according to the diagnosis result.

1 is a conceptual diagram illustrating an application running on an Android platform.
2A shows a structure of an application file, and FIG. 2B shows a part of an exemplary manifest file.
3 shows an operation in which a user installs and executes an application in a smart device.
4 is a diagram illustrating an apparatus for diagnosing privileges required by an application according to an exemplary embodiment of the present invention.
FIG. 5 is a conceptual diagram illustrating a process of a rights diagnosis unit according to an embodiment of the present invention.
FIG. 6 is a conceptual diagram illustrating a relationship of authority according to an embodiment of the present invention.
7 is a flowchart illustrating a method for diagnosing a privilege required by an application according to an embodiment of the present invention.
8 is a configuration diagram of a server for statically diagnosing a privilege required by an application according to another embodiment of the present invention.
9 is a flowchart of a method for statically diagnosing an authority required by an application in a server according to another 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 in a smart device according to another embodiment of the present invention.
FIG. 12 is a flowchart illustrating a method of diagnosing privilege of an installed application in a smart device according to another embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

4 is a diagram of an apparatus 400 for diagnosing privileges required by an application according to an embodiment of the present invention. Referring to FIG. 4, the privilege diagnosis apparatus 400 includes an application acquisition unit 410, a control flow analysis unit 420, and an authorization diagnosis unit 430 according to an embodiment of the present invention.

Generally, an application is provided in the form of a package including additional information including program source code of the application, signature information of the application, authentication information, authority information, and the like. The application can extract the source code from the application package and obtain additional information. 2, the source code includes resources.arsc, the additional information includes a folder such as an AndroidManifest.xml file and META-INF in which application components or input configurations required by applications are registered can do.

The authorization diagnostic device 400 can fetch the application installed in the smart device from the storage space of the smart device. In addition, an application may be received from an external server connected to the wired / wireless network. In this case, the authority diagnosing apparatus 400 may additionally include an application receiving unit (not shown). It will also be appreciated by those skilled in the art that even if the developer's device is not a smart device, it is possible to take the application from the developer's device and analyze the privileges required by the application for smart device using the privilege analysis device 400 .

The application acquisition unit 410 may convert the source code of the acquired application into an assembly code suitable for the platform on which the application is executed. Alternatively, you can extract the source code that has been converted from the application package into the appropriate assembly code. In the case of the Android platform, the application acquisition unit 410 can acquire the source code of the application in the form of byte code of the Dalvik virtual machine.

The control flow analysis unit 420 may analyze the source code or the assembly code of the application. The source code includes a plurality of functions and / or commands (collectively referred to as a function hereinafter), and each of the functions includes a library function of a virtual machine or a device Can be called. Some library functions may require specific privileges.

The control flow analyzer 420 basically extracts a function included in the source code and generates the list. In addition, functions included in the source code can be created by filtering functions that are not called or executed when the application is executed. The filtering operation largely includes control flow analysis, internal state tracking to exclude dead code, and type analysis of functions to respond to virtual calls.

The control flow allows you to determine the order of execution among the functions that make up the source code and whether the function is called when the application is executed. In addition, the control flow analyzing unit 420 can grasp the start point of the application by using the additional information such as the manifest file, and analyze the execution order of the functions that can be reached from the start position and whether or not the functions are called.

In addition, since it is difficult to accurately grasp a function to be executed without actually executing an application, the control flow analyzing unit 420 analyzes all the actual execution results through static analysis to see if the functions included in the source code are actually called. In this case, to improve the accuracy and efficiency of the analysis, it is possible to trace the internal state as well as the call path. In other words, control flow analysis identifies the execution order and all possible paths in execution of a program, but generally the program source is a conditional jump such as goto, if-else, case, swich, for, Because it contains a loop statement, there are functions that are not executed or invoked that do not actually happen when the value of a variable is tracked in a sinusoid such as a conditional jump. These functions are preferably excluded from the scope of analysis. For example, in a source code including a function of transmitting address book information in case of condition 1, correcting address book information in case of condition 2, and initializing address book information in case of condition 3, If the flow is analyzed, it is confirmed that all the functions of the conditions 1, 2, and 3 are executable. However, if the portion calling the function of the condition 3 through the tracking of the internal state can not actually be executed, ) Can ignore this dead code and analyze only the code of condition 1 and condition 2 as the actual calling function.

The source code may also include functions whose functions are called upon execution of the application. For example, if a child class B, C, or D that inherits class A inherits Method M, each method M redefines Method M, then the function that is called by AM () (), And DM () are determined at execution time. The control flow analyzing unit 420 may concurrently analyze the type of the function including the tracking of the inheritance relation and the type conversion of the function so as to correspond to the virtual call. In the above example, assuming that the application is transferred to B.M () at execution time, the control flow analysis unit 420 can analyze the functions of C.M () and D.M () from the actual call function.

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

FIG. 5 is a conceptual diagram showing the process of the authority diagnosis unit 430. FIG. 5, the control flow analyzing unit 420 analyzes the function 520 actually reached by the control flow analyzing unit 420 among all the functions 510 included in the application, and provides the analyzed function 520 to the permission checking unit 430 do. In the example of FIG. 5, Functions 04, 06, and 09 correspond to functions that are included in the source code of the application but are not actually executed or called.

The authority diagnosis unit 430 can diagnose the library function 530 and the authority 540 that the actual reaching functions call based on the control flow analysis result. In the example of FIG. 5, library functions A to F corresponding to Fuctions 01 to 03, 05, and 07 to be actually called are analyzed. Among these functions, except for Library D which does not require a special authority, the functions requested by the remaining functions are diagnosed. It can be seen that the authority diagnosis result of the application illustrated in FIG. 5 uses the authority of CALL_PHONE, CAMERA, INTERNET, READ_LOGS, and SEND_SMS. On the other hand, DIAGOSTIC and REBOOT privileges are set in the source code, but not in the actual application execution.

In FIG. 5, all of the functions 510 included in the source code of the application, the actual reach function 520 in the control flow analysis, the library function 530, and the authority 540 are described in a one-to-one correspondence relationship. Those skilled in the art will appreciate that there can be many-to-one / one-to-many correspondence between functions and functions, or between functions and rights.

FIG. 6 is a conceptual diagram illustrating a relationship of authority according to an embodiment of the present invention. FIG. 6 is a flow diagram illustrating an example of a method of generating an application 610 that includes all rights 610 previously requested (declared) in additional information, rights 620 required by functions included in the source code of the application, And the authority 630 judged to be necessary. All rights (610) requested in the side information may be the rights requested in the manifest file on the Android platform. In FIG. 6, the authority requested in the additional information is shown to include the authority actually required to execute the application. However, there may also be cases where a developer misconfigures the permissions required to run an application in addition to the usual cases of over-setting the permissions required to run the application. In this case, the authority diagnostic apparatus according to an embodiment of the present invention compares the previously requested authority 610 with the authority list 630 determined to be necessary for execution of the application in the additional information, and outputs the comparison result, that is, Not only the permissions that are required to run the application but also the permissions that are missing from the side information.

In the example of FIG. 6, the developer requested the CALL_PHONE and CALL_PRIVILEGED rights at the time of application development, but does not use emergency calls in real applications. In addition, a request for a calendar, an address book, a call state, a synchronization state, and a log information read right (READ_CALENDAR, READ_CONTACTS, READ_PHONE_STATE, READ_SYNC_STATE, READ_LOGS) is requested. It also requests REBOOT and RECEIVE_BOOT_COMPLETED permissions, but does not require any privileges to run the actual application. The authority diagnosis unit 430 may output all of the results of the diagnosis or only the required authority list. In addition, the user can be informed of the deletion target authority and / or the addition target authority authority in the current supplementary information. Further, the additional information may be modified based on the diagnosis result, or a code corresponding to the authority setting part may be generated and provided in a form suitable for the platform on which the application is running.

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

In step 710, the application acquisition unit 410 may acquire additional information necessary for analyzing the source code and / or the application from the application. In addition, the source code of the application may be converted into assembly code suitable for the platform on which the application is executed. In operation 720, the control flow analysis unit 420 may generate a function list including at least one function among the functions constituting the source code. In addition, by using additional information such as a manifest, it is possible to grasp the starting point of the application, analyze the control flow from the starting point, and analyze the execution order and calling state of functions that can be reached when the application is executed. You can also filter functions that are not called by tracing the source code's internal state. In addition, by analyzing the format of a function, it is possible to analyze a function that is actually transferred at the time of a virtual call, thereby filtering a function that is not transferred. In step 730, based on the list of functions generated in step 720 of the application, it is possible to diagnose the authority actually required to execute the application. In addition to the above steps, when the application package is received from an external device such as a server, the application package may further include receiving the application. In addition, when it is desired to output the diagnosis result to a display device or the like, the result of authority diagnosis of the application can be displayed using the display unit of the device.

According to the embodiment of the present invention described above, there is an effect that it is possible to easily grasp the privilege required when the application is executed through the static analysis of the source code without actually executing the application. Through this, the application developer has an effect of preventing leakage of sensitive information such as personal information by developing an application by requesting only necessary privileges.

Figure 8 is a diagram of a server 800 that statically diagnoses authorizations needed by an application in accordance with another embodiment of the present invention. In this embodiment, the server 800 includes a marketplace and a store on-line. The server 800 includes an application receiving unit 810, an application obtaining unit 820, a control flow analyzing unit 830, an authority diagnosis unit 840, and an application registration unit 850. In connection with the server 800 according to the present embodiment, the same descriptions as those already described above are omitted or abbreviated.

The application receiving unit 810 receives the application package from the application developer device 870. The application acquisition unit 820 acquires the source code and the additional information of the application from the received application. The additional information may include previously requested authorization information, and the authorization information may be included in the manifest file. The control flow analyzing unit 830 analyzes the control flow of the function and source code included in the source code of the application and generates a function list including at least one function included in the source code. The authority diagnosis unit 840 determines the authority required by the function list and compares it with the previously requested authority information. As a result of the comparison, if the additional information is requested to be not required to execute the application, the comparison result is provided to the application developer device 870. The application registration unit 850 registers the application in a marketplace provided by the server 800 or a list of applications that can be provided to the consumer device 880 when the authorization requested in the supplementary information matches the authorization list required for actual execution of the application Register.

The authority diagnosis unit 840 does not provide the diagnosis result to the application developer device 870 when authority that is not required for execution of the application is requested to the diagnosis result additional information, The rights information can be modified to provide the application package to the application registration section.

Those skilled in the art can understand that it is also possible to notify the developer device 870 of the right when necessary for execution of the application but not to request the right from the additional information or modify the additional information to include the right will be.

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

Referring to FIG. 9, in step 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 step 930, a function list is generated based on an analysis of the control flow of the application. Determines the authority required to execute the application based on the function list generated in step 940, and compares it with the previously requested authorization information included in the supplementary information. In step 950, if the authority requested when the comparison result is actually executed matches the requested authority in the additional information, the process proceeds to step 960; otherwise, the process proceeds to step 970 or 980. In step 960, the application package is registered in a marketplace provided by the server and the process is terminated. In step 970, the diagnostic result is transmitted to the developer device. In step 980, based on the diagnosis result, the additional information is modified so as to include only the authority necessary for executing the application, and then the modified application package is registered in the marketplace provided by the server.

According to another embodiment of the present invention, even if the developer requests a broader request without necessarily requesting the application development, the developer requests only the authority necessary to execute the application in the process of registering with the server providing the application Additional information can be easily modified or automatically modified by the server. In addition, the application providing server can also provide the user with only the application required to execute the application, and the user can trust the same to 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 embodiment includes an application calling unit 1010, an application obtaining unit 1020, a control flow analyzing unit 1030, an authority diagnosis unit 1040 and a display unit 1050. In the description of this embodiment, the description overlapping with the above-described embodiment is omitted.

Referring to FIG. 10, the application calling unit 1010 calls at least one application installed in the smart device 1000. The application calling unit 1010 may call all the applications installed in the smart device 1000 and may call all the applications other than the applications diagnosed as matching the rights already requested from the additional information with the rights that the application actually uses It is possible.

The application obtaining unit 1010 obtains the source code and the additional information for at least one application that has been called, and the control flow analyzing unit 1020 analyzes the control flow of the application based on the acquired 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 previously requested authority is matched in the side information. The above-described process may be performed for each application invoked individually, or may be performed only for an application selected by the user among the invoked applications. The display unit 1040 displays the diagnostic result on the display screen of the smart device.

11 is a diagram showing an example of diagnosing an authority actually used by an application installed in the smart device 1000. In FIG. 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, CAMERA, FLASHLIGHT, and NFC among the privileges declared in the additional information are not actually used. The user can feedback the diagnosis result to the developer or the application providing server, or delete the application.

Although not shown, those skilled in the art will be able to perform authorization diagnostics on all or a plurality of applications 1110 that have been invoked, display the results of the diagnostics in a list of a plurality of applications 1110 and, if a particular application is selected by the user, It will be appreciated that it is also possible to display the results (1120).

12 is a flowchart illustrating a method of diagnosing an authority of an installed application in the smart device 1000 according to another embodiment of the present invention. Referring to FIG. 12, at step 1210, at least one application called to the device is called. In step 1220, among the applications called by the user, an input for selecting an application to be authorized is received. In step 1230, the source code and the 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 step 1250, an authority necessary for executing the application is diagnosed on the basis of the function list. In step 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 repetitively for all applications called in step 1210, or only for one or more selected applications among the called applications. In addition to the above steps, it is also possible to feed back the diagnosis result to the developer device or application providing server or to delete the application.

According to another embodiment of the present invention, a user has an effect of calling an application installed in his / her smart device and easily grasping what privilege an application actually uses and what resources it can access. It also has the effect of solving the problem of not knowing what privileges an application requires, and when it is executed, which privileges are used or resources are accessed only at installation time. Further, it is possible to weaken the phenomenon of excessively setting unnecessary privileges to the execution of the application by feeding back the diagnosis result to the developer or application providing server or deleting the application according to the diagnosis result.

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 includes a storage medium such as a magnetic storage medium (e.g., ROM, floppy disk, hard disk, etc.), optical reading medium (e.g., CD ROM,

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.

The present invention has been described with reference to the preferred embodiments.

It is to be understood that all embodiments and conditional statements disclosed herein are intended to assist the reader in understanding the principles and concepts of the present invention to those skilled in the art, It will be understood that the invention may be embodied in various other forms without departing from the spirit or essential characteristics thereof. 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)

  1. In a method for verifying the authorization required by an application running on a device,
    Obtaining a source code of the application from the application;
    Generating a function list including at least one function included in the source code; And
    Determining an authorization required by the function list when the application is executed in the device,
    Wherein the function list includes a function determined to be executable based on a control flow of the source code from a start position of the source code.
  2. The method according to claim 1,
    Wherein the step of acquiring further acquires additional information including previously requested permission information,
    Comparing the previously requested rights information with the determined authority and outputting a comparison result.
  3. 3. The method of claim 2,
    And the additional information further includes start position information of the source code.
  4. The method of claim 3,
    Wherein the function list is a list of functions that are judged to be not executed when the application is executed by judging conditions included in the function among the functions determined to be executable.
  5. The method of claim 3,
    Wherein the function list is a list of functions that are judged to be invoked by a virtual call when the application is executed by judging a type of the function among the functions judged to be executable, How to.
  6. 3. The method of claim 2,
    Wherein the previously requested rights information is contained in a manifest file,
    And generating a modified manifest file based on the determined authority if the previously requested authority information does not match the determined authority.
  7. In a way to verify the permissions required by an application on a server,
    Receiving the application from a developer device;
    Obtaining additional information including a source code of the application and previously requested permission information from the application;
    Generating a function list including at least one function included in the source code;
    Determining an authority required by the function list when the application is executed; And
    And compares the previously-requested authority information with the determined authority, registers the application in the server if the determined authority matches the previously-requested authority information, and transmits the determined authority and the previously- And notifying the developer device of the comparison result if it does not match.
  8. 8. The method of claim 7,
    And modifying the additional information based on the determined authority if the determined authority does not match the previously requested authority information.
  9. In a way to verify the permissions an application needs in a smart device,
    Calling at least one application installed in the smart device;
    Receiving a selection of at least one application from among the called applications;
    Obtaining additional information including a source code of the application and previously requested permission information from the selected at least one application;
    Generating a function list including at least one function included in the source code;
    Determining an authority required by the function list when the application is executed; And
    Comparing the previously requested rights information with the determined rights and displaying a comparison result on a screen of the smart device,
    Wherein the function list includes a function determined to be executable based on a control flow of the source code from a start position of the source code.
  10. 10. The method of claim 9,
    And transmitting the comparison result to the developer device or the application providing server.
  11. 1. An authority diagnostic apparatus for verifying an authority required by an application executing in a device,
    An application acquiring unit for acquiring a source code of the application from the application;
    A control flow analyzing unit for generating a function list including at least one function included in the source code; And
    And an authorization diagnostic unit for determining authorization required by the function list when the application is executed in the device,
    Wherein the function list includes a function determined to be executable based on a control flow of the source code from a start position of the source code.
  12. 12. The method of claim 11,
    Wherein the application obtaining unit further obtains additional information including previously requested permission information,
    Wherein the authority diagnostic unit compares the previously requested authority information with the determined authority and outputs a comparison result.
  13. 13. The method of claim 12,
    Wherein the additional information further includes start position information of the source code.
  14. 14. The method of claim 13,
    Wherein the function list is a list of functions obtained by filtering a function determined to be not invoked when the application is executed by determining a condition included in the function among the functions determined to be executable.
  15. 14. The method of claim 13,
    Wherein the function list is a list of functions obtained by filtering a function determined to be not invoked by a virtual call when the application is executed by determining the type of the function among the functions determined to be executable .
  16. 13. The method of claim 12,
    Wherein the previously requested rights information is contained in a manifest file,
    Wherein the authority diagnostic unit generates a modified manifest file based on the determined authority if the previously requested authority information does not match the determined authority.
  17. For a server that verifies the permissions required by an application,
    An application receiving unit for receiving the application from a developer device;
    An application acquiring unit for acquiring additional information including a source code of the application and previously requested permission information from the application;
    A control flow analyzing unit for generating a function list including at least one function included in the source code; And
    An authorization diagnostic unit for determining authorization required for the function list when the application is executed; And
    And an application registration unit for registering the application in the server,
    Wherein the authority diagnostic unit compares the determined authority with the previously requested authority information and notifies the comparison result to the developer device if the determined authority does not match the previously requested authority information,
    Wherein the application registration unit compares the determined authority with the previously requested authority information, and registers the application in the server when the determined authority matches the previously requested authority information.
  18. 18. The method of claim 17,
    Wherein the authority diagnosis unit modifies the additional information based on the determined authority if the determined authority does not match the previously requested authority information.
  19. In a smart device that verifies the rights an application needs,
    An application calling unit calling at least one application installed in the smart device and receiving a selection of at least one application from among the called applications;
    An application acquiring unit for acquiring additional information including a source code of the application and previously requested permission information from the selected at least one application;
    A control flow analyzing unit for generating a function list including at least one function included in the source code;
    An authority diagnostic unit for determining an authority required by the function list when the application is executed, and comparing the previously requested authority information with the determined authority; And
    And a display unit for displaying the comparison result on a screen of the smart device,
    Wherein the function list includes a function determined to be executable based on a control flow of the source code from a start position of the source code.
  20. 20. The method of claim 19,
    And a transmitting unit for transmitting the comparison result to the developer device or the application providing server.
  21. A computer-readable recording medium storing a program for causing a computer to execute the method of any one of claims 1 to 10.
KR1020120025228A 2012-03-12 2012-03-12 Method and Apparatus to Evaluate Required Permissions for Application KR101900047B1 (en)

Priority Applications (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

Applications Claiming Priority (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

Publications (2)

Publication Number Publication Date
KR20130116409A KR20130116409A (en) 2013-10-24
KR101900047B1 true 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)

Families Citing this family (3)

* 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
KR20160100746A (en) 2015-02-16 2016-08-24 삼성전자주식회사 Electronic devcie for executing application and method for cotrolling thereof

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001098876A2 (en) 2000-06-21 2001-12-27 Microsoft Corporation Filtering a permission set using permission requests associated with a code assembly
US20080100610A1 (en) * 2006-10-26 2008-05-01 Konica Minolta Business Technologies, Inc. Image processing device and computer-readable medium storing program
US7743407B2 (en) 2001-08-13 2010-06-22 Qualcomm Incorporated Using permissions to allocate device resources to an application

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7099663B2 (en) * 2001-05-31 2006-08-29 Qualcomm Inc. Safe application distribution and execution in a wireless environment
US20060141985A1 (en) * 2004-12-23 2006-06-29 Motorola, Inc. Dynamic management for interface access permissions
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

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001098876A2 (en) 2000-06-21 2001-12-27 Microsoft Corporation Filtering a permission set using permission requests associated with a code assembly
US7743407B2 (en) 2001-08-13 2010-06-22 Qualcomm Incorporated Using permissions to allocate device resources to an application
US20080100610A1 (en) * 2006-10-26 2008-05-01 Konica Minolta Business Technologies, Inc. Image processing device and computer-readable medium storing program

Also Published As

Publication number Publication date
WO2013137616A1 (en) 2013-09-19
KR20130116409A (en) 2013-10-24

Similar Documents

Publication Publication Date Title
US10133564B2 (en) Application wrapping system and method
CN108351770B (en) Method and implementation environment for securely implementing program commands
US9201632B2 (en) Systems and methods for incremental software development
Davis et al. RetroSkeleton: retrofitting android apps
Yang et al. Appintent: Analyzing sensitive data transmission in android for privacy leakage detection
Cao et al. EdgeMiner: Automatically Detecting Implicit Control Flow Transitions through the Android Framework.
Arzt et al. Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps
Li et al. Static analysis of android apps: A systematic literature review
CN104885092B (en) Security system and method for operating system
Liu et al. Efficient privilege de-escalation for ad libraries in mobile apps
KR101872141B1 (en) Consistent extension points to allow an extension to extend functionality of an application to another application
Zhauniarovich et al. Stadyna: Addressing the problem of dynamic code updates in the security analysis of android applications
Wei et al. Permission evolution in the android ecosystem
Acar et al. Sok: Lessons learned from android security research for appified software platforms
US10545775B2 (en) Hook framework
US20170034180A1 (en) Allowing first module of computer code to make use of service provided by second module while ensuring security of system
Sun et al. Taintart: A practical multi-level information-flow tracking system for android runtime
Grace et al. Unsafe exposure analysis of mobile in-app advertisements
US8850581B2 (en) Identification of malware detection signature candidate code
JP6248153B2 (en) Activate trust level
US9152521B2 (en) Systems and methods for testing content of mobile communication devices
US8732529B2 (en) Mobile communication terminal capable of testing application and method thereof
WO2015124018A1 (en) Method and apparatus for application access based on intelligent terminal device
Stevens et al. Asking for (and about) permissions used by android apps
CN102799817B (en) For the system and method using Intel Virtualization Technology to carry out malware protection

Legal Events

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