KR102547757B1 - Methods and apparatus for disarming a link in hwp - Google Patents

Abstract

In the present specification, in a method for disarming a non-executable file by a server, based on the fact that the format of the non-executable file is an HWP file, records are collected from the HWP file, and the record is a text hypertext file. Based on the indication of the link, extracting the link information, harmless the extracted link information, and harmless the extracted link information, except for the schema information in the extracted link information, the rest is blank. can be replaced with

Description

Method and device for disarming link in HWP {METHODS AND APPARATUS FOR DISARMING A LINK IN HWP}

This specification relates to a method and apparatus for harmless Link in an HWP document.

In Advanced Persistent Threat (APT) attacks, an attacker sets a specific target and applies advanced attack techniques to continuously utilize various types of malicious codes to steal targeted information.

In particular, APT attacks are often undetectable at the initial intrusion stage, and often use Non-Portable Executable (Non-PE) files containing malicious codes.

As a method for checking whether a non-executable file is malicious, there is a signature-based inspection method. This is a method of checking whether a non-executable file contains a malicious code signature. However, most malicious non-executable files evade this diagnosis by including malicious code in scripts such as JavaScript or macroscript, or by encoding scripts in some cases. It's hard to know. Therefore, it is almost impossible to properly inspect whether a non-executable file is malicious with the existing signature-based inspection method.

The purpose of this specification is to propose a method for harmless Link while maintaining the overall structure of HWP.

The technical problems to be achieved by this specification are not limited to the above-mentioned technical problems, and other technical problems not mentioned are clear to those skilled in the art from the detailed description of the specification below. will be understandable.

One aspect of the present specification is a method for disarming a non-executable file by a server, based on the fact that the format of the non-executable file is an HWP file, collecting a record from the HWP file; extracting link information based on the record indicating a text hyperlink; and harmless the extracted link information. Including, the step of disarming the extracted link information comprises: replacing the rest of the extracted link information with blanks other than schema information; can include

Another aspect of the present specification is a method for disarming a non-executable file by a server, based on the fact that the format of the non-executable file is an HWP file, collecting records from the HWP file step; extracting link information based on the record indicating an object hyperlink; and harmless the extracted link information; Including, the step of disarming the extracted link information comprises: replacing the rest of the extracted link information with blanks other than schema information; can include

Another aspect of the present specification is a method for disarming a non-executable file by a server, based on the fact that the format of the non-executable file is an HWP file, collecting records from the HWP file step; extracting link information based on the record indicating data connection; and harmless the extracted link information. Including, the step of disarming the extracted link information comprises: replacing the rest of the extracted link information with blanks other than schema information; can include

In addition, the collecting of the records may include extracting a Section stream included in BodyText storage of the HWP file; and collecting records of the Section stream; can include

The collecting of the records may include obtaining a Tag ID from a header of the record; and determining a data area based on the Tag ID; may further include.

The extracting of the link information may include determining a ctrl ID in the data area based on the Tag ID indicating a control header; determining a command length based on the ctrl ID; and extracting a string representing a link address based on the length of the command. can include

According to an embodiment of the present specification, link detoxification can be performed while maintaining the entire structure of the HWP.

Effects obtainable in the present specification are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below. .

1 is a diagram showing a server or client related to the present specification.
2 is an example of an abnormal input that can be applied to this specification.
3 illustrates a detoxification method to which the present specification can be applied.
4 illustrates a method of disarming an HWP file to which this specification can be applied.
5 illustrates the structure of a general HWP file to which this specification can be applied.
6 is an example of a record structure to which this specification can be applied.
7 is an example of a record of a Section stream to which this specification can be applied.
8 is an example of a record indicating a text hyperlink to which this specification can be applied.
9 is an example of a record indicating an entity hyperlink to which this specification can be applied.
10 is an example of a record indicating data connection to which this specification can be applied.
11 illustrates a method of disarming a PDF file to which this specification can be applied.
The accompanying drawings, which are included as part of the detailed description to aid understanding of the present specification, provide examples of the present specification and describe technical features of the present specification together with the detailed description.

Hereinafter, the embodiments disclosed in this specification will be described in detail with reference to the accompanying drawings, but the same or similar components are given the same reference numerals regardless of reference numerals, and redundant description thereof will be omitted. The suffixes "module" and "unit" for components used in the following description are given or used together in consideration of ease of writing the specification, and do not have meanings or roles that are distinct from each other by themselves. In addition, in describing the embodiments disclosed in this specification, if it is determined that a detailed description of a related known technology may obscure the gist of the embodiment disclosed in this specification, the detailed description thereof will be omitted. In addition, the accompanying drawings are only for easy understanding of the embodiments disclosed in this specification, the technical idea disclosed in this specification is not limited by the accompanying drawings, and all changes included in the spirit and technical scope of this specification , it should be understood to include equivalents or substitutes.

Terms including ordinal numbers, such as first and second, may be used to describe various components, but the components are not limited by the terms. These terms are only used for the purpose of distinguishing one component from another.

It is understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, but other elements may exist in the middle. It should be. On the other hand, when an element is referred to as “directly connected” or “directly connected” to another element, it should be understood that no other element exists in the middle.

Singular expressions include plural expressions unless the context clearly dictates otherwise.

In this specification, terms such as "comprise" or "having" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, but one or more other features It should be understood that the presence or addition of numbers, steps, operations, components, parts, or combinations thereof is not precluded.

Also, the term “unit” used in the specification means a software or hardware component, and “unit” performs certain roles. However, "unit" is not meant to be limited to software or hardware. A “unit” may be configured to reside in an addressable storage medium and may be configured to reproduce on one or more processors. Thus, as an example, “unit” can refer to components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays and variables. Functionality provided within components and "parts" may be combined into fewer components and "parts" or further separated into additional components and "parts".

Also, according to one embodiment of the present specification, "unit" may be implemented as a processor and a memory. The term “processor” should be interpreted broadly to include general-purpose processors, central processing units (CPUs), microprocessors, digital signal processors (DSPs), controllers, microcontrollers, state machines, and the like. In some circumstances, “processor” may refer to an application specific integrated circuit (ASIC), programmable logic device (PLD), field programmable gate array (FPGA), or the like. The term "processor" refers to a combination of processing devices, such as, for example, a combination of a DSP and a microprocessor, a combination of a plurality of microprocessors, a combination of one or more microprocessors in conjunction with a DSP core, or any other such configuration. may also refer to

The term “memory” should be interpreted broadly to include any electronic component capable of storing electronic information. The term memory includes random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable-programmable read-only memory (EPROM), electrical may refer to various types of processor-readable media, such as erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, and the like. A memory is said to be in electronic communication with the processor if the processor can read information from and/or write information to the memory. Memory integrated with the processor is in electronic communication with the processor.

As used herein, a "non-executable file" is a concept opposite to an executable file or an executable file, and means a file that is not itself executed. For example, the non-executable file may be a PDF file, a Korean file, a document file such as a word file, an image file such as a JPG file, a video file, a JavaScript file, and an HTML file, but is not limited thereto.

Hereinafter, with reference to the accompanying drawings, embodiments will be described in detail so that those skilled in the art can easily carry out the embodiments. In addition, in order to clearly describe the present disclosure in the drawings, parts irrelevant to the description may be omitted.

1 is a diagram showing a server or client related to the present specification.

In this specification, a server (or cloud server) or a client may include a control unit 100 and a communication unit 130. The controller 100 may include a processor 110 and a memory 120 . The processor 110 may execute instructions stored in the memory 120 . The processor 110 may control the communication unit 130 .

The processor 110 may control the operation of the server or client based on instructions stored in the memory 120 . A server or client may include one processor or may include a plurality of processors. When the server or the client includes a plurality of processors, at least some of the plurality of processors may be located at physically separated distances. In addition, the server or client may be implemented in various known ways without being limited thereto.

The communication unit 130 may include one or more modules enabling wireless communication between a server or client and a wireless communication system, between a server or client and another server or client, or between a server or client and an external server. Also, the communication unit 110 may include one or more modules that connect a server or a client to one or more networks.

The controller 100 may control at least some of the components of the server or client in order to drive an application program stored in the memory 120 . Furthermore, the control unit 100 may combine and operate at least two or more of the components included in the server or client to drive the application program.

In this specification, the server may include a reversing engine or/and a CDR engine providing CDR services.

Reversing Engine

The reversing engine is an analysis/diagnostic engine that automates the reverse engineering (reversing) process for malicious non-executable files.

For example, the reversing engine may perform the following steps.

1. File analysis: As a step of analyzing the appearance of the non-executable file itself (eg, attribute, author, date of creation, file type), similar to general vaccine programs, maliciousness can be diagnosed only with the information of the non-executable file itself. can

2. Static analysis: This step is to extract and analyze the data in the non-executable file to determine whether it is normal or malicious. The non-executable file is not executed, and internal data is extracted according to the file structure and compared and analyzed to diagnose maliciousness. there is. This may be suitable for macros, URL extraction analysis, and the like.

3. Dynamic analysis: This is a step of analyzing behaviors while executing and monitoring non-executable files to determine whether they are malicious. It is easy to detect malicious behaviors using normal functions such as macros, hyperlinks, and DDE.

4. Debugging Analysis: This step analyzes vulnerabilities and exploits by executing and debugging non-executable files. Detects vulnerabilities of applications using text, tables, fonts, pictures, etc. in documents, including macros, hyperlinks, and DDE. suitable for doing

The reversing engine may include a debugging engine that may be used for debugging analysis. The debugging engine can diagnose vulnerabilities occurring in document input, processing, and output stages by debugging the process of reading non-executable files. Vulnerability here refers to the use of errors and bugs that occur when an application program receives an unexpected value from the code (logic) developed by the application developer. Malicious actions such as remote code execution can be executed.

Content Disarm and Reconstruction (CDR)

The CDR service is a solution that disassembles non-executable files, removes malicious or unnecessary files, and creates new files by making the contents the same as the original as much as possible.

In other words, Contents Disarm and Reconstruction (CDR) means a service that disarms and reconstructs the contents in a document to create a safe document and provides it to customers. For example, Word, Excel, PowerPoint, Hangul, PDF) may be targeted, and the harmless target content may be active content (eg, macro, hyperlink, OLE object, etc.).

2 is an example of an abnormal input that can be applied to this specification.

Referring to FIG. 2, when an application program receives an abnormal value (for example, when the input value exceeds the normal range of 2) through a non-executable file, the application program is changed into an execution flow unintended by the developer and thus vulnerable. this can work. The debugging engine automatically debugs the document browsing process, sets a breakpoint at a specific point related to the vulnerability, checks a specific value related to the input value, determines whether the input value is a value that causes a vulnerability, and diagnoses whether the input value is malicious.

More specifically, the debugging engine can start debugging by identifying non-executable files and running an application to view them. If a module is loaded while viewing a non-executable file, the debugging engine checks whether the module is an analysis target module, and if it is an analysis target, it can set a breakpoint at a designated address.

For example, a malicious non-executable file may have branching points at which an application program is terminated or branched into a flow in which no malicious activity occurs unless a specific condition such as an application version or an operating system environment is satisfied. The server can set a breakpoint at a divergence point that has been previously analyzed by an analyst and has this possibility.

In addition, the server may set conditions associated with a corresponding branching point to continuously execute the application program without terminating or lead to a flow in which a malicious action may occur.

If the process stops at the corresponding breakpoint while the process of the application program is running, the server may perform a step of detecting whether or not there is a vulnerability according to the detection logic and then storing the result in an analysis report.

The automated reversing engine included in the server can analyze and diagnose malicious non-executable files through a diagnosis algorithm researched and developed by an analyst by automatically performing and analyzing the above steps.

3 illustrates a detoxification method to which the present specification can be applied.

Referring to FIG. 3 , the server may determine the document format of the non-executable file (S3010). For example, in order to determine the document format of the non-executable file, the server may open the non-executable file and confirm the format of the document by checking the signature type on the binary code.

For example, non-executable files each have a unique format, and the basic content of the format is a file signature. In the file signature, specific bytes located at the beginning of the file can also be used to identify the file format.

For example, an HWP file may have a signature of “D0 CF 11 E0 A1 B1 1A E1”, and a PDF file may have a signature of “25 50 44 46”.

When the server determines that the format of the non-executable file is a PDF file, the server detoxifies the PDF file (S3020). ).

* Figure 4 illustrates a method of harmless HWP files to which this specification can be applied.

Referring to FIG. 4, when the server determines that the format of the non-executable file is an HWP file, a method of disarming the HWP file is illustrated.

After unzipping HWP files and CFB-type files, you can check the directory and file structure. At this time, the directory type is called storage, and the file type is called stream.

5 illustrates the structure of a general HWP file to which this specification can be applied.

Referring to FIG. 5, BodyText may include a Section stream.

BodyText - Section stream: This can store contents such as paragraphs, tables, and drawing objects corresponding to the body of the document. Link information can also be stored in the Section stream. Depending on the body section of the HWP file, it can be divided into Section0, Section1, etc.

File compressed storage: Streams can be compressed (eg zlib) to reduce file size. When decompressing, the contents are the same, and the section stream is also subject to compression.

Referring back to FIG. 4 , the server may perform a harmless operation according to the HWP link function.

Table 1 is an example of HWP link functions to which this specification can be applied.

type explanation text hyperlink Hyperlinks set in text. object hyperlink A hyperlink set to an object, such as a picture or shape. data connection Hyperlinks set in text.
Different from hyperlinks in how they appear in the text.

Information on this link function can be stored in the body area (Section stream). Section streams are included in the BodyText storage, and the Section stream can be composed of HWP data records. The server can extract the section stream in the HWP file and harmless link-related records by traversing all records in the section stream. 6 is an example of a record structure to which this specification can be applied.

6 is an example of a record structure referring to the Korean document file structure 5.0 (Hwp Document File Formats 5.0), revision 1.3:20181108 document (HWP specification).

The size of the record header is 32 bits and consists of TagID (10 bits), Level (10 bits), and Size (12 bits).

(1) Tag ID: This tag indicates the type of data indicated by the record. Since 10 bits are used for Tag ID, it is possible from 0x000 to 0x3FF.

- 0x000 - 0x00F = Used for special purposes, not general record tags.

- 0x010 - 0x1FF = Area reserved for internal use by Korean characters (HWPTAG_BEGIN = 0x010)

- 0x200 - 0x3FF = Area available for use by external applications

(2) Level: Since it is common for one object to be composed of several records, the concept of "logically related consecutive records" is needed rather than a single record. A level is information for expressing a logical grouping of related records. All records constituting a stream can be expressed in a hierarchical structure, and a level indicates the depth in this hierarchical structure.

(3) Size: Indicates the length of the data area in bytes. When all 12 bits are 1, the length of the data area is 4095 bytes or more. In this case, a DWORD indicating the length is added consecutively to the record header. That is, when the data is 4095 bytes or more, the record is expressed like an extended data record.

Referring back to FIG. 4 , the server collects records from the HWP file (S4010).

For example, a server can collect records from the Section stream in BodyText storage.

Table 2 is an example of a data record of BodyText to which this specification can be applied.

Tag ID Value explanation HWPTAG_PARA_HEADER HWPTAG_BEGIN+50 paragraph header HWPTAG_PARA_TEXT HWPTAG_BEGIN+51 the text of a paragraph HWPTAG_PARA_CHAR_SHAPE HWPTAG_BEGIN+52 the shape of the text in a paragraph HWPTAG_PARA_LINE_SEG HWPTAG_BEGIN+53 paragraph layout HWPTAG_PARA_RANGE_TAG HWPTAG_BEGIN+54 area tags in paragraphs HWPTAG_CTRL_HEADER HWPTAG_BEGIN+55 control header HWPTAG_LIST_HEADER HWPTAG_BEGIN+56 paragraph list header HWPTAG_PAGE_DEF HWPTAG_BEGIN+57 paper settings HWPTAG_FOOTNOTE_SHAPE HWPTAG_BEGIN+58 footnote/endnote shape HWPTAG_PAGE_BORDER_FILL HWPTAG_BEGIN+59 side border/background HWPTAG_SHAPE_COMPONENT HWPTAG_BEGIN+60 individual HWPTAG_TABLE HWPTAG_BEGIN+61 table object HWPTAG_SHAPE_COMPONENT_LINE HWPTAG_BEGIN+62 straight object HWPTAG_SHAPE_COMPONENT_RECTANGLE HWPTAG_BEGIN+63 rectangle object HWPTAG_SHAPE_COMPONENT_ELLIPSE HWPTAG_BEGIN+64 ellipse object HWPTAG_SHAPE_COMPONENT_ARC HWPTAG_BEGIN+65 arc object HWPTAG_SHAPE_COMPONENT_POLYGON HWPTAG_BEGIN+66 polygon object HWPTAG_SHAPE_COMPONENT_CURVE HWPTAG_BEGIN+67 curve object HWPTAG_SHAPE_COMPONENT_OLE HWPTAG_BEGIN+68 OLE object HWPTAG_SHAPE_COMPONENT_PICTURE HWPTAG_BEGIN+69 figure object HWPTAG_SHAPE_COMPONENT_CONTAINER HWPTAG_BEGIN+70 container object HWPTAG_CTRL_DATA HWPTAG_BEGIN+71 control arbitrary data HWPTAG_EQEDIT HWPTAG_BEGIN+72 formula object RESERVED HWPTAG_BEGIN+73 reservation HWPTAG_SHAPE_COMPONENT_TEXTART HWPTAG_BEGIN+74 nice writing HWPTAG_FORM_OBJECT HWPTAG_BEGIN+75 form object HWPTAG_MEMO_SHAPE HWPTAG_BEGIN+76 memo shape HWPTAG_MEMO_LIST HWPTAG_BEGIN+77 memo list header HWPTAG_CHART_DATA HWPTAG_BEGIN+79 chart data HWPTAG_VIDEO_DATA HWPTAG_BEGIN+82 video data HWPTAG_SHAPE_COMPONENT_UNKNOWN HWPTAG_BEGIN+99 Unknown

Referring to Table 2, the server can determine the meaning of the header by extracting the Tag ID from the header of the record. Here, it may be HWPTAG_BEGIN = 0x010. 7 is an example of a record of a Section stream to which this specification can be applied. Referring to FIG. 7 , the server may parse the first 4 bytes of header information (eg, 0x4200 8001). For example, the server may obtain a Tag ID from the header and determine that the Tag ID means a paragraph header according to Table 2. Based on the header of the record indicating the paragraph header, the server can determine the data area.

Table 3 is an example of how the server parses records of the Section stream.

order movement One - Separate 4 bytes 0x4200 8001 into bytes and arrange them in reverse order Byte unit: 42 00 80 01 ₍₁₆₎ (2 digits are 1 byte, 1 digit is 4 bits)
Arranged in reverse order: 01 80 00 42 ₍₁₆₎
Bit arrangement: (Size)0000 0001 1000 (Level)0000 0000 00(Tag ID)00 0100 0010 ₍₂₎ 2 Tag ID is the lower 10 bits from bits 0 to 9 00 0100 0010 ₍₂₎
= 0 4 2 ₍₁₆₎ (= 0x042)
= 0x010 + 0x032 = 0x010 + 50 ₍₁₀₎ => indicates paragraph header 3 The size of the data area is the upper 12 bits from bit 20 to 31 0000 0001 1000 ₍₂₎ = 0x018 4 Level information is 0x0000000 0000 00 ₍₂₎ = 0x000

The server can determine the data area through the Size value. For example, the server may determine the data area 720 after the header area 710 . Since the Tag ID indicates the paragraph header, the server can parse the data area into paragraph header data. Through this operation, the server can collect records of the Section stream. Referring back to FIG. 4 , the server extracts first link information based on the record indicating a text hyperlink (S4020). For example, if the Tag ID indicates HWPTAG_CTRL_HEADER (control header) in the header information of the record, the server may determine that the record indicates a hyperlink. In this case, the data area can start with 0x6B 6C 68 25 (klh%). 8 is an example of a record indicating a text hyperlink to which this specification can be applied.

Referring to FIG. 8 , the server may analyze header information 810 of a record indicating a text hyperlink.

Table 4 is an example of server header information analysis.

type value header 0x4704 B004 Reverse order by byte 04 B0 04 47 ₍₁₆₎ batch by bit (Size)0000 0100 1011 (Level)0000 0000 01(Tag ID)00 0100 0111 ₍₂₎ Tag ID (Lower 10 bits) 00 0100 0111 ₍₂₎
= 0x047
= 0x010 + 0x37
= 0x010 + 55 ₍₁₀₎
= HWPTAG_CTRL_HEADER (control header) Size (upper 12 bits) 0000 0100 1011 ₍₂₎
= 0x04B Level 00 0000 0001 ₍₂₎
= 0x001

Referring to Table 4, since the Tag ID indicates the control header, the server can determine the data area based on the specification of the control header.

Table 5 is an example of control header specifications to which this specification can be applied.

data type length (bytes) explanation UINT32 4 ctrl ID UINT 4 Properties (see Table 153) BYTE One Other properties WORD 2 command length (len) WCHAR array[len] 2Хlen command (unique information to be processed for each field type) UINT32 4 id (unique ID within the document) total length variable 15 + (2Хlen)

Table 6 is an example of extracting first link information of a text hyperlink to which this specification can be applied.

order movement One [ctrl ID] reads the first 4 bytes (820) of ctrl ID from the data area and arranges them in reverse order
6B 6C 68 25 = klh%
Server because Tag ID is control header and ctrl ID is %hlk ,
Recognize the record as a text hyperlink 2 [Attribute] Read the next 4 bytes (830) from the data area. 3 [Other properties] Read the next 1 byte (840) from the data area. 4 Read the next 2 bytes (850) from the [command length] data area and place them in reverse order
1C 00 => 00 1C
command length is 0x001C = 28 ₍₁₀₎ 5 Read the next {command length - 14} _{(= 56 - 14 = 42)} bytes from the [command] data area. (6800 7400 7400 7000 5C00 3A00 2F00 2F00 7700 7700 7700 2E00 6E00 6100 7600 6500 7200 2E00 6300 6F00 6D00)
Since the command length is 28 and one character is 2 bytes long, the actual length is 28*2 =56 bytes.
On the other hand, since the lower 14 bytes of 56 bytes are not text string information but option values, 56 - 14 = 42 bytes are read to obtain the text string of the link address.
These 42 bytes contain the following two pieces of information.
- String for web address + “|” (delimiter) + string to describe
Since the data actually needed is a string for a web address, the server uses “|” of 42 bytes. Recognizes until a character appears as a web address string, “|” in the string If there are no characters, the server recognizes the entire 42 bytes as a web address string.
Therefore, the server extracts the “http\://www.naver.com” string as the first link information.

Referring back to FIG. 4 , the server extracts second link information based on the fact that the record indicates an entity hyperlink (S4030). Object hyperlinks can be created in the form of HWPTAG_CTRL_DATA (control any data record) followed by an object record. For example, an object hyperlink may have a HWPTAG_SHAPE_COMPONENT record + HWPTAG_CTRL_DATA record form, and second link information may be included in the HWPTAG_CTRL_DATA record. After checking the record structure of the object hyperlink in the section stream, the server can harm {control any data record}.

9 is an example of a record indicating an entity hyperlink to which this specification can be applied.

Referring to FIG. 9 , the server may analyze header information 910 of a record indicating a text hyperlink.

Table 7 is an example of server header information analysis.

type value header 0x570C 0005 Reverse order by byte 05 00 0C 57 ₍₁₆₎ batch by bit (Size)0000 0101 0000 (Level)0000 0000 11(Tag ID)00 0101 0111 ₍₂₎ Tag ID (Lower 10 bits) 00/0101/0111 ₍₂₎
= 0/5/7 ₍₁₆₎ ( = 0x057)
= 0x010 + 0x47
= 0x010 + 71 ₍₁₀₎
= HWPTAG_CTRL_DATA (control random data) Size (upper 12 bits) 0000 0101 0000 ₍₂₎
= 0x050 Level 00 0000 0011 ₍₂₎
= 0x003

Based on the HWP specification, the server can determine the data area in any data record of the control.

4. Data record

4.2. Data record in 'document information'

4.2.12. document random data

Item data is obtained as many as the number of parameter items.

Table 8 illustrates parameter sets of HWP specifications to which this specification can be applied.

data type length (bytes) explanation WORD 2 Parameter set ID INT16 2 The number of items in the parameter set (n) Parameter Item VariableХn Parameter items (see Table 9) total length variable 4 + (variableХn) bytes

Table 9 illustrates parameter items of the HWP specification to which this specification can be applied.

data type length (bytes) explanation WORD 2 Parameter Item ID WORD 2 Parameter Item Type (See Table 10) Parameter Item
Type variable Parameter item data total length variable 4 + variable bytes

Table 10 illustrates parameter item types of HWP specifications to which this specification can be applied.

value division data type explanation 0 PI_NULL UINT NULL One PIT_BSTR WORD string length (slen) WCHAR array[len] string 2 PIT_I1 UINT INT8 3 PIT_I2 UINT INT16 4 PIT_I4 UINT INT32 5 PIT_I UINT INT 6 PIT_UI1 UINT UINT8 7 PIT_UI2 UINT UINT16 8 PIT_UI4 UINT UINT32 9 PIT_UI UINT UINT 0x8000 PIT_SET Parameter Set parameter set 0x8001 PIT_ARRAY INT16 number of parameter sets ParameterArray array of parameter sets 0x8002 PIT_BINDATA UINT16 binary data id

The server may parse the data area by referring to Tables 8 to 10.

Table 11 is an example of extracting second link information of an object hyperlink to which this specification can be applied.

order movement One Read the first 2 bytes (920) of the parameter set ID from the [Parameter Set ID] data area.
- 1B 02 => 02 1B 2 Read the next 4 bytes (930) from [the number of items in the parameter set] data area and place them in reverse order
- 0100 0000 ₍₂₎ => 0000 0001 ₍₂₎ = 1 ₍₁₀₎
- The number of items in the parameter set is 1 3 Read the next 2 bytes (940) from [Parameter item - Parameter item ID] data area
- 6F 02 => 02 6F 4 [Parameter item - type of parameter item] Read the next 2 bytes (950) from the data area and place them in reverse order
- 00 80 => 80 00
- Since it is 0x8000, the server interprets the subsequent data as a parameter set. 5 Read the next 2 bytes (960) from the [Parameter Set ID] data area.
- 6F 02 => 02 6F 6 Read the next 4 bytes (0100 0000) from the [number of items in the parameter set] data area, and place them in reverse order
- 0100 0000 ₍₂₎ => 0000 0001 ₍₂₎ = 1 ₍₁₀₎
- The server determines the number of items in the parameter set as one 7 Read the next 2 bytes (6502) from [Parameter item - Parameter item ID] data area
- 65 02 => 02 65 8 [Parameter item - type of parameter item] Read the next 2 bytes (0100) from the data area and place them in reverse order
- 01 00 => 00 01
- Since 1 = PIT_BSTR (refer to Table 10), the server interprets the subsequent data as “string length (2 bytes) + character string” 9 Read the next 2 bytes (1D00) from the [string length] data area and place them in reverse order
- 1D 00 => 00 1D
- String length is 0x1D = 29 ₍₁₀₎ 10 [string] The server reads the next {string length - 14} _{(= 58 - 14 = 44)} bytes (6800 ~ 6D00) from the data area
- Since the command length is 29 and one character has a length of 2 bytes, the actual length is 29*2 =58 bytes
- On the other hand, since the lower 14 bytes of 58 bytes are not text string information but option values, 58 - 14 = 44 bytes are read to obtain the text string of the link address.
These 44 bytes contain two pieces of information:
- String for web address + “|” (delimiter) + string to describe
Since the data actually needed is a string for a web address, the server uses “|” of 42 bytes. Recognizes until a character appears as a web address string
- “|” Since there are no characters, the server recognizes the entire 44 bytes as a web address string.
The server extracts the “http\://www.google.com” string as the second link information.

Referring back to FIG. 4 , the server extracts third link information based on the record indicating data connection (S4040). For example, a data link is a control header tag, just like a text hyperlink, and the ctrl ID can have the value %unk (unknown field). More specifically, in the header information of the record indicating data connection, the Tag ID is HWPTAG_CTRL_HEADER (control header), and the data area can start with 0x6B 6E 75 25 (knu%).

10 is an example of a record indicating data connection to which this specification can be applied.

Referring to FIG. 10 , the server may analyze header information 1010 of a record indicating a text hyperlink.

Table 12 is an example of server header information analysis.

type value header 0x4704 7006 Reverse order by byte 06 70 04 47 ₍₁₆₎ batch by bit (Size)0000 0110 0111 (Level)0000 0000 01(Tag ID)00 0100 0111 ₍₂₎ Tag ID (Lower 10 bits) 00 0100 0111 ₍₂₎
= 0x047
= 0x010 + 0x37
= 0x010 + 55 ₍₁₀₎
= control header Size (upper 12 bits) 0000 0110 0111 ₍₂₎
= 0x067 Level 00 0000 0001 ₍₂₎
= 0x001

Referring to Table 12, since the Tag ID (0x047) is a control header, the server can interpret the record based on the specifications in Table 5.

Table 13 is an example of third link information extraction of data connection to which this specification can be applied.

order movement One Read the first 4 bytes (1020) of ctrl ID from [ctrl ID] data area
- 6B 6E 75 25 = knu%
- If placed in reverse order, %unk
Since the tag ID is the control header and the ctrl ID is %unk, the server determines that the record indicates data connection. 2 [Attribute] Read the next 4 bytes (1030) from the data area 3 [Other properties] Read the next 1 byte (1040) from the data area 4 Read the next 2 bytes (1050) from the [command length] data area and place them in reverse order
- 2A 00 => 00 2A
command length is 0x002A = 42 ₍₁₀₎ 5 The server first reads the next {string length - 14} _{(= 84 - 14 = 70)} bytes (6800~6500) from the data area- Since the command length is 42 and one character has a length of 2 bytes, The actual length is 42*2 =84 bytes. However, since the lower 14 bytes of 84 bytes are not string information but option values, the server reads 84 - 14 = 70 bytes to find the string of link address.
These 70 bytes contain two pieces of information:
- String for web address + “|” (delimiter) + string to display
Since the data actually needed is a string for the web address, the server uses “|” of 70 bytes. Recognizes until a character appears as a web address string.
The server extracts “http\://www.google.com” string as third link information.

Referring back to FIG. 4, the server detoxifies the extracted link information (S4050). Only information is left, and the rest can be replaced with blanks (2000). Through this, the entire length of the link information can be maintained as it is, and the link information can be harmless with minimal modification.

11 illustrates a method of disarming a PDF file to which this specification can be applied.

Referring to FIG. 11, when the server determines that the format of a non-executable file is a PDF file, a method of disarming a PDF file is illustrated.

The server searches for a dictionary type by traversing based on basic elements of the PDF file (S1110). For example, the server can traverse based on obj as a primitive of PDF files. Depending on the value set in obj, the actual role and function of the element can be defined.

In the case of the general method of traversing based on each page and checking the elements inside the page, there can be many exceptions such as Action obj circularly referencing itself in the actual document, so there is a risk of missing exception handling. .

For example, since PDF frequently refers to indirect obj, traversing based on obj is stable in terms of time complexity.

Also, since one obj can be referenced from multiple pages, the problem of duplicate search must be considered. Since the traversal method based on obj can traverse all objs of a certain document, it is guaranteed to search all objs with one traversal.

This obj can have a dictionary type. For example, the dictionary type is one of eight primitive data types (Boolean values, Integer and Real numbers, Strings, Names, Arrays, Dictionaries, Streams, and the null object), which is a {key}-{value} pair. It can be included as one entry having a correspondence relationship.

The server checks whether a URI (Uniform Resource Identifier) entry is included in the searched data type (S1120).

For example, a datatype can contain a URI action object. URI Action is a Dictionary type, and includes S and URI as required elements (eg << /S URI /URI ( https://www.seculetter.com) >>). The server can check the URI entry based on whether S and the URI key are included.

Table 14 is an example of S and URI keys to which this specification can be applied.

Key Type Value S name (Required)
The type of action that this dictionary describes; shall be URI for a URI action. URI ASCII string (Required) The uniform resource identifier to resolve, encoded in 7-bit ASCII.

Based on the fact that the URI entry is included, the server detoxifies the URI entry (S1130). For example, the server can leave only Link schema information in the ASCII string value of the URI key.

Table 15 is an example of URI entry harmonization to which this specification can be applied.

before detoxification After detoxification <<
/S URI
/URI ( https://www.seculetter.com)
/Next 10 0 R
>> <<
/S URI
/URI (https://)
/Next 10 0 R
>>

If an essential element is removed or the URI Action itself is removed, a problem may occur in which the Next Action operation connected with the URI Action is not performed. thus. The server performs detoxification by minimally modifying only the parts that are actually problematic. The server can repeatedly detoxify URI entries for other basic elements. The above specification can be implemented as computer readable code on a medium on which a program is recorded. A computer-readable medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include Hard Disk Drive (HDD), Solid State Disk (SSD), Silicon Disk Drive (SDD), ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. , and also includes those implemented in the form of a carrier wave (eg, transmission over the Internet). Accordingly, the above detailed description should not be construed as limiting in all respects and should be considered illustrative. The scope of this specification should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of this specification are included in the scope of this specification.

In addition, although services and embodiments have been described above, this is only an example and does not limit the present specification, and those skilled in the art to which this specification belongs will not deviate from the essential characteristics of the present service and embodiments. It will be appreciated that various modifications and applications not exemplified above are possible. For example, each component specifically shown in the embodiments can be modified and implemented. And differences related to these modifications and applications should be construed as being included in the scope of the present specification as defined in the appended claims.

Claims (6)

In the method for the server to disarm non-executable files,
Extracting a Section stream included in BodyText storage of the HWP file based on the fact that the format of the non-executable file is an HWP file;
Collecting records of the Section stream;
obtaining a Tag ID from a header of the record;
determining a data area based on the Tag ID;
determining a ctrl ID in the data area;
determining a command length in the data area based on the Tag ID and the ctrl ID indicating a text hyperlink;
Extracting a string representing a link address based on the length of the command; and
Replacing the remainder of the extracted character string with blanks other than schema information;
Including, detoxification method.
In the method for the server to disarm non-executable files,
Extracting a Section stream included in BodyText storage of the HWP file based on the fact that the format of the non-executable file is an HWP file;
Collecting records of the Section stream;
obtaining a Tag ID from a header of the record;
determining a data area based on the Tag ID;
determining a command length in the data area based on the Tag ID indicating an object hyperlink;
Extracting a string representing a link address based on the length of the command; and
Replacing the remainder of the extracted character string with blanks other than schema information;
Including, detoxification method.
In the method for the server to disarm non-executable files,
Extracting a Section stream included in BodyText storage of the HWP file based on the fact that the format of the non-executable file is an HWP file;
Collecting records of the Section stream;
obtaining a Tag ID from a header of the record;
determining a data area based on the Tag ID;
determining a ctrl ID in the data area;
determining a command length in the data area based on data linking indicated by the Tag ID and the ctrl ID;
Extracting a string representing a link address based on the length of the command; and
Replacing the remainder of the extracted character string with blanks other than schema information;
Including, detoxification method.

delete delete delete

Images