看流星社区

 找回密码
 注册账号
查看: 2023|回复: 0

[转转]反调试技巧总结-原理和实现-----转

[复制链接]

该用户从未签到

发表于 2017-6-1 13:32:50 | 显示全部楼层 |阅读模式
原本也是转的,但我没找到原作者

标 题:反调试技巧总结-原理和实现-----转
作 者:lcx4
时 间:2016-4-7


链 接:http://www.lcx4.com/?post=51






2008.8.7shellwolf
一、前言
前段学习反调试和vc,写了antidebug-tester,经常会收到message希望交流或索要实现代码,我都没有回复。其实代码已经在编程版提供了1个版本,另其多是vc内嵌asm写的,对cracker而言,只要反下就知道了。我想代码其实意义不是很大,重要的是理解和运用。
做个简单的总结,说明下实现原理和实现方法。也算回复了那些给我发Message的朋友。

部分代码和参考资料来源:
1、<<脱壳的艺术>>hawking
2、<<windowsanti-debuggerreference>>Angeljyt
3、http://bbs.pediy.com
4、<<软件加密技术内幕>>看雪学院
5、<<ANTI-UNPACKERTRICKS>&gteterFerrie

我将反调试技巧按行为分为两大类,一类为检测,另一类为攻击,每类中按操作对象又分了五个小类:
1、通用调试器包括所有调试器的通用检测方法
2、特定调试器包括OD、IDA等调试器,也包括相关插件,也包括虚拟环境
3、断点包括内存断点、普通断点、硬件断点检测
4、单步和跟踪主要针对单步跟踪调试
5、补丁包括文件补丁和内存补丁
反调试函数前缀
检测攻击
通用调试器FD_AD_
特定调试器FS_AS_
断点FB_AB_
单步和跟踪FT_AT_
补丁FP_AP_

声明:
1、本文多数都是摘录和翻译,我只是重新组合并翻译,不会有人告侵权吧。里面多是按自己的理解来说明,可能有理解错误,或有更好的实现方法,希望大家帮忙指出错误。
2、我并没有总结完全,上面的部分分类目前还只有很少的函数甚至空白,等待大家和我一起来完善和补充。我坚信如果有扎实的基础知识,丰富的想像力,灵活的运用,就会创造出更多的属于自己的反调试。而最强的反调试,通常都是自己创造的,而不是来自别人的代码。

二、查找-通用调试器(FD_)
函数列表如下,后面会依次说明,需事先说明的是,这些反调试手段多数已家喻户晓,目前有效的不多,多数已可以通过OD的插件顺利通过,如果你想验证它们的有效性,请关闭OD的所有反反调试插件:
boolFD_IsDebuggerPresent();
boolFD_PEB_BeingDebuggedFlag();
boolFD_PEB_NtGlobalFlags();
boolFD_Heap_HeapFlags();
boolFD_Heap_ForceFlags();
boolFD_Heap_Tail();
boolFD_CheckRemoteDebuggerPresent();
boolFD_NtQueryInfoProc_DbgPort();
boolFD_NtQueryInfoProc_DbgObjHandle();
boolFD_NtQueryInfoProc_DbgFlags();
boolFD_NtQueryInfoProc_SysKrlDbgInfo();
boolFD_SeDebugPrivilege();
boolFD_Parent_Process();
boolFD_DebugObject_NtQueryObject();
boolFD_Find_Debugger_Window();
boolFD_Find_Debugger_Process();
boolFD_Find_Device_Driver();
boolFD_Exception_Closehandle();
boolFD_Exception_Int3();
boolFD_Exception_Popf();
boolFD_OutputDebugString();
boolFD_TEB_check_in_Vista();
boolFD_check_StartupInfo();
boolFD_Parent_Process1();
boolFD_Exception_Instruction_count();
boolFD_INT_2d();

2.1FD_IsDebuggerPresent()
对调试器来说,IsDebuggerPresent是臭名昭著的恶意函数。不多说了,它是个检测调试的api函数。实现更简单,只要调用IsDebuggerPresent就可以了。在调用它之前,可以加如下代码,以用来检测是否在函数头有普通断点,或是否被钩挂。
//checksoftbreak
if(*(BYTE*)Func_addr==0xcc)
returntrue;
//checkhook
if(*(BYTE*)Func_addr!=0x64)
returntrue;
2.2FD_PEB_BeingDebuggedFlag
我们知道,如果程序处于调试器中,那么在PEB结构中有个beingDegug标志会被设置,直接读取它就可判断是否在调试器中。实际上IsDebuggerPresent就是这么干的。
__asm
{
moveax,fs:[30h];EAX=TEB.ProcessEnvironmentBlock
inceax
inceax
moveax,[eax]
andeax,0x000000ff;AL=PEB.BeingDebugged
testeax,eax
jnert_label
jmprf_label
}

2.3FD_PEB_NtGlobalFlags
PEB中还有其它FLAG表明了调试器的存在,如NtGlobalFlags。它位于PEB环境中偏移为0x68的位置,默认情况下该值为0,在win2k和其后的windows平台下,如果在调试中,它会被设置为一个特定的值。使用该标志来判断是否被调试并不可靠(如在winnt中),但这种方法却也很常用。这个标志由下面几个标志组成:
***_HEAP_ENABLE_TAIL_CHECK(0x10)
***_HEAP_ENABLE_FREE_CHECK(0x20)
***_HEAP_VALIDATE_PARAMETERS(0x40)
检测NtGlobalFlags的方法如下,这个方法在ExeCryptor中使用过。
__asm
{
moveax,fs:[30h]
moveax,[eax+68h]
andeax,0x70
testeax,eax
jnert_label
jmprf_label
}

2.4FD_Heap_HeapFlags()
同样,调试器也会在堆中留下痕迹,你可以使用kernel32_GetProcessHeap()函数,如果你不希望使用api函数(以免暴露),则可以直接在PEB中寻找。同样的,使用HeapFlags和后面提到的ForceFlags来检测调试器也不是非常可靠,但却很常用。
这个域由一组标志组成,正常情况下,该值应为2。
__asm
{
moveax,fs:[30h]
moveax,[eax+18h]EB.ProcessHeap
moveax,[eax+0ch]EB.ProcessHeap.Flags
cmpeax,2
jnert_label
jmprf_label
}

2.5FD_Heap_ForceFlags
进程堆里另外一个标志,ForceFlags,它也由一组标志组成,正常情况下,该值应为0。
__asm
{
moveax,fs:[30h]
moveax,[eax+18h]EB.ProcessHeap
moveax,[eax+10h]EB.ProcessHeap.ForceFlags
testeax,eax
jnert_label
jmprf_label
}

2.6FD_Heap_Tail
如果处于调试中,堆尾部也会留下痕迹。标志HEAP_TAIL_CHECKING_ENABLED将会在分配的堆块尾部生成两个0xABABABAB。如果需要额外的字节来填充堆尾,HEAP_FREE_CHECKING_ENABLED标志则会生成0xFEEEFEEE。

据说Themida使用过这个反调试
__asm
{
moveax,buff
;getunused_bytes
movzxecx,byteptr[eax-2]
movzxedx,wordptr[eax-8];size
subeax,ecx
leaedi,[edx*8+eax]
moval,0abh
movcl,8
repesca**
jert_label
jmprf_label
}

2.7FD_CheckRemoteDebuggerPresent
CheckRemoteDebuggerPresent是另一个检测调试的api,只是可惜它似乎只能在winxpsp1版本以后使用。它主要是用来查询一个在winnt时就有的一个数值,其内部会调用NtQueryInformationProcess(),我是这样实现的:
FARPROCFunc_addr;
HMODULEhModule=GetModuleHandle("kernel32.dll");
if(hModule==INVALID_HANDLE_VALUE)
returnfalse;
(FARPROC&)Func_addr=GetProcAddress(hModule,"CheckRemoteDebuggerPresent");
if(Func_addr!=NULL)
{
__asm
{
pusheax;
pushesp;
push0xffffffff;
callFunc_addr;
testeax,eax;
jerf_label;
popeax;
testeax,eax
jerf_label;
jmprt_label;
}
}

2.8FD_NtQueryInfoProc_DbgPort
使用ntdll_NtQueryInformationProcess()来查询ProcessDebugPort可以用来检测反调试。如果进程被调试,其返回值应为0xffffffff。
下面的代码应该是从pediy里copy过来的,时间太长,不记得是哪位兄弟的代码了。
HMODULEhModule=GetModuleHandle("ntdll.dll");
ZW_QUERY_INFORMATION_PROCESSZwQueryInformationProcess;
ZwQueryInformationProcess=(ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule,"ZwQueryInformationProcess");
if(ZwQueryInformationProcess==NULL)
returnfalse;
PROCESS_DEBUG_PORT_INFOProcessInfo;
if(STATUS_SUCCESS!=ZwQueryInformationProcess(GetCurrentProcess(),ProcessDebugPort,&amprocessInfo,sizeof(ProcessInfo),NULL))
returnfalse;
else
if(ProcessInfo.DebugPort)
returntrue;
else
returnfalse;

2.9FD_NtQueryInfoProc_DbgObjHandle
在winxp中引入了"debugobject".当一个调试活动开始,一个"debugobject"被创建,同也相应产生了一个句柄。使用为公开的ProcessDebugObjectHandle类,可以查询这个句柄的数值。
代码可能还是从pediy里复制的,不记得了。
HMODULEhModule=GetModuleHandle("ntdll.dll");
ZW_QUERY_INFORMATION_PROCESSZwQueryInformationProcess;
ZwQueryInformationProcess=(ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule,"ZwQueryInformationProcess");
if(ZwQueryInformationProcess==NULL)
returnfalse;
_PROCESS_DEBUG_OBJECTHANDLE_INFOProcessInfo;
if(STATUS_SUCCESS!=ZwQueryInformationProcess(GetCurrentProcess(),(PROCESS_INFO_CLASS)0x0000001e,&amprocessInfo,sizeof(ProcessInfo),NULL))
returnfalse;
else
if(ProcessInfo.ObjectHandle)
returntrue;
else
returnfalse;

2.10FD_NtQueryInfoProc_DbgFlags();
同样的未公开的ProcessDebugFlags类,当调试器存在时,它会返回false。
HMODULEhModule=GetModuleHandle("ntdll.dll");
ZW_QUERY_INFORMATION_PROCESSZwQueryInformationProcess;
ZwQueryInformationProcess=(ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule,"ZwQueryInformationProcess");
if(ZwQueryInformationProcess==NULL)
returnfalse;
_PROCESS_DEBUG_FLAGS_INFOProcessInfo;
if(STATUS_SUCCESS!=ZwQueryInformationProcess(GetCurrentProcess(),(PROCESS_INFO_CLASS)0x0000001f,&amprocessInfo,sizeof(ProcessInfo),NULL))
returnfalse;
else
if(ProcessInfo.Debugflags)
returnfalse;
else
returntrue;

2.11FD_NtQueryInfoProc_SysKrlDbgInfo()
这个方法估计对大家用处不大,SystemKernelDebuggerInformation类同样可以用来识别调试器,只是可惜在windows下无效,据称可以用在reactOS中。
HMODULEhModule=GetModuleHandle("ntdll.dll");
ZW_QUERY_SYSTEM_INFORMATIONZwQuerySystemInformation;
ZwQuerySystemInformation=(ZW_QUERY_SYSTEM_INFORMATION)GetProcAddress(hModule,"ZwQuerySystemInformation");
if(ZwQuerySystemInformation==NULL)
returnfalse;
SYSTEM_KERNEL_DEBUGGER_INFORMATIONInfo;
if(STATUS_SUCCESS==ZwQuerySystemInformation(SystemKernelDebuggerInformation,&Info,sizeof(Info),NULL))
{
if(Info.DebuggerEnabled)
{
if(Info.DebuggerNotPresent)
returnfalse;
else
returntrue;
}
else
returnfalse;
}
else
returntrue;



2.12FD_SeDebugPrivilege()
当一个进程获得SeDebugPrivilege,它就获得了对CSRSS.EXE的完全控制,这种特权也会被子进程继承,也就是说一个被调试的程序如果获得了CSRSS.EXE的进程ID,它就可以使用openprocess操作CSRSS.EXE。获得其进程ID有很多中方法,如Process32Next,或NtQuerySystemInformation,在winxp下可以使用CsrGetProcessId。
hTmp=OpenProcess(PROCESS_ALL_ACCESS,false,PID_csrss);
if(hTmp!=NULL)
{
CloseHandle(hProcessSnap);
returntrue;
}

2.13FD_Parent_Process()
通常我们都直接在windows界面下运行应用程序,这样的结果就是它的父进程为"explorer.exe",这个反调试就是检测应用程序的父进程是否为"explorer.exe",如不是则判定为处于调试器中,这也不是百分百可靠,因为有的时候你的程序是在命令行提示符下运行的。
Yoda使用了这个反调试,它使用Process32Next检测父进程,目前很多插件已经通过使Process32Next始终返回false来越过这个反调试(比如HideOD)。不过可以对代码做些简单的修正来处理这个反反调试。

2.14FD_DebugObject_NtQueryObject();
如前面所描述的,当一个调试活动开始,一个"debugobject"被创建,同也相应产生了一个句柄。我们可以查询这个调试对象列表,并检查调试对象的数量,以实现调试器的检测。
HMODULEhModule=GetModuleHandle("ntdll.dll");
PNtQueryObjectNtQueryObject;
NtQueryObject=(PNtQueryObject)GetProcAddress(hModule,"NtQueryObject");

if(NtQueryObject==NULL)
returnfalse;
unsignedcharszdbgobj[25]=
"\x44\x00\x65\x00\x62\x00\x75\x00\x67\x00\x4f\x00\x62\x00\x6a\x00\x65\x00\x63\x00\x74\x00\x00\x00";
unsignedchar*psz=&szdbgobj[0];
__asm
{
xorebx,ebx;
pushebx;
pushesp;
pushebx;
pushebx;
push3;
pushebx;
Calldwordptr[NtQueryObject];
popedi;
push4;
push1000h;
pushedi;
pushebx;
calldwordptr[VirtualAlloc];
pushebx;
pushedi;
pusheax;
push3;
pushebx;
xchgesi,eax;
Calldwordptr[NtQueryObject];
lodsd;
xchgecx,eax;
lable1:lodsd;
movzxedx,ax;
lodsd;
xchgesi,eax;
cmpedx,16h;
jnelabel2;
xchgecx,edx;
movedi,psz;
repecmp**;
xchgecx,edx;
jnelabel2;
cmpdwordptr[eax],edx
jnert_label;
lable2:addesi,edx
andesi,-4;
lodsd
looplabel1;
}
returnfalse;
rt_label:
returntrue;
2.15FD_Find_Debugger_Window();
通过列举运行的应用程序的窗口,并于常用调试相关工具比对的方法,应该很常用了,就不多说了。这个也是个可以自行增加项目的函数,你可以将一些常用的调试工具归入其中,比如OD,IDA,WindBG,SoftICE等,你也可以添加任何你需要的,比如"ImportREConstructorv1.6FINAL(C)2001-2003MackT/uCF","RegistryMonitor-Sysinternals:www.sysinternals.com"等等。
//ollyice
hWnd=CWnd::FindWindow(_T("1212121"),NULL);
if(hWnd!=NULL)
returntrue;
//ollydbgv1.1
hWnd=CWnd::FindWindow(_T("icu_dbg"),NULL);
if(hWnd!=NULL)
returntrue;
//ollyicepe--diy
hWnd=CWnd::FindWindow(_T("pe--diy"),NULL);
if(hWnd!=NULL)
returntrue;
//ollydbg?-°?
hWnd=CWnd::FindWindow(_T("ollydbg"),NULL);
if(hWnd!=NULL)
returntrue;
//ollydbg?-°?
hWnd=CWnd::FindWindow(_T("odbydyk"),NULL);
if(hWnd!=NULL)
returntrue;
//windbg
hWnd=CWnd::FindWindow(_T("WinDbgFrameClass"),NULL);
if(hWnd!=NULL)
returntrue;
//dede3.50
hWnd=CWnd::FindWindow(_T("TDeDeMainForm"),NULL);
if(hWnd!=NULL)
returntrue;
//IDA5.20
hWnd=CWnd::FindWindow(_T("TIdaWindow"),NULL);
if(hWnd!=NULL)
returntrue;
//others
hWnd=CWnd::FindWindow(_T("TESTDBG"),NULL);
if(hWnd!=NULL)
returntrue;
hWnd=CWnd::FindWindow(_T("kk1"),NULL);
if(hWnd!=NULL)
returntrue;
hWnd=CWnd::FindWindow(_T("Eew75"),NULL);
if(hWnd!=NULL)
returntrue;
hWnd=CWnd::FindWindow(_T("Shadow"),NULL);
if(hWnd!=NULL)
returntrue;
//PEiDv0.94
hWnd=CWnd::FindWindow(NULL,&quotEiDv0.94");
if(hWnd!=NULL)
returntrue;
//RegMON
hWnd=CWnd::FindWindow(NULL,"RegistryMonitor-Sysinternals:www.sysinternals.com");
if(hWnd!=NULL)
returntrue;
//FileMonitor
hWnd=CWnd::FindWindow(NULL,"FileMonitor-Sysinternals:www.sysinternals.com");
if(hWnd!=NULL)
returntrue;
//ImportRecv1.6
hWnd=CWnd::FindWindow(NULL,"ImportREConstructorv1.6FINAL(C)2001-2003MackT/uCF");
if(hWnd!=NULL)
returntrue;
returnfalse;

2.16FD_Find_Debugger_Process();
与上面的方法类似,区别是这个反调试用通过查询进程名字与已知的常用调试器应用程序名字进行比对,以确定是否有调试器处于运行状态。
if(strcmp(pe32.szExeFile,"OLLYICE.EXE")==0)
returntrue;
if(strcmp(pe32.szExeFile,"IDAG.EXE")==0)
returntrue;
if(strcmp(pe32.szExeFile,"OLLYDBG.EXE")==0)
returntrue;
if(strcmp(pe32.szExeFile,&quotEID.EXE")==0)
returntrue;
if(strcmp(pe32.szExeFile,"SOFTICE.EXE")==0)
returntrue;
if(strcmp(pe32.szExeFile,"LORDPE.EXE")==0)
returntrue;
if(strcmp(pe32.szExeFile,"IMPORTREC.EXE")==0)
returntrue;
if(strcmp(pe32.szExeFile,"W32DSM89.EXE")==0)
returntrue;
if(strcmp(pe32.szExeFile,"WINDBG.EXE")==0)
returntrue;


2.17FD_Find_Device_Driver()
调试工具通常会使用内核驱动,因此如果尝试是否可以打开一些调试器所用到的设备,就可判断是否存在调试器。常用的设备名称如下:
\\.\SICE(SoftICE)
\\.\SIWVID(SoftICE)
\\.\NTICE(SoftICE)
\\.\REGVXG(RegMON)
\\.\REGVXD(RegMON)
\\.\REGSYS(RegMON)
\\.\REGSYS(RegMON)
\\.\FILEVXG(FileMON)
\\.\FILEM(FileMON)
\\.\TRW(TRW2000)

2.18FD_Exception_Closehandle()
如果给CloseHandle()函数一个无效句柄作为输入参数,在无调试器时,将会返回一个错误代码,而有调试器存在时,将会触发一个EXCEPTION_INVALID_HANDLE(0xc0000008)的异常。
__try
{
CloseHandle(HANDLE(0x00001234));
returnfalse;
}
__except(1)
{
returntrue;
}



2.19FD_Exception_Int3()
通过Int3产生异常中断的反调试比较经典。当INT3被执行到时,如果程序未被调试,将会异常处理器程序继续执行。而INT3指令常被调试器用于设置软件断点,int3会导致调试器误认为这是一个自己的断点,从而不会进入异常处理程序。
__asm
{
pushoffsetexception_handler;setexceptionhandler
pushdwordptrfs:[0h]
movdwordptrfs:[0h],esp
xoreax,eax;resetEAXinvokeint3
int3h
popdwordptrfs:[0h];restoreexceptionhandler
addesp,4

testeax,eax;checktheflag
jert_label
jmprf_label

exception_handler:
moveax,dwordptr[esp+0xc];EAX=ContextRecord
movdwordptr[eax+0xb0],0xffffffff;setflag(ContextRecord.EAX)
incdwordptr[eax+0xb8];setContextRecord.EIP
xoreax,eax
retn

rt_label:
xoreax,eax
inceax
movesp,ebp
popebp
retn
rf_label:
xoreax,eax
movesp,ebp
popebp
retn
}

2.20FD_Exception_Popf()
我们都知道标志寄存器中的陷阱标志,当该标志被设置时,将产生一个单步异常。在程序中动态设置这给标志,如果处于调试器中,该异常将会被调试器捕获。
可通过下面的代码设置标志寄存器。
pushf
movdwordptr[esp],0x100
popf

2.21FD_OutputDebugString()
在有调试器存在和没有调试器存在时,OutputDebugString函数表现会有所不同。最明显的不同是,如果有调试器存在,其后的GetLastError()的返回值为零。
OutputDebugString("");
tmpD=GetLastError();
if(tmpD==0)
returntrue;
returnfalse;

2.22FD_TEB_check_in_Vista();
这是从windowsanti-debugreference里拷贝出来的,据说是适用于vista系统下检测调试器。我没有vista所以也没有测试。有条件的可以试下,有问题帮忙反馈给我。多谢。
//vista
__asm
{
pushoffsetexception_handler;setexceptionhandler
pushdwordptrfs:[0h]
movdwordptrfs:[0h],esp
xoreax,eax;resetEAXinvokeint3
int3h
popdwordptrfs:[0h];restoreexceptionhandler
addesp,4
moveax,fs:[18h];teb
addeax,0BFCh
movebx,[eax];pointertoaunicodestring
testebx,ebx;(ntdll.dll,gdi32.dll,...)
jerf_label
jmprt_label
exception_handler:
moveax,dwordptr[esp+0xc];EAX=ContextRecord
incdwordptr[eax+0xb8];setContextRecord.EIP
xoreax,eax
retn
}

2.23FD_check_StartupInfo();
这是从pediy上拷贝来的。Window创建进程的时候会把STARTUPINFO结构中的值设为0,而通过调试器创建进程的时候会忽略这个结构中的值,也就是结构中的值不为0,所以可以利用这个来判断是否在调试程序。
STARTUPINFOsi;
ZeroMemory(&si,sizeof(si));
si.cb=sizeof(si);
GetStartupInfo(&si);
if((si.dwX!=0)||(si.dwY!=0)
||(si.dwXCountChars!=0)||(si.dwYCountChars!=0)
||(si.dwFillAttribute!=0)||(si.dwXSize!=0)
||(si.dwYSize!=0))
returntrue;
else
returnfalse;

2.24FD_Parent_Process1()
与前面的FD_Parent_Process原理一样,唯一不同的是使用ZwQueryInformationProcess检测父进程,而没有使用Process32Next,这有一个好处是可以绕过OD的HideOD插件。

2.25FD_Exception_Instruction_count()
好像《软件加解密技术》中有提到这个反调试。
通过注册一个异常句柄,在特定地址设置一些硬件断点,当通过这些地址时都会触发EXCEPTION_SINGLE_STEP(0x80000004)的异常,在异常处理程序中,将会调整指令指针到一条新指令,然后恢复运行。可以通过进入进程context结构来设置这些断点,有些调试器不能处理那些不是自己设置的硬件断点,从而导致一些指令将会被漏掉计数,这就形成了一个反调试。
__asm
{
xoreax,eax;
cdq;
pushe_handler;
pushdwordptrfs:[eax];
movfs:[eax],esp;
int3;
hwbp1:nop
hwbp2:nop
hwbp3:nop
hwbp4:nop
divedx
nop
popdwordptrfs:[0]
addesp,4
cmpal,4;
jnert_label;
jmprf_label;

e_handler:
xoreax,eax;
;ExceptionRecord
movecx,dwordptr[esp+0x04]
;Contextrecord
movedx,dwordptr[esp+0x0c]
;ContextEIP
incbyteptr[edx+0xb8];

;ExceptionCode
movecx,dwordptr[ecx];

;1.EXCEPTION_INT_DIVIDE_BY_ZERO
cmpecx,0xc0000094;
jneEx_next2;
;Context_eip
incbyteptr[edx+0xb8];
movdwordptr[edx+0x04],eax;dr0
movdwordptr[edx+0x08],eax;dr1
movdwordptr[edx+0x0c],eax;dr2
movdwordptr[edx+0x10],eax;dr3
movdwordptr[edx+0x14],eax;dr6
movdwordptr[edx+0x18],eax;dr7
ret

;2.EXCEPTION_BREAKPOINT
Ex_next2:
cmpecx,0x80000003;
jneEx_next3;

movdwordptr[edx+0x04],offsethwbp1;dr0
movdwordptr[edx+0x08],offsethwbp2;dr1
movdwordptr[edx+0x0c],offsethwbp3;dr2
movdwordptr[edx+0x10],offsethwbp4;dr3
movdwordptr[edx+0x18],0x155;dr7
ret

;3.EXCEPTION_SINGLE_STEP
Ex_next3:
cmpecx,0x80000004
jnert_label
;CONTEXT_Eax
incbyteptr[edx+0xb0]
ret
}

2.26FD_INT_2d()
在windowsanti-debugreference中指出,如果程序未被调试这个中断将会生产一个断点异常.被调试并且未使用跟踪标志执行这个指令,将不会有异常产生程序正常执行.如果被调试并且指令被跟踪,尾随的字节将被跳过并且执行继续.因此,使用INT2Dh能作为一个强有力的反调试和反跟踪机制。
__try
{
__asm
{
int2dh
inceax;anyopcodeofsinglebyte.
;orucanputsomejunkcode,"0xc8"..."0xc2"..."0xe8"..."0xe9"
}
returntrue;
}
__except(1)
{
returnfalse;
}



三、检测-专用调试器(FS_)
这一部分是我比较喜欢的,但内容还不是很丰富,比如:
1、针对SoftIce的检测方法有很多,但由于我从没使用过Softice,也没有条件去测试,所以没有给出太多,有兴趣的可以自己查阅资料进行补充,针对softice网上资料较多,或查阅《软件加解密技术》。
2、同样,这里也没有给出windbg等等其它调试器的检测方法。
3、而针对Odplugin,也只给了几种HideOD的检测。事实上,目前OD的使用者通常都使用众多的强大插件,当OD的反调试越来越普遍时,自己设计几款常用的OD插件的反调试,将会是非常有效的反调试手段。
4、对VME的检测也只给出了两种,如想丰富这一部分可以参考PeterFerrie的一篇anti-vme的文章(http://bbs.pediy.com/showthread.php?t=68411)。里面有非常多的anti-vme方法。

针对专用调试器的函数列表如下:
//findspecificdebugger
boolFS_OD_Exception_GuardPages();
boolFS_OD_Int3_Pushfd();
boolFS_SI_UnhandledExceptionFilter();
boolFS_ODP_Process32NextW();
boolFS_ODP_OutputDebugStringA();
boolFS_ODP_OpenProcess();
boolFS_ODP_CheckRemoteDebuggerPresent();
boolFS_ODP_ZwSetInformationThread();
boolFS_SI_Exception_Int1();
boolIsInsideVMWare_();
boolFV_VMWare_VMX();
boolFV_VPC_Exception();
intFV_VME_RedPill();//0:none,1:vmvare;2:vpc;3thers

3.1FS_OD_Exception_GuardPages
“保护页异常”是一个简单的反调试技巧。当应用程序尝试执行保护页内的代码时,将会产生一个EXCEPTION_GUARD_PAGE(0x80000001)异常,但如果存在调试器,调试器有可能接收这个异常,并允许该程序继续运行,事实上,在OD中就是这样处理的,OD使用保护页来实现内存断点。
最开始实现时忘记了free申请的空间,多谢sessiondiy提醒。

SYSTEM_INFOsSysInfo;
LPVOIDlpvBase;
BYTE*lptmpB;
GetSystemInfo(&sSysInfo);
DWORDdwPageSize=sSysInfo.dwPageSize;
DWORDflOldProtect;

DWORDdwErrorcode;

lpvBase=VirtualAlloc(NULL,dwPageSize,MEM_COMMIT,PAGE_READWRITE);
if(lpvBase==NULL)
returnfalse;

lptmpB=(BYTE*)lpvBase;
*lptmpB=0xc3;//retn

VirtualProtect(lpvBase,dwPageSize,PAGE_EXECUTE_READ|PAGE_GUARD,&flOldProtect);

__try
{
__asmcalldwordptr[lpvBase];
VirtualFree(lpvBase,0,MEM_RELEASE);
returntrue;
}
__except(1)
{
VirtualFree(lpvBase,0,MEM_RELEASE);
returnfalse;
}

3.2FS_OD_Int3_Pushfd
这是个最近比较牛X的反调试,据称是vmp1.64里发现的,好像ttprotect里面也有使用,我没有验证。Pediy里有帖子详细讨论,我是看到gkend的分析,才搞懂一些。下面摘自gkend分析

int3,pushfd和int3,popfd一样的效果。只要修改int3后面的popfd为其他值,OD都能通过。老掉牙的技术又重新被用了。SEH异常机制的运用而已。
原理:在SEH异常处理中设置了硬件断点DR0=EIP+2,并把EIP的值加2,那么应该在int3,popfd后面的指令执行时会产生单步异常。但是OD遇到前面是popfd/pushfd时,OD会自动在popfd后一指令处设置硬件断点,而VMP的seh异常处理会判断是否已经设置硬件断点,如果已经有硬件断点就不产生单步异常,所以不能正常执行。
[/code]


大家也可以仔细研究下OD下的pushfd,popfd等指令,相信利用它们可以构造很多反调试,下面是我实现的一个,不过现在看起来有点没看懂,不知当时为什么用了两个int3。
__asm
{
pushoffsete_handler;setexceptionhandler
pushdwordptrfs:[0h]
movdwordptrfs:[0h],esp
xoreax,eax;resetEAXinvokeint3
int3h
pushfd
nop
nop
nop
nop
popdwordptrfs:[0h];restoreexceptionhandler
addesp,4

testeax,eax;checktheflag
jerf_label
jmprt_label

e_handler:
pushoffsete_handler1;setexceptionhandler
pushdwordptrfs:[0h]
movdwordptrfs:[0h],esp
xoreax,eax;resetEAXinvokeint3
int3h
nop
popdwordptrfs:[0h];restoreexceptionhandler
addesp,4
;EAX=ContextRecord
movebx,eax;dr0=>ebx
moveax,dwordptr[esp+0xc]
;setContextRecord.EIP
incdwordptr[eax+0xb8];
movdwordptr[eax+0xb0],ebx;dr0=>eax
xoreax,eax
retn

e_handler1:
;EAX=ContextRecord
moveax,dwordptr[esp+0xc]
;setContextRecord.EIP
incdwordptr[eax+0xb8];
movebx,dwordptr[eax+0x04]
movdwordptr[eax+0xb0],ebx;dr0=>eax
xoreax,eax
retn
rt_label:
xoreax,eax
inceax
movesp,ebp
popebp
retn
rf_label:
xoreax,eax
movesp,ebp
popebp
retn
}

3.3FS_SI_UnhandledExceptionFilter
这个针对SoftIce的反调试很简单,好像是SoftIce会修改UnhandledExceptionFilter这个函数的第一个字节为CC。因此判断这个字节是否为cc,就是一种检查softice的简便方法。

FARPROCUaddr;
BYTEtmpB=0;
(FARPROC&)Uaddr=GetProcAddress(GetModuleHandle("kernel32.dll"),"UnhandledExceptionFilter");
tmpB=*((BYTE*)Uaddr);//取UnhandledExceptionFilter函数第一字节
tmpB=tmpB^0x55;
if(tmpB==0x99)//如该字节为CC,则SoftICE己加载
returntrue;
else
returnfalse;

3.4FS_ODP_Process32NextW
当我在调试FD_parentprocess时,感觉总是怪怪的,使用OD时运行Process32NextW总是返回失败,搞了一个晚上,才搞懂原来是OD的插件HideOD在作怪。当HideOD的Process32NextW的选项被选中时,它会更改Process32NextW的返回值,使其始终返回false,这主要是HideOD针对FD_parentprocess这个反调试的一个反反调试。但也正是这一点暴露的它的存在。
intOSVersion;
FARPROCFunc_addr;
WORDtmpW;
//1.Process32Next
HMODULEhModule=GetModuleHandle("kernel32.dll");
(FARPROC&)Func_addr=GetProcAddress(hModule,"Process32NextW");
if(Func_addr!=NULL)
{
tmpW=*(WORD*)Func_addr;
OSVersion=myGetOSVersion();
switch(OSVersion)
{
caseOS_winxp:
if(tmpW!=0xFF8B)//maybeoptionofProcess32Nextisselected.
returntrue;
break;
default:
if(tmpW==0xC033)
returntrue;
break;
}
}
但上面的代码并不完美,因为有跨平台问题,所以要先获得当前操作系统版本。目前只在win2k和winxp下进行了测试。

3.5FS_ODP_OutputDebugStringA
同样,HIDEOD的OutputDebugStringA选项,也对OutputDebugStringA这个api做了处理,具体修改内容我记不得了,大家可以自己比对一下。我的代码如下:
intOSVersion;
FARPROCFunc_addr;
WORDtmpW;
//2.OutputDebugStringA
HMODULEhModule=GetModuleHandle("kernel32.dll");
(FARPROC&)Func_addr=GetProcAddress(hModule,"OutputDebugStringA");
if(Func_addr!=NULL)
{
tmpW=*(WORD*)Func_addr;
OSVersion=myGetOSVersion();
switch(OSVersion)
{
caseOS_winxp:
if(tmpW!=0x3468)//maybeoptionofOutputDebugStringAtisselected.
returntrue;
break;
default:
if(tmpW==0x01e8)
returntrue;
break;
}
}
returnfalse;

3.6FS_ODP_OpenProcess
这个据称这个是针对HideDebugger这个插件的,当这个插件开启时,它会挂钩OpenProcess这个函数,它修改了OpenProcess的前几个字节。因此检测这几个字节就可实现这个反调试。
FARPROCFunc_addr;
BYTEtmpB;
//OpenProcess
HMODULEhModule=GetModuleHandle("kernel32.dll");
(FARPROC&)Func_addr=GetProcAddress(hModule,"OpenProcess");
if(Func_addr!=NULL)
{
tmpB=*((BYTE*)Func_addr+6);
if(tmpB==0xea)//HideDebuggerPluginofODispresent
returntrue;
}
returnfalse;

3.7FS_ODP_CheckRemoteDebuggerPresent
和前面提到的两个HideOD的反调试类似,不多说了。大家可以自行比对一下开启和不开启HideOD时,CheckRemoteDebuggerPresent函数的异同,就可以设计反这个插件的反调试了。
intOSVersion;
FARPROCFunc_addr;
BYTEtmpB;
//2.CheckRemoteDebuggerPresent
HMODULEhModule=GetModuleHandle("kernel32.dll");
(FARPROC&)Func_addr=GetProcAddress(hModule,"CheckRemoteDebuggerPresent");
if(Func_addr!=NULL)
{
tmpB=*((BYTE*)Func_addr+10);
OSVersion=myGetOSVersion();
switch(OSVersion)
{
caseOS_winxp:
if(tmpB!=0x74)//HideODispresent
returntrue;
break;
default:
break;
}
}
returnfalse;

3.8FS_ODP_ZwSetInformationThread
和前面提到的几个HideOD的反调试类似,大家可以自行比对一下开启和不开启HideOD时,ZwSetInformationThread函数的异同,就可以设计反这个插件的反调试了。
intOSVersion;
FARPROCFunc_addr;
WORDtmpW;
BYTEtmpB0,tmpB1;
//2.CheckRemoteDebuggerPresent
HMODULEhModule=GetModuleHandle("ntdll.dll");
(FARPROC&)Func_addr=GetProcAddress(hModule,"ZwSetInformationThread");
if(Func_addr!=NULL)
{
tmpW=*((WORD*)Func_addr+3);
tmpB0=*((BYTE*)Func_addr+9);
tmpB1=*((BYTE*)Func_addr+10);
OSVersion=myGetOSVersion();
switch(OSVersion)
{
caseOS_winxp:
if(tmpW!=0x0300)//HideODispresent
returntrue;
break;
caseOS_win2k:
if((tmpB0!=0xcd)&&(tmpB1!=0x2e))
returntrue;
break;
default:
break;
}
}
returnfalse;

3.9FS_SI_Exception_Int1
通常int1的DPL为0,这表示"cd01"机器码不能在3环下执行。如果直接执行这个中断将会产生一个保护错误,windows会产生一个EXCEPTION_ACCESS_VIOLATION(0xc0000005)异常。然而,如果SOFTICE正在运行,它挂钩了int1,并调整其DPL为3。这样SoftICE就可以在用户模式执行单步操作了。
当int1发生时,SoftICE不检查它是由于陷阱标志位还是由软件中断产生,SoftICE总是去调用原始中断1的句柄,此时将会产生一个EXCEPTION_SINGLE_STEP(0x80000004)而不是EXCEPTION_ACCESS_VIOLATION(0xc0000005)异常,这就形成了一个简单的反调试方法。

__asm
{
pushoffseteh_int1;setexceptionhandler
pushdwordptrfs:[0h]
movdwordptrfs:[0h],esp
xoreax,eax;resetflag(EAX)invokeint3
int1h
popdwordptrfs:[0h];restoreexceptionhandler
addesp,4

cmpeax,0x80000004;checktheflag
jert_label_int1
jmprf_label_int1

eh_int1:
moveax,[esp+0x4];
movebx,dwordptr[eax];
moveax,dwordptr[esp+0xc];EAX=ContextRecord
movdwordptr[eax+0xb0],ebx;setflag(ContextRecord.EAX)

incdwordptr[eax+0xb8];setContextRecord.EIP
incdwordptr[eax+0xb8];setContextRecord.EIP
xoreax,eax
retn
}

3.10FV_VMWare_VMX
这是一个针对VMWare虚拟机仿真环境的反调试,我从网上直接拷贝的代码。
VMWARE提供一种主机和客户机之间的通信方法,这可以被用做一种VMWare的反调试。Vmware将会处理IN(端口为0x5658/’VX’)指令,它会返回一个majic数值“VMXh”到EBX中。
当在保护模式操作系统的3环下运行时,IN指令的执行将会产生一个异常,除非我们修改了I/O的优先级等级。然而,如果在VMWare下运行,将不会产生任何异常,同时EBX寄存器将会包含’VMXh’,ECX寄存器也会被修改为Vmware的产品ID。
这种技巧在一些病毒中比较常用。
针对VME的反调试,在peterFerrie的另一篇文章<<AttacksonMoreVirtualMachineEmulators>>中有大量的描述,有兴趣的可以根据这篇文章,将FV_反调试好好丰富一下。

boolIsInsideVMWare_()
{
boolr;
_asm
{
pushedx
pushecx
pushebx

moveax,'VMXh'
movebx,0//anyvaluebutMAGICVALUE
movecx,10//getVMWareversion
movedx,'VX'//portnumber
ineax,dx//readport
//onreturnEAXreturnstheVERSION
cmpebx,'VMXh'//isitareplyfromVMWare?
setz[r]//setreturnvalue

popebx
popecx
popedx
}
returnr;
}

boolFV_VMWare_VMX()
{
__try
{
returnIsInsideVMWare_();
}
__except(1)//1=EXCEPTION_EXECUTE_HANDLER
{
returnfalse;
}
}

3.11FV_VPC_Exception
这个代码我也是完整从网上拷贝下来的,具体原理在<<AttacksonMoreVirtualMachineEmulators>>这篇文章里也有详细描述。与VMWare使用一个特殊端口完成主机和客户机间通信的方法类似的是,VirtualPC靠执行非法指令产生一个异常供内核捕获。这个代码如下:

代码:
0F3Fx1x2
0FC7C8y1y2
[/code]


由这两个非法指令引起的异常将会被应用程序捕获,然而,如果VirtualPC正在运行,将不会产生异常。X1,x2的允许的数值还不知道,但有一部分已知可以使用,如0A00,1100…等等。
__declspec(naked)boolFV_VPC_Exception()
{
_asm
{
pushebp
movebp,esp

movecx,offsetexception_handler

pushebx
pushecx

pushdwordptrfs:[0]
movdwordptrfs:[0],esp

movebx,0//Flag
moveax,1//VPCfunctionnumber
}

//callVPC
_asm__emit0Fh
_asm__emit3Fh
_asm__emit07h
_asm__emit0Bh

_asm
{
moveax,dwordptrss:[esp]
movdwordptrfs:[0],eax

addesp,8

testebx,ebx

setzal

leaesp,dwordptrss:[ebp-4]
movebx,dwordptrss:[esp]
movebp,dwordptrss:[esp+4]

addesp,8

jmpret1
exception_handler:
movecx,[esp+0Ch]
movdwordptr[ecx+0A4h],-1//EBX=-1->notrunning,ebx=0->running
adddwordptr[ecx+0B8h],4//->skippastthecalltoVPC
xoreax,eax//exceptionishandled
ret
ret1:
ret
}
}

3.12FV_VME_RedPill
这个方法似乎是检测虚拟机的一个简单有效的方法,虽然还不能确定它是否是100%有效。名字很有意思,红色药丸(为什么不是bluepill,哈哈)。我在网上找到了个ppt专门介绍这个方法,可惜现在翻不到了。记忆中原理是这样的,主要检测IDT的数值,如果这个数值超过了某个数值,我们就可以认为应用程序处于虚拟环境中,似乎这个方法在多CPU的机器中并不可靠。据称ScoobyDoo方法是RedPill的升级版。代码也是在网上找的,做了点小改动。有四种返回结果,可以确认是VMWare,还是VirtualPC,还是其它VME,或是没有处于VME中。
//returnvalue:0:none,1:vmvare;2:vpc;3thers
unsignedcharmatrix[6];

unsignedcharredpill[]=
"\x0f\x01\x0d\x00\x00\x00\x00\xc3";

HANDLEhProcess=GetCurrentProcess();

LPVOIDlpAddress=NULL;
PDWORDlpflOldProtect=NULL;

__try
{
*((unsigned*)&redpill[3])=(unsigned)matrix;

lpAddress=VirtualAllocEx(hProcess,NULL,6,MEM_RESERVE|MEM_COMMIT,PAGE_EXECUTE_READWRITE);

if(lpAddress==NULL)
return0;

BOOLsuccess=VirtualProtectEx(hProcess,lpAddress,6,PAGE_EXECUTE_READWRITE,lpflOldProtect);

if(success!=0)
return0;

memcpy(lpAddress,redpill,8);

((void(*)())lpAddress)();

if(matrix[5]>0xd0)
{
if(matrix[5]==0xff)//vmvare
return1;
elseif(matrix[5]==0xe8)//vitualpc
return2;
else
return3;
}
else
return0;
}
__finally
{
VirtualFreeEx(hProcess,lpAddress,0,MEM_RELEASE);
}

四、检测-断点(FB_)
这一部分内容较少,但实际上可用的方法也比较多,我没有深入研究,不敢乱写,照抄了几个常用的方法:
//findbreakpoint
boolFB_HWBP_Exception();
DWORDFB_SWBP_Memory_CRC();
boolFB_SWBP_ScanCC(BYTE*addr,intlen);
boolFB_SWBP_CheckSum_Thread(BYTE*addr_begin,BYTE*addr_end,DWORDsumValue);

4.1FB_HWBP_Exception
在异常处理程序中检测硬件断点,是比较常用的硬件断点检测方法。在很多地方都有提到。
__asm
{
pushoffsetexeception_handler;setexceptionhandler
pushdwordptrfs:[0h]
movdwordptrfs:[0h],esp
xoreax,eax;resetEAXinvokeint3
int1h
popdwordptrfs:[0h];restoreexceptionhandler
addesp,4
;testifEAXwasupdated(breakpointidentified)
testeax,eax
jnzrt_label
jmprf_label

exeception_handler:
;EAX=CONTEXTrecord
moveax,dwordptr[esp+0xc]

;checkifDebugRegistersContext.Dr0-Dr3isnotzero
cmpdwordptr[eax+0x04],0
jnehardware_bp_found
cmpdwordptr[eax+0x08],0
jnehardware_bp_found
cmpdwordptr[eax+0x0c],0
jnehardware_bp_found
cmpdwordptr[eax+0x10],0
jnehardware_bp_found
jmpexception_ret

hardware_bp_found:
;setContext.EAXtosignalbreakpointfound
movdwordptr[eax+0xb0],0xFFFFFFFF
exception_ret:
;setContext.EIPuponreturn
incdwordptr[eax+0xb8];setContextRecord.EIP
incdwordptr[eax+0xb8];setContextRecord.EIP
xoreax,eax
retn
}
4.2FB_SWBP_Memory_CRC()
由于在一些常用调试器中,比如OD,其是将代码设置为0xcc来实现普通断点,因此当一段代码被设置了普通断点,则其中必定有代码的修改。因此对关键代码进行CRC校验则可以实现侦测普通断点。但麻烦的是每次代码修改,或更换编译环境,都要重新设置CRC校验值。
下面的代码拷贝自《软件加解密技术》,里面完成的是对整个代码段的CRC校验,CRC校验值保存在数据段。CRC32算法实现代码网上有很多,就不列出来了。
DWORDFB_SWBP_Memory_CRC()
{
//打开文件以获得文件的大小
DWORDfileSize,NumberOfBytesRW;
DWORDCodeSectionRVA,CodeSectionSize,NumberOfRvaAndSizes,DataDirectorySize,ImageBase;
BYTE*pMZheader;
DWORDpPEheaderRVA;
TCHAR*pBuffer;
TCHARszFileName[MAX_PATH];

GetModuleFileName(NULL,szFileName,MAX_PATH);
//打开文件
HANDLEhFile=CreateFile(
szFileName,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
if(hFile!=INVALID_HANDLE_VALUE)
{
//获得文件长度:
fileSize=GetFileSize(hFile,NULL);
if(fileSize==0xFFFFFFFF)return0;
pBuffer=newTCHAR[fileSize];////申请内存,也可用VirtualAlloc等函数申请内存
ReadFile(hFile,pBuffer,fileSize,&NumberOfBytesRW,NULL);//读取文件内容
CloseHandle(hFile);//关闭文件
}
else
return0;
pMZheader=(BYTE*)pBuffer;//此时pMZheader指向文件头
pPEheaderRVA=*(DWORD*)(pMZheader+0x3c);//读3ch处的PE文件头指针
///定位到PE文件头(即字串“PE\0\0”处)前4个字节处,并读出储存在这里的CRC-32值:

NumberOfRvaAndSizes=*((DWORD*)(pMZheader+pPEheaderRVA+0x74));//得到数据目录结构数量
DataDirectorySize=NumberOfRvaAndSizes*0x8;//得到数据目录结构大小
ImageBase=*((DWORD*)(pMZheader+pPEheaderRVA+0x34));//得到基地址
//假设第一个区块就是代码区块
CodeSectionRVA=*((DWORD*)(pMZheader+pPEheaderRVA+0x78+DataDirectorySize+0xc));//得到代码块的RVA值
CodeSectionSize=*((DWORD*)(pMZheader+pPEheaderRVA+0x78+DataDirectorySize+0x8));///得到代码块的内存大小
deletepBuffer;//释放内存
returnCRC32((BYTE*)(CodeSectionRVA+ImageBase),CodeSectionSize);
}

4.3FB_SWBP_ScanCC
扫描CC的方法,比照前面校验代码CRC数值的方法更直接一些,它直接在所要检测的代码区域内检测是否有代码被更改为0xCC,0xcc对应汇编指令为int3,对一些常用的调试器(如OD)其普通断点就是通过修改代码为int3来实现的。但使用时要注意是否正常代码中就包含CC。通常这个方法用于扫描API函数的前几个字节,比如检测常用的MessageBoxA、GetDlgItemTextA等。

boolFB_SWBP_ScanCC(BYTE*addr,intlen)
{
FARPROCFunc_addr;
HMODULEhModule=GetModuleHandle("USER32.dll");
(FARPROC&)Func_addr=GetProcAddress(hModule,"MessageBoxA");
if(addr==NULL)
addr=(BYTE*)Func_addr;//fortest
BYTEtmpB;
inti;
__try
{
for(i=0;i<len;i++,addr++)
{
tmpB=*addr;
tmpB=tmpB^0x55;
if(tmpB==0x99)//cmp0xcc
returntrue;
}
}
__except(1)
returnfalse;
returnfalse;
}

4.4FB_SWBP_CheckSum_Thread(BYTE*addr_begin,BYTE*addr_end,DWORDsumValue);
此方法类似CRC的方法,只是这里是检测累加和。它与CRC的方法有同样的问题,就是要在编译后,计算累加和的数值,再将该值保存到数据区,重新编译。在这里创建了一个单独的线程用来监视代码段。
DWORDWINAPICheckSum_ThreadFunc(LPVOIDlpParam)
{
DWORDdwThrdParam[3];
BYTEtmpB;
DWORDValue=0;
dwThrdParam[0]=*((DWORD*)lpParam);
dwThrdParam[1]=*((DWORD*)lpParam+1);
dwThrdParam[2]=*((DWORD*)lpParam+2);
BYTE*addr_begin=(BYTE*)dwThrdParam[0];
BYTE*addr_end=(BYTE*)dwThrdParam[1];
DWORDsumValue=dwThrdParam[2];
for(inti=0;i<(addr_end-addr_begin);i++)
Value=Value+*(addr_begin+i);
/*//ifsumvalueisconst,itshouldbesubstract.
DWORDtmpValue;
Value=Value-(sumValue&0x000000FF);
tmpValue=(sumValue&0x0000FF00)>>8;
Value=Value-tmpValue;
tmpValue=(sumValue&0x0000FF00)>>16;
Value=Value-tmpValue;
tmpValue=(sumValue&0x0000FF00)>>24;
Value=Value-tmpValue;*/
if(Value!=sumValue)
MessageBox(NULL,"SWBPisfoundbyCheckSum_ThreadFunc","CheckSum_ThreadFunc",MB_OK|MB_ICONSTOP);
return1;
}

boolFB_SWBP_CheckSum_Thread(BYTE*addr_begin,BYTE*addr_end,DWORDsumValue)
{
DWORDdwThreadId;
DWORDdwThrdParam[3];
dwThrdParam[0]=(DWORD)addr_begin;
dwThrdParam[1]=(DWORD)addr_end;
dwThrdParam[2]=sumValue;
HANDLEhThread;

hThread=CreateThread(
NULL,//defaultsecurityattributes
0,//usedefaultstacksize
CheckSum_ThreadFunc,//threadfunction
&dwThrdParam[0],//argumenttothreadfunction
0,//usedefaultcreationflags
&dwThreadId);//returnsthethreadidentifier
//Checkthereturnvalueforsuccess.

if(hThread==NULL)
returnfalse;
else
{
Sleep(1000);
CloseHandle(hThread);
returntrue;
}
}
五、检测-跟踪(FT_)
个人认为,反跟踪的一些技巧,多数不会非常有效,因为在调试时,多数不会被跟踪经过,除非用高超的技巧将关键代码和垃圾代码及这些反跟踪技巧融合在一起,否则很容易被发现或被无意中跳过。
函数列表如下:
//FindSingle-SteporTrace
boolFT_PushSS_PopSS();
voidFT_RDTSC(unsignedint*time);
DWORDFT_GetTickCount();
DWORDFT_SharedUserData_TickCount();
DWORDFT_timeGetTime();
LONGLONGFT_QueryPerformanceCounter(LARGE_INTEGER*lpPerformanceCount);
boolFT_F1_IceBreakpoint();
boolFT_Prefetch_queue_nop1();
boolFT_Prefetch_queue_nop2();

5.1FT_PushSS_PopSS
这个反调试在<<windowsanti-debugreference>>里有描述,如果调试器跟踪经过下面的指令序列:
__asm
{
pushss//反跟踪指令序列
;junk
popss//反跟踪指令序列
pushf//反跟踪指令序列
;junk
popeax//反跟踪指令序列
}
Pushf将会被执行,同时调试器无法设置压进堆栈的陷阱标志,应用程序通过检测陷阱标志就可以判断处是否被跟踪调试。

__asm
{
pushebp
movebp,esp
pushss//反跟踪指令序列
;junk
popss//反跟踪指令序列
pushf//反跟踪指令序列
;junk
popeax//反跟踪指令序列
andeax,0x00000100
jnzrt_label

xoreax,eax
movesp,ebp
popebp
retn
rt_label:
xoreax,eax
inceax
movesp,ebp
popebp
retn
}

5.2FT_RDTSC
通过检测某段程序执行的时间间隔,可以判断出程序是否被跟踪调试,被跟踪调试的代码通常都有较大的时间延迟,检测时间间隔的方法有很多种。比如RDTSC指令,kernel32_GetTickCount函数,winmm_timeGetTime函数等等。
下面为RDTSC的实现代码。

inttime_low,time_high;
__asm
{
rdtsc
movtime_low,eax
movtime_high,edx
}

5.3FT_GetTickCount
GetTickCount函数检测时间间隔简单且常用。直接调用即可。具体可查MSDN。

5.4FT_SharedUserData_TickCount
直接调用GetTickCount函数来检测时间间隔的方法,虽然简单却容易被发现。而使用GetTickCount的内部实现代码,直接读取SharedUserData数据结构里的数据的方法,更隐蔽些。下面的代码是直接从GetTickCount里扣出来的,其应该是在位于0x7FFE0000地址处的SharedUserData数据接口里面直接取数据,不过这个代码应该有跨平台的问题,我这里没有处理。大家可以完善下。
DWORDtmpD;
__asm
{
movedx,0x7FFE0000
moveax,dwordptr[edx]
muldwordptr[edx+4]
shrdeax,edx,0x18
movtmpD,eax
}
returntmpD;

5.5FT_timeGetTime
使用winmm里的timeGetTime的方法也可以用来检测时间间隔。直接调用这个函数即可。具体可查MSDN。

5.6FT_QueryPerformanceCounter
这是一种高精度时间计数器的方法,它的检测刻度最小,更精确。
if(QueryPerformanceCounter(lpPerformanceCount))
returnlpPerformanceCount->QuadPart;
else
return0;

5.7FT_F1_IceBreakpoint
在<<Windowsanti-debugreference>>中有讲述这个反跟踪技巧。这个所谓的"Icebreakpoint"是Intel未公开的指令之一,机器码为0xF1.执行这个指令将产生单步异常.,如果程序已经被跟踪,调试器将会以为它是通过设置标志寄存器中的单步标志位生成的正常异常.相关的异常处理器将不会被执行到.下面是我的实现代码:

__asm
{
pushoffseteh_f1;setexceptionhandler
pushdwordptrfs:[0h]
movdwordptrfs:[0h],esp
xoreax,eax;resetEAXinvokeint3
_emit0xf1
popdwordptrfs:[0h];restoreexceptionhandler
addesp,4
testeax,eax
jzrt_label_f1
jmprf_label_f1

eh_f1:
moveax,dwordptr[esp+0xc]
movdwordptr[eax+0xb0],0x00000001;setflag(ContextRecord.EAX)
incdwordptr[eax+0xb8]
xoreax,eax
retn
rt_label_f1:
inceax
movesp,ebp
popebp
retn
rf_label_f1:
xoreax,eax
movesp,ebp
popebp
retn
}


5.8FT_Prefetch_queue_nop1
这个反调试是在<<ANTI-UNPACKERTRICKS>>中给出的,它主要是基于REP指令,通过REP指令来修改自身代码,在非调试态下,计算机会将该指令完整取过来,因此可以正确的执行REP这个指令,将自身代码完整修改,但在调试态下,则在修改自身的时候立即跳出。
这个反跟踪技巧个人觉得用处不大,因为只有在REP指令上使用F7单步时,才会触发这个反跟踪,而我个人在碰到REP时,通常都是F8步过。下面是利用这个CPU预取指令的特性的实现反跟踪的一种方法,正常情况下,REP指令会修改其后的跳转指令,进入正常的程序流程,但在调试态下,其无法完成对其后代码的修改,从而实现反调试。

DWORDoldProtect;
DWORDtmpProtect;
__asm
{
leaeax,dwordptr[oldProtect]
pusheax
push0x40
push0x10
pushoffsetlabel3;
calldwordptr[VirtualProtect];
nop
label3:
moval,0x90
push0x10
popecx
movedi,offsetlabel3
repstosb
jmprt_label
nop
nop
nop
nop
nop
rf_label:
;writeback
movdwordptr[label3],0x106a90b0
movdwordptr[label3+0x4],0x205CBF59
movdwordptr[label3+0x8],0xAAF30040
movdwordptr[label3+0xc],0x90909090
movdwordptr[label3+0x6],offsetlabel3
leaeax,dwordptr[tmpProtect];
;restoreprotect
pusheax
pusholdProtect
push0x10
pushoffsetlabel3;
calldwordptr[VirtualProtect];

xoreax,eax
movesp,ebp
popebp
retn
rt_label:
;writeback
movdwordptr[label3],0x106a90b0
movdwordptr[label3+0x4],0x205CBF59
movdwordptr[label3+0x8],0xAAF30040
movdwordptr[label3+0xc],0x90909090
movdwordptr[label3+0x6],offsetlabel3
leaeax,dwordptr[tmpProtect];
;restoreprotect
pusheax
pusholdProtect
push0x10
pushoffsetlabel3;
calldwordptr[VirtualProtect];

xoreax,eax
inceax
movesp,ebp
popebp
retn
}


5.9FT_Prefetch_queue_nop2
与5.8节类似,这是根据CPU预取指令的这个特性实现的另一种反跟踪技巧。原理是通过检测REP指令后的ECX值,来判断REP指令是否被完整执行。在正常情况下,REP指令完整执行后,ECX值应为0;但在调试态下,由于REP指令没有完整执行,ECX值为非0值。通过检测ECX值,实现反跟踪。
DWORDoldProtect;
DWORDtmpProtect;
__asm
{
leaeax,dwordptr[oldProtect]
pusheax
push0x40
push0x10
pushoffsetlabel3;
calldwordptr[VirtualProtect];
movecx,0
label3:
moval,0x90
push0x10
popecx
movedi,offsetlabel3
repstosb
nop
nop
nop
nop
nop
nop
pushecx
;writeback
movdwordptr[label3],0x106a90b0
movdwordptr[label3+0x4],0x201CBF59
movdwordptr[label3+0x8],0xAAF30040
movdwordptr[label3+0xc],0x90909090
movdwordptr[label3+0x6],offsetlabel3
leaeax,dwordptr[tmpProtect];
;restoreprotect
pusheax
pusholdProtect
push0x10
pushoffsetlabel3;
calldwordptr[VirtualProtect];
popecx

testecx,ecx
jnert_label
}
rf_label:
returnfalse;
rt_label:
returntrue;

六、检测-补丁(FP_)
这部分内容也较少,方法当然也有很多种,原理都差不多,我只选了下面三种。这几种方法通常在一些壳中较常用,用于检验文件是否被脱壳或被恶意修改。
函数列表如下:
//findPatch
boolFP_Check_FileSize(DWORDSize);
boolFP_Check_FileHashValue_CRC(DWORDCRCVALUE_origin);
boolFP_Check_FileHashValue_MD5(DWORDMD5VALUE_origin);

6.1FP_Check_FileSize(DWORDSize)
通过检验文件自身的大小的方法,是一种比较简单的文件校验方法,通常如果被脱壳,或被恶意修改,就可能影响到文件的大小。我用下面的代码实现。需注意的是,文件的大小要先编译一次,将首次编译得到的数值写入代码,再重新编译完成。
DWORDCurrent_Size;
TCHARszPath[MAX_PATH];
HANDLEhFile;

if(!GetModuleFileName(NULL,szPath,MAX_PATH))
returnFALSE;

hFile=CreateFile(szPath,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL);
if(hFile==INVALID_HANDLE_VALUE)
returnfalse;
Current_Size=GetFileSize(hFile,NULL);
CloseHandle(hFile);
if(Current_Size!=Size)
returntrue;
returnfalse;

6.2FP_Check_FileHashValue_CRC
检验文件的CRC数值,是比较常用的文件校验方法,相信很多人都碰到过了,我是在《软件加解密技术》中了解到的。需注意的是文件原始CRC值的获得,及其放置位置,代码编写完成后,通常先运行一遍程序,使用调试工具获得计算得到的数值,在将这个数值写入文件中,通常这个数值不参加校验,可以放置在文件的尾部作为附加数据,也可以放在PE头中不用的域中。
下面的代码只是个演示,没有保存CRC的真实数值,也没有单独存放。

DWORDfileSize,NumberOfBytesRW;
DWORDCRCVALUE_current;
TCHARszFileName[MAX_PATH];
TCHAR*pBuffer;
GetModuleFileName(NULL,szFileName,MAX_PATH);
HANDLEhFile=CreateFile(
szFileName,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
if(hFile!=INVALID_HANDLE_VALUE)
{
fileSize=GetFileSize(hFile,NULL);
if(fileSize==0xFFFFFFFF)returnfalse;
pBuffer=newTCHAR[fileSize];
ReadFile(hFile,pBuffer,fileSize,&NumberOfBytesRW,NULL);
CloseHandle(hFile);
}
CRCVALUE_current=CRC32((BYTE*)pBuffer,fileSize);
if(CRCVALUE_origin!=CRCVALUE_current)
returntrue;
returnfalse;

6.3FP_Check_FileHashValue_MD5
与6.2节的原理相同,只是计算的是文件的MD5数值。仍要注意6.2节中同样的MD5真实数值的获得和存放问题。
点击按钮快速添加回复内容: 支持 高兴 激动 给力 加油 苦寻 生气 回帖 路过 感恩
您需要登录后才可以回帖 登录 | 注册账号

本版积分规则

小黑屋|手机版|Archiver|看流星社区 |网站地图

GMT+8, 2024-3-19 14:32

Powered by Kanliuxing X3.4

© 2010-2019 kanliuxing.com

快速回复 返回顶部 返回列表