老古董修修还是能用的！

由于工作需要，还在用vs2005这个老古董，虽然很不喜欢。

虽然很轻，但有两个原因不喜欢：

1. 调试总要加载符号，不让加非加，慢的无语

2. 时不时总是无缘无故无法启动

无法启动这个事已经无数次出现了，重装，重启，屏蔽Assist均是无效。

后来无意间点击了C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\devenv.com，可以启动了。

但这次这个方法也不行了，实在是忍无可忍。

决定干它。

上调试器，启动devenv.exe。

看到崩溃原因 c00000fd，就是栈溢出，看来应该是函数调用无限循环了。

不要问我为啥知道，因为之前遇到过。

看看栈，果然如此，user32->msdev!xxx->user32->msdev!xxx->...

0:000:x86> kn 10 # ChildEBP RetAddr  00 000a3048 76cb9cae ntdll_77660000!RtlActivateActivationContextUnsafeFast+0x1801 000a3118 76cb9577 USER32!UserCallWinProcCheckWow+0x14e02 000a3150 76cb771b USER32!CallWindowProcAorW+0x7f03 000a3168 059dea67 USER32!CallWindowProcW+0x1b //5007ea6704 000a3188 059dea34 msenv!CAutoCompletionManagerCL::TargetSubclassProc+0x2905 000a31a4 76cc2edb msenv!CAutoCompletionManagerCL::TargetSubclassProcSTATIC+0x2a06 000a31d0 76cb9e9a USER32!_InternalCallWinProc+0x2b07 000a32b4 76cb9577 USER32!UserCallWinProcCheckWow+0x33a08 000a32ec 76cb771b USER32!CallWindowProcAorW+0x7f09 000a3304 059dea67 USER32!CallWindowProcW+0x1b0a 000a3324 059dea34 msenv!CAutoCompletionManagerCL::TargetSubclassProc+0x290b 000a3340 76cc2edb msenv!CAutoCompletionManagerCL::TargetSubclassProcSTATIC+0x2a0c 000a336c 76cb9e9a USER32!_InternalCallWinProc+0x2b0d 000a3450 76cb9577 USER32!UserCallWinProcCheckWow+0x33a0e 000a3488 76cb771b USER32!CallWindowProcAorW+0x7f0f 000a34a0 059dea67 USER32!CallWindowProcW+0x1b...

打开IDA，简单看看msdev。

int __userpurge CAutoCompletionManagerCL::TargetSubclassProcSTATIC@<eax>(int a1@<esi>, HWND a2, unsigned int a3, unsigned int a4, unsigned int a5){  CAutoCompletionManagerCL *v5; // ecx  int result; // eax
  if ( GetPropW(a2, L"MSENV_ACMgr") )    result = CAutoCompletionManagerCL::TargetSubclassProc(v5, a2, a4, a5, a1);  else    result = DefWindowProcAW(a2, a3, a4, a5);  return result;}
text:5007EA3A 000                 push    ebp.text:5007EA3B 004                 mov     ebp, esp.text:5007EA3D 004                 cmp     ebx, 0Eh.text:5007EA40 004                 push    edi.text:5007EA41 008                 jnz     loc_500FEDCF.text:5007EA47 008                 mov     dword ptr [esi+34h], 1.text:5007EA4E.text:5007EA4E     loc_5007EA4E:                           ; CODE XREF: CAutoCompletionManagerCL::TargetSubclassProc(HWND__ *,uint,uint,long)+803C6↓j.text:5007EA4E                                             ; CAutoCompletionManagerCL::TargetSubclassProc(HWND__ *,uint,uint,long)+17B9CA↓j ....text:5007EA4E 008                 mov     eax, [esi+30h] //=0 不会再调用CallWindowProcAW.text:5007EA51 008                 xor     edi, edi.text:5007EA53 008                 test    eax, eax.text:5007EA55 008                 jz      short loc_5007EA69.text:5007EA57 008                 push    [ebp+arg_8].text:5007EA5A 00C                 push    [ebp+arg_4].text:5007EA5D 010                 push    ebx.text:5007EA5E 014                 push    [ebp+arg_0].text:5007EA61 018                 push    eax //调用原始函数.text:5007EA62 01C                 call    ?CallWindowProcAW@@YGJP6GJPAUHWND__@@IIJ@Z0IIJ@Z ; CallWindowProcAW(long (*)(HWND__ *,uint,uint,long),HWND__ *,uint,uint,long).text:5007EA67 008                 mov     edi, eax.text:5007EA69.text:5007EA69     loc_5007EA69:                           ; CODE XREF: CAutoCompletionManagerCL::TargetSubclassProc(HWND__ *,uint,uint,long)+1B↑j.text:5007EA69 008                 cmp     ebx, 82h.text:5007EA6F 008                 jz      loc_501B3877.text:5007EA75

CAutoCompletionManagerCL::TargetSubclassProcSTATIC应该是个wndproc，本来逻辑应该是在内部CallWindowProcAW调用原始wndproc，但是CallWindowProcAW又调用了CAutoCompletionManagerCL::TargetSubclassProcSTATIC，这样死循环，一直到栈移除。

看看CAutoCompletionManagerCL::TargetSubclassProcSTATIC是哪里设置的，找到了：

int __userpurge CAutoCompletionManagerCL::AttachToCombo@<eax>(CAutoCompletionManagerCL *this@<ecx>, int a2@<eax>, struct IMsoControl *a3, HWND a4){  result = CAutoCompletionManager::OnCreate(this); //创建控件  if ( result >= 0 && !result )  {       v11 = (HWND)*((_DWORD *)this + 10);    if ( v6 )      v7 = SetWindowLongW(v11, -4, (LONG)CAutoCompletionManagerCL::TargetSubclassProcSTATIC);    else      v7 = SetWindowLongA(v11, -4, (LONG)CAutoCompletionManagerCL::TargetSubclassProcSTATIC);    v13 = (HWND)*((_DWORD *)this + 10);    *((_DWORD *)this + 12) = v7; //+30 = 1

所以问题应该基本清晰了，SetWindowLongW(v11, -4, (LONG)CAutoCompletionManagerCL::TargetSubclassProcSTATIC);被重复设置了，*((_DWORD *)this + 12) = v7，保存的值被覆盖成了CAutoCompletionManagerCL::TargetSubclassProcSTATIC

所以这样死循环，导致调用栈溢出

第一次进入msenv!CAutoCompletionManagerCL::AttachToCombo设置SetWindowLongW返回就已经是msenv!CAutoCompletionManagerCL::TargetSubclassProcSTATIC

赋值之前看到原始地址：

msenv!CAutoCompletionManagerCL::AttachToCombo+0x60:05910cb5 894330          mov     dword ptr [ebx+30h],eax ds:002b:06e03228={msenv!_FakeEditProc (0596eab8)}

猜测CAutoCompletionManager::OnCreate中就已经调用SetWindowLongW了。

尝试使用条件断点看看能不能找到。

0:000:x86> u CAutoCompletionManagerCL::TargetSubclassProcSTATICmsenv!CAutoCompletionManagerCL::TargetSubclassProcSTATIC:05aeea06 55              push    ebp0:000:x86> bc 10:000:x86> bp USER32!SetWindowLongW ".if(poi(esp+c)==05aeea06 ){}.else{g};"

断下后，确认函数没问题，看看调用栈。

可以看到msenv!CAutoCompletionManagerCL::VerifyAttachment在OnCreate内部设置了一次。

USER32!SetWindowLongW:76cb7730 8bff            mov     edi,edi0:000:x86> dd esp00194a2c  05c6a3cc 00093096 fffffffc 05aeea0600194a3c  07747120 00000000 05aeec46 00000000
0:000:x86> kn # ChildEBP RetAddr  00 00194a28 05c6a3cc USER32!SetWindowLongW01 00194a40 05aeec46 msenv!CAutoCompletionManagerCL::VerifyAttachment+0x6902 00194a50 05aee7ca msenv!CAutoCompletionManagerCL::VerifyAllAttachments+0x3103 00194a70 05ae2021 msenv!CAutoCompletionManagerCL::UseAutocompletion+0x3f04 00194abc 05ae1ceb msenv!CMsoDropdownUser::GetText+0x12f...18 001961b0 76cc2edb msenv!TBWndWindowProc+0x6519 001961dc 76cb9e9a USER32!_InternalCallWinProc+0x2b1a 001962c0 76cb9a9a USER32!UserCallWinProcCheckWow+0x33a...49 00198424 05a90d54 msenv!CVsAutoCompletion::InitUI+0x2514a 00198440 05a90c6b msenv!CAutoCompletionManager::OnCreate+0x58 //这里是创建4b 00198448 05a90ae1 msenv!CAutoCompletionManagerCL::AttachToCombo+0x124c 00198468 05ae2021 msenv!CAutoCompletionManagerCL::UseAutocompletion+0x95 4d 001984b0 05a90a72 msenv!CMsoDropdownUser::GetText+0x12f4e 001984c8 05a9096b msenv!TBCDD::ResetEditText+0x124f 0019c6d8 05b018aa msenv!TBCDD::FDraw+0x68450 0019c84c 05b013cc msenv!TB::FDraw+0xbb751 0019c8c8 76cc2edb msenv!TBWndProc+0xfa52 0019c8f4 76cb9e9a USER32!_InternalCallWinProc+0x2b
int __usercall CAutoCompletionManagerCL::VerifyAttachment@<eax>(int a1@<esi>){
      v7 = *(HWND *)(a1 + 40);      if ( v4 )        v5 = SetWindowLongW(v7, -4, (LONG)CAutoCompletionManagerCL::TargetSubclassProcSTATIC);      else        v5 = SetWindowLongA(v7, -4, (LONG)CAutoCompletionManagerCL::TargetSubclassProcSTATIC);      *(_DWORD *)(a1 + 48) = v5;    }}

所以应该是msevn逻辑出现了问题，应该加上控件创建成功后，才能SetWindowsLong，或者直接在SetWindowLong之前判断是否已经设置过。

我可以给他改改代码，但是挺麻烦的。

再看看是不是有什么可以控制的条件，有更简单的修改方法。

看看CAutoCompletionManagerCL::AttachToCombo被谁调用了：

Breakpoint 0 hitmsenv!CAutoCompletionManagerCL::AttachToCombo:03a10c59 53              push    ebx0:000:x86> kn # ChildEBP RetAddr  00 00198448 03a10ae1 msenv!CAutoCompletionManagerCL::AttachToCombo01 00198468 03a62021 msenv!CAutoCompletionManagerCL::UseAutocompletion+0x9502 001984b0 03a10a72 msenv!CMsoDropdownUser::GetText+0x12f03 001984c8 03a1096b msenv!TBCDD::ResetEditText+0x1204 0019c6d8 03a818aa msenv!TBCDD::FDraw+0x68405 0019c84c 03a813cc msenv!TB::FDraw+0xbb706 0019c8c8 76cc2edb msenv!TBWndProc+0xfa

看看CAutoCompletionManagerCL::UseAutocompletion的逻辑：

int __userpurge CAutoCompletionManagerCL::UseAutocompletion@<eax>(CVSShellMenu *a1@<ecx>, struct IMsoControl *a2@<edi>, struct IMsoControl *a3){  v6 = 0;  if ( !CAutoCompletionManagerCL::ms_picLastUsed )    CAutoCompletionManagerCL::ms_picLastUsed = a3;  if ( CCmdWindow::ms_fEnableAutocompletion ) //这个状态为0，应该就不会出现了  {    v7 = CVSShellMenu::GetHwndByPic(a1, a2);    v10 = (struct IMsoControl *)v7;    if ( !v7 )      return 1;    CAutoCompletionManagerCL::VerifyAllAttachments(a3); //重复设置的点    if ( CAutoCompletionManagerCL::GetManager(a3, v7) )      return v6;    if ( CAutoCompletionManagerCL::GetManagerByTargetHwnd(v7) )      return 1;    v6 = ATL::CComObject<CAutoCompletionManagerCL>::CreateInstance(&hData);    if ( v6 >= 0 )    {      x = hData;      (*(void (__stdcall **)(HANDLE))(*(_DWORD *)hData + 4))(hData);      v4 = dword_5074D4FC;      if ( safe::CEnvArray<CAutoCompletionManagerCL *,CAutoCompletionManagerCL *>::SetSize() )      {        *((_DWORD *)CAutoCompletionManagerCL::ms_rgManagers + v4) = x;        v6 = CAutoCompletionManagerCL::AttachToCombo(x, (int)a3, v10, v9); //初始化        if ( v6 )          CAutoCompletionManagerCL::OnDestroy(v5);      }      else      {        v6 = -2147024882;      }    }  }  return v6;}

猜测跟代码自动完成有关，这个CCmdWindow::ms_fEnableAutocompletion变量好像可以弄弄，如果设置为假，就完全不会进入后面的逻辑。

现在看看CCmdWindow::ms_fEnableAutocompletion在哪里设置的。

void __stdcall PrefInitPart2(){   if ( GetUserOption(0, L"CommandWindowAutocompletion", Data, 4u, (unsigned int)v72) < 0 )    *(_DWORD *)Data = 1; //没配置默认为1  v32 = 0;  hKey = *(HKEY *)Data;  CCmdWindow::ms_fEnableAutocompletion = *(_DWORD *)Data; //设置状态

好像有戏，CommandWindowAutocompletion是用户配置相关的。CommandWindowAutocompletion未配置默认开启ms_fEnableAutocompletion。

int __userpurge GetUserOption@<eax>(int a1@<eax>, LPCWSTR lpValueName, LPBYTE lpData, DWORD cbData, unsigned int a5){
  hKey = 0;  if ( a1 )    VBRegOpenTwoKeysFromRoot(      HKEY_CURRENT_USER,      (const unsigned __int16 *)a1,      L"General",      (HKEY)&hKey,      v7,      v10,      (unsigned int)v11,      (HKEY *)hKey);  else    VBRegOpenKeyFromRoot(&hKey, HKEY_CURRENT_USER, L"General", (HKEY)0x20019, v7, (unsigned int)v10, v11);//a1=0  v5 = HrFromRegError(v8);  if ( v5 >= 0 )  {    RegQueryValueExW(hKey, lpValueName, 0, 0, lpData, &cbData);    v5 = HrFromRegError(v9);    if ( hKey )      RegCloseKey(hKey);  }  return v5;}int __userpurge VBRegOpenTwoKeysFromRoot@<eax>(HKEY a1@<ebx>, const unsigned __int16 *a2@<edi>, const unsigned __int16 *a3@<esi>, HKEY a4, const unsigned __int16 *a5, const unsigned __int16 *a6, unsigned int a7, HKEY *a8){
  if ( !g_pMainParam || (v7 = (const wchar_t *)*((_DWORD *)g_pMainParam + 31)) == 0 || !*v7 )    v7 = L"Software\\Microsoft\\VisualStudio\\8.0";}
0:000:x86> pmsenv!VBRegOpenKeyFromRoot+0xed:05a54d9d ff1550109205    call    dword ptr [msenv!_imp__RegOpenKeyExW (05921050)] ds:002b:05921050={AcLayers!NS_VirtualRegistry::APIHook_RegOpenKeyExW (68d83ce0)}0:000:x86> dd esp0019d300  80000001 0019d31c 00000000 000200190019d310  0019d314 0019d364 000001e4 006f00530019d320  00740066 00610077 00650072 004d005c0019d330  00630069 006f0072 006f0073 007400660019d340  0056005c 00730069 00610075 0053006c0019d350  00750074 00690064 005c006f 002e00380019d360  005c0030 00650047 0065006e 006100720019d370  0000006c 007c0cf0 baadf00d 007ed3e00:000:x86> du 0019d31c 0019d31c  "Software\Microsoft\VisualStudio\"0019d35c  "8.0\General"

通过调试确认，最终找到配置位置：

计算机\HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\8.0\GeneralCommandWindowAutocompletion = 0;REG_DWORD

增加注册表CommandWindowAutocompletion，设置为0，这样ms_fEnableAutocompletion就是0，问题解决。

看名字这个有点像代码自动完成功能的，但不知道ms_fEnableAutocompletion配置为0之后会不会影响该功能。

哈哈，经过验证没有影响，终于又可以正常使用这个老古董了。

（完）

阅读原文

跳转微信打开

程序员就是折腾~

author: anhkgg
date: 2021年6月19日

前情提要

最近在分析某个软件时，提示错误。赶紧挂上windbg看看调用栈，看能不能找到问题。

一看应该能够解决，需要结合IDA静态分析。

通过任务管理器进程转到文件，发现文件已经不存在了，咋办？

还好，进程还在，可以把主程序dump下来，就可以静态分析了。

如何dump呢？简单的可以通过windbg的.writemem把内存写入文件，但是文件不是合法（可运行）的PE，虽然此时文件和内存中数据完全相同（IDA可以将就分析）。

PE文件的文件结构和内存结构是不完全相同的，最重要的原因是文件对齐和内存对齐不同。

所以windbg的.writemem是不支持把内存dump生成合法的PE文件，除非自己再进行文件修复。

此时，不知道有没有人想起来逆向中脱壳，是不是也有类似操作，我这里不是脱壳，但需要做的确和脱壳类似。

所以我想到了LordPE（没用OD），它可以把内存dump之后生成正确的PE文件，然后再ImportREC修复输入表即可。

这活脱脱的就是脱壳啊，哈哈，无所谓啦。

分析

好久不使LordPE，赶紧找出来，运行之后，发现不行。咋回事？该版本不支持枚举高权限进程？不至于啊。

连着换了多个版本，还是不行，LordPE枚举到的进程中没有我的目标进程，而且很多进程名都是[System Process]。

LordPE不至于这么弱吧？！算了，祭出windbg分析一下吧。

windbg启动LordPE，对枚举进程API下断，bp kernel32!ProcessNext，居然没断下来。

WTF？

那断ntdll的API总行了吧，bp ntdll!NtQuerySystemInformation。可以，发现用的是kernel32!EnumProcess。

0:000> kv
 # ChildEBP RetAddr  Args to Child              
00 0019f5e0 200013fc 004a0010 00000400 0019f600 KERNELBASE!K32EnumProcesses (FPO: [Non-Fpo])
01 0019f74c 00405fb6 004a0010 00000400 69970c70 procs!GetProcessIDList+0x13c
02 0019f7a0 6992b4f2 ffffffff 00001003 00000001 LordPE+0x5fb6
03 0019f7c4 69929edb 00040426 00001003 00000001 COMCTL32!FlatSB_SubclassWndProc+0x22 (FPO: [6,0,0])
04 0019f820 fffffffe 0019f874 69929e20 00040426 COMCTL32!CallNextSubclassProc+0x69 (FPO: [Non-Fpo])
05 0019f844 7789c79c 00000000 00559420 00000000 0xfffffffe
06 0019f920 766760bf 00000000 00000000 004911c8 ntdll!RtlDeactivateActivationContextUnsafeFast+0x9c (FPO: [Non-Fpo])

然后发现procs!GetProcessIDList，看名字明显就是获取所有进程PID。

IDA打开procs.dll一看，这个DLL提供了所有进程和模块管理的接口。

可以看到，他根据Is_xxx_200024FC（系统版本）分两类API来获取信息，第二种才是我前面没成功下断的ProcessNext。

这不是重点，上面的枚举代码没什么问题，不过我没怎么用过EnumProcess接口，不确定是否有问题，所以我把Is_xxx_200024FC强制改为0，然后所有接口都通过tlhelp32接口来获取进程和模块信息。

再往上层回溯，进入LordPE，发现神奇的东西。

长度传的0xF0，也就是240 / 4 = 60，也就是说LordPE只能获取60个进程。

DWORD dwProcessId[60];

而在win10上，动不动就是上百个进程，所以没有枚举到我要看的目标进程太正常了。

只想吐槽，LordPE作者怎么会写出这样的代码，这就算在xp、win7，进程超过60个也歇菜了。

修改

问题找到了，现在该想想如何修改让LordPE能够正常用起来。

首先想到的是，既然枚举进程不全，我可以自己枚举进程插入到进程列表中。

但需要确认点击某个进程选dump是怎么处理的？

获取到选择的进程行，让后dwProcessId[index]拿到进程PID，然后调用dump函数。

这，index超了60，dwProcessId[index]就不行了啊，这个PID不合法啊。

此路不通。

那把dwProcessId扩大呢？

dwProcessId大小60个，后面马上接着其他变量，连对齐空间都没有。

不可行。

可以看到，引用dwProcessId的位置还不只一个。

更多想法：

1. dwProcessId通过malloc分配，但得修改所有引用位置的代码，从dwProcessId[index]换成(*dwProcess)[index]

2. 劫持所有procs.dll接口，把参数PID换成我需要dump的进程，同样也需要替换模块地址。

3. 或者重写一个…(额)

觉得都挺麻烦的。

此时，去百度搜索了一下，发现已经有前人做过相关工作了。

LordPE只显示60个进程 fix

他是在PE中找到空白位置，用做新的dwProcessId地址，然后把所有引用dwProcessId的位置换成这个新地址，还挺简单，不过最多只能存256个进程PID，将就可以用了。

然后procs.dll接口也存在问题，居然还有硬编码F0来EnumProcess获取进程（几乎所有接口）。

不过我前面已经修改了Is_xxx_200024FC，所以不会用enumprocess，全部使用的tlhelp32的ProcessNext接口，不会存在这个问题。

所以暂时确定方案：

1. 找到新位置用作dwProcessId，并修改引用位置

2. 修改procs.dll的Is_xxx_200024FC为0

在结尾看到800h的对齐位置。

0x800/4=0x200=512字节，那么可以枚举到512个进程。

把所有dwProcessId换成41EA88，大小F0换成800h。

现在可以正常枚举到进程。

总结

经过一番折腾，目前满足我当前需求，可以正常dump出错的软件，但是LordPE不支持64进程，所有可能某些情况下还是鸡肋。

很少这么手工修改软件，思路还是挺重要的，要不是搜到那篇帖子，我可能就会采用勾上procs.dll的导出接口和dump函数，但随便几点某个进程，选择dump时，会弹出一个我的界面选择真实的目标进程，然后返回调用dump函数，也同样是可以同样的功能。

最后立个flag，有时间还是想写个支持64进程的增强版LordPE。或者我孤陋寡闻，目前已经有类似程序，有知情大佬，请不吝告知。

阅读原文

跳转微信打开

手持两把锟斤拷,口中疾呼烫烫烫。脚踏千朵屯屯屯,笑看万物锘锘锘

最近用vscode编辑代码，中文总是变成乱码“锟斤拷”，无法恢复。

思考了一下，按理说就算别识别成另一种编码，我换成正确编码应该是能够正常显示的，但结果是不能。

所以究竟发生了什么？

这次终于认真研究了一下，用010editor对比二进制数据，终于发现…

数据已经改变了，还有一些特征。

//内存基址
//锟节达拷锟街?

C4 DA | B4 E6 | BB F9 | D6 B7
EF BF BD DA | B4 EF BF BD | EF BF BD | D6 B7

对比之后发现，某些字节还是原始的，某些字节替换成了EF BF BD。

百度一搜EF BF BD，发现原来是这样的。

在众多的utf-8码点值中，除了ascii，你还应该记住「EF BF BD」，因为它是很多编程语言以及库中的备胎，即无效的码点值在编码的时候会默认用这个码点值进行替换，即utf-8中的超级「备胎」(REPLACEMENT CHARACTER)。utf-8 神秘符号 efbf bdef bfbd
很多时候我们在打开utf-8的时候会有 � 等很多像问号的编码出现这时候我们打开这个文件的二进制就会发现 问号对应的十六进制编码就是efbf bdef bfbd。这个编码到底是什么呢？为什么会有这种编码呢。这就要从各种编码格式的转换说起。而且大部分出现这种问题的就是用gbk编码的文件用utf-8编码格式打开。当编码格式中出现utf-8无法解析的字节，那么这个字节就会被替换成 efbf bdef bfbd 这时我们会发现文件大小也发生了改变，因为未知字节全部变成三个未知字节。而这时候再将其转换为gbk锟 (0xEFBF)，斤（0xBDEF），拷（0xBFBD） 这就是 锟斤拷 那么我是在什么时候发现这个问题：python 的 print 我们一般都会把python代码设置成全局utf-8编码。这时候如果你收到的是一个gbk的编码，但是直接打出来。就会发现出现很多问号。这个时候直接复制粘贴再看二进制就不是真正接受的数据。因为print自动将收到的数据进行了utf-8解码。这样无法解析的编码就变成efbf bdef bfbd。所以在遇到乱码的时候就需要在数据的原始接受处，及第一次转码发生之前将数据用二进制写入文件留存

所以，本来代码使用的gbk（其实是ansi）编码保存的，用vscode打开时，自动识别成了utf8，也没注意到乱码了，只要此时一保存，完了。

已经被换成了锟斤拷（重新用gbk打开看到是锟斤拷）。

so，使用vscode的时候要注意打开编码是否正确，如果遇到此种情况，如法恢复。

因为替换成了EF BF BD，没法知道原始数据是什么。

最后就是吐槽，vscode识别编码（Auto Guess Encoding并不好用，经常会被识别成Windows 1252）不准确，相比来说notepad++这方面做的不错。

阅读原文

跳转微信打开

chrome导致win10蓝屏？

chrome：不是我的锅！

今天看到有人说chrome访问一个设备路径导致win10蓝屏，一搜帖子还挺多的。

作为win内核研究人员，对此非常感兴趣。赶紧打开虚拟机，装上chrome，测试一把。

果然蓝了。

分析

挂上Windbg调试器，很容易就发现问题在哪里了。

eax=9d35e390 ebx=00000012 ecx=00000000 edx=9d35e390 esi=b7cb5798 edi=9d35e390
eip=b8fd693a esp=abc7f78c ebp=abc7f790 iopl=0         nv up ei ng nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010282
condrv!CdpDispatchCleanup+0x1a:
b8fd693a 8b11            mov     edx,dword ptr [ecx]  ds:0023:00000000=????????
Resetting default scope
LAST_CONTROL_TRANSFER:  from 82a4f2a6 to 829959e4
STACK_TEXT:  
abc7ec84 82a4f2a6 00000003 417ab436 0000001e nt!RtlpBreakWithStatusInstruction
abc7ecd8 82a4ecb4 896dc340 abc7f0c0 abc7f0f4 nt!KiBugCheckDebugBreak+0x1f
abc7f094 8299439a 0000001e c0000005 b8fd693a nt!KeBugCheck2+0x7ad
abc7f0b8 829942d1 0000001e c0000005 b8fd693a nt!KiBugCheck2+0xc6
abc7f0d8 82a50f6b 0000001e c0000005 b8fd693a nt!KeBugCheckEx+0x19
abc7f0f4 829d5b52 abc7f638 82b59960 abc7f1f0 nt!KiFatalExceptionHandler+0x1a
abc7f118 829d5b24 abc7f638 82b59960 abc7f1f0 nt!ExecuteHandler2+0x26
abc7f1e0 8292e595 abc7f638 abc7f1f0 00010037 nt!ExecuteHandler+0x24
abc7f61c 829ce781 abc7f638 00000000 abc7f718 nt!KiDispatchException+0x1b5
abc7f688 829d3062 ffffffff ffffffff ffffffff nt!KiDispatchTrapException+0x51
abc7f688 b8fd693a ffffffff ffffffff ffffffff nt!KiTrap0E+0x382
abc7f790 828b0368 b7cb5798 9d35e390 a9d2c220 condrv!CdpDispatchCleanup+0x1a
abc7f7a8 82bd9e04 abc7fa74 b7cb5798 a9d2c220 nt!IofCallDriver+0x48
abc7f7e8 82bd49aa 00000000 a9d2c220 00000001 nt!IopCloseFile+0x184
abc7f8ac 82bb53b3 b7cb5798 45ff2480 00000000 nt!IopParseDevice+0xa6a
abc7f99c 82bb7cb7 00000040 87ff2480 6c600001 nt!ObpLookupObjectName+0xea3
abc7fa3c 82beecb7 098cf240 87ff2480 6c600001 nt!ObOpenObjectByNameEx+0x1c7
abc7fc04 829cce6b 098cf240 098cf270 098cf2ac nt!NtQueryFullAttributesFile+0x15f
abc7fc04 77cd5ef0 098cf240 098cf270 098cf2ac nt!KiSystemServicePostCall
098cf220 77cd352a 75ff982e 098cf240 098cf270 ntdll!KiFastSystemCallRet
098cf224 75ff982e 098cf240 098cf270 098cf2d0 ntdll!NtQueryFullAttributesFile+0xa
098cf2ac 0fcb8f87 085375a8 00000000 098cf2d0 KERNELBASE!GetFileAttributesExW+0x7e
WARNING: Stack unwind information not available. Following frames may be wrong.
098cf350 10ec66a9 098cf54c 098cf520 00a90000 chrome!ChromeMain+0x34a47

mov edx,dword ptr [ecx]读0地址导致内存访问异常，蓝屏。

具体原因就是微软condrv.sys处理cleanup例程的时候对访问指针判断不够严谨，FileObject->FsContext未空，未作判断直接读取内容导致蓝屏。

condrv!CdpDispatchCleanup
PAGE:00016925                 mov     eax, [ebp+Irp]
PAGE:00016928                 mov     ecx, [eax+60h] //Irp->Tail.Overlay.CurrentStackLocation
PAGE:0001692B                 mov     ecx, [ecx+18h] //IoStack->FileObject
PAGE:0001692E                 test    ecx, ecx
PAGE:00016930                 jz      loc_181F9
PAGE:00016936                 mov     ecx, [ecx+0Ch] //FileObject->FsContext
PAGE:00016939                 push    esi
PAGE:0001693A                 mov     edx, [ecx] //ecx=0，读取违例

影响

我也往回看了几个老版本win10系统，condrv.sys同样存在一样的问题，说明这个已经存在很久了，只是最近刚被发现了。

粗略分析来看，FsContext一般来说并不能被攻击者控制，并且此处只是一个读内存问题，一般不能得到一个有效的漏洞攻击利用。

所以大家并不用特别担心，如果有人拿来恶作剧，最多就是让你电脑蓝屏重启一下，危害并不大。

但是，注意别在写文档、写代码等等情况下，还未保存数据的时候，中招了。

那么，节哀，刚刚辛辛苦苦写的东西肯定没了！

最后，等待微软修复吧。

最后的最后：

1. 并不是只有chrome访问这个设备路径才有问题，所有使用chrome内核的浏览器都会中招

2. 朋友发你一个看起来像txt文本的批处理文件，也会导致windows蓝屏。

3. 以及其他各种脚本文件，点开之前都看看内容是不是存在设备路径\\.\globalroot\device\condrv\kernelconnect

4. ...

（完）

阅读原文

跳转微信打开

我觉得，有些事情还是别潜意思觉得~~

起因

今天关注到看雪一篇帖子《关于QQ读取Chrome历史记录的澄清》访问量突然爆发，貌似引起了很大的震动。

帖子内容大致是，作者看到v2ex一篇帖子《QQ 正在尝试读取你的浏览记录》说QQ后台尝试读取你的浏览器历史记录。

然后本着探索的精神，作者去简单抓取了一下QQ的文件访问行为，和简单的逆向分析。

然后得出结论是，QQ并不是针对Chrome，而是会遍历读取所有浏览器历史记录，确认会中招的浏览器包括但不限于如Chrome、Chromium、360极速、360安全、猎豹、2345等浏览器（看出了吗，就是所有使用chrome内核的浏览器）。

这个…我有点…震惊！不敢置信。

所以，根据作者帖子提供的线索，我也去看了看QQ相关位置的代码，究竟是做什么功能，一探究竟。

分析

原帖作者通过history搜索到关键代码，我也照着做了，然后发现了不同的事情。

可能有点先入为主，原帖作者并没有怎么仔细看相关代码的逻辑和功能，认为QQ读取了chrome历史记录文件并进行了sqlite数据操作。

其实呢？如果仔细一点，就会发现下面的代码。

很明显，QQ仅仅暂时拷贝了chrome历史记录文件到临时文件temphis.db，然后刷选了url进行了一些检测，log信息中看到关键字ptjcur Detect2。

然后通过DeleteFile删除了临时文件temphis.dbg，中间代码也并没有发现什么上传服务器的代码。

所以我觉得原帖作者得到QQ后台读取浏览器历史记录，并臆测可能会对用户做什么危害的行为，有上升到了用户隐私上，这个结论确实是有点不妥的。

因为读取历史记录和删除临时文件中间并没有什么上传服务器之类的操作，所有都是本地完成的。

这个结论对企鹅有点不公平，对一个如日冲天的互联网公司不公平。

不能因为某些xx历史行为，就无脑接受坏人设定，不清楚细节就轻易下结论，当然我并不否认那些历史xx行为。

为了搞清楚真相，我进行了更深入的分析，发现一些新的东西。

读取历史记录相关逻辑是在一个线程中，线程首先会判断dns domain是tencent.com或者存在SNGPERF，则bint为1，那么后面的读取历史记录也就不会做了（这是不针对企鹅内部环境？）。

如果bint是0，则开始detect。

首先通过urlcache（后面再读取chrome历史记录）读取url信息（ptjcur Detect1）。

然后计算url的md5，比几个固定的md5值比较。

如果md5匹配，会解析url分析&后面的参数，然后继续把这个参数做md5计算，和一些md5比较，匹配存入一块内存。

具体后续有什么动作，经过这些简单的分析还不能确认，所以也不能轻易对其下结论。

需要比较url的md5如下，有条件的朋友可以去跑跑看结果是什么，然后企鹅究竟要作什么就一目了然了。

0x1C6389BA, 0xF2FA5666, 0xF2A2E0D3, 0xC892E7BA
0xB829484C, 0x520F7CC3, 0x94EC8A73, 0xD808E79
0xDDA1029, 0x9E67F3BB, 0xB18ACC45, 0x597CF438
0x2564591C, 0x5B11347B, 0x846A0F72, 0xEF704A8

结论

最后总结，经过上面的分析，我们并不能对QQ的行为下结论，并不能因为临时读取和计算了一下url，就判定是对用户隐私的侵害（有可能真的如某些人说的，这可能是对某些不雅网站的检查呢）。
当然，在这件事情中，QQ并不完全是无辜者，读取用户浏览器历史记录是一个非常敏感的行为，应该必须让用户清楚得知道，你并没用用此信息做什么伤害用户利益的事情。

最后的最后呢，我想到一个非常有意思的点，说不定这件事情就是因为开发人员一个不小心搞出来的乌龙呢？

哈哈，知道我说的什么吗？就是前面我提到的，判断dns域名是不是tencent.com，bint为0，才会有后面一系列行为，所以我当时很迷惑的猜测，对企鹅内部环境并不检测。

而可能因为开发人员手误把if(bint)写错成了if(!bint)导致检测了非企鹅内部环境，而其实这个功能只是针对企鹅内部环境做的。

当然，这只是我的猜测，具体还得看看企鹅自己的解释。

(完)

阅读原文

跳转微信打开

网上的资料很多坑~

了解一点操作系统知识的同学们应该都知道，文件占用无法删除，是因为某些进程正在使用该文件。

要删除这样的文件，就需要让那些进程关闭文件，然后自然可以删除。
一句话的事，那究竟要怎么用代码来实现这个功能呢？

打开和关闭文件

还记得上大学第一门语言课-C语言，迄今为止还依然活跃并被一直使用的语言。

比汇编容易理解，又更接近底层，所以Windows操作系统内核大部分代码都是用C语言来编写的。

在C的课程里，我们学过通过FILE来操作使用文件，比如：

FILE *fp;
fp = fopen("c:\\temp\\test.txt", "r")

通过读的方式打开一个文件，使用非常简单，后续通过fp这个结构体指针操作文件即可。

其实fopen并不接近操作系统，他是对win32 API CreateFile的封装。

也就是前者是标准库接口，在Windows、linux、unix等都是通用接口。

而后者才是和操作系统关联紧密，由微软自己提供的API。

要更好的理解进程如何使用文件的，我们还得看看CreateFile这个API接口。

HANDLE CreateFileA(
  LPCSTR                lpFileName,
  DWORD                 dwDesiredAccess,
  DWORD                 dwShareMode,
  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  DWORD                 dwCreationDisposition,
  DWORD                 dwFlagsAndAttributes,
  HANDLE                hTemplateFile
);

这是msdn对CreateFile的定义，简单来看我们可以只关注lpFileName和返回值，lpFileName传递你要打开的文件，返回值是操作系统给你的一个代表文件的句柄（handle）。

HANDLE hFile = CreateFileA("c:\\temp\\test.txt", ...);

要对文件进行读、写等操作都需要这个句柄，也就是说这个句柄至关重要，它表示文件正在被使用。

然后什么时候结束使用呢，我们需要看另一个API CloseHandle.

BOOL CloseHandle(
  HANDLE hObject
);

CloseHandle用于关闭一个正在被使用的文件，通过句柄来关闭。

现在明白过来了吗，只要我们让进程调用CloseHandle这个API，关闭被占用的文件句柄，那么该文件也就被解除占用了。

哈哈，是不是很简单。

枚举占用文件的进程

那么我就想问同学们一个问题，怎么知道哪些进程在使用我们想删除的文件呢？怎么去查找？

带着这个问题，我们继续往下看。

我们来想一个问题，操作系统给调用CreateFile的用户返回了一个句柄，然后通过句柄来操作文件，那操作系统是如何知道句柄代表哪个文件呢？

我们简单思考一下，我们要达到这个目的有没有什么方法，比如我用一个数组来存用户打开的文件路径，而数组序号就返回给用户，下次用户就只需要把序号给我，我就知道要操作什么问题了。

演示代码，忽略细节
LPWSTR FileTable[100] = {0};
HANDLE CreateFileA(
  LPCSTR                lpFileName,
  ...)
  {
      for(int i = 0; i < 100; i ++) {
          if(FileTable[i] == NULL) { //还有空位
              FileTable[i] = lpFileName; //保存路径
              return (HANDLE)i; //返回句柄
          }
      }
      return NULL;
  }
BOOL CloseHandle(
  HANDLE hObject
) {
    if((int)hObject < 100) {
        if(FileTable[hObject]) {
            FileTable[hObject] = NULL;//找到文件路径
            return TRUE;
        }
    }
    return FALSE;
}

上面简单的代码演示了一下我们粗略考略的文件和句柄的关系以及句柄的管理，那操作系统是不是这么做的呢？其实也差不多。

任意进程，只要每打开一个对象（包括文件、进程、线程等等），就会获得一个句柄。

这个句柄用来标志对某个对象的一次打开，通过句柄，可以直接找到对应的内核对象。

每个进程都有一个句柄表，用来记录本进程打开的所有内核对象。

句柄表可以简单看做为一个一维数组，每个表项就是一个句柄，一个结构体，一个句柄描述符。

 struct _HANDLE_TABLE_ENTRY  //句柄描述符
 struct _HANDLE_TABLE    //句柄表描述符

好，更加细节的句柄表的原理我们不用再深究，我们只需要知道每个进程都有一个句柄表，通过句柄表就可以找到打开的文件。

这就是我们的目的，我们需要查到进程是不是打开了我们要删除的文件，我们需要查句柄表。

那怎么查呢？

操作系统给用户提供了一个接口ZwQuerySystemInformation。

NTSTATUS WINAPI ZwQuerySystemInformation(
  _In_      SYSTEM_INFORMATION_CLASS SystemInformationClass,
  _Inout_   PVOID                    SystemInformation,
  _In_      ULONG                    SystemInformationLength,
  _Out_opt_ PULONG                   ReturnLength
);

它可以获取系统非常多的信息，包括进程、模块、处理器、内存等等各种信息。

而SystemHandleInformation = 16就能获取到系统所有的句柄信息。

typedef struct _SYSTEM_HANDLE_TABLE_ENTRY_INFO
{
    USHORT UniqueProcessId;//所属进程
    USHORT CreatorBackTraceIndex;
    UCHAR ObjectTypeIndex;
    UCHAR HandleAttributes;
    USHORT HandleValue; //句柄
    PVOID Object;
    ULONG GrantedAccess;
} SYSTEM_HANDLE_TABLE_ENTRY_INFO, *PSYSTEM_HANDLE_TABLE_ENTRY_INFO;
typedef struct _SYSTEM_HANDLE_INFORMATION
{
    ULONG NumberOfHandles;
    SYSTEM_HANDLE_TABLE_ENTRY_INFO Handles[1];
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;

既然知道了方法，下面就开始枚举所有句柄，找到我们被占用的文件的进程信息。

Status = ZwQuerySystemInformation(SystemHandleInformation,
            Information,
            Length,
            &ReturnLength);
for (i = 0; i < Information->NumberOfHandles; i++) {
    if (Information->Handles[i].UniqueProcessId != CurrentProcessId) {//不是当前进程
        Status = ZwQueryObject(TargetHandle, ObjectTypeInformation, &TypeInfo, sizeof(TypeInfo), NULL);
        RtlInitUnicodeString(&TargetType, L"File");
        if (!RtlEqualUnicodeString(&TypeInfo.Info.TypeName, &TargetType, FALSE)) {
            goto __next;
        }
        Status = ZwQueryObject(TargetHandle, ObjectNameInformation, &NameInfo, sizeof(NameInfo), NULL);
        if (RtlEqualUnicodeString(&NameInfo.Info.Name, &FileName, FALSE)) {
            printf("在进程(%d)发现文件占用：(%x) %wZ\n",
                    ProcessId,
                    Information->Handles[i].HandleValue,
                    &NameInfo.Info.Name);
        }
    }
}

ZwQuerySystemInformation获取到所有句柄信息，通过循环枚举Information->Handles，找到句柄类型属于File，路径是目标文件的进程。

ZwQueryObject传入ObjectTypeInformation可以获取句柄类型，ZwQueryObject传入ObjectNameInformation可以获取文件路径。

如此两个条件的对比，就能让我们找到占用文件的进程了。

是不是感觉还挺简单，不复杂嘛。

坑一：ZwQueryObject

前面提到，每个进程都有自己的句柄表，所以ZwQuerySystemInformation枚举拿到的句柄并不能直接使用，还需要复制一份到本进程才有效。

系统也提供了API叫做DuplicateHandle:

BOOL DuplicateHandle(
  HANDLE   hSourceProcessHandle,
  HANDLE   hSourceHandle,
  HANDLE   hTargetProcessHandle,
  LPHANDLE lpTargetHandle,
  DWORD    dwDesiredAccess,
  BOOL     bInheritHandle,
  DWORD    dwOptions
);
DuplicateHandle(hSrcProc, Information->Handles[i].HandleValue, hCurProc, TargetHandle, ...);

上面我们使用的TargetHandle就是通过复制获取的。

这个地方并不是坑，而是在通过ZwQueryObject获取句柄对应的文件路径时，会发生阻塞，导致程序卡死无法继续运行。

0: kd> kv
 # ChildEBP RetAddr  Args to Child
00 d7fdb7cc 828aacda 00000000 00000000 a7d73040 nt!KiSwapContext+0x19 (FPO: [Uses EBP] [1,0,4])
01 d7fdb86c 828aa358 d7fdb930 a7d73120 a7d73040 nt!KiSwapThread+0x4aa (FPO: [Non-Fpo])
02 d7fdb8c8 828a9d67 00000000 00000000 00000000 nt!KiCommitThreadWait+0x128 (FPO: [Non-Fpo])
03 d7fdb978 829298a3 8ff18afc 00000000 a7d73300 nt!KeWaitForSingleObject+0x1f7 (FPO: [Non-Fpo])
04 d7fdb9a4 82c0759f 88c0e801 d7fdba18 8ff18ab0 nt!IopWaitForLockAlertable+0x3f (FPO: [Non-Fpo])
05 d7fdb9cc 82d3f75c 88c0e800 a7d733f8 d7fdb9ef nt!IopWaitAndAcquireFileObjectLock+0x41 (FPO: [Non-Fpo])
06 d7fdba1c 82bed31a 000001ee d7fdbb01 9a651dc0 nt!IopQueryXxxInformation+0x150f3e
07 d7fdba9c 82becf65 00000000 007af7a4 00000210 nt!IopQueryNameInternal+0x31a (FPO: [Non-Fpo])
08 d7fdbab8 82bece25 8ff18ab0 87ff2400 007af7a4 nt!IopQueryName+0x1b (FPO: [Non-Fpo])
09 d7fdbb40 82bec6a6 00000210 d7fdbc04 d7fdbb01 nt!ObQueryNameStringMode+0x495 (FPO: [Non-Fpo])
0a d7fdbbf8 829cce6b 8ff18ab0 00000000 007af7a4 nt!NtQueryObject+0x186 (FPO: [SEH])
0b d7fdbbf8 77cd5ef0 8ff18ab0 00000000 007af7a4 nt!KiSystemServicePostCall (FPO: [0,3] TrapFrame @ d7fdbc14)

经过一些简单的分析，如果文件被是同步（SYNCHRONIZE）打开的，内核会等待一下锁，等其他线程操作完成，本线程才能拿到所有权。

//
    // Make a special check here to determine whether this is a synchronous
    // I/O operation.  If it is, then wait here until the file is owned by
    // the current thread.  If this is not a (serialized) synchronous I/O
    // operation, then initialize the local event.
    //
    if (FileObject->Flags & FO_SYNCHRONOUS_IO) {
        BOOLEAN interrupted;
        if (!IopAcquireFastLock( FileObject )) {
            status = IopAcquireFileObjectLock( FileObject,
                                               Mode,
                                               (BOOLEAN) ((FileObject->Flags & FO_ALERTABLE_IO) != 0),
                                               &interrupted );
            if (interrupted) {
                ObDereferenceObject( FileObject );
                return status;
            }
        }
        KeClearEvent( &FileObject->Event );
        synchronousIo = TRUE;
    }

所以这里我们就需要通过线程和超时的方式来调用ZwQueryObject，让程序可以不阻塞正常运行。

void
QueryThread(
    IN PQUERY_CONTEXT Context
) {
    Status = ZwQueryObject(TargetHandle, ObjectNameInformation, &NameInfo, sizeof(NameInfo), NULL);
}
ThreadHandle = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)QueryThread, Context, 0, NULL);
Result = WaitForSingleObject(ThreadHandle, 1000); //等待1秒超时，线程退出
TerminateThread(ThreadHandle, 0);
CloseHandle(ThreadHandle);

坑二：文件Map

解决上面的问题之后，我们基本就解决了文件占用的问题，大部分情况下，我们可以正常删除文件了。

可是…

某些时候，我们要删除的文件并不是普通文件，可能是一个DLL、或者其他特殊文件。

关闭所有占用的句柄后，依然无法删除文件，还是提示占用。

这可怎么办？

类似于DLL这种文件，进程在使用中，操作系统会映射一份内存到进程空间，此时并没有句柄与之对应。

但是它却关联了文件的内核对象，专业术语说增加了一次文件对象的引用。

我们要知道，为了能够安全删除一个文件，操作系统需要保证该文件的内核对象在两种引用计数上清零。

一个是句柄引用计数，一个是对象引用计数。

前面我们通过枚举句柄，将句柄引用计数清零。

但是因为共享内存的原因，对象引用计数仍未清零，所以无法删除文件。

0: kd> !handle 48
PROCESS fffffa801b7c6060
    SessionId: 1  Cid: 0b70    Peb: 7efdf000  ParentCid: 0588
    DirBase: 1bfea000  ObjectTable: fffff8a0029f27e0  HandleCount: 157.
    Image: procexp.exe
Handle table at fffff8a0029f27e0 with 157 entries in use
0004: Object: fffffa801bdcca10  GrantedAccess: 00000003 Entry: fffff8a0020cc010
Object: fffffa801bdcca10  Type: (fffffa8018dcfa30) File
    ObjectHeader: fffffa801bdcc9e0 (new version)
        HandleCount: 0//句柄引用计数  PointerCount: 1 //对象引用计数

我们通过!vad俩看看内存map。

0: kd> !vad fffffa8019d34e00
VAD           Level     Start       End Commit
fffffa8019d34e00  0      1000      12ce      0 Mapped       READONLY           \Windows\Globalization\Sorting\SortDefault.nls
0: kd> dt _mmvad fffffa8019d34e00
nt!_MMVAD
   +0x000 u1               : <unnamed-tag>
   +0x008 LeftChild        : (null) 
   +0x010 RightChild       : (null) 
   +0x018 StartingVpn      : 0x1000
   +0x020 EndingVpn        : 0x12ce
   +0x028 u                : <unnamed-tag>
   +0x030 PushLock         : _EX_PUSH_LOCK
   +0x038 u5               : <unnamed-tag>
   +0x040 u2               : <unnamed-tag>
   +0x048 Subsection       : 0xfffffa80`1b56ef90 _SUBSECTION
   +0x048 MappedSubsection : 0xfffffa80`1b56ef90 _MSUBSECTION
   +0x050 FirstPrototypePte : 0xfffff8a0`00b02000 _MMPTE
   +0x058 LastContiguousPte : 0xfffff8a0`00b03670 _MMPTE
   +0x060 ViewLinks        : _LIST_ENTRY [ 0xfffffa80`18ec81c0 - 0xfffffa80`18fcd190 ]
   +0x070 VadsProcess      : 0xfffffa80`1b7c6061 _EPROCESS
0: kd> dt 0xfffffa80`1b56ef90 _SUBSECTION
nt!_SUBSECTION
   +0x000 ControlArea      : 0xfffffa80`1b56ef10 _CONTROL_AREA
   +0x008 SubsectionBase   : 0xfffff8a0`00b02000 _MMPTE
   +0x010 NextSubsection   : 0xfffffa80`193a0a60 _SUBSECTION
   +0x018 PtesInSubsection : 0x2cf
   +0x020 UnusedPtes       : 0
   +0x020 GlobalPerSessionHead : (null) 
   +0x028 u                : <unnamed-tag>
   +0x02c StartingSector   : 0
   +0x030 NumberOfFullSectors : 0x2cf
0: kd> dt 0xfffffa80`1b56ef10 _CONTROL_AREA
nt!_CONTROL_AREA
   +0x000 Segment          : 0xfffff8a0`03b31fd0 _SEGMENT
   +0x008 DereferenceList  : _LIST_ENTRY [ 0x00000000`00000000 - 0x00000000`00000000 ]
   +0x018 NumberOfSectionReferences : 0
   +0x020 NumberOfPfnReferences : 0x101
   +0x028 NumberOfMappedViews : 0x2a
   +0x030 NumberOfUserReferences : 0x2a
   +0x038 u                : <unnamed-tag>
   +0x03c FlushInProgressCount : 0
   +0x040 FilePointer      : _EX_FAST_REF
   +0x048 ControlAreaLock  : 0n0
   +0x04c ModifiedWriteCount : 0
   +0x04c StartingFrame    : 0
   +0x050 WaitList         : (null) 
   +0x058 u2               : <unnamed-tag>
   +0x068 LockedPages      : 1
   +0x070 ViewList         : _LIST_ENTRY [ 0xfffffa80`1be91570 - 0xfffffa80`1abbe690 ]
0: kd> dx -id 0,0,fffffa801b7c6060 -r1 (*((ntkrnlmp!_EX_FAST_REF *)0xfffffa801b56ef50))
(*((ntkrnlmp!_EX_FAST_REF *)0xfffffa801b56ef50))                 [Type: _EX_FAST_REF]
    [+0x000] Object           : 0xfffffa801b61fa14 [Type: void *]
    [+0x000 ( 3: 0)] RefCnt           : 0x4 [Type: unsigned __int64]
    [+0x000] Value            : 0xfffffa801b61fa14 [Type: unsigned __int64]
0: kd> !object 0xfffffa801b61fa10
Object: fffffa801b61fa10  Type: (fffffa8018dcfa30) File
    ObjectHeader: fffffa801b61f9e0 (new version)
    HandleCount: 0  PointerCount: 5
    Directory Object: 00000000  Name: \Windows\Globalization\Sorting\SortDefault.nls {HarddiskVolume2}
0: kd> dt _file_object 0xfffffa801b61fa10
nt!_FILE_OBJECT
   +0x000 Type             : 0n5
   +0x002 Size             : 0n216
   +0x008 DeviceObject     : 0xfffffa80`19e9d530 _DEVICE_OBJECT
   +0x010 Vpb              : 0xfffffa80`19eca270 _VPB
   +0x018 FsContext        : 0xfffff8a0`00ad0140 Void
   +0x020 FsContext2       : 0xfffff8a0`00ad0330 Void
   +0x028 SectionObjectPointer : 0xfffffa80`1b61f808 _SECTION_OBJECT_POINTERS
0: kd> dx -id 0,0,fffffa801b7c6060 -r1 ((ntkrnlmp!_SECTION_OBJECT_POINTERS *)0xfffffa801b61f808)
((ntkrnlmp!_SECTION_OBJECT_POINTERS *)0xfffffa801b61f808)                 : 0xfffffa801b61f808 [Type: _SECTION_OBJECT_POINTERS *]
    [+0x000] DataSectionObject : 0xfffffa801b56ef10 [Type: void *] //其实就是前面的_mmvad->Subsection->ControlArea
    [+0x008] SharedCacheMap   : 0x0 [Type: void *]
    [+0x010] ImageSectionObject : 0x0 [Type: void *]

SortDefault.nls是被映射到了进程中，通过_mmvad->Subsection->ControlArea->FilePointer我们可以一步步定位到它引用的文件对象。

!object 0xfffffa801b61fa10看到确实是该文件，也可以通过fileobject->SectionObjectPointer->DataSectionObject找到对应的映射内存。

如此我们初步理解了文件map导致文件占用无法删除文件的原理。

下面我们就需要找到方法怎么解决这个问题。

首先，需要枚举进程的虚拟内存，找到是否有我们需要查找的文件的map，然后对该进程有两种操作：

1. 非常暴力但是简单的方法，那就是直接关闭进程

2. 或者unmap这块内存，解除对象引用计数（经过测试，未成功）

如何枚举虚拟内存呢，使用ZwQueryVirtualMemory.

NTSTATUS ZwQueryVirtualMemory(
  _In_      HANDLE                   ProcessHandle,
  _In_opt_  PVOID                    BaseAddress,
  _In_      MEMORY_INFORMATION_CLASS MemoryInformationClass,
  _Out_     PVOID                    MemoryInformation,
  _In_      SIZE_T                   MemoryInformationLength,
  _Out_opt_ PSIZE_T                  ReturnLength
);
//MemoryBasicInformation
typedef struct _MEMORY_BASIC_INFORMATION {
  PVOID  BaseAddress;
  PVOID  AllocationBase;
  ULONG  AllocationProtect;
  USHORT PartitionId;
  SIZE_T RegionSize;
  ULONG  State;
  ULONG  Protect;
  ULONG  Type;
} MEMORY_BASIC_INFORMATION, *PMEMORY_BASIC_INFORMATION;
Type
The type of pages in the region. The following types are defined.
MEM_IMAGE 0x1000000 Indicates that the memory pages within the region are mapped into the view of an image section.
MEM_MAPPED 0x40000  Indicates that the memory pages within the region are mapped into the view of a section.
MEM_PRIVATE 0x20000 Indicates that the memory pages within the region are private (that is, not shared by other processes).

从0地址开始，每次加一个页，获取内存信息，如果内存的type是MEM_IMAGE或者MEM_MAPPED，那么就是文件map，然后获取虚拟内存对应名字，判断是不是目标文件。

for (;;) {
    Status = ZwQueryVirtualMemory(ProcessHandle, BaseAddress, MemoryBasicInformation,
        &MemoryInfo, sizeof(MemoryInfo), NULL);
    if (MemoryInfo.Type == MEM_IMAGE ||  //image
        MemoryInfo.Type == MEM_MAPPED) { //data
            Status = ZwQueryVirtualMemory(ProcessHandle, BaseAddress, MemoryMappedFilenameInformation, &Name, sizeof(Name), NULL);
            if (RtlEqualUnicodeString(&Name.u, &TargetName, TRUE)) {
                //找到目标文件
                break;
            }
        }
    }
}

找到目标进程后，关闭进程，轻松删除文件。

（完）

如果觉得内容还不错，请不吝点赞或在看，谢谢。

欢迎关注公众号：Anhkgg日记本

阅读原文

跳转微信打开

cmake

「日记」CMakeLists使用笔记
by anhkgg
2019年3月3日

最近用了一下cmake，虽然还不熟练，但是感觉比Makefile更简单，并且是跨平台的。

这里大概总结一下常用语法。

首先，cmake命令可以全大写或者全小写。

最简单的

//test.cpp
#include <stdio.h>
int main()
{
    printf("hello CMakeLists\n");
    return 0;
}

编写CMakeLists.txt

# CMake 最低版本号要求
cmake_minimum_required (VERSION 2.8)
# 项目信息
project (test)
# 查找当前目录下的所有源文件
# 并将名称保存到 DIR_SRCS 变量
aux_source_directory(. DIR_SRCS)
# 指定生成目标
add_executable(test ${DIR_SRCS})

编译

mkdir build
cd build
cmake ..
make

静态库

//testlib.cpp
int add(int a, int b)
{
    return a+b;
}

# CMake 最低版本号要求
cmake_minimum_required (VERSION 2.8)
# 项目信息
project (testlib)
# 查找当前目录下的所有源文件
# 并将名称保存到 DIR_SRCS 变量
aux_source_directory(. DIR_SRCS)
# 指定生成目标
add_library(testlib STATIC ${DIR_SRCS})

➜  build make
Scanning dependencies of target testlib
[ 50%] Building CXX object CMakeFiles/testlib.dir/testlib.cpp.o
[100%] Linking CXX static library libtestlib.a
[100%] Built target testlib

链接静态库

//test.cpp
#include <stdio.h>
int add(int a, int b);
int main()
{
    printf("1 + 2 = %d\n", add(1, 2));
    return 0;
}

# CMake 最低版本号要求
cmake_minimum_required (VERSION 2.8)
# 项目信息
project (test)
# 查找当前目录下的所有源文件
# 并将名称保存到 DIR_SRCS 变量
aux_source_directory(. DIR_SRCS)
# 指定生成目标
add_executable(test ${DIR_SRCS})
find_library(
    TESTLIB testlib
    PATHS ./build)
message(${TESTLIB})
target_link_libraries (test ${TESTLIB})

动态库

# CMake 最低版本号要求
cmake_minimum_required (VERSION 2.8)
# 项目信息
project (testlib)
# 查找当前目录下的所有源文件
# 并将名称保存到 DIR_SRCS 变量
aux_source_directory(. DIR_SRCS)
# 指定生成目标
add_library(testlib SHARED ${DIR_SRCS})

[ 33%] Building CXX object CMakeFiles/testlib.dir/test.cpp.o
[ 66%] Building CXX object CMakeFiles/testlib.dir/testlib.cpp.o
[100%] Linking CXX shared library libtestlib.so
[100%] Built target testlib

安装

# 指定 编译目标 的安装路径
install (TARGETS test DESTINATION bin)

make install

其他命令

include_directories：指定头文件的搜索路径，相当于指定gcc的-I参数
>> include_directories (${HELLO_SOURCE_DIR}/Hello)  #增加Hello为include目录
link_directories：动态链接库或静态链接库的搜索路径，相当于gcc的-L参数
       >> link_directories (${HELLO_BINARY_DIR}/Hello)     #增加Hello为link目录
add_subdirectory：包含子目录
       >> add_subdirectory (Hello)
add_executable：编译可执行程序，指定编译，好像也可以添加.o文件
       >> add_executable (helloDemo demo.cxx demo_b.cxx)   #将cxx编译成可执行文件——
add_custom_target:
message( status|fatal_error, “message”):
set_target_properties( ... ): lots of properties... OUTPUT_NAME, VERSION, ....
link_libraries( lib1 lib2 ...): All targets link with the same set of libs
set environment variable，设置环境变量，编译用到的源文件全部都要放到这里，否则编译能够通过，但是执行的时候会出现各种问题，比如"symbol lookup error xxxxx , undefined symbol"
SET(TEST_MATH
 ${DIR_SRCS}
)

https://www.jianshu.com/p/5a63414f0691
https://www.cnblogs.com/cv-pr/p/6206921.html
https://www.cnblogs.com/lidabo/p/7359422.html
https://www.hahack.com/codes/cmake/

阅读原文

跳转微信打开

看bolt，破thunder

by Anhkgg | 2018年12月16日 | 078/100

这篇其实应该几天前就写了的，不过耽搁了，现在补上。

已经忘了那天怎么突然想起去搜索了一下"迅雷API"，然后看到了"迅雷7应用开发在线文档"。

地址是：http://xldoc.xl7.xunlei.com/

其中"BOLT界面引擎"真的是让我对迅雷的技术人员刮目相看，虽然我第一次听说这个界面库。

虽然我好像要找到的是"迅雷下载开放引擎"，确实有，但是好像过时，并未更新开放，现在已经不能使用。

我对bolt前前后后大致了解了一下，对原理、如何使用有了一定的印象。

为什么我会突然对此感兴趣呢？因为我其实一直像破一下迅雷，比如去广告、去浏览器窗口页、高速（离线）下载等等。

但确实比较难，一直没下手，这次看到bolt真的是眼睛一亮。

因为最新的迅雷依然是bolt开发，虽然内部使用的bolt已经更新，但有迹可循了。

blot大致来说（我的粗略理解）：

1. 通过ui树来组织界面，提供常用的ui元对象。
2. 使用xml来定义界面元素，lua来完成界面逻辑。
3. 更多功能通过lua调用c接口来完成。
4. xml和lua通过打包加密发布为xar文件
5. bolt sdk提供了几个dll，XLFSIO.dll去解密xar
6. bolt还有字节的绘图引擎（位图、文本、矢量），据说比gdi好

更多细节还需要继续看文档学习，目前大致了解这些。

bolt究竟如何不好说，不过确实已经有很多产品在使用，并且迅雷自己的产品也在使用，应该是比较完善成熟的一套东西了。

另外一个很有名的界面库duilib，也有很多公司再使用，比如360、腾讯、百度等等，并且开源，其实有时间是很有研究的价值的。

不管如何，我都是非常佩服写界面的同志的，更何况是自己开发界面引擎的牛牛。

不过我此时的重点不过使用bolt，而在于破迅雷，希望再后面的研究中能够有大大的帮助。

（完）

阅读原文

跳转微信打开

有针对性的熟悉东西审计就是快

by Anhkgg | 2018年12月25日 | 080/100

因为之前一段时间有尝试挖过内核漏洞，对于该类型漏洞各种触发原因确实比较熟悉了。

无非就那么几类：

0. 初级的，没有校验输入null，或者长度
1. 长度校验不够，导致溢出
2. 无符号、有符号混用，造成数据截断，溢出
3. 输入中有offset，控制可溢出
4. 输入中有指针，控制任意地址读写
5. 字符串非0结尾，可溢出
6. 内存是否合法，可读写缺乏校验，或者校验不够，可绕过
7. 某些内容分内存和长度两个字段表示，相互校验不够严谨，长度可控溢出

总结来说，输入结构越复杂漏洞可能越多。

所以在此处产品代码审计中，很快就找到多个漏洞，大多会忽略字符串的处理，然后是长度的校验。

某些漏洞在fuzz时没有跑出来，一个是因为当时协议分析不够，为绕过协议检查，还有缺少某些payload，如绕过不严谨的内存检查。

后面根据这些情况对fuzz进行了增强，后续验证是否有效。

另外也负责这些漏洞的修复，发现其实都是些非常小的问题，但危害却是不小。

以前的产品都缺乏这方面的教育，虽然是安全产品，也却真的不安全。

还是tx、数字之类的更加有战斗经验，自保护确实都非常不错。

对接口调用的防护使用了非常多的手段
1. 文件签名校验
2. 白名单进程
3. 路径检查、dll劫持防护、dll签名检查等等

总的来说，这次活挺有意义，下次有时间再详细总结一下。

阅读原文

跳转微信打开

Google 牛！

by Anhkgg | 2018年12月14日 | 075/100

写代码这么久，还真是第一次正儿八经写单元测试。以前一直认为编码和测试是两个行当，叫做RD和QA。

最近学了「单元测试」的部分内容之后，才知道测试也分级别，最基本的单元测试是RD自己的事情。其实RD确认也一直做了这件事情，只是我没有意识到而已。

单元测试就是测试写出的函数或类的功能的正确性，保证代码质量，避免出现某些黑盒测试无法覆盖的功能点，把bug消灭在开发阶段，提高效率。

理解之后，其实就知道，平实写代码，进行功能验证的时候，就是在做单元测试。

但是确认没有做到那么规范和完美。

单元测试常用的工具是GTest和BTest，顾名思义，前者叫做google test。

这次我使用的就是GTest，从https://github.com/google/googletest下载代码之后，进入googletest\msvc\2010，打开gtest.sln，然后编译出lib文件。

创建单元测试工程，设置include目录\googletest\include，和lib目录。

基本代码结构就是如此，通过TEST宏来定义单侧函数，尽量做到一个TEST测试一个独立功能，或者相关功能。

#include "gtest/gtest.h"

TEST(ProjectTest, TestName)
{
}

int main(int argc, char** argv)
{
    testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

然后使用EXPECT_EQ来判断函数结果是否符合预期，比如：

EXPECT_EQ(true, GetColumnCount(count));
EXPECT_EQ(5, count);
EXPECT_EQ(0, _stricmp("hijklm", data));

GTesth还有其他高级的功能，Moch，Hook之类，暂时并没有涉及到。

最后如果所有测试用例通过，显示如下：

[==========] Running 2 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 2 tests from WordTableTest
[ RUN      ] WordTableTest.BuildIn
[       OK ] WordTableTest.BuildIn (0 ms)
[ RUN      ] WordTableTest.UserType
[       OK ] WordTableTest.UserType (0 ms)
[----------] 2 tests from WordTableTest (2 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test case ran. (3 ms total)
[  PASSED  ] 2 tests.

阅读原文

跳转微信打开

代码即脸面

by Anhkgg | 2018年12月13日 | 074/100

代码规范就像人的脸面一样，要好看，要能给人看。别人看的越喜欢说明代码写的越好。

代码规范涉及内容其实非常之多，不同语言还有不同的规范。这里就说说命名的规则，什么驼峰（大驼峰、小驼峰）、匈牙利之类的。名字这么优雅，说到底名字的单词写法，第一个字母大小还是小写，或者所有字母小写。

具体如下：

大驼峰式命名规则：FirstName, CamelCase

小驼峰式命名规则：firstName, camelCase

匈牙利命名法：通过在变量名前面加上相应的小写字母的符号标识作为前缀，标识出变量的作用域，类型等这些符号可以多个同时使用，顺序是先m_（成员变量）， 再指针，再简单数据类型，再其它。例如：m_lpszStr, 表示指向一个以0字符结尾的字符串的长指针成员变量。

//https://www.cnblogs.com/Offie/p/5021368.html

属性+类型+描述
属性一般是小写字母+_:
g_:全局变量 m_:类成员变量 s_:静态变量 c_:常量
类型就多了：
b:bool sz:以零结束的字符串 p:指针 n:整整
dw:双字 l:长整型 无符号:u 函数:fn

还有个特别的linux中最常用的下划线命名法，全小写单词加下划线，如print_employee_paychecks。

当然代码规范不仅仅就这点内容，比如还有其他的if后面括号的空格位置，变量初始化，大括号怎么放等等。

Windows代码和linux代码的规范大相径庭，所以如果没有特殊要求，根据个人爱好，习惯一种代码规范，代码会越写越好看，真的就像艺术品一样。

另外好不好看，其实跟使用的字体有非常大的关系，有些字体能够所有字符相同大小，样式规整，代码一罗列起来给人一种铺面而来的美感。

我特别羡慕同事调好的字体，但是我死活调不出跟他一样的效果，只能羡慕、羡慕、羡慕。

最后在总结一点，本次考试代码重构的一点心得。

因为处理的数据，包括不同的类型，比如int，char*，float等等，为了使接口统一，使用方便，就比较适合使用模板来完成，如模板函数。

在数据解析中，不同数据解析方法不同，但为了解析接口统一以及可扩展新的数据类型支持，将解析接口抽象出来，做成了模板接口类。

如此抽象之后，代码结构非常清晰，扩展方便，使用简单，自我感觉是很好的一次代码重构。

最后感觉稍微更喜欢C++那么一点点！

阅读原文

跳转微信打开

晚

by Anhkgg | 2018年12月10日 | 071/100

01 闲聊

休假之后得第一天上班，遇上堵车，折腾了近两小时，一上午都没了。

好不容易进了办公楼，电梯里遇到了公司大老板，蒙了，错过了一次要合影的机会，惨！

02 总结

白天（其实只有下午时间了）主要完成工作上的事情，开了两次会，验证了某个遗留问题。

晚上寻思把前面写的小工具完善了，分享出去。

工具叫做IDARvaTool，其实是用于逆向分析中增加效率的小工具。

因为做逆向调试经常遇到过这种问题：在同时使用两大神器OD(或Windbg)和IDA逆向某程序时，调试中模块基址经常变化，而在IDA中默认为0x400000（或0x10000000），所以在调试到某个点想到IDA整体对比分析一下的时候，发现计算地址真的好麻烦，特别时在经常需要计算的时候，这个问题尤为明显。

所以对于我个人来说，这个工具非常棒！也希望别人能够觉得非常棒！

工具具体见：「神器」不容错过！逆向调试好帮手：神算子偏移计算工具。

阅读原文

跳转微信打开