Start debugging of Vista

Link: http://advdbg.org/blogs/advdbg_system/articles/784.aspx

Before Vista, ntldr is a Windows operating system loader. It is responsible for switching the CPU from the real mode to the protection mode, loading kernel files and startup drivers, then, the execution permission is handed over to the entry function of the kernel file, that is, kisystemstartup.

From the perspective of the task to be completed, ntldr is divided into two parts: one is responsible for accepting the execution right, performing mode switching, and checking the hardware, that is, preparing the startup. This part is usually called boot; the other part is responsible for loading the Kernel File and preparing the kernel for running. It is usually called osloader.

Vistawill split the above two shards into two independent program files, namely, bootmgrand winload.exe. Describes the relationship between bootmgr and winload and their functions during startup.

Unlike ntldr that needs to replace the check version when debugging ntldr, the debug engine has been built in both bootmgr and winload, which is consistent with the kernel practice. Therefore, if you want to debug bootmgr and winload, you do not need to replace these two program files as long as you start their internal debugging engines.

To enable bootmgr debugging, run the following command in the console window with administrator privileges:
Bcdedit/set {bootmgr} bootdebug on
Bcdedit/set {bootmgr} debugtype serial
Bcdedit/set {bootmgr} debugport 1
Bcdedit/set {bootmgr} baudrate 115200

The last three lines set the connection method between the debugger and the debugging engine. If 1394 is used, set it:

Bcdedit/set {bootmgr} debugtype 1394
Bcdedit/set {bootmgr} Channel 22

After the above settings, restart the system. After the BIOS stage, the screen will remain black, rendering unable to continue starting. In fact, this is bootmgr waiting to establish a connection with the debugger. After the cable is connected, start the windbg debugger and the two will establish a connection, displaying information similar to the following:

Microsoft (r) Windows debugger version 6.9.0003.113 x86
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \. \ COM1
Waiting to reconnect...
BD: boot debugger initialized
Connected to Windows boot debugger 6000x86 compatible target, ptr64 false
Kernel debugger connection established.
Symbol search path is: SRV * D: \ symbols * http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows boot debugger kernel version 6000 up free x86 compatible
Product: Unknown <ffffffff>, Suite: smallbusiness enterprise BackOffice communicationserver terminalserver extends embeddednt datacenter singleuserts personal blade embeddedrestricted securityappliance storageserver computeserver <8000>
Primary image base = 0x00400000 loaded module list = 0x004ffff8
System uptime: not available

0x00400000 is the base address of the bootmgr module. The main code of bootmgr is 32-bit, and only a small part of the 16-bit code is used to take control of the firmware. In addition, it is worth noting that bootmgr works in protection mode, but it does not enable the paging mechanism, but only uses the paging mechanism. Observe the values of the Cr0 AND Cr 3 registers to prove this:

Kd> r Cr0
Cr0 = 00000011
Kd> r 303.
32a = 00000000

After the connection is established, windbg allows bootmgr to continue running. The bootmgr usually displays the Start Menu. Press Ctrl + break, then bootmgr will be interrupted into the debugger. At this time, you can execute various kernel debugging commands, such:

Kd> LM
Start end module name
00400000 00514000 bootmgr (PDB symbols) D: \ symbols \ bootmgr. PDB \ 819f5a93195d47e424ed729b0d341191 \ bootmgr. PDB
Microsoft's symbolic server provides the public symbolic file of bootmgr. Therefore, as long as the path of the symbolic server is set, windbg can automatically download the appropriate symbolic file.

Kd> X bootmgr! *
0042b3fd bootmgr! Tpmapiauthsesscreateosap = <no type information>
0044c4da bootmgr! Cmpgetindexelementsize = <no type information>
00452d54 bootmgr! Rcconsolebaudrates = <no type information>
0042f56f bootmgr! Osxmlbrowser ::~ Osxmlbrowser = <no type information>
00431b10 bootmgr! Export stylesheet: getcontents = <no type information>

.......

Of course, you can also use the stack backtracking command to observe the function call situation:

Kd> kV
Childebp retaddr ARGs to child
00061e34 00347c7e 001b6380 00000001 00061e90 bootmgr! Dbgbreakpoint
00061e44 00000024f 00061e8c 001b63b8 00061e88 bootmgr! Blxmlconsole: getinput + 0xe
00061e90 004024c1 00000002 004021f3 00000000 bootmgr! Osxmlbrowser: browse + 0xe0
00061e98 004021f3 00000000 00000000 00061f8f bootmgr! Bmdisplaygetbootmenustatus + 0x13 (FPO: [0, 0, 1])
00061f10 004017a4 00da-f9c 001f4280 00000002 bootmgr! Bmdisplaybootmenu + 0X174
00061f6c 00401261 00347f9c 00061f9c 00000002 bootmgr! BMP getselectedbootentry + 0xf8
00061ff0 000209ea 000249a8 7d8b697c 74ff8514 bootmgr! Bmmain + 0x261
Warning: frame IP not in any known module. Following frames may be wrong.
00000000 f000ff53 f000e2c3 f000ff53 f000ff53 0x209ea
00000000 00000000 f000e2c3 f000ff53 f000ff53 0xf000ff53

Through stack backtracking, we can see that bmmain is the 32-bit code entry function of bootmgr, and bmdisplaybootmenu is the main function responsible for displaying and managing the Startup menu. Several stack frames below bmmain should be traces of 16-bit code execution.

After setting a breakpoint for the return address 00401261 of the BMP getselectedbootentry function, press F5 to continue the execution of the target system. At this time, the menu of the target system can be active. After selecting one of the boot Vista functions, the breakpoint set just now hits immediately. You can see the bootmgr loading winload process in a single step tracking. The main functions include:

Bootmgr! Bmplaunchbootentry

Bootmgr! Imgarchpcatstartbootapplication

Before bootmgr gives the execution permission to winload, it will call blbdstop to disconnect from the debugger.

If you want to continue debugging winload, you should first enable the debug engine in winload. The command is:
Bcdedit/set {guid} bootdebug on

After winload is started, if its debugging engine is enabled, the debugging engine will establish a connection with the debugger and display the connection information similar to the previous one. The following are several important functions in winload:

Winload! Mmarchinitialize

Winload! Archbuildkernelgdt

Winload! Oslarchpkernelsetupphase0

Winload! Oslarchtransfertokernel

The last one is responsible for transferring the execution right to the kernel. Before transferring the execution permission, winload also calls the blbdstop function to cut off the debugging session. If you want to continue to debug the kernel, you should first enable kernel debugging and then establish a connection with the kernel.

If the system is restored from sleep, bootmgr loads winresume, and winresume also integrates a debugging engine, so it can also be tracked and debugged, for example, the stack rollback below shows the winresume program initialization process:

Kd> kpl

Childebp retaddr

00120ad8 0059da7f winresume! Rtlpbreakwithstatusinstruction

00120cf0 0059d97d winresume! Vdbuplintexwithprefixinternal + 0x100

00120d00 0059641a winresume! Dbuplint + 0x11

00120d28 00587550 winresume! Blstatusprint + 0x60

00120d6c 00585524 winresume! Consolefirmwareopen + 0x64

00120d88 0058373d winresume! Consoleopen + 0x58

00120da8 00583242 winresume! Blpdeviceopen + 0x13c

00120dc4 0058bd5b winresume! Bldeviceopen + 0x16

00120ed8 0058bcc7 winresume! Dsppregisterconsole + 0x56

00120f6c 0058b999 winresume! Dsppinitialize + 0xfd

00120f78 005950a2 winresume! Blpdisplayinitialize + 0x26

00120f94 0057c0c6 winresume! Initializelibrary + 0x176

00120fe8 004444fa winresume! Hbmain + 0xc6

Warning: frame IP not in any known module. Following frames may be wrong.

00000000 f000eef3 0x4444fa

00000000 00000000 0xf000eef3

 

Debugging, you can enable these debugging engines at the same time, or you can enable one of them as needed. The first three debugging engines are cloned Based on the kernel debugging engine (KD) in the kernel. They use the KD-compatible protocol. For the debugger (windbg, it does not distinguish whether the other side is a real kD or a clone of KD. Therefore, when bootmgr interrupts the debugging session, the windbg prompts the same information as that when the kernel exits.