WO2024063184A1 - Method and apparatus for disarming link in pdf or hwp - Google Patents

Abstract

The present specification relates to a method by which a server disarms a non-portable executable file, comprising: collecting a record from an HWP file on the basis that the format of the non-portable executable file is that of the HWP file; extracting first link information on the basis that the record indicates a text hyper link; extracting second link information on the basis that the record indicates an entity hyper link; extracting third link information on the basis that the record indicates a data link; and disarming the extracted link information, wherein the extracted link information can include the first link information, the second link information, or the third link information.

Description

Method and apparatus for detoxification of LINK in PDF or HWP

This specification relates to a method and device for detoxifying links in PDF and HWP documents.

Advanced Persistent Threat (APT) attacks involve attackers selecting a specific target and continuously utilizing various types of malicious code by applying advanced attack techniques to steal targeted information.

In particular, APT attacks are often not detected in the initial intrusion stage, and often use non-executable (Non-PE: Non-Portable Executable) files containing malicious code.

There is a signature-based inspection method for checking whether non-executable files are malicious. This is a way to check whether a non-executable file contains signatures of malicious code. However, most malicious non-executable files avoid this diagnosis by including malicious code in a script such as JavaScript or macroscript, or in some cases, encoding the script, but the non-executable file itself does not know what script is inside it. It's hard to know. Therefore, it is almost impossible to properly check whether non-executable files are malicious using existing signature-based inspection methods.

The purpose of this specification is to propose a method to detoxify Link while maintaining the overall structure of PDF and HWP.

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

One aspect of the present specification is a method for a server to disarm a non-executable file, including collecting records from the HWP file based on the format of the non-executable file being an HWP file; extracting first link information based on the record indicating a text hyperlink; extracting second link information based on the record indicating an entity hyperlink; extracting third link information based on the record indicating data linkage; and detoxifying the extracted link information, wherein the extracted link information may include the first link information, the second link information, or the third link information.

In addition, based on the fact that the format of the non-executable file is a PDF file, traversing the basic elements of the PDF file and searching for a dictionary type; Checking whether the data type includes a URI entry; and detoxifying the URI entry based on whether the URI entry is included, where the data type may include a URI action object.

Additionally, the step of checking whether the URI entry is included may be based on the “S” key and the “URI” key.

Additionally, the step of detoxifying the URI entry may include maintaining only the Link schema information in the ASCII string value of the “URI” key.

Additionally, the step of detoxifying the extracted link information may include replacing the rest of the extracted link information other than schema information with blank spaces.

In addition, the step of collecting the records includes extracting a Section stream included in BodyText storage of the HWP file; and collecting records of the Section stream.

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

In addition, the step of extracting the first link information includes determining a ctrl ID in the data area based on the Tag ID indicating a control header; determining the command length based on the ctrl ID; and extracting a string representing a link address based on the command length; may include.

Another aspect of the present specification is a server for disarming non-executable files, comprising: a communication unit; Memory; and a processor that functionally controls the communication unit and the memory, wherein the processor collects a record from the HWP file based on the format of the non-executable file being an HWP file, and the record is text. extracting first link information based on the record indicating a hyperlink, extracting second link information based on the record indicating an entity hyperlink, and based on the record indicating a data connection, Third link information is extracted and the extracted link information is rendered harmless, and the extracted link information may include the first link information, the second link information, or the third link information.

According to the embodiment of the present specification, Link can be detoxified while maintaining the overall structure of PDF and HWP.

The effects that can be obtained in this specification are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by those skilled in the art from the description below. .

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

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

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

Figure 4 illustrates a method of detoxification of an HWP file to which this specification can be applied.

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

Figure 6 is an example of a record structure to which this specification can be applied.

Figure 7 is an example of a record of a Section stream to which this specification can be applied.

Figure 8 is an example of a record indicating a text hyperlink to which this specification can be applied.

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

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

Figure 11 illustrates a method for detoxifying 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 embodiments of the present specification and explain technical features of the present specification together with the detailed description.

Hereinafter, embodiments disclosed in the present specification will be described in detail with reference to the attached drawings. However, identical or similar components will be assigned the same reference numbers regardless of reference numerals, and duplicate descriptions thereof will be omitted. The suffixes “module” and “part” for components used in the following description are given or used interchangeably only for the ease of preparing the specification, and do not have distinct meanings or roles in themselves. Additionally, in describing the embodiments disclosed in this specification, if it is determined that detailed descriptions of related known technologies may obscure the gist of the embodiments disclosed in this specification, the detailed descriptions will be omitted. In addition, the attached drawings are only for easy understanding of the embodiments disclosed in this specification, and the technical idea disclosed in this specification is not limited by the attached drawings, and all changes included in the spirit and technical scope of this specification are not limited. , should be understood to include equivalents or substitutes.

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

When a component is said to be "connected" or "connected" to another component, it is understood that it may be directly connected to or connected to the other component, but that other components may exist in between. It should be. On the other hand, when it is mentioned that a component is “directly connected” or “directly connected” to another component, it should be understood that there are no other components in between.

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

In this specification, terms such as “comprise” or “have” are intended to indicate the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, but are not intended to indicate the presence of one or more other features. It should be understood that this does not exclude in advance the possibility of the existence or addition of elements, numbers, steps, operations, components, parts, or combinations thereof.

Additionally, the term “unit” used in the specification refers to a software or hardware component, and the “unit” performs certain roles. However, “wealth” is not limited to software or hardware. The “copy” may be configured to reside on an addressable storage medium and may be configured to run on one or more processors. Thus, as an example, “part” refers to software components, such as object-oriented software components, class components, and task components, processes, functions, properties, procedures, Includes subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided within the components and “parts” may be combined into smaller numbers of components and “parts” or may be further separated into additional components and “parts”.

Additionally, according to an embodiment of the present specification, “unit” may be implemented with a processor and 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, etc. In some contexts, “processor” may refer to an application-specific integrated circuit (ASIC), programmable logic device (PLD), field programmable gate array (FPGA), etc. The term “processor” refers to a combination of processing devices, 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 combination with a DSP core, or any other such combination of configurations. It may also refer to

The term “memory” should be interpreted broadly to include any electronic component capable of storing electronic information. The terms memory include 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, etc. A memory is said to be in electronic communication with a processor if the processor can read information from and/or write information to the memory. The memory integrated into the processor is in electronic communication with the processor.

As used herein, “non-executable file” refers to a file that does not execute on its own, as opposed to an executable file or executable file. For example, non-executable files may be document files such as PDF files, Hangul files, Word files, image files such as JPG files, video files, JavaScript files, HTML files, etc., but are not limited thereto.

Below, with reference to the attached drawings, embodiments will be described in detail so that those skilled in the art can easily implement them. In order to clearly explain the present disclosure in the drawings, parts unrelated to the description may be omitted.

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

In this specification, a server (or cloud server) or client may include a control unit 100 and a communication unit 130. The control unit 100 may include a processor 110 and a memory 120. The processor 110 may execute instructions stored in the memory 120. The processor 110 can 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 multiple processors. When a server or client includes a plurality of processors, at least some of the plurality of processors may be located physically spaced apart from each other. Additionally, the server or client is not limited to this and may be implemented in various known ways.

The communication unit 130 may include one or more modules that enable 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. Additionally, the communication unit 110 may include one or more modules that connect servers or clients to one or more networks.

The control unit 100 may control at least some of the components of the server or client to run the application program stored in the memory 120. Furthermore, the control unit 100 can operate at least two of the components included in the server or client in combination with each other to run the application program.

In this specification, the server may include a reversing engine or/and a CDR engine that provides a CDR service.

Reversing engine

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

For example, a reversing engine can perform the following steps:

1. File analysis: This is the step of analyzing the appearance of the non-executable file itself (e.g., properties, author, creation date, file type). Similar to a general anti-virus program, it is possible to diagnose maliciousness using only the information of the non-executable file itself. You can.

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

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

4. Debugging analysis: This is the step of analyzing vulnerabilities, exploits, etc. by executing and debugging non-executable files. It detects vulnerabilities in the application using the body of the document, tables, fonts, pictures, etc., including macros, hyperlinks, and DDE. It is suitable for

The reversing engine may include a debugging engine that can be used for debugging analysis. The debugging engine can diagnose vulnerabilities that occur in the document input, processing, and output stages by debugging the viewing process of non-executable files. Here, a vulnerability refers to taking advantage of errors, bugs, etc. that occur when an application receives unexpected values from the code (logic) developed by the application developer. Through the vulnerability, an attacker can cause denial of service due to abnormal termination, etc. It can perform malicious actions such as remote code execution.

Content Disarm and Reconstruction (CDR)

The CDR service is a solution that creates a new file by disassembling non-executable files, removing malicious or unnecessary files, and keeping the content as identical as possible to the original.

In other words, Contents Disarm and Reconstruction (CDR) refers to a service that provides customers by creating a safe document by disarming and reconstructing the content in the document, and the files subject to detoxification include all non-executable files (e.g. For example, Word, Excel, PowerPoint, Hangul, PDF) can be targeted, and the content targeted for detoxification can be active content (eg, macros, hyperlinks, OLE objects, etc.).

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

Referring to Figure 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 execution flow is changed to an unintentional one by the developer, resulting in a vulnerability. This can work. The debugging engine automatically debugs the document viewing process, sets breakpoints at specific points related to vulnerabilities, checks specific values related to input values, and determines whether the input value causes a vulnerability or not, thereby diagnosing whether it is malicious.

More specifically, the debugging engine can identify non-executable files and start debugging by running an application to view them. When a module is loaded in the process of viewing a non-executable file, the debugging engine checks whether the module is the target of analysis, and if so, can set a breakpoint at the specified address.

For example, a malicious non-executable file may terminate the application if certain conditions, such as the version of the application or the operating system environment, are not met, or may have branching points that branch to a flow in which no malicious action occurs. The server is analyzed by an analyst in advance and breakpoints can be set at branch points that have this possibility.

In addition, the server can set conditions in relation to the branch point that can continue to run the application without terminating it or lead to a flow in which malicious actions can occur.

If the process stops at the breakpoint point during execution of the application process, the server can detect vulnerabilities according to detection logic and then store the results in an analysis report.

The automated reversing engine included in the server automatically performs and analyzes the above-mentioned steps, and can diagnose and block malicious non-executable files through diagnostic algorithms researched and developed by analysts.

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

Referring to FIG. 3, the server can determine the document format of the non-executable file (S3010). For example, in order to determine the document format of a non-executable file, the server can open the non-executable file and check the signature type in the binary code to determine the format of the document.

For example, each non-executable file has its own unique format, and the basic content of the format is the file signature. File signatures can also be used to distinguish file formats by specifying the specific bytes located at the beginning of the file.

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”.

If the server determines that the format of the non-executable file is a PDF file, it can perform detoxification of the PDF file (S3020), and if it determines that the format of the non-executable file is a HWP file, it can perform detoxification of the HWP file (S3030) ).

Figure 4 illustrates a method of detoxification of an HWP file 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 for detoxifying the HWP file is illustrated.

If you decompress CFB-type files, including HWP 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.

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

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

BodyText - Section stream: Contents such as paragraphs, tables, and drawing objects corresponding to the body of the document can be stored here. 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.

Compressed storage of files: Streams can be compressed (e.g. zlib style) to reduce file size. When decompressed, the contents are the same, and the Section stream is also subject to compression.

Referring again to FIG. 4, the server can perform a detoxification operation according to the HWP link function.

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

type	explanation
text hyperlink	Hyperlink set in text.
object hyperlink	A hyperlink set to an object such as a picture or shape.
data connection	Hyperlink set in text. The way it is displayed in the text is different from a hyperlink.

Information of this link function can be stored in the body area (Section stream). BodyText storage includes Section streams, and the Section stream can be composed of HWP data records. The server can extract the Section stream within the HWP file and detoxify link-related records by traversing all records within the Section stream.

Figure 6 is an example of a record structure to which this specification can be applied.

Figure 6 is an example of a record structure referring to the Hangul 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 is a tag that indicates the type of data that the record represents. Tag ID uses 10 bits, so 0x000 - 0x3FF is possible.

- 0x000 - 0x00F = Used for special purposes rather than general record tags.

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

- 0x200 - 0x3FF = Area that can be used by external applications

(2) Level: In most cases, one object is composed of multiple records, so the concept of “logically related consecutive records” rather than a single record is needed. The level is information to express a logical bundle of related records. All records that make up a stream can be expressed in a hierarchical structure, and the level represents 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 to the record header. In other words, when data exceeds 4095 bytes, the record is expressed as an extended data record.

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

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

Table 2 is an example of a data record of the body (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 the paragraph
HWPTAG_PARA_CHAR_SHAPE	HWPTAG_BEGIN+52	letter shape in paragraph
HWPTAG_PARA_LINE_SEG	HWPTAG_BEGIN+53	Layout of paragraphs
HWPTAG_PARA_RANGE_TAG	HWPTAG_BEGIN+54	Paragraph area tag
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 Appearance
HWPTAG_PAGE_BORDER_FILL	HWPTAG_BEGIN+59	Page 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	square 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	polygonal object
HWPTAG_SHAPE_COMPONENT_CURVE	HWPTAG_BEGIN+67	curved object
HWPTAG_SHAPE_COMPONENT_OLE	HWPTAG_BEGIN+68	OLE object
HWPTAG_SHAPE_COMPONENT_PICTURE	HWPTAG_BEGIN+69	drawing object
HWPTAG_SHAPE_COMPONENT_CONTAINER	HWPTAG_BEGIN+70	container object
HWPTAG_CTRL_DATA	HWPTAG_BEGIN+71	control random 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	note 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 extract the Tag ID from the header of the record and determine the meaning of the header. Here, HWPTAG_BEGIN = 0x010. Figure 7 is an example of a record of a Section stream to which this specification can be applied.

Referring to FIG. 7, the server can parse the first 4 bytes of header information (for example, 0x4200 8001). For example, the server can obtain a Tag ID from the header and determine that the Tag ID means a paragraph header according to Table 2. Based on which record headers indicate paragraph headers, the server can determine the data area.

Table 3 is an example of the operation of the server parsing records of the Section stream.

order	movement
One	- Separate 4 bytes 0x4200 8001 into byte units and place them in reverse order. Byte unit: 42 00 80 01 (16) (2 digits are 1 byte, 1 digit is 4 bits) Reverse arrangement: 01 80 00 42 (16) Bit placement: (Size)0000 0001 1000 (Level)0000 0000 00(Tag ID)00 0100 0010 (2)
2	Tag ID is the lower 10 bits from bits 0 to 9: 00 0100 0010 (2) = 0 4 2 (16) (= 0x042) = 0x010 + 0x032 = 0x010 + 50 (10) => Indicates paragraph header
3	The size of the data area is the upper 12 bits from bits 20 to 310000 0001 1000 (2) = 0x018
4	Level information is 0x0000000 0000 00 (2) = 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. The server can parse the data area into paragraph header data because the Tag ID indicates the paragraph header. Through this operation, the server can collect records of the Section stream. Referring again 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 may start with 0x6B 6C 68 25 (klh%).

Figure 8 is an example of a record indicating a text hyperlink to which this specification can be applied.

Referring to FIG. 8, the server can 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
Arrange in reverse order by byte	04 B0 04 47 (16)
Lay out bit by bit	(Size)0000 0100 1011 (Level)0000 0000 01(Tag ID)00 0100 0111 (2)
Tag ID (lower 10 bits)	00 0100 0111 (2) = 0x047 = 0x010 + 0x37 = 0x010 + 55 (10) = HWPTAG_CTRL_HEADER (Control Header)
Size (upper 12 bits)	0000 0100 1011 (2) = 0x04B
Level	00 0000 0001 (2) = 0x001

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

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

data type	Length (bytes)	explanation
UINT32	4	ctrl ID
UINT	4	Attributes (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] Read the first 4 bytes (820) of the ctrl ID from the data area and place them in reverse order. 6B 6C 68 25 = klh% Because the tag ID is the control header and the ctrl ID is %hlk, the server Recognize the record as a text hyperlink
2	[Property] Read the next 4 bytes (830) from the data area.
3	[Other properties] Read the next 1 byte (840) from the data area.
4	[command length] Read the next 2 bytes (850) from the data area and place them in reverse order. 1C 00 => 00 1C command length is 0x001C = 28 (10)
5	[command] Reads the next {command length - 14} (= 56 - 14 = 42) bytes from the 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. Meanwhile, since the lower 14 bytes of the 56 bytes are option values rather than string information, 56 - 14 = 42 bytes must be read to obtain the link address string. These 42 bytes contain the following two pieces of information. - String for web address + “|” (separator) + string to explain Since the actual data needed is a string for a web address, the server uses “|” among the 42 bytes. The period before the character appears is recognized as a web address string, with “|” 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 again to FIG. 4, the server extracts second link information based on the record indicating an object hyperlink (S4030). Object hyperlinks can be created in the form of HWPTAG_CTRL_DATA (control arbitrary data records) following an object record. For example, an object hyperlink may have the form of a HWPTAG_SHAPE_COMPONENT record + HWPTAG_CTRL_DATA record, and the 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 {control arbitrary data records}. Figure 9 is an example of a record indicating an entity hyperlink to which this specification can be applied.

Referring to FIG. 9, the server can 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
Arrange in reverse order by byte	05 00 0C 57 (16)
Lay out bit by bit	(Size)0000 0101 0000 (Level)0000 0000 11(Tag ID)00 0101 0111 (2)
Tag ID (lower 10 bits)	00 / 0101 /0111 (2) = 0 / 5 / 7 (16) ( = 0x057) = 0x010 + 0x47 = 0x010 + 71 (10) = HWPTAG_CTRL_DATA (Control Random Data)
Size (upper 12 bits)	0000 0101 0000 (2) = 0x050
Level	00 0000 0011 (2) = 0x003

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

4.2. Data records in 'Document Information'

4.2.12. document random data

Obtain item data equal to the number of parameter items.

Table 8 illustrates the parameter set of the HWP specification to which this specification can be applied.

data type	Length (bytes)	explanation
WORD	2	Parameter set ID
INT16	2	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 types (see Table 10)
Parameter Item Type	variable	Parameter item data
total length		variable	4 + variable bytes

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

value	division	data type		explanation
0	PIT_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	Parameter set array
0x8002	PIT_BINDATA	UINT16	Binary data ID

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

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

order	movement
One	[Parameter set ID] Read the first 2 bytes (920) of the parameter set ID from the data area. - 1B 02 => 02 1B
2	[Number of items in the parameter set] Read the next 4 bytes (930) from the data area and place them in reverse order. - 0100 0000 (2) => 0000 0001 (2) = 1 (10) - The number of items in the parameter set is 1.
3	[Parameter Item - Parameter Item ID] Read the next 2 bytes (940) from the data area. - 6F 02 => 02 6F
4	[Parameter item - Parameter item type] 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	[Parameter set ID] Read the next 2 bytes (960) from the data area. - 6F 02 => 02 6F
6	[Number of items in the parameter set] Read the next 4 bytes (0100 0000) from the data area and arrange them in reverse order. - 0100 0000 (2) => 0000 0001 (2) = 1 (10) - The server determines that the number of items in the parameter set is 1.
7	[Parameter Item - Parameter Item ID] Read the next 2 bytes (6502) from the data area. - 65 02 => 02 65
8	[Parameter item - Parameter item type] Read the next 2 bytes (0100) from the data area and arrange them in reverse order. - 01 00 => 00 01 - Since 1 = PIT_BSTR (see Table 10), the server interprets the subsequent data as “string length (2 bytes) + string”.
9	[String length] Read the next 2 bytes (1D00) from the data area and place them in reverse order. - 1D 00 => 00 1D - String length is 0x1D = 29 (10)
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. - Meanwhile, since the lower 14 bytes of the 58 bytes are option values rather than string information, 58 - 14 = 44 bytes must be read to obtain the link address string. These 44 bytes contain the following two pieces of information: - String for web address + “|” (separator) + string to explain Since the actual data needed is a string for a web address, the server uses “|” among the 42 bytes. The period before the character appears is recognized as a web address string. - “|” Because there are no characters, the server recognizes all 44 bytes as a web address string. The server extracts the string “http\://www.google.com” as second link information.

Referring again 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%). Figure 10 is an example of a record indicating data connection to which this specification can be applied.

Referring to FIG. 10, the server can 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
Arrange in reverse order by byte	06 70 04 47 (16)
Lay out bit by bit	(Size)0000 0110 0111 (Level)0000 0000 01(Tag ID)00 0100 0111 (2)
Tag ID (lower 10 bits)	00 0100 0111 (2) = 0x047 = 0x010 + 0x37 = 0x010 + 55 (10) = control header
Size (upper 12 bits)	0000 0110 0111 (2) = 0x067
Level	00 0000 0001 (2) = 0x001

Referring to Table 12, since 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	[ctrl ID] Reads the first 4 bytes (1020) of ctrl ID from the data area. - 6B 6E 75 25 = knu% - %unk if placed in reverse order The server determines that the record indicates data connection because the Tag ID is a control header and the ctrl ID is %unk.
2	[Property] Read the next 4 bytes (1030) from the data area
3	[Other properties] Read the next 1 byte (1040) from the data area.
4	[command length] Read the next 2 bytes (1050) from the data area and place them in reverse order. - 2A 00 => 00 2A command length is 0x002A = 42 (10)
5	The server first reads the next {string length - 14} (= 84 - 14 = 70) bytes (6800~6500) from the data area - because the Command length is 42 and one character has a length of 2 bytes, Actual length is 42*2 =84 bytes. However, because the lower 14 bytes of the 84 bytes are option values rather than string information, the server reads 84 - 14 = 70 bytes to obtain the link address string. These 70 bytes contain the following two pieces of information: - String for web address + “|” (Separator) + String to display Since the actual data needed is a string for the web address, the server uses “|” among the 70 bytes. The period before the character appears is recognized as a web address string. The server extracts the string “http\://www.google.com” as third link information.

Referring again to FIG. 4, the server detoxifies the extracted link information (S4050). For example, the server creates a schema from link information (e.g., first/second/third link information). You can leave only the information and replace the rest with blank spaces (2000). Through this, the entire length of the link information can be maintained as is, and the link information can be rendered harmless with minimal modification.

Figure 11 illustrates a method for detoxifying a PDF file to which this specification can be applied.

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

The server searches for the dictionary type by traversing the basic elements of the PDF file (S1110). For example, the server can traverse obj as the basic element of a PDF file. 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 checking elements inside the page by traversing each page, there may be many exceptions in the actual document, such as Action obj circularly referencing itself, so there is a risk of missing exception handling. .

For example, since PDF frequently references indirect obj, traversing by obj is more stable in terms of time complexity.

Additionally, since one obj can be referenced on multiple pages, the problem of redundant search must also be considered. Since the method of traversing based on obj can traverse all objs of a certain document, searching for all objs in one traversal can be guaranteed.

These objs can have a dictionary type. For example, a dictionary type is one of eight basic data types (Boolean values, Integer and Real numbers, Strings, Names, Arrays, Dictionaries, Streams, and the null object) and consists of a {key}-{value} pair. It can be included as a single entry with a corresponding relationship.

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

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

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.

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

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

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

If essential elements are removed or the URI Action itself is removed, a problem may occur in which the Next Action associated 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-mentioned specification can be implemented as computer-readable code on a program-recorded medium. Computer-readable media includes all types of recording devices that store data that can be read by a computer system. Examples of computer-readable media include HDD (Hard Disk Drive), SSD (Solid State Disk), SDD (Silicon Disk Drive), ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. It also includes those implemented in the form of carrier waves (e.g., transmission via the Internet). Accordingly, the above detailed description should not be construed as restrictive 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 the description has been made above with a focus on services and embodiments, this is only an example and does not limit the present specification, and those skilled in the art will understand that it does not deviate from the essential characteristics of the services and embodiments. It can be seen 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 the differences related to these modifications and applications should be construed as being included in the scope of the present specification as defined in the attached claims.

Claims (9)

1. In how the server disarms non-executable files,

   Based on the format of the non-executable file being an HWP file, collecting records from the HWP file;

   extracting first link information based on the record indicating a text hyperlink;

   extracting second link information based on the record indicating an entity hyperlink;

   extracting third link information based on the record indicating data linkage; and

   Detoxifying the extracted link information;

   Includes,

   The extracted link information is

   A detoxification method comprising the first link information, the second link information, or the third link information.
2. According to paragraph 1,

   Based on the fact that the format of the non-executable file is a PDF file, searching for a dictionary type by traversing basic elements of the PDF file;

   Checking whether the data type includes a URI entry; and

   A step of detoxifying the URI entry based on whether the URI entry is included,

   The above data type is

   A detoxification method containing a URI action object.
3. According to paragraph 2,

   The step of checking whether the URI entry is included is

   Disarming method based on “S” key and “URI” key.
4. According to paragraph 3,

   The step of detoxifying the URI entry is

   Maintaining only Link schema information in the ASCII string value of the “URI” key;

   A method of detoxification, including.
5. According to paragraph 1,

   The step of detoxifying the extracted link information is

   Replacing the rest of the extracted link information except schema information with blank spaces;

   Detoxification method, including.
6. According to clause 5,

   The step of collecting the records is

   Extracting a Section stream included in BodyText storage of the HWP file; and

   collecting records of the Section stream;

   A method of detoxification, including.
7. According to clause 6,

   The step of collecting the records is

   Obtaining a Tag ID from the header of the record; and

   determining a data area based on the Tag ID;

   A detoxification method further comprising:
8. In clause 7,

   The step of extracting the first link information is

   determining a ctrl ID in the data area based on the Tag ID indicating a control header;

   determining the command length based on the ctrl ID; and

   extracting a string representing a link address based on the command length;

   A method of detoxification, including.
9. In a server that disarms non-executable files,

   Ministry of Communications;

   Memory; and

   It includes a processor that functionally controls the communication unit and the memory,

   The processor is

   Based on the format of the non-executable file being an HWP file, a record is collected from the HWP file, and based on the record indicating a text hyperlink, first link information is extracted, and the record is extracting second link information based on indicating an entity hyperlink; extracting third link information based on the record indicating a data connection; detoxifying the extracted link information; Link information includes the first link information, the second link information, or the third link information.

Images