KR20230100441A - Method for self integrity verification of dynamic library and apparatus thereof - Google Patents

Abstract

In order to achieve the above object, a method for verifying self-integrity of a dynamic library according to an embodiment of the present invention includes generating a Mach Object File (Mach-O File), and a verification value for the Mach object file. Calculating, and storing the calculated verification value in a predetermined location in the Mach object file.

Description

Method for self-integrity verification of dynamic library and device therefor

The following embodiments relate to a method and apparatus for self-verifying the integrity of a dynamic library, and more particularly, to a method for self-verifying the integrity of a dynamic library in an operating system such as iOS in a server-less manner.

Recently, security threats such as malicious attacks on portable devices such as smart phones, privacy data protection threats, eavesdropping, and abuse are increasing.

Therefore, research is being conducted in various aspects on a method for verifying the integrity of a file executed in a portable device.

As a conventional method for verifying the integrity of a dynamic library, a method for verifying integrity in conjunction with a separate external file or server is known. However, the method using a separate external file or server has a problem in that a value for integrity verification must be generated for distributed apps in all download target environments, and a separate file or server must be configured.

Therefore, there is an urgent need for a method for verifying the integrity of the dynamic library itself without a separate file or server.

Korean Patent Publication No. 10-2021-0144687 (Title of Invention: Device and Application Integrity Verification)

An object of the present invention is to provide a method and apparatus for ensuring the integrity of a dynamic library in an environment such as iOS.

Another object of the present invention is to provide a method and apparatus for verifying the integrity of a dynamic library without a separate server or file.

In order to achieve the above object, a method for verifying self-integrity of a dynamic library according to an embodiment of the present invention includes generating a Mach Object File (Mach-O File), and a verification value for the Mach object file. Calculating, and storing the calculated verification value in a predetermined location in the Mach object file.

At this time, the Mach object file may include a Header area, a Load Command area, and a Data area.

At this time, the predetermined position in the Mach object file may correspond to a padding area in the Load Command area.

At this time, when the Mach object file is loaded, an inspection value for the Mach object file may be generated, and integrity may be verified based on whether the verification value matches the inspection value.

At this time, when the Mach object file is loaded, a loading time and path of the Mach object file may be searched, and the inspection value for the data area may be generated based on the path.

In this case, the check value may correspond to the HMAC value for the Mach object file.

In this case, the location where the Mach object file is stored may be variably set according to a preset policy.

In addition, a method for self-integrity verification of a dynamic library according to another embodiment of the present invention for achieving the above object includes generating a check value for a Mach Object File (Mach-O File), and the Mach and checking whether a verification value of the Mach object file included in the object file and the check value match.

At this time, the Mach object file may include a Header area, a Load Command area, and a Data area.

At this time, a verification value for the Mach object file may be stored in a padding area within the Load Command area.

At this time, when the Mach object file is loaded, a loading time and path of the Mach object file may be searched, and the inspection value for the data area may be generated based on the path.

In this case, the check value may correspond to the HMAC value for the Mach object file.

In this case, the location where the Mach object file is stored may be variably set according to a preset policy.

In addition, an apparatus for self-integrity verification of a dynamic library according to an embodiment of the present invention for achieving the above object includes a memory in which at least one program is recorded, and a processor executing the program, wherein the program is a Mach object. The steps of generating a check value for a Mach Object File (Mach-O File) and checking whether the check value matches the check value for the Mach object file included in the Mach object file are performed. Contains commands for

At this time, the Mach object file may include a Header area, a Load Command area, and a Data area.

At this time, a verification value for the Mach object file may be stored in a padding area within the Load Command area.

At this time, when the Mach object file is loaded, a loading time and path of the Mach object file may be searched, and the inspection value for the data area may be generated based on the path.

In this case, the check value may correspond to the HMAC value for the Mach object file.

In this case, the location where the Mach object file is stored may be variably set according to a preset policy.

According to the present invention, it is possible to provide a method and apparatus for guaranteeing the integrity of a dynamic library in an environment such as iOS.

In addition, the present invention can provide a method and apparatus for verifying the integrity of a dynamic library without a separate server or file.

1 is a flowchart illustrating a method for self-integrity verification of a dynamic library according to an embodiment of the present invention.
2 is a flowchart illustrating a method for self-integrity verification of a dynamic library according to another embodiment of the present invention.
3 is a diagram conceptually illustrating a Mach-O file structure.
4 is a detailed diagram showing a Mach-O file structure including a padding area.
5 is a diagram showing the configuration of a computer system according to an embodiment.

Advantages and features of the present invention, and methods of achieving them, will become clear with reference to the detailed description of the following embodiments taken in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be implemented in various different forms, only these embodiments make the disclosure of the present invention complete, and common knowledge in the art to which the present invention belongs. It is provided to fully inform the holder of the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numbers designate like elements throughout the specification.

Although "first" or "second" is used to describe various elements, these elements are not limited by the above terms. Such terms may only be used to distinguish one component from another. Therefore, the first component mentioned below may also be the second component within the technical spirit of the present invention.

Terms used in this specification are for describing embodiments and are not intended to limit the present invention. In this specification, singular forms also include plural forms unless specifically stated otherwise in a phrase. As used herein, "comprises" or "comprising" implies that a stated component or step does not preclude the presence or addition of one or more other components or steps.

Unless otherwise defined, all terms used herein may be interpreted as meanings commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in commonly used dictionaries are not interpreted ideally or excessively unless explicitly specifically defined.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings, and when describing with reference to the drawings, the same or corresponding components are given the same reference numerals, and overlapping descriptions thereof will be omitted. .

1 is a flowchart illustrating a method for self-integrity verification of a dynamic library according to an embodiment of the present invention.

Specifically, FIG. 1 may correspond to a method for generating a dynamic library capable of verifying self-integrity.

Referring to FIG. 1 , a method for self-integrity verification of a dynamic library according to an embodiment generates a Mach Object File (Mach-O File) (S110).

At this time, the Mach-O file can be used in a system based on the Mach Kernel, and systems using the Mach Kernel include Darwin iOS, macOS, watchOS, and the like.

At this time, the Mach object file may include a Header area, a Load Command area, and a Data area.

Next, a verification value for the Mach object file is calculated (S120).

In this case, the verification value may correspond to an HMAC value or a separate electronic signature value for the Mach object file.

Next, the calculated verification value is stored in a predetermined location in the Mach object file (S130).

At this time, the predetermined position in the Mach object file may correspond to a padding area in the Load Command area.

At this time, when the Mach object file is loaded, an inspection value for the Mach object file may be generated, and integrity may be verified based on whether the verification value matches the inspection value.

At this time, when the Mach object file is loaded, a loading time and path of the Mach object file may be searched, and the inspection value for the data area may be generated based on the path.

In this case, the check value may correspond to the HMAC value for the Mach object file.

In this case, the location where the Mach object file is stored may be variably set according to a preset policy.

2 is a flowchart illustrating a method for self-integrity verification of a dynamic library according to another embodiment of the present invention.

In a method for self-integrity verification of a dynamic library according to another embodiment of the present invention, a check value for a Mach Object File (Mach-O File) is generated (S210).

At this time, the Mach object file may include a Header area, a Load Command area, and a Data area.

Next, it is checked whether the verification value of the Mach object file included in the Mach object file and the check value match (S220).

At this time, a verification value for the Mach object file may be stored in a padding area within the Load Command area.

At this time, when the Mach object file is loaded, a loading time and path of the Mach object file may be searched, and the inspection value for the data area may be generated based on the path.

In this case, the check value may correspond to the HMAC value for the Mach object file.

In this case, the location where the Mach object file is stored may be variably set according to a preset policy.

3 is a diagram conceptually illustrating a Mach-O file structure.

4 is a detailed diagram showing a Mach-O file structure including a padding area.

Mach-O is an abbreviation for Mach Object file format, and refers to formats such as executable files, object codes, and libraries. Mach-O is used in most systems based on the Mach Kernel. These include Darwin iOS, macOS, watchOS, etc., and come in many types, such as executables, shared and static libraries, Kernel Extension (KEXT) bundles, and debug support files.

The structure of a Mach-O file consists of one Mach-O Header, a series of Load Commands, and Data (Raw Content). Data consists of one or more segments, and each segment contains a section. This is included. A padding area exists at the end of the Load Commands area.

As an existing integrity verification method of the Mach-O file, it is defined in the LC_CODE_SIGNATURE area as an item of the Load Commands Table, and the digital signature value of the Mach-O file is added to the end of the raw content to ensure file integrity. It can be defined so that it can be checked.

Bitcode is a code to support various cputypes. In general, a developer builds a universal library for each cpu architecture and registers it in the App Store. In the past, various resources as well as libraries were registered in the App Store, including all resources according to various environments such as each cpu architecture or 32/64 bit, and the app downloaded all resources to the user terminal. However, since the above method is inefficient in that all resources are downloaded, bitcode was devised as a technology to download only the necessary resources from the App Store to the user terminal in order to overcome the above inefficiency.

When a developer compiles the source code and first generates bitcode and registers it in the App Store, the App Store builds it again according to the cpu type and downloads the application to the user terminal. Even if this results in an additional CPU architecture, no additional work is required from the developer.

However, in the case of a code that should not be changed, such as a cryptographic module, if it is registered in the App Store as a bitcode, the cryptographic module is changed during the download process, resulting in a problem that integrity verification of the cryptographic module initially registered as a bitcode becomes impossible.

Apps distributed in bitcode can perform integrity verification using the Mach-O file electronic signature (CodeSign) method. However, there is a problem in that the app registered with the initial bit code is changed and the cryptographic module itself cannot perform verification.

As an example of another integrity verification method, there is a method using an external file or server.

When a file registered as bitcode is downloaded to a user terminal, an integrity verification value for the downloaded app is generated. The generated integrity verification value is stored in an external file or server. Next, the integrity verification for the app is performed by comparing the integrity verification value stored in the external file or server with the generated integrity verification value.

However, the integrity verification method using an external file or server has a disadvantage in that integrity verification values must be generated for all download target environments, and a separate file or server for integrity verification must be provided.

A method for verifying the integrity of a Mach-O file according to an embodiment of the present invention is as follows.

First, the padding area (buffer) of the load command area is left empty, and the code area starts from a specific offset using offset information.

Since the starting position of the code area and the position of the code signature attached when the developer packages are all recorded in the load command information, the position of the code can be secured through this.

At this time, the code signature is attached to the last part of the code and generally has a size of about 24KB.

An integrity value is created using the secured code information. In this case, the integrity value may be set to HMAC or a separate digital signature value, and the scope of the present invention is not limited thereto.

By designating and storing the integrity value at a location within the padding area, a file including the integrity value is constructed.

Next, self-integrity verification is performed in the execution process. The loaded dynamic library finds its own path and creates an integrity verification value.

Specifically, the loaded dynamic library checks the loading time and location of the dynamic library for self-integrity verification.

The path where the dynamic library is located is installed in a variable location according to the App Store policy, so it searches its own location when it is run.

The process of finding the path of the dynamic library dylib is shown in [Table 1] below.

struct mach_header* header = &_mh_dylib_header;
const char* imagename = 0;
int cnt = _dyld_image_count();
for(I=1; I<cnt; I++)
{
if(_dyld_get_image_header(I) == header)
imagename = (MC_CHAR*)_dyld_get_image_name(I);
}

In the path searched through the above path search process, an integrity verification value for the content area is created.

Next, integrity is verified by comparing a preset integrity verification value with the generated integrity verification value.

5 is a diagram showing the configuration of a computer system according to an embodiment.

The self-integrity verification device of the dynamic library according to the embodiment may be implemented in the computer system 1000 such as a computer-readable recording medium.

Computer system 1000 may include one or more processors 1010, memory 1030, user interface input devices 1040, user interface output devices 1050, and storage 1060 that communicate with each other over a bus 1020. can In addition, computer system 1000 may further include a network interface 1070 coupled to network 1080 . The processor 1010 may be a central processing unit or a semiconductor device that executes programs or processing instructions stored in the memory 1030 or the storage 1060 . The memory 1030 and the storage 1060 may be storage media including at least one of volatile media, nonvolatile media, removable media, non-removable media, communication media, and information delivery media. For example, memory 1030 may include ROM 1031 or RAM 1032 .

In addition, an apparatus for self-integrity verification of a dynamic library according to an embodiment of the present invention for achieving the above object includes a memory 1030 in which at least one program is recorded, and a processor 1010 executing the program, , The program generates a check value for a Mach object file (Mach-O File), and determines whether a check value for the Mach object file included in the Mach object file and the check value match. Contains instructions for performing the steps to be checked.

At this time, the Mach object file may include a Header area, a Load Command area, and a Data area.

At this time, a verification value for the Mach object file may be stored in a padding area within the Load Command area.

At this time, when the Mach object file is loaded, a loading time and path of the Mach object file may be searched, and the inspection value for the data area may be generated based on the path.

In this case, the check value may correspond to the HMAC value for the Mach object file.

In this case, the location where the Mach object file is stored may be variably set according to a preset policy.

The specific implementations described herein are examples and do not limit the scope of the present invention in any way. For brevity of the specification, description of conventional electronic components, control systems, software, and other functional aspects of the systems may be omitted. In addition, the connection of lines or connecting members between the components shown in the drawings are examples of functional connections and / or physical or circuit connections, which can be replaced in actual devices or additional various functional connections, physical connection, or circuit connections. In addition, if there is no specific reference such as “essential” or “important”, it may not be a component necessarily required for the application of the present invention.

Therefore, the spirit of the present invention should not be limited to the above-described embodiments and should not be determined, and all scopes equivalent to or equivalently changed from the claims as well as the claims to be described later are within the scope of the spirit of the present invention. will be said to belong to

1000: computer system 1010: processor
1020: bus 1030: memory
1031: Rom 1032: RAM
1040: user interface input device
1050: user interface output device
1060: storage 1070: network interface
1080: Network

Claims (19)

Creating a Mach Object File (Mach-O File);
calculating a verification value for the Mach object file;
storing the calculated verification value in a predetermined location within the Mach object file;
Self-integrity verification method of a dynamic library comprising a. The method of claim 1,
The Mach object file is
A self-integrity verification method of a dynamic library comprising a header area, a load command area, and a data area. The method of claim 2,
The preset location in the Mach object file is
Self-integrity verification method of the dynamic library, characterized in that it corresponds to the padding area in the Load Command area. The method of claim 1,
When the Mach object file is loaded, a check value for the Mach object file is generated, and integrity is verified based on whether the verification value and the check value match. The method of claim 4,
When the Mach object file is loaded, the loading time and path of the Mach object file are searched, and the inspection value for the data area is generated based on the path. The method of claim 5,
The self-integrity verification method of a dynamic library, characterized in that the check value corresponds to the HMAC value for the Mach object file. The method of claim 5,
The self-integrity verification method of a dynamic library, characterized in that the location where the Mach object file is stored is variably set according to a preset policy. generating a test value for a Mach Object File (Mach-O File); and
checking whether a verification value of the Mach object file included in the Mach object file and the check value match;
Self-integrity verification method of a dynamic library comprising a. The method of claim 8,
The Mach object file is
A self-integrity verification method of a dynamic library comprising a header area, a load command area, and a data area. The method of claim 9,
The verification value for the Mach object file is
Self-integrity verification method of the dynamic library, characterized in that stored in the padding area in the load command area. The method of claim 8,
When the Mach object file is loaded, the loading time and path of the Mach object file are searched, and the inspection value for the data area is generated based on the path. The method of claim 11,
The self-integrity verification method of a dynamic library, characterized in that the check value corresponds to the HMAC value for the Mach object file. The method of claim 11,
The self-integrity verification method of a dynamic library, characterized in that the location where the Mach object file is stored is variably set according to a preset policy. a memory in which at least one program is recorded; and
Processor running the program
Including,
said program
generating a test value for a Mach Object File (Mach-O File); and
checking whether a verification value of the Mach object file included in the Mach object file and the check value match;
Self-integrity verification device of a dynamic library, characterized in that it comprises instructions for the execution of. The method of claim 14,
The Mach object file is
A self-integrity verification device of a dynamic library comprising a header area, a load command area, and a data area. The method of claim 15
The verification value for the Mach object file is
Self-integrity verification device of the dynamic library, characterized in that stored in the padding area in the Load Command area. The method of claim 14,
When the Mach object file is loaded, the loading time and path of the Mach object file are searched, and the inspection value for the data area is generated based on the path. The method of claim 17
The self-integrity verification device of the dynamic library, characterized in that the check value corresponds to the HMAC value for the Mach object file. The method of claim 17
The self-integrity verification device of a dynamic library, characterized in that the location where the Mach object file is stored is variably set according to a preset policy.

Images