EP3029564B1 - System and method for providing access to original routines of boot drivers - Google Patents
System and method for providing access to original routines of boot drivers Download PDFInfo
- Publication number
- EP3029564B1 EP3029564B1 EP15156673.4A EP15156673A EP3029564B1 EP 3029564 B1 EP3029564 B1 EP 3029564B1 EP 15156673 A EP15156673 A EP 15156673A EP 3029564 B1 EP3029564 B1 EP 3029564B1
- Authority
- EP
- European Patent Office
- Prior art keywords
- boot
- driver
- interceptor
- drivers
- routines
- 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
Links
- 238000000034 method Methods 0.000 title claims description 34
- 230000002155 anti-virotic effect Effects 0.000 claims description 16
- 238000004590 computer program Methods 0.000 claims description 5
- 230000008569 process Effects 0.000 description 11
- 230000003287 optical effect Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 238000001514 detection method Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000005192 partition Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000013515 script Methods 0.000 description 3
- 241000700605 Viruses Species 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 238000007630 basic procedure Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
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/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- 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/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
-
- 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/561—Virus type analysis
-
- 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/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
-
- 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/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/575—Secure boot
-
- 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 present disclosure relates to the field of computer security, and more specifically, to systems and methods for providing access to original routines of boot drivers.
- US 2007/0209032 A1 discloses a driver verification component for verifying that a driver component processes I/O requests in a specified amount of time, and the driver verification component can be enabled for selected drivers and/or selected checks without rebooting the system.
- WO 01/67252 A1 discloses a method of providing secure communication with kernel-level components of a computer system having an operating system that includes user space and kernel space by means of locating an authentication module in the kernel space, in communicably coupled relation with the kernel-level components, to selectively encrypt and decrypt communications between the kernel-level components and a remote site, and by locating a transport module in the kernel space, in communicably coupled relation with the authentication module, to selectively transmit and receive the communications.
- US8479292B1 discloses a boot driver security management system for detecting and correcting infected boot drivers, wherein a valid entry point for each of a plurality of boot drivers running under an operating system is gleaned by a reading and operating system component such as the registry to obtain an inventory of boot drivers running under the operating system, and then reading a valid entry point for each boot driver from a corresponding image on disc, so that this results in gleaning the valid entry points for infected boot drivers, because if a boot driver has been infected, attempts to access the infected boot driver are diverted by the malicious code to a clean copy from which the valid entry point is gleaned, wherein the gleaned valid entry points of the boot drivers are stored in the registry.
- a rootkit is a type of malware that is frequently used by a third party (usually an intruder) to gain access to a computer system intended to conceal running processes, files or system data, which helps an intruder maintain access to a system without the user's knowledge.
- a general description of the most common techniques used by root kits is disclosed in CHRIS RIES: "Inside Windows Rootkits", [Online], 22 May 2006 (2006-05-22), XP002426314, Retrieved from the Internet: URL:http://www.vigilantminds.com> [retrieved on 2007-03-23].
- a rootkit typically hides logins, processes, threads, registry keys, files, and logs and may include software to intercept data from terminals, network connections, and the keyboard.
- Rootkits are capable of infecting boot drivers that are executed during loading of an operating system (OS) and thus before any antivirus software is loaded on the system. Rootkits may also be embedded in operating system processes in a filter-like manner, so that any regular malware detection means cannot get information related to hidden software or software pieces.
- OS operating system
- Rootkits may also be embedded in operating system processes in a filter-like manner, so that any regular malware detection means cannot get information related to hidden software or software pieces.
- rootkits typically activate themselves before the operating system has completely booted up upon startup of the computer, and rootkits usually acquire system privileges.
- rootkits typically take steps to mask their existence, and prevent conventional antivirus detection mechanisms from identifying their existence. For example, a typical antivirus software invokes a system function call to identify the processes that are currently running. The rootkit intercepts the function call, and provides its own return parameters to the antivirus software, but masks its own process. Also, the rootkit typically hides the files in which it is stored from conventional antivirus mechanisms that check whether files contain known virus signatures.
- the invention is set out in the independent claims.
- a method for accessing routines of boot drivers of the operating system comprises: identifying, by the driver interceptor, boot drivers that have been loaded into a memory of the computer, but have not been initialized by a boot loader of the operating system, wherein identification of boot drivers is performed using a list of boot drivers that have been loaded into the memory of the computer, but have not been initialized by the boot loader of the operating system; installing, by the driver interceptor, an interceptor handler operable to intercept calls of initialization routines of the identified boot drivers, wherein the interceptor handler is operable to replace an address of an original entry point of the boot driver, which is contained in a list of boot drivers, with an address of an entry point of the intercept handler, wherein the original entry point of the boot driver is stored in the intercept handler; intercepting, by the driver interceptor, the program calls to the initialization routines of the identified boot drivers when the identified boot drivers are initialized by the boot loader of the operating system; storing, by the interceptor handler, information about the identified boot
- the list of boot drivers is read by the driver interceptor in a system registry.
- the list of boot drivers is read by the driver interceptor using the boot loader of the operating system.
- the information about the boot driver is saved in a memory region of the computer allocated for the driver interceptor.
- the information about the boot driver obtained during initialization of the boot driver contains one or more of: the name of the boot driver; the address of the entry points of some or all of the initialization routines of the boot driver; the parameters transferred to the boot driver by the boot loader of the operating system during initialization; the path to the driver in the registry; the address of the entry point; and the driver object structure.
- a computer system for accessing routines of boot drivers of an operating system comprises: a memory for storing an antivirus application configured to place a driver interceptor into a master boot record of the computer system before other boot drivers; a hardware processor coupled to the memory and configured to: identify, by the driver interceptor, the boot drivers that have been loaded into the memory, but have not been initialized by a boot loader of the operating system, wherein identification of boot drivers is performed using the list of boot drivers that have been loaded into the memory of the computer, but have not been initialized by the boot loader of the operating system; install, by the driver interceptor, an interceptor handler operable to intercept calls of initialization routines of the identified boot drivers, wherein the interceptor handler is operable to replace an address of an original entry point of the boot driver, which is contained in a list of boot drivers, with an address of an entry point of the intercept handler, wherein the original entry point of the boot driver is stored in the intercept handler; intercept, by the driver interceptor, the program calls to the initialization routines
- a computer program product stored on a non-transitory computer readable storage medium, includes computer executable instructions for performing the above-mentioned method steps.
- Example aspects are described herein in the context of a system, method and computer program product for detecting access of boot driver routines by malware.
- 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. 1 shows an example of a process of booting an operating system (OS), including the phase of initialization of the driver interceptor.
- OS operating system
- Such a process of booting the OS is characteristic of the majority of OSs, such as Windows, Unix, OS X, Android and others.
- BIOS basic input/output system
- the BIOS basic input/output system
- POST power-on self-test
- the self-test process terminates when the BIOS finds the system partition of the hard disk, reads the MBR (master boot record) and starts the boot manager (for example, in the Windows OS, Bootmgr.exe).
- the boot manager finds the OS boot loader in the system partition of the hard disk (such as Winload.exe in the Windows OS) and starts it in step 102.
- the BIOS has been replaced by the UEFI (Unified Extensible Firmware Interface), and the MBR by the GPT (GUID Partition Table - a format standard for layout of partition table on a physical hard disk using globally unique identifiers (GUID)), respectively, which can be used in the present invention.
- UEFI Unified Extensible Firmware Interface
- GPT globally unique identifiers
- the OS boot loader initializes the boot-start system drivers needed to read data from the disk and initialize the OS kernel.
- the OS boot loader loads the system registry hive and the system drivers needed to initialize the OS, after which it sends the data which has been read to the OS kernel.
- the driver interceptor installed by the antivirus application is initialized.
- loading of the driver interceptor before the other drivers can be assured by installing an early boot group in the registry.
- the value SERVICE_BOOT_START of the StartType entry read from the INF file of the driver, will be written into the registry.
- the antivirus application can change the list of booting groups.
- step 106 the other boot drivers are initialized and in step 107 the ordinary drivers and the software are initialized.
- the booting of the OS ends in step 108.
- a rootkit has been installed on the computer, its driver can also be initialized in step 107.
- Fig. 2 shows a method of intercepting the call of the boot driver initialization routine.
- the OS boot loader 210 transfers control in turn by means of the PnP Manager (Plug and Play Manager - a manager that provides the support for PnP functionality in Windows) to the entry point 221 of each boot driver 220 (hereinafter, for purposes of illustration, this will be called a driver).
- the OS boot loader 210 transfers to the boot driver 220, as arguments, the pointer to the driver object (a structure containing pointers to the driver routines; for example, in the Windows OS, the structure DRIVER_OBJECT) and the path to the driver key in the registry.
- the routine DriverEntry is responsible for the initialization 222 of the driver, whose entry point is Driverlnit - a member of the structure DRIVER_OBJECT.
- the driver interceptor 230 Since the driver interceptor 230 was initialized as one of the first among the boot drivers in step 105, after initialization it finds and reads the list of boot drivers that have been loaded into memory but not yet initialized. In one example, this list can be read in the system registry or with the use of the OS boot loader 210 (for example, in the Windows OS, the list may be kept in the structure KeLoaderBlock, formed and transferred to the entry point of the OS kernel by the OS boot loader).
- the list of noninitialized boot drivers may contain the following information:
- the driver interceptor 230 installs an intercept handler 231, which is needed to intercept the calls of the initialization routines of the boot drivers.
- the intercept handler 231 of the initialization routines of the boot drivers when installed, the intercept handler 231 replaces the address of the entry point of the boot driver 220, whose pointer is contained in the list of boot drivers, with the address of the entry point of the intercept handler 231, wherein the original entry point of the driver 221 will be kept by the intercept handler 231.
- the OS boot loader 210 transfers control to the entry point 221, the control will be intercepted by the intercept handler 231.
- the intercept handler 231 then transfers the control to the previously saved original entry point of the driver 221.
- control will be transferred back to the intercept handler 231 which caused the initialization of the driver 220.
- the intercept handler 231 saves information about the boot driver 220 that is provided by the driver in the course of its initialization.
- the information can contain:
- information about the boot driver 220, as well as its original entry point, can be saved in the memory region allocated for the driver interceptor.
- step 108 various applications of user level are able to call up access routines.
- accessing the driver routines By accessing the driver routines, access can be gained to the hardware of various devices via the drivers of these devices.
- a rootkit may intercept the calls by applications for driver routines in the memory with subsequent filtering of the access to the corresponding devices.
- the driver interceptor 230 accesses the original routines of the boot drivers.
- the SCSI Port Driver is responsible for working with the disk. Access to the driver routines responsible for working with disk requests (such as IRP_MJ_INTERNAL_DEVICE_CONTROL, IRP_MJ_SCSI) will also occur via the original addresses (i.e., not modified by the rootkit) with the aid of the driver interceptor 230.
- the antivirus check may include signature analysis, heuristic analysis, emulation, checking by use of a reputation service, and others.
- the antivirus application may perform the removal of the rootkit: the file on the disk, the malicious code loaded into the memory, and other traces of the activity of the rootkit may be deleted.
- the computer may also be restarted. In certain cases, a restarting of the computer is also needed for complete removal of the malicious code loaded into the memory.
- the antivirus application may formulate a cure script, which will be implemented in an early stage of the OS booting. After this, it is necessary to restart the computer.
- the cure script may contain, for example, the address of the location of the rootkit files on the disk and a command to remove them.
- the rootkit will be removed by one of the anti-rootkit drivers of the antivirus that is responsible for implementing the cure scripts.
- any other antivirus application driver (such as the anti-rootkit driver) can implement the accessing of the original routines of the boot drivers.
- Fig. 3 shows an example of a general-purpose computer system (which may be a personal computer or a server) 20, which may be used to implement examples of system and methods disclosed herein.
- the computer system 20 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, including 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 read only 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 work 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. 5 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)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (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)
- Stored Programmes (AREA)
Description
- The present disclosure relates to the field of computer security, and more specifically, to systems and methods for providing access to original routines of boot drivers.
- Methods for verifying driver component behavior are known from the prior art.
- For example,
US 2007/0209032 A1 discloses a driver verification component for verifying that a driver component processes I/O requests in a specified amount of time, and the driver verification component can be enabled for selected drivers and/or selected checks without rebooting the system. -
WO 01/67252 A1 -
US8479292B1 discloses a boot driver security management system for detecting and correcting infected boot drivers, wherein a valid entry point for each of a plurality of boot drivers running under an operating system is gleaned by a reading and operating system component such as the registry to obtain an inventory of boot drivers running under the operating system, and then reading a valid entry point for each boot driver from a corresponding image on disc, so that this results in gleaning the valid entry points for infected boot drivers, because if a boot driver has been infected, attempts to access the infected boot driver are diverted by the malicious code to a clean copy from which the valid entry point is gleaned, wherein the gleaned valid entry points of the boot drivers are stored in the registry. - A rootkit is a type of malware that is frequently used by a third party (usually an intruder) to gain access to a computer system intended to conceal running processes, files or system data, which helps an intruder maintain access to a system without the user's knowledge. A general description of the most common techniques used by root kits is disclosed in CHRIS RIES: "Inside Windows Rootkits", [Online], 22 May 2006 (2006-05-22), XP002426314, Retrieved from the Internet: URL:http://www.vigilantminds.com> [retrieved on 2007-03-23]. A rootkit typically hides logins, processes, threads, registry keys, files, and logs and may include software to intercept data from terminals, network connections, and the keyboard. Rootkits are capable of infecting boot drivers that are executed during loading of an operating system (OS) and thus before any antivirus software is loaded on the system. Rootkits may also be embedded in operating system processes in a filter-like manner, so that any regular malware detection means cannot get information related to hidden software or software pieces.
- One of the difficulties with detecting rootkits is due to the fact that, unlike viruses, rootkits typically activate themselves before the operating system has completely booted up upon startup of the computer, and rootkits usually acquire system privileges. Also, rootkits typically take steps to mask their existence, and prevent conventional antivirus detection mechanisms from identifying their existence. For example, a typical antivirus software invokes a system function call to identify the processes that are currently running. The rootkit intercepts the function call, and provides its own return parameters to the antivirus software, but masks its own process. Also, the rootkit typically hides the files in which it is stored from conventional antivirus mechanisms that check whether files contain known virus signatures.
- Therefore, there is a need to improve detection of rootkits and similar types of malware.
- Disclosed are examples of a system, a method and a computer program product for providing access to original routines of boot drivers of an operating system of a computer. The invention is set out in the independent claims.
- In one example embodiment, a method for accessing routines of boot drivers of the operating system comprises: identifying, by the driver interceptor, boot drivers that have been loaded into a memory of the computer, but have not been initialized by a boot loader of the operating system, wherein identification of boot drivers is performed using a list of boot drivers that have been loaded into the memory of the computer, but have not been initialized by the boot loader of the operating system; installing, by the driver interceptor, an interceptor handler operable to intercept calls of initialization routines of the identified boot drivers, wherein the interceptor handler is operable to replace an address of an original entry point of the boot driver, which is contained in a list of boot drivers, with an address of an entry point of the intercept handler, wherein the original entry point of the boot driver is stored in the intercept handler; intercepting, by the driver interceptor, the program calls to the initialization routines of the identified boot drivers when the identified boot drivers are initialized by the boot loader of the operating system; storing, by the interceptor handler, information about the identified boot driver that is provided by the boot driver in the course of its initialization, wherein the information contains at least an address of the entry point for one or more routines of the identified boot drivers; and accessing, by the driver interceptor, the routines of the identified boot drivers using the previously stored addresses of the entry points for one or more routines.
- In one example, the list of boot drivers is read by the driver interceptor in a system registry.
- In one example, the list of boot drivers is read by the driver interceptor using the boot loader of the operating system.
- In one example, the information about the boot driver is saved in a memory region of the computer allocated for the driver interceptor.
- In one example, the information about the boot driver obtained during initialization of the boot driver contains one or more of: the name of the boot driver; the address of the entry points of some or all of the initialization routines of the boot driver; the parameters transferred to the boot driver by the boot loader of the operating system during initialization; the path to the driver in the registry; the address of the entry point; and the driver object structure.
- In another example, a computer system for accessing routines of boot drivers of an operating system comprises: a memory for storing an antivirus application configured to place a driver interceptor into a master boot record of the computer system before other boot drivers; a hardware processor coupled to the memory and configured to: identify, by the driver interceptor, the boot drivers that have been loaded into the memory, but have not been initialized by a boot loader of the operating system, wherein identification of boot drivers is performed using the list of boot drivers that have been loaded into the memory of the computer, but have not been initialized by the boot loader of the operating system; install, by the driver interceptor, an interceptor handler operable to intercept calls of initialization routines of the identified boot drivers, wherein the interceptor handler is operable to replace an address of an original entry point of the boot driver, which is contained in a list of boot drivers, with an address of an entry point of the intercept handler, wherein the original entry point of the boot driver is stored in the intercept handler; intercept, by the driver interceptor, the program calls to the initialization routines of the identified boot drivers when the identified boot drivers are initialized by the boot loader of the operating system; store, by the interceptor handler, information about the identified boot drivers that is provided by the boot driver in the course of its initialization, wherein information contains at least an address of the entry point for one or more routines of the identified boot driver; and provide access, by the driver interceptor, to the routines of the identified boot driver by previously stored addresses of the entry points for one or more routines.
- In another example, a computer program product, stored on a non-transitory computer readable storage medium, includes computer executable instructions for performing the above-mentioned method steps.
- The above simplified summary of example aspects serves to provide a basic understanding of the present disclosure. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects of the present disclosure. Its sole purpose is to present one or more aspects in a simplified form as a prelude to the more detailed description of the disclosure that follows. To the accomplishment of the foregoing, the one or more aspects of the present disclosure include the features described and particularly pointed out in the claims.
- The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate one or more example aspects of the present disclosure and, together with the detailed description, serve to explain their principles and implementations.
-
Fig. 1 shows an example of a process of booting an operating system. -
Fig. 2 shows an example method of intercepting the call of the boot driver initialization routine. -
Fig. 3 shows an example of a general-purpose computer system that may be used to implement systems and methods for detecting access of boot driver routines by malware. - Example aspects are described herein in the context of a system, method and computer program product for detecting access of boot driver routines by malware. 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. Reference will now be made in detail to implementations of the example aspects as illustrated in the accompanying drawings. The same reference indicators will be used to the extent possible throughout the drawings and the following description to refer to the same or like items.
-
Fig. 1 shows an example of a process of booting an operating system (OS), including the phase of initialization of the driver interceptor. Such a process of booting the OS is characteristic of the majority of OSs, such as Windows, Unix, OS X, Android and others. When the power supply of the computer is turned on, the BIOS (basic input/output system) is loaded instep 101, and with the help of the software and hardware written into the BIOS the computer equipment is initialized and the POST (power-on self-test) is run. The self-test process terminates when the BIOS finds the system partition of the hard disk, reads the MBR (master boot record) and starts the boot manager (for example, in the Windows OS, Bootmgr.exe). The boot manager finds the OS boot loader in the system partition of the hard disk (such as Winload.exe in the Windows OS) and starts it instep 102. It should be noted that in many modern computers the BIOS has been replaced by the UEFI (Unified Extensible Firmware Interface), and the MBR by the GPT (GUID Partition Table - a format standard for layout of partition table on a physical hard disk using globally unique identifiers (GUID)), respectively, which can be used in the present invention. - In
step 103, the OS boot loader initializes the boot-start system drivers needed to read data from the disk and initialize the OS kernel. Instep 104, the OS boot loader loads the system registry hive and the system drivers needed to initialize the OS, after which it sends the data which has been read to the OS kernel. Instep 105, the driver interceptor installed by the antivirus application is initialized. In one example, in the Windows OS, loading of the driver interceptor before the other drivers can be assured by installing an early boot group in the registry. For example, in the Windows OS, the value SERVICE_BOOT_START of the StartType entry, read from the INF file of the driver, will be written into the registry. Moreover, the antivirus application can change the list of booting groups. - Next, in
step 106, the other boot drivers are initialized and in step 107 the ordinary drivers and the software are initialized. The booting of the OS ends instep 108. In one example, if a rootkit has been installed on the computer, its driver can also be initialized in step 107. -
Fig. 2 shows a method of intercepting the call of the boot driver initialization routine. When the boot drivers are initialized instep 106, theOS boot loader 210 transfers control in turn by means of the PnP Manager (Plug and Play Manager - a manager that provides the support for PnP functionality in Windows) to theentry point 221 of each boot driver 220 (hereinafter, for purposes of illustration, this will be called a driver). In one example, theOS boot loader 210 transfers to theboot driver 220, as arguments, the pointer to the driver object (a structure containing pointers to the driver routines; for example, in the Windows OS, the structure DRIVER_OBJECT) and the path to the driver key in the registry. As an example, in the Windows OS, the routine DriverEntry is responsible for theinitialization 222 of the driver, whose entry point is Driverlnit - a member of the structure DRIVER_OBJECT. - In the process of
initialization 222 of theboot driver 220, the following actions are performed: - 1. The driver stores the entry points for the routines of the
driver 223 in the driver object or driver extension. Driver routines include both standard routines (for example, in the Windows OS: AddDevice, Startlo, Unload and others), and the driver's own routines. - 2. Various driver-wide objects used by the driver are created and/or initialized, and various system resources of the driver are installed.
- 3. The unused allocated memory is freed up.
- 4. The status of completion of the initialization of the
driver 224 and the ability to receive and execute requests from the PnP manager for the configuring, adding and running of devices is returned to the OS boot loader. - Since the
driver interceptor 230 was initialized as one of the first among the boot drivers instep 105, after initialization it finds and reads the list of boot drivers that have been loaded into memory but not yet initialized. In one example, this list can be read in the system registry or with the use of the OS boot loader 210 (for example, in the Windows OS, the list may be kept in the structure KeLoaderBlock, formed and transferred to the entry point of the OS kernel by the OS boot loader). - In one example, the list of noninitialized boot drivers may contain the following information:
- name;
- load address of the boot driver in the memory;
- path to the driver in the registry;
- object of the driver;
- address of the entry point.
- After obtaining the list of boot drivers, the
driver interceptor 230 installs anintercept handler 231, which is needed to intercept the calls of the initialization routines of the boot drivers. In one example, when theintercept handler 231 of the initialization routines of the boot drivers is installed, theintercept handler 231 replaces the address of the entry point of theboot driver 220, whose pointer is contained in the list of boot drivers, with the address of the entry point of theintercept handler 231, wherein the original entry point of thedriver 221 will be kept by theintercept handler 231. Thus, when theOS boot loader 210 transfers control to theentry point 221, the control will be intercepted by theintercept handler 231. Theintercept handler 231 then transfers the control to the previously saved original entry point of thedriver 221. - After completing the
initialization routine 224 control will be transferred back to theintercept handler 231 which caused the initialization of thedriver 220. Theintercept handler 231 saves information about theboot driver 220 that is provided by the driver in the course of its initialization. In one example, the information can contain: - the name of the
boot driver 220; - the address of the entry points of some or all of the routines of the
boot driver 220; - the parameters transferred to the
boot driver 220 by theOS boot loader 210 in the initialization process; - the path to the driver in the registry;
- the address of the entry point;
- the driver object structure.
- In yet another example, information about the
boot driver 220, as well as its original entry point, can be saved in the memory region allocated for the driver interceptor. - After the booting of the OS, in
step 108, various applications of user level are able to call up access routines. By accessing the driver routines, access can be gained to the hardware of various devices via the drivers of these devices. To conceal its presence and the presence of other malicious components in the system, a rootkit may intercept the calls by applications for driver routines in the memory with subsequent filtering of the access to the corresponding devices. - To prevent the malicious activity, in the last step of the present invention the
driver interceptor 230 accesses the original routines of the boot drivers. In the Windows OS, the SCSI Port Driver is responsible for working with the disk. Access to the driver routines responsible for working with disk requests (such as IRP_MJ_INTERNAL_DEVICE_CONTROL, IRP_MJ_SCSI) will also occur via the original addresses (i.e., not modified by the rootkit) with the aid of thedriver interceptor 230. Thus, if a rootkit is present in the system, it will be accessible to the antivirus application, despite attempts to conceal its operation (location of the file on the disk, control flows, and so on). As a consequence, the rootkit will be analyzed and discovered in the course of the normal antivirus check. In one example, the antivirus check may include signature analysis, heuristic analysis, emulation, checking by use of a reputation service, and others. - After detection, the antivirus application may perform the removal of the rootkit: the file on the disk, the malicious code loaded into the memory, and other traces of the activity of the rootkit may be deleted. To check whether the removal was successful, the computer may also be restarted. In certain cases, a restarting of the computer is also needed for complete removal of the malicious code loaded into the memory.
- In one example, if it is not possible to remove the rootkit or its parts, the antivirus application may formulate a cure script, which will be implemented in an early stage of the OS booting. After this, it is necessary to restart the computer. The cure script may contain, for example, the address of the location of the rootkit files on the disk and a command to remove them. During the booting of the OS the rootkit will be removed by one of the anti-rootkit drivers of the antivirus that is responsible for implementing the cure scripts.
- In one example, any other antivirus application driver (such as the anti-rootkit driver) can implement the accessing of the original routines of the boot drivers.
-
Fig. 3 shows an example of a general-purpose computer system (which may be a personal computer or a server) 20, which may be used to implement examples of system and methods disclosed herein. The computer system 20 includes acentral processing unit 21, asystem memory 22 and asystem bus 23 connecting the various system components, including the memory associated with thecentral processing unit 21. Thesystem bus 23 is realized like any bus structure known from the prior art, including 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 read only 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 theROM 24. - The personal computer 20, in turn, includes a
hard disk 27 for reading and writing of data, amagnetic disk drive 28 for reading and writing on removablemagnetic disks 29 and anoptical drive 30 for reading and writing on removableoptical disks 31, such as CD-ROM, DVD-ROM and other optical information media. Thehard disk 27, themagnetic disk drive 28, and theoptical drive 30 are connected to thesystem bus 23 across thehard disk interface 32, themagnetic disk interface 33 and theoptical 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 removablemagnetic disk 29 and a removableoptical disk 31, but it should be understood that it is possible to employ other types ofcomputer 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 thesystem bus 23 via thecontroller 55. - The computer 20 has a
file system 36, where the recordedoperating system 35 is kept, and alsoadditional program applications 37,other program modules 38 andprogram 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 (not shown) can be used: microphone, joystick, game controller, scanner, and so on. Such input devices usually plug into the computer system 20 through aserial 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). Amonitor 47 or other type of display device is also connected to thesystem bus 23 across an interface, such as avideo adapter 48. In addition to themonitor 47, 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 work 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. In LAN or WAN networks, the personal computer 20 is connected to the local-
area network 50 across a network adapter ornetwork interface 51. When networks are used, the personal computer 20 can employ amodem 54 or other modules for providing communications with a wide-area computer network such as the Internet. Themodem 54, which is an internal or external device, is connected to thesystem bus 23 by aserial 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. - In various examples, 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. By way of example, and not limitation, 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.
- In various examples, the systems and methods are described in the present disclosure in terms of modules. The term "module" as used herein 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. In certain implementations, at least a portion, and in some cases, all, of a module can be executed on the processor of a general purpose computer (such as the one described in greater detail in Fig. 5 above). Accordingly, each module can be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.
- In the interest of clarity, not all of the routine features of examples are disclosed herein. It will be appreciated that in the development of any actual implementation of the present disclosure, numerous implementation-specific decisions must be made in order to achieve the developer's specific goals, and that these specific goals will vary for different implementations and different developers. It will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill in the art having the benefit of this disclosure.
- Furthermore, it is to be understood that the phraseology or terminology used herein is for the purpose of description and not of restriction, such that the terminology or phraseology of the present specification is to be interpreted by the skilled in the art in light of the teachings and guidance presented herein, in combination with the knowledge of the skilled in the relevant art(s). Moreover, it is not intended for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such.
- The various examples disclosed herein encompass present and future known equivalents to the known modules referred to herein by way of illustration. Moreover, while examples and applications have been shown and described, it would be apparent to those skilled in the art having the benefit of this disclosure that many more modifications than mentioned above are possible without departing from the inventive concepts disclosed herein.
Claims (11)
- A method for accessing routines of boot drivers (220) of an operating system (35) of a computer (20), the method comprising:identifying, by a driver interceptor (230) placed into a master boot record of the computer system (20), boot drivers (220) that have been loaded into memory of the computer (20), but have not been initialized by a boot loader (210) of the operating system (35), wherein identification of boot drivers (220) is performed using a list of boot drivers (220) that have been loaded into the memory of the computer (20), but have not been initialized by the boot loader (210) of the operating system (35);installing, by the driver interceptor (230), an interceptor handler (231) operable to intercept calls of initialization routines of the identified boot drivers (220); wherein the interceptor handler (231) is operable to replace an address of an original entry point (221) of the boot driver (220), which is contained in the list of boot drivers (220), with an address of an entry point of the interceptor handler (231), wherein the original entry point (221) of the boot driver (220) is stored in the interceptor handler (231),intercepting, by the driver interceptor (230), the program calls to the initialization routines of the identified boot drivers (220) when the identified boot drivers (220) are initialized by the boot loader (210) of the operating system (35);storing, by the interceptor handler (231), information about the identified boot drivers (220) that is provided by the boot driver (220) in the course of its initialization, wherein the information contains at least an address of the entry point for one or more routines (223) of the identified boot drivers (220); and
accessing, by the driver interceptor (230), the routines (223) of the identified boot drivers (220) using the previously stored addresses of the entry points for one or more routines (223). - The method of claim 1, wherein the list of boot drivers (220) is read by the driver interceptor (230) in a system registry.
- The method of claim 1, wherein the list of boot drivers (220) is read by the driver interceptor (230) using the boot loader (210) of the operating system (35).
- The method of claim 3, wherein the information about the boot driver (220) is saved in a memory region of the computer (20) allocated for the driver interceptor (230).
- The method according to any of the preceding claims, wherein the information about the boot driver (220) is obtained during initialization of the boot driver (220) and contains one or more of: the name of the boot driver (220); the address of the entry points of some or all of the initialization routines of the boot driver (220); the parameters transferred to the boot driver (220) by the boot loader (210) of the operating system (35) during initialization; the path to the driver in the registry; the address of the entry point; and the driver object structure.
- A computer system for accessing routines of boot drivers (220) of an operating system (35) of a computer (20), the system comprising:a memory (22) for storing an antivirus application configured to place a driver interceptor (230) into a master boot record of the computer system before other boot drivers (220);a hardware processor (21) coupled to the memory (22),characterized in that the hardware processor (21) is configured to:identify, by the driver interceptor (230), boot drivers (220) that have been loaded into the memory (22), but have not been initialized by a boot loader (210) of the operating system (35), wherein identification of boot drivers (220) is performed using a list of boot drivers (220) that have been loaded into the memory (22) of the computer, but have not been initialized by the boot loader (210) of the operating system (35);install, by the driver interceptor (230), an interceptor handler (231) operable to intercept calls of initialization routines of the identified boot drivers (220); wherein the interceptor handler (231) is operable to replace an address of an original entry point (221) of the boot driver (220), which is contained in the list of boot drivers (220), with an address of an entry point of the interceptor handler (231), wherein the original entry point (221) of the boot driver (220) is stored in the interceptor handler (231),intercept, by the driver interceptor (230), the program calls to the initialization routines of the identified boot drivers (220) when the identified one or more boot drivers (220) are initialized by the boot loader (210) of the operating system (35);store, by the interceptor handler (231), information about the identified boot drivers (220) that is provided by the boot driver (220) in the course of its initialization, wherein the information contains at least an address of the entry point for one or more routines (223) of the identified boot drivers (220); and
access, by the driver interceptor (230), the routines (223) of the identified boot drivers (220) using the previously stored addresses of the entry points for one or more routines (223). - The system of claim 6, wherein the list of boot drivers (220) is read by the driver interceptor (230) in a system registry.
- The system of claim 6, wherein the list of boot drivers (220) is read by the driver interceptor (230) using the boot loader (210) of the operating system (35).
- The system of claim 8, wherein the information about the boot driver (220) is saved in a memory region of the computer (20) allocated for the driver interceptor (230).
- The system according to any of claims 6 to 9, wherein the information about the boot driver (220) is obtained during initialization of the boot driver (220) and contains one or more of: the name of the boot driver (220); the address of the entry points of some or all of the initialization routines of the boot driver (220); the parameters transferred to the boot driver (220) by the boot loader (210) of the operating system (35) during initialization; the path to the driver in the registry; the address of the entry point; and the driver object structure.
- A computer program product stored on a non-transitory computer-readable storage medium, the computer program product comprising computer-executable instructions for performing the method steps of claims 1-5.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
RU2014148959/08A RU2586576C1 (en) | 2014-12-05 | 2014-12-05 | Method of accessing procedures of loading driver |
US14/607,284 US9195832B1 (en) | 2014-12-05 | 2015-01-28 | System and method for providing access to original routines of boot drivers |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3029564A1 EP3029564A1 (en) | 2016-06-08 |
EP3029564B1 true EP3029564B1 (en) | 2017-02-22 |
Family
ID=54542895
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP15156673.4A Active EP3029564B1 (en) | 2014-12-05 | 2015-02-26 | System and method for providing access to original routines of boot drivers |
Country Status (4)
Country | Link |
---|---|
US (1) | US9195832B1 (en) |
EP (1) | EP3029564B1 (en) |
CN (1) | CN105678160B (en) |
RU (1) | RU2586576C1 (en) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9208105B2 (en) | 2013-05-30 | 2015-12-08 | Dell Products, Lp | System and method for intercept of UEFI block I/O protocol services for BIOS based hard drive encryption support |
CN106203070A (en) * | 2016-06-29 | 2016-12-07 | 北京金山安全软件有限公司 | Drive loading prevention method and device |
CN105956462B (en) * | 2016-06-29 | 2019-05-10 | 珠海豹趣科技有限公司 | A kind of method, apparatus and electronic equipment preventing malicious loading driving |
US10313121B2 (en) * | 2016-06-30 | 2019-06-04 | Microsoft Technology Licensing, Llc | Maintaining operating system secrets across resets |
CN108304209B (en) * | 2018-02-28 | 2021-01-15 | 联想(北京)有限公司 | Firmware upgrading method and firmware upgrading system |
JP7179482B2 (en) * | 2018-04-19 | 2022-11-29 | キヤノン株式会社 | Information processing device, control method, and its program |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8479292B1 (en) * | 2010-11-19 | 2013-07-02 | Symantec Corporation | Disabling malware that infects boot drivers |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4779187A (en) * | 1985-04-10 | 1988-10-18 | Microsoft Corporation | Method and operating system for executing programs in a multi-mode microprocessor |
US5974549A (en) * | 1997-03-27 | 1999-10-26 | Soliton Ltd. | Security monitor |
US20010044904A1 (en) | 1999-09-29 | 2001-11-22 | Berg Ryan J. | Secure remote kernel communication |
US7549055B2 (en) | 2003-05-19 | 2009-06-16 | Intel Corporation | Pre-boot firmware based virus scanner |
WO2005074032A1 (en) | 2004-01-28 | 2005-08-11 | Fujitsu Limited | Semiconductor device and its manufacturing method |
US7533415B2 (en) * | 2004-04-21 | 2009-05-12 | Trend Micro Incorporated | Method and apparatus for controlling traffic in a computer network |
US7571448B1 (en) * | 2004-07-28 | 2009-08-04 | Symantec Corporation | Lightweight hooking mechanism for kernel level operations |
US20070209032A1 (en) | 2006-02-23 | 2007-09-06 | Microsoft Corporation | Driver verifier |
US20080005797A1 (en) * | 2006-06-30 | 2008-01-03 | Microsoft Corporation | Identifying malware in a boot environment |
US7769992B2 (en) * | 2006-08-18 | 2010-08-03 | Webroot Software, Inc. | File manipulation during early boot time |
CN100504904C (en) * | 2007-12-25 | 2009-06-24 | 北京大学 | Windows concealed malevolence software detection method |
US7591019B1 (en) * | 2009-04-01 | 2009-09-15 | Kaspersky Lab, Zao | Method and system for optimization of anti-virus scan |
US8171272B1 (en) * | 2009-04-09 | 2012-05-01 | Symantec Corporation | Critical pre-OS driver verification |
US8516509B2 (en) | 2011-02-08 | 2013-08-20 | BlueStripe Software, Inc. | Methods and computer program products for monitoring system calls using safely removable system function table chaining |
RU2472215C1 (en) * | 2011-12-28 | 2013-01-10 | Закрытое акционерное общество "Лаборатория Касперского" | Method of detecting unknown programs by load process emulation |
RU2510074C2 (en) * | 2012-02-24 | 2014-03-20 | Закрытое акционерное общество "Лаборатория Касперского" | System and method of checking executable code before execution thereof |
JP5842683B2 (en) * | 2012-03-12 | 2016-01-13 | 富士通株式会社 | Information processing apparatus, memory dump program, and memory dump method |
-
2014
- 2014-12-05 RU RU2014148959/08A patent/RU2586576C1/en active IP Right Revival
-
2015
- 2015-01-28 US US14/607,284 patent/US9195832B1/en active Active
- 2015-02-26 EP EP15156673.4A patent/EP3029564B1/en active Active
- 2015-08-14 CN CN201510502331.XA patent/CN105678160B/en active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8479292B1 (en) * | 2010-11-19 | 2013-07-02 | Symantec Corporation | Disabling malware that infects boot drivers |
Also Published As
Publication number | Publication date |
---|---|
EP3029564A1 (en) | 2016-06-08 |
US9195832B1 (en) | 2015-11-24 |
CN105678160B (en) | 2019-03-08 |
RU2586576C1 (en) | 2016-06-10 |
CN105678160A (en) | 2016-06-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11269996B2 (en) | System and method for protecting memory pages | |
US10460099B2 (en) | System and method of detecting malicious code in files | |
US8892858B2 (en) | Methods and apparatus for trusted boot optimization | |
US10242186B2 (en) | System and method for detecting malicious code in address space of a process | |
EP3029564B1 (en) | System and method for providing access to original routines of boot drivers | |
RU2691187C1 (en) | System and methods for auditing a virtual machine | |
US9213829B2 (en) | Computing device including a port and a guest domain | |
US20150271139A1 (en) | Below-OS Security Solution For Distributed Network Endpoints | |
Heasman | Implementing and detecting a pci rootkit | |
US20090328195A1 (en) | Authentication and Access Protection of Computer Boot Modules in Run-Time Environments | |
US8572741B2 (en) | Providing security for a virtual machine by selectively triggering a host security scan | |
US9245122B1 (en) | Anti-malware support for firmware | |
KR20120000535A (en) | Providing silicon integrated code for a system | |
US9448888B2 (en) | Preventing a rollback attack in a computing system that includes a primary memory bank and a backup memory bank | |
EP2958045B1 (en) | System and method for treatment of malware using antivirus driver | |
US20200342109A1 (en) | Baseboard management controller to convey data | |
US9342694B2 (en) | Security method and apparatus | |
RU2585978C2 (en) | Method of invoking system functions in conditions of use of agents for protecting operating system kernel | |
US20190339960A1 (en) | System and Method to Deploy or Update Operating System Service Capabilities | |
RU2638735C2 (en) | System and method of optimizing anti-virus testing of inactive operating systems | |
EP3293660A1 (en) | System and method of detecting malicious code in files | |
RU2596577C2 (en) | Method of creating a system call handler | |
KR20110048014A (en) | Method and apparatus on computer platform |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20150226 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06F 21/57 20130101ALI20160803BHEP Ipc: G06F 9/44 20060101AFI20160803BHEP Ipc: G06F 21/56 20130101ALI20160803BHEP |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
INTG | Intention to grant announced |
Effective date: 20161004 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: PLFP Year of fee payment: 3 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: REF Ref document number: 869750 Country of ref document: AT Kind code of ref document: T Effective date: 20170315 |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602015001519 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG4D |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: MP Effective date: 20170222 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 869750 Country of ref document: AT Kind code of ref document: T Effective date: 20170222 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170522 Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170523 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170522 Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170622 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: NL Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20170222 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: IT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602015001519 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: MM4A |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20170226 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: PLFP Year of fee payment: 4 |
|
26N | No opposition filed |
Effective date: 20171123 |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20170228 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20170226 Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20170228 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MT Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20170226 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20180228 Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20180228 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO Effective date: 20150226 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: TR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170222 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20170622 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20231229 Year of fee payment: 10 Ref country code: GB Payment date: 20240108 Year of fee payment: 10 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: FR Payment date: 20240103 Year of fee payment: 10 |