USPatent applicationPatented

Electronic device and method for detecting malicious file

Granted 3 Mar 2020 · 1 office action

Life of the application

12 dated events
⤢ drag to zoom20182020202220242026202820302032203420362038ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

An electronic device and a method for detecting a malicious file are provided. The method includes the following steps: An executable file is searched, and an import table is extracted from the executable file. The import table includes at least a name of a first DDL and a name of a second DDL. A distance between the first DLL and the second DLL is calculated. Whether the distance exceeds a threshold is determined. If the distance exceeds the threshold, then whether a duplicate content of the import table exists in the executable file is checked. The executable file is regarded as a malicious file if the duplicate content of the import table exists in the executable file.

Description

8 parts
›This application claims the benefit of Taiwan application…

This application claims the benefit of Taiwan application Serial No. 105141250, filed Dec. 13, 2016, the subject matter of which is incorporated herein by reference.

BACKGROUND OF THE INVENTION
›Field of the Invention

The invention relates in general to an electronic device and a detection method, and more particularly to an electronic device and a method for detecting a malicious file.

›Description of the Related Art

Along with the popularity of network technology, many information need to be transmitted through network. An electronic device, once connected to the network, may easily become a target of malicious programs. Existing anti-virus technology detects and scans files to locate malicious programs or files according to the known characteristic values of the malicious programs. For example, ordinary anti-virus software detects and scans malicious files according to the known characteristic values of the malicious programs. However, such method cannot prevent the electronic device from the PE infection caused by advanced persistent threat (APT) or zero-day malicious programs because anti-virus software companies do not have the characteristic values of the newly launched or customized malicious programs, and therefore cannot locate the malicious programs or files in the electronic device. Therefore, how to effectively detect malicious programs or files in the electronic device has become a prominent task for the industry.

›SUMMARY OF THE INVENTION

The present invention is directed to an electronic device and a method for detecting a malicious file. The method for detecting a malicious file quickly identifies a possible malicious file, and accurately determines whether the possible malicious file is a malicious file.

According to one embodiment of the present invention, a method for detecting a malicious file is provided. The method includes the following steps. An executable file is searched, and an import table is extracted from the executable file. The import table at least includes a name of a first dynamic-link library (DLL) and a name of a second DDL. A distance between the first DLL and the second DLL is calculated. Whether the distance exceeds a threshold is determined. If the distance exceeds the threshold, whether a duplicate content of the import table exists in the executable file is checked. The executable file is regarded as a malicious file if the duplicate content of the import table exists in the executable file.

According to another embodiment of the present invention, an electronic device is provided. The electronic device includes a processor and a storage unit. The storage unit stores an executable file. The processor searches the executable file and extracts an import table from the executable file. The import table at least includes a name of a first DDL and a name of a second DDL. The processor calculates a distance between the first DLL and the second DLL. The processor determines whether the distance exceeds a threshold. If the distance exceeds the threshold, then the processor checks whether a duplicate content of the import table exists in the executable file. The executable file is regarded as a malicious file if the duplicate content of the import table exists in the executable file.

The above and other aspects of the invention will become better understood with regard to the following detailed description of the preferred but non-limiting embodiment (s). The following description is made with reference to the accompanying drawings.

›BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an electronic device.

FIG. 2 is a flowchart of a method for detecting a malicious file according to an embodiment of the invention.

FIG. 3 is a schematic diagram of an example of an import table.

FIG. 4 is a schematic diagram of another example of an import table.

FIG. 5 is a schematic diagram of an example of an import table.

FIG. 6A is a schematic diagram of an import table and a PE header in a normal executable file.

FIG. 6B is a schematic diagram of an import table with a hacker-added address.

›DETAILED DESCRIPTION OF THE INVENTION · 1 of 2

FIG. 1 is a block diagram of an electronic device 100 . The electronic device 100 includes a processor 102 and a storage unit 104 . The electronic device 100 can be realized by a desktop computer, a laptop computer, or a PC tablet. The storage unit 104 can be realized by a hard disk, a memory card, or a memory for storing data files.

Refer to FIGS. 1 and 2 . FIG. 2 is a flowchart of a method for detecting a malicious file according to an embodiment of the invention. Firstly, the method begins at step S 202 , an executable file is searched and an import table is extracted from the executable file by the processor 102 . Specifically, the executable file is stored in the storage unit 104 , and the processor 102 searches the executable file stored in the storage unit 104 and extracts the import table from the executable file. The import table is read-only and records the DDLs imported by the executable file. Referring to FIG. 3 , a schematic diagram of an example of an import table 300 is shown. The import table 300 includes a name A of a first DDL, a name B of a second DDL, and a name C of a third DDL.

Then, the method proceeds to step S 204 , a distance between the DDLs is calculated by the processor 102 . For example, the processor 102 calculates a distance d 1 between the first DDL and the second DDL and a distance d 2 between the second DDL and the third DDL.

Then, the method proceeds to step S 206 , whether the distance exceeds a threshold is determined by the processor 102 . If the distance does not exceed the threshold, then the method proceeds to step S 208 . If the distance exceeds the threshold, then the method proceeds to step S 210 . The threshold can be a self-defined value. In one embodiment, the threshold relates to an average value and a standard deviation of the distances among multiple normal DDLs. For example, the threshold can be defined as the average value of the distances among multiple normal DDLs plus two times of the standard deviation. However, the definition of the threshold of the invention is not limited thereto. Refer to FIGS. 3 and 4 . FIG. 4 is a schematic diagram of another example of an import table 300 . Each DDL may include multiple functions. The import table 300 further includes the names of the functions of the DDL and the addresses of the functions. For example, the import table 300 includes a name A of a first DDL, the names A 1 , A 2 , . . . , AM of the functions of the first DDL and the address of each function (such as “0x00001, 0x00005, . . . , 0x00017”); a name B of a second DDL, the names B 1 , B 2 , . . . , BN of the functions of the second DDL and the address of each function (such as “0x00021, 0x00025, . . . , 0x00045”); a name C of a third DDL, the names C 1 , C 2 , . . . , CP of the functions of the third DDL and the address of each function (such as “0x00049, 0x00053, . . . , 0x00065”). The function with name A 1 is the first function of the first DDL, and the function with name AM is the last function of the first DDL. The function with name B 1 is the first function of the second DDL, and the function with name BN is the last function of the second DDL. The function with name C 1 is the first function of the third DDL, and the function with name CP is the last function of the third DDL.

A distance d 1 between the first DDL and the second DDL as indicated in FIG. 3 is obtained according to the difference obtained by subtracting the address of the last function of the first DDL from the address of the first function of the second DDL. A distance d 2 between the second DDL and the third DDL is obtained according to the difference obtained by subtracting the address of the last function of the second DDL from the address of the first function of the third DDL. That is, the distance d 1 is expressed as: 0x00021−0x00017=4 bytes; the distance d 2 is expressed as: 0x00049−0x00045=4 bytes. The address of the function is a relative virtual address (RVA).

During ordinary program compilation, the addresses of the functions of the DDL imported by the program will be defined and recorded in the import table, and the deviation of the distances between the addresses of the functions normally will not be too large. For example, the distances between the functions mostly are about 4 to 300 bytes. If the executable file generated from the compilation is found to have been attacked by a hacker, the distances between the addresses newly added by the hacker (here below referred as malicious address) and the addresses of normal functions would normally be greater than tens of thousands of bytes. Again, refer to FIGS. 3 and 4 . The distance d 1 and the distance d 2 calculated by the processor 102 both are 4 bytes. The processor 102 determines that both the distance d 1 and the distance d 2 do not exceed the threshold (suppose the threshold is defined as 300 bytes), and this implies that no malicious address has been added to the import table 300 by the hacker, and the method proceeds to step S 208 . In step S 208 , the executable file is regarded as a normal file by the processor 102 .

Referring to FIG. 5 , a schematic diagram of an example of an import table 400 is shown. The processor 102 calculates the distance d 1 as 4 , the distance d 2 as 4 , and the distance d 3 as 20100 . The processor 102 then determines that the distance d 3 exceeds the threshold (suppose the threshold is defined as 300 bytes), and this implies that a malicious address might have been added to the import table 400 by the hacker, and the executable file could possibly be a malicious file. Then, the method proceeds to the step S 210 , whether the executable file is a malicious file is further determined.

In step S 206 , which executable files could possibly be malicious files can be quickly identified according to the distance and the threshold. In an embodiment, the threshold is set as the average value of the distances among multiple normal DDLs plus two times of the standard deviation, and the accuracy of identifying malicious files could reach 95% to 97.5% (the adjustment of the threshold will affect the accuracy). The average value and the standard deviation of the distances among multiple normal DDLs can be calculated using a newly installed system. The newly installed system assumes that all files within the system are normal files, searches all executable files across the newly installed system(s), calculates the distances among multiple normal DDLs in each executable file, and uses the average value and the standard deviation obtained from the calculation of distances as a reference for setting the threshold of the invention. In another embodiment, if the threshold is set as two times of the standard deviation of the distances among multiple normal DDLs, then the accuracy of identifying malicious files can reach 97.5%. Therefore, in step S 206 , possible malicious files can be quickly identified according to whether the distance exceeds the threshold. Then, in step S 210 , whether the identified file is a malicious file is accurately determined.

›DETAILED DESCRIPTION OF THE INVENTION · 2 of 2

In step S 210 , whether the executable file is a malicious file is determined by the processor 102 according to whether a duplicate content of the import table exists in the executable file. Refer to FIGS. 6A and 6B . FIG. 6A is a schematic diagram of an import table 300 and a PE header 500 in a normal executable file. FIG. 6B is a schematic diagram of an import table 400 with a malicious address added by a hackers. As indicated in FIG. 6A , when a normal program is executed, firstly, a content of the PE header 500 is read, the next content of the import table 300 to read is obtained according to the address to which the index of PE header 500 directs, and the DDL necessary for executing programs is downloaded according to the content of the import table 300 . As indicated in FIG. 6B , the attack launched by hackers (PE infection) is described below. Firstly, the content of the import table 300 is duplicated to a padding block such as the block 400 A. That is the content of the block 400 A is identical to the content of the import table 300 . Then, a malicious address is added to the import table 400 , for example, the malicious address is added to the block 400 B. That is, the content of the block 400 B is the newly added malicious address. Then, the content of the PE header 500 is edited, and the index of the PE header 500 is directed to the import table 400 . Thus, in the scenario of FIG. 6B , when a program is executed, firstly, the content of the PE header 500 is read, the content of the import table 400 is read according to the index of PE header 500 , and the DDL is downloaded according to the content of the import table 400 and the function (including both normal and malicious DDLs and functions) is executed.

Since the hacker cannot add a new malicious address to the import table 300 which is read-only, the hacker, when launching an attack, will duplicate the import table 300 to the padding block and add a malicious address (as indicated in FIG. 6B ). Therefore, in step S 210 , whether the executable file is a malicious file is determined according to whether a duplicate content of the import table 300 exists in a block of the executable file.

If the duplicate content of the import table 300 does not exist in any blocks of the executable file (as indicated in FIG. 6A ), then the method proceeds to step S 212 . In step S 212 , the executable file is regarded as a normal file by the processor 102 , and this indicates that the executable file has not been attacked by the hacker.

If the duplicate content of the import table 300 exists in a block of the executable file, for example, the content of the import table 300 is identical to the content of the block 400 A of the import table 400 as indicated in FIG. 6B , which implies that the executable file has been attacked by the hacker, then the method proceeds to step S 214 . In step S 214 , the executable file is regarded as a malicious file by the processor 102 . In an embodiment as indicated in step S 214 , after an executable file is regarded as a malicious file, the processor 102 can further locate the malicious DDL and function of the electronic device 100 according to the content of the import table. Refer to FIGS. 5 and 6B . After an executable file is regarded as a malicious file (such as the scenario of FIG. 6B ), the processor 102 knows that the content of the block 400 B of the import table 400 (corresponding to the content of the name D of the fourth DDL of FIG. 5 ) is the name of the malicious DDL and the name of the malicious function. Thus, the processor 102 regarded the fourth DDL with name D as a malicious file, and the fourth function with names D 1 , D 2 , . . . , DQ as a malicious function.

The judgement for determining whether the executable file is a malicious file according to whether a duplicate content of the import table exists in the executable file as disclosed in step S 210 can reach an accuracy of 100%.

As disclosed above, the invention does not detect or scan malicious DDL according to the characteristic value, but determines whether the executable file is a malicious file according to whether a duplicate content of the import table exists in the executable file and locates the malicious DDL according to the distances among the DDLs imported by the executable. Therefore, the invention can effective prevent the PE infection caused by advanced persistent threat (APT) or zero-day malicious programs.

While the invention has been described by way of example and in terms of the preferred embodiment(s), it is to be understood that the present disclosure is not limited thereto. On the contrary, it is intended to cover various modifications and similar arrangements and procedures, and the scope of the appended claims therefore should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements and procedures.

1 of 8 part labels are ours — the grant heads the rest

Claims as granted

17 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

2 codes
IPC · International Patent Classification
Section G — Physics
  • G06F21/56
  • G06F21/00

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomJul 2017Oct 2017Jan 2018Apr 2018Jul 2018Oct 2018Jan 2019Apr 2019Jul 2019Oct 2019Jan 2020Apr 2020USPTOApplicantNon-final rejectionResponse after non-finalNotice of allowance
USPTOApplicanthover for detail · click to open
Pendency
2.5 y
931 days filing → grant
Office actions
1
non-final + final
Responses
1
no RCE
Examiner
Joseph P Hirl
art unit 2435 · TC 2400
Citations: 18 back · 0 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom20182020202220242026202820302032203420362038Owner 4
Titlehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock