This article is a logical continuation of the Simple SST Unhooker article. This article is written as an answer to the article Driver to Hide Processes and Files. Second Edition: Splicing by Serg Bratus.

I will try to oppose the splicing method to remove all the hooks, which setting is described in his article.

Written by:

Victor Milokum,
Team Leader of Network Security Team

Table of Contents

1.      Introduction
2.      Relocs.
3.      Import table
4.      Implementation
5.      Demonstration
6.      How to build

Introduction

What is the best way of dealing with splicing in the context of struggle with hidden processes? Obviously, the best way is to verify the whole ntoskernel image entirely.

The verification of the loaded (original) image with a file is provided in the previous article. But I analyzed only a part of ntoskernel - sdt / sst - there. It is possible to expand the functionality of the previous driver so that it passes through all the sections and verifies them, as the windbg !chkimg extension does:

"The !chkimg extension detects corruption in the images of executable files by comparing them to the copy on a symbol store or other file repository." (for more information, see http://msdn.microsoft.com/en-us/library/ff562217(v=vs.85).aspx).

In fact, we need to write something similar. We can use memory mapped files, just like I did in the previous article to compare the loaded ntoskernel with the file. The easiest way is to take the old driver as a basis and add the necessary functionality to it. As far as the executing ntoskernel.exe system is a standard PE file, the verification algorithm will repeat some actions of the PE loader.

PE loader works section by section as follows:

"It's important to note that PE files are not just mapped into memory as a single memory-mapped file. Instead, the Windows loader looks at the PE file and decides what portions of the file to map in. This mapping is consistent in that higher offsets in the file correspond to higher memory addresses when mapped into memory. The offset of an item in the disk file may differ from its offset once loaded into memory. However, all the information is present to allow you to make the translation from disk offset to memory offset (see Figure 1)." (for more information, see http://msdn.microsoft.com/en-us/magazine/cc301805.aspx)

That’s why we have to verify the file section by section too.

PE format is well described in the article mentioned above, so I will not describe it entirely. I will describe it only from a practical point of view.

The complete article text is available only for the registered users. Please Log In or Register.