As we are running with the same privileges as the kernel we can do this in an easier way and ensure that any changes to this mechanism in the future doesn't stop our ability to write to this memory.
Running in kernel mode we have the ability to change the CR0 register. The 16th bit of the CR0 register is responsible for enforcing whether or not the CPU can write to memory marked read-only. With this is mind we can rewrite the functions that we were using in functs.
I've changed the names to make it apparent that these functions are actually doing something different. To support hiding multiple files we need to implement a character device to communicate with the rootkit we could use a network connection but we'll take that up later and we need a method of storing the data. For storing the data we will use a linked list , the kernel has the ability to manipulate linked lists but I will create my own functions for doing this as a programming exercise later we will investigate how to use the features already in the kernel.
The structure of each element is defined at the top lines 1 - 4 , its pretty simple, just a basic singly linked list. Both of these functions take 1 argument, a string, and add or remove that string to the list depending on which function is called.
This functions takes a string as an argument and iterates through the list checking, first the length, and then the whole string, against every entry in the list, if it finds a match it returns a 1 , otherwise it returns a 0.
Initially I developed this linked list in a normal C application and just improved upon it and kernelfied it. Clearly this application is using more primitive versions of the addfile and remfile functions above. Its also using the usermode's malloc and free instead of vmalloc and vfree for obvious reasons.
I only included this to show how I've developed these functions in usermode and then converted it to kernelmode. Anyway, the kernel functions above addfile , remfile , emptylist and lookupfilename as well as the struct declarations and definition should go into the file list. Because we want to hide some files when the LKM is loaded and also empty the list when the LKM is unloaded we need to include the list.
Lastly we need to edit the Makefile to include list. So, as you can clearly see, our LKM automatically hides files on initialization and now should have the capability to hide multiple files.
We now need the ability to communicate with the LKM to dynamically hide and unhide files. Most ARK tools check for rookit-like behavior which is not always indicative of a malware infection. SSDT is a table that stores addresses of functions that are used by Windows. Whenever a function is called, Windows looks in this table to find the address for it.
Both Legitimate programs and rootkits can hook into and alter this table. Hooking is one of the techniques used by a rootkit to alter the normal execution path of the operating system. Rootkit hooks are basically installed modules which intercept the principal system services that all programs and the OS rely on. By using a hook, a rootkit can alter the information that the original OS function would have returned.
There are many tables in an OS that can be hooked by a rootkit and those hooks are undetectable unless you know exactly what you're looking for. API Kernel hooks are not always bad since some system monitoring software and security tools use them as well. If no hooks are active on a system it means that all system services are handled by ntoskrnl. ARK scanners do not differentiate between what is good and what is bad Therefore, even on a clean system some hidden essential components may be detected when performing a scan to check for the presence of rootkits.
As such, you should not be alarmed if you see any hidden entries created by legitimate programs after performing a scan. This interference can produce misleading or inaccurate scan results, false detection of legitimate files, cause unexpected crashes, BSODs , and general dross.
This 'dross' often makes it hard to differentiate between genuine malicious rootkits and the legitimate drivers used by CD Emulators. In most cases further investigation is requiredafter the initial ARK scan by someone trained in rootkit detection or with advanced knowledge of the operating system. However, if a rootkit has replaced the part of the kernel servicing those calls, it can return all the information the system monitor wants - except for anything relating to the rootkit.
Antivirus programs also use standard system calls, and this is why they are very poor at detecting rootkits on a running system. This ability to operate invisibly within the OS means that a major use of rootkits is to conceal other malware, which might in turn run in the outer rings of operating systems.
Some rootkits can even disable antivirus software. It's not unusual to find a highly sophisticated rootkit protecting a fairly simple piece of malware. So, how can they be discovered? Because a rootkit can actively defend against detection on a running operating system, the only way to be sure that it's not doing so is to prevent it from running.
The best way of doing this is to shut down the operating system itself and examine the disk upon which it is installed. Though this is specialised work, many antivirus vendors have woken up to the need for such tools, and now supply them free of charge. Based on Linux, this boots in place of the computer's operating system and scans the hard disk without any rootkit activity getting in the way. Once this is done, place the DVD in the drive and reboot the computer.
After a few seconds, the BitDefender boot menu will appear. Press [Enter], and after a few minutes a graphical desktop will load. BitDefender's software runs automatically from here. Click 'Continue' to start and the software will download and install the latest updates.
BitDefender then sets to work examining the disk. The software will run for 15 minutes or more depending on the size of your disk. It scans not only the operating system files but also the boot loader and other files, looking for signs of infection. Provided that any rootkits are listed in the downloaded definition files, this should identify any stealth malware it encounters - including the malware that the rootkit was shielding.
This is a convention in Linux and refers to the fact that the software mounts the system disk as it would any other storage device. Once you have completed the scan and hopefully found nothing, you can switch the system off and on again, remove the disk and boot into Windows.
Though it's harder to determine whether a running Windows system is infected with a rootkit, it can be done. One solution to this problem is the free utility GMER, which you can download from www. This randomises the filename. In theory, any lurking rootkit might be ready to block the GMER executable, but if the filename is random, it will be harder for this to happen.
You'll then download a zip file, which Windows Explorer should be able to open. Drag and drop the GMER. This can take a while, but don't be concerned about the long list that appears unless you see something red, which indicates a possible infection.
As it scans, GMER also produces information about the running system.
0コメント