+

WO2018194196A1 - Procédé et système de détection d'application d'obfuscation et d'évaluation de la sécurité d'un fichier elf - Google Patents

Procédé et système de détection d'application d'obfuscation et d'évaluation de la sécurité d'un fichier elf Download PDF

Info

Publication number
WO2018194196A1
WO2018194196A1 PCT/KR2017/004236 KR2017004236W WO2018194196A1 WO 2018194196 A1 WO2018194196 A1 WO 2018194196A1 KR 2017004236 W KR2017004236 W KR 2017004236W WO 2018194196 A1 WO2018194196 A1 WO 2018194196A1
Authority
WO
WIPO (PCT)
Prior art keywords
obfuscation
section
header
code
elf
Prior art date
Application number
PCT/KR2017/004236
Other languages
English (en)
Korean (ko)
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 PCT/KR2017/004236 priority Critical patent/WO2018194196A1/fr
Priority to JP2018080912A priority patent/JP7131946B2/ja
Priority to US15/958,115 priority patent/US10963563B2/en
Publication of WO2018194196A1 publication Critical patent/WO2018194196A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the following description relates to a method and system for detecting and evaluating the application of obfuscation of an ELF file and to a computer program stored in a computer readable recording medium in combination with a computer for executing the security evaluation method on a computer. .
  • the App store is an online content marketplace that sells various applications that can be mounted on a terminal such as a smartphone.
  • a terminal such as a smartphone.
  • the developer of an application registers a file (for example, an Android Application Package (Apk)) for installing a developed application on a terminal in an app store, and users of the application are required through the app store.
  • By downloading a file for the application it is possible to install and run the application on their terminal.
  • various game applications such as game publishers are distributed to users.
  • the first risk of an application is that the application contains information developed by malicious intentions, such as malicious code, to perform malicious functions on the terminal of the application publisher or the user on which the application is installed and run.
  • Korean Patent Laid-Open No. 10-2014-0098025 relates to a system and method for security evaluation of an application uploaded to an app store, and when an application to be registered in an app store detects a malicious function, the application Disclosed is a technique for rejecting entry into an app store.
  • the second risk of an application is the risk to the security of the application itself.
  • the application performs a function other than the function originally intended by the developer, thereby reducing the reliability of the service to be provided through the application. This exists. Therefore, there is a need for application publishers to provide a certain level of security for applications in distributing various applications (installation files of applications) that they did not develop directly.
  • each application may be equipped with security solutions of different security levels and may not include any security measures.
  • security solutions of different security levels and may not include any security measures.
  • security levels provided by the security solutions mounted in each application.
  • Java-level vulnerability check can be performed at the programming language level (for example, Android Application Package (Apk)), and from the application publisher's point of view, each of the numerous registered applications There is a problem that it is difficult to provide security that is maintained above a certain level.
  • programming language level for example, Android Application Package (Apk)
  • the level of security applied to the registered application is analyzed and identified in an objective manner in terms of obfuscation, vulnerability, and / or security solution, and the analyzed information is provided to provide security for the application. It provides a method and system for evaluating security that can be used to improve gender.
  • a method of evaluating security of an application comprising: registering a package file for installing and running an application; Identifying an executable and linkable format (ELF) file included in the registered package file; Determining whether to apply obfuscation to at least one of an ELF header, a section header, a section, and a segment included in the ELF file; And determining a security grade of the ELF file based on whether the obfuscation is applied.
  • ELF executable and linkable format
  • a computer program for recording a computer program for executing the security evaluation method is provided.
  • a computer program stored in a computer readable recording medium for executing the security evaluation method in a computer in combination with a computer is provided.
  • a system for evaluating the security of an application comprising: at least one processor implemented to execute computer readable instructions, the at least one processor registering a package file for installation and running of the application, Identify an executable and linkable format (ELF) file included in a registered package file, determine whether to apply obfuscation to at least one of an ELF header, a section header, a section, and a segment included in the ELF file.
  • ELF executable and linkable format
  • the level of security applied to the registered application is analyzed and identified in an objective manner in terms of obfuscation, vulnerability, and / or security solution, and the analyzed information is provided to provide security for the application. Can be used to improve sex.
  • FIG. 1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
  • FIG. 2 is a block diagram illustrating an internal configuration of an electronic device and a server according to an embodiment of the present invention.
  • FIG. 3 is a block diagram of a security evaluation system according to an embodiment of the present invention.
  • 4 and 5 illustrate a first example of detecting obfuscation of a symbol in an ELF file included in a registered package file according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating a second example of detecting obfuscation of a symbol in an ELF file included in a registered package file according to one embodiment of the present invention.
  • FIG. 7 illustrates a third example of detecting obfuscation of a symbol in an ELF file included in a registered package file according to an embodiment of the present invention.
  • FIG. 8 illustrates an example of detecting obfuscation of an ELF header of an ELF file according to an embodiment of the present invention.
  • FIG. 9 is a diagram for one example of determining whether to apply obfuscation to a header of a section including executable code according to an embodiment of the present invention.
  • FIG. 10 illustrates an example of detecting obfuscation of a code according to an embodiment of the present invention.
  • FIG. 11 illustrates an example of code conformance according to an embodiment of the present invention.
  • FIG. 12 is a diagram for one example of determining whether to apply obfuscation to a code based on information on a branch position according to an embodiment of the present invention.
  • FIG. 13 is a diagram for one example of adding a dummy code to source code according to one embodiment of the present invention.
  • FIG. 14 is a block diagram illustrating an example of components that may be included in a processor of a server according to an embodiment of the present invention.
  • 15 is a flowchart illustrating an example of a security evaluation method that can be performed by a server according to an embodiment of the present invention.
  • 16 is a flowchart illustrating a method of determining whether obfuscation is applied to an ELF header according to an embodiment of the present invention.
  • 17 is a flowchart illustrating a method of determining whether obfuscation is applied to a header of a dynamic linking symbol table section (.dynsym section) according to an embodiment of the present invention.
  • FIG. 18 is a flowchart illustrating a method of determining whether obfuscation is applied to a header of a section including executable code according to an embodiment of the present invention.
  • 19 is a flowchart illustrating a method of determining whether obfuscation is applied to a dynamic linking symbol table section according to an embodiment of the present invention.
  • 20 is a flowchart illustrating a method of determining whether to apply obfuscation to a read-only section according to an embodiment of the present invention.
  • 21 is a flowchart illustrating a first example of a method of determining whether obfuscation is applied to a code according to an embodiment of the present invention.
  • 22 is a flowchart illustrating a second example of a method of determining whether obfuscation is applied to a code according to an embodiment of the present invention.
  • 23 is a flowchart illustrating a third example of a method of determining whether obfuscation is applied to a code according to an embodiment of the present invention.
  • 24 is a flowchart illustrating a method of analyzing an instruction to determine whether obfuscation is applied to a code according to an embodiment of the present invention.
  • the security evaluation system may be implemented through a server to be described later, and the security evaluation method according to the embodiments of the present invention may be performed through the server described above.
  • a computer program according to an embodiment of the present invention may be installed and run on a server, and the server may perform a security evaluation method according to an embodiment of the present invention under control of the driven computer program.
  • the computer program described above may be stored in a computer-readable recording medium in combination with a computer-implemented server to execute a security evaluation method on a computer.
  • FIG. 1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
  • the network environment of FIG. 1 illustrates an example including a plurality of electronic devices 110, 120, 130, and 140, a plurality of servers 150 and 160, and a network 170.
  • 1 is an example for describing the present invention, and the number of electronic devices or the number of servers is not limited as shown in FIG. 1.
  • the plurality of electronic devices 110, 120, 130, and 140 may be fixed terminals or mobile terminals implemented as computer devices.
  • Examples of the plurality of electronic devices 110, 120, 130, and 140 include a smart phone, a mobile phone, a navigation device, a computer, a notebook computer, a digital broadcasting terminal, a personal digital assistant (PDA), and a portable multimedia player (PMP). Tablet PC).
  • FIG. 1 illustrates the shape of a smart phone as an example of the electronic device 1 110, in the embodiments of the present invention, the electronic device 1 110 may use a wireless or wired communication method to substantially connect the network 170. It may mean one of various physical devices that can communicate with other electronic devices 120, 130, 140 and / or servers 150, 160.
  • the communication method is not limited, and may include not only a communication method using a communication network (for example, a mobile communication network, a wired internet, a wireless internet, a broadcasting network) that the network 170 may include, but also a short range wireless communication between devices.
  • the network 170 may include a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), and a broadband network (BBN). And one or more of networks such as the Internet.
  • the network 170 may also include any one or more of network topologies, including bus networks, star networks, ring networks, mesh networks, star-bus networks, trees, or hierarchical networks, but It is not limited.
  • Each of the servers 150 and 160 communicates with the plurality of electronic devices 110, 120, 130, and 140 through the network 170 to provide a command, code, file, content, service, or the like. It may be implemented in devices.
  • the server 150 may be a system that provides a first service to a plurality of electronic devices 110, 120, 130, and 140 connected through the network 170, and the server 160 may also have a network ( It may be a system that provides a second service to the plurality of electronic devices 110, 120, 130, and 140 connected through the 170.
  • the server 150 may be at least some of the devices constituting the system of the application publisher, and receives a package file of an application installed and operated on the plurality of electronic devices 110, 120, 130, and 140.
  • the service to be distributed can be provided as the first service.
  • the server 160 may provide a service associated with the application as the second service to a plurality of electronic devices 110, 120, 130, and 140 that install and run the application through the distributed package file.
  • the server 150 may be implemented as a dedicated system for evaluating the security of a package file to be registered to provide information about the evaluated security for the package file to be registered.
  • 2 is a block diagram illustrating an internal configuration of an electronic device and a server according to an embodiment of the present invention. 2 illustrates an internal configuration of the electronic device 1 110 and the server 150 as an example of the electronic device. In addition, the other electronic devices 120, 130, 140, or the server 160 may also have the same or similar internal configuration as the aforementioned electronic device 1 110 or the server 150.
  • the electronic device 1 110 and the server 150 may include memories 211 and 221, processors 212 and 222, communication modules 213 and 223, and input / output interfaces 214 and 224.
  • the memories 211 and 221 may be computer-readable recording media, and may include a permanent mass storage device such as random access memory (RAM), read only memory (ROM), and a disk drive.
  • RAM random access memory
  • ROM read only memory
  • the non-volatile mass storage device such as a ROM and a disk drive may be included in the electronic device 1 110 or the server 150 as a separate permanent storage device that is separated from the memories 211 and 221.
  • the memory 211, 221 includes an operating system and at least one program code (for example, a browser installed and driven in the electronic device 1 110 or an application installed in the electronic device 1 110 to provide a specific service). Code) can be stored.
  • These software components may be loaded from a computer readable recording medium separate from the memories 211 and 221.
  • Such a separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, disk, tape, DVD / CD-ROM drive, memory card, and the like.
  • software components may be loaded into the memory 211, 221 through a communication module 213, 223 that is not a computer readable recording medium.
  • At least one program is a computer program that is installed by files provided by a file distribution system (for example, the server 160 described above) through the network 170 to distribute installation files of developers or applications. It may be loaded into the memories 211 and 221 based on (for example, the above-described application).
  • a file distribution system for example, the server 160 described above
  • the network 170 to distribute installation files of developers or applications. It may be loaded into the memories 211 and 221 based on (for example, the above-described application).
  • Processors 212 and 222 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input / output operations. Instructions may be provided to the processors 212, 222 by the memory 211, 221 or the communication modules 213, 223. For example, the processors 212 and 222 may be configured to execute a command received according to a program code stored in a recording device such as the memory 211 and 221.
  • the communication modules 213 and 223 may provide a function for the electronic device 1 110 and the server 150 to communicate with each other through the network 170, and the electronic device 1 110 and / or the server 150 may communicate with each other. May provide a function for communicating with another electronic device (eg, electronic device 2 120) or another server (eg, server 160). For example, a request generated by the processor 212 of the electronic device 1 110 according to a program code stored in a recording device such as the memory 211 may be controlled by the server 170 through the network 170 under the control of the communication module 213. 150).
  • control signals, commands, contents, files, and the like provided according to the control of the processor 222 of the server 150 are transmitted to the communication module of the electronic device 1 110 via the communication module 223 and the network 170 ( It may be received by the electronic device 1110 through 213.
  • the control signal, command, content, file, etc. of the server 150 received through the communication module 213 may be transmitted to the processor 212 or the memory 211, and the content, file, etc. may be transferred to the electronic device 1.
  • 110 may be stored as a storage medium (permanent storage described above) that may further include.
  • the input / output interface 214 may be a means for interfacing with the input / output device 215.
  • the input device may include a device such as a keyboard or a mouse, and the output device may include a device such as a display or a speaker.
  • the input / output interface 214 may be a means for interfacing with a device in which functions for input and output are integrated into one, such as a touch screen.
  • the input / output device 215 may be configured as one device with the electronic device 1110.
  • the input / output interface 224 of the server 150 may be a means for interfacing with an apparatus (not shown) for input or output that may be connected to or included in the server 150.
  • the processor 212 of the electronic device 1110 uses data provided by the server 150 or the electronic device 2 120 in processing a command of a computer program loaded in the memory 211.
  • the service screen or the content may be displayed on the display through the input / output interface 214.
  • the electronic device 1 110 and the server 150 may include more components than those of FIG. 2. However, it is not necessary to clearly show most of the prior art components.
  • the electronic device 1 110 may be implemented to include at least some of the above-described input / output devices 215 or other components such as a transceiver, a global positioning system (GPS) module, a camera, various sensors, a database, and the like. It may further include elements.
  • GPS global positioning system
  • an acceleration sensor when the electronic device 1 110 is a smartphone, an acceleration sensor, a gyro sensor, a camera module, various physical buttons, a button using a touch panel, an input / output port, and vibration for a smartphone generally include Various components such as a vibrator may be implemented to be further included in the electronic device 1 110.
  • FIG. 3 is a block diagram of a security evaluation system according to an embodiment of the present invention.
  • the security evaluation system 300 of FIG. 3 may be implemented through the server 150 described above.
  • the server 150 includes the package decomposition module 310, the file identification module 320, the parsing module 330, the analysis module 340, and the report module 350 included in the security evaluation system 300. May be representations of the different functions of the processor 222.
  • the package disassembly module 310 may be used as a function of the processor 222 in which the processor 222 of the server 150 disassembles a package file according to a control command included in a computer program.
  • the vulnerability detection module 342 included in the analysis module 340 may be implemented as a core module for vulnerability detection.
  • the server 150 may provide a service for distributing package files of applications registered by developers to users.
  • the package disassembly module 310 may disassemble the registered package files.
  • an Android application package (Apk) is a file format of a package file used for distributing software and middleware of Android, which is a mobile operating system, and has a '.apk' extension.
  • APK Android application package
  • embodiments of the present invention will be described based on a package file such as an APK, but it will be readily understood by those skilled in the art that the same or similar features may be applied to other kinds of package files through this description. .
  • the file identification module 320 may identify files included in the disassembled package file.
  • the extensions shown in Figure 3 ('dex', 'so', 'dll', 'json', 'ini', 'apk', 'xml', 'cert') as described previously, It will be readily understood by those skilled in the art.
  • the parsing module 330 may parse the identified files.
  • the parser 331 may parse files of a specific extension (eg, 'dex', 'so', 'dll') among the identified files, and the collector 332 may parse a specific extension (eg, You can collect the necessary information from the files of 'json', 'ini', 'apk', 'xml', and 'cert').
  • the parsing module 330 may identify each of the classes and methods included in the 'dex' file, and track a number of masses by instructing the instructions contained in the method. Can be identified by separating. The mass of instructions can be divided based on branch instructions such as the 'goto' statement, the 'switch' statement, or the 'if' statement.
  • the parsing module 330 may generate and manage information on call relationships between these instruction masses. For example, the call relations between the instruction masses may be managed in a tree structure, and the information on the call relations may include information on a method called by a specific instruction mass. The generation and management of such information may be processed for each of files included in a package file such as an APK file, and the parsing method may vary according to the characteristics of the file.
  • the parsed information and the collected information may be passed to the analysis module 340.
  • the analysis module 340 obfuscates a corresponding package file (or an application installed and driven in a user terminal such as the electronic device 1 110 through the package file) based on the information transmitted from the parsing module 330. It can generate and provide analysis information from an obfuscation point of view, a vulnerability point of view, and a security solution point of view.
  • the obfuscation detection module 341 may generate analysis information on the level of obfuscation applied to files of a specific extension (eg, 'dex', 'so', 'dll'). Can be. To this end, the obfuscation detection module 341 may determine whether obfuscation is applied for each preset item according to the type of file.
  • a specific extension eg, 'dex', 'so', 'dll'.
  • the vulnerability detection module 342 generates analysis information on whether there are any vulnerabilities in files of a specific extension (for example, 'dex', 'so', or 'config' which is a configuration file extension). can do.
  • the security evaluation system 300 may manage information about known vulnerabilities, and the vulnerability detection module 342 uses information about these vulnerabilities to determine which vulnerabilities exist in which files. Analyze information can be generated.
  • the platform detection module 343 may extract information about the platform on which the corresponding application is developed and / or the platform on which the corresponding application operates.
  • the security evaluation system 300 may use different analysis methods depending on which platform the application is developed on, for example, a development tool such as Unity or Cocos.
  • the security evaluation system 300 may use a different analysis method for each platform because the file format included in the package file may vary for each platform on which the application operates.
  • the security evaluation system 300 may extract information about the platform for the package file, and may analyze the package file or provide information about the extracted platform to the outside based on such information.
  • the security tool detection module 344 can detect the security solution that the developer of the package file has inserted into the package file. For example, a first security tool provided in a library form by a third party may be added to a corresponding package file by a developer. As another example, a second security tool developed by the developer may be added to the package file by the developer. In other words, the security tool detection module 344 may generate analysis information about whether the security tool is applied to the package file.
  • the relationship analysis module 345 may generate analysis information about a reference relationship between files included in the package file. For example, when the first file includes code for calling the second file, the analysis information may be generated such that the information about the reference relationship between the first file and the second file is included in the analysis information.
  • the report module 350 collects the analysis information generated by the analysis module 340 and provides a report for the person of the security evaluation system 300 (for example, an administrator of the server 150 or a security inspection team of an application publisher). Can be generated. Such a report may be provided to terminals of related parties using Hypertext Markup Language (HTML) or eXtensible Markup Language (XML) as in the example of FIG. 3.
  • HTML Hypertext Markup Language
  • XML eXtensible Markup Language
  • the Executable and Linkable Format (ELF), which will be described later, is a standard file format for executable files, object files, shared libraries, and core dumps.
  • Obfuscation for such ELF files can be broadly classified into header obfuscation and code obfuscation.
  • 4 and 5 illustrate a first example of detecting obfuscation of a symbol in an ELF file included in a registered package file according to an embodiment of the present invention.
  • FIG. 4 illustrates a section header table 410 included in an ELF file and a header 411 of a dynamic linking symbol table section (.dynsym section) included in the section header table 410.
  • 4 further shows a symbol entry table 420 of the dynamic linking symbol table section (.dynsym section) included in the ELF file, and the symbol entry table in the header 411 of the dynamic linking symbol table section. 420 is indicated.
  • the symbol entry table 420 may be a table listing names and addresses of an import function and an export function.
  • the section header table 410 defines information such as a name, a memory, a start address, a file offset, a size, a sorting method, and a presentation method for each section included in the ELF file.
  • the sections include a dynamic linking information section (.dynamic section), a read-only data section (.rodata section or a .rdata section), and a section (.init section or .init_array section) containing code to be used at process initialization. It contains various sections such as) and is well known.
  • information about a .dynsym section may be defined via the header of the .dynsym section in the section header table 410, where the header of the .dynsym section may contain at least some of these defined values (e.g., the .dynsym section You can point to the .dynsym section by its starting address, file offset and size).
  • FIG. 5 illustrates an example of obfuscating values defined in the header 411 of the dynamic linking symbol table section of FIG. 4, and replacing the defined values with nulls 510.
  • the header 411 of the dynamic linking symbol table section cannot point to the symbol entry table 420, so that the section header of the ELF file may be obfuscated.
  • the values defined in the header 411 of the dynamic linking symbol table section may be obfuscated by changing to null 510 or other information to obfuscate the symbols used in the ELF file.
  • the security evaluation system 300 may detect obfuscation of the section header by analyzing values defined in the header 411 of the dynamic linking symbol table section.
  • the security assessment system 300 may include a first condition in which the header 411 of the dynamic linking symbol table section includes a null 510, and the header 411 of the dynamic linking symbol table section is parsed. If the condition of any one of the second condition that is impossible and the information contained in the header 411 of the dynamic linking symbol table section is not present in the dynamic linking information section (.dynamic section) among the sections is satisfied, It can be determined that obfuscation is applied to the header.
  • the first condition may refer to a condition in which a value defined in the header 411 of the dynamic linking symbol table section is replaced with a null 510.
  • the header 411 of the dynamic linking symbol table section has a predefined structure, and there is an existing scheme for parsing the header 411 of the dynamic linking symbol table section according to the predefined structure.
  • the second condition may mean a condition in which the header 411 of the dynamic linking symbol table section is attempted to be parsed through such a conventional parsing scheme, and the header 411 of the dynamic linking symbol table section is not normally parsed. .
  • the security evaluation system 300 cannot parse the header 411 of the dynamic linking symbol table section, and thus the second condition is satisfied. can confirm.
  • the security evaluation system 300 checks whether the information included in the header 411 of the dynamic linking symbol table section exists in the dynamic linking information section (.dynamic section), and if it does not exist, It can be confirmed that the value included in the header 411 has been changed. In other words, the security evaluation system 300 may confirm that the third condition is satisfied.
  • the security evaluation system 300 may determine that obfuscation is applied to the header 411 of the dynamic linking symbol table section.
  • FIG. 6 is a diagram illustrating a second example of detecting obfuscation of a symbol in an ELF file included in a registered package file according to one embodiment of the present invention.
  • the name of the import function 610 and the name of the export function 620 are nulled. null) shows an example.
  • the security assessment system 300 finds the symbol entry table 420 pointed to by the header 411 of the dynamic linking symbol table section and analyzes the values of the import and export functions to analyze the dynamic linking symbol table section. It can be determined whether or not obfuscation is applied. For example, the security assessment system 300 may determine a section (dynamic linking) if the values of the import and export functions contain nulls or are not represented in American Standard Code for Information Interchange (ASCII) code. It can be determined that obfuscation is applied to the symbol table section).
  • ASCII American Standard Code for Information Interchange
  • FIG. 7 illustrates a third example of detecting obfuscation of a symbol in an ELF file included in a registered package file according to an embodiment of the present invention.
  • ELF files can contain read-only sections (.rdata section 710 or .rodata sections), and the section header table 410 contains headers for these read-only sections. (.rdata section header 720 or .rodata section header).
  • Obfuscation for such a read-only section may be achieved by encrypting or encoding the texts contained in the read-only section. Therefore, the security evaluation system 300 obfuscates the read-only section by checking the read-only section through the header for the read-only section and analyzing the read-only values included in the identified read-only section. Can be detected.
  • the security assessment system 300 identifies the .rdata section header 720 in the section header table 410 of the ELF file, and the identified .rdata section header 720 is pointing. Find the .rdata section 730 to analyze the values contained in the .rdata section 730.
  • the .rdata section 730 may be a section that obfuscates the texts included in the .rdata section 710, and the security evaluation system 300 determines that values included in the .rdata section 730 are null. ), Or not represented in ASCII code, it can be seen that obfuscation is applied to the .rdata section 730, unlike the .rdata section 710.
  • the first ELF header 810 is an unobfuscated header and shows an example including information such as the size of the section header 811, the number of section headers 812, and the size of the section 813.
  • the second ELF header 820 is a header to which obfuscation is applied, and shows an example in which original values are changed to manipulated values 821.
  • the security evaluation system 300 may determine whether to apply obfuscation to the ELF header by detecting an abnormal value of the ELF header.
  • normal values of the ELF header may have a range of values, but may be out of this range when obfuscation is applied.
  • the security assessment system 300 may set a range of normal values for at least one item of the size of the section header included in the ELF header, the number of section headers, and the size of the section, and in the ELF header, the at least A value of one item may be extracted, and if the extracted value is out of a set range of normal values, it may be determined that obfuscation is applied to the ELF header.
  • values extracted from the first ELF header 810 will be included in the range of normal values, and values extracted from the second ELF header 820 will be out of the range of normal values. .
  • the security evaluation system 300 may detect that obfuscation is applied to the ELF header.
  • FIG. 9 is a diagram for one example of determining whether to apply obfuscation to a header of a section including executable code according to an embodiment of the present invention.
  • the section header table 410 described above may include a header of a section (.text section) including executable code.
  • the header 910 of the normal .text section may include a size 911 of the executable code, and the size of the executable code 911 included in the header 910 of the normal .text section as one of the obfuscation schemes. There is a way to manipulate.
  • FIG. 9 illustrates an example in which the obfuscation is applied to the header 910 of the normal .text section, and the header 920 of the obfuscated .text section including the manipulated value 921.
  • the security evaluation system 300 exports an export symbol entry (Export function of FIG. 9) from the symbol entry table 420 included in the dynamic linking symbol table section (.dynsym section). Function)) can be used to collect the address of functions.
  • the security evaluation system 300 may repeatedly collect the addresses of the functions through the addresses of these export functions, and calculate the size of the executable code using the collected addresses.
  • the security evaluation system 300 may extract the size of the executable code 911 from the header 910 of the normal .text section, and extract the size of the extracted executable code 911 and the calculated size of the executable code. By comparing, it may be determined that obfuscation has not been applied to the header 910 of the normal .text section.
  • the manipulated value 921 is extracted from the obfuscated .text section header 920, as in the embodiment of FIG. 9, the manipulated value 921 is the size of the original executable code 911. Since it is different from the calculated execution code size, the security evaluation system 300 may detect that the obfuscation is applied to the header 920 of the obfuscated .text section. .
  • FIG. 10 illustrates an example of detecting obfuscation of a code according to an embodiment of the present invention.
  • the section header table 410 may include a header of a section (.init section and / or .init_array section) that contains code for process initialization.
  • 10 shows a header 1010 of the .init section and a header 1020 of the .init_array section, respectively.
  • 10 also shows a segment 1030. Segment 1030 is created as the linker merges the sections that the ELF file contains.
  • the header 1010 of the .init section and / or the header 1020 of the .init_array section are executed first at run time so that the segment 1030 ) May be implemented to execute codes of a code segment 1031.
  • the code segment 1031 may have a read-write-execute (RWE) right
  • the data segment 1032 may have a read-write (RW) right.
  • RWE read-write-execute
  • This code segment 1031 contains actual executable code for driving an application. However, when obfuscation is performed on executable codes (for example, when at least some of the executable code is encrypted), and when the codes of the code segment 1031 are executed in a normal manner, the executable code is executed normally due to the encrypted code. Can't.
  • a new segment having read-write-execute (RWE) rights is added to restore the obfuscated code.
  • 10 illustrates an example in which an instruction for restoring obfuscated code is added to an added segment 1033.
  • the header 1010 of the .init section and / or the header 1020 of the .init_array section that are executed first at runtime may be changed to point to the added segment 1033 instead of the code segment 1031.
  • security assessment system 300 may detect the presence of added segment 1033. In this case, the security evaluation system 300 may determine that obfuscation is applied to the code segment 1031 when an added segment 1033 having a read-write-execute (RWE) right exists. have.
  • RWE read-write-execute
  • the security assessment system 300 may detect whether there is a pointing to the segment 1033 added to the header 1010 of the .init section and / or the header 1020 of the .init_array section. . At this time, the security evaluation system 300 obfuscates the code segment 1031 when there is a pointing to the segment 1033 added to the header 1010 of the .init section and / or the header 1020 of the .init_array section. You can decide that the paint is applied.
  • security assessment system 300 analyzes (eg, disassembles) the added segment 1032 to restore obfuscated code contained in code segment 1031 (eg, encrypted). When the code for decoding the code is present in the added segment 1033, it may be determined that obfuscation is applied to the code segment 1031.
  • the security evaluation system 300 may detect whether the code is obfuscated by analyzing the code itself.
  • FIG. 11 illustrates an example of code conformance according to an embodiment of the present invention.
  • the security evaluation system 300 may export an export symbol entry (the export function of FIG. 9) from a symbol entry table 420 included in a dynamic linking symbol table section (.dynsym section). Function)) can be used to collect the address of functions.
  • the security evaluation system 300 may analyze the instructions included in each function through the collected address.
  • the instructions Push and Pop are the most commonly used instructions in assembly language, and push a and b 1110 are instructions for storing the values of operands a and b in a stack (register).
  • Pop a, b (1120) is an instruction for the operation of taking out the value of the top of the stack and storing it in the operands a, b.
  • the security evaluation system 300 may analyze whether the code is pushed by searching whether the value of the pushed register is Pop. If the value of the pushed register is not Pop, it may be determined that obfuscation is applied to at least some code.
  • Such matching is required between a pair of instructions stmfd and ldmfd and a pair of instructions stmdb and pop.w.
  • the security evaluation system 300 may further analyze the consistency of such pairs of instructions stmfd and ldmfd and pairs of instructions stmdb and pop.w, and if there is no consistency between the instructions, at least some of the code may be obfuscated. You can judge.
  • the security evaluation system 300 may determine whether to apply obfuscation to at least some of the codes depending on the existence of an operation code (opcode) combination that does not exist (not predefined). In other words, in the case where an obfuscation code is formed according to obfuscation, the security evaluation system 300 may detect obfuscation of the code.
  • opcode operation code
  • the security evaluation system 300 may determine whether to apply obfuscation to the code based on the information on the branch position of the branch (branch) code. For example, as described above, the security evaluation system 300 has information about all functions through information about addresses of functions. At this time, if the position of the instruction to be performed next through the branch code is not the position to these functions, the security evaluation system 300 may detect obfuscation of the code.
  • FIG. 12 is a diagram for one example of determining whether to apply obfuscation to a code based on information on a branch position according to an embodiment of the present invention.
  • FIG. 12 illustrates an example of branching to an added segment 1033 through the branch code 1210 included in the function A 1200, rather than the code segment 1031 of the segment 1030 described with reference to FIG. 10. have.
  • the security evaluation system 300 may detect that obfuscation is applied to at least some code.
  • the security evaluation system 300 may determine whether to apply obfuscation to the binary code based on the presence of a dummy code of a predefined pattern.
  • Dummy code is code that is added to make code analysis difficult without affecting registers. Therefore, the security evaluation system 300 may predefine and manage information on patterns of these dummy codes, and if there are codes of a managed pattern, it may be determined as dummy codes, and code obfuscation may be performed. To detect that a dummy code has been added.
  • Table 1 below shows an example of a dummy code.
  • the security evaluation system 300 may be obfuscated by adding dummy code to the source code. Such dummy code may be converted into junk code through compilation.
  • FIG. 13 is a diagram for one example of adding a dummy code to source code according to one embodiment of the present invention.
  • FIG. 13 illustrates that the dummy code 1321 is added to the source code 1310 including the operation code 1311 to generate the obfuscated source code 1320, and the obfuscated source code 1320 is compiled to the junk code.
  • An example of generating a binary code 1330 including a 1133 and a compiled operation code 1332 is shown.
  • the security evaluation system 300 may pre-set and manage the patterns for the dummy code 1321 and / or the junk code 1331, and if a predefined pattern is found in the source code or the binary code. For example, it can detect the application of obfuscation to the code. For example, successive use of instruction ldr and / or instruction lsls in binary code may be set as a pattern for junk code 1331. In this case, the security evaluation system 300 may detect the application of obfuscation to the code by analyzing a binary code and detecting a pattern in which the instruction ldr and / or the instruction lsls are repeatedly used.
  • FIG. 14 is a block diagram illustrating an example of a component that may be included in a processor of a server according to an embodiment of the present invention
  • FIG. 15 is a security evaluation that may be performed by a server according to an embodiment of the present invention.
  • the security evaluation system 300 may be implemented in the form of a computer device such as the server 150 described above.
  • the processor 222 of the server 150 is a package file register 1410, an ELF file identifier 1420, and obfuscation as components for implementing the security evaluation system 300.
  • the determiner 1430, the security grade determiner 1440, and the reporter 1450 may be included.
  • the processor 222 and the components of the processor 222 may perform steps 1510 to 1550 included in the security evaluation method of FIG. 15.
  • the processor 222 and the components of the processor 222 may be implemented to execute a control instruction according to a code of an operating system included in the memory 221 or a code of at least one program.
  • the components of the processor 222 may be representations of different functions of the processor 222 performed by the processor 222 according to a control command provided by a code stored in the server 150.
  • the package file register 1410 may be used as a functional representation of the processor 222 in which the processor 222 registers a package file according to the above-described control command.
  • the package file registration unit 1410 may register a package file for installing and driving the application.
  • the package file can be registered with the application publisher for distribution to users of the application.
  • the security evaluation system 300 may be implemented in a device that provides a service for distributing package files of applications for which an application publisher is registered, or as a separate system that communicates with the aforementioned device through the network 170. Can be implemented.
  • the security evaluation system 300 may receive and register a package file registered with an application publisher through the network 170.
  • a package file may include an Android application package (Apk) as described above.
  • the ELF file identification unit 1420 may identify an executable and linkable format (ELF) file included in the registered package file.
  • ELF executable and linkable format
  • the PE file may be a so file.
  • the ELF file to be identified may be identified through an extension of the file among the files identified through the package decomposition module 310 and the file identification module 320.
  • the obfuscation determiner 1430 may determine whether to apply obfuscation to at least one of an ELF header, a section header, a section, and a segment included in the ELF file.
  • Various embodiments for determining whether to apply obfuscation have already been described in detail, and more detailed operations of the obfuscation determiner 1430 according to these embodiments will be described in more detail with reference to the following drawings.
  • the security rating determiner 1440 may determine a security rating for the ELF file based on whether obfuscation is applied.
  • the security level of the ELF file may be determined according to whether obfuscation is applied to the ELF file, the type or degree of obfuscation applied to the ELF file, and the like.
  • the type of obfuscation has been described in detail through various embodiments described above, and the degree of obfuscation may be determined based on, for example, the number of types of obfuscation applied, the degree of conformity of codes, and the like.
  • the reporting unit 1450 may report information on whether obfuscation is applied and information on a security level determined for the ELF file. For example, for an identified ELF file, whether the section header is obfuscated, whether obfuscation is applied to strings and / or string tables, whether obfuscation is applied to symbol tables, whether obfuscation is applied to code, and so on. Information may be provided to an administrator or user of the security evaluation system 300.
  • Steps 1610 through 1630 of FIG. 16 may be included in step 1530 of FIG. 15. In this case, step 1610 may be included in step 1530 but may be performed before step 1530.
  • the obfuscation determiner 1430 may set a range of normal values for at least one item of the size of the section header included in the ELF header, the number of section headers, and the size of the section.
  • the obfuscation determiner 1430 may extract a value of at least one item from the ELF header. If the ELF header is not obfuscated, a value included in the range of normal values will be extracted, and if the ELF header is obfuscated, a value outside the range of normal values will be extracted.
  • the obfuscation determination unit 1430 may determine that the obfuscation is applied to the ELF header when the extracted value is out of the set range of the normal value. In other words, the obfuscation determiner 1430 sets a range of normal values for at least one of the size of the section header, the number of section headers, and the size of the section in advance, and then obfuscates the ELF header of the ELF file. This can be used to determine whether or not the application is applied. Obfuscation detection for such an ELF header has already been described in detail with reference to FIG. 8.
  • Steps 1710 and 1720 of FIG. 16 may be included in step 1530 of FIG. 15.
  • the obfuscation determiner 1430 may extract a header of the dynamic linking symbol table section (.dynsym section) from the section header table included in the ELF file.
  • the obfuscation determiner 1430 may determine whether to apply obfuscation to the section header by analyzing the header of the extracted dynamic linking symbol table section.
  • the obfuscation determination unit 1430 may include a first condition in which the header of the extracted dynamic linking symbol table section includes null, and a header in which the header of the extracted dynamic linking symbol table section cannot be parsed. If the condition included in the condition 2 and the third condition in which the information included in the header of the extracted dynamic linking symbol table section does not exist in the dynamic linking information section (.dynamic section) of the sections is satisfied, the section It can be determined that obfuscation is applied to the header. Obfuscation detection for the header of this dynamic linking symbol table section (.dynsym section) has already been described in detail with reference to FIGS. 4 and 5.
  • FIG. 18 is a flowchart illustrating a method of determining whether obfuscation is applied to a header of a section including executable code according to an embodiment of the present invention. Steps 1810 through 1830 of FIG. 18 may be included in step 1530 of FIG. 15.
  • the obfuscation determiner 1430 may collect addresses of functions through an export symbol entry included in a dynamic linking symbol table section (.dynsym section) among sections included in the ELF file. .
  • the obfuscation determiner 1430 may disassemble the address of an export symbol entry to track the entire functions and collect the address.
  • the obfuscation determination unit 1430 may extract a value for the size of the executable code from the header of the section (.text section) including the executable code in the section header table included in the ELF file. If the header of the section containing the executable code (.text section) has been manipulated (obfuscated), the value extracted will be different from the value computed through the collected addresses.
  • the obfuscation determination unit 1430 may determine whether to apply obfuscation to the header of the section including the execution code by comparing the extracted value with the size of the execution code calculated through the collected addresses. In other words, if the calculated value and the extracted value are different, the obfuscation of the header of the section including the executable code is detected. Obfuscation detection for the header of the section containing such executable code has already been described in detail with reference to FIG. 9.
  • Step 1910 of FIG. 19 may be included in step 1530 of FIG. 15.
  • the obfuscation determiner 1430 analyzes the symbol entry included in the dynamic linking symbol table section (.dynsym section) among the sections included in the ELF file, and includes at least one of a name and an address included in the symbol entry. If one contains null or is not represented in American Standard Code for Information Interchange (ASCII) code, it can be determined that obfuscation has been applied to the dynamic linking symbol table section. This obfuscation detection process has already been described in detail with reference to FIG. 6.
  • ASCII American Standard Code for Information Interchange
  • Step 2010 of FIG. 20 may be included in step 1530 of FIG. 15.
  • the obfuscation determination unit 1430 analyzes the information included in the read-only section among the sections included in the ELF file, so that the included information includes null or If not expressed in ASCII code, you can determine that obfuscation is applied to the read-only section.
  • This read-only section may include a .rdata section or a .rodata section, and the obfuscation detection for these sections has already been described in detail with reference to FIG. 7.
  • Step 21 is a flowchart illustrating a first example of a method of determining whether obfuscation is applied to a code according to an embodiment of the present invention. Step 2110 of FIG. 21 may be included in step 1530 of FIG. 15.
  • the obfuscation determiner 1430 may have other read-write-execute privileges in addition to the segments in which sections included in the ELF file are integrated and created through the linker. Depending on whether the segment is added, it is possible to determine whether or not to obfuscate the code included in the predefined segment. In FIG. 10, the added segment 1033 has been described, and the addition of the segment itself may mean that obfuscation is applied to the code. Accordingly, the obfuscation determiner 1430 may interpret that obfuscation is applied to the code that another segment having a read-write-execute right is added.
  • Steps 2210 through 2230 of FIG. 22 may be included in step 1530 of FIG. 15.
  • the obfuscation determiner 1430 may identify a header of a section (.init section or .init_array section) including code for process initialization in the section header table included in the ELF file.
  • the obfuscation determiner 1430 may determine that obfuscation is applied to a code included in a predefined segment when a pointer to another segment identified in the header of the identified section exists.
  • the obfuscation determiner 1430 detects that the .init section or the .init_array section points to the segment to which it is added, and includes the code included in the predefined segment (for example, the code segment 1031 of FIG. 10). Can be detected as obfuscation for.
  • Steps 2310 and 2320 of FIG. 23 may be included in step 1530 of FIG. 15.
  • the obfuscation determination unit 1430 analyzes another identified segment, and when there is a code for restoring the encrypted code at runtime of the application, the obfuscation is included in the code included in the predefined segment. It can be determined that it has been applied.
  • the obfuscation determination unit 1430 analyzes the added segment to determine whether there is a code for restoring the encrypted code, and determines the existence of the code (eg, the code segment of FIG. 10). 1031) can be detected as obfuscation of the code included in).
  • Steps 2410 and 2420 of FIG. 24 may be included in step 1530 of FIG. 15.
  • the obfuscation determiner 1430 may collect addresses of functions through an export symbol entry included in a dynamic linking symbol table section (.dynsym section) among sections included in the ELF file. .
  • the obfuscation determination unit 1430 may determine whether to apply obfuscation to the code by analyzing the instructions included in the functions by using the collected address.
  • the obfuscation determiner 1430 may determine the consistency between the instructions included in the functions, whether there is an undefined operation code (opcode) combination, information on the branch position of the branch code, and the predefined location. It may be determined whether obfuscation is applied to the code based on at least one of whether a dummy code of the pattern exists.
  • opcode undefined operation code
  • the obfuscation determiner 1430 may read-write-execute, in addition to the segment in which the sections included in the ELF file are integrated and generated through the linker. RWE) confirm the addition of another segment with authority, and if the instructions included by the functions branch to code included in the other segment, it may be determined that obfuscation is applied to the code.
  • 16 to 24 may be performed in parallel with each other in step 1530.
  • the steps of performing the same operation may not be performed in duplicate, but may be performed only once. For example, collecting the addresses of the functions 1810 and 2410 may be performed only one of the two.
  • the security level applied to the registered application is determined in an objective manner in accordance with obfuscation, vulnerability, and / or security solution. It can be used to improve the security of the application by analyzing and understanding and providing the analyzed information. In addition, it is possible to detect whether obfuscation is applied to an Executable and Linkable Format (ELF) file.
  • ELF Executable and Linkable Format
  • the system or apparatus described above may be implemented as a hardware component, a software component or a combination of hardware components and software components.
  • the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs).
  • ALUs arithmetic logic units
  • FPGAs field programmable gate arrays
  • PLU programmable logic unit
  • the processing device may execute an operating system (OS) and one or more software applications running on the operating system.
  • the processing device may also access, store, manipulate, process, and generate data in response to the execution of the software.
  • processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include.
  • the processing device may include a plurality of processors or one processor and one controller.
  • other processing configurations are possible, such as parallel processors.
  • the software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device.
  • Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. It can be embodied in.
  • the software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner.
  • Software and data may be stored on one or more computer readable media.
  • the method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium.
  • the computer readable medium may include program instructions, data files, data structures, etc. alone or in combination.
  • the program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks.
  • Such a recording medium may be various recording means or storage means in the form of a single or several hardware combined, and is not limited to a medium directly connected to any computer system, but may be distributed on a network.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.

Landscapes

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

Abstract

L'invention concerne un procédé et un système de détection d'application d'obfuscation et d'évaluation de la sécurité d'un fichier de format exécutable et liable (ELF). Le procédé d'évaluation de sécurité peut comprendre les étapes consistant à : enregistrer un fichier progiciel servant à installer et à exécuter une application ; identifier un fichier de format exécutable et liable (ELF) inclus dans le fichier progiciel enregistré ; déterminer si l'obfuscation a été appliquée à un en-tête ELF et/ou un en-tête de section et/ou une section ou un segment inclus dans le fichier ELF ; et déterminer un niveau de sécurité pour le fichier ELF sur la base de l'application de l'obfuscation.
PCT/KR2017/004236 2017-04-20 2017-04-20 Procédé et système de détection d'application d'obfuscation et d'évaluation de la sécurité d'un fichier elf WO2018194196A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/KR2017/004236 WO2018194196A1 (fr) 2017-04-20 2017-04-20 Procédé et système de détection d'application d'obfuscation et d'évaluation de la sécurité d'un fichier elf
JP2018080912A JP7131946B2 (ja) 2017-04-20 2018-04-19 アプリケーションの保安性を評価する方法およびシステム
US15/958,115 US10963563B2 (en) 2017-04-20 2018-04-20 Method and system for evaluating security of application

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2017/004236 WO2018194196A1 (fr) 2017-04-20 2017-04-20 Procédé et système de détection d'application d'obfuscation et d'évaluation de la sécurité d'un fichier elf

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/004243 Continuation WO2018194198A1 (fr) 2017-04-20 2017-04-20 Procédé et système pour détecter l'application d'un brouillage à un fichier pe et évaluer sa sécurité

Related Child Applications (2)

Application Number Title Priority Date Filing Date
PCT/KR2017/004243 Continuation WO2018194198A1 (fr) 2017-04-20 2017-04-20 Procédé et système pour détecter l'application d'un brouillage à un fichier pe et évaluer sa sécurité
PCT/KR2017/004584 Continuation WO2018199366A1 (fr) 2017-04-20 2017-04-28 Procédé et système permettant de détecter si un obscurcissement a été appliqué à un fichier dex et d'évaluer la sécurité

Publications (1)

Publication Number Publication Date
WO2018194196A1 true WO2018194196A1 (fr) 2018-10-25

Family

ID=63855840

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/004236 WO2018194196A1 (fr) 2017-04-20 2017-04-20 Procédé et système de détection d'application d'obfuscation et d'évaluation de la sécurité d'un fichier elf

Country Status (1)

Country Link
WO (1) WO2018194196A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109598107A (zh) * 2018-11-20 2019-04-09 江苏通付盾信息安全技术有限公司 一种基于应用安装包文件的代码转换方法及装置
CN109614772A (zh) * 2018-11-20 2019-04-12 江苏通付盾信息安全技术有限公司 基于应用安装包文件的代码转换方法及装置
CN113742002A (zh) * 2021-09-10 2021-12-03 上海达梦数据库有限公司 一种动态库依赖关系获取方法、装置、设备及存储介质
CN114398102A (zh) * 2022-01-18 2022-04-26 杭州米络星科技(集团)有限公司 一种应用程序包生成方法、装置、编译服务器及计算机可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6668325B1 (en) * 1997-06-09 2003-12-23 Intertrust Technologies Obfuscation techniques for enhancing software security
KR20120120686A (ko) * 2011-04-25 2012-11-02 삼성전자주식회사 휴대용 단말기에서 어플리케이션 패키지를 처리하기 위한 장치 및 방법
KR101490047B1 (ko) * 2013-09-27 2015-02-04 숭실대학교산학협력단 자가변환 기반 애플리케이션 코드 난독화 장치 및 그 방법
KR101700731B1 (ko) * 2012-04-26 2017-01-31 텐센트 테크놀로지(센젠) 컴퍼니 리미티드 애플리케이션에 접근하기 위한 방법 및 장치
KR20170018744A (ko) * 2015-08-10 2017-02-20 라인 가부시키가이샤 어플리케이션의 코드를 보호하기 위한 시스템 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6668325B1 (en) * 1997-06-09 2003-12-23 Intertrust Technologies Obfuscation techniques for enhancing software security
KR20120120686A (ko) * 2011-04-25 2012-11-02 삼성전자주식회사 휴대용 단말기에서 어플리케이션 패키지를 처리하기 위한 장치 및 방법
KR101700731B1 (ko) * 2012-04-26 2017-01-31 텐센트 테크놀로지(센젠) 컴퍼니 리미티드 애플리케이션에 접근하기 위한 방법 및 장치
KR101490047B1 (ko) * 2013-09-27 2015-02-04 숭실대학교산학협력단 자가변환 기반 애플리케이션 코드 난독화 장치 및 그 방법
KR20170018744A (ko) * 2015-08-10 2017-02-20 라인 가부시키가이샤 어플리케이션의 코드를 보호하기 위한 시스템 및 방법

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109598107A (zh) * 2018-11-20 2019-04-09 江苏通付盾信息安全技术有限公司 一种基于应用安装包文件的代码转换方法及装置
CN109614772A (zh) * 2018-11-20 2019-04-12 江苏通付盾信息安全技术有限公司 基于应用安装包文件的代码转换方法及装置
CN113742002A (zh) * 2021-09-10 2021-12-03 上海达梦数据库有限公司 一种动态库依赖关系获取方法、装置、设备及存储介质
CN114398102A (zh) * 2022-01-18 2022-04-26 杭州米络星科技(集团)有限公司 一种应用程序包生成方法、装置、编译服务器及计算机可读存储介质
CN114398102B (zh) * 2022-01-18 2023-08-08 杭州米络星科技(集团)有限公司 一种应用程序包生成方法、装置、编译服务器及计算机可读存储介质

Similar Documents

Publication Publication Date Title
JP7131946B2 (ja) アプリケーションの保安性を評価する方法およびシステム
WO2014035043A1 (fr) Appareil et procédé permettant de diagnostiquer des applications malveillantes
WO2018194196A1 (fr) Procédé et système de détection d'application d'obfuscation et d'évaluation de la sécurité d'un fichier elf
WO2019054613A1 (fr) Procédé et système d'identification de progiciel source libre en fonction d'un fichier binaire
WO2017213400A1 (fr) Détection de logiciels malveillants par exploitation des variations de re-composition de logiciel malveillant
CN107408176A (zh) 恶意对象的执行剖析检测
WO2013089340A1 (fr) Appareil et procédé de détection de similarité entre applications
WO2013191458A1 (fr) Appareil et procédé de vérification de licence et support de stockage lisible par ordinateur stockant un programme associé
WO2019066222A1 (fr) Procédé et système pour identifier un progiciel libre sur la base d'un fichier binaire
CN108353083A (zh) 用于检测域产生算法(dga)恶意软件的系统及方法
Mao et al. Detecting malicious behaviors in javascript applications
WO2017126786A1 (fr) Dispositif électronique d'analyse de code malveillant et procédé associé
WO2016024838A1 (fr) Procédé et système de fourniture de service de sécurité d'application en nuage
WO2014088262A1 (fr) Dispositif et procédé de détection d'applications frauduleuses/modifiées
WO2018199366A1 (fr) Procédé et système permettant de détecter si un obscurcissement a été appliqué à un fichier dex et d'évaluer la sécurité
CN113961919B (zh) 恶意软件检测方法和装置
WO2019135425A1 (fr) Procédé et système de vérification de licence de logiciel à source ouverte
WO2024071451A1 (fr) Procédé de détection de macro malveillante dans un fichier non exécutable à l'aide d'une technologie ocr, et appareil associé
WO2019004503A1 (fr) Procédé et système de détection de vulnérabilité d'application
WO2016200058A1 (fr) Dispositif, procédé et programme informatique de fusion binaire
WO2024071855A1 (fr) Procédé et système de fourniture de service de détection de macrobot
WO2020111482A1 (fr) Procédé et système d'ingénierie inverse utilisant des mégadonnées en fonction du contexte d'exécution de programme
US20200394301A1 (en) Program analysis system, program analysis method and storage medium
CN116881173B (zh) 接口参数的检测方法、装置、电子设备和计算机可读介质
EP4137976A1 (fr) Dispositif d'apprentissage, dispositif de détection, procédé d'apprentissage, procédé de détection, programme d'apprentissage et programme de détection

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17906284

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17906284

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载