KR102548779B1 - Methods and apparatus for extracting and inspecting document files inserted into documents in ms-cfb format - Google Patents

Abstract

In the present specification, a method for a server to extract and examine a document file inserted into a CFB (Compound File Binary) format document includes: checking whether there is an object inserted document in the CFB format document; extracting the object-embedded document based on a result of the inspection; and adding the extracted document as a document to be inspected. and the CFB format document may include an MS-DOC format document or an XLS format document.

Description

Method for extracting and examining document files inserted into documents in MS-CFB format and device therefor

The present specification relates to a method and apparatus for extracting and examining a document file inserted into a document in the MS-CFB (Compound File Binary: a binary-based file format stored in a format in which multiple files and folders are stored in one file) format.

In the Advanced Persistent Threat (APT) attack, an attacker sets a specific target and applies advanced attack techniques to continuously utilize various types of malicious codes to steal target 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 rather than Portable Executable (PE) files.

A non-executable file is a concept opposite to an executable file, and means a file that is not executed by itself. Examples of non-executable files include document files such as word files, Excel files, Hangul files, and PDF files, image files, video files, JavaScript files, and HTML files. The reason why non-executable files containing malicious codes are frequently used in APT attacks is that applications that execute non-executable files basically have some level of security vulnerability. In addition, if the malicious code is included in the non-executable file, the modified malicious code can be easily created by changing the file.

In particular, when a document of the same format is specified using object insertion in a MS-CFB format document, simple extraction of the inserted document may not be possible.

For example, a complete MS-CFB format file must contain the actual data of the file and the information linking it to the MS-CFB structure. In the inserted MS-CFB document, all existing connection information disappears and only the actual data of the file is included as listed in the upper document, making it impossible to detect the danger of the inserted file.

The purpose of this specification is to propose a method for extracting and examining a document file inserted into a document in MS-CFB format.

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 a server to extract and inspect a document file inserted into a CFB (Compound File Binary) format document, comprising: checking whether there is an entity-embedded document in the CFB format document; extracting the object-embedded document based on a result of the inspection; and adding the extracted document as a document to be inspected. and the CFB format document may include an MS-DOC format document or an XLS format document.

In addition, the step of extracting the entity-embedded document may include acquiring directory entries related to the entity-embedded document; based on the directory entries, generating a first compound file header; based on the directory entries, creating a sector chain; connecting the obtained directory entries in a tree structure; generating a CFB connection structure based on the first composite file header and the sector chain; and generating document extraction data based on the CFB connection structure. can include

In addition, the sector chain may be based on Mini FAT Sector, Directory Sector, User-defined data, FAT Sector, and DIFAT Sector.

Also, the sector chain may be divided into a normal sector chain or a mini sector chain based on the Mini Stream Cutoff Size of the composite file header.

Also, the generating of the document extraction data may include recording the composite file header; Recording User-data of Mini Fat; Recording user-data of FAT; Recording a Directory Entry; writing the mini-sector chain; and recording the sector chain; can include

Another aspect of the present specification is a server for extracting and examining a document file inserted into a CFB (Compound File Binary) format document, comprising: a communication unit; Memory; and a processor functionally controlling the communication unit and the memory. The processor checks whether there is an entity-embedded document in the CFB format document, extracts the entity-embedded document based on the result of the inspection, and adds the extracted document as a document to be inspected, , The CFB format document may include an MS-DOC format document or an XLS format document.

According to an embodiment of the present specification, a document file inserted into a document of MS-CFB format can be extracted and inspected.

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 is an example of an object insertion document to which the present specification can be applied.
4 and 5 are examples of MS-CFB connection structures to which the present specification can be applied.
6 is an embodiment of a server to which this specification can be applied.
7 is an example of object inserted document extraction to which the present specification can be applied.
8 illustrates a composite file header to which this specification can be applied.
9 is an example of storage area allocation to which the present specification can be applied.
10 is an example of sectors of a mini Fat array to which the present specification can be applied.
11 is an example of a sector of a directory entry arrangement to which the present specification can be applied.
12 is an example of a user-defined data sector chain to which this specification can be applied.
13 is an example of sectors of a FAT arrangement to which this specification can be applied.
14 illustrates a sector of a DIFAT arrangement 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 step is to determine whether or not the non-executable file is malicious by reading and monitoring the non-executable file through an application program including an editor and reader, and analyzing the behavior while monitoring it. Detecting malicious behavior using normal functions such as macros, hyperlinks, and DDE easy to do

4. Debugging analysis: This step analyzes vulnerabilities and exploits by reading 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 is an example of an object insertion document to which the present specification can be applied.

Referring to FIG. 3, among MS-CFB format documents, MS-Word (eg, attached.doc) inserts an object of a file (eg, attachment.doc) and XLS (eg, ppt_in_xls.xls) ) exemplifies object insertion in a file.

Documents in MS-CFB format can be expressed in a tree structure. For example, data files can be placed under the Root dictory of the Tree structure. More specifically, when the document to be inserted is MS-Word, one ObjectPool directory is created under the Root dictory, and a directory (for example, _1729593587) related to a file to be inserted as an object can be additionally created as a subdirectory. All data 3000 of a file (eg, attachment.doc) inserted into a subdirectory may be stored.

A plurality of files can be object-inserted in the same way, and another file can be object-inserted into the object-embedded file by making the directory related to the object-embedded file the root directory and overlapping in the same way.

In more detail, the ObjectPool directory corresponds to a file into which an object is inserted, and may include a directory related to a file into which an object is inserted. Accordingly, a directory related to a file into which an object is inserted may be a data area of a file into which an object is inserted.

That is, when there are N object inserted files, N directories of the same format may be created in the same location as a directory related to an object inserted file such as _1729597664.

If another file is inserted into the object inserted file, the depth may increase again in the form of ObjectPool -> _0000000000 at the child level of the directory related to the object inserted file, such as _1729597664.

If the inserted document is XLS, only a 1-depth directory of MBD000***** format is created like MBD0005229D under the Root dictory, and the file inserted in the directory related to the object inserted file of MBD000***** format (3000 ) can all be stored.

If there are N object inserted files, N directories of the same type can be created in the same location as the directory related to the MBD000***** type of object inserted file.

If another file is object-embedded inside the object-embedded file, the depth of the sub-directory may increase again at the child level of the directory related to the object-embedded file, such as the MBD000***** format.

4 and 5 are examples of MS-CFB connection structures to which the present specification can be applied.

CFB specifications are being shared through the web.

In relation to this, specifications that can be applied to this specification are as follows.

([MS-CFB]: Compound File Binary File Format, https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cfb/53989ce4-7b05-4f8d-829b-d08d6148375b)

One Introduction

This document specifies a new structure called OLE (Object Linking and Embedding) or COM (Component Object Model) structured storage implemented as files in binary file format. This structure name can be shortened to a compound file.

Existing file systems struggle when trying to efficiently store multiple types of objects in a single document. Compound files provide a solution by implementing a simplified file system within the file. Structured storage defines a way to treat a single file as a hierarchical collection of two types of objects (storage objects and stream objects) that act as directories and files, respectively. This scheme is called structured storage. The purpose of structured storage is to reduce the performance penalty and overhead associated with storing individual objects in flat files. The standard Windows COM implementation of OLE structured storage is called a compound file. For more information on structured storage, see [MSDN-SS].

Structured storage solves the performance problem by not having to completely rewrite files every time a new object is added or an existing object grows in size. New data is written to the next available location in the file, and the storage object updates the internal structure that holds the location of the storage object and the stream object. At the same time, structured storage allows end users to interact with and manage compound files as if they were a single file rather than a nested hierarchy of individual objects. For example, compound files can be copied, backed up, and emailed just like regular single files.

4 illustrates a simplified file system in which several directories and files are nested in a hierarchy.

5 illustrates a structured storage compound file hierarchy comprising nested storage objects and stream objects.

Referring to FIG. 5 , a compound file is a single file that includes a nested hierarchical structure of storage objects and stream objects, and includes a directory-like storage object and a file-like stream object.

A file of the MS-CFB structure may largely include a connection part/data part. For example, all data for the MS-CFB structure may correspond to the connection part.

The data unit can be used in an application that processes a corresponding file. For example, in the extension doc, ppt, xls, MS-CFB can be commonly used for other formats or the format of the connection part. Data parts of the extensions doc, ppt, and xls can be used in applications (eg Word, PowerPoint, and Excel) that process each extension.

For a document to be inserted into a document of MS-CFB format (embedded document), the inserted document can add information for the data portion of the document to be inserted to its own junction. For example, in the document to be inserted, only the data portion may be included in the inserted document excluding the connection portion. The server may extract the data part of the inserted document from the inserted document, regenerate the MS-CFB structure for the extracted data, and save it as a file.

6 is an embodiment of a server to which this specification can be applied.

Referring to FIG. 6 , the server may determine whether the document in the CFB format is malicious.

The server checks whether there is an object-embedded document in the CFB format document (S6010). For example, the server may check whether there is an entity-embedded document based on a subdirectory (eg, ObjectPool directory) in a root directory included in a CFB format document. The object inserted document may be a CFB format document. A CFB format document, which is an inserted document, may include MS-DOC and/or XLS format files.

The server extracts the object-embedded document based on the inspection result (S6020). For example, if there is an object-embedded document, the server may extract the object-embedded document for malicious inspection of the object-embedded document.

7 is an example of object inserted document extraction to which the present specification can be applied.

Referring to FIG. 7 , the server acquires directory entries related to the object-embedded document (S7010). Thereafter, the server may substitute the acquired items into the form and structure used in the actual CFB file based on the CFB specification.

The server creates a compound file header based on the directory entries (S7020).

The relevant specifications are as follows.

1.1 Glossary

This document uses the following terms:

Access Control List (ACL): A list (such as an object or set of objects) of Access Control Entries (ACEs) that collectively describes the security rules for authorizing access to some resource.

Application: A participant that must initiate, propagate, and complete an atomic transaction. Applications communicate with a transaction manager to start and complete transactions. Applications communicate with a transaction manager to organize transactions sent to and from other applications. Applications also communicate on a per-application basis with resource managers to submit requests for resource operations.

child object, children: An object that is not the root of the tree. The children of object o are the set of all objects whose parent is o.

class identifier (CLSID): A GUID that identifies a software component. For example, DCOM object classes or COM classes.

Compound file: A structure that divides a single file into sectors to store a simplified FAT file system-like file system within a single file.

Coordinated Universal Time (UTC): A high-precision atomic time standard that approximately tracks Universal Time (UT).

Creation time: The time the storage object was created (UTC).

Directory: A database that stores information about objects such as users, groups, computers, printers, and directory services that make this information available to users and applications.

Directory entry: A structure containing the file information of a storage object or stream object.

directory stream: An array of directory entries grouped by sectors.

Double-indirect file allocation table (DIFAT): A structure used to locate FAT sectors in a compound file.

File: A data entity in the file system that users can access and manage. The file must have a unique name in the directory. It consists of one or more byte streams containing related data sets and a set of attributes (also called attributes) that describe the file or the data within the file. File creation time is an example of a file attribute.

File allocation table (FAT): A data structure created by the operating system when a volume is formatted using the FAT or FAT32 file system. The operating system stores information about each file in the FAT so that the file can be retrieved later.

file system: A system that allows applications to store and retrieve files on a storage device. Files are laid out in a hierarchical structure. A file system specifies naming conventions for files and a format for specifying paths to files in a tree structure. Each file system consists of one or more drivers and DLLs that define the file system's data formats and functions. File systems can exist on diskettes, hard disks, jukeboxes, removable optical disks, and tape backup devices.

Global Unique Identifier (GUID): A term used interchangeably with universally unique identifier (UUID) in Microsoft protocol technical documents (TD).

header: A structure at the beginning of a compound file.

Little-endian: A multi-byte value aligned with the least significant byte stored in the memory location at the lowest address.

mini FAT: An area allocated separately to the FAT and a File Allocation Table (FAT) structure used to allocate space for mini streams. It has a separate sector size smaller than FAT.

mini stream: A structure containing all user-defined data for a stream object smaller than a predefined size limit.

modification time: The last time the storage object was modified (UTC).

object: A set of attributes, each with a value associated with it. Two properties of an object have special meaning: the identification property and the parent identification property. An identifying attribute is a specified single-valued attribute that appears on every object. The value of this attribute identifies the object. For a set of objects in replicas, the values of the identifying properties are distinct. A parent identifying property is a specified single-valued property that appears on all objects. The value of this property identifies the object's parent.

Object class: A category of object identified in COM by a CLSID, members obtained through activation of the CLSID.

Parent object: An object is the root of the object tree or has a parent object. If two objects have the same parent object, their relative distinguished names (RDNs) must have different values.

Root storage object: This is the storage object of the compound file that needs to be accessed before referencing other storage objects and stream objects. The highest-level parent object in the hierarchy of storage objects and stream objects.

Sector: The smallest addressable unit on a disk.

Sector chain: A linked list of sectors where each sector can be located in a different location within a compound file. It is expressed by connecting as many sectors as necessary for data of various sizes in a linked list.

Sector number (number): A non-negative integer identifying a particular sector in a compound file.

Sector size (size): The size of a sector in a compound file in bytes, typically 512 bytes.

storage: A storage object defined in [MS-CFB].

Storage object: An object of a compound file, similar to a file system directory. A storage object's parent object must be another storage object or a root storage object.

stream: An element of a compound file as described in [MS-CFB]. Streams contain sequences of bytes that can be read or written by applications, and can only exist on storage.

Stream object: An object in a compound file similar to a file system file. The parent object of a stream object must be either a storage object or a root storage object.

Stream object: A server object used to read and write large string and binary properties.

Unallocated free sector: An empty sector that can be allocated to hold data.

Unicode: A character encoding standard developed by the Unicode Consortium.

User-defined data: The main stream part of a stream object.

UTF-16: A standard for encoding Unicode characters defined in the Unicode standard.

2 Structures

2.2 Compound File Headers

8 illustrates a composite file header to which this specification can be applied.

Referring to FIG. 8, the compound file header structure must be located at the beginning of the file (offset 0).

A compound file header structure may contain:

Header Signature (8 bytes): This is the identification signature for the compound file structure and should be set to the values 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1.

Header CLSID (16 bytes): Reserved and unused class ID which must be set to all 0 (CLSID_NULL).

Minor Version (2 bytes): Version number for nonbreaking changes. If the major version field is 0x0003 or 0x0004, this field MUST be set to 0x003E.

Major Version (2 bytes): Version number for breaking changes. This field should be set to 0x0003 (version 3) or 0x0004 (version 4).

Byte Order (2 bytes): This field must be set to 0xFFE. This field is a byte order mark for all integer fields, specifying little-endian byte order.

Sector Shift (2 bytes): This field should be set to 0x0009 or 0x000c depending on the major version field.

Mini Sector Shift (2 bytes): This field should be set to 0x0006.

Reserved (6 bytes): This field must be set to all zeros.

Number of Directory Sectors (4 bytes): This integer field contains the number of directory sectors in the compound file.

Number of FAT Sectors (4 bytes): This integer field contains the number of FAT sectors in the compound file.

First Directory Sector Location (4 bytes): This integer field contains the starting sector number of the directory stream.

Transaction Signature Number (4 bytes): This integer field MAY contain a sequence number that is incremented each time a compound file is saved by an implementation that supports file transactions. This field should be set to all 0 if file transaction is not implemented.

Mini Stream Cutoff Size (4 bytes): Data size value to determine the allocation location of the target data, either FAT or Mini FAT. This integer field should be set to 0x00001000.

First Mini FAT Sector Location (4 bytes): This integer field contains the starting sector number of the mini FAT.

Number of Mini FAT Sectors (4 bytes): This integer field contains the number of mini FAT sectors in the compound file.

First DIFAT Sector Location (4 bytes): This integer field contains the starting sector number of DIFAT.

Number of DIFAT Sectors (4 bytes): This integer field contains the number of DIFAT sectors in the compound file.

DIFAT (436 bytes): This array of 32-bit integer fields contains the positions of the first 109 FAT sectors of the compound file.

The server may create a compound file header based on the specification.

For example, a server could create a compound file header like this:

A. Header Signature (8 bytes): Stored as the following values: 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1.

B. Header CLSID (16 bytes): Unused value. Set all values to 0.

C. Minor Version (2 bytes): Set to 0x003E value.

D. Major Version (2 bytes): Specifies the version number. It must be either 0x003 or 0x004, and the value is set according to the inserted document.

E. Byte Order (2 bytes): Indicates byte order representation, set to 0xFFFE (little endian).

F. Sector Shift (2 bytes): Set to one of the 2 cases below according to the Major Version value. Sector Size is obtained by calculating the set value as an exponent of 2.

Major Version 3 -> 0x0009 : Use Sector Size as 512 (2^9)

Major Version 4 -> 0x000c : Use Sector Size as 4096 (2^12)

G. Mini Sector Shift (2 bytes) : Set to 0x0006. Express the size of Mini Sector using the same as sector shift (2^6 -> 64Byte).

H. Reserved (6 bytes): Set all values to 0.

I. Number of Directory Sectors (4 bytes): Stores the number of Directory Sectors. Set to 0 if Major Version is 3.

J. Number of FAT Sectors (4 bytes): Saves the number of FAT sectors of the current file.

K. First Directory Sector Location (4 bytes): Stores the first Sector ID of Directory Sector.

L. Transaction Signature Number (4 bytes): Set all to 0 as file transaction values are not stored separately.

M. Mini Stream Cutoff Size (4 bytes): Specifies the size that distinguishes whether to save user-defined data in Mini FAT or FAT. Set to 0x00001000. (4096 bytes)

N. First Mini FAT Sector Location (4 bytes): Stores the first Sector ID of the Mini FAT Sector.

O. Number of Mini FAT Sectors (4 bytes): Saves the number of Mini FAT Sectors in the current file.

P. First DIFAT Sector Location (4 bytes): Stores the first Sector ID of DIFAT Sector.

Q. Number of DIFAT Sectors (4 bytes): Saves the number of DIFAT sectors in the current file.

R. DIFAT (436 bytes): An array of Sector IDs expressed as 32-bit integers, each of which points to the location of the FAT Sector. Up to 109 can be stored, and the excess of the number is stored in the DIFAT sector.

Referring again to FIG. 7 , the server creates a sector chain based on the directory entry (S7030).

9 is an example of storage area allocation to which the present specification can be applied.

Referring to FIG. 9 , the server may access data in sector units based on the size specified in the header. For example, the server may obtain an offset by bit shifting a sector number. Sectors may be configured in the form of sector chains according to the required space size, and such sector chains may also be allocated and stored as separate sectors. In addition, Mini Sector can also be configured in the form of a sector chain.

In more detail, the storage area is composed of Header and FAT and can be used by connecting Sector, which is the basic unit, as much as required for each data. For example, sectors that can be configured in the form of a sector chain are:

Data allocated to the FAT area:

A. Mini Fat Sector

The relevant specifications are as follows.

2.4 Compound File Mini FAT Sectors

mini FAT is used to allocate space in mini streams. A mini-stream is divided into smaller equal-length sectors, and the sector size used for a mini-stream is specified in the composite file header (64 bytes).

10 is an example of sectors of a mini Fat array to which the present specification can be applied.

Referring to FIG. 10, the position of a mini FAT sector is stored in the FAT standard chain, and the start of the chain is stored in the header (the position of the first mini FAT start sector). A mini FAT sector number can be converted to a mini stream as a byte offset using the formula sector number x 64 bytes. This formula differs from the formula used to convert a file's sector number to byte offset because no header is stored in the mini-stream.

Mini-streams are chained within the FAT in exactly the same way as regular streams. The starting sector of the mini-stream is referenced in the first directory entry (root storage stream ID 0).

If all user streams in the file are larger than the cutoff of 4,096 bytes, mini FAT and mini streams are not required. In this case, the position of the first mini-FAT start sector of the header can be set to ENDOFCHANE, and the position of the start sector of the root directory entry can be set to ENDOFCHANE.

Referring back to FIG. 9 , the server may store the Sector chain of the Mini Sector. For example, since a mini sector is a 4-byte array, up to 128 can be stored in one sector. The server receives the required number of sectors and can find the Mini FAT Start Location through the first root entry of the directory entry. A mini sector can be used for data storage that is smaller than the header's mini stream cutoff size. Conceptually, the server can be configured as a mini-sector chain in the same way as a sector chain is configured by allocating sectors as needed.

B. Directory Sector

The relevant specifications are as follows.

2.6 Compound File Directory Sectors

An array of directory entries is a structure used to contain information about streams and storage objects in a compound file, and to maintain a tree-style containment structure.

An array of directory entries is allocated as a standard chain of directory sectors within FAT. Each directory entry is identified by a non-negative number called a stream ID. The first sector of the directory sector chain must contain the root store directory entry as the first directory entry of stream ID 0.

11 is an example of a sector of a directory entry arrangement to which the present specification can be applied.

Referring back to FIG. 9, the Directory Entry structure is fixed to 128 Bytes and can store up to 4 items based on a 512 Byte Sector. The server can continuously record the Directory Entry structure as an array in the Sector.

C. User-defined data (User-Data)

Relevant specifications include:

2.7 Compound File User-Defined Data Sectors

A stream sector is simply a collection of random bytes. They are components of user-defined data streams and are not limited in content. User-defined data sectors are represented as chains in FAT or mini-FAT, and each chain must have a single directory entry associated with it to hold stream object metadata such as name and size.

12 is an example of a user-defined data sector chain to which this specification can be applied.

Referring to FIG. 12, in the example of FIG. 12 where sector #0 to sector #8 are indicated, the user-defined data sector chain starts at sector #7, continues with sector #1, continues with sector #3, and ends with sector #5. The next sector position of sector #5 may point to ENDOFCHIN (0xFFFFE).

To hold all user-defined data, the length of the user-defined data sector chain must be greater than or equal to the stream size specified in the stream object's directory entry. The unused part of the last sector among the user-defined data of the stream object must be filled with 0 to prevent unintended information from being leaked.

Again, referring to FIG. 9, the server can directly record data of a large size that cannot fit into a mini FAT into a sector.

D. FAT Sector

The relevant specifications are as follows.

2.3 Compound File FAT Sectors

FAT is the primary allocation of space within compound files. All sectors of a file are marked within FAT in some way, including unallocated sectors (free). A FAT is a sector chain composed of one or more FAT sectors.

13 is an example of sectors of a FAT arrangement to which this specification can be applied.

Referring to FIG. 13, FAT is an array of sector numbers representing space allocation within a file, grouped into FAT sectors. Each stream is represented in FAT by a chain of sectors in much the same way as in the FAT file system.

A set of FAT sectors can be considered together in a single array. Each entry in that array contains the sector number of the next sector in the chain, and this sector number can be used as an index into the FAT array to continue along the chain.

Same as others for sectors containing storage for chain terminators (ENDOFCHANE = 0xFFFFF), free sectors (FREESECT = 0xFFFFF), FAT sectors (FATSECT = 0xFFFFF), or DIFAT sectors (DIFSECT = 0xFFFFFFF). A special value that is not linked in any way is reserved.

The location of the FAT sector is read from DIFAT. FAT is represented by itself, but not as a chain. A special reserved sector number (FATSECT = 0xFFFFD) is used to indicate sectors allocated to FAT.

You can use the “(sector number + 1) x sector size” formula to convert a sector number to a byte offset in a file. This means sector #0 of the file starts with a non-zero byte offset sector size.

Referring back to FIG. 9 , the server may store sector chains of FAT sectors.

E. DIFAT Sector

The relevant specifications are as follows.

2.5 Compound File DIFAT Sectors

The DIFAT array is used to represent the storage of FAT sectors. DIFAT is represented as an array of 32-bit sector numbers. DIFAT arrays are stored in both the header and DIFAT sectors. In the header, the DIFAT array occupies 109 entries, and in each DIFAT sector, the DIFAT array occupies the total sector minus 4 bytes. (The last field is for linking DIFAT sector chains.)

14 illustrates a sector of a DIFAT arrangement to which this specification can be applied.

Referring to Figure 14, DIFAT sectors are linked together by the last field of each DIFAT sector. As an optimization, the first 109 FAT sectors are represented within the header itself. In a 512 byte sector composite file (6.875 MB = (1 header sector + 109 FAT sectors x 128 blank entries) x 512 bytes per sector) no DIFAT sectors are required for composite files smaller than 6.875 MB.

DIFAT represents FAT sectors in a different way than FAT represents sector chains. The specific exponent n for the DIFAT array contains the sector number of the (n+1)th FAT sector. For example, since the DIFAT array starts with index #0, index #3 of DIFAT contains the sector number for the fourth FAT sector.

Storage in the DIFAT sector is reserved with the FAT, but not linked to the FAT. The space of the DIFAT sector is denoted by the special sector number DIFISCT (0xFFFFFC).

The location of the first DIFAT sector is stored in the header.

The special value of ENDOFCHIN (0xFFFFE) is stored in the "next DIFAT sector position" field of the last DIFAT sector or in the header when the DIFAT sector is not needed.

Referring back to FIG. 9, in the DIFAT sector, the FAT sector is not represented as a sector chain. Up to 109 FAT sectors are stored in the DIFAT array inside the header, but if this is exceeded, the server can allocate a DIFAT sector to store a separate DIFAT array. DIFAT Sector is a 4-byte array, so up to 128 can be stored in one sector.

Referring back to FIG. 7 , the server may allocate a data area to a mini sector chain and/or sector chain for each directory item based on the Mini Stream Cutoff Size of the composite file header. In more detail, if the size of the directory entry is smaller than the mini stream cutoff size, the server may allocate a data area in a mini fat sector chain in response to this. If the size of the directory entry is greater than the Mini Stream Cutoff Size, the server may allocate a data area in a fat sector chain in response thereto.

The server connects the obtained directory items in a tree structure (S7040). For example, the tree structure may include a red-black tree. More specifically, the server can connect directory entries in a Red-Black Tree structure using Left Sibling, Right Sibling, and Color Flag.

The server creates a CFB connection structure based on the composite file header and the sector chain (S7050).

For example, a server can allocate a Directory Sector to a FAT that stores an array of Directory Entries. In more detail, the server may input the first sector ID of the directory sector into First Directory Sector Location of the compound file header, and input the total number of required sectors of the directory sector into Number of Directory Sectors of the compound file header. For example, in Number of Directory Sectors, if the Major Version is 3, 0, and if the Major Version of the Header is 4, the number of actual total required sectors may be input.

In addition, the server may allocate a Mini FAT Sector to the FAT, which stores the Sector chain allocated to the Mini FAT. For example, the server puts the Sector ID (of the FAT) that the Mini FAT Sector starts with in the Mini FAT Sector Location of the composite file header, and the Total Needs assigned to the Mini FAT Sector in the Number of Mini FAT Sectors of the composite file header ( You can input the number of Sectors of FAT.

Also, the server may allocate a DIFAT sector. For example, the server may obtain how many required FAT sectors are based on the composite file header. If the number of required FAT sectors exceeds 109, the server can allocate DIFAT sectors for storing the excess. The first Sector ID of the DIFAT Sector can be stored in the Header's First DIFAT Sector Location. The number of DIFAT Sectors can be stored in the Header's Number of DIFAT Sectors value. A value of 0xFFFFFFFC may be input to all sector chains of the FAT corresponding to the allocated DIFAT sector without indicating a separate connection.

Also, the server may allocate a FAT sector. For example, the server may obtain the number of FAT sectors required to store all sector chains based on the composite file header. A value of 0xFFFFFFFD can be input to all Sector chains of FAT corresponding to the allocated FAT Sector without indicating a separate connection. The number of FAT Sectors can be stored in the Header's Number of FAT Sectors value.

For example, the server can start by allocating the first ID of the allocated FAT sector to the DIFAT[0] value of the Header and continuously enter values as follows:

i. Sector ID of FAT Sector 0 -> Header::DIFAT[0]

ii. Sector ID of FAT Sector 1 -> Header::DIFAT[1]

iii. … ..

iv. Sector ID of FAT Sector 108 -> Header::DIFAT[108]

v. Sector ID of FAT Sector 109 -> DIFAT[0] in DIFAT Sector 0

Again, referring to FIG. 7 , the server generates document extraction data based on the CFB connection structure (S7060).

Since the server can create the CFB connection structure by recording the document extraction data in the same order of creation, document extraction data in the format shown in FIG. 9 can be generated.

For example, the server first records the composite file header (eg, re-records the previously created composite file header) and then records User-data in Mini FAT. More specifically, in order to record User-data in Mini FAT, the server may record data allocated to Mini FAT among directory entries in the order of directory entries. Thereafter, for User-data in FAT recording, after User-data in Mini FAT recording, the server may record and create remaining items in the order of Directory Entry. The server records the Directory Entry, records the Mini Sector chain representing the concatenation of Mini FATs, records the DIFAT Sector (if data exists), records the Sector chain representing the concatenation of the FATs, and records the document extraction data. can create

Referring again to FIG. 6 , the server adds the extracted document as a document to be inspected (S6030). For example, the server may take the document extraction data as an extracted document and add it to the extracted file list. Through this, the server can extract the object-embedded document and perform malicious inspection on the extracted document.

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 (7)

In a method for a server to extract and inspect a document file inserted in a CFB (Compound File Binary) format document,
checking whether there is an entity-embedded document in the CFB format document;
extracting the object-embedded document in the form of an original document file based on a result of the inspection; and
adding the extracted document as a document to be inspected;
Including,
The above CFB format documents are
Contains a document in MS-DOC format or a document in XLS format;
The document in which the object is inserted is
It is composed of the data part of the original document file,
The step of extracting the object-inserted document in the form of an original document file
acquiring directory entries related to the entity-embedded document;
based on the directory entries, creating a compound file header;
based on the directory entries, creating a sector chain;
connecting the obtained directory entries in a tree structure;
generating a CFB connection structure based on the composite file header and the sector chain; and
generating document extraction data based on the CFB connection structure;
Including, inspection method.
delete According to claim 1,
The sector chain
Inspection methods based on Mini FAT Sector, Directory Sector, User-defined data, FAT Sector, and DIFAT Sector.
According to claim 3,
The sector chain
Based on the Mini Stream Cutoff Size of the composite file header, it is divided into a normal sector chain or a mini sector chain.
According to claim 4,
The step of generating the document extraction data is
writing the composite file header;
Recording User-data of Mini Fat;
Recording user-data of FAT;
Recording a Directory Entry;
writing the mini-sector chain; and
recording the sector chain;
Including, inspection method.
In a server for extracting and inspecting a document file inserted in a document in CFB (Compound File Binary) format,
communications department;
Memory; and
a processor functionally controlling the communication unit and the memory; including,
The processor
Checking whether there is an entity-embedded document in the CFB format document, extracting the entity-embedded document in the form of an original document file based on the result of the inspection, and adding the extracted document as a document to be inspected,
The above CFB format documents are
Contains a document in MS-DOC format or a document in XLS format;
The object inserted document is composed of the data part of the original document file,
In order to extract the object-embedded document in the form of an original document file, directory entries related to the object-embedded document are obtained, based on the directory entries, a composite file header is created, and based on the directory entries to create a sector chain, connect the obtained directory entries in a tree structure, create a CFB connection structure based on the composite file header and the sector chain, and extract documents based on the CFB connection structure A server that generates data.
According to claim 1,
The document in which the object is inserted is
A test method that does not include a connection portion of the original document file.

Images