0、主要内容

全文围绕着微软底层是如何实现printf的这个宗旨，从应用程序开始着手分析，一直到内核层，进行双机调试，顺藤摸瓜，追寻数据的流向，又从内核回到用户态程序，接着又依据内核态调试时获知的信息，对用户态另一个进程进行分析，抓出了一系列的信息，使得这个问题越来越清楚，完完全全将printf的实现过程大白于天下。

涉及到的内容如下：

1、内核对象及内核对象管理；
2、设备驱动程序及驱动程序对象；
3、MDL；
4、用户态程序与内核驱动通信DeviceIoControl；
5、Windbg调试；
6、C运行时库代码分析；

 

1、背景

作为程序员，printf这个函数肯定是不陌生的，刚学C语言那会，第一个程序基本也都是经典的printf(“hello world\n”)吧，一用十几年了，但重来都没有深究过背后的实现原理，只知道他是C语言标准库规定的，用起来很爽。最近几天恰好得闲，于是花了点时间把这个问题给搞清楚了；整个过程非常有意思，本以为简单分析下微软随IDE一起公布的C运行时库代码就能搞清楚的，可越分析越发现仅仅依靠这点源码压根解不开谜团，或者说，C运行时库关于printf的部分仅仅只有一个核心的API，遂搭建双机调试，进行内核分析；

 

2、分析过程之源码部分分析

2.1实例代码如下，很简单；IDE是VS2017；这部分源码较多，大家耐心看完

#include <stdio.h>
#include <Windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
    while(1)
    {
        printf("hello world\n");
        Sleep(500);
    }

    return 0;
}

每隔500ms就打印一下字符串“hello world\n”；下边来跟一下VC运行时库的源码；源码步骤比较繁琐，如果不感兴趣可直接略过，看后边的结论；总结起来就是一句话printf——->WriteFile();

2.2源码分析

经过千山万水，终于看到曙光了，总结起来就是一句话printf——->WriteFile();源码面前，了无密码，现在最关心的是这个WriteFile()写入的文件到底是个什么神仙文件？

 

3、分析部分之内核调试分析——写

根据最后一幅图的os_handle这个数据可知，句柄值为0x0C，现在来看下这个句柄到底是个啥。借助Procexp.exe工具，如下：

光看这名字就不想普通的文件，如果是普通的文件的话，应该是有磁盘路径的，这显然是内核驱动创建的一个设备对象，那这玩意到底是啥呢？这才是今天的重点，且往下看；这时我们需要双机调试了，这玩意在内核里；把这程序拷贝到虚拟机，运行，然后用Windbg查数据；

查看下该对象的具体信息，如下所示：

1: kd> !object 0xFFFFCC8BDCEA4EF0
Object: ffffcc8bdcea4ef0  Type: (ffffcc8bd88cdb20) File
    ObjectHeader: ffffcc8bdcea4ec0 (new version)
    HandleCount: 2  PointerCount: 64696
    Directory Object: 00000000  Name: \Output {ConDrv}
1: kd> dt _OBJECT_HEADER ffffcc8bdcea4ec0
nt!_OBJECT_HEADER
   +0x000 PointerCount     : 0n64696
   +0x008 HandleCount      : 0n2
   +0x008 NextToFree       : 0x00000000`00000002 Void
   +0x010 Lock             : _EX_PUSH_LOCK
   +0x018 TypeIndex        : 0x50 'P'
   +0x019 TraceFlags       : 0 ''
   +0x019 DbgRefTrace      : 0y0
   +0x019 DbgTracePermanent : 0y0
   +0x01a InfoMask         : 0x4c 'L'
   +0x01b Flags            : 0 ''
   +0x01b NewObject        : 0y0
   +0x01b KernelObject     : 0y0
   +0x01b KernelOnlyAccess : 0y0
   +0x01b ExclusiveObject  : 0y0
   +0x01b PermanentObject  : 0y0
   +0x01b DefaultSecurityQuota : 0y0
   +0x01b SingleHandleEntry : 0y0
   +0x01b DeletedInline    : 0y0
   +0x01c Reserved         : 0xffffb68d
   +0x020 ObjectCreateInfo : 0xffffcc8b`db7aed80 _OBJECT_CREATE_INFORMATION
   +0x020 QuotaBlockCharged : 0xffffcc8b`db7aed80 Void
   +0x028 SecurityDescriptor : (null)
   +0x030 Body             : _QUAD

里边的很多字段暂时不用管，后边会专门撰文写Windows内核里对象管理的实现原理，但有一个信息是值得我们关注的，就是这个对象的类型是File，即文件；简单说明下，在Windows内核里，对象都是有类型的，就像应用层一样，每个对象都有其所对应的类类型，进程的对象类型为Process，线程的对象类型为Thread，等等，自然的文件对象的类型即为File了；那下边具体看下这个文件有什么特别的，且看下边的操作：

1: kd> dt _FILE_OBJECT ffffcc8bdcea4ef0
nt!_FILE_OBJECT
   +0x000 Type             : 0n5
   +0x002 Size             : 0n216
   +0x008 DeviceObject     : 0xffffcc8b`dbee7b20 _DEVICE_OBJECT
   +0x010 Vpb              : (null)
   +0x018 FsContext        : 0xffffb68d`59de5b30 Void
   +0x020 FsContext2       : 0xffffcc8b`dacca230 Void
   +0x028 SectionObjectPointer : (null)
   +0x030 PrivateCacheMap  : (null)
   +0x038 FinalStatus      : 0n0
   +0x040 RelatedFileObject : 0xffffcc8b`dd122550 _FILE_OBJECT
   +0x048 LockOperation    : 0 ''
   +0x049 DeletePending    : 0 ''
   +0x04a ReadAccess       : 0 ''
   +0x04b WriteAccess      : 0 ''
   +0x04c DeleteAccess     : 0 ''
   +0x04d SharedRead       : 0 ''
   +0x04e SharedWrite      : 0 ''
   +0x04f SharedDelete     : 0 ''
   +0x050 Flags            : 0x10040002
   +0x058 FileName         : _UNICODE_STRING "\Output"
   +0x068 CurrentByteOffset : _LARGE_INTEGER 0x0
   +0x070 Waiters          : 0
   +0x074 Busy             : 0
   +0x078 LastLock         : (null)
   +0x080 Lock             : _KEVENT
   +0x098 Event            : _KEVENT
   +0x0b0 CompletionContext : (null)
   +0x0b8 IrpListLock      : 0
   +0x0c0 IrpList          : _LIST_ENTRY [ 0xffffcc8b`dcea4fb0 - 0xffffcc8b`dcea4fb0 ]
   +0x0d0 FileObjectExtension : (null)

确实挺特殊的，绝大部分字段都没有数据；但与该文件相关联的设备对象值得我们去探究下，如下：

1: kd> dt 0xffffcc8b`dbee7b20 _DEVICE_OBJECT
nt!_DEVICE_OBJECT
   +0x000 Type             : 0n3
   +0x002 Size             : 0x150
   +0x004 ReferenceCount   : 0n10
   +0x008 DriverObject     : 0xffffcc8b`dc4fa200 _DRIVER_OBJECT
   +0x010 NextDevice       : (null)
   +0x018 AttachedDevice   : (null)
   +0x020 CurrentIrp       : (null)
   +0x028 Timer            : (null)
   +0x030 Flags            : 0x50
   +0x034 Characteristics  : 0x20000
   +0x038 Vpb              : (null)
   +0x040 DeviceExtension  : (null)
   +0x048 DeviceType       : 0x50
   +0x04c StackSize        : 2 ''
   +0x050 Queue            : <unnamed-tag>
   +0x098 AlignmentRequirement : 0
   +0x0a0 DeviceQueue      : _KDEVICE_QUEUE
   +0x0c8 Dpc              : _KDPC
   +0x108 ActiveThreadCount : 0
   +0x110 SecurityDescriptor : 0xffffb68d`575f0380 Void
   +0x118 DeviceLock       : _KEVENT
   +0x130 SectorSize       : 0
   +0x132 Spare1           : 0
   +0x138 DeviceObjectExtension : 0xffffcc8b`dbee7c70 _DEVOBJ_EXTENSION
   +0x140 Reserved         : (null)

设备对象在Windows内核里即可以表征一个实实在在的硬件设备，也可以是虚拟出来的一个假的设备，这就是Windows内核分层设计的妙处所在，好了设备仅仅是指代硬件，而该硬件具有哪些功能，则是由其关联的驱动对象所表征的，下边我们再看下其关联的驱动对象：

1: kd> dt 0xffffcc8b`dc4fa200 _DRIVER_OBJECT
nt!_DRIVER_OBJECT
   +0x000 Type             : 0n4
   +0x002 Size             : 0n336
   +0x008 DeviceObject     : 0xffffcc8b`dbee7b20 _DEVICE_OBJECT
   +0x010 Flags            : 0x12
   +0x018 DriverStart      : 0xfffff802`14530000 Void
   +0x020 DriverSize       : 0x12000
   +0x028 DriverSection    : 0xffffcc8b`dc472cf0 Void
   +0x030 DriverExtension  : 0xffffcc8b`dc4fa350 _DRIVER_EXTENSION
   +0x038 DriverName       : _UNICODE_STRING "\Driver\condrv"
   +0x048 HardwareDatabase : 0xfffff802`151f4e38 _UNICODE_STRING "\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM"
   +0x050 FastIoDispatch   : 0xfffff802`14534020 _FAST_IO_DISPATCH
   +0x058 DriverInit       : 0xfffff802`1453e010     long  +fffff8021453e010
   +0x060 DriverStartIo    : (null)
   +0x068 DriverUnload     : 0xfffff802`1453c8e0     void  +fffff8021453c8e0
   +0x070 MajorFunction    : [28] 0xfffff802`14537e10     long  +fffff80214537e10

该驱动对象的名字叫”\Driver\condrv”，跟之前的设备对象的名字还挺呼应的；对于驱动对象来说，最重要的要说MajorFunction数组里放着的那些个例程了；我们来看下这些历程中比较重要的一个

回调例程的函数原型如下：

typedef NTSTATUS DRIVER_DISPATCH (__in struct _DEVICE_OBJECT *DeviceObject, __inout struct _IRP *Irp);

下一个断点看看，命中之后能获取哪些有用的信息；

1: kd> bp 0xfffff802145382a0
1: kd> g
1: kd> k
# Child-SP          RetAddr           Call Site
00 ffffcb80`4ec07808 fffff802`14a428d9 0xfffff802`145382a0
01 ffffcb80`4ec07810 fffff802`14ed755e nt!IofCallDriver+0x59
02 ffffcb80`4ec07850 fffff802`14ed8ca0 nt!IopSynchronousServiceTail+0x19e
03 ffffcb80`4ec07900 fffff802`14b79553 nt!NtWriteFile+0x8b0
04 ffffcb80`4ec07a10 00000000`6e5e1e5c nt!KiSystemServiceCopyEnd+0x13
05 00000000`00aeead8 00000000`6e5e1b3a 0x6e5e1e5c
06 00000000`00aeeae0 00000023`774de7bc 0x6e5e1b3a
07 00000000`00aeeae8 00000000`6e580023 0x00000023`774de7bc
08 00000000`00aeeaf0 00000000`00000000 0x6e580023

断下来了，也确实看到nt!NtWriteFile了，但这个是内核态的并不是用户态的，我这里pdb路径没有设，设置正确的话，栈是完美的，不过这不影响我们的分析过程；要想直接看nt!NtWriteFile的参数比较麻烦，因为x64架构下的内核是通过寄存器传递参数的，这样需要手动去分析参数，比较麻烦，不过没关系，数据还在，回头看下回调函数的例程原型，第二个参数为IRP*，这个里边有我们想要的东西；来看下：

1: kd> !irp ffffcc8bdc6addc0
Irp is active with 2 stacks 2 is current (= 0xffffcc8bdc6aded8)
Mdl=ffffcc8bdd351330: No System Buffer: Thread ffffcc8bd9c4f2c0:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
[N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000    
            Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_WRITE(4), N/A(0)]
            0  0 ffffcc8bdbee7b20 ffffcc8bdcea4ef0 00000000-00000000    
           \Driver\condrv
            Args: 0000000d 00000000 00000000 00000000

重点关注其中的Mdl=ffffcc8bdd351330这行，来继续追踪下数据，这里稍微拓展下，MDL的全称是Memory Descriptor List，即内存 描述链表，是内核里常用来维护缓冲区内存用的一种结构，是个单项链表，借此我们正好来看下数据：

1: kd> dt _mdl ffffcc8bdd351330
nt!_MDL
   +0x000 Next             : (null)
   +0x008 Size             : 0n56
   +0x00a MdlFlags         : 0n266
   +0x00c AllocationProcessorNumber : 1
   +0x00e Reserved         : 0
   +0x010 Process          : 0xffffcc8b`dacf9200 _EPROCESS
   +0x018 MappedSystemVa   : 0xffff9401`ce12f940 Void
   +0x020 StartVa          : 0x00000000`00bee000 Void
   +0x028 ByteCount        : 0xd
   +0x02c ByteOffset       : 0x3a4

各个字段的解释如下：

Next： 指向下一个MDL结构，从而构成链表，有时一个IRP会包含多个MDL；
Size： MDL本身的大小，注意包含了定长部分和变长两部分的size；
MdlFlags：属性标记，如所描述的物理页有没有被lock住等；
Process： 顾名思义，指向该包含该虚拟地址的地址空间的对应进程结构；
MappedSystemVa：内核态空间中的对应地址；
StartVa： 用户或者内核地址空间中的虚拟地址，取决于在哪allocate的，该值是页对齐的；
ByteCount：MDL所描述的虚拟地址段的大小，byte为单位；
ByteOffset：起始地址的页内偏移，因为MDL所描述的地址段不一定是页对齐的；
MdlFlags标志取值如下图，而这里的取值是0n266=0x10a；

参照下图可知，内核虚拟地址空间还没有分配，没关系，先看下用户态的数据是啥，先弥补下前边查看nt!NtWriteFile不方便而导致的没能查看数据的不快；

1: kd> db 0x00000000`00bee000+0x3a4 ld
00000000`00bee3a4  68 65 6c 6c 6f 20 77 6f-72 6c 64 0d 0a           hello world..

正好是我们printf输出的字符串，“hello world\n”,到目前为止一切还在掌控中；那内核总会不一直不分配内核空间吧，因为只要进程切换了，CR3就换了，页表就换了，用户态的数据就有可能访问不到了，所以下一步我们就看下内核合适给MDL.MappedSystemVa 字段挂上数据；指向合适的内核内存空间；方法如下：

1: kd> ba r8 ffffcc8bdd351330+18
1: kd> g
Breakpoint 1 hit
nt!MmMapLockedPagesSpecifyCache+0x16a:
fffff802`14a58fea 83e601          and     esi,1
1: kd> dt _mdl ffffcc8bdd351330
nt!_MDL
   +0x000 Next             : (null)
   +0x008 Size             : 0n56
   +0x00a MdlFlags         : 0n267
   +0x00c AllocationProcessorNumber : 1
   +0x00e Reserved         : 0
   +0x010 Process          : 0xffffcc8b`dacf9200 _EPROCESS
   +0x018 MappedSystemVa   : 0xffff9401`cea433a4 Void
   +0x020 StartVa          : 0x00000000`00bee000 Void
   +0x028 ByteCount        : 0xd
   +0x02c ByteOffset       : 0x3a4

数据设置好了，除了MappedSystemVa 字段被安排了合适的值，MdlFlags 字段也发生了改变；即多了项MDL_MAPPED_TO_SYSTEM_VA；赶紧来看下数据对不对：

1: kd> db 0xffff9401`cea433a4
ffff9401`cea433a4  68 65 6c 6c 6f 20 77 6f-72 6c 64 0d 0a ea be 00  hello world.....
ffff9401`cea433b4  c0 ea be 00 50 00 00 00-d4 e3 be 00 cc 30 11 03  ....P........0..

顺便提一下，大家看下下图，最后一级的pfn居然一样，奇不奇怪？一点都不奇怪，本来就是两个虚拟地址映射到同一份物理页：

OK了，到目前为止，我们知道了printf———>WriteFile——->NtWriteFile———>DriverObject.Write例程；下边我们需要知道，谁来读取这个数据呢？

 

4、分析部分之内核调试分析——读

接着上边的，在MappedSystemVa所指向的虚拟内存地址设置一个访问断点，看看谁来处理该数据的，如下：

1: kd> ba r4 0xffff9401`cea433a4
1: kd> g
Breakpoint 2 hit
fffff802`14531424 48ffc9          dec     rcx
1: kd> kb
# RetAddr           : Args to Child                                                           : Call Site
00 fffff802`1453991d : 00000000`00000000 fffff802`14aac8e9 ffffcc8b`00000000 ffffcb80`4ec076f8 : 0xfffff802`14531424
01 00000000`00000000 : fffff802`14aac8e9 ffffcc8b`00000000 ffffcb80`4ec076f8 ffffb68d`6aa157c0 : 0xfffff802`1453991d

栈不完美，没关系，我们来看看当前的进程是哪个。要查看当前的进程是哪个，方法有很多，下边就给出两种方法，看官自取：

方法1：

1: kd> dt _EPROCESS @$proc -yn ImageF
nt!_EPROCESS
   +0x448 ImageFilePointer : 0xffffcc8b`dea4ad10 _FILE_OBJECT
   +0x450 ImageFileName : [15]  "work.exe"

方法2：

1: kd> !pcr
KPCR for Processor 1 at ffff9401cdcc0000:
    Major 1 Minor 1
    NtTib.ExceptionList: ffff9401cdcd0fb0
        NtTib.StackBase: ffff9401cdccf000
       NtTib.StackLimit: 0000000000aeead8
     NtTib.SubSystemTib: ffff9401cdcc0000
          NtTib.Version: 00000000cdcc0180
      NtTib.UserPointer: ffff9401cdcc0870
          NtTib.SelfTib: 0000000000cac000
                SelfPcr: 0000000000000000
                   Prcb: ffff9401cdcc0180
                   Irql: 0000000000000000
                    IRR: 0000000000000000
                    IDR: 0000000000000000
          InterruptMode: 0000000000000000
                    IDT: 0000000000000000
                    GDT: 0000000000000000
                    TSS: 0000000000000000
          CurrentThread: ffffcc8bd9c4f2c0
             NextThread: ffffcc8bdb76d380
             IdleThread: ffff9401cdcccb40
              DpcQueue: Unable to read nt!_KDPC_DATA.DpcListHead.Flink @ ffff9401cdcc2f80

1: kd> !thread ffffcc8bd9c4f2c0
THREAD ffffcc8bd9c4f2c0  Cid 2744.1ea8  Teb: 0000000000cac000 Win32Thread: 0000000000000000 RUNNING on processor 1
IRP List:
    ffffcc8bdc6addc0: (0006,0238) Flags: 00060a00  Mdl: ffffcc8bdd351330
Not impersonating
DeviceMap                 ffffb68d596246e0
Owning Process            ffffcc8bdacf9200       Image:         work.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      146715         Ticks: 3 (0:00:00:00.046)
Context Switch Count      1518           IdealProcessor: 1             
UserTime                  00:00:00.046
KernelTime                00:00:00.640
Win32 Start Address work!ILT+110(_wmainCRTStartup) (0x0000000000841073)
Stack Init ffffcb804ec07c10 Current ffffcb804ec069a0
Base ffffcb804ec08000 Limit ffffcb804ec01000 Call 0000000000000000
Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffcb80`4ec07698 fffff802`1453991d : 00000000`00000000 fffff802`14aac8e9 ffffcc8b`00000000 ffffcb80`4ec076f8 : 0xfffff802`14531424
ffffcb80`4ec076a0 00000000`00000000 : fffff802`14aac8e9 ffffcc8b`00000000 ffffcb80`4ec076f8 ffffb68d`6aa157c0 : 0xfffff802`1453991d

嗯，还是work.exe自己，看看是不是复制之类的操作；看汇编下附近的代码：

1: kd> ?rdx+rcx-1
Evaluate expression: -118739493964889 = ffff9401`cea433a7
1: kd> db ffff9401`cea433a7
ffff9401`cea433a7  6c 6f 20 77 6f 72 6c 64-0d 0a ea be 00 c0 ea be  lo world........
1: kd> db rcx
ffff9401`cea44d54  6f 20 77 6f 72 6c 64 0d-0a 00 00 00 9c eb be 00  o world.........

确实是在复制字符串，这个不管，多几次g，断下来之后，看下进程名，调整断点如下：

1: kd> ba r4 0xffff9401`cdf953a4 "dt @$proc _EPROCESS -yn Image"

多执行机制g命令之后，如下图所示，出现了另一个进程也来读取这个数据：

简单看下这个进程当前的线程信息，如下：

可以知道的信息有线程的ID，线程的Teb信息，有了这些，直接用用户态调试器直接调试即可，但已经用到了内核调试器，那就简单看下当前的线程在干啥吧，看下他的用户态栈；大致浏览下信息，看看有没有什么特别的API调用；

好，接下来转战用户态调试器；如果大家对内核调试熟悉的话，完全可以直接用内核态调试器直接调试用户态程序，也没多麻烦；

 

5、分析部分之用户态conhost.exe进程行为分析

先来看下DeviceIoControl()函数原型：

BOOL DeviceIoControl(
  HANDLE       hDevice,
  DWORD        dwIoControlCode,
  LPVOID       lpInBuffer,
  DWORD        nInBufferSize,
  LPVOID       lpOutBuffer,
  DWORD        nOutBufferSize,
  LPDWORD      lpBytesReturned,
  LPOVERLAPPED lpOverlapped
);

参数解释请见https://docs.microsoft.com/zh-cn/windows/win32/api/ioapiset/nf-ioapiset-deviceiocontrol

x64下，函数参数传递前4个参数是通过cd89寄存器传递的，剩余的通过栈传递，下边来找一下这几个参数：

下边来简单看下传输的缓冲区数据，看不出啥，这个需要去逆向分析通信协议了，不是我们关注的重点，那就让这个函数执行完，我们看看输出的内容吧：

0:000> dd 000000cbe9a7fcd0
000000cb`e9a7fcd0  011c5524 00000000 00000000 00000000
000000cb`e9a7fce0  00000000 00000000 e9a7fd58 000000cb
000000cb`e9a7fcf0  00000004 00000000

原来conhost.exe是通过这个DeviceIoControl()API通过500006这个控制码跟驱动要的数据；
至此整够过程全部分析完毕；

 

6、总结

本文从printf的源码层层深入分析，到驱动的调试逆向分析，再到conhost.exe进程的数据获取过程的详细分析；本文涉及到的知识点比较多；总结起来有以下几点：

1、printf源码的调试跟踪，如何定位观点点；
2、内核对象管理，设备对象，驱动对象及主要的例程；
3、MDL；
4、内核调试；
5、用户态调试；
6、用户态程序通过DeviceIoControl()与内核驱动交互，获取特定数据；
7、printf实现的多进程架构；涉及的内容比较多，希望读者花点时间好
6、用户态程序通过DeviceIoControl()与内核驱动交互，获取特定数据；
7、printf实现的多进程架构；

好整理总结；