绝顶技术：断点+内存映射组合的CLR超强Bug？-51CTO.COM

前言

你见过断点+内存映射，制造了一个另类隐藏极深，强悍的BUG吗？这是一个虚拟机CLR的BUG。不同于之前所遇见的BUG这次费时最多，但是问题已然清晰。本篇来看下。

友情提示：学会本篇，你就是绝级的高手，足可笑傲当世。

概括

1.问题说明

BUG的起因在后面，先看看问题的描述。假如说遇到这样一个问题，在某个地址(以Addr1表示)下了一个断点，程序继续运行，就会某个地方抛出一个异常，首先确认的是这段运行的代码是完全没有问题的。也就是说这个异常只会在下了断点之后，才会抛出。查看堆栈，这个异常非常清晰明了，那就是程序运行过程中某个字段(filed1)的值为0。而通过这个字段也就是field1的空值去访问field1的成员变量，自然是报了异常。

问题很简单，似乎马上就找到了异常出错的地方，也就是field1==0造成的。但为什么field1会为空？它在哪里被赋值的，导致它是空值？跟下断点有什么关系?这些都没解决。

问题一：field1在哪里被赋值的？

经过跟踪发现，field1是通过Windows API的两个函数MapViewOfFileEx，MapViewOfFile进行内存映射来赋值的。这两个内存映射函数映射了两个内存地址。

MapViewOfFileEx映射的是可读，可写，可执行的内存地址(以pRX来表示)。也即是：

FILE_MAP_EXECUTE | FILE_MAP_READ | FILE_MAP_WRITE

MapViewOfFile映射的是可读，可写的内存地址（以pRW来表示），也即是：

FILE_MAP_READ | FILE_MAP_WRITE

当往pRW内存地址写入数值，pRX也同时写入相应的数值，这就是内存映射。这里就是field1被赋值的地方。

问题二：为什么会导致field1空值？

上面说的是，在某个地址也就是上面说的Addr1这个地方下了一个断点，跟踪发现，如果不在Addr1处下断点，那么field1不等于0，也就不会报异常，如果在Addr1处下断点，那么field1等于0,导致了异常的发生。

这个BUG很诡异，难道是断点造成的？

继续跟踪发现，如果在离Addr1偏移量很远的地址下断点，则不会导致了field1==0,如果在Addr1地址上下偏移的地方下断点(也就是偏移比较近的位置)，则会导致field1等于0。难道Addr1地址的上下偏移范围跟field1有一定的关联？
继续跟踪发现，field的值在Addr1地址的后面，它的值本身也是一个地址。每块内存都有一个起始地址，姑且叫Base。那么filed,Addr1,Base的组成如下图所示：

图片

可以看到Addr1和field1的起始地址都是Base，而Base则是被MapViewOfFileEx Windows API内存映射的起始地址。Addr1则是被映射的这块内存里面的某个函数中的某个地址。这里假如说它是程序入口Main函数的函数头地址，也可以是Main函数中间的某个地址。如下图：

图片

因为实际上在Addr1处下了断点，也即是在被MapViewOfFileEx映射的内存地址里面下了断点。在内存映射里面下了断点，就会导致了通过MapViewOfFile映射的内存pRW赋值的时候,pRX会被赋值不上的情况。

pRX和pRW如下图所示:

图片

如果把这个断点，下在MapViewOfFileEx映射的内存范围之外，则不会存在赋值不上的情况。

这里可以确定的就是，在内存映射的范围内下断点，断点会干扰内存映射范围内的数值。

2.检测上面结论是否正确

上面只是问题的分析，如果想要检验上面所述BUG问题是否正确。则需要代码加以辅助证明。

下面是一段内存映射的代码：

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


#define DPTR(type) type*
#define VAL32(x) x
#define HIDWORD(_qw)    ((ULONG)((_qw) >> 32))
#define LODWORD(_qw)    ((ULONG)(_qw))


#define VIRTUAL_ALLOC_RESERVE_GRANULARITY (64*1024) 


typedef DPTR(IMAGE_DOS_HEADER) PTR_IMAGE_DOS_HEADER;
typedef DPTR(IMAGE_NT_HEADERS) PTR_IMAGE_NT_HEADERS;
typedef long long int64_t;
typedef unsigned long long uint64_t;
static const uint64_t MaxDoubleMappedSize = 2048ULL * 1024 * 1024 * 1024;


typedef unsigned __int64 ULONG_PTR, * PULONG_PTR;
typedef ULONG_PTR TADDR;


extern "C" IMAGE_DOS_HEADER __ImageBase;
typedef UINT32  COUNT_T;


template <typename T> inline T ALIGN_UP(T val, size_t alignment)
{
    return (T)ALIGN_UP((size_t)val, alignment);
}


void* GetClrModuleBase()
{
    return (void*)&__ImageBase;
}


IMAGE_NT_HEADERS* FindNTHeaders(TADDR m_base)
{
    return PTR_IMAGE_NT_HEADERS(m_base + VAL32(PTR_IMAGE_DOS_HEADER(m_base)->e_lfanew));
}
COUNT_T GetVirtualSize(TADDR base)
{
    return FindNTHeaders(base)->OptionalHeader.SizeOfImage;
}
void main()
{
    size_t pMaxExecutableCodeSize = (size_t)MaxDoubleMappedSize;


    void* pHandle = CreateFileMapping(
        INVALID_HANDLE_VALUE,    // use paging file
        NULL,                    // default security
        PAGE_EXECUTE_READWRITE | SEC_RESERVE,  // read/write/execute access
        HIDWORD(MaxDoubleMappedSize),                       // maximum object size (high-order DWORD)
        LODWORD(MaxDoubleMappedSize),   // maximum object size (low-order DWORD)
        NULL);


    SIZE_T sizeOfLargePage = GetLargePageMinimum();
    int nCount = 10;
    PVOID pAddr = VirtualAlloc(NULL, sizeOfLargePage * nCount, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);


    MEMORY_BASIC_INFORMATION mbi;
    VirtualQuery(pAddr, &mbi, sizeof mbi);


    void* base = GetClrModuleBase();
    SIZE_T base1 = (SIZE_T)base;
    SIZE_T size = GetVirtualSize((TADDR)base1);
    SIZE_T reach = 0x7FFF0000u;
    BYTE* g_preferredRangeMin = (base1 + size > reach) ? (BYTE*)(base1 + size - reach) : (BYTE*)0;
    BYTE* g_preferredRangeMax = (base1 + reach > base1) ? (BYTE*)(base1 + reach) : (BYTE*)-1;
    
    BYTE* pStart;
    pStart = g_preferredRangeMin + (g_preferredRangeMax - g_preferredRangeMin) / 8;
    pStart += 0x1000 * 0x00000003;
    BYTE* tryAddr = pStart; //(BYTE*)ALIGN_UP((BYTE*)pStart, VIRTUAL_ALLOC_RESERVE_GRANULARITY);


    BYTE* pRX = (BYTE*)MapViewOfFileEx((HANDLE)pHandle,
        FILE_MAP_EXECUTE | FILE_MAP_READ | FILE_MAP_WRITE,
        HIDWORD((int64_t)0),
        LODWORD((int64_t)0),
        0x0000000000010000,
        g_preferredRangeMax);


    VirtualAlloc(pRX, 0x0000000000010000, MEM_COMMIT, PAGE_EXECUTE_READ);


        MEMORY_BASIC_INFORMATION mbInfo;
    VirtualQuery((LPCVOID)pRX, &mbInfo, sizeof(mbInfo));


    void* pRW = (BYTE*)MapViewOfFile((HANDLE)pHandle,
        FILE_MAP_READ | FILE_MAP_WRITE,
        HIDWORD((int64_t)0),
        LODWORD((int64_t)0),
        0x0000000000010000);


    VirtualAlloc(pRW, 0x0000000000010000, MEM_COMMIT, PAGE_READWRITE);


    char abc[] = "abc";
    memcpy(pRW, abc, 3);
    VirtualQuery((LPCVOID)pRX, &mbInfo, sizeof(mbInfo));
}

以上例子，进行了一个内存模拟映射。通过以上例子，观察发现。当在pRX所在地址范围内下断点，则会导致当往pRW里面赋值的时候，pRX赋值不上的情况，如下pRX地址处汇编代码：

Address:00007ff739180000() //pRX Address
00007FF73917FFFC  ?? ?????? 
00007FF73917FFFD  ?? ?????? 
00007FF73917FFFE  ?? ?????? 
00007FF73917FFFF  ?? ?????? 
00007FF739180000  add         byte ptr [rax],al  
00007FF739180002  add         byte ptr [rax],al  
00007FF739180004  add         byte ptr [rax],al  
00007FF739180006  add         byte ptr [rax],al

这里来到了pRX的地址00007ff739180000处,在pRX地址向后偏移2个字节处下断点,也即00007FF739180002。

然后在pRW地址处进行赋值，如下pRW处内存展示：

Address:0x000001BEE1610000 //pRW Memory
0010000000000000 0010000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000

这里的pRW地址是0x000001BEE1610000。

往它的第一个八字节赋值了:0010000000000000。然后看下pRX的的内存，如下：

Addres:0x00007FF739180000  //pRX Memory
0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000

可以看到在被MapViewOfFileEx映射的内存范围内下断点之后，pRW的赋值并不能更改pRX的值。这就导致了开头的异常BUG。

3.代码还原

通过以上理论分析和代码分析，基本上确定了，这个BUG就是断点+内存映射造成的。如果把断点下在内存映射的范围内的某个一个地址上，则会导致内存赋值的失败。如果不下断点，或者断点不在内存映射范围内，则不存在这种情况。这应该是微软Windows内核的一个BUG。以上就是全部用户态的BUG展示了，如果想要更深一些，则需要追踪Windows内核，这个有时间再研究。

这个BUG起因于，CLR调用C#入口Main的汇编代码里面下的断点，运行到.Ctor然后报了异常。这个异常的排查过程如上所示，但是依然有疑惑。就是为啥通过VS调试C#源代码则不会报这个异常。难道VS直接运行C#源代码跟CLR调用略有不同?