KR102657534B1 - Electronic device and method for veryfying integrity of application - Google Patents

Abstract

An electronic device according to various embodiments includes a communication module; and a processor, wherein the processor receives, through the communication module, an installation file of an application including an application package and a signature database including a first signature corresponding to at least a portion of the application package - the first The signature is confirmed based on a first verification target code region confirmed based on the DEX file corresponding to the application package, confirming the first signature from the signature database, and responding to an execution command of the application, Configure to check the second signature based on the second verification target code area confirmed based on the ODEX file of the application, and check the integrity of the application based on whether the second signature is the same as the first signature. It can be. Various other embodiments are possible.

Description

Electronic device for verifying the integrity of an application and a method for verifying the integrity of the application {ELECTRONIC DEVICE AND METHOD FOR VERYFYING INTEGRITY OF APPLICATION}

Various embodiments relate to an electronic device for verifying the integrity of an application and a method for verifying the integrity of an application. More specifically, an electronic device for verifying the integrity of an optimized DEX and a method for verifying the integrity of an optimized DEX. It's about method.

With the spread of smartphones, the application market continues to grow. As the number of applications distributed within the mobile ecosystem increases, various discussions are taking place regarding the development and distribution of applications. In particular, in situations where the use of open mobile platforms is dominant, several methods are known to ensure the security and stability of applications. For example, various methods are known for verifying the integrity of a DEX file included in an application package file.

In existing electronic devices and methods for verifying the integrity of an application, when the execution command of the application is confirmed, the electronic device generates an ODEX file by converting the DEX file of the application in real time, and generates an ODEX file converted from the DEX file of the application. Compare with cache ODEX file. In this case, the overhead is large because the ODEX file is created by converting the DEX file of the application in real time every time the application execution command is confirmed. Additionally, ODEX files converted from electronic devices take up a lot of storage space. Additionally, since existing electronic devices and methods for verifying the integrity of an application only compare ODEX files, there is a possibility of incorrectly determining the integrity if the optimized DEX is included in the VDEX file rather than the ODEX file.

According to an electronic device and a method performed on the electronic device according to various embodiments, a signature verified based on the DEX file of the application may be included in the installation file of the application. According to various embodiments, the signature may be a hash generated based on at least a portion of the cache file. According to various embodiments, if the optimized DEX cannot be confirmed from the ODEX file, the signature can be confirmed based on the VDEX file.

According to various embodiments, an electronic device includes a communication module; and a processor, wherein the processor receives, through the communication module, an installation file of an application including an application package and a signature database including a first signature corresponding to at least a portion of the application package - the first The signature is confirmed based on a first verification target code region confirmed based on the DEX file corresponding to the application package, confirming the first signature from the signature database, and responding to an execution command of the application, Configure to check the second signature based on the second verification target code area confirmed based on the ODEX file of the application, and check the integrity of the application based on whether the second signature is the same as the first signature. It can be.

According to various embodiments, an electronic device includes a communication module; and a processor, wherein the processor: receives, through the communication module, an installation file of an application including an application package, from a signature database including a first signature corresponding to at least a portion of the application package, the communication module. Receive the first signature through - the first signature is confirmed based on a first verification target code region confirmed based on the DEX file corresponding to the application package - in response to an execution command of the application , confirming a second signature based on a second verification target code region confirmed based on the ODEX file of the application; It can be set to check the integrity of the application based on whether the second signature is the same as the first signature.

According to various embodiments, a method for verifying the integrity of an application includes: receiving an installation file of the application including an application package and a signature database including a first signature corresponding to at least a portion of the application package - the first The signature is confirmed based on a first code region to be verified, which is confirmed based on the DEX file corresponding to the application package; Verifying the first signature from the signature database; In response to an execution command of the application, verifying a second signature based on a second code region to be verified that is verified based on an ODEX file of the application; It may include an operation of checking the integrity of the application based on whether the second signature is the same as the first signature.

According to various embodiments, a method for verifying the integrity of an application includes: receiving an installation file of the application including an application package; An operation of receiving the first signature from a signature database including a first signature corresponding to at least some of the application packages, wherein the first signature is a first verification target confirmed based on a DEX file corresponding to the application package. Identified based on code area -; In response to an execution command of the application, verifying a second signature based on a second code region to be verified that is verified based on an ODEX file of the application; It may include an operation of checking the integrity of the application based on whether the second signature is the same as the first signature.

According to various embodiments, a method for verifying the integrity of an electronic device and an application according to various embodiments is provided. Accordingly, the signature verified based on the DEX file of the application may be included in the installation file of the application. Therefore, since there is no need to convert or generate a signature based on the DEX file of the application for verification every time an application execution command is confirmed, the overhead for verification can be reduced.

Additionally, according to various embodiments, the signature may be a hash generated based on at least a portion of the optimized DEX file. Therefore, the storage space required for verification can be reduced.

Additionally, according to various embodiments, when the electronic device cannot confirm the optimized DEX from the ODEX file, it can confirm the signature based on the VDEX file. Therefore, even if the optimized DEX is included in a VDEX file rather than an ODEX file, the integrity can be correctly determined and the false positive rate of tampering can be reduced.

1 shows a block diagram of an electronic device in a network environment according to various embodiments.
Figure 2 shows a block diagram illustrating a program according to various embodiments.
3A shows a SW module according to various embodiments.
3B shows a SW module according to various embodiments.
FIG. 4A illustrates a diagram for explaining a first signature generation process according to various embodiments.
FIG. 4B illustrates a diagram illustrating an application integrity verification process according to various embodiments.
FIG. 5 illustrates a diagram for explaining the operation of an electronic device according to various embodiments.
Figure 6 shows a flowchart for explaining the operation of an electronic device according to various embodiments.
Figure 7 shows a flowchart for explaining the operation of an electronic device according to various embodiments.
Figure 8 shows a flowchart for explaining the operation of an electronic device according to various embodiments.
FIG. 9A shows a flowchart for explaining the operation of an electronic device according to various embodiments.
FIG. 9B shows a flowchart for explaining the operation of an electronic device according to various embodiments.
Figure 10 shows a flowchart for explaining the operation of an electronic device according to various embodiments.

1 is a block diagram of an electronic device 101 in a network environment 100, according to various embodiments. Referring to FIG. 1, in the network environment 100, the electronic device 101 communicates with the electronic device 102 through a first network 198 (e.g., a short-range wireless communication network) or a second network 199. It is possible to communicate with the electronic device 104 or the server 108 through (e.g., a long-distance wireless communication network). According to one embodiment, the electronic device 101 may communicate with the electronic device 104 through the server 108. According to one embodiment, the electronic device 101 includes a processor 120, a memory 130, an input device 150, an audio output device 155, a display device 160, an audio module 170, and a sensor module ( 176), interface 177, haptic module 179, camera module 180, power management module 188, battery 189, communication module 190, subscriber identification module 196, or antenna module 197 ) may include. In some embodiments, at least one of these components (eg, the display device 160 or the camera module 180) may be omitted, or one or more other components may be added to the electronic device 101. In some embodiments, some of these components may be implemented as a single integrated circuit. For example, the sensor module 176 (e.g., a fingerprint sensor, an iris sensor, or an illumination sensor) may be implemented while being embedded in the display device 160 (e.g., a display).

The processor 120, for example, executes software (e.g., program 140) to configure at least one other component (e.g., hardware or software component) of the electronic device 101 connected to the processor 120. It can be controlled and various data processing or calculations can be performed. According to one embodiment, as at least part of data processing or computation, the processor 120 stores commands or data received from another component (e.g., sensor module 176 or communication module 190) in volatile memory 132. The commands or data stored in the volatile memory 132 can be processed, and the resulting data can be stored in the non-volatile memory 134. According to one embodiment, the processor 120 includes a main processor 121 (e.g., a central processing unit or an application processor), and an auxiliary processor 123 that can operate independently or together (e.g., a graphics processing unit, an image signal processor). , sensor hub processor, or communication processor). Additionally or alternatively, the auxiliary processor 123 may be set to use less power than the main processor 121 or to specialize in a designated function. The auxiliary processor 123 may be implemented separately from the main processor 121 or as part of it.

The auxiliary processor 123 may, for example, act on behalf of the main processor 121 while the main processor 121 is in an inactive (e.g., sleep) state, or while the main processor 121 is in an active (e.g., application execution) state. ), along with the main processor 121, at least one of the components of the electronic device 101 (e.g., the display device 160, the sensor module 176, or the communication module 190) At least some of the functions or states related to can be controlled. According to one embodiment, coprocessor 123 (e.g., image signal processor or communication processor) may be implemented as part of another functionally related component (e.g., camera module 180 or communication module 190). there is.

The memory 130 may store various data used by at least one component (eg, the processor 120 or the sensor module 176) of the electronic device 101. Data may include, for example, input data or output data for software (e.g., program 140) and instructions related thereto. Memory 130 may include volatile memory 132 or non-volatile memory 134.

The program 140 may be stored as software in the memory 130 and may include, for example, an operating system 142, middleware 144, or application 146.

The input device 150 may receive commands or data to be used in a component of the electronic device 101 (e.g., the processor 120) from outside the electronic device 101 (e.g., a user). The input device 150 may include, for example, a microphone, mouse, keyboard, or digital pen (eg, stylus pen).

The sound output device 155 may output sound signals to the outside of the electronic device 101. The sound output device 155 may include, for example, a speaker or a receiver. The speaker can be used for general purposes such as multimedia playback or recording playback, and the receiver can be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part of it.

The display device 160 can visually provide information to the outside of the electronic device 101 (eg, a user). The display device 160 may include, for example, a display, a hologram device, or a projector, and a control circuit for controlling the device. According to one embodiment, the display device 160 may include touch circuitry configured to detect a touch, or a sensor circuit configured to measure the intensity of force generated by the touch (e.g., a pressure sensor). there is.

The audio module 170 can convert sound into an electrical signal or, conversely, convert an electrical signal into sound. According to one embodiment, the audio module 170 acquires sound through the input device 150, the sound output device 155, or an external electronic device (e.g., directly or wirelessly connected to the electronic device 101). Sound may be output through an electronic device 102 (e.g., speaker or headphone).

The sensor module 176 detects the operating state (e.g., power or temperature) of the electronic device 101 or the external environmental state (e.g., user state) and generates an electrical signal or data value corresponding to the detected state. can do. According to one embodiment, the sensor module 176 includes, for example, a gesture sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, It may include a temperature sensor, humidity sensor, or light sensor.

The interface 177 may support one or more designated protocols that can be used to connect the electronic device 101 directly or wirelessly with an external electronic device (eg, the electronic device 102). According to one embodiment, the interface 177 may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

The connection terminal 178 may include a connector through which the electronic device 101 can be physically connected to an external electronic device (eg, the electronic device 102). According to one embodiment, the connection terminal 178 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).

The haptic module 179 can convert electrical signals into mechanical stimulation (e.g., vibration or movement) or electrical stimulation that the user can perceive through tactile or kinesthetic senses. According to one embodiment, the haptic module 179 may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

The camera module 180 can capture still images and moving images. According to one embodiment, the camera module 180 may include one or more lenses, image sensors, image signal processors, or flashes.

The power management module 188 can manage power supplied to the electronic device 101. According to one embodiment, the power management module 388 may be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

The battery 189 may supply power to at least one component of the electronic device 101. According to one embodiment, the battery 189 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

The communication module 190 provides a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device 101 and an external electronic device (e.g., the electronic device 102, the electronic device 104, or the server 108). It can support establishment and communication through established communication channels. Communication module 190 operates independently of processor 120 (e.g., an application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module 190 is a wireless communication module 192 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (e.g., : LAN (local area network) communication module, or power line communication module) may be included. Among these communication modules, the corresponding communication module is a first network 198 (e.g., a short-range communication network such as Bluetooth, WiFi direct, or IrDA (infrared data association)) or a second network 199 (e.g., a cellular network, the Internet, or It can communicate with external electronic devices through a computer network (e.g., a telecommunication network such as a LAN or WAN). These various types of communication modules may be integrated into one component (e.g., a single chip) or may be implemented as a plurality of separate components (e.g., multiple chips). The wireless communication module 192 uses subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module 196 within a communication network such as the first network 198 or the second network 199. The electronic device 101 can be confirmed and authenticated.

The antenna module 197 may transmit or receive signals or power to or from the outside (e.g., an external electronic device). According to one embodiment, the antenna module may include one antenna including a radiator made of a conductor or a conductive pattern formed on a substrate (eg, PCB). According to one embodiment, the antenna module 197 may include a plurality of antennas. In this case, at least one antenna suitable for a communication method used in a communication network such as the first network 198 or the second network 199 is connected to the plurality of antennas by, for example, the communication module 190. can be selected Signals or power may be transmitted or received between the communication module 190 and an external electronic device through the selected at least one antenna. According to some embodiments, other components (eg, RFIC) in addition to the radiator may be additionally formed as part of the antenna module 197.

At least some of the components are connected to each other through a communication method between peripheral devices (e.g., bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)) and signal ( (e.g. commands or data) can be exchanged with each other.

According to one embodiment, commands or data may be transmitted or received between the electronic device 101 and the external electronic device 104 through the server 108 connected to the second network 199. Each of the electronic devices 102 and 104 may be the same or different type of device from the electronic device 101. According to one embodiment, all or part of the operations performed in the electronic device 101 may be executed in one or more of the external electronic devices 102, 104, or 108. For example, when the electronic device 101 must perform a certain function or service automatically or in response to a request from a user or another device, the electronic device 101 may perform the function or service instead of executing the function or service on its own. Alternatively, or additionally, one or more external electronic devices may be requested to perform at least part of the function or service. One or more external electronic devices that have received the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device 101. The electronic device 101 may process the result as is or additionally and provide it as at least part of a response to the request. For this purpose, for example, cloud computing, distributed computing, or client-server computing technology. This can be used.

Figure 2 is a block diagram 200 illustrating a program 240 according to various embodiments. According to one embodiment, the program 240 includes an operating system 242, middleware 244, or an application 246 executable on the operating system 242 for controlling one or more resources of the electronic device 101. It can be included. Operating system 242 may include, for example, Android ^TM , iOS ^TM , Windows ^TM , Symbian ^TM , Tizen ^TM , or Bada ^TM . At least some of the programs 240 are preloaded into the electronic device 101, for example, during manufacturing, or are stored in an external electronic device (e.g., the electronic device 102 or 104, or a server) when used by a user. It can be downloaded or updated from 108)).

The operating system 242 may control management (eg, allocation or retrieval) of one or more system resources (eg, process, memory, or power) of the electronic device 101 . Operating system 242 may additionally or alternatively operate on other hardware devices of electronic device 101, such as input device 150, audio output device 155, display device 160, audio module 170. , sensor module 176, interface 177, haptic module 179, camera module 180, power management module 188, battery 189, communication module 190, subscriber identification module 196, or It may include one or more driver programs for driving the antenna module 197.

The middleware 244 may provide various functions to the application 246 so that functions or information provided from one or more resources of the electronic device 101 can be used by the application 246. The middleware 244 includes, for example, an application manager 201, a window manager 203, a multimedia manager 205, a resource manager 207, a power manager 209, a database manager 211, and a package manager 213. ), connectivity manager (215), notification manager (217), location manager (219), graphics manager (221), security manager (223), call manager (225), or voice recognition manager (227). You can.

The application manager 201 may, for example, manage the life cycle of the application 246. The window manager 203 may, for example, manage one or more GUI resources used on the screen. For example, the multimedia manager 205 identifies one or more formats required for playing media files, and encodes or decodes the corresponding media file using a codec suitable for the selected format. It can be done. The resource manager 207 may manage, for example, the source code of the application 246 or the memory space of the memory 130 . The power manager 209 manages, for example, the capacity, temperature, or power of the battery 189, and may use this information to determine or provide related information necessary for the operation of the electronic device 101. . According to one embodiment, the power manager 209 may interface with a basic input/output system (BIOS) (not shown) of the electronic device 101.

Database manager 211 may create, search, or change a database to be used by application 246, for example. The package manager 213 may, for example, manage the installation or update of applications distributed in the form of package files. The connectivity manager 215 may manage, for example, a wireless connection or direct connection between the electronic device 101 and an external electronic device. For example, the notification manager 217 may provide a function for notifying the user of the occurrence of a designated event (eg, an incoming call, message, or alarm). The location manager 219 may, for example, manage location information of the electronic device 101. The graphics manager 221 may, for example, manage one or more graphic effects to be provided to the user or a user interface related thereto.

Security manager 223 may provide, for example, system security or user authentication. The telephony manager 225 may manage, for example, a voice call function or a video call function provided by the electronic device 101. For example, the voice recognition manager 227 transmits the user's voice data to the server 108 and provides a command corresponding to a function to be performed in the electronic device 101 based at least in part on the voice data, Alternatively, text data converted based at least in part on the voice data may be received from the server 108. According to one embodiment, the middleware 244 may dynamically delete some existing components or add new components. According to one embodiment, at least a portion of the middleware 244 may be included as part of the operating system 242 or may be implemented as separate software different from the operating system 242.

The application 246 includes, for example, home 251, dialer 253, SMS/MMS (255), instant message (IM) 257, browser 259, camera 261, and alarm 263. , Contacts (265), Voice Recognition (267), Email (269), Calendar (271), Media Player (273), Album (275), Watch (277), Health (279) (such as exercise amount or blood sugar) It may include applications that measure biometric information) or environmental information 281 (e.g., measure atmospheric pressure, humidity, or temperature information). According to one embodiment, the application 246 may further include an information exchange application (not shown) that can support information exchange between the electronic device 101 and an external electronic device. The information exchange application may include, for example, a notification relay application configured to deliver designated information (e.g., calls, messages, or alarms) to an external electronic device, or a device management application configured to manage the external electronic device. there is. The notification relay application, for example, transmits notification information corresponding to a specified event (e.g., mail reception) generated in another application (e.g., email application 269) of the electronic device 101 to an external electronic device. You can. Additionally or alternatively, the notification relay application may receive notification information from an external electronic device and provide it to the user of the electronic device 101.

The device management application may, for example, control the power (e.g., turn-on or turn-on) of an external electronic device or some component thereof (e.g., display device 160 or camera module 180) that communicates with the electronic device 101. -off) or functions (e.g., brightness, resolution, or focus of the display device 160 or the camera module 180) can be controlled. A device management application may additionally or alternatively support installation, deletion, or update of applications running on external electronic devices.

Figure 3A shows a SW module 300a according to various embodiments. The SW module 300a includes an application package 330a, a signature database 310a, and a DEX signature generation unit 322a, a DEX verification target code area extractor 326a, and a signature storage unit included in the developer electronic device 320a. It may include part 324a. The application package 330a is an image of an application and may be, for example, an APK format file. The application package 330a may include a DEX 332a, which is an executable image of the corresponding application.

The DEX verification target code area extractor 326a may extract the DEX 332a from the application package 330a of the application subject to protection and generate a first signature corresponding to the application subject to protection. The DEX verification target code area extractor 326a may identify the first verification target code area based on the DEX 332a corresponding to the application package 330a. According to various embodiments, the DEX verification target code area extractor 326a parses the DEX 332a corresponding to the application package 330a and then applies a mapping rule to generate a first optimized DEX file, and generates a first optimized DEX file. Operation codes and registers are extracted from the optimized DEX file, the extracted operation codes and registers are parsed in function units or code area units and divided into a plurality of first parts, and at least one of the plurality of first parts is selected as the first verification target. You can check it as a code area. The DEX signature generator 322a may generate a first signature based on the first code region to be verified by the DEX code region to be verified extractor 326a. According to various embodiments, the DEX signature generation unit 322a may generate the first signature by applying a hash function to the first verification target code region identified by the DEX verification target code region extractor 326a. According to various embodiments, there is no limitation on the specific type of hash function. The signature storage unit 324a may store the first signature generated by the DEX signature generation unit 322a in the signature database 310a. According to various embodiments, the signature database 310a may store the first signature and information on codes corresponding to the first signature, for example, function name or location.

FIG. 3B shows a SW module 300b according to various embodiments. The SW module 300b includes a comparison unit 321b, a signature extraction unit 323b, a cache signature generation unit 325b, and a signature database 310b included in the virtual machine 330b and the user electronic device 320b. It may include a cache verification target code area extraction unit 327b. The virtual machine 330b may be an execution environment for an application. According to various embodiments, virtual machine 330b may be a Dalvik virtual machine or an Android runtime. According to various embodiments, the virtual machine 330b may load the application cache 334b into memory in response to an application execution command. According to various embodiments, the application cache 334b may be an executable image of an application used in the virtual machine 330b. Depending on various embodiments, application cache 334b may be an ODEX file or a VDEX file.

According to various embodiments, the cache verification target code area extractor 327b may identify the second verification target code area based on the application cache 334b. According to various embodiments, the cache verification target code area extractor 327b extracts the second optimized DEX file from the application cache 334b, extracts the operation code and register from the second optimized DEX file, and extracts the extracted The operation code and register may be parsed in function units or code area units and divided into a plurality of second parts, and at least one of the plurality of second parts may be confirmed as the second verification target code area. The cache signature generator 325b may generate a second signature based on the second code region to be verified that is confirmed by the cache code region extractor 327b. According to various embodiments, the cache signature generation unit 325b may generate a second signature by applying a hash function to the second verification target code area identified by the cache verification target code area extractor 327b. According to various embodiments, there is no limitation on the specific type of hash function. According to various embodiments, the hash function may be the same as the hash function applied by the DEX signature generator 322a described with reference to FIG. 3A. The signature extraction unit 323b may extract a signature to be compared with the second signature from the signature database 310b. According to various embodiments, the signature to be compared with the second signature may be the first signature described with reference to FIG. 3A. The comparison unit 321b may compare the second signature generated in response to the execution command of the application with the signature stored in the signature database 310b. According to various embodiments, the comparison unit 321b may check whether the second signature is the same as the first signature described with reference to FIG. 3A.

FIG. 4A illustrates a diagram illustrating a first signature generation process 400a according to various embodiments. Specifically, the first signature creation process 400a may be performed before the application is installed on the user's electronic device (eg, electronic device 101). According to various embodiments, the first signature generation process 400a may be performed during the application development process by an electronic device used for application development (hereinafter, “developer electronic device”).

The developer electronic device can check the DEX file 420a corresponding to the application package 410a from the application package 410a. According to various embodiments, the process of checking the DEX file 420a corresponding to the application package 410a from the application package 410a is performed by the DEX verification target code area extractor 326a included in the developer electronic device. It can be. According to various embodiments, the application package 410a may have an apk extension. The developer electronic device may parse the confirmed DEX file 420a and apply mapping rules to generate the first optimized DEX file 430a. According to various embodiments, the process of generating the first optimized DEX file 430a may be performed by the DEX verification target code area extractor 326a included in the developer electronic device. According to various embodiments, at least some of the mapping rules may be as shown in Table 1 below, for example.

Operation code (hex) Operation code name Android 5 Android 6, 7, 8 Optimized operation code Optimized operation code name Optimized operation code Optimized operation code name 0E return-void 73 return-void-no-barrier 73 return-void-no-barrier 1F check-cast 00 nop 00 nop 52 iget E3 iget-quick E3 iget-quick 53 iget-wide E4 iget-wide-quick E4 iget-wide-quick 54 iget-object E5 iget-object-quick E5 iget-object-quick 59 iput E6 iput-quick E6 iput-quick 5C iput-boolean E.B. iput-boolean-quick 5D iput-byte EC iput-byte-quick 5E iput-char ED iput-char-quick 5F iput-short EE iput-short-quick 5A iput-wide E7 iput-wide-quick E7 iput-wide-quick 5B iput-object E8 iput-object-quick E8 iput-object-quick 6E invoke-virtual E9 iput-virtual-quick E9 invoke-virtual-quick 74 invoke-virtual/range EA invoke-virtual-quick/range EA invoke-virtual-quick/range 55 iget-boolean - - EF iget-boolean-quick 56 iget-byte - - F0 iget-byte-quick 57 iget-char - - F1 iget-char-quick 58 iget-short - - F2 iget-short-quick

According to the mapping rules shown in Table 1, the hexadecimal operation code is converted to an optimized operation code. As shown in Table 1, in various embodiments, the mapping rule for converting a hexadecimal operation code to an optimized operation code may differ depending on the Android version of the application user's electronic device. According to various embodiments, a first optimized DEX file 430a corresponding to an application for an electronic device using Android version 5 and a first optimized DEX file 430a corresponding to an application for an electronic device using Android version 6, 7, or 8. 1 The optimized DEX file 430a may be different.

The developer electronic device may check the first verification target code area 440a from the first optimized DEX file 430a. According to various embodiments, the process of confirming the first code area to be verified (440a) from the first optimized DEX file (430a) may be performed by the DEX subject to verification code area extractor (326a). According to various embodiments, the developer electronic device extracts operation codes and registers from the first optimized DEX file 430a, parses the extracted operation codes and registers in function units or code area units, and divides them into a plurality of first parts. After dividing, at least one of the plurality of first parts can be confirmed as the first code area to be verified.

The developer electronic device may generate the first signature 450a based on the first verification target code area 440a. According to various embodiments, the process of generating the first signature 450a based on the first verification target code region 440a may be performed by the DEX signature generator 322a. According to various embodiments, a developer electronic device may generate a first signature by applying a hash function to the first verification target code area 440a. According to various embodiments, there is no limitation on the specific type of hash function.

The developer electronic device may store the generated first signature 450a in the signature database 460a. According to various embodiments, the process of storing the first signature 450a in the signature database 460a may be performed by the signature storage unit 324a.

According to various embodiments, the signature database 460a may be included in the installation file of the application along with the application package 410a. In this case, the signature database 460a is included in the installation file of the application and is received by the user's electronic device (eg, by the processor 120 through the communication module 190). Alternatively, according to various embodiments, the signature database 460a may be included in an external server that communicates with the developer's electronic device and the user's electronic device, respectively. According to various embodiments, the signature database 460a may be included in an application server that provides applications to the user's electronic device. According to various embodiments, the developer's electronic device and the user's electronic device may access the signature database 460a through a cloud service or network service.

As described above with respect to Table 1, according to various embodiments, a first optimized DEX file 430a corresponding to an application for an electronic device using Android version 5 and Android version 6, 7, or 8 is used. The first optimized DEX file 430a corresponding to the application for the electronic device may be different. Accordingly, the first signature 450a corresponding to an electronic device using Android version 5 and the application and the first signature 450a corresponding to an electronic device using Android version 6, 7, or 8 may be different. According to various embodiments, when the signature database 460a is included in an external server that communicates with the developer's electronic device and the user's electronic device, respectively, the signature storage unit 324a is a device corresponding to an electronic device using Android version 5. 1 signature 450a and the first signature 450a corresponding to an electronic device using Android version 6, 7, or 8 may be separately stored in the signature database 460a. According to various embodiments, when the signature database 460a is included in the installation file of the application together with the application package 410a, the first signature 450a is included in the application installation file for the electronic device using the corresponding Android version. May be included.

FIG. 4B illustrates a diagram illustrating an application integrity verification process 400b according to various embodiments. According to various embodiments, the application integrity verification process 400b may be performed in response to an application execution command being confirmed in the electronic device 101 (eg, processor 120) on which the application is installed. According to various embodiments, the application integrity verification process 400b may be performed by the electronic device 101 (hereinafter, “user electronic device”) on which the application is installed.

The user electronic device 101 may extract the second optimized DEX file 430b from the application cache file 470b. According to various embodiments, the process of extracting the second optimized DEX file 430b from the application cache file 470b may be performed by the cache verification target code area extractor 327b. According to various embodiments, the application cache file 470b may be an ODEX file or a VDEX file.

The user electronic device 101 may check the second verification target code area 440b from the second optimized DEX file 430b. According to various embodiments, the process of confirming the second code area to be verified (440b) from the second optimized DEX file (430b) may be performed by the cache subject code area to be verified (327b). According to various embodiments, the user electronic device 101 extracts operation codes and registers from the second optimized DEX file, parses the extracted operation codes and registers in function units or code area units, and divides them into a plurality of second parts. After dividing, at least one of the plurality of second parts can be confirmed as the second verification target code area 440b.

The user electronic device 101 may generate the second signature 455b based on the second verification target code area 440b. According to various embodiments, the process of generating the second signature 455b based on the second code region to be verified 440b may be performed by the cache signature generator 325b. According to various embodiments, the user electronic device 101 may generate a second signature by applying a hash function to the second verification target code area 440b. According to various embodiments, the hash function may be the same as the hash function applied to the first verification target code region 440a to generate the first signature 450a, and there is no limitation on the specific type of the hash function.

The user electronic device 101 may check the first signature 450b stored in the signature database 460b. According to various embodiments, the process of checking the first signature 450b stored in the signature database 460b may be performed by the signature extractor 323b. According to various embodiments, the first signature 450b stored in the signature database 460b may be generated through the process 400a for generating the first signature 450a, which is described with reference to FIG. 4A.

The user electronic device 101 may compare the first signature 450b stored in the signature database 460b with the second signature 455b generated by the application cache file 470b. According to various embodiments, a process of comparing the first signature 450b and the second signature 455b may be performed by the comparison unit 321b. According to various embodiments, the user electronic device 101 may check the integrity of the application based on whether the first signature 450b and the second signature 455b are the same. A specific operation to check the integrity of the application based on whether the first signature 450b and the second signature 455b are the same will be described later with reference to FIGS. 8, 9a, and 9b.

FIG. 5 illustrates a diagram for explaining the operation of an electronic device according to various embodiments. The electronic device 502 (eg, processor 120) may receive (510) the installation file of the application from the application server 501. According to various embodiments, the installation file of an application may include an application package.

The electronic device 502 may check the first signature (520) by referring to the signature database 503. According to various embodiments, the signature database 503 may be included in an installation file of an application received from the application server 501. When the signature database 503 is included in the installation file of the application received from the application server 501, the electronic device 502 (e.g., processor 120) generates the first signature based on the installation file of the application. You can check (520). According to various embodiments, the signature database 503 may be included in an external server separate from the electronic device 502 or the application server 501. According to various embodiments, the signature database 503 may be included in the application server 501. When the signature database 503 is included in an external server separate from the electronic device 502 or the application server 501, or when the signature database 503 is included in the application server 501, the electronic device 502 communicates The first signature may be confirmed (520) by receiving the first signature from the signature database 503 through a module (eg, communication module 190).

The electronic device 502 may check the application execution command (530). According to various embodiments, the electronic device 502 (e.g., the processor 120) executes an application execution command through at least one of the input device 150, the touch circuit within the display device 160, or the interface 177. You can confirm that this has been entered.

The electronic device 502 may confirm the second signature (540) in response to the application execution command being confirmed (530). Details of the process of verifying the second signature (540) have been described in detail with reference to FIG. 4B, and will not be repeated here.

The electronic device 502 may check (550) whether the application has integrity based on whether the second signature is the same as the first signature. Details of the operation of checking (550) whether the application has integrity based on whether the second signature is the same as the first signature will be described later with reference to FIGS. 8, 9A, and 9B.

Although the process of confirming the first signature (520) is shown in FIG. 5 as being performed before the application execution command confirmation (530), according to various embodiments, the point in time when the process of confirming the first signature (520) occurs is There is no limit as long as it is before checking whether the 2 signature is the same as the first signature. For example, the electronic device 502 may check the second signature (540) and then check the first signature (520) in response to the application execution command confirmation (530).

Figure 6 shows a flowchart for explaining the operation of an electronic device according to various embodiments. According to various embodiments, operation 600 shown in FIG. 6 may be performed by a processor (eg, processor 120) included in an electronic device (eg, electronic device 101).

In operation 610, a processor (eg, processor 120) included in an electronic device (eg, electronic device 101) may receive an installation file for an application including an application package and a signature database. According to various embodiments, the signature database may include a first signature corresponding to at least some of the application packages. According to various embodiments, the first signature may be confirmed based on the first verification target code region confirmed based on the DEX file corresponding to the application package. According to various embodiments, the first verification target code region extracts operation codes and registers from the first optimized DEX file generated by parsing the DEX file corresponding to the application package and applying mapping rules, and extracts the extracted operation code. And it may be at least a part of a plurality of first parts that are confirmed by parsing the register in function units or code area units. According to various embodiments, the first signature may be generated by applying a hash function to the first verification target code region.

In operation 620, the processor 120 may check the second signature in response to an execution command of the application. According to various embodiments, the processor 120 may confirm the second signature based on the second verification target code region confirmed based on the ODEX file of the application in response to the execution command of the application. According to various embodiments, the processor 120 extracts a second optimized DEX file from the ODEX file of the application, extracts operation codes and registers from the second optimized DEX file, and converts the extracted operation codes and registers into function units. Alternatively, at least some of the plurality of second parts confirmed by parsing in units of code areas can be confirmed as the second code area to be verified. According to various embodiments, the second optimized DEX file may be extracted from the application's ODEX file. According to various embodiments, the processor 120 may verify the second signature by applying a hash function to the second verification target code region to generate the second signature.

In operation 630, the processor 120 may check the first signature from the signature database. Although operation 630 is shown in FIG. 6 as being performed after operation 620, according to various embodiments, operation 630 is any other operation before the operation of checking whether the second signature is the same as the first signature is performed. It may be performed at any time. For example, operation 630 may be performed after the execution command of the application is confirmed but before checking the second signature.

In operation 640, the processor 120 may check whether the application has integrity based on whether the second signature is the same as the first signature. Details of the process of checking the integrity of the application will be described later with reference to FIGS. 7 and 8.

Figure 7 shows a flowchart for explaining the operation of an electronic device according to various embodiments. Specifically, operation 700 shown in FIG. 7 illustrates operations of an electronic device for verifying a second signature. According to various embodiments, operation 700 shown in FIG. 7 may be performed by a processor (eg, processor 120) included in an electronic device (eg, electronic device 101).

In operation 710, a processor (eg, processor 120) included in the electronic device (eg, electronic device 101) may extract the second optimized DEX file from the ODEX file of the application. According to various embodiments, the application cache file 470b may be an ODEX file or a VDEX file.

In operation 720, processor 120 may extract operation codes and registers from the second optimized DEX file.

At operation 730, processor 120 may parse the operation code and registers into a plurality of second parts. For example, the processor 120 may parse operation codes and registers in function units. According to various embodiments, the processor 120 may parse operation codes and registers on a code region basis.

In operation 740, the processor 120 may identify at least some of the plurality of second parts as the second verification target code region.

In operation 750, the processor 120 may verify the second signature by applying a hash function to the second verification target code region.

Figure 8 shows a flowchart for explaining the operation of an electronic device according to various embodiments. Specifically, operation 800 shown in FIG. 8 illustrates an operation for verifying the integrity of an application based on whether the first signature and the second signature are the same. According to various embodiments, operation 800 shown in FIG. 8 may be performed by a processor (e.g., processor 120) included in an electronic device (e.g., electronic device 101) on which the application is installed. You can.

In operation 810, the processor 120 may check whether the second signature is the same as the first signature. According to various embodiments, the second signature may be generated based on the ODEX file of the application. According to various embodiments, the second signature may be generated based on the VDEX file of the application. Other details of the process of generating the second signature and the first signature have been described in detail with reference to FIGS. 4A and 4B and will not be repeated here.

If the second signature is confirmed to be the same as the first signature, in operation 820, the processor 120 may confirm that the application has integrity. If it is determined that the second signature is not the same as the first signature, in operation 830, the processor 120 may confirm that there is no integrity of the application.

FIGS. 9A and 9B show flowcharts for explaining the operation of an electronic device according to various embodiments. Specifically, operation 900 shown in FIGS. 9A and 9B illustrates an operation for verifying the integrity of an application based on whether the first signature and the second signature are the same. According to various embodiments, the operation 900 shown in FIGS. 9A and 9B is performed on a processor (e.g., processor 120) included in an electronic device (e.g., electronic device 101) on which an application is installed. It can be performed by:

In operation 910, the processor 120 may check the execution command of the application. At operation 920, processor 120 may attempt to extract a second optimized DEX file from the application's ODEX file. According to various embodiments, when the operating system of the electronic device 101 is Android version 8 or lower, the optimized DEX is included in the ODEX file of the application, so the processor 120 generates the second optimized DEX based on the ODEX file of the application. You can extract files. Alternatively, according to various embodiments, when the operating system of the electronic device 101 is Android version 8 or higher, the optimized DEX is included in the VDEX file of the application rather than the ODEX file of the application, so the processor 120 stores the ODEX file of the application. Based on this, extracting the second optimized DEX file may fail.

In operation 930, the processor 120 may check whether the second optimized DEX file is extracted from the ODEX file of the application. As described above with reference to operation 920, depending on various embodiments, whether the optimized DEX is included in the application's ODEX file or the application's VDEX file, or depending on the version of the operating system of the electronic device 101. Therefore, whether the second optimized DEX file is extracted from the ODEX file of the application may differ.

If it is determined that the second optimized DEX file is extracted from the application's ODEX file, in operation 931, processor 120 may verify the second signature based on the second optimized DEX file extracted from the application's ODEX file. there is. The details of the process of confirming the second signature based on the second optimized DEX file are the same as described above with reference to FIG. 4B, and will not be described herein.

In operation 940, the processor 120 may check whether the second signature generated based on the second optimized DEX file extracted from the ODEX file of the application is the same as the first signature confirmed by referring to the signature database. Details regarding the first signature have been described above with reference to FIG. 4A and will not be repeated here.

If the second signature generated based on the ODEX file of the application is confirmed to be identical to the first signature, in operation 941, the processor 120 may confirm that the application has integrity. If it is determined that the second signature generated based on the ODEX file of the application is not the same as the first signature, in operation 942, the processor 120 may confirm that the application does not have integrity.

If it is determined that the second optimized DEX file is not extracted from the application's ODEX file, at operation 932, processor 120 may extract the third optimized DEX file from the application's VDEX file. At operation 950, processor 120 may verify the third signature based on the third optimized DEX file. Since the details of the process of checking the second signature from the application cache file, described with reference to FIG. 4B, can be equally applied to operations 932 and 950, they will not be repeatedly described here.

In operation 960, the processor 120 may check whether the third signature is the same as the first signature. If the third signature is confirmed to be the same as the first signature, in operation 961, the processor 120 may confirm that the application has integrity. If it is determined that the third signature is not the same as the first signature, in operation 962, the processor 120 may confirm that there is no integrity of the application.

Figure 10 shows a flowchart for explaining the operation of an electronic device according to various embodiments. According to various embodiments, operation 1000 shown in FIG. 10 may be performed by a processor (eg, processor 120) included in an electronic device (eg, electronic device 101).

In operation 1010, a processor (eg, processor 120) included in an electronic device (eg, electronic device 101) may receive an installation file of an application including an application package.

In operation 1020, processor 120 may receive a first signature from a signature database. According to various embodiments, operation 1020 may be performed in response to an execution command of the application corresponding to the application installation file received in operation 1010. According to various embodiments, the processor 120 may receive the first signature from the signature database through the communication module 190. According to various embodiments, the signature database may be included in a server external to the electronic device 101. According to various embodiments, the signature database may be included in the application server that provides the installation file of the application to the processor 120 in operation 1010.

In operation 1030, the processor 120 may check the second signature in response to an execution command of the application. The verification process of the second signature has been described in detail with reference to FIG. 4B and will not be repeated here.

In operation 1040, the processor 120 may check whether the application has integrity based on whether the second signature is the same as the first signature. Details of the process of checking the integrity of the application have been described in detail with reference to FIGS. 7 and 8 and will not be repeated here.

According to various embodiments, the electronic device 101 includes a communication module 190; and a processor 120, wherein the processor 120 includes an application package and a signature database 460a, 460b including first signatures 450a, 450b corresponding to at least some of the application packages. The installation file of the application is received through the communication module 190, and the first signatures 450a and 450b are a first verification target code region confirmed based on the DEX file 420a corresponding to the application package ( Verified based on 450a) - Verifies the first signature (450a, 450b) from the signature database (460a, 460b), and in response to an execution command of the application, based on the ODEX file (470b) of the application Check the second signature (455b) based on the second verification target code region (440b), and the application based on whether the second signature (455b) is the same as the first signature (450a, 450b) It can be set to check the presence or absence of integrity.

According to various embodiments, the first verification target code region 450a is at least a portion of the operation code and register extracted from the first optimized DEX file 430a generated by applying a mapping rule to the DEX file 420a. You can.

According to various embodiments, the first verification target code area 450a is a plurality of first verification target code areas 450a that are confirmed by parsing the operation code and register extracted from the first optimized DEX file 430a on a function basis or a code area basis. It may be at least some of the parts.

According to various embodiments, the second code area to be verified (440b) may be at least a portion of the operation code and registers extracted from the second optimized DEX file (430b) extracted from the ODEX file (470b) of the application.

According to various embodiments, the second code area to be verified (440b) is a plurality of second code areas that are confirmed by parsing the operation code and register extracted from the second optimized DEX file (430b) on a function basis or a code area basis. It may be at least some of the parts.

According to various embodiments, the first signatures 450a and 450b are generated by applying a hash function to the first code region to be verified (450a), and the second signature (455b) is generated by applying a hash function to the code region to be verified (450a). It can be generated by applying a hash function to (440b).

According to various embodiments, the processor 120 determines that the application has integrity based on confirmation that the second signature 455b is the same as the first signatures 450a and 450b, and Based on confirmation that the second signature 455b is not the same as the first signatures 450a and 450b, it can be set to confirm that there is no integrity of the application.

According to various embodiments, the processor 120, based on determining that the second optimized DEX file 430b cannot be extracted from the application's ODEX file: extracts the third optimized DEX file 430b from the application's VDEX file. Extract the DEX file; extracting a third verification target code region from the third optimized DEX file; verifying a third signature based on the third code region to be verified; Check whether the third signature is the same as the first signature (450a, 450b); Confirm that there is integrity of the application based on the third signature being confirmed to be the same as the first signature (450a, 450b); Based on confirmation that the third signature is not the same as the first signatures 450a and 450b, it can be configured to confirm that there is no integrity of the application.

According to various embodiments, the electronic device 101 includes a communication module 190; and a processor 120, wherein the processor 120: receives an installation file of an application including an application package through the communication module 190, and creates a first signature corresponding to at least a portion of the application package ( Receive the first signatures 450a, 450b from the signature databases 460a, 460b including 450a, 450b through the communication module 190 - the first signatures 450a, 450b are stored in the application Verified based on the first verification target code region 450a, verified based on the DEX file corresponding to the package -, In response to an execution command of the application, a second verification target verified based on the ODEX file of the application verify the second signature 455b based on the code region 440b; The second signature 455b may be set to check the integrity of the application based on whether it is the same as the first signatures 450a and 450b.

According to various embodiments, the installation file of the application may be received from the application server to the electronic device 101, and the signature databases 460a and 460b may be associated with the application server.

According to various embodiments, a method for verifying the integrity of an application includes: an application package, and a signature database 460a, 460b including first signatures 450a, 450b corresponding to at least some of the application packages. An operation of receiving an installation file - the first signatures 450a and 450b are confirmed based on a first verification target code region 450a, which is confirmed based on a DEX file corresponding to the application package; Verifying the first signature (450a, 450b) from the signature database (460a, 460b); In response to an execution command of the application, verifying a second signature (455b) based on a second code region to be verified (440b) confirmed based on the ODEX file of the application; It may include an operation of checking the integrity of the application based on whether the second signature (455b) is the same as the first signature (450a, 450b).

According to various embodiments, the first verification target code area 450a may be at least a portion of the operation code and register extracted from the first optimized DEX file 430a generated by applying a mapping rule to the DEX file.

According to various embodiments, the first verification target code area 450a is a plurality of first verification target code areas 450a that are confirmed by parsing the operation code and register extracted from the first optimized DEX file 430a on a function basis or a code area basis. It may be at least some of the parts.

According to various embodiments, the operation of checking the second signature 455b includes at least a portion of the operation code and registers extracted from the second optimized DEX file 430b extracted from the ODEX file of the application. 2 It may include a verification operation as the verification target code area 440b.

According to various embodiments, the second code area to be verified (440b) is a plurality of second code areas that are confirmed by parsing the operation code and register extracted from the second optimized DEX file (430b) on a function basis or a code area basis. It may be at least some of the parts.

According to various embodiments, the first signatures 450a and 450b are generated by applying a hash function to the first verification target code region 450a, and the operation of verifying the second signature 455b includes the first verification target code region 450a. 2 An operation of applying a hash function to the verification target code area 440b may be included.

According to various embodiments, according to claim 1, the operation of checking the integrity of the application is based on confirming that the second signature (455b) is the same as the first signature (450a, 450b), Confirming that there is integrity of the application, and based on confirming that the second signature (455b) is not the same as the first signatures (450a, 450b), confirming that there is no integrity of the application. there is.

According to various embodiments, the method may include, based on determining that the second optimized DEX file 430b cannot be extracted from the application's ODEX file: extracting a third optimized DEX file from the application's VDEX file; The action of extracting; Extracting a third verification target code region from the third optimized DEX file; Verifying a third signature based on the third code region to be verified; Checking whether the third signature is the same as the first signature (450a, 450b); Confirming that integrity verification of the application is successful based on confirmation that the third signature is identical to the first signature (450a, 450b); Based on confirmation that the third signature is not the same as the first signatures 450a and 450b, the method may further include confirming that integrity verification of the application has failed.

According to various embodiments, a method for verifying the integrity of an application includes: receiving an installation file of the application including an application package; An operation of receiving the first signatures (450a, 450b) from a signature database (460a, 460b) containing the first signatures (450a, 450b) corresponding to at least some of the application packages - the first signatures (450a, 450b) ) is confirmed based on the first verification target code region 450a, which is confirmed based on the DEX file corresponding to the application package -; In response to an execution command of the application, verifying a second signature (455b) based on a second code region to be verified (440b) confirmed based on the ODEX file of the application; It may include an operation of checking the integrity of the application based on whether the second signature (455b) is the same as the first signature (450a, 450b).

According to various embodiments, the installation file of the application may be received from the application server to the electronic device 101, and the signature databases 460a and 460b may be associated with the application server.

Electronic devices according to various embodiments disclosed in this document may be of various types. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to embodiments of this document are not limited to the above-described devices.

The various embodiments of this document and the terms used herein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various changes, equivalents, or replacements of the embodiments. In connection with the description of the drawings, similar reference numbers may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the above items, unless the relevant context clearly indicates otherwise. In this document, “A or B,” “at least one of A and B,” “at least one of A or B,” “A, B, or C,” “at least one of A, B, and C,” and “A. Each of phrases such as “at least one of , B, or C” may include any one of the items listed together in the corresponding phrase, or any possible combination thereof. Terms such as "first", "second", or "first" or "second" may be used simply to distinguish one component from another, and to refer to those components in other respects (e.g., importance or order) is not limited. One (e.g., first) component is said to be “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicatively.” Where mentioned, it means that any of the components can be connected to the other components directly (e.g. wired), wirelessly, or through a third component.

The term “module” used in this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example. A module may be an integrated part or a minimum unit of the parts or a part thereof that performs one or more functions. For example, according to one embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of the present document are one or more instructions stored in a storage medium (e.g., built-in memory 136 or external memory 138) that can be read by a machine (e.g., electronic device 101). It may be implemented as software (e.g., program 140) including these. For example, a processor (e.g., processor 120) of a device (e.g., electronic device 101) may call at least one command among one or more commands stored from a storage medium and execute it. This allows the device to be operated to perform at least one function according to the at least one instruction called. The one or more instructions may include code generated by a compiler or code that can be executed by an interpreter. Device-readable storage media may be provided in the form of non-transitory storage media. Here, 'non-transitory' only means that the storage medium is a tangible device and does not contain signals (e.g. electromagnetic waves). This term refers to cases where data is stored semi-permanently in the storage medium. There is no distinction between temporary storage cases.

According to one embodiment, methods according to various embodiments disclosed in this document may be included and provided in a computer program product. Computer program products are commodities and can be traded between sellers and buyers. The computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or via an application store (e.g. Play Store ^TM ) or on two user devices (e.g. It can be distributed (e.g. downloaded or uploaded) directly between smartphones) or online. In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

According to various embodiments, each component (eg, module or program) of the above-described components may include a single entity or a plurality of entities. According to various embodiments, one or more of the components or operations described above may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (eg, modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each component of the plurality of components identically or similarly to those performed by the corresponding component of the plurality of components prior to the integration. . According to various embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, or omitted. Alternatively, one or more other operations may be added.

Claims (20)

In electronic devices,
communication module; and
Includes a processor,
The processor,
Receive, through the communication module, an installation file of an application including an application package and a signature database including a first signature corresponding to at least a portion of the application package, wherein the first signature is a DEX corresponding to the application package. Verified based on the first verification target code region verified based on the file -,
Confirming the first signature from the signature database,
In response to an execution command of the application, confirming a second signature based on a second verification target code region confirmed based on the ODEX file of the application,
is set to check the integrity of the application based on whether the second signature is the same as the first signature,
The first verification target code area is one of a plurality of first parts confirmed by parsing the operation code and register extracted from the first optimized DEX file generated by applying the mapping rule to the DEX file on a function basis or a code area basis. At least some,
The second verification target code area is at least a part of a plurality of second parts confirmed by parsing the operation code and registers extracted from the second optimized DEX file extracted from the ODEX file of the application on a function basis or a code area basis. ,
The processor,
Based on determining that the second optimized DEX file cannot be extracted from the application's ODEX file:
extract a third optimized DEX file from the VDEX file of the application;
extracting a third verification target code region from the third optimized DEX file;
verifying a third signature based on the third code region to be verified;
check whether the third signature is the same as the first signature;
based on confirming that the third signature is identical to the first signature, confirming that there is integrity of the application;
The electronic device is configured to confirm that there is no integrity of the application based on confirming that the third signature is not the same as the first signature. delete delete delete delete According to paragraph 1,
The first signature is generated by applying a hash function to the first verification target code region,
The second signature is generated by applying a hash function to the second verification target code region. The method of claim 1, wherein the processor:
Based on confirmation that the second signature is identical to the first signature, confirm that the application has integrity,
The electronic device is configured to confirm that there is no integrity of the application based on confirming that the second signature is not the same as the first signature. delete In electronic devices,
communication module; and
Includes a processor,
The processor:
Receiving the installation file of the application including the application package from the application server through the communication module,
Receive the first signature through the communication module from a signature database including a first signature corresponding to at least some of the application packages, and confirm the first signature based on a DEX file corresponding to the application package. is confirmed based on the first verification target code area, and the signature database is an external server separate from the application server.
In response to an execution command of the application, confirming a second signature based on a second verification target code region confirmed based on the ODEX file of the application;
is set to check the integrity of the application based on whether the second signature is the same as the first signature,
The first verification target code area is one of a plurality of first parts confirmed by parsing the operation code and register extracted from the first optimized DEX file generated by applying the mapping rule to the DEX file on a function basis or a code area basis. At least some,
The second verification target code area is at least a part of a plurality of second parts confirmed by parsing the operation code and registers extracted from the second optimized DEX file extracted from the ODEX file of the application on a function basis or a code area basis. ,
The processor,
Based on determining that the second optimized DEX file cannot be extracted from the application's ODEX file:
extract a third optimized DEX file from the VDEX file of the application;
extracting a third verification target code region from the third optimized DEX file;
verifying a third signature based on the third code region to be verified;
check whether the third signature is the same as the first signature;
based on confirming that the third signature is identical to the first signature, confirming that there is integrity of the application;
The electronic device is configured to confirm that there is no integrity of the application based on confirming that the third signature is not the same as the first signature. delete In a method of verifying the integrity of an application performed on an electronic device:
Receiving an installation file of the application including an application package and a signature database including a first signature corresponding to at least a portion of the application package, wherein the first signature is based on a DEX file corresponding to the application package. Confirmed based on the first verification target code area confirmed by -;
Verifying the first signature from the signature database;
In response to an execution command of the application, verifying a second signature based on a second code region to be verified that is verified based on an ODEX file of the application; and
Including the operation of confirming the integrity of the application based on whether the second signature is the same as the first signature,
The first verification target code area is one of a plurality of first parts confirmed by parsing the operation code and registers extracted from the first optimized DEX file generated by applying the mapping rule to the DEX file on a function basis or a code area basis. At least some,
The second verification target code area is at least a part of a plurality of second parts confirmed by parsing the operation code and registers extracted from the second optimized DEX file extracted from the ODEX file of the application on a function basis or a code area basis. ,
Based on determining that the second optimized DEX file cannot be extracted from the application's ODEX file:
Extracting a third optimized DEX file from the VDEX file of the application;
Extracting a third verification target code region from the third optimized DEX file;
Verifying a third signature based on the third code region to be verified;
Checking whether the third signature is the same as the first signature;
Confirming that the application has integrity based on confirmation that the third signature is identical to the first signature; and
The method further includes confirming that there is no integrity of the application based on confirming that the third signature is not the same as the first signature. delete delete delete delete According to clause 11,
The first signature is generated by applying a hash function to the first verification target code region,
The operation of verifying the second signature includes applying a hash function to the second verification target code region. The method of claim 11, wherein the operation of checking the integrity of the application includes:
An operation to confirm that there is integrity of the application based on confirmation that the second signature is the same as the first signature, and
and confirming that there is no integrity of the application based on confirming that the second signature is not the same as the first signature. delete In a method of verifying the integrity of an application performed on an electronic device:
Receiving an installation file of the application including an application package from an application server;
An operation of receiving the first signature from a signature database including a first signature corresponding to at least some of the application packages, wherein the first signature is a first verification target confirmed based on a DEX file corresponding to the application package. verified based on code region, and the signature database is an external server separate from the application server;
In response to an execution command of the application, verifying a second signature based on a second code region to be verified that is verified based on an ODEX file of the application; and
Including the operation of confirming the integrity of the application based on whether the second signature is the same as the first signature,
The first verification target code area is one of a plurality of first parts confirmed by parsing the operation code and registers extracted from the first optimized DEX file generated by applying the mapping rule to the DEX file on a function basis or a code area basis. At least some,
The second verification target code area is at least a part of a plurality of second parts confirmed by parsing the operation code and registers extracted from the second optimized DEX file extracted from the ODEX file of the application on a function basis or a code area basis. ,
Based on determining that the second optimized DEX file cannot be extracted from the application's ODEX file:
Extracting a third optimized DEX file from the VDEX file of the application;
Extracting a third verification target code region from the third optimized DEX file;
Verifying a third signature based on the third code region to be verified;
Checking whether the third signature is the same as the first signature;
Confirming that the application has integrity based on confirmation that the third signature is identical to the first signature; and
The method further includes confirming that there is no integrity of the application based on confirming that the third signature is not the same as the first signature.



delete

Images