US9384364B1 - System and method of controlling access of a native image of a machine code to operating system resources - Google Patents

System and method of controlling access of a native image of a machine code to operating system resources Download PDF

Info

Publication number
US9384364B1
US9384364B1 US14/811,135 US201514811135A US9384364B1 US 9384364 B1 US9384364 B1 US 9384364B1 US 201514811135 A US201514811135 A US 201514811135A US 9384364 B1 US9384364 B1 US 9384364B1
Authority
US
United States
Prior art keywords
assembly
native image
image
category
trust
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US14/811,135
Other languages
English (en)
Inventor
Dmitry G. Ivanov
Nikita A. Pavlov
Dmitry V. Shvetsov
Mikhail A. Gorshenin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kaspersky Lab AO
Original Assignee
Kaspersky Lab AO
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kaspersky Lab AO filed Critical Kaspersky Lab AO
Assigned to AO Kaspersky Lab reassignment AO Kaspersky Lab ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GORSHENIN, MIKHAIL A., IVANOV, DMITRY G., PAVLOV, NIKITA A., SHVETSOV, DMITRY V.
Priority to EP15184119.4A priority Critical patent/EP3076292B1/en
Priority to CN201610067701.6A priority patent/CN105631337B/zh
Priority to JP2016017104A priority patent/JP6469028B2/ja
Priority to US15/164,323 priority patent/US9460306B1/en
Application granted granted Critical
Publication of US9384364B1 publication Critical patent/US9384364B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/468—Specific access rights for resources, e.g. using capability register
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/564—Static detection by virus signature recognition
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/568—Computer malware detection or handling, e.g. anti-virus arrangements eliminating virus, restoring damaged files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Definitions

  • the disclosure relates to the field of computer science, and more specifically, to a system and method for controlling access of a native image of a machine code to resources of an operating system of a computer device.
  • a .NET application may be created using a certain number of assemblies together, where an assembly is a binary file serviced by a Common Language Runtime (“CLR”) environment.
  • CLR Common Language Runtime
  • a .NET assembly includes the following metadata elements:
  • the PE header identifies that the assembly can be loaded and executed in operating systems of the Windows® family.
  • the PE header also identifies the type of application (e.g., console application, application with graphic user interface, code library and the like).
  • the CLR header constitutes data that can support all .NET assemblies so that they can be maintained in the CLR environment.
  • the CLR header contains such data as flags, CLR versions, entry point (e.g., in a particular instance, the address for the beginning of the function Main( )), which allows the executing environment to determine the makeup of the file being managed (i.e., a file containing managed code).
  • Each assembly contains CIL code, which is an intermediate code not dependent on the processor.
  • the CIL code is compiled in real time mode by a JIT (just in time, i.e., dynamic compilation) compiler into instructions corresponding to the requirements of the specific processor.
  • JIT just in time, i.e., dynamic compilation
  • the metadata is used to determine the location of types on in the binary file, for the placement of the types in memory, and to simplify the process of a remote call for the methods of the types.
  • the assembly may also contain a manifest, which describes each module making up the assembly, the version of the assembly, and also any external assemblies to which the current assembly makes reference.
  • the manifest also contains all metadata needed to specify the requirements of the assembly for versions and the identity of the assembly, as well as all the metadata needed to determine the scope of the assembly and to allow links to resources and classes.
  • the following table shows the data contained in the manifest of an assembly. The first four elements—name of the assembly, version number, language and regional parameters, as well as the strong name data—constitute the identity of the assembly.
  • Information Information used by the execution environment to on Links to compare the links to types with the files containing their Types declarations and implementations. This involves types which are exported by the assembly.
  • Information A list of other assemblies for which there are static on Links to links from the given assembly. Each link includes the Assemblies name of the dependent assembly, the metadata of the assembly (version, language and regional parameters, operating system, etc.) and the public key, if the assembly has a strong name.
  • Any .NET assembly may contain any given number of embedded resources, such as application icons, graphic files, audio fragments or string tables.
  • An assembly can consist of several modules.
  • a module is a part of an assembly, i.e., a logical collection of code or resources.
  • the hierarchy of entities used in the assembly is: assembly>module>type (classes, interfaces, structures, enumerations, delegates)>method.
  • a module can be internal (i.e., inside a file of the assembly) or external (i.e., a separate file).
  • a module does not have an entry point, nor does it have any individual version number, and therefore it cannot be loaded directly by the CLR environment.
  • Modules can only be loaded by the main module of the assembly, such as a file containing the manifest of the assembly.
  • the manifest of the module contains only an enumeration of all external assemblies.
  • Each module has a Module Version Identifier (“MVID”), which is a unique identifier written out in each module of the assembly, which changes during each compilation.
  • MVID Module Version Identifier
  • FIG. 1A illustrates an exemplary layout of a single-file assembly.
  • all requirement elements e.g., headers, CIL code, metadata of types, the manifest and resources
  • FIG. 1B illustrates an example of a multiple-file assembly.
  • a multiple-file assembly consists of a set of .NET modules that are deployed in the form of a single logical unit and provided with the same version number. Typically, one of these modules is called the main module and contains the manifest of the assembly and also may contain all necessary CIL instructions, metadata, headers and additional resources.
  • the manifest of the main module describes all the other related modules on which the operation of the main module depends.
  • the secondary modules in a multiple-file assembly may be assigned the extension *.netmodule.
  • the secondary *.netmodule modules also contain CIL code and metadata of types, as well as a manifest of the level of the module, in which the external assemblies needed by the given module are enumerated.
  • an assembly can be signed with a digital signature (e.g., an X.509) that is situated in the overlay of the PE file or digitally-signed catalog file (.cat).
  • a StrongName signature is used in addition or separately, i.e., a hash generated by using the contents of the assembly and the RSA private key.
  • the hash is situated in the assembly between the PE header and the metadata. The hash makes it possible to check for no change in the assembly since the time when it was compiled. For a single-file assembly, free bytes are left after the PE header when the file is compiled. The hash of the file is then calculated using the private key and the resulting hash is entered into these available bytes.
  • the technology is different for multiple-file assemblies. Besides the hash of the main file of the assembly, hashes are also calculated for the external modules, after which the data is entered into the main assembly. The modules do not have their own signatures and they have different MVIDs from the main module. The following items are entered into manifest of the assembly:
  • assemblies are divided into: private and public/shared. Private assemblies should always be located in the same catalog as the client application in which they are used (i.e., the application catalog) or in one of its subcatalogs.
  • a public assembly can be used at the same time in several applications on the same device.
  • Public assemblies are not situated inside the same catalog as the applications in which they are supposed to be used. Instead, they can be installed in a global assembly cache (GAC).
  • GAC global assembly cache
  • the GAC can be located in several places at the same time as shown in the following table:
  • a strong name is the modern-day .NET equivalent of the global unique identifier (GUID) that was used in COM. Unlike the GUID values in COM, which are 128-bit numbers, the .NET strong names are based in part on two interrelated cryptographic keys, known as a public key and a secret (private) key.
  • GUID global unique identifier
  • a strong name consists of a set of interrelated data, including, at least:
  • a user can obtain the public and private key, for example, the data of the public and private keys is generated by the utility sn.exe, provided as part of the .NET Framework SDK.
  • This utility generates a file containing data for two different, yet mathematically related keys—the public and private keys. The locations of this file are then indicated to the compiler, which writes the full value of the public key in the manifest of the assembly.
  • the compiler generates on the basis of the entire content of the assembly (e.g., CIL code, metadata, etc.) a corresponding hash.
  • the hash is a numerical value that is statistically unique to fixed input data. Consequently, in the event of a change in any data of a .NET assembly (even a single character in a string literal), the compiler will generate a different hash.
  • the generated hash then combines with the private key data contained inside the file to obtain the digital signature, inserted in the assembly inside the CLR header data.
  • FIG. 1C illustrates an exemplary process for generating a strong name.
  • the private key data is not indicated in the manifest, but used only to identify the content of the assembly by the digital signature (along with the generated hash).
  • the assembly can be installed in the GAC.
  • the path to the assembly in the GAC can be, for example:
  • ⁇ GAC_32 is the GAC_architecture of the processor
  • ⁇ KasperskyLab is the name of the assembly
  • ⁇ 2.0.0.0_b03f5f7f11d50a3a is the version of the assembly_public key marker
  • KasperskyLab.dll is the ⁇ assembly name.extension.
  • the execution of the code of an assembly occurs as follows. First, the PE header is analyzed to determine which process should be started (32 or 64 bit). Next, the selected file version MSCorEE.dll is loaded (C: ⁇ Windows ⁇ System32 ⁇ MSCorEE.dll for 32-bit systems).
  • An example of the source code of an assembly is presented as follows:
  • the JIT compiler transforms the CIL code into machine commands.
  • FIG. 2 illustrates an exemplary method of executing an assembly code.
  • the CLR environment finds all the declared types (classes) (for example, the type Console).
  • the CLR environment determines the methods, combining them in a record inside a unified “structure” (one method each, as defined in the type Console).
  • the entries contain the addresses at which the implementations of the methods can be found.
  • the JIT compiler is called up.
  • the JIT compiler is aware of the method being called up and the type which defines this method. Once called up, the JIT compiler searches in the metadata of the corresponding assembly for the implementation of the method code (i.e., the code implementing the method WriteLine(string str)).
  • the JIT compiler then compiles the CIL code into machine code and saves the compiled code in dynamic memory.
  • the JIT compiler returns to the internal “structure” of the type data (Console) and replaces the address of the method being called up with the address of the memory section with the machine code.
  • the method Main( ) again accesses the method WriteLine(string str). Since the code has already been compiled, the access is without a JIT compiler call. After executing the method WriteLine(string str) control returns to the method Main( ).
  • the native images mentioned above solve the problem of slow working of the function at the time of the first call.
  • an image will be loaded from which the machine code will be executed.
  • the JIT compiler does not need to compile anything and/or also create the data structures each time again. All of this is taken from the image.
  • An image can be created for any given .NET assembly regardless of whether or not it is installed in the GAC.
  • one uses the utility ngen.exe, located by the path %WINDIR% ⁇ Microsoft.NET ⁇ Framework ⁇ Framework_version> ⁇ ngen.exe.
  • NIC Native Image Cache
  • the path to the compilable image is formed as follows, for example: C: ⁇ Windows ⁇ assembly ⁇ NativeImages_v4.0.30319_32 ⁇ Kaspersky ⁇ 9c87f327866f53aec68d4fee40 cde33d ⁇ Kaspersky.ni.dll, where
  • C: ⁇ Windows ⁇ assembly ⁇ NativeImages is the path to the image cache in the system
  • v4.0.30319_32 is ⁇ version.NET Framework>_ ⁇ processor architecture (32 or 64)>;
  • Kaspersky is the friendly name of the assembly
  • 9c87f327866f53aec68d4fee40cde33d is the hash of the application.
  • Kaspersky.ni.dll is ⁇ friendly name of the assembly>.ni. ⁇ extension>.
  • the Native Image Service is used to control the images. This allows the developers to postpone the installation, updating and removal of images in machine code, these procedures being carried out later on, when the device is standing still.
  • Native Image Service is launched by the program installing the application or the update. This is done by means of the utility ngen.exe.
  • the service works with a queue of requests saved in the Windows® registry, each of the requests having its own priority. The priority established determines when the task will be performed.
  • images in machine code are created not only on the initiative of the developers or administrators, but also automatically by the .NET Framework platform.
  • the .NET Framework platform automatically creates an image, tracking the work of the JIT compiler.
  • creating an image during the operation of an application takes too much time, and, therefore, this operation is often carried out later on, for which purpose the CLR environment places the tasks in a queue and executes them during a standstill of the device.
  • the CLR environment uses the assembly binding module (i.e., the Assemble Binder) to find assemblies for loading at the moment of executing the corresponding assembly.
  • the CLR may use several kinds of binding modules.
  • An image binding module i.e., a Native Binder
  • the searching for a required image is performed in two stages—first, the given module identifies the assembly and image in the file system and, second, the given module checks the correspondence of the image to the assembly.
  • FIG. 3 illustrates a method of operating the binding module.
  • the assembly binding module searches for the assembly, the search is performed in the GAC, which presupposes that the sought assembly is signed and the content of the assembly is not read; and in the application catalog where the assembly is opened and the metadata is read.
  • step 320 the image binding module searches for an image in the NIC corresponding to the identified assembly. In the event that the image is identified, this is checked in step 330 , and the image binding module reads the necessary data and metadata from the image in step 340 , to ensure that the image satisfies certain criteria, for which a careful analysis is performed, including, but not limited to, reviewing:
  • the MVID is used for the check.
  • the image is analyzed to determine whether it is current and control is transferred to the JIT compiler in step 370 if it is not current. Otherwise, the code from the image is loaded in step 360 .
  • the number of native images substantially exceeds the number of assemblies and the native images generated by the same parent assembly may differ from one device to another and from one image version to another, all of which greatly complicates the task of categorizing the images.
  • Some conventional file categorization methods use cloud services and the like, but no solutions have been created that are able to correctly and efficiently categorize an image.
  • an example method for controlling access of a native image of a machine code to resources of an operating system of a device includes obtaining, by the hardware processor, the native image of the machine code; identifying, by the hardware processor, a parent assembly from which the native image was created; determining, by the hardware processor, a category of trust of the parent assembly; determining, by the hardware processor, a category of trust of the native image based on the category of trust of the parent assembly; and restricting, by the hardware processor, access of the native image that has an untrusted category of trust to the resources of the operating system of the device.
  • the category of trust of the native image corresponds to the category of trust of the parent assembly.
  • the method further includes: determining a correspondence between the native image and the parent assembly; and determining, based on the determined correspondence, whether the native image is modified.
  • an example method for controlling access of a native image of a machine code to resources of an operating system of a device includes: restricting, by a hardware processor, writing access to the native image of the machine code; identifying, by the hardware processor, a parent assembly which was used to create the native image having a restricted writing access; updating, by the hardware processor, the native image based on the parent assembly; determining, by the hardware processor, a category of trust of the parent assembly; assigning, by the hardware processor, a category of trust of the parent assembly to the updated native image; and restricting, by the hardware processor, access of the updated native image that has an untrusted category of trust to the resources of the operating system of the device.
  • writing access is restricted to all processes except for ngen.exe.
  • updating of the native image of the machine code includes replacing the native image having the restricted writing access with a new native image of the machine code of the parent assembly.
  • FIG. 1 a illustrates an exemplary layout of a single-file assembly.
  • FIG. 1 b illustrates an example of a multiple-file assembly.
  • FIG. 1 c illustrates an exemplary process for generating a strong name.
  • FIG. 2 illustrates an exemplary method of executing an assembly code.
  • FIG. 3 illustrates a method of operating the binding module.
  • FIG. 4 illustrates an exemplary method of categorizing images according to one aspect.
  • FIG. 5 illustrates an exemplary structure of an image according to one aspect.
  • FIG. 6 illustrates an exemplary method for assigning a category to an image according to one aspect.
  • FIG. 7 illustrates an example of a general-purpose computer system on which the disclosed systems and method can be implemented.
  • Example aspects are described herein in the context of a system, method and computer program product for controlling access of a native image of a machine code to resources of an operating system of a device.
  • Those of ordinary skill in the art will realize that the following description is illustrative only and is not intended to be in any way limiting. Other aspects will readily suggest themselves to those skilled in the art having the benefit of this disclosure.
  • FIG. 4 illustrates an example method of categorizing images according to one aspect.
  • an image is obtained.
  • the image may be obtained from the native image cache “NIC”) (e.g., if the image is installed on a device and being used as intended on the device), and, in another example, the image may be obtained from any other image repository (such as when the device is being used as storage and the images are not being used as intended on the device).
  • the category of trust of the image is determined.
  • a request is made to a database to determine the category of trust of the image, where, the checksum of the image can be used.
  • the MVID of the image can be used. Templates are also used to determine the category of the image. The mechanism of working with templates is discussed in more detail below.
  • the parent assembly from which the image was created is determined.
  • MVID e.g., Windows Registry
  • binding module e.g., binding module
  • strong name e.g., strong name
  • a determination by the MVID may be used, for example, when a database exists containing the MVIDs of the assemblies existing on the current device.
  • the MVID of the image may be identified in the database containing the MVIDs of the assemblies.
  • the parent assembly may be determined from the entries in the registry when an entry in the registry is created during the creation of the image(s). An example of such an entry is discussed in more detail above.
  • the entry may contain information about the path to the parent assembly, information about the native image and a various ancillary data. By comparison of data from the registry and data obtained from the analyzed image, a parent assembly may be identified.
  • the parent assembly may be determined from the strong name used for images created from strong-named assemblies.
  • the components of the strong name of the parent assembly are extracted from the image, the strong name is generated, and on the basis of this data, the path is determined to the parent assembly in the GAC on the device or in a database saving the assemblies in an orderly manner according to the strong names.
  • the process to determine the parent assembly depends on a number of factors, which may include, for example, the location of the parent assembly and the image (e.g., the user's device or a remote or local database), the possibility of compromising the assembly and the image at their place of storage, the method of naming the assembly (strong name or ordinary name), and so on.
  • the correspondence between the native image and the assembly is determined in step 421 .
  • This step is performed if there is a likelihood that the native image (after being created) might have been altered without authorization (e.g., it may be compromised, corrupted or the like) at the storage location.
  • an algorithm may be employed to determine the correspondence that uses an image binding module (discussed above).
  • an image from this assembly i.e., original native image, which is a guaranteed unmodified image
  • the comparison can be performed on byte by byte basis.
  • the modification of the images is allowed only to trusted processes, such as ngen.exe only, for example, while other processes are only permitted to read data from the native image.
  • the mechanism of templates may be employed to determine the correspondence between an image and the parent assembly.
  • the image is considered to be compromised (i.e., malicious).
  • a compromised image may differ from the original image by the CIL code, the machine code, the metadata of the types, the information contained in the CLR and PE headers and the like.
  • FIG. 5 illustrates an exemplary structure of a native image according to one aspect.
  • the native image like the parent assembly, has a certain structure.
  • the assembly KasperskyLab.dll and the image KasperskyLab.ni.dll contain metadata and code, where the assembly contains exclusively CIL code, while the native image in a particular aspect also contains machine code and the structure NativeImageHeader.
  • the template KasperskyLab.dll.tmpl (discussed above) is generated and associated (i.e., correspondence established) with the parent assembly and the image created from it.
  • the exemplary system and method uses, for example, the intelligent hash technique (also known as local sensitive hash).
  • the template is generated as shown in FIG. 5 .
  • data i.e., the manifest, the metadata, the CIL code, and the like
  • data is extracted from the assembly.
  • the same data as well as the machine code are extracted from the native image.
  • the data, which is unchanged for each of the possible versions of the image created from the same parent assembly, is processed (for example, the check sum is calculated from it) and the hash is formed and placed in the template.
  • the data, which changes from one version to another of the image, such as the machine code, is also processed and an intelligent hash is generated accordingly.
  • a function call journal for the machine code is generated, a listing with disassembled machine code, or any other entity reflecting the logic of implementation of the given machine code; and the intelligent hash is formed from these entities.
  • these entities are used directly in the template.
  • the template is formed so as to unambiguously relate (establish the correspondence of) the parent assembly and the image, regardless of the image versions depending on the software and hardware configuration of the device.
  • the logic of execution of the image code ceases to correspond to the logic of execution of the assembly code, no correspondence is established between the parent assembly and the image on the basis of the template, and the image is determined to not correspond to the assembly.
  • the template When the template is used, it is found that the updated image corresponds to the parent assembly (i.e., the logic of execution of the machine code remains the same).
  • a malicious program is installed on the device, which modifies the image Kaspersky.ni.dll.
  • the template when used, it is determined that the image modified by the malicious program does not correspond to the parent assembly (e.g., the logic of execution of the machine code differs from the logic embedded in the parent assembly).
  • a category of trust of an assembly is the degree of trust in the assembly (trusted or untrusted) on the part of the protection system of the device, such as an antivirus application.
  • the danger status of an assembly in the context of the present disclosure can be: dangerous or not dangerous.
  • the danger status of an assembly determines the danger of an assembly to the device on which that assembly is installed.
  • the danger of an assembly to a device includes, in one example aspect, the possibility of theft of data from the device, substitution of data, or unauthorized modification of the software of the device during the execution of the code of the assembly.
  • Trusted assemblies include assemblies that are not dangerous as determined by the protection system.
  • the protection system of the device in assigning a category of trust to an assembly, does so locally in the context of the current state on the device and on the basis of information about the assembly.
  • information is the danger status of the assembly.
  • the danger status of an assembly may be determined by using identification information of the assembly, such as the MVID of the assembly, the strong name of the assembly, the check sum of the assembly and the like.
  • a request is organized to a reputation database in step 431 .
  • the database resides on the device on which the assembly is stored and in another aspect the base resides remotely.
  • the assembly If the assembly is known (i.e., information about it is contained in the reputation database), then the assembly already has a danger status of not dangerous or dangerous, accordingly, depending on the information from the reputation database. If the identification information of the assembly is not contained in the database, the assembly is considered to be unknown, i.e., the assembly does not have a status (i.e., status undetermined). If the assembly has a not dangerous status, then in one particular aspect the assembly receives the category of trusted. In another particular aspect, the category of the assembly is determined from other factual and statistical information about the assembly, for example, by way of installing the assembly on a device or its affiliation with installed packages whose danger status is known.
  • the factual information about the assembly is information about the digital signature (for example, the StrongName of the signature or X.509).
  • the digital signature should be validated.
  • identification information is obtained about the digital signature of the assembly, which contains information about the manufacturer or the hash of the file or parts thereof, for example.
  • the signature may be located either in the assembly or in the catalog (i.e., catalog signature).
  • the danger status of the digital signature of an assembly is determined by using the identification information of the signature, for which an inquiry is organized to a reputation database. If the signature is known (i.e., information about the signature is contained in the reputation database), then the signature already has a status of not dangerous or dangerous.
  • the signature is considered to be unknown, i.e., the signature does not have a status (i.e., status unknown).
  • the signature has the status not dangerous, then in a particular aspect the assembly is given the category of trusted, and if the signature has the status dangerous, then in a particular aspect the assembly is given the category of untrusted.
  • Status is assigned to signatures in various ways. In one particular aspect, the status of the signatures depends on the manufacturer. In another aspect, the status of the signatures is assigned by inheritance from the installer, whose signature status is known. In another aspect, the status of a signature is assigned depending on the popularity of the signature, for example, the more popular the signature, the higher level of trust is assigned.
  • the category of trust is determined by an antivirus checking of the assembly, for which various methods are used to detect a malicious program, including signature, heuristic, statistical, and the like. In this aspect, if the assembly is found to be not dangerous from the results of the antivirus check, the assembly receives the category of trusted. Otherwise, the assembly is considered untrusted.
  • the category of trust of the image is determined.
  • the image is assigned the category of trust determined for the parent assembly.
  • the category of the image is determined by the method described above for step 410 .
  • the exemplary system and method confirms that the repository of images has not been and will not be changed without authorization according to an exemplary aspect.
  • FIG. 6 illustrates an example method for assigning a category to an image.
  • access is limited to the repository of images or at least to one image.
  • the restricting comprises only allowing trusted processes or a finite number of certain trusted processes to modify an image, such as only the process ngen.exe, all other processes being only allowed read access.
  • the restricting includes total blocking of access to write into the repository as a whole or at least to one image.
  • step 610 the parent assembly used to create the image whose access has been restricted is determined.
  • step 620 at least one image is updated (e.g., replaced by another image).
  • the updating includes in removing a previously created image and creating a new image by the operating system (e.g., by running ngen.exe on the parent assembly or by an automatic image creation service).
  • only part of the image data is updated, such as the machine code, and the updating is done by trusted processes. In the first case, the image after its removal is created anew.
  • this is performed immediately, and in another case, the creation is postponed for a certain length of time, for example, until the running of the parent assembly, as determined in step 610 , of the image being updated.
  • the category of the parent assembly is assigned to the image.
  • the antivirus application uses categories of trust in its operation, for example, it removes native images having a category of trust of untrusted, or substantially restricts their use, for example, it limits their access to the resources provided by the operating system.
  • the antivirus application may perform antivirus scan of detected parent assembly, and exclude the native image of the machine code from the antivirus analysis, but associate results of the antivirus scan of the parent assembly with the native image of the machine code. This improves the performance of antivirus analysis of the computer system, when only parent assemblies are being scanned, while the created from them native images of machine code will inherit the category of trust and/or danger status (the verdict) of the assembly. Therefore antivirus scan of the native images is not performed.
  • FIG. 7 illustrates an example of a general-purpose computer system (which may be a personal computer or a server) on which the disclosed systems and method can be implemented according to an example aspect.
  • the computer system includes a central processing unit 21 , a system memory 22 and a system bus 23 connecting the various system components, including the memory associated with the central processing unit 21 .
  • the system bus 23 is realized like any bus structure known from the prior art, containing in turn a bus memory or bus memory controller, a peripheral bus and a local bus, which is able to interact with any other bus architecture.
  • the system memory includes permanent memory (ROM) 24 and random-access memory (RAM) 25 .
  • the basic input/output system (BIOS) 26 includes the basic procedures ensuring the transfer of information between elements of the personal computer 20 , such as those at the time of loading the operating system with the use of the ROM 24 .
  • the personal computer 20 includes a hard disk 27 for reading and writing of data, a magnetic disk drive 28 for reading and writing on removable magnetic disks 29 and an optical drive 30 for reading and writing on removable optical disks 31 , such as CD-ROM, DVD-ROM and other optical information media.
  • the hard disk 27 , the magnetic disk drive 28 , and the optical drive 30 are connected to the system bus 23 across the hard disk interface 32 , the magnetic disk interface 33 and the optical drive interface 34 , respectively.
  • the drives and the corresponding computer information media are power-independent modules for storage of computer instructions, data structures, program modules and other data of the personal computer 20 .
  • the present disclosure provides the implementation of a system that uses a hard disk 27 , a removable magnetic disk 29 and a removable optical disk 31 , but it should be understood that it is possible to employ other types of computer information media 56 which are able to store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random-access memory (RAM) and so on), which are connected to the system bus 23 via the controller 55 .
  • solid state drives, flash memory cards, digital disks, random-access memory (RAM) and so on which are connected to the system bus 23 via the controller 55 .
  • the computer 20 has a file system 36 , where the recorded operating system 35 is kept, and also additional program applications 37 , other program modules 38 and program data 39 .
  • the user is able to enter commands and information into the personal computer 20 by using input devices (keyboard 40 , mouse 42 ).
  • Other input devices can be used: microphone, joystick, game controller, scanner, and so on.
  • Such input devices usually plug into the computer system 20 through a serial port 46 , which in turn is connected to the system bus, but they can be connected in other ways, for example, with the aid of a parallel port, a game port or a universal serial bus (USB).
  • a monitor 47 or other type of display device is also connected to the system bus 23 across an interface, such as a video adapter 48 .
  • the personal computer can be equipped with other peripheral output devices (not shown), such as loudspeakers, a printer, and so on.
  • the personal computer 20 is able to operate in a network environment, using a network connection to one or more remote computers 49 .
  • the remote computer (or computers) 49 are also personal computers or servers having the majority or all of the aforementioned elements in describing the nature of a personal computer 20 , as shown in FIG. 4 .
  • Other devices can also be present in the computer network, such as routers, network stations, peer devices or other network nodes.
  • Network connections can form a local-area computer network (LAN) 50 and a wide-area computer network (WAN). Such networks are used in corporate computer networks and internal company networks, and they generally have access to the Internet.
  • LAN or WAN networks the personal computer 20 is connected to the local-area network 50 across a network adapter or network interface 51 .
  • the personal computer 20 can employ a modem 54 or other modules for providing communications with a wide-area computer network such as the Internet.
  • the modem 54 which is an internal or external device, is connected to the system bus 23 by a serial port 46 . It should be noted that the network connections are only examples and need not depict the exact configuration of the network, i.e., in reality there are other ways of establishing a connection of one computer to another by technical communication modules.
  • the systems and methods described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the methods may be stored as one or more instructions or code on a non-transitory computer-readable medium.
  • Computer-readable medium includes data storage.
  • such computer-readable medium can comprise RAM, ROM, EEPROM, CD-ROM, Flash memory or other types of electric, magnetic, or optical storage medium, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a processor of a general purpose computer.
  • module refers to a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or field-programmable gate array (FPGA), for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device.
  • a module can also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software.
  • a module can be executed on the processor of a general purpose computer (such as the one described in greater detail in FIG. 6 above). Accordingly, each module can be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Virology (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)
US14/811,135 2015-03-31 2015-07-28 System and method of controlling access of a native image of a machine code to operating system resources Active US9384364B1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP15184119.4A EP3076292B1 (en) 2015-03-31 2015-09-07 System and method of controlling access of a native image of a machine code to operating system resources
CN201610067701.6A CN105631337B (zh) 2015-03-31 2016-01-29 控制机器代码的本机图像访问操作系统资源的系统及方法
JP2016017104A JP6469028B2 (ja) 2015-03-31 2016-02-01 オペレーティング・システム・リソースに対する機械語のネイティブイメージのアクセス制御のシステム及び方法
US15/164,323 US9460306B1 (en) 2015-03-31 2016-05-25 System and method for controlling access of machine code to operating system resources

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2015111422A RU2635271C2 (ru) 2015-03-31 2015-03-31 Способ категоризации сборок и зависимых образов
RU2015111422 2015-03-31

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/164,323 Continuation US9460306B1 (en) 2015-03-31 2016-05-25 System and method for controlling access of machine code to operating system resources

Publications (1)

Publication Number Publication Date
US9384364B1 true US9384364B1 (en) 2016-07-05

Family

ID=56234946

Family Applications (2)

Application Number Title Priority Date Filing Date
US14/811,135 Active US9384364B1 (en) 2015-03-31 2015-07-28 System and method of controlling access of a native image of a machine code to operating system resources
US15/164,323 Active US9460306B1 (en) 2015-03-31 2016-05-25 System and method for controlling access of machine code to operating system resources

Family Applications After (1)

Application Number Title Priority Date Filing Date
US15/164,323 Active US9460306B1 (en) 2015-03-31 2016-05-25 System and method for controlling access of machine code to operating system resources

Country Status (5)

Country Link
US (2) US9384364B1 (zh)
EP (1) EP3076292B1 (zh)
JP (1) JP6469028B2 (zh)
CN (1) CN105631337B (zh)
RU (1) RU2635271C2 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2660643C1 (ru) * 2017-09-29 2018-07-06 Акционерное общество "Лаборатория Касперского" Система и способ выявления вредоносного CIL-файла
CN110531971A (zh) * 2019-08-29 2019-12-03 深圳市今天国际物流技术股份有限公司 访问代码自动生成方法、装置、计算机设备及存储介质
US10530957B2 (en) * 2014-08-11 2020-01-07 Avision Inc. Image filing method
US10713359B2 (en) 2017-09-29 2020-07-14 AO Kaspersky Lab System and method of identifying a malicious intermediate language file
US10846403B2 (en) * 2018-05-15 2020-11-24 International Business Machines Corporation Detecting malicious executable files by performing static analysis on executable files' overlay
EP4006716A4 (en) * 2019-07-22 2023-07-26 Connectfree Corporation COMPUTING SYSTEM AND INFORMATION PROCESSING PROCEDURES

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180073041A (ko) * 2016-12-22 2018-07-02 삼성전자주식회사 전자 장치, 그 제어 방법 및 컴퓨터 판독가능 기록 매체
DE102018000471A1 (de) * 2018-01-22 2019-07-25 Giesecke+Devrient Mobile Security Gmbh Blockchain-basiertes Identitätssystem
CN108984413A (zh) * 2018-07-24 2018-12-11 浙江数链科技有限公司 分支代码管理方法及装置
KR20230043235A (ko) * 2019-06-10 2023-03-30 구글 엘엘씨 펌웨어의 보안 검증

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5579478A (en) * 1995-05-16 1996-11-26 Hewlett-Packard Company System administration module for an operating system affords graded restricted access privileges
US6199181B1 (en) * 1997-09-09 2001-03-06 Perfecto Technologies Ltd. Method and system for maintaining restricted operating environments for application programs or operating systems
US20070186070A1 (en) * 2006-02-03 2007-08-09 Neoware, Inc. Computer operating system with selective restriction of memory write operations
US20120157049A1 (en) * 2010-12-17 2012-06-21 Nichola Eliovits Creating a restricted zone within an operating system
US8621647B1 (en) * 2010-01-11 2013-12-31 Google Inc. Restricting privileges of first privileged process in operating system using second privileged process
US20140208426A1 (en) 2008-05-28 2014-07-24 Zscaler, Inc. Systems and methods for dynamic cloud-based malware behavior analysis
US20140222876A1 (en) * 2013-02-05 2014-08-07 International Business Machines Corporation File system extended attribute support in an operating system with restricted extended attributes
US20150347774A1 (en) * 2014-05-30 2015-12-03 Apple Inc. Restricted resource classes of an operating system
US20160048409A1 (en) * 2014-08-12 2016-02-18 Peter Briel System and method for automatic initiation and management of a guest operating system which enables a restriction of access to the host machine

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7124408B1 (en) * 2000-06-28 2006-10-17 Microsoft Corporation Binding by hash
US6993751B2 (en) * 2001-05-14 2006-01-31 Microsoft Corporation Placing exception throwing instructions in compiled code
US7051322B2 (en) * 2002-12-06 2006-05-23 @Stake, Inc. Software analysis framework
US20060143689A1 (en) * 2004-12-21 2006-06-29 Docomo Communications Laboratories Usa, Inc. Information flow enforcement for RISC-style assembly code
CN101300584B (zh) * 2005-08-06 2012-02-29 微软公司 防止对软件或运行时数据的未经授权的修改的方法
CN101359355B (zh) * 2007-08-02 2010-07-14 芯微技术（深圳）有限公司 Windows系统下受限帐户提升用户权限的方法
US8424082B2 (en) * 2008-05-08 2013-04-16 Google Inc. Safely executing an untrusted native code module on a computing device
US9250938B2 (en) * 2008-10-15 2016-02-02 Microsoft Technology Licensing, Llc Caching runtime generated code
US8752016B2 (en) * 2008-12-15 2014-06-10 Apple Inc. Converting JavaScript into a device-independent representation
CN101615230A (zh) * 2009-08-07 2009-12-30 浪潮电子信息产业股份有限公司 一种文件可信执行和可信保护的方法
US8924922B2 (en) * 2010-06-14 2014-12-30 Microsoft Corporation Pre-compiling hosted managed code
JP2012164081A (ja) * 2011-02-04 2012-08-30 Toshiba Corp 中間コード検査システム、中間コード検査方法、及び中間コード検査プログラム
US9584877B2 (en) * 2011-06-16 2017-02-28 Microsoft Technology Licensing, Llc Light-weight validation of native images
CN102663318B (zh) * 2012-03-22 2015-04-08 百度在线网络技术（北京）有限公司 一种浏览器进程权限的控制方法
US9569184B2 (en) * 2012-09-05 2017-02-14 Microsoft Technology Licensing, Llc Generating native code from intermediate language code for an application
US8732674B1 (en) * 2012-11-14 2014-05-20 Microsoft Corporation Revertable managed execution image instrumentation

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5579478A (en) * 1995-05-16 1996-11-26 Hewlett-Packard Company System administration module for an operating system affords graded restricted access privileges
US6199181B1 (en) * 1997-09-09 2001-03-06 Perfecto Technologies Ltd. Method and system for maintaining restricted operating environments for application programs or operating systems
US20070186070A1 (en) * 2006-02-03 2007-08-09 Neoware, Inc. Computer operating system with selective restriction of memory write operations
US7395394B2 (en) * 2006-02-03 2008-07-01 Hewlett-Packard Development Company, L.P. Computer operating system with selective restriction of memory write operations
US20140208426A1 (en) 2008-05-28 2014-07-24 Zscaler, Inc. Systems and methods for dynamic cloud-based malware behavior analysis
US8621647B1 (en) * 2010-01-11 2013-12-31 Google Inc. Restricting privileges of first privileged process in operating system using second privileged process
US20120157049A1 (en) * 2010-12-17 2012-06-21 Nichola Eliovits Creating a restricted zone within an operating system
US20140222876A1 (en) * 2013-02-05 2014-08-07 International Business Machines Corporation File system extended attribute support in an operating system with restricted extended attributes
US9053108B2 (en) * 2013-02-05 2015-06-09 International Business Machines Corporation File system extended attribute support in an operating system with restricted extended attributes
US20150347774A1 (en) * 2014-05-30 2015-12-03 Apple Inc. Restricted resource classes of an operating system
US20160048409A1 (en) * 2014-08-12 2016-02-18 Peter Briel System and method for automatic initiation and management of a guest operating system which enables a restriction of access to the host machine

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Denning; A lattice model of secure information flow; Published in: Magazine Communications of the ACM CACM Homepage archive; vol. 19 Issue 5, May 1976; pp. 236-243; ACM Digital Library. *
Sandhu et al.; Access control: principle and practice; Published in: IEEE Communications Magazine (vol. 32 , Issue: 9 ); pp. 40-48; Date of Publication: Sep. 1994; IEEE Xplore. *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10530957B2 (en) * 2014-08-11 2020-01-07 Avision Inc. Image filing method
RU2660643C1 (ru) * 2017-09-29 2018-07-06 Акционерное общество "Лаборатория Касперского" Система и способ выявления вредоносного CIL-файла
US10713359B2 (en) 2017-09-29 2020-07-14 AO Kaspersky Lab System and method of identifying a malicious intermediate language file
US10846403B2 (en) * 2018-05-15 2020-11-24 International Business Machines Corporation Detecting malicious executable files by performing static analysis on executable files' overlay
EP4006716A4 (en) * 2019-07-22 2023-07-26 Connectfree Corporation COMPUTING SYSTEM AND INFORMATION PROCESSING PROCEDURES
CN110531971A (zh) * 2019-08-29 2019-12-03 深圳市今天国际物流技术股份有限公司 访问代码自动生成方法、装置、计算机设备及存储介质
CN110531971B (zh) * 2019-08-29 2023-01-03 深圳市今天国际物流技术股份有限公司 访问代码自动生成方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
US9460306B1 (en) 2016-10-04
EP3076292A1 (en) 2016-10-05
JP6469028B2 (ja) 2019-02-13
RU2635271C2 (ru) 2017-11-09
US20160292450A1 (en) 2016-10-06
RU2015111422A (ru) 2016-10-27
EP3076292B1 (en) 2017-07-19
CN105631337A (zh) 2016-06-01
CN105631337B (zh) 2018-05-29
JP2016197399A (ja) 2016-11-24

Similar Documents

Publication Publication Date Title
US9460306B1 (en) System and method for controlling access of machine code to operating system resources
US7823186B2 (en) System and method for applying security policies on multiple assembly caches
KR100965706B1 (ko) 코드 재기입이 가능한 컴퓨터 장치 및 코드 재기입 방법
JP5437550B2 (ja) ファームウェアの必要なメモリ容量を減らすシステム及び方法
US9332021B2 (en) Methods and systems for preventing security breaches
JP5992622B2 (ja) 悪意あるアプリケーション診断装置及び方法
US11507669B1 (en) Characterizing, detecting and healing vulnerabilities in computer code
US8424093B2 (en) System and method for updating antivirus cache
US20170277524A1 (en) Dynamic container deployment with parallel conditional layers
US8146162B1 (en) System and method for acceleration of malware detection using antivirus cache
US20070289019A1 (en) Methodology, system and computer readable medium for detecting and managing malware threats
US10216510B2 (en) Silent upgrade of software with dependencies
US9367686B1 (en) System and method for antivirus checking of native images of software assemblies
US11397812B2 (en) System and method for categorization of .NET applications
JP5736335B2 (ja) アプリケーション解析装置、アプリケーション解析システム、およびプログラム
KR20050079625A (ko) 객체 지향 프로그래밍 언어 및 툴에서의 버전닝 지원 방법
RU2628920C2 (ru) Способ обнаружения вредоносных сборок
RU2625052C1 (ru) Способ ограничения доступа образа машинного кода к ресурсам операционной системы
RU2617925C2 (ru) Способ антивирусной проверки компьютерной системы
JP7084160B2 (ja) 起動制御装置、起動制御システム、起動制御方法、及び、起動制御プログラム
CN114185556A (zh) 一种智能合约部署方法、装置、设备以及存储介质

Legal Events

Date Code Title Description
AS Assignment

Owner name: AO KASPERSKY LAB, RUSSIAN FEDERATION

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:IVANOV, DMITRY G.;PAVLOV, NIKITA A.;SHVETSOV, DMITRY V.;AND OTHERS;REEL/FRAME:036197/0356

Effective date: 20150715

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8