File conversion in restricted process

(54) Title: CONVERSION OF ARCHIVE WITH (57) Summary:

RESTRICTION PROCESS (30) Unionist Priority: 26/02/2007 us 11 / 679,068 (73) Holder (s): Microsoft Corporation (72) Inventor (s): Aaron E. Erlandson, Ambrose T. Treacy, Benjamin J. Bunker , Christopher C. White, David Leblanc, Eric Fox, Maithili V. Dandige, Roberta A. Little (74) Attorney (s): Alexandre Ferreira (86) International Request: pct uS2008053360 of 07/02/2008 (87) International Publication : wo 2008 / i06289de 04/09/2008 “CONVERSION OF FILE WITH RESTRICTION PROCESS”

FUNDAMENTALS

For software designers, it has been a constant concern to deal with malicious code in the form of generic viruses and types called Trojan horses. Hackers, as a rule, have taken advantage of vulnerabilities within an application or the file format as soon as this vulnerability becomes known. Malicious coding takes advantage of a known vulnerability on the same day that it becomes generally exposed, and is referred to as a zero-day exploit. To date, there are very few solutions that actually deal with these types of zero-day explorations.

Given the speed at which malicious code can be circulated on a zero-day exploit, designers have not had enough time to implement a feature or some other solution that will address the vulnerability. Often, the only solution available is to reduce the potential for malicious code to enter by encouraging users to complete the best security procedures, such as turning off unnecessary services, keeping resource levels up to date. , and avoiding the opening of connections from unknown or unexpected sources. Once a vulnerability becomes known, a user can avoid opening files that are affected by that vulnerability. However, this does not provide an adequate solution in situations where a user must have access to the file.

Furthermore, currently available software applications (for example, anti-virus software) used to search and eliminate malicious code must have some prior knowledge of the malicious code or the vulnerability being exploited. For example, some applications scan documents for encryption that have previously been identified as malicious. Other applications need knowledge about the vulnerability, such as a particular field in a structure that could be evaluated as abnormally coded. Each of these methods requires prior knowledge (of coding or vulnerability). In a zero-day exploit, the vulnerability will not yet be known, and hackers will, as a rule, create new code that will not be identified as malicious. This makes the currently available software applications ineffective against zero-day exploits.

The modalities of the present invention address these and other considerations. And yet, although relatively specific problems have been discussed, it should be understood that the modalities of the present invention should not be restricted to solving the specific problems identified in the fundamentals.

SUMMARY

The summary is introduced as a way of selecting concepts in a simplified format, concepts that will be discussed later in the Detailed Description section. This summary is not intended to identify the key or essential factors of the matter in question now claimed, nor is it intended to be used as an aid element in determining the scope of the matter in question claimed.

The description of the modalities aimed at removing or disabling malicious encoding from a file in a first file format is made by converting the file into a file converted to a second file format. In the modalities, the malicious code that is contained inside the file is removed or deactivated during the conversion of the file into a converted file. The conversion is performed by a converter, which is loaded into a restricted computational process. The computational process has restricted privileges, limiting its access to the underlying operating and computational systems. In view of this, even if a malicious code embedded inside the file is able to function during the conversion, the damage it may cause will become limited due to this loading occurring within the restriction process.

The modalities can be implemented in the form of a computational process, or in the form of a manufactured article, such as a computer program product or, computer-readable media. The computer program product can consist of computer storage media read through a computer system and, coding a computer program of instructions for executing a computer process. The computer program product may also consist of a signal propagated in a carrier read through a computer system and encoding a computer program of instructions for executing a computer process.

BRIEF DESCRIPTION OF THE DRAWINGS

The non-limiting and non-exhaustive modalities are described with reference to the figures below, in which identical reference numerals refer to identical parts throughout the various views, unless otherwise indicated.

Figure 1 illustrates a system that is used to remove or disable malicious coding from a file, according to one modality.

Figure 2 illustrates a system that can be used to safely open a file that may contain malicious coding, according to one modality.

Figure 3 illustrates an operational flowchart for removing or disabling malicious coding from a file.

Figure 4 illustrates an operational flow chart for safely opening a file that may contain malicious code.

Figure 5 illustrates a second operational flowchart for safely opening a file that may contain malicious code.

Figure 6 illustrates a block diagram of a computational environment suitable for implementing modalities.

DETAILED DESCRIPTION

The various modalities are more fully described below with reference to the accompanying drawings, which form part of them, and show the specific modalities for carrying out the invention. However, the modalities can be implemented in many different formats and should not be seen as being limited to the modalities established by this specification; on the contrary, these modalities are provided so that this document becomes complete and integral, and has a full scope of the scope of the invention for specialists in the field. The modalities can be carried out in the form of methods, systems or devices. In view of this, the modalities can take the form of a hardware implementation, an integral software implementation or an implementation combining the software and hardware aspects. So the detailed description given below should not be given a limited meaning.

The logical operations of the various modalities are implemented (1) in the form of a sequence of the computationally implemented steps running in a computer system and / or (2) in the form of modules interconnected by machines within the computer system. The implementation is a matter of choice depending on the performance requirements of the computational system implemented. As a result, the logical operations generating the modalities described in this report are alternatively referred to as operations, steps or modules.

As already briefly described, the modalities are aimed at removing or deactivating malicious coding from a file in a first file format by converting the file to a second file format. Malicious coding is removed or deactivated without any prior knowledge of the code, or the vulnerability put in place to conduct the code. The conversion is performed through a converter, which is loaded into a restricted computational process. The computational process has its privileges restricted in order to limit its access to the underlying computational and operational system. That is, if the malicious encoding embedded within the file is able to execute during the conversion, the damage that it may create becomes limited given its restricted access. In the present application, the term “malicious coding” intends to have a wide scope with the inclusion of software as part of a file or application with unauthorized purposes. Examples of malicious code include viruses, parasites, Trojan horses, and other types of undesirable software.

Figure 1 illustrates a system 100 that is used to safely open a file that may contain malicious code, according to one modality. In this embodiment, system 100 includes operating system 102 with a record 112, application 104, converter 106, and a file 110. File 110 includes data 110A and a file extension 110B (for example, as part of the file name ). In addition, according to this modality, application 104 includes a block 114 surveillance. Block surveillance 114 in some modalities indicates which types of files (ie file formats) are blocked from being opened by the application 104. Still, block surveillance 114 can also indicate which types of files are found up with your bailouts blocked. Block surveillance and its use in blocking the opening and / or saving of a file are discussed in detail in the North American Patent Application Serial Number 11/679048, entitled “FILE BLOCKING MITIGATION”, with the same co-authorship and deposited at the same date of the present request and included in this report in its entirety as a reference.

Converter 106 is used for converting files from a first file format to a second file format. Converting files from the first file format to the second file format removes or disables malicious coding that may be embedded within the files. The converter 106 can communicate with the operating system 102 for purposes relating to the functions of accessing the operating system. In the modality shown in Figure 1, converter 106 is loaded in a process with restriction 120, so that the conversion of files from a first file format to the second file format is performed within the process with restriction 120. The process with restriction 120 presents limited access privileges with the operating system 102, and the underlying computer system running by the operating system. In other words, process 120 has limited privileges for requesting functions from the operating system.

Turning now to application 104, it can communicate with operating system 102 for purposes relating to the functions of accessing the operating system. In the modality shown in Figure 1, application 104 is not within a restricted process as it is for converter 106, and, therefore, has greater privileges regarding the request of the operating system functions. In addition, application 104 can open, edit, save, and / or create files. In the modality shown in Figure 1, application 104 is interacting with file 110. As an example, application 104 can represent a word processing application. A user can launch an application 104 and then open a file (for example, file 110) with application 104, which will load the file 110 into memory and provide access to the file. The user can then add or edit the data (ie data 110A) in file 110. Application 104 is not limited to a specific type of application, it can comprise applications of any genre, such as a word processor, spreadsheet, graphic presenter, etc.

Application 104, in the modalities, adjusts the file extension 110B to indicate that the file 110 is of a particular type. For example, in this mode, the file extension 110B is part of the file name of the file 110 assigned to the file when it is “saved” or “saved as”. For example, a word processing application can cause a file (for example a text document) to have a file extension such as ".doc" to indicate that the file is a file in binary format.

Sometimes file extensions, such as 110B, are used by administrators to detect or block potentially malicious files (that is, a known vulnerability that can be exploited to introduce malicious coding) before they are received by a network. For example, an email server can be configured to detect and block all emails with files featuring a particular file extension, while enabling incoming emails with files featuring other file extensions to the client's email network. However, because file extensions can be easily manipulated by simply renaming a file with a different extension, the use of file extensions does not translate into a reliable mechanism for identifying files with malicious code that may be introduced into the network. Furthermore, blocking a file before it enters a network prevents a user, while waiting for the file, from becoming aware of the file lock and / or the existence of a security issue with the file.

In the modality shown in Figure 1, application 104 includes the inspector-type module 124. The inspector-type module 124 examines the file data (for example, ο 110A) and determines the actual file format of a file. The term "true file format" is used in this application to describe the current file format. Consider, for example, a word processing document that can have a * .doc file format; * .dot; or * .wiz. It should be understood that in the modality shown in Figure 1, the actual file format of a file is not determined by inspecting a file extension, such as the 110B extension. On the contrary, the inspector-type module 114 examines a portion of the file data, for example, ο 110A, and based on an examination determines the true file format of a file.

In one embodiment, the inspector-type module 124 reads the first few bits of data from a file (that is, probes the file), and based on factors such as the formation of the main header and data structures within the scope of the examined data, the inspector-type module 124 can determine a true file format for the file. The actual file format is described in the present application using a file extension. For example, a file format can be described as * .doc; * .dot; and / or * .wiz. However, one should not confuse the description of a true file format in the form of a file extension with the determination of a true file format, which does not involve examining the file extension.

In operation, system 100 first launches an application, such as application 104. Application 104 can be launched by the user by requesting the launch of this application 104, for example, by double-clicking on an icon representing the application 104. Alternatively, a user can request that file 110 be opened, for example, by double-clicking on a file icon 110. In this case, the operating system 102 can associate the file extension 110B with the application 104 and initiate the launch of the application 104.

Application 104 loads configuration information when launched. In some modalities, the configuration information is stored in a registry 112 of the operating system 102. In these modalities, when the application 102 takes off, it will request the configuration information from the operating system 102, which will retrieve the information from the registry. 112. In one embodiment, block surveillance 114 is stored in the form of configuration information within the operating system registry 102; for example, in the form of registration keys. As a result, when application 104 is launched, block 114 surveillance is recovered from register 112.

In some embodiments, access to block 114 surveillance is limited to those users with the privilege to write / modify the 112 record, for example, users with administrative privileges. Therefore, an administrator can effectively control file formats that have blocked openings or saves using application 104.

Once launched, application 104 can be used for opening, editing, and saving files. As a first example, when application 104 tries to open file 110, the inspector module first examines a portion of data 110A to determine a true file format 110. According to the description above, in one mode, the module type inspector 124 determines the true file format by examining the first few bits of data 110A. The inspector-type module 124 can make use of the main header information or data structures within the 110A data to be able to determine the true file format of the 110 file. Once the true file format of the 110 file has been determined. , application 104 compares the true file format with block surveillance

114. If the true file format of the 110 file is not identified by the surveillance as having its opening blocked, application 104 will open the 110 file by loading the file into memory and providing access to the file with the user for addition, editing, and saving data in file 110.

If the true file format of file 110 is identified by block surveillance 114 as having its opening blocked, application 104 will block the opening of file 110. In one embodiment, application 104 displays a message to a user indicating that the file it is not a file format with a blocked opening.

In another embodiment, in response to a determination that file 110 has its opening blocked, converter 106 can be launched to convert the file from its true file type to a second file type that does not have its opening blocked. In this mode, converter 106 is loaded in a restriction process 120 and is used to convert file 110 into a second file without opening it by application 104.

In some embodiments of system 100, an administrator can set converter 106 as the element with pre-defined enabling to handle files of a specific file format. In the event of a zero-day scan, where a particular file format has been identified as vulnerable, an administrator can investigate possible damage to the computer system or network by adjusting converter 106 in the form of a pre-enabled element -defined to handle vulnerable format files. This reduces the feasibility of losses during zero-day scanning, since at any time a user tries to open a file stored in the vulnerable file format, converter 106 will be launched to convert the file into another format. As previously described, the conversion will eliminate the malicious coding from being transferred / stored in the converted file. Furthermore, because the 1056 converter is loaded in the 120 restriction process, any malicious coding that is executed will have a limited impact on the computer system or the network.

In some embodiments, an administrator can take additional care during a zero-day scan by establishing block surveillance for application 104 to block files with the vulnerable format. Hence, in combination with the establishment of converter 106 as the element with pre-defined activation, a computer system or network acquires robust protection against damage that may be caused by malicious coding included in a file with a vulnerable format.

Figure 2 illustrates a system 200 with a more detailed description of converter 106. System 200 includes file 202A, comprising a first file format (file format 1), converter 106, converted file 202B, comprising a second file format (file format 2), and operating system 102 with registration 112. In the mode shown in Figure 2, converter 106 is loaded in a process with restriction 120, so that a conversion from file format 1 to file format 2 is performed within the process with restriction 120. The process with restriction 120 has limited access privileges to operating system 102, and the underlying computer system where operating system 102 is running. This ensures that even if the malicious code will execute, such as the malicious code 204, the damage is limited to what it can do to the operating system 102 and the underlying computer system. Figure 2 shows the details of a converter mode 106, which converts a 202A file from a first file format to a 202B file converted from a second file format, and in the process removes or disables the malicious coding 204 of converted file data.

In operation, the system 200 starts the converter 106 first. The launch of the converter 106 can occur upon user request for the launch of the converter 106, for example, by double clicking on an icon representing the converter 106. Alternatively, a user can request that the 202A file be opened, for example, by double clicking on an 202A file icon. In this case, the operating system 102 can associate the 202A file (or its file extension) with converter 106 and initiate the launch of converter 106.

Converter 106 is loaded in restriction process 120 when launched. When launched, converter 106 can load configuration information from register 112. Configuration information can include information indicating the specific mechanism by which process 120 becomes restricted. Process 120 has limited access privileges to operating system 102, and the underlying computer system on which operating system 120 is running. Experts in the field will note that the specific restrictions placed on process 120, and the mechanism by which process 120 becomes restricted, will vary, depending on the specific operating system 102, and through other model considerations, such as the level of risk assigned to the 202A file.

In some modalities, process 120 has been denied its permission to perform particular operations and / or to make calls to specific functions of the operating system 102. For example, process 120 of reading or writing information with the registry 112 of operating system 112 due to registry 120 storing sensitive configuration information for various applications. However, process 120 is allowed to read and write data with other storage locations. In other modalities, process 120 is restricted to being able to execute only those functions that are necessary to convert a file from a file format 1 to a file format 2. For example, process 120 is only allowed to read data from a file being converted (for example, file 202A), and to write data next to the converted file (for example, file 202B) with the information converted to file format 2.

As described above, the mechanism by which the process becomes restricted will depend on the specific operating system 102. In one embodiment, operating system 102 consists of a version of the “WINDOWS” operating system that provides a limited amount of access privileges to a process. For example, in the “WINDOWS” operating system versions, each process has an associated access sign describing a process security context that includes a list of system-extended privileges for the process. An access signal that typically describes a restricted security context is called a restricted signal. A restricted signal describes a limited set of privileges extended to the system. In one embodiment, process 120 is restricted to being associated with a restricted signal describing a limited set of privileges extended to the system.

In other embodiments of system 200 that make use of a version of the 'WINDOWS' operating system, process 120 may have its association with a work object restricted. A work object allows groups of processes to be managed in the form of a unit. Work objects control the attributes of the processes associated with them. A work object can be used to enforce limits on an associated process, such as the size of the working set, process priority, and time limit for finishing work. In one embodiment, process 120 has its association with a work object restricted by putting into effect the pre-defined limits for process 120.

In other embodiments, process 120 may be restricted to the use of a desktop computer container or to a restricted group of windows. The “WINDOWS” operating system versions allow desktop computer containers to have multiple users connected to a group of windows. A desktop computer container is a container object with the guarantee that it is contained within a group of windows. A desktop computer container consists of a logical compilation of user interface elements, which in turn is contained within a group of windows, implemented according to the versions of the WINDOWS operating system. Certain aspects of communication between processes running within versions of the “WINDOWS” operating system are regulated based on whether the processes are assigned to the same desktop computer, where in some cases, communication is regulated by those processes that share the same group of windows. Inter-process communications can have security implications, and for this reason, in some embodiments, the 200-restricted process runs in a group of separate windows (which implies a separate desktop computer, since all desktop computers table only have a group of windows in the form of a container).

In the modalities of system 200 implementing the use of an operating system “WINDOWS 120, process 120 has restricted its use of restricted signs, work objects, and groups of window / containers of desktop computers. The use of two or more of these mechanisms provides robust security that limits the damage that may be caused by malicious coding running in process 120 during the conversion of the 202A file from file format 1 to a converted 202B file in the format of file 2. In a specific modality, process 120 has restricted its use of all three items, the restricted sign, a work object, and a desktop computer container.

After converter 106 is loaded in a process with restriction 120, converter 106 converts file 202A from file format 1 to converted file 202B in file format 2. As previously described, the converter has no knowledge of malicious coding 204 that may be located inside a 202A file, nor is it aware of the vulnerability. In the modalities, converter 106 converts the 202A file using an analyzer and a machine. The analyzer analyzes the file for data extraction, which is expressed by the machine in a different file format, called file format 2. The new data expressed is stored in the converted 202B file. In one embodiment, during the process of analyzing the 202A file, the analyzer identifies the characteristics inside the 202A file, such as the main header information and data structures of the 202A file, used by the analyzer to determine what data will be transferred to the converted 202B file. Malicious encoding 204 does not include the characteristics used by converter 106 to determine what data to store in the converted file 202B, and therefore is not included in the converted file 202B. When the converter analyzer 106 analyzes malicious code 104, it will not recognize the characteristics necessary for transferring data to the 202B file. As a result, the malicious encoding 204 will be eliminated from the file data transferred to the converted file 202B. The converted 202B file can then be safely opened and accessed externally to the restricted 120 process.

In other embodiments, malicious encoding 204 can be passed on to converted file 202B. Typically, applications make use of an analyzer to scan a file before opening the file. In view of this, malicious coding, like malicious coding 204, turns to analyzers designed to open files of a specific file format. That is, malicious code 204 can attack analyzers used to open files in file format 1. Thus, even if malicious code 204 is included in the converted file 202B, it will not be a major security threat due to the converted file 202B will be opened by analyzers designed to open files with file format 2. Thus, in these modalities, the simple conversion of the 202A file in file format 1 to the converted file 202B in file format 2 eliminates the threat of malicious encryption 204 even if the encoding is inserted in the converted file 202B.

In some situations, malicious code 204 may attack converter 106 when this converter 106 proceeds to convert file 202A. As previously described, converter 106 runs in a process with restriction 120, which has restricted privileges. As a result, even if the malicious code 204 successfully manages this execution during the conversion of the 202A file, the losses that it may cause become limited.

In the modalities, the conversion performed by the converter 106 provides advantages over the software applications, which are specifically designed for the removal of the malicious coding of the files. Typically, these applications that are developed for the removal of malicious coding must have some knowledge of which characteristics to examine to be able to identify the malicious coding or, which structures to examine that may present themselves as vulnerable by storing infected payloads. In contrast, converter 106 has no knowledge of malicious coding 204, on the contrary, the mere fact that malicious coding 204 does not contain the characteristics necessary for converting data from file format 1 to file format 2 will remove the Malicious encoding 204 of the data transferred to the converted file 202B. Furthermore, even if malicious code 204 is transferred in the converted file 202B, it does not pose a serious security threat due to the new file format (for example, file format 2) of the converted file 202B.

In some embodiments, converter 106 consists of a two-way converter which implies that it can convert file format 1 to file format 2 and also convert file format 2 back to file format 1. In one embodiment, after converter 106 has generated converted file 202B and removed malicious code 204 from being transferred to converted file 202B, it converts file 202B back to file format 1. In one example, the 202A file may be a binary file format (file format 1) that has been identified as having a security vulnerability. As a result, file 202A is converted by converter 106 into converted file 202B into an XML file format (file format 2), which removes or disables malicious coding 204. However, a user may not have an application that is capable of to open files that are presented in an XML format. Thus, the 202B file is converted back to the binary file format (file format 1) in order to allow a user to open and access the file data.

Figures 3 to 5 illustrate operational flow charts 300, 400, and 500, according to the modalities. Operational flowcharts 300, 400, and 500 can be run in any suitable computing environment. For example, operational flowcharts can be run by a system, such as systems 100 and 200 (Figure 1 and Figure 2), for removing malicious encoding from a file and securely opening the file. Therefore, the description of the operational flowcharts 300, 400, and 500, can refer to at least one of the components of Figure 1 and Figure 2. However, any references to the components of Figure 1 and Figure 2 comprise an environment without limitations for operational flowcharts 300, 400, and 500.

Furthermore, although the operational flowcharts 300, 400 and 500 are illustrated and described sequentially in a particular order, in other modalities, operations can be carried out in different orders, numerous times, and / or in parallel. One or more operations in some modalities may be omitted or combined.

Figure 3 illustrates an operational flow chart 300 for removing malicious coding from a file, according to one embodiment. In operation 302, a converter that is capable of converting a file from a first format to a second format, is loaded in a restricted process. In the modalities, the converter consists of converter 106 (Figure 1 and Figure 2), which is loaded in the process with restriction 120 (Figure 1 and Figure 2). The process with restriction 120 has limited access privileges to the operating system, such as, for example, the operating system 102. The restrictions placed on the process limit the possibility of damage caused by malicious coding that is performed during conversion of a file by the converter.

Operation 302 can be initiated as a result of a user requesting a converter to be triggered, for example, by double clicking on an icon representing the converter. Alternatively, a user can make the request by opening a specific file, for example, by double-clicking on a file icon, and, in response, operation 302 will start the converter running by loading the converter into a restricted process.

After the converter has been loaded in a restricted process, the operational flowchart moves to operation 304, where the malicious code is removed by converting the file from a first file format to a second format. Operation 304 is performed within the restricted process. In one embodiment, the conversion is performed by the converter 106 in the process with restriction 120. As previously described, converter 106 will analyze a file in a first file format and identify the characteristics within the file that are used to extract data from the file. The extracted data is then stored in a converted file that is in a second file format. The converted file is free of any malicious coding that may have been inserted into the first file. The converted file can be safely opened in a process with fewer restrictions than the restricted process used in converting the file.

Figure 4 illustrates an operational flow chart 400 for safely opening a file for accessing the data in the file, according to one modality. In operation 402, a request to open a file is received. In one embodiment, the request is received by a converter, such as a converter 106 (Figure 1 and Figure 2). For example, a user can try to open a file by launching a converter and then select the file through the converter. In another modality, the request is received by an application, such as application 104 (Figure 1). A user can try to open a file by launching the application and then select the file. In some modalities, the request is received when the user selects a file, by double-clicking on a file icon.

The operational flowchart then passes to operation 404, where a converter, capable of converting a file from a first format to a second format, is loaded in a restriction process. In the modalities, the converter is the converter 106 (Figure 1 and Figure 2), which is loaded in the restriction process 120 (Figure 1 and Figure 2). The restricted process has limited privileges for requesting functions from an operating system, and access to resources on an underlying computer system. This reduces the damage that may be caused by malicious coding running within the 120 process.

In operation 406, the converter converts a file from the first file format, generating a second file that is in a second file format. In the modalities, the file conversion process eliminates any malicious coding that may be embedded inside the file and will be stored in the second file. The elimination of malicious code occurs without any knowledge of the malicious code, or any knowledge of a vulnerability being exploited by the malicious code. In other ways, any malicious coding within a file can be disabled by simply converting the file from the first file format to the second file format. In the modalities, the converter is the 106 converter (Figure 1 and Figure 2) that analyzes the file to extract data from the file and store it in the second file.

After operation 406, the flowchart moves to operation 408, where the file is opened. In the modalities, operation 408 involves launching an application that is capable of opening and providing access to the converted file that is in the second file format. In other embodiments, operation 408 may involve a number of additional operations, such as converting the converted file a second time. For example, the converter used in operation 406 can be a double-acting converter, that is, it can convert files from the first file format to the second file format, as well as convert the files in the second file format to the first file format. In one embodiment, operation 408 involves converting the file in the second file format back to the first original file format, using the converter. This operation can be accompanied by the launch of an application capable of opening the file in the first file format.

In other embodiments, another converter can be used to convert a file in the second file format to a third file format. In this mode, operation 408 may involve the launch of a second converter that converts the file in the second file format to a third file format. This operation can be accompanied by the launch of an application capable of opening and providing access to the file in the third file format.

Figure 5 illustrates an operational flow chart 500 for safely opening a file, according to one modality. Operation 502 receives a request to open a file. In one embodiment, the request is received through an application, such as an application 104 (Figure 1). For example, a user can launch an application and then select the file. In some modalities, a user selects a file, which can be automatically launched in an appropriate application to open the file (or prompt the user to select an application to open the file).

In operation 504 the file data from the file is examined by determining the true file format. In one embodiment, an application featuring an inspector-type module, such as an inspector-type module 124 (Figure 1), is used to inspect file data before the file is loaded into memory. The data of the file inspected by the inspector type module comprises only a small fraction of the data inside the file. Through the identification of the characteristics within the data, such as the main header information and the data structures, the inspector module can make a determination as to the true file format without the need for a complete examination, or an extensive part data contained within the file.

In operation 506, a determination is made as to whether the true type of file for the file has its opening blocked. In the modalities, the determination is made through access to a block surveillance, such as block surveillance 114A (Figure 1), indicating which file formats have their openings blocked. If in operation 506, a determination occurs so that there is no blocking of the true file format, then the flowchart goes to operation 508 where the file is opened by loading the file into memory and then promoting access to the file. For example, in one mode, an application, such as application 104, performs operation 508 by loading the file into memory and providing access to a user through the application, allowing the user to edit, add, and save data in the file.

If in operation 506, a determination is made that the file's true file format has its opening blocked, the flowchart goes to operation 510. In operation 510, a converter capable of converting a file from a first format to a second format, is loaded in a restriction process. In the modalities, the converter is the converter 106 (Figure 1 and Figure 2), which is loaded in the restriction process 120 (Figure 1 and Figure 2). The restriction process has its privileges limited when requesting functions from an operating system and when accessing resources in an underlying computer system. Limited privileges reduce the damage that may be caused by malicious coding running within process 120.

In operation 512, the converter loaded in the restricted process converts a file from the first file format to generate a second file that is in a second file format. In some ways, the file conversion process eliminates the possibility of any malicious coding, which may be embedded within the first file, of being introduced in the second file. The elimination of malicious code occurs without any knowledge of the malicious code, or any knowledge of a vulnerability being exploited by the malicious code. In other ways, simply converting the file from the first file format to the second file format eliminates the risk of malicious coding aimed at the analyzers used to open files in the first file format. In the modalities, the converter is a 106 converter (Figure 1 and Figure 2) that analyzes the file in a first file format, identifying the characteristics inside the file that are used to extract data from the file. Then the data is stored in the second file, which is in a second file format. The second file is free of any malicious coding that may have been inserted into the first file.

After operation 512, the flowchart moves to operation 508, where the converted file is opened. In the modalities, operation 508 involves an application that is capable of opening and providing access to the converted file that is in the second file format. In other embodiments, operation 508 may involve a number of additional operations, such as converting the converted file a second time.

Figure 6 illustrates a generic computational environment 600, which can be used to implement the modalities described in this report. The computational environment 600 comprises only an example of a computational environment and is not intended to suggest any kind of limitation to the scope of use or functionality of the computer and network architectures. Nor should computing environment 600 be interpreted as having any dependency or requirements related to any type of combination between the components illustrated in the example relating to computing environment 600.

In its most basic configuration, system 600 typically includes at least one processing unit 602 and memory 604. Depending on the exact configuration and type of computing device, memory 604 may be volatile (such as RAM), not volatile (such as ROM, instant memory, etc.) or some form of combination between the two. This most basic configuration is illustrated in Figure 6 by the dotted line 606. As shown in Figure 6, applications, such as application 104 (Figure 1), including block surveillance 114 and inspector-type module 124, can be loaded into system memory 604 for use by the system user 600. Figure 6 also shows the process with restriction 120 by which converter 106 is loaded to convert a file from a first format to a file converted to a second format for removing malicious encoding that may have been embedded in the file. .

In addition, the 600 system may also have additional features / functionality. For example, the system 600 may also include additional storage (removable and / or non-removable) including, but not limited to, optical or magnetic tapes or disks. Such additional storage is illustrated in Figure 6 through removable storage 608 and non-removable 610. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as instructions with computer readings, data structures, program modules or other data. Memory 604, removable storage 608 and non-removable storage 610 all comprise examples of media for computer storage. Computational storage media includes, but is not limited to RAM, ROM, EEPROM, instant memory or other memory technology, CD-ROM, versatile digital discs (DVD) or other optical storage devices, magnetic tapes, magnetic tape, storage magnetic disk or other magnetic storage devices, or any other media that can be used to store the desired information and which can be accessed by the 600 system. Any computational storage media can represent part of the 600 system.

The 600 system can also contain connections for 612 communications that enable the system to communicate with other devices. Connections for 612 communications consist of an example of communication media. Typically, communication media personify instructions with computer readings, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transport mechanism including any information supply medium. The term “modulated data signal” represents a signal having one or more of its characteristics adjusted or altered in such a way as to encode the information in the signal. As an example, and not a limitation, communication media includes wired media, such as a wired or direct wired network, and non-wired media such as acoustic, RF, infrared media and others without wiring. The term computer reading media is used in this report for both storage and communication media.

The 600 system can also feature 614 input devices, such as a keyboard, mouse, pen, voice input device, touch input device, etc. 616 output devices, such as a viewer, speakers, printer, etc., can be included in the same way. All of these devices are well known in the field and do not need to be discussed in detail in the report.

Reference has been made throughout this specification to the terms "modality", "one modality", "first modality", "another modality", and "some modality" meaning that a particular factor, structure, or characteristic described has been included, at least in one embodiment of the present invention. Thus, the use of such phrases may refer to more than one modality. Furthermore, the characteristics, structures, or factors described can be combined in any suitable way in one or more of the modalities.

A specialist in the relevant field will be able to identify, however, that the invention can be carried out without the presence of one or more of the specific details, or through other methods, resources, materials, etc. At other times, it failed to present details, structures, resources, or well-known operations just to avoid obscuring aspects of the invention.

Although example modalities and applications of the present invention have been illustrated and described, it should be understood that the invention is not limited to the precise configuration and features described above. Various modifications, changes, and apparent variations can be made by experts in the field with respect to the arrangement, operation, and details of the methods and system of the present invention described in this report without deviation from the scope of the claimed invention.