绝顶技术:断点+内存映射组合的CLR超强BUG？
前言
你见过断点+内存映射，制造了一个另类隐藏极深，强悍的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_WRITEMapViewOfFile映射的是可读，可写的内存地址（以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调用略有不同?
结尾
作者：江湖评谈