Anti-debugging logs starting from scratch

Author: tongyongmc
I do not know what name should be appropriate, mainly for those who are preparing to debug the kernel
 
================= Programming environment ==================================
VS2008 + DDK + VA + DDKWIZARD
1. Install VS2008 and MSDN
2. Install DDK
3. Install ddkwizard_setup
4. Install Visual Assist X
5.-> Error 1 => Find ddkbuild. bat and ddkbuild. cmd and put them in the/windows/system32 directory.
6.-> Error 2 => Computer/.../environment variable, add two System Variables
1. W7BASE = D: \ WinDDK \ 7600.16385.1
2. WXPBASE = D: \ WinDDK \ 7600.16385.1
7.-> error 3 => VS2008/Tools/Options/Projects and Solutions/VC ++ Directories
Win32/Include files =>
Add D: \ WinDDK \ 7600.16385.1 \ inc \ api to the end. Otherwise, an error is prompted when compiling a common win32 application.
Add D: \ WinDDK \ 7600.16385.1 \ inc \ ddk to the end
Other: If the installation sequence is incorrect and VA cannot support DDK, add api and ddk to/Options/Projects/C ++ Directories of VA.
=> Custom/Stable include files, same as adding to the end
= Done =
 
1: error PRJ0019: A tool returned an error code from "Deming Makefile project actions"
=> 'Ddkbuild. cmd' is not an internal or external command or a runable program.
2: 1> DDKBLD: ERROR #3: To build using type W7 you need to set the % W7BASE % environment variable to point to the Windows 7/Windows 2008 Server R2 DDK base directory!
3: unable to track UNICODE_STRING in VS2008 by F12
 
 
=============== Dual-machine debugging ====================================
Windbg + VMware
1. Install VMware
2. Install Windbg (this is included in DDK)
3. Install IDA
4. VMware settings (with xp and win7 systems)
Xp:
Add the debug startup item to the c: \ boot. ini file.
[Operating systems]
Multi (0) disk (0) rdisk (0) partition (1) \ WINDOWS = "Microsoft Windows XP Professional"/noexecute = optin/fastdetect
Multi (0) disk (0) rdisk (0) partition (1) \ WINDOWS = "Microsoft Windows XP Professional-debug"/fastdetect/debug/debugport = com1/baudrate = 115200
 
Win7:
Add a debug startup Item in msconfig
Msconfig-> advanced options-> debugging, debugging port COM1, baud rate 115200
 
Modify the serial port settings of the two systems on VMware:
Connect when powering on
This terminal is a server
Another terminal is an application.
In I/o mode, the CPU usage is automatically abandoned during round robin.
Xp: Use named pipe \. \ pipe \ com_1
Win7: Use named pipe \. \ pipe \ com_2
 
5. Windbg settings
The symbolic path. xp and win7 symbols can all be placed in the same directory. If no, windbg automatically downloads the file to E: \ sysbols.
E: \ symbols; SRV * E: \ symbols * http://msdl.microsoft.com/download/symbols
 
Set two windbg shortcuts, modify the parameters, and connect the two VMS respectively.
Xp:
D: \ tools \ windbg \ windbg.exe-B-k com: port =\\\ pipe \ com_1, baud = 115200, pipe
Win7:
D: \ tools \ windbg \ windbg.exe-B-k com: port =\\\ pipe \ com_2, baud = 115200, pipe
 
6. dump two systems in windbg
Dumping the entire Windows 7 system memory (Full kernel dump) took me more than 40 hours...
(Creating a full kernel dump over the COM port is a VERY slow operation.) There are other connection methods except COM, but I won't ..
. Dump/f e: \ win7_dump.dmp
 
=============== Driver loading tool ==================================
A source code is provided later. If you like it, you can download it.
 
================== Preparation complete ==================================
So far, we have a driver loading tool that can add functions at any time, a win7 dump file, dual-machine debugging, and a programming environment.
 
============== Analyze the anti-debugging of the driver layer from scratch ==========
In the past, there was only reverse experience at the application layer. I have never touched on the driver and do not know about anti-debugging.
The following is a game-driven protection process that started around November 14 and ended in December 1.
The first appearance of a game is:
1. Game processes, daemon processes, and drivers
2. The target process cannot be seen in the OllyICE append list, and the target process name can be displayed normally in the task management column.
3. Windows 7: After removing two kernel Hook hooks, the OD can see the target process, but an error occurred while attaching the Hook! (Kernel hook viewed by xuetr)
4. Windows XP: Remove two kernel hooks and the game exits directly.
5. Use the Virtual Machine VMware + Windbg for debugging. An error is reported when the game starts!
6. VMware + Windows 7 [Debug]: after the game is started, the Windows 7 system has no response and can only restart the system.
7. VMware + Windows 7: The game can be started normally.
8. The OD loaded the game's main journey. The OD crashed and the module encountered an error. Error code: 0xc0000005 (the last error was caused by a long module name in the PE Structure. My OD is very old)
9. After the OD loads the game's main journey normally, there is detected information, and multiple attempts to find the information source are fruitless.
 
 
The above are the attempts made before November 17, and the most painful time-there is no direction at all. Then I adjusted my thinking direction and put my focus on 5th, 6, and 7 clues. The following is the main part of the debugging log at that time, which is slightly modified.
 
 
2010/11/17 debugging of ** finally broke through ^_^
It has never been known before ** how to identify whether the system is in Debug or normal state. After learning about the exception distribution mechanism in Windows, the process of Debug is different from that of normal state, mainly because KdpTrap and KdpStub correspond to different systems.
At this point, there are four areas related to dual-machine debugging: KdpDebugRoutine (function pointer), KdpBootedNodbug (bool), KdPitchDebugger (bool), and DebuggerEnabled (bool ).
You can change the system from Debug to normal by modifying KdpDebugRoutine to KdpStub and the other three flag. The Windbg is in the waiting state. ** It can be executed normally. After ** loading, modify the preceding four values and the Windbg can obtain the right to speak again!
******
Therefore, I will do another task, a driver, to allow the system to switch between Debug and normal states! In this way, I can debug the game at any time during running. If possible, it is best to allow the driver to communicate with OD at any time.
 
2010/11/18 complete driver loading Tool
Complete a general driver loading tool and test. You can switch the Debug system between Debug and normal. However, normal systems cannot be switched to Debug. The next step is to switch the normal system at will!
(This hasn't started yet ...)
 
2010/11/19
1. After testing, the converted system can perform dual-machine debugging and disconnect ws2_32! Send failed.
2. After XueTr is used to restore the two kernel hooks, the OD can see the ** process and the append fails.
3. failed to attach. use dual-machine debugging to view the cause! Key function kernel32! DebugActiveProcess.
 
Process kernel32! DebugActiveProcess-> ntdll! ZwDebugActiveProcess-> function no. 0x60-> KeServiceDescriptorTable [0] [0x60*4]-> nt! NtDebugActiveProcess
The preceding steps can be run successfully.
Failed to exist in ntdll! NtCreateThreadEx-> nt! NtCreateThreadEx:
After tracking, it is found that the final problem occurs at nt_RtlImageNtHeaderEx + 0x45 in the above line. Because the PE Header of the object ** process is erased, a failure value is returned when this function is judged!
In addition, if the kernel hook is not restored, the ** Pe Header is not rewritten. Once restored, a thread of ** will erase the PE Header, the OD cannot be attached.
(It's really good to have win7 dump in combination with ida)
 
2010/11 /??
** After comparing the blacklist and whitelist, determine whether to allow the target process.
By modifying the content of the blacklist and whitelist, the OD can be attached smoothly, but the module information of ** cannot be read!
(I don't know the specific date, but I started with nt from the two kernel hooks that I saw on xuetr! NtReadVirtualMemory, nt! NtWriteVirtualMemory. During this period, the White List of NtWriteVirtualMemory is obtained through this clue)
 
2010/11/22
After the related tools are created, the OD can see the target process and append the tool. However, an error occurs after the tool is attached, and the module information of the object cannot be seen. The target process is constantly resetting the debugport.
 
Multiple Threads have this action. One of them is constantly creating a thread, and the new thread is constantly checking the debugport. If you bypass the debugport check?
(There may be some inaccuracy here, but it is certain that a thread is clearing the debugport and has read many posts. The final clue is from the snow)
 
2010/11/23 ** reset debugport
Windbg writes a breakpoint to debugport
Kd> u** + 0x41764
** + 0x41764:
9b2fb764 8702 xchg eax, dword ptr [edx] // Reset
9b2fb766 6685e9 test cx, bp
9b2fb769 660fbae501 bt bp, 1
9b2fb76e 8b36 mov esi, dword ptr [esi]
9b2fb770 83 ecdc sub esp, 0 ffffdch
9b2fb773 0f886545ffff js ** + 0x35cde (9b2efcde)
9b2fb779 f5 cmc
9b2fb77a 3bf1 cmp esi, ecx
 
 
Manually modify the edx value and find that the od can survive normally after being attached. However, if this thread is suspended, the game will automatically exit soon after the od append!
 
Use the tool to modify the ** driver code (debugport is cleared). In Multiple tests, you can always attach the driver code, but in the real machine status, OD was soon detected. When the program exits, a dialog box is displayed, indicating that the daemon process is terminated abnormally. When the program exits, there will be a separate thread, freezing this thread, OD will survive for a long time.
(Up to now, there is no way to break the game breakpoint)
 
2010/11/25
OD is disconnected from the game, and the game exits abnormally. 0x80000003
 
2010/11/29
After learning about the HidePort of the thread, the production tool can break the breakpoint, but the OD will be detected. The main problem is that the RtlExitUserProcess function is called in thread 0x00cc0654 (This function also calls ZwTerminateProcess ).
This thread will be created without stopping the CreateThread API (function no. 0x58 ).
The question now is, are parameters passed in when this thread is created? If no parameter is passed, does this thread detect OD running ?!
Supplement: Because the HidePort of the game's main thread is set to 1, the kernel shields exceptions on the thread and sends them to the user layer. Therefore, the Code int3 modified by OD will cause an exception that causes the main thread to exit.
 
2010/11/30
In nt! NtCreatethreadEx is disconnected. There is no call to create thread 0x00cc0654! Therefore, we still cannot know where the thread 0x00cc0654 is created in the program. It is strange that the thread should be constantly created and the thread ID is always the same, but after retn, the thread will no longer be created .. (This is because the thread's entry point can always be disconnected)
 
2010/12/01
 
It basically implements OD additional debugging, but where does thread 0x00cc0654 come from, how is it created, and how to check OD? (Not solved, too many code variations)
 
 
Summary:
Most of the anti-debugging operations are at the driver level and are known technical points.
1. Reverse Debug system debugging system and normal version Switching
2. DebugPort clears nop and drops the relevant code segment.
3. Set HidePort of the main thread to 1 to reset HidePort
4. the kernel function hook is opened in whitelist mode. Find the whitelist and add it manually
5. 0x00cc0654 thread detection directly changes the thread entry to retn
 
 
 
I think many people outside of the kernel are wandering outside the door like me. In fact, it is not that difficult to do it as long as it is done.