怎么重新编译安装php5.6CE5.6
点击联系发帖人
时间：2016-11-30 02:26
linux下CentOS6.2编译安装MySQL5.5.25 教程 -linux-操作系统-壹聚教程网linux下CentOS6.2编译安装MySQL5.5.25 教程
本文章介绍了关于CentOS6.2编译安装MySQL5.5.25有需要的同学可参考一下。
按照之前ubuntu安装的步骤安装后，启动mysql启动不起来。错误代码为& The server quit without updating PID file(/var/lib/mysql/CentOS.pid)&，百度和google都搜索了一些资料，基本一致，对我没帮助，按照他们说的修改了也不行。于是乎结合张晏的博客，最终成功搞定。
第一步：我们首先安装依赖库和开发工具
#依赖库和开发工具
yum -y install gcc gcc-c++ autoconf libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-devel curl curl-devel e2fsprogs e2fsprogs-devel krb5 krb5-devel libidn libidn-devel openssl openssl-devel openldap openldap-devel nss_ldap openldap-clients openldap-servers
yum -y install pcre-devel& zlib-devel
yum -y install gd-devel libjpeg-devel libpng-devel freetype-devel libxml2-devel curl-devel freetype-devel
yum -y install bison gcc gcc-c++ autoconf automake zlib* libxml* ncurses-devel libtool-ltdl-devel* mysql-devel
第二步：由于mysql5.5开始，不再使用configure安装，而是使用cmake。所以需要先安装cmake
tar -zxvf cmake-2.8.6.tar.gz
cd cmake-2.8.6/
./configure
make && make install
第三步：cmake安装mysql（我已经下载好了mysql源码文件，放在U盘里，拷贝到/tmp目录下）
//进入/tmp目录下
tar -zxvf mysql-5.5.25.tar.gz
cd mysql-5.5.25
-DCMAKE_INSTALL_PREFIX=/usr/local/webserver/mysql
-DMYSQL_DATADIR=/user/local/webserver/mysql/data
-DSYSCONFDIR=/etc
-DEXTRA_CHARSETS=all
-DDEFAULT_CHARSET=utf8
-DDEFAULT_COLLATION=utf8_general_ci
-DWITH_INNOBASE_STORAGE_ENGINE=1
-DWITH_ARCHIVE_STORAGE_ENGINE=1
-DWITH_BLACKHOLE_STORAGE_ENGINE=1
-DWITH_FEDERATED_STORAGE_ENGINE=1
-DWITH_PARTITION_STORAGE_ENGINE=1
-DWITH_PERFSCHEMA_STORAGE_ENGINE=1
-DMYSQL_UNIX_ADDR=/tmp/mysqld.sock
-DMYSQL_TCP_PORT=3306
-DWITH_DEBUG=0
-DENABLED_LOCAL_INFILE=1
回车执行，执行完成后继续执行 make && make install
第四步：设置mysql
#设置Mysql
#在support-files目录中有五个配置信息文件(这里很重要，一定要根据自己的内存复制对应的cnf文件，否则mysql始终起不来)：
#f (内存&=64M)
#f (内存 128M)
#f (内存 512M)
#f (内存 1G-2G)
#my-innodb-f (内存 4GB)
cd /usr/local/webserver/mysql
cp ./support-files/f /f
#在 [mysqld] 段增加
datadir = /data/mysql
wait-timeout = 30
max_connections = 512
default-storage-engine = MyISAM
#在 [mysqld] 段修改
max_allowed_packet = 16M
第五步：添加mysql用户和用户组，生成新的mysql授权表
//添加mysql运行的用户和用户组
groupadd mysql
useradd -g mysql mysql -s /bin/false -d /home/mysql& //没有shell，不可本机登陆（安全起见）
cd /usr/local/webserver/mysql
chown -R root .
chown -R mysql data
chgrp -R mysql .
//生成新的mysql授权表
//进入目录下的脚本目录
cd /usr/local/webserver/mysql/scripts
//利用mysql_install_db脚本生成新的mysql授权表
./mysql_install_db --basedir=/usr/local/webserver/mysql --datadir=/usr/local/webserver/mysql/data --user=mysql
//mysql server在系统中的服务项设置
//复制服务文件并修改
cd /usr/local/webserver/mysql/support-files
cp mysql.server mysqld
//修改mysqld
basedir=/usr/local/webserver/mysql
datadir=/usr/local/webserver/mysql/data
mv mysqld /etc/init.d/mysqld
chmod 755 /etc/init.d/mysqld
//设置软连接使mysql,& ,& mysqladmin这三个bin命令能在shell中直接运行
sudo ln -s /usr/local/webserver/mysql/bin/mysql /usr/bin
sudo ln -s /usr/local/webserver/mysql/bin/mysqldump /usr/bin
sudo ln -s /usr/local/webserver/mysql/bin/mysqladmin /usr/bin
rm -rf /etc/f 因为已经把此文件复制到/f& 如果不删除的话，mysql启动不起来。
第六步：启动mysql，设置mysql用户名和密码
/etc/init.d/mysqld start
//设置root密码
mysqladmin -u root pass &admin&
//mysql中文乱码解决
//然后在[mysqld]配置选项下添加
character-set-server=utf8
//然后进入mysql
cd /usr/local/webserver/mysql/bin
mysql -u root -p
提示输入密码
mysql& show variables like '%character%';
//结果：character_set_database，character_set_server两项都变为utf8了
上一页： &&&&&下一页：相关内容查看: 957|回复: 3
反调试技巧总结-原理和实现
阅读权限40
在线时间7 小时
积分主题听众
技法精湛来自于日积月累
论坛严禁灌水，一律永久封禁！</
反调试技巧总结-原理和实现
我将反调试技巧按行为分为两大类，一类为检测，另一类为攻击，每类中按操作对象又分了五个小类：
1、 通用调试器& &&&包括所有调试器的通用检测方法
2、 特定调试器& &&&包括OD、IDA等调试器，也包括相关插件，也包括虚拟环境
3、 断点& && && &&&包括内存断点、普通断点、硬件断点检测
4、 单步和跟踪& &&&主要针对单步跟踪调试
5、 补丁& && && &&&包括文件补丁和内存补丁
反调试函数前缀
& && && && &&&检测& && &&&攻击
通用调试器& &&&FD_& && &&&AD_
特定调试器& &&&FS_& && &&&AS_
断点& && && &&&FB_& && &&&AB_
单步和跟踪& &&&FT_& && &&&AT_
补丁& && && &&&FP_& && &&&AP_
1、本文多数都是摘录和翻译，我只是重新组合并翻译，不会有人告侵权吧。里面多是按自己的理解来说明，可能有理解错误，或有更好的实现方法，希望大家帮忙指出错误。
2、我并没有总结完全，上面的部分分类目前还只有很少的函数甚至空白，等待大家和我一起来完善和补充。我坚信如果有扎实的基础知识，丰富的想像力，灵活的运用，就会创造出更多的属于自己的反调试。而最强的反调试，通常都是自己创造的，而不是来自别人的代码。
二、 查找-通用调试器(FD_)
函数列表如下，后面会依次说明，需事先说明的是，这些反调试手段多数已家喻户晓，目前有效的不多，多数已可以通过OD的插件顺利通过，如果你想验证它们的有效性，请关闭OD的所有反反调试插件：
bool FD_IsDebuggerPresent();
bool FD_PEB_BeingDebuggedFlag();
bool FD_PEB_NtGlobalFlags();
bool FD_Heap_HeapFlags();
bool FD_Heap_ForceFlags();
bool FD_Heap_Tail();
bool FD_CheckRemoteDebuggerPresent();
bool FD_NtQueryInfoProc_DbgPort();
bool FD_NtQueryInfoProc_DbgObjHandle();
bool FD_NtQueryInfoProc_DbgFlags();
bool FD_NtQueryInfoProc_SysKrlDbgInfo();
bool FD_SeDebugPrivilege();
bool FD_Parent_Process();
bool FD_DebugObject_NtQueryObject();
bool FD_Find_Debugger_Window();
bool FD_Find_Debugger_Process();
bool FD_Find_Device_Driver();
bool FD_Exception_Closehandle();
bool FD_Exception_Int3();
bool FD_Exception_Popf();
bool FD_OutputDebugString();
bool FD_TEB_check_in_Vista();
bool FD_check_StartupInfo();
bool FD_Parent_Process1();
bool FD_Exception_Instruction_count();
bool FD_INT_2d();
2.1 FD_IsDebuggerPresent()
对调试器来说，IsDebuggerPresent是臭名昭著的恶意函数。不多说了，它是个检测调试的api函数。实现更简单，只要调用IsDebuggerPresent就可以了。在调用它之前，可以加如下代码，以用来检测是否在函数头有普通断点，或是否被钩挂。
&&//check softbreak
&&if(*(BYTE*)Func_addr==0xcc)
&&//check hook
&&if(*(BYTE*)Func_addr!=0x64)
2.2 FD_PEB_BeingDebuggedFlag
我们知道，如果程序处于调试器中，那么在PEB结构中有个beingDegug标志会被设置，直接读取它就可判断是否在调试器中。实际上IsDebuggerPresent就是这么干的。
& & mov eax, fs:[30h] ;EAX =&&TEB.ProcessEnvironmentBlock
& & inc eax
& & inc eax
& & mov eax, [eax]
& & and eax,0x000000ff&&;AL&&=&&PEB.BeingDebugged
& & test eax, eax
& & jne rt_label
& & jmp rf_label
2.3 FD_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中使用过。
& & mov eax, fs:[30h]
& & mov eax, [eax+68h]
& & and eax, 0x70
& & test eax, eax
& & jne rt_label
& & jmp rf_label
2.4 FD_Heap_HeapFlags()
同样，调试器也会在堆中留下痕迹，你可以使用kernel32_GetProcessHeap()函数，如果你不希望使用api函数（以免暴露），则可以直接在PEB中寻找。同样的，使用HeapFlags和后面提到的ForceFlags来检测调试器也不是非常可靠，但却很常用。
这个域由一组标志组成，正常情况下，该值应为2。
& & mov eax, fs:[30h]
& & mov eax, [eax+18h] EB.ProcessHeap
& & mov eax, [eax+0ch] EB.ProcessHeap.Flags
& & cmp eax, 2
& & jne rt_label
& & jmp rf_label
2.5 FD_Heap_ForceFlags
进程堆里另外一个标志，ForceFlags，它也由一组标志组成，正常情况下，该值应为0。
& & mov eax, fs:[30h]
& & mov eax, [eax+18h] EB.ProcessHeap
& & mov eax, [eax+10h] ;PEB.ProcessHeap.ForceFlags
& & test eax, eax
& & jne rt_label
& & jmp rf_label
2.6 FD_Heap_Tail
如果处于调试中，堆尾部也会留下痕迹。标志HEAP_TAIL_CHECKING_ENABLED 将会在分配的堆块尾部生成两个0xABABABAB。如果需要额外的字节来填充堆尾，HEAP_FREE_CHECKING_ENABLED标志则会生成0xFEEEFEEE。
据说Themida使用过这个反调试
& & mov eax, buff
& & ;get unused_bytes
& & movzx ecx, byte ptr [eax-2]
& & movzx edx, word ptr [eax-8] ;size
& & sub eax, ecx
& & lea edi, [edx*8+eax]
& & mov al, 0abh
& & mov cl, 8
& & repe sca**
& & je rt_label
& & jmp rf_label
2.7 FD_CheckRemoteDebuggerPresent
CheckRemoteDebuggerPresent是另一个检测调试的api，只是可惜它似乎只能在winxp sp1版本以后使用。它主要是用来查询一个在winnt时就有的一个数值，其内部会调用NtQueryInformationProcess()，我是这样实现的：
&&FARPROC Func_
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);
&&if (hModule==INVALID_HANDLE_VALUE)
&&(FARPROC&) Func_addr =GetProcAddress(hModule, &CheckRemoteDebuggerPresent&);
&&if (Func_addr != NULL)&&
& & __asm&&
& && &push&&
& && &push&&
& && &push&&0
& && &call&&Func_
& && &test&&eax,
& && &je& & rf_
& && &pop& &
& && &test&&eax,eax
& && &je& & rf_
& && &jmp& & rt_
2.8 FD_NtQueryInfoProc_DbgPort
使用ntdll_NtQueryInformationProcess()来查询ProcessDebugPort可以用来检测反调试。如果进程被调试，其返回值应为0xffffffff。
下面的代码应该是从pediy里copy过来的，时间太长，不记得是哪位兄弟的代码了。
&&HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
&&ZW_QUERY_INFORMATION_PROCESS ZwQueryInformationP&&
& & ZwQueryInformationProcess = (ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule, &ZwQueryInformationProcess&);&&
& & if (ZwQueryInformationProcess == NULL)&&
&&PROCESS_DEBUG_PORT_INFO ProcessI&&
&&if (STATUS_SUCCESS != ZwQueryInformationProcess(GetCurrentProcess( ), ProcessDebugPort, &ProcessInfo, sizeof(ProcessInfo), NULL))&&
& & if(ProcessInfo.DebugPort)
2.9 FD_NtQueryInfoProc_DbgObjHandle
&&在winxp中引入了&debug object&.当一个调试活动开始，一个&debug object&被创建，同也相应产生了一个句柄。使用为公开的ProcessDebugObjectHandle类，可以查询这个句柄的数值。
&&代码可能还是从pediy里复制的，不记得了。
&&HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
&&ZW_QUERY_INFORMATION_PROCESS ZwQueryInformationP&&
& & ZwQueryInformationProcess = (ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule, &ZwQueryInformationProcess&);&&
& & if (ZwQueryInformationProcess == NULL)&&
&&_PROCESS_DEBUG_OBJECTHANDLE_INFO ProcessI&&
&&if (STATUS_SUCCESS != ZwQueryInformationProcess(GetCurrentProcess( ), (PROCESS_INFO_CLASS)0x0000001e, &ProcessInfo, sizeof(ProcessInfo), NULL))&&
& & if(ProcessInfo.ObjectHandle)
2.10 FD_NtQueryInfoProc_DbgFlags();
同样的未公开的ProcessDebugFlags类，当调试器存在时，它会返回false。
&&HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
&&ZW_QUERY_INFORMATION_PROCESS ZwQueryInformationP&&
& & ZwQueryInformationProcess = (ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule, &ZwQueryInformationProcess&);&&
& & if (ZwQueryInformationProcess == NULL)&&
&&_PROCESS_DEBUG_FLAGS_INFO ProcessI&&
&&if (STATUS_SUCCESS != ZwQueryInformationProcess(GetCurrentProcess( ), (PROCESS_INFO_CLASS)0x0000001f, &ProcessInfo, sizeof(ProcessInfo), NULL))&&
& & if(ProcessInfo.Debugflags)
2.11 FD_NtQueryInfoProc_SysKrlDbgInfo()
这个方法估计对大家用处不大，SystemKernelDebuggerInformation类同样可以用来识别调试器，只是可惜在windows下无效，据称可以用在reactOS中。
& &HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
& & ZW_QUERY_SYSTEM_INFORMATION ZwQuerySystemI&&
& & ZwQuerySystemInformation = (ZW_QUERY_SYSTEM_INFORMATION)GetProcAddress(hModule, &ZwQuerySystemInformation&);&&
& & if (ZwQuerySystemInformation == NULL)&&
& & SYSTEM_KERNEL_DEBUGGER_INFORMATION I&&
& & if (STATUS_SUCCESS == ZwQuerySystemInformation(SystemKernelDebuggerInformation, &Info, sizeof(Info), NULL))&&
& && &&&if (Info.DebuggerEnabled)&&
& && &&&{&&
& && && && &if (Info.DebuggerNotPresent)&&
& && && && && &
& && && && &else&&
& && && && && &
& && &&&}&&
& && &&&else&&
& && && && &
& & else&&
2.12 FD_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 );
2.13 FD_Parent_Process()
通常我们都直接在windows界面下运行应用程序，这样的结果就是它的父进程为&explorer.exe&，这个反调试就是检测应用程序的父进程是否为&explorer.exe&，如不是则判定为处于调试器中，这也不是百分百可靠，因为有的时候你的程序是在命令行提示符下运行的。
Yoda使用了这个反调试，它使用Process32Next检测父进程，目前很多插件已经通过使Process32Next始终返回false来越过这个反调试(比如HideOD)。不过可以对代码做些简单的修正来处理这个反反调试。
2.14 FD_DebugObject_NtQueryObject();
&&如前面所描述的，当一个调试活动开始，一个&debug object&被创建，同也相应产生了一个句柄。我们可以查询这个调试对象列表，并检查调试对象的数量，以实现调试器的检测。
&&HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
&&PNtQueryObject NtQueryO
&&NtQueryObject = (PNtQueryObject)GetProcAddress(hModule,&NtQueryObject&);
&&if(NtQueryObject==NULL)
&&unsigned char szdbgobj[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&;
&&unsigned char *psz=&szdbgobj[0];
& & xor& & ebx,
& & push&&
& & push&&
& & push&&
& & push&&
& & push&&3;
& & push&&
& & Call&&dword ptr [NtQueryObject];
& & push&&4;
& & push&&1000h;
& & push&&
& & push&&
& && &call&&dword ptr [VirtualAlloc];
& & push&&
& & push&&
& & push&&
& & push&&3;
& & push&&
& & xchg&&esi,
& & Call&&dword ptr [NtQueryObject];
& & xchg&&ecx,
& & movzx&&edx,
& & xchg&&esi,
& & cmp& & edx,16h;
& & jne& & label2;
& & xchg&&ecx,
& & mov& & edi,
& & repe&&cmp**;
& & xchg&&ecx,
& & jne& & label2;
& & cmp& & dword ptr [eax],edx
& & jne& & rt_
lable2:&&add& & esi,edx
& & and& & esi,-4;
& & loop&&label1;
2.15 FD_Find_Debugger_Window();
通过列举运行的应用程序的窗口，并于常用调试相关工具比对的方法，应该很常用了，就不多说了。这个也是个可以自行增加项目的函数，你可以将一些常用的调试工具归入其中，比如OD,IDA,WindBG,SoftICE等，你也可以添加任何你需要的，比如&Import REConstructor v1.6 FINAL (C)
MackT/uCF&，&Registry Monitor - Sysinternals: &等等。
&&//ollyice
& & hWnd=CWnd::FindWindow(_T(&1212121&),NULL);
& & if (hWnd!=NULL)
&&//ollydbg v1.1
& & hWnd=CWnd::FindWindow(_T(&icu_dbg&),NULL);
& & if (hWnd!=NULL)
&&//ollyice pe--diy
& & hWnd=CWnd::FindWindow(_T(&pe--diy&),NULL);
& & if (hWnd!=NULL)
&&//ollydbg ?-°?
& & hWnd=CWnd::FindWindow(_T(&ollydbg&),NULL);
& & if (hWnd!=NULL)
&&//ollydbg ?-°?
& & hWnd=CWnd::FindWindow(_T(&odbydyk&),NULL);
& & if (hWnd!=NULL)
&&//windbg
& & hWnd=CWnd::FindWindow(_T(&WinDbgFrameClass&),NULL);
& & if (hWnd!=NULL)
&&//dede3.50
& & hWnd=CWnd::FindWindow(_T(&TDeDeMainForm&),NULL);
& & if (hWnd!=NULL)
&&//IDA5.20
& & hWnd=CWnd::FindWindow(_T(&TIdaWindow&),NULL);
& & if (hWnd!=NULL)
&&//others
& & hWnd=CWnd::FindWindow(_T(&TESTDBG&),NULL);
& & if (hWnd!=NULL)
& & hWnd=CWnd::FindWindow(_T(&kk1&),NULL);
& & if (hWnd!=NULL)
& & hWnd=CWnd::FindWindow(_T(&Eew75&),NULL);
& & if (hWnd!=NULL)
& & hWnd=CWnd::FindWindow(_T(&Shadow&),NULL);
& & if (hWnd!=NULL)
&&//PEiD v0.94
& & hWnd=CWnd::FindWindow(NULL,&PEiD v0.94&);
& & if (hWnd!=NULL)
&&//RegMON
& & hWnd=CWnd::FindWindow(NULL,&Registry Monitor - Sysinternals: &);
& & if (hWnd!=NULL)
&&//File Monitor
& & hWnd=CWnd::FindWindow(NULL,&File Monitor - Sysinternals: &);
& & if (hWnd!=NULL)
&&//Import Rec v1.6
& & hWnd=CWnd::FindWindow(NULL,&Import REConstructor v1.6 FINAL (C)
MackT/uCF&);
& & if (hWnd!=NULL)
2.16 FD_Find_Debugger_Process();
&&与上面的方法类似，区别是这个反调试用通过查询进程名字与已知的常用调试器应用程序名字进行比对，以确定是否有调试器处于运行状态。
& & if(strcmp(pe32.szExeFile,&OLLYICE.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&IDAG.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&OLLYDBG.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&PEID.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&SOFTICE.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&LORDPE.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&IMPORTREC.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&W32DSM89.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&WINDBG.EXE&)==0)
2.17 FD_Find_Device_Driver()
&&调试工具通常会使用内核驱动，因此如果尝试是否可以打开一些调试器所用到的设备，就可判断是否存在调试器。常用的设备名称如下：
\\.\SICE&&（SoftICE）
\\.\SIWVID（SoftICE）& &&&
\\.\NTICE&&（SoftICE）& &&&
\\.\REGVXG（RegMON）
\\.\REGVXD（RegMON）
\\.\REGSYS（RegMON）
\\.\REGSYS（RegMON）
\\.\FILEVXG（FileMON）
\\.\FILEM（FileMON）
\\.\TRW（TRW2000）
2.18 FD_Exception_Closehandle()
&&如果给CloseHandle()函数一个无效句柄作为输入参数，在无调试器时，将会返回一个错误代码，而有调试器存在时，将会触发一个EXCEPTION_INVALID_HANDLE (0xc0000008)的异常。
& & CloseHandle(HANDLE(0x));
&&__except(1)
2.19 FD_Exception_Int3()
&&通过Int3产生异常中断的反调试比较经典。当INT3 被执行到时, 如果程序未被调试, 将会异常处理器程序继续执行。而INT3指令常被调试器用于设置软件断点，int 3会导致调试器误认为这是一个自己的断点，从而不会进入异常处理程序。
& & push& &offset exception_ set exception handler
& & push&&dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& &eax,reset EAX invoke int3
& & int& & 3h
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& &esp,4
& & test& &eax, check the flag&&
& & je& & rt_label
& & jmp& & rf_label
exception_handler:
& & mov& &eax,dword ptr [esp+0xc];EAX = ContextRecord
& & mov& & dword ptr [eax+0xb0],0set flag (ContextRecord.EAX)
& & inc& &dword ptr [eax+0xb8];set ContextRecord.EIP
& & xor& &eax,eax
& & xor eax,eax
& & inc eax
& & mov esp,ebp
& & pop ebp
& & xor eax,eax
& & mov esp,ebp
& & pop ebp
2.20 FD_Exception_Popf()
我们都知道标志寄存器中的陷阱标志，当该标志被设置时，将产生一个单步异常。在程序中动态设置这给标志，如果处于调试器中，该异常将会被调试器捕获。
可通过下面的代码设置标志寄存器。
& & pushf&&
& & mov dword ptr [esp], 0x100
2.21 FD_OutputDebugString()
&&在有调试器存在和没有调试器存在时，OutputDebugString函数表现会有所不同。最明显的不同是， 如果有调试器存在，其后的GetLastError()的返回值为零。
&&OutputDebugString(&&);
&&tmpD=GetLastError();
&&if(tmpD==0)
2.22 FD_TEB_check_in_Vista();
&&这是从windows anti-debug reference里拷贝出来的，据说是适用于vista系统下检测调试器。我没有vista所以也没有测试。有条件的可以试下，有问题帮忙反馈给我。多谢。
& & //vista
& && &push& &offset exception_ set exception handler
& && &push&&dword ptr fs:[0h]
& && &mov& & dword ptr fs:[0h],esp& &
& && &xor& &eax,reset EAX invoke int3
& && &int& & 3h
& && &pop& & dword ptr fs:[0h];restore exception handler
& && &add& &esp,4
& && &mov eax, fs:[18h] ; teb
& && &add eax, 0BFCh&&
& && &mov ebx, [eax] ; pointer to a unicode string&&
& && &test ebx, (ntdll.dll, gdi32.dll,...)&&
& && &je& && &rf_label
& && &jmp& & rt_label
&&exception_handler:
& && &mov& &eax,dword ptr [esp+0xc];EAX = ContextRecord
& && &inc& &dword ptr [eax+0xb8];set ContextRecord.EIP
& && &xor& &eax,eax
& && &retn
2.23 FD_check_StartupInfo();
&&这是从pediy上拷贝来的。Window创建进程的时候会把STARTUPINFO结构中的值设为0,而通过调试器创建进程的时候会忽略这个结构中的值，也就是结构中的值不为0，所以可以利用这个来判断是否在调试程序。
&&STARTUPINFO
&&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) )
2.24 FD_Parent_Process1()
与前面的FD_Parent_Process原理一样，唯一不同的是使用ZwQueryInformationProcess检测父进程，而没有使用Process32Next，这有一个好处是可以绕过OD的HideOD插件。
2.25 FD_Exception_Instruction_count()
&&好像《软件加解密技术》中有提到这个反调试。
&&通过注册一个异常句柄，在特定地址设置一些硬件断点，当通过这些地址时都会触发EXCEPTION_SINGLE_STEP (0x)的异常，在异常处理程序中，将会调整指令指针到一条新指令，然后恢复运行。可以通过进入进程context结构来设置这些断点，有些调试器不能处理那些不是自己设置的硬件断点，从而导致一些指令将会被漏掉计数，这就形成了一个反调试。
& & xor& & eax,
& & push&&e_
& & push&&dword ptr fs:[eax];
& & mov& & fs:[eax],
& & int 3;
hwbp1:&&nop
hwbp2:&&nop
hwbp3:&&nop
hwbp4:&&nop
& & div& & edx
& & pop& & dword ptr fs:[0]
& & add& & esp,4
& & cmp& & al,4;
& & jne& & rt_
& & jmp& & rf_
e_handler:
& & xor& & eax,
& & ;ExceptionRecord
& & mov& & ecx,dword ptr[esp+0x04]
& & ;Contextrecord
& & mov& & edx,dword ptr[esp+0x0c]
& & ;ContextEIP
& & inc& & byte ptr[edx+0xb8];
& & ;ExceptionCode
& & mov& & ecx,dword ptr[ecx];
& & ;1.EXCEPTION_INT_DIVIDE_BY_ZERO
& & cmp& & ecx,0xc0000094;
& & jne& & Ex_next2;
& & ;Context_eip
& & inc& & byte ptr[edx+0xb8];
& & mov& & dword ptr[edx+0x04],dr0
& & mov& & dword ptr[edx+0x08],dr1
& & mov& & dword ptr[edx+0x0c],dr2
& & mov& & dword ptr[edx+0x10],dr3
& & mov& & dword ptr[edx+0x14],dr6
& & mov& & dword ptr[edx+0x18],dr7
& & ;2.EXCEPTION_BREAKPOINT
& & cmp& & ecx,0x;
& & jne& & Ex_next3;
& & mov& & dword ptr[edx+0x04],offset hwbp1;dr0
& & mov& & dword ptr[edx+0x08],offset hwbp2;dr1
& & mov& & dword ptr[edx+0x0c],offset hwbp3;dr2
& & mov& & dword ptr[edx+0x10],offset hwbp4;dr3
& & mov& & dword ptr[edx+0x18],0x155;dr7
& & ;3.EXCEPTION_SINGLE_STEP
& & cmp&&ecx,0x
& & jne& & rt_label
& & ;CONTEXT_Eax
& & inc& & byte ptr[edx+0xb0]
2.26 FD_INT_2d()
在windows anti-debug reference中指出，如果程序未被调试这个中断将会生产一个断点异常. 被调试并且未使用跟踪标志执行这个指令, 将不会有异常产生程序正常执行. 如果被调试并且指令被跟踪, 尾随的字节将被跳过并且执行继续. 因此, 使用 INT 2Dh 能作为一个强有力的反调试和反跟踪机制。
& && &&&int 2dh
& && &any opcode of singlebyte.
& && &;or u can put some junkcode,&0xc8&...&0xc2&...&0xe8&...&0xe9&
&&__except(1)
三、&&检测-专用调试器(FS_)
& & 这一部分是我比较喜欢的，但内容还不是很丰富，比如：
1、&&针对SoftIce的检测方法有很多，但由于我从没使用过Softice，也没有条件去测试，所以没有给出太多，有兴趣的可以自己查阅资料进行补充，针对softice网上资料较多，或查阅《软件加解密技术》。
2、&&同样，这里也没有给出windbg等等其它调试器的检测方法。
3、&&而针对Odplugin，也只给了几种HideOD的检测。事实上，目前OD的使用者通常都使用众多的强大插件，当OD的反调试越来越普遍时，自己设计几款常用的OD插件的反调试，将会是非常有效的反调试手段。
4、&&对VME的检测也只给出了两种，如想丰富这一部分可以参考Peter Ferrie的一篇anti-vme的文章（）。里面有非常多的anti-vme方法。
& & 针对专用调试器的函数列表如下：
//find specific debugger
bool FS_OD_Exception_GuardPages();
bool FS_OD_Int3_Pushfd();
bool FS_SI_UnhandledExceptionFilter();
bool FS_ODP_Process32NextW();
bool FS_ODP_OutputDebugStringA();
bool FS_ODP_OpenProcess();
bool FS_ODP_CheckRemoteDebuggerPresent();
bool FS_ODP_ZwSetInformationThread();
bool FS_SI_Exception_Int1();
bool IsInsideVMWare_();
bool FV_VMWare_VMX();
bool FV_VPC_Exception();
int FV_VME_RedPill();//0:none,1:2:3thers
3.1 FS_OD_Exception_GuardPages
& & “保护页异常”是一个简单的反调试技巧。当应用程序尝试执行保护页内的代码时，将会产生一个EXCEPTION_GUARD_PAGE(0x)异常，但如果存在调试器，调试器有可能接收这个异常，并允许该程序继续运行，事实上，在OD中就是这样处理的，OD使用保护页来实现内存断点。
最开始实现时忘记了free申请的空间，多谢sessiondiy提醒。
&&SYSTEM_INFO sSysI
&&LPVOID lpvB
&&BYTE * lptmpB;
&&GetSystemInfo(&sSysInfo);
&&DWORD dwPageSize=sSysInfo.dwPageS
&&DWORD flOldP
&&DWORD dwE
&&lpvBase=VirtualAlloc(NULL,dwPageSize,MEM_COMMIT,PAGE_READWRITE);
&&if(lpvBase==NULL)
&&lptmpB=(BYTE *)lpvB
&&*lptmpB=0xc3;//retn
&&VirtualProtect(lpvBase,dwPageSize,PAGE_EXECUTE_READ | PAGE_GUARD,&flOldProtect);
& & __asm&&call dword ptr[lpvBase];
& & VirtualFree(lpvBase,0,MEM_RELEASE);
&&__except(1)
& & VirtualFree(lpvBase,0,MEM_RELEASE);
3.2 FS_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异常处理会判断是否已经设置硬件断点，如果已经有硬件断点就不产生单步异常，所以不能正常执行。
& & 大家也可以仔细研究下OD下的pushfd,popfd等指令，相信利用它们可以构造很多反调试，下面是我实现的一个，不过现在看起来有点没看懂，不知当时为什么用了两个int3。
& & push& &offset e_ set exception handler
& & push&&dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& &eax,reset EAX invoke int3
& & int& & 3h
& & pushfd
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& &esp,4
& & test& &eax, check the flag&&
& & je& & rf_label
& & jmp& & rt_label
e_handler:
& & push& &offset e_handler1; set exception handler
& & push&&dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& &eax,reset EAX invoke int3
& & int& & 3h
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& &esp,4
& & ;EAX = ContextRecord
& & mov& & ebx,dr0=&ebx
& & mov& &eax,dword ptr [esp+0xc]
& & ;set ContextRecord.EIP
& & inc& &dword ptr [eax+0xb8];
& & mov& & dword ptr [eax+0xb0],dr0=&eax
& & xor& & eax,eax
e_handler1:
& & ;EAX = ContextRecord
& & mov& &eax,dword ptr [esp+0xc]
& & ;set ContextRecord.EIP
& & inc& &dword ptr [eax+0xb8];
& & mov& & ebx,dword ptr[eax+0x04]
& & mov& & dword ptr [eax+0xb0],dr0=&eax
& & xor& & eax,eax
& & xor&&eax,eax
& & inc eax
& & mov esp,ebp
& & pop&&ebp
& & xor eax,eax
& & mov esp,ebp
& & pop ebp
3.3 FS_SI_UnhandledExceptionFilter
& & 这个针对SoftIce的反调试很简单，好像是SoftIce会修改UnhandledExceptionFilter这个函数的第一个字节为CC。因此判断这个字节是否为cc，就是一种检查softice的简便方法。
BYTE tmpB = 0;
(FARPROC&) Uaddr =GetProcAddress ( GetModuleHandle(&kernel32.dll&),&UnhandledExceptionFilter&);
tmpB = *((BYTE*)Uaddr);& &// 取UnhandledExceptionFilter函数第一字节
tmpB=tmpB^0x55;
if(tmpB ==0x99)& && && &&&// 如该字节为CC，则SoftICE己加载
3.4 FS_ODP_Process32NextW
& & 当我在调试FD_parentprocess时，感觉总是怪怪的，使用OD时运行Process32NextW总是返回失败，搞了一个晚上，才搞懂原来是OD的插件HideOD在作怪。当HideOD的Process32NextW的选项被选中时，它会更改Process32NextW的返回值，使其始终返回false，这主要是HideOD针对FD_parentprocess这个反调试的一个反反调试。但也正是这一点暴露的它的存在。
&&FARPROC Func_
&&WORD tmpW;
&&//1.Process32Next
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule,&Process32NextW&);
&&if (Func_addr != NULL)&&
& & tmpW=*(WORD*)Func_
& & OSVersion=myGetOSVersion();
& & switch(OSVersion)
& & case OS_winxp:
& && &if(tmpW!=0xFF8B)//maybe option of Process32Next is selected.
& & default:
& && &if(tmpW==0xC033)
& & 但上面的代码并不完美，因为有跨平台问题，所以要先获得当前操作系统版本。目前只在win2k和winxp下进行了测试。
3.5 FS_ODP_OutputDebugStringA
& & 同样,HIDEOD的OutputDebugStringA选项，也对OutputDebugStringA这个api做了处理，具体修改内容我记不得了，大家可以自己比对一下。我的代码如下：
&&FARPROC Func_
&&WORD tmpW;
&&//2.OutputDebugStringA
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule,&OutputDebugStringA&);
&&if (Func_addr != NULL)&&
& & tmpW=*(WORD*)Func_
& & OSVersion=myGetOSVersion();
& & switch(OSVersion)
& & case OS_winxp:
& && &if(tmpW!=0x3468)//maybe option of OutputDebugStringAt is selected.
& & default:
& && &if(tmpW==0x01e8)
3.6 FS_ODP_OpenProcess
& & 这个据称这个是针对HideDebugger这个插件的，当这个插件开启时，它会挂钩OpenProcess这个函数，它修改了OpenProcess的前几个字节。因此检测这几个字节就可实现这个反调试。
&&FARPROC Func_
&&BYTE tmpB;
&&//OpenProcess
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule,&OpenProcess&);
&&if (Func_addr != NULL)&&
& & tmpB=*((BYTE*)Func_addr+6);
& & if(tmpB==0xea)//HideDebugger Plugin of OD is present
3.7 FS_ODP_CheckRemoteDebuggerPresent
& & 和前面提到的两个HideOD的反调试类似，不多说了。大家可以自行比对一下开启和不开启HideOD时，CheckRemoteDebuggerPresent函数的异同，就可以设计反这个插件的反调试了。
&&FARPROC Func_
&&BYTE tmpB;
&&//2.CheckRemoteDebuggerPresent
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule,&CheckRemoteDebuggerPresent&);
&&if (Func_addr != NULL)&&
& & tmpB=*((BYTE*)Func_addr+10);
& & OSVersion=myGetOSVersion();
& & switch(OSVersion)
& & case OS_winxp:
& && &if(tmpB!=0x74)//HideOD is present
& & default:
3.8 FS_ODP_ZwSetInformationThread
& & 和前面提到的几个HideOD的反调试类似，大家可以自行比对一下开启和不开启HideOD时，ZwSetInformationThread函数的异同，就可以设计反这个插件的反调试了。
&&FARPROC Func_
&&WORD tmpW;
&&BYTE tmpB0,tmpB1;
&&//2.CheckRemoteDebuggerPresent
&&HMODULE hModule = 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)
& & case OS_winxp:
& && &if(tmpW!=0x0300)//HideOD is present
& & case OS_win2k:
& && &if((tmpB0!=0xcd)&&(tmpB1!=0x2e))
& & default:
3.9 FS_SI_Exception_Int1
& & 通常int1的DPL为0,这表示&cd 01&机器码不能在3环下执行。如果直接执行这个中断将会产生一个保护错误，windows会产生一个EXCEPTION_ACCESS_VIOLATION (0xc0000005)异常。然而，如果SOFTICE正在运行，它挂钩了int1，并调整其DPL为3。这样SoftICE就可以在用户模式执行单步操作了。
& & 当int 1发生时，SoftICE不检查它是由于陷阱标志位还是由软件中断产生，SoftICE总是去调用原始中断1的句柄，此时将会产生一个EXCEPTION_SINGLE_STEP (0x)而不是EXCEPTION_ACCESS_VIOLATION (0xc0000005)异常，这就形成了一个简单的反调试方法。
& & push& &offset eh_int1; set exception handler
& & push&&dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& &eax,reset flag(EAX) invoke int3
& & int& & 1h
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& &esp,4
& & cmp& & eax,0x; check the flag&&
& & je& & rt_label_int1
& & jmp& & rf_label_int1
& & mov& & eax,[esp+0x4];
& & mov& & ebx,dword ptr [eax];
& & mov& &eax,dword ptr [esp+0xc];EAX = ContextRecord
& & mov& & dword ptr [eax+0xb0],set flag (ContextRecord.EAX)
& & inc& &dword ptr [eax+0xb8];set ContextRecord.EIP
& & inc& &dword ptr [eax+0xb8];set ContextRecord.EIP
& & xor& &eax,eax
3.10 FV_VMWare_VMX
& & 这是一个针对VMWare虚拟机仿真环境的反调试，我从网上直接拷贝的代码。
& & VMWARE提供一种主机和客户机之间的通信方法，这可以被用做一种VMWare的反调试。Vmware将会处理IN （端口为0x5658/’VX’）指令，它会返回一个majic数值“VMXh”到EBX中。
& & 当在保护模式操作系统的3环下运行时，IN指令的执行将会产生一个异常，除非我们修改了I/O的优先级等级。然而，如果在VMWare下运行，将不会产生任何异常，同时EBX寄存器将会包含’VMXh’，ECX寄存器也会被修改为Vmware的产品ID。
& & 这种技巧在一些病毒中比较常用。
& & 针对VME的反调试，在peter Ferrie的另一篇文章&&Attacks on More Virtual Machine Emulators&&中有大量的描述，有兴趣的可以根据这篇文章，将FV_反调试好好丰富一下。
bool IsInsideVMWare_()
& & push& &edx
& & push& &ecx
& & push& &ebx
& & mov& & eax, 'VMXh'
& & mov& & ebx, 0 // any value but MAGIC VALUE
& & mov& & ecx, 10 // get VMWare version
& & mov& & edx, 'VX' // port number
& & in& &&&eax, dx // read port
& && && && && && & // on return EAX returns the VERSION
& & cmp& & ebx, 'VMXh' // is it a reply from VMWare?
& & setz& &[r] // set return value
& & pop& & ebx
& & pop& & ecx
& & pop& & edx
bool FV_VMWare_VMX()
& & return IsInsideVMWare_();
&&__except(1) // 1 = EXCEPTION_EXECUTE_HANDLER
3.11 FV_VPC_Exception
& & 这个代码我也是完整从网上拷贝下来的，具体原理在&&Attacks on More Virtual Machine Emulators&&这篇文章里也有详细描述。与VMWare使用一个特殊端口完成主机和客户机间通信的方法类似的是，VirtualPC靠执行非法指令产生一个异常供内核捕获。这个代码如下：
0F 3F x1 x20F C7 C8 y1 y2
& & 由这两个非法指令引起的异常将会被应用程序捕获，然而，如果VirtualPC正在运行，将不会产生异常。X1,x2的允许的数值还不知道，但有一部分已知可以使用，如0A 00,11 00…等等。
__declspec(naked) bool FV_VPC_Exception()
& & push ebp
& & mov&&ebp, esp
& & mov&&ecx, offset exception_handler
& & push ebx
& & push ecx
& & push dword ptr fs:[0]
& & mov&&dword ptr fs:[0], esp
& & mov&&ebx, 0 // Flag
& & mov&&eax, 1 // VPC function number
& & // call VPC&&
& &_asm __emit 0Fh
& &_asm __emit 3Fh
& &_asm __emit 07h
& &_asm __emit 0Bh
& & mov eax, dword ptr ss:[esp]
& & mov dword ptr fs:[0], eax
& & add esp, 8
& & test ebx, ebx
& & setz al
& & lea esp, dword ptr ss:[ebp-4]
& & mov ebx, dword ptr ss:[esp]
& & mov ebp, dword ptr ss:[esp+4]
& & add esp, 8
& & jmp ret1
exception_handler:
& & mov ecx, [esp+0Ch]
& & mov dword ptr [ecx+0A4h], -1 // EBX = -1 -& not running, ebx = 0 -& running
& & add dword ptr [ecx+0B8h], 4 // -& skip past the call to VPC
& & xor eax, eax // exception is handled
3.12 FV_VME_RedPill
& & 这个方法似乎是检测虚拟机的一个简单有效的方法，虽然还不能确定它是否是100%有效。名字很有意思，红色药丸（为什么不是bluepill,哈哈）。我在网上找到了个ppt专门介绍这个方法，可惜现在翻不到了。记忆中原理是这样的，主要检测IDT的数值，如果这个数值超过了某个数值，我们就可以认为应用程序处于虚拟环境中，似乎这个方法在多CPU的机器中并不可靠。据称ScoobyDoo方法是RedPill的升级版。代码也是在网上找的，做了点小改动。有四种返回结果，可以确认是VMWare，还是VirtualPC，还是其它VME，或是没有处于VME中。
& &//return value:&&0:none,1:2:3thers
& &unsigned char matrix[6];
& & unsigned char redpill[] =&&
& && &&&&\x0f\x01\x0d\x00\x00\x00\x00\xc3&;
& & HANDLE hProcess = GetCurrentProcess();
& & LPVOID lpAddress = NULL;
& & PDWORD lpflOldProtect = NULL;
& && &&&*((unsigned*)&redpill[3]) = (unsigned)
& && &&&lpAddress = VirtualAllocEx(hProcess, NULL, 6, MEM_RESERVE|MEM_COMMIT , PAGE_EXECUTE_READWRITE);
& && &&&if(lpAddress == NULL)
& && && && &return 0;
& && &&&BOOL success = VirtualProtectEx(hProcess, lpAddress, 6, PAGE_EXECUTE_READWRITE , lpflOldProtect);
& && &&&if(success != 0)
& && && && & return 0;
& && &&&memcpy(lpAddress, redpill, 8);
& && &&&((void(*)())lpAddress)();
& && &&&if (matrix[5]&0xd0)&&
& && && & if(matrix[5]==0xff)//vmvare
& && && && &return 1;
& && && & else if(matrix[5]==0xe8)//vitualpc
& && && && &return 2;
& && && & else
& && && && &return 3;
& && &&&else&&
& && && && &return 0;
& & __finally
& && &&&VirtualFreeEx(hProcess, lpAddress, 0, MEM_RELEASE);
四、&&检测-断点(FB_)
这一部分内容较少，但实际上可用的方法也比较多，我没有深入研究，不敢乱写，照抄了几个常用的方法：
//find breakpoint
bool FB_HWBP_Exception();
DWORD FB_SWBP_Memory_CRC();
bool FB_SWBP_ScanCC(BYTE * addr,int len);
bool FB_SWBP_CheckSum_Thread(BYTE *addr_begin,BYTE *addr_end,DWORD sumValue);
4.1 FB_HWBP_Exception
&&在异常处理程序中检测硬件断点，是比较常用的硬件断点检测方法。在很多地方都有提到。
& & push& &offset exeception_ set exception handler
& & push& &dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& & eax,reset EAX invoke int3
& & int& & 1h
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& & esp,4
& & ;test if EAX was updated (breakpoint identified)&&
& & test& &eax,eax
& & jnz& &&&rt_label
& & jmp& & rf_label
exeception_handler:
& & ;EAX = CONTEXT record
& & mov& &&&eax,dword ptr [esp+0xc]
& & ;check if Debug Registers Context.Dr0-Dr3 is not zero
& & cmp& &&&dword ptr [eax+0x04],0
& & jne& &&&hardware_bp_found
& & cmp& &&&dword ptr [eax+0x08],0
& & jne& &&&hardware_bp_found
& & cmp& &&&dword ptr [eax+0x0c],0
& & jne& &&&hardware_bp_found
& & cmp& &&&dword ptr [eax+0x10],0
& & jne& &&&hardware_bp_found
& & jmp& &&&exception_ret
hardware_bp_found:
& & ;set Context.EAX to signal breakpoint found
& & mov& &&&dword ptr [eax+0xb0],0xFFFFFFFF
exception_ret:
& & ;set Context.EIP upon return
& & inc& && & dword ptr [eax+0xb8];set ContextRecord.EIP
& & inc& && & dword ptr [eax+0xb8];set ContextRecord.EIP
& & xor& &&&eax,eax
4.2 FB_SWBP_Memory_CRC()
&&由于在一些常用调试器中，比如OD，其是将代码设置为0xcc来实现普通断点，因此当一段代码被设置了普通断点，则其中必定有代码的修改。因此对关键代码进行CRC校验则可以实现侦测普通断点。但麻烦的是每次代码修改，或更换编译环境，都要重新设置CRC校验值。
&&下面的代码拷贝自《软件加解密技术》，里面完成的是对整个代码段的CRC校验，CRC校验值保存在数据段。CRC32算法实现代码网上有很多，就不列出来了。
DWORD FB_SWBP_Memory_CRC()
&&//打开文件以获得文件的大小
&&DWORD fileSize,NumberOfBytesRW;
&&DWORD CodeSectionRVA,CodeSectionSize,NumberOfRvaAndSizes,DataDirectorySize,ImageB
&&BYTE* pMZ
&&DWORD pPEheaderRVA;
&&TCHAR&&*pB
&&TCHAR szFileName[MAX_PATH];&&
&&GetModuleFileName(NULL,szFileName,MAX_PATH);
&&//打开文件
&&HANDLE hFile = CreateFile(
& & szFileName,
& & GENERIC_READ,
& & FILE_SHARE_READ,&&
& & OPEN_EXISTING,
& & FILE_ATTRIBUTE_NORMAL,
& & NULL);
& &if ( hFile != INVALID_HANDLE_VALUE )
& & //获得文件长度 :
& & fileSize = GetFileSize(hFile,NULL);
& & if (fileSize == 0xFFFFFFFF) return 0;
& & pBuffer = new TCHAR [fileSize];& &&&//// 申请内存,也可用VirtualAlloc等函数申请内存
& & ReadFile(hFile,pBuffer, fileSize, &NumberOfBytesRW, NULL);//读取文件内容
& & CloseHandle(hFile);&&//关闭文件
& &&&return 0;
&&pMZheader=(BYTE*)pB //此时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));///得到代码块的内存大小
&&delete pB&&// 释放内存
&&return CRC32((BYTE*)(CodeSectionRVA+ImageBase),CodeSectionSize);
4.3 FB_SWBP_ScanCC
扫描CC的方法，比照前面校验代码CRC数值的方法更直接一些，它直接在所要检测的代码区域内检测是否有代码被更改为0xCC，0xcc对应汇编指令为int3 ,对一些常用的调试器(如OD)其普通断点就是通过修改代码为int3来实现的。但使用时要注意是否正常代码中就包含CC。通常这个方法用于扫描API函数的前几个字节，比如检测常用的MessageBoxA、GetDlgItemTextA等。
bool FB_SWBP_ScanCC(BYTE * addr,int len)
&&FARPROC Func_
&&HMODULE hModule = GetModuleHandle(&USER32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule, &MessageBoxA&);
&&if (addr==NULL)
& & addr=(BYTE *)Func_//for test
&&BYTE tmpB;
& & for(i=0;i&i++,addr++)
& && &tmpB=*
& && &tmpB=tmpB^0x55;
& && &if(tmpB==0x99)// cmp 0xcc
&&__except(1)
4.4 FB_SWBP_CheckSum_Thread(BYTE *addr_begin,BYTE *addr_end,DWORD sumValue);
此方法类似CRC的方法，只是这里是检测累加和。它与CRC的方法有同样的问题，就是要在编译后，计算累加和的数值，再将该值保存到数据区，重新编译。在这里创建了一个单独的线程用来监视代码段。
DWORD WINAPI CheckSum_ThreadFunc( LPVOID lpParam )&&
&&DWORD dwThrdParam[3];
&&BYTE tmpB;
&&DWORD Value=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];
&&DWORD sumValue=dwThrdParam[2];
&&for(int i=0;i&(addr_end-addr_begin);i++)
& & Value=Value+*(addr_begin+i);
&&/* //if sumvalue is const,it should be substract.
&&DWORD tmpV
&&Value=Value-(sumValue&0x000000FF);
&&tmpValue=(sumValue&0x0000FF00)&&8;
&&Value=Value-tmpV
&&tmpValue=(sumValue&0x0000FF00)&&16;
&&Value=Value-tmpV
&&tmpValue=(sumValue&0x0000FF00)&&24;
&&Value=Value-tmpV*/
&&if (Value!=sumValue)
& & MessageBox(NULL,&SWBP is found by CheckSum_ThreadFunc&,&CheckSum_ThreadFunc&,MB_OK|MB_ICONSTOP);
& & return 1;&&
bool FB_SWBP_CheckSum_Thread(BYTE *addr_begin,BYTE *addr_end,DWORD sumValue)
& & DWORD dwThreadId;
&&DWORD dwThrdParam[3];
&&dwThrdParam[0]=(DWORD)addr_
&&dwThrdParam[1]=(DWORD)addr_
&&dwThrdParam[2]=sumV
& & HANDLE hT&&
& & hThread = CreateThread(&&
& && &&&NULL,& && && && && && && && &// default security attributes&&
& && &&&0,& && && && && && && && && &// use default stack size& &
& && &&&CheckSum_ThreadFunc,& && && &// thread function&&
& && &&&&dwThrdParam[0],& && && && && & // argument to thread function&&
& && &&&0,& && && && && && && && && &// use default creation flags&&
& && &&&&dwThreadId);& && && && && & // returns the thread identifier&&
& & // Check the return value for success.&&
& &if (hThread == NULL)&&
& && &Sleep(1000);
& && &CloseHandle( hThread );
五、&&检测-跟踪(FT_)
个人认为，反跟踪的一些技巧，多数不会非常有效，因为在调试时，多数不会被跟踪经过，除非用高超的技巧将关键代码和垃圾代码及这些反跟踪技巧融合在一起，否则很容易被发现或被无意中跳过。
函数列表如下：
//Find Single-Step or Trace
bool FT_PushSS_PopSS();
void FT_RDTSC(unsigned int * time);
DWORD FT_GetTickCount();
DWORD FT_SharedUserData_TickCount();
DWORD FT_timeGetTime();
LONGLONG FT_QueryPerformanceCounter(LARGE_INTEGER *lpPerformanceCount);
bool FT_F1_IceBreakpoint();
bool FT_Prefetch_queue_nop1();
bool FT_Prefetch_queue_nop2();
5.1 FT_PushSS_PopSS
这个反调试在&&windows anti-debug reference&&里有描述，如果调试器跟踪经过下面的指令序列：
& & push ss& & //反跟踪指令序列
& & pop&&ss& & //反跟踪指令序列
& & pushf& & //反跟踪指令序列
& & pop eax& & //反跟踪指令序列
Pushf将会被执行，同时调试器无法设置压进堆栈的陷阱标志，应用程序通过检测陷阱标志就可以判断处是否被跟踪调试。
& & push ebp
& & mov ebp,esp
& & push ss& & //反跟踪指令序列
& & pop&&ss& & //反跟踪指令序列
& & pushf& & //反跟踪指令序列
& & pop eax& & //反跟踪指令序列
& & and&&eax,0x
& & jnz&&rt_label
& & xor eax,eax
& & mov esp,ebp
& & pop ebp
& & xor eax,eax
& & inc eax
& & mov esp,ebp
& & pop ebp
5.2 FT_RDTSC
通过检测某段程序执行的时间间隔，可以判断出程序是否被跟踪调试，被跟踪调试的代码通常都有较大的时间延迟，检测时间间隔的方法有很多种。比如RDTSC指令，kernel32_GetTickCount函数，winmm_ timeGetTime 函数等等。
下面为RDTSC的实现代码。
&&int time_low,time_
& & mov& & time_low,eax
& & mov& & time_high,edx
5.3 FT_GetTickCount
&&GetTickCount函数检测时间间隔简单且常用。直接调用即可。具体可查MSDN。
5.4 FT_SharedUserData_TickCount
&&直接调用GetTickCount函数来检测时间间隔的方法，虽然简单却容易被发现。而使用GetTickCount的内部实现代码，直接读取SharedUserData数据结构里的数据的方法，更隐蔽些。下面的代码是直接从GetTickCount里扣出来的，其应该是在位于0x7FFE0000地址处的SharedUserData数据接口里面直接取数据，不过这个代码应该有跨平台的问题，我这里没有处理。大家可以完善下。
&&DWORD tmpD;
& & mov& &&&edx, 0x7FFE0000
& & mov& &&&eax, dword ptr [edx]
& & mul& &&&dword ptr [edx+4]
& & shrd& & eax, edx, 0x18
& & mov& & tmpD,eax
&&return tmpD;
5.5 FT_timeGetTime
&&使用winmm里的timeGetTime的方法也可以用来检测时间间隔。直接调用这个函数即可。具体可查MSDN。
5.6 FT_QueryPerformanceCounter
&&这是一种高精度时间计数器的方法，它的检测刻度最小，更精确。
&&if(QueryPerformanceCounter(lpPerformanceCount))
& && &&&return lpPerformanceCount-&QuadP
& &&&return 0;
5.7 FT_F1_IceBreakpoint
&&在&&Windows anti-debug reference&&中有讲述这个反跟踪技巧。这个所谓的&Ice breakpoint& 是Intel 未公开的指令之一, 机器码为0xF1.执行这个指令将产生单步异常.,如果程序已经被跟踪, 调试器将会以为它是通过设置标志寄存器中的单步标志位生成的正常异常. 相关的异常处理器将不会被执行到.下面是我的实现代码：
&&push& &offset eh_f1; set exception handler
& &&&push&&dword ptr fs:[0h]
& &&&mov& & dword ptr fs:[0h],esp& &
& &&&xor& &eax,reset EAX invoke int3
& &&&_emit 0xf1
& &&&pop& & dword ptr fs:[0h];restore exception handler
& &&&add& & esp,4
&&test&&eax,eax
&&jz& & rt_label_f1
&&jmp& & rf_label_f1
& &&&mov eax,dword ptr[esp+0xc]
&&mov& & dword ptr [eax+0xb0],0x;set flag (ContextRecord.EAX)
& &&&inc dword ptr [eax+0xb8]
& &&&xor eax,eax
rt_label_f1:
&&inc& & eax
&&mov& & esp,ebp
& &&&pop& & ebp
rf_label_f1:
&&xor& & eax,eax
&&mov& & esp,ebp
& &&&pop& & ebp
5.8 FT_Prefetch_queue_nop1
这个反调试是在&&ANTI-UNPACKER TRICKS&&中给出的，它主要是基于REP指令，通过REP指令来修改自身代码，在非调试态下，计算机会将该指令完整取过来，因此可以正确的执行REP这个指令，将自身代码完整修改，但在调试态下，则在修改自身的时候立即跳出。
这个反跟踪技巧个人觉得用处不大，因为只有在REP指令上使用F7单步时，才会触发这个反跟踪，而我个人在碰到REP时，通常都是F8步过。下面是利用这个CPU预取指令的特性的实现反跟踪的一种方法，正常情况下，REP指令会修改其后的跳转指令，进入正常的程序流程，但在调试态下，其无法完成对其后代码的修改，从而实现反调试。
& &DWORD oldP
& &DWORD tmpP
& & lea eax,dword ptr[oldProtect]
& & push eax
& & push 0x40
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & mov al,0x90
& & push 0x10
& & pop ecx
& & mov edi,offset label3
& & rep stosb
& & jmp rt_label
& & ;write back
& & mov dword ptr[label3],0x106a90b0
& & mov dword ptr[label3+0x4],0x205CBF59
& & mov dword ptr[label3+0x8],0xAAF30040
& & mov dword ptr[label3+0xc],0x
& & mov dword ptr[label3+0x6],offset label3
& & lea eax, dword ptr[tmpProtect];
& & ;restore protect
& & push eax
& & push oldProtect
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & xor eax,eax
& & mov esp,ebp
& & pop ebp
& & ;write back
& & mov dword ptr[label3],0x106a90b0
& & mov dword ptr[label3+0x4],0x205CBF59
& & mov dword ptr[label3+0x8],0xAAF30040
& & mov dword ptr[label3+0xc],0x
& & mov dword ptr[label3+0x6],offset label3
& & lea eax, dword ptr[tmpProtect];
& & ;restore protect
& & push eax
& & push oldProtect
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & xor eax,eax
& & inc eax
& & mov esp,ebp
& & pop ebp
5.9 FT_Prefetch_queue_nop2
&&与5.8节类似，这是根据CPU预取指令的这个特性实现的另一种反跟踪技巧。原理是通过检测REP指令后的ECX值，来判断REP指令是否被完整执行。在正常情况下，REP指令完整执行后，ECX值应为0；但在调试态下，由于REP指令没有完整执行，ECX值为非0值。通过检测ECX值，实现反跟踪。
&&DWORD oldP
&&DWORD tmpP
& & lea eax,dword ptr[oldProtect]
& & push eax
& & push 0x40
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & mov ecx,0
& & mov al,0x90
& & push 0x10
& & pop ecx
& & mov edi,offset label3
& & rep stosb
& & push ecx
& & ;write back
& & mov dword ptr[label3],0x106a90b0
& & mov dword ptr[label3+0x4],0x201CBF59
& & mov dword ptr[label3+0x8],0xAAF30040
& & mov dword ptr[label3+0xc],0x
& & mov dword ptr[label3+0x6],offset label3
& & lea eax, dword ptr[tmpProtect];
& & ;restore protect
& & push eax
& & push oldProtect
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & pop ecx
& & test ecx,ecx
& & jne rt_label
六、&&检测-补丁(FP_)
这部分内容也较少，方法当然也有很多种，原理都差不多，我只选了下面三种。这几种方法通常在一些壳中较常用，用于检验文件是否被脱壳或被恶意修改。
函数列表如下：
//find Patch
bool FP_Check_FileSize(DWORD Size);
bool FP_Check_FileHashValue_CRC(DWORD CRCVALUE_origin);
bool FP_Check_FileHashValue_MD5(DWORD MD5VALUE_origin);
6.1 FP_Check_FileSize(DWORD Size)
&&通过检验文件自身的大小的方法，是一种比较简单的文件校验方法，通常如果被脱壳，或被恶意修改，就可能影响到文件的大小。我用下面的代码实现。需注意的是，文件的大小要先编译一次，将首次编译得到的数值写入代码，再重新编译完成。
&&DWORD Current_S
&&TCHAR szPath[MAX_PATH];
&&HANDLE hF
&&if( !GetModuleFileName( NULL,szPath, MAX_PATH ) )
& && &&&return FALSE;
&&hFile = CreateFile(szPath,&&
& & GENERIC_READ ,
& & FILE_SHARE_READ,&&
& & OPEN_ALWAYS,&&
& & FILE_ATTRIBUTE_NORMAL,&&
& & NULL);
&&if (hFile == INVALID_HANDLE_VALUE)
&&Current_Size=GetFileSize(hFile,NULL);
&&CloseHandle(hFile);
&&if(Current_Size!=Size)
6.2 FP_Check_FileHashValue_CRC
&&检验文件的CRC数值，是比较常用的文件校验方法，相信很多人都碰到过了，我是在《软件加解密技术》中了解到的。需注意的是文件原始CRC值的获得，及其放置位置，代码编写完成后，通常先运行一遍程序，使用调试工具获得计算得到的数值，在将这个数值写入文件中，通常这个数值不参加校验，可以放置在文件的尾部作为附加数据，也可以放在PE头中不用的域中。
&&下面的代码只是个演示，没有保存CRC的真实数值，也没有单独存放。
&&DWORD fileSize,NumberOfBytesRW;
&&DWORD CRCVALUE_
&&TCHAR szFileName[MAX_PATH];&&
&&TCHAR&&*pB
&&GetModuleFileName(NULL,szFileName,MAX_PATH);
&&HANDLE hFile = CreateFile(
& & szFileName,
& & GENERIC_READ,
& & FILE_SHARE_READ,&&
& & OPEN_EXISTING,
& & FILE_ATTRIBUTE_NORMAL,
& & NULL);
&&if (hFile != INVALID_HANDLE_VALUE )
& & fileSize = GetFileSize(hFile,NULL);
& & if (fileSize == 0xFFFFFFFF)
& & pBuffer = new TCHAR [fileSize];& &
& & ReadFile(hFile,pBuffer, fileSize, &NumberOfBytesRW, NULL);
& & CloseHandle(hFile);
&&CRCVALUE_current=CRC32((BYTE *)pBuffer,fileSize);
&&if(CRCVALUE_origin!=CRCVALUE_current)
联系我时，请说是在 外挂海论坛 上看到的，谢谢！
上一篇：下一篇：
阅读权限20
在线时间4 小时
积分主题听众
太强大了。佩服啊
阅读权限30
在线时间8 小时
积分主题听众
高手云集 马上来看看
阅读权限40
在线时间10 小时
积分主题听众
看完了 回复一下 不知道说什么
Powered by Discuz! X3.2
Comsenz Inc.}
本文章介绍了关于CentOS6.2编译安装MySQL5.5.25有需要的同学可参考一下。
按照之前ubuntu安装的步骤安装后，启动mysql启动不起来。错误代码为& The server quit without updating PID file(/var/lib/mysql/CentOS.pid)&，百度和google都搜索了一些资料，基本一致，对我没帮助，按照他们说的修改了也不行。于是乎结合张晏的博客，最终成功搞定。
第一步：我们首先安装依赖库和开发工具
#依赖库和开发工具
yum -y install gcc gcc-c++ autoconf libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-devel curl curl-devel e2fsprogs e2fsprogs-devel krb5 krb5-devel libidn libidn-devel openssl openssl-devel openldap openldap-devel nss_ldap openldap-clients openldap-servers
yum -y install pcre-devel& zlib-devel
yum -y install gd-devel libjpeg-devel libpng-devel freetype-devel libxml2-devel curl-devel freetype-devel
yum -y install bison gcc gcc-c++ autoconf automake zlib* libxml* ncurses-devel libtool-ltdl-devel* mysql-devel
第二步：由于mysql5.5开始，不再使用configure安装，而是使用cmake。所以需要先安装cmake
tar -zxvf cmake-2.8.6.tar.gz
cd cmake-2.8.6/
./configure
make && make install
第三步：cmake安装mysql（我已经下载好了mysql源码文件，放在U盘里，拷贝到/tmp目录下）
//进入/tmp目录下
tar -zxvf mysql-5.5.25.tar.gz
cd mysql-5.5.25
-DCMAKE_INSTALL_PREFIX=/usr/local/webserver/mysql
-DMYSQL_DATADIR=/user/local/webserver/mysql/data
-DSYSCONFDIR=/etc
-DEXTRA_CHARSETS=all
-DDEFAULT_CHARSET=utf8
-DDEFAULT_COLLATION=utf8_general_ci
-DWITH_INNOBASE_STORAGE_ENGINE=1
-DWITH_ARCHIVE_STORAGE_ENGINE=1
-DWITH_BLACKHOLE_STORAGE_ENGINE=1
-DWITH_FEDERATED_STORAGE_ENGINE=1
-DWITH_PARTITION_STORAGE_ENGINE=1
-DWITH_PERFSCHEMA_STORAGE_ENGINE=1
-DMYSQL_UNIX_ADDR=/tmp/mysqld.sock
-DMYSQL_TCP_PORT=3306
-DWITH_DEBUG=0
-DENABLED_LOCAL_INFILE=1
回车执行，执行完成后继续执行 make && make install
第四步：设置mysql
#设置Mysql
#在support-files目录中有五个配置信息文件(这里很重要，一定要根据自己的内存复制对应的cnf文件，否则mysql始终起不来)：
#f (内存&=64M)
#f (内存 128M)
#f (内存 512M)
#f (内存 1G-2G)
#my-innodb-f (内存 4GB)
cd /usr/local/webserver/mysql
cp ./support-files/f /f
#在 [mysqld] 段增加
datadir = /data/mysql
wait-timeout = 30
max_connections = 512
default-storage-engine = MyISAM
#在 [mysqld] 段修改
max_allowed_packet = 16M
第五步：添加mysql用户和用户组，生成新的mysql授权表
//添加mysql运行的用户和用户组
groupadd mysql
useradd -g mysql mysql -s /bin/false -d /home/mysql& //没有shell，不可本机登陆（安全起见）
cd /usr/local/webserver/mysql
chown -R root .
chown -R mysql data
chgrp -R mysql .
//生成新的mysql授权表
//进入目录下的脚本目录
cd /usr/local/webserver/mysql/scripts
//利用mysql_install_db脚本生成新的mysql授权表
./mysql_install_db --basedir=/usr/local/webserver/mysql --datadir=/usr/local/webserver/mysql/data --user=mysql
//mysql server在系统中的服务项设置
//复制服务文件并修改
cd /usr/local/webserver/mysql/support-files
cp mysql.server mysqld
//修改mysqld
basedir=/usr/local/webserver/mysql
datadir=/usr/local/webserver/mysql/data
mv mysqld /etc/init.d/mysqld
chmod 755 /etc/init.d/mysqld
//设置软连接使mysql,& ,& mysqladmin这三个bin命令能在shell中直接运行
sudo ln -s /usr/local/webserver/mysql/bin/mysql /usr/bin
sudo ln -s /usr/local/webserver/mysql/bin/mysqldump /usr/bin
sudo ln -s /usr/local/webserver/mysql/bin/mysqladmin /usr/bin
rm -rf /etc/f 因为已经把此文件复制到/f& 如果不删除的话，mysql启动不起来。
第六步：启动mysql，设置mysql用户名和密码
/etc/init.d/mysqld start
//设置root密码
mysqladmin -u root pass &admin&
//mysql中文乱码解决
//然后在[mysqld]配置选项下添加
character-set-server=utf8
//然后进入mysql
cd /usr/local/webserver/mysql/bin
mysql -u root -p
提示输入密码
mysql& show variables like '%character%';
//结果：character_set_database，character_set_server两项都变为utf8了
上一页： &&&&&下一页：相关内容查看: 957|回复: 3
反调试技巧总结-原理和实现
阅读权限40
在线时间7 小时
积分主题听众
技法精湛来自于日积月累
论坛严禁灌水，一律永久封禁！</
反调试技巧总结-原理和实现
我将反调试技巧按行为分为两大类，一类为检测，另一类为攻击，每类中按操作对象又分了五个小类：
1、 通用调试器& &&&包括所有调试器的通用检测方法
2、 特定调试器& &&&包括OD、IDA等调试器，也包括相关插件，也包括虚拟环境
3、 断点& && && &&&包括内存断点、普通断点、硬件断点检测
4、 单步和跟踪& &&&主要针对单步跟踪调试
5、 补丁& && && &&&包括文件补丁和内存补丁
反调试函数前缀
& && && && &&&检测& && &&&攻击
通用调试器& &&&FD_& && &&&AD_
特定调试器& &&&FS_& && &&&AS_
断点& && && &&&FB_& && &&&AB_
单步和跟踪& &&&FT_& && &&&AT_
补丁& && && &&&FP_& && &&&AP_
1、本文多数都是摘录和翻译，我只是重新组合并翻译，不会有人告侵权吧。里面多是按自己的理解来说明，可能有理解错误，或有更好的实现方法，希望大家帮忙指出错误。
2、我并没有总结完全，上面的部分分类目前还只有很少的函数甚至空白，等待大家和我一起来完善和补充。我坚信如果有扎实的基础知识，丰富的想像力，灵活的运用，就会创造出更多的属于自己的反调试。而最强的反调试，通常都是自己创造的，而不是来自别人的代码。
二、 查找-通用调试器(FD_)
函数列表如下，后面会依次说明，需事先说明的是，这些反调试手段多数已家喻户晓，目前有效的不多，多数已可以通过OD的插件顺利通过，如果你想验证它们的有效性，请关闭OD的所有反反调试插件：
bool FD_IsDebuggerPresent();
bool FD_PEB_BeingDebuggedFlag();
bool FD_PEB_NtGlobalFlags();
bool FD_Heap_HeapFlags();
bool FD_Heap_ForceFlags();
bool FD_Heap_Tail();
bool FD_CheckRemoteDebuggerPresent();
bool FD_NtQueryInfoProc_DbgPort();
bool FD_NtQueryInfoProc_DbgObjHandle();
bool FD_NtQueryInfoProc_DbgFlags();
bool FD_NtQueryInfoProc_SysKrlDbgInfo();
bool FD_SeDebugPrivilege();
bool FD_Parent_Process();
bool FD_DebugObject_NtQueryObject();
bool FD_Find_Debugger_Window();
bool FD_Find_Debugger_Process();
bool FD_Find_Device_Driver();
bool FD_Exception_Closehandle();
bool FD_Exception_Int3();
bool FD_Exception_Popf();
bool FD_OutputDebugString();
bool FD_TEB_check_in_Vista();
bool FD_check_StartupInfo();
bool FD_Parent_Process1();
bool FD_Exception_Instruction_count();
bool FD_INT_2d();
2.1 FD_IsDebuggerPresent()
对调试器来说，IsDebuggerPresent是臭名昭著的恶意函数。不多说了，它是个检测调试的api函数。实现更简单，只要调用IsDebuggerPresent就可以了。在调用它之前，可以加如下代码，以用来检测是否在函数头有普通断点，或是否被钩挂。
&&//check softbreak
&&if(*(BYTE*)Func_addr==0xcc)
&&//check hook
&&if(*(BYTE*)Func_addr!=0x64)
2.2 FD_PEB_BeingDebuggedFlag
我们知道，如果程序处于调试器中，那么在PEB结构中有个beingDegug标志会被设置，直接读取它就可判断是否在调试器中。实际上IsDebuggerPresent就是这么干的。
& & mov eax, fs:[30h] ;EAX =&&TEB.ProcessEnvironmentBlock
& & inc eax
& & inc eax
& & mov eax, [eax]
& & and eax,0x000000ff&&;AL&&=&&PEB.BeingDebugged
& & test eax, eax
& & jne rt_label
& & jmp rf_label
2.3 FD_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中使用过。
& & mov eax, fs:[30h]
& & mov eax, [eax+68h]
& & and eax, 0x70
& & test eax, eax
& & jne rt_label
& & jmp rf_label
2.4 FD_Heap_HeapFlags()
同样，调试器也会在堆中留下痕迹，你可以使用kernel32_GetProcessHeap()函数，如果你不希望使用api函数（以免暴露），则可以直接在PEB中寻找。同样的，使用HeapFlags和后面提到的ForceFlags来检测调试器也不是非常可靠，但却很常用。
这个域由一组标志组成，正常情况下，该值应为2。
& & mov eax, fs:[30h]
& & mov eax, [eax+18h] EB.ProcessHeap
& & mov eax, [eax+0ch] EB.ProcessHeap.Flags
& & cmp eax, 2
& & jne rt_label
& & jmp rf_label
2.5 FD_Heap_ForceFlags
进程堆里另外一个标志，ForceFlags，它也由一组标志组成，正常情况下，该值应为0。
& & mov eax, fs:[30h]
& & mov eax, [eax+18h] EB.ProcessHeap
& & mov eax, [eax+10h] ;PEB.ProcessHeap.ForceFlags
& & test eax, eax
& & jne rt_label
& & jmp rf_label
2.6 FD_Heap_Tail
如果处于调试中，堆尾部也会留下痕迹。标志HEAP_TAIL_CHECKING_ENABLED 将会在分配的堆块尾部生成两个0xABABABAB。如果需要额外的字节来填充堆尾，HEAP_FREE_CHECKING_ENABLED标志则会生成0xFEEEFEEE。
据说Themida使用过这个反调试
& & mov eax, buff
& & ;get unused_bytes
& & movzx ecx, byte ptr [eax-2]
& & movzx edx, word ptr [eax-8] ;size
& & sub eax, ecx
& & lea edi, [edx*8+eax]
& & mov al, 0abh
& & mov cl, 8
& & repe sca**
& & je rt_label
& & jmp rf_label
2.7 FD_CheckRemoteDebuggerPresent
CheckRemoteDebuggerPresent是另一个检测调试的api，只是可惜它似乎只能在winxp sp1版本以后使用。它主要是用来查询一个在winnt时就有的一个数值，其内部会调用NtQueryInformationProcess()，我是这样实现的：
&&FARPROC Func_
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);
&&if (hModule==INVALID_HANDLE_VALUE)
&&(FARPROC&) Func_addr =GetProcAddress(hModule, &CheckRemoteDebuggerPresent&);
&&if (Func_addr != NULL)&&
& & __asm&&
& && &push&&
& && &push&&
& && &push&&0
& && &call&&Func_
& && &test&&eax,
& && &je& & rf_
& && &pop& &
& && &test&&eax,eax
& && &je& & rf_
& && &jmp& & rt_
2.8 FD_NtQueryInfoProc_DbgPort
使用ntdll_NtQueryInformationProcess()来查询ProcessDebugPort可以用来检测反调试。如果进程被调试，其返回值应为0xffffffff。
下面的代码应该是从pediy里copy过来的，时间太长，不记得是哪位兄弟的代码了。
&&HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
&&ZW_QUERY_INFORMATION_PROCESS ZwQueryInformationP&&
& & ZwQueryInformationProcess = (ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule, &ZwQueryInformationProcess&);&&
& & if (ZwQueryInformationProcess == NULL)&&
&&PROCESS_DEBUG_PORT_INFO ProcessI&&
&&if (STATUS_SUCCESS != ZwQueryInformationProcess(GetCurrentProcess( ), ProcessDebugPort, &ProcessInfo, sizeof(ProcessInfo), NULL))&&
& & if(ProcessInfo.DebugPort)
2.9 FD_NtQueryInfoProc_DbgObjHandle
&&在winxp中引入了&debug object&.当一个调试活动开始，一个&debug object&被创建，同也相应产生了一个句柄。使用为公开的ProcessDebugObjectHandle类，可以查询这个句柄的数值。
&&代码可能还是从pediy里复制的，不记得了。
&&HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
&&ZW_QUERY_INFORMATION_PROCESS ZwQueryInformationP&&
& & ZwQueryInformationProcess = (ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule, &ZwQueryInformationProcess&);&&
& & if (ZwQueryInformationProcess == NULL)&&
&&_PROCESS_DEBUG_OBJECTHANDLE_INFO ProcessI&&
&&if (STATUS_SUCCESS != ZwQueryInformationProcess(GetCurrentProcess( ), (PROCESS_INFO_CLASS)0x0000001e, &ProcessInfo, sizeof(ProcessInfo), NULL))&&
& & if(ProcessInfo.ObjectHandle)
2.10 FD_NtQueryInfoProc_DbgFlags();
同样的未公开的ProcessDebugFlags类，当调试器存在时，它会返回false。
&&HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
&&ZW_QUERY_INFORMATION_PROCESS ZwQueryInformationP&&
& & ZwQueryInformationProcess = (ZW_QUERY_INFORMATION_PROCESS)GetProcAddress(hModule, &ZwQueryInformationProcess&);&&
& & if (ZwQueryInformationProcess == NULL)&&
&&_PROCESS_DEBUG_FLAGS_INFO ProcessI&&
&&if (STATUS_SUCCESS != ZwQueryInformationProcess(GetCurrentProcess( ), (PROCESS_INFO_CLASS)0x0000001f, &ProcessInfo, sizeof(ProcessInfo), NULL))&&
& & if(ProcessInfo.Debugflags)
2.11 FD_NtQueryInfoProc_SysKrlDbgInfo()
这个方法估计对大家用处不大，SystemKernelDebuggerInformation类同样可以用来识别调试器，只是可惜在windows下无效，据称可以用在reactOS中。
& &HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
& & ZW_QUERY_SYSTEM_INFORMATION ZwQuerySystemI&&
& & ZwQuerySystemInformation = (ZW_QUERY_SYSTEM_INFORMATION)GetProcAddress(hModule, &ZwQuerySystemInformation&);&&
& & if (ZwQuerySystemInformation == NULL)&&
& & SYSTEM_KERNEL_DEBUGGER_INFORMATION I&&
& & if (STATUS_SUCCESS == ZwQuerySystemInformation(SystemKernelDebuggerInformation, &Info, sizeof(Info), NULL))&&
& && &&&if (Info.DebuggerEnabled)&&
& && &&&{&&
& && && && &if (Info.DebuggerNotPresent)&&
& && && && && &
& && && && &else&&
& && && && && &
& && &&&}&&
& && &&&else&&
& && && && &
& & else&&
2.12 FD_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 );
2.13 FD_Parent_Process()
通常我们都直接在windows界面下运行应用程序，这样的结果就是它的父进程为&explorer.exe&，这个反调试就是检测应用程序的父进程是否为&explorer.exe&，如不是则判定为处于调试器中，这也不是百分百可靠，因为有的时候你的程序是在命令行提示符下运行的。
Yoda使用了这个反调试，它使用Process32Next检测父进程，目前很多插件已经通过使Process32Next始终返回false来越过这个反调试(比如HideOD)。不过可以对代码做些简单的修正来处理这个反反调试。
2.14 FD_DebugObject_NtQueryObject();
&&如前面所描述的，当一个调试活动开始，一个&debug object&被创建，同也相应产生了一个句柄。我们可以查询这个调试对象列表，并检查调试对象的数量，以实现调试器的检测。
&&HMODULE hModule = GetModuleHandle(&ntdll.dll&);&&
&&PNtQueryObject NtQueryO
&&NtQueryObject = (PNtQueryObject)GetProcAddress(hModule,&NtQueryObject&);
&&if(NtQueryObject==NULL)
&&unsigned char szdbgobj[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&;
&&unsigned char *psz=&szdbgobj[0];
& & xor& & ebx,
& & push&&
& & push&&
& & push&&
& & push&&
& & push&&3;
& & push&&
& & Call&&dword ptr [NtQueryObject];
& & push&&4;
& & push&&1000h;
& & push&&
& & push&&
& && &call&&dword ptr [VirtualAlloc];
& & push&&
& & push&&
& & push&&
& & push&&3;
& & push&&
& & xchg&&esi,
& & Call&&dword ptr [NtQueryObject];
& & xchg&&ecx,
& & movzx&&edx,
& & xchg&&esi,
& & cmp& & edx,16h;
& & jne& & label2;
& & xchg&&ecx,
& & mov& & edi,
& & repe&&cmp**;
& & xchg&&ecx,
& & jne& & label2;
& & cmp& & dword ptr [eax],edx
& & jne& & rt_
lable2:&&add& & esi,edx
& & and& & esi,-4;
& & loop&&label1;
2.15 FD_Find_Debugger_Window();
通过列举运行的应用程序的窗口，并于常用调试相关工具比对的方法，应该很常用了，就不多说了。这个也是个可以自行增加项目的函数，你可以将一些常用的调试工具归入其中，比如OD,IDA,WindBG,SoftICE等，你也可以添加任何你需要的，比如&Import REConstructor v1.6 FINAL (C)
MackT/uCF&，&Registry Monitor - Sysinternals: &等等。
&&//ollyice
& & hWnd=CWnd::FindWindow(_T(&1212121&),NULL);
& & if (hWnd!=NULL)
&&//ollydbg v1.1
& & hWnd=CWnd::FindWindow(_T(&icu_dbg&),NULL);
& & if (hWnd!=NULL)
&&//ollyice pe--diy
& & hWnd=CWnd::FindWindow(_T(&pe--diy&),NULL);
& & if (hWnd!=NULL)
&&//ollydbg ?-°?
& & hWnd=CWnd::FindWindow(_T(&ollydbg&),NULL);
& & if (hWnd!=NULL)
&&//ollydbg ?-°?
& & hWnd=CWnd::FindWindow(_T(&odbydyk&),NULL);
& & if (hWnd!=NULL)
&&//windbg
& & hWnd=CWnd::FindWindow(_T(&WinDbgFrameClass&),NULL);
& & if (hWnd!=NULL)
&&//dede3.50
& & hWnd=CWnd::FindWindow(_T(&TDeDeMainForm&),NULL);
& & if (hWnd!=NULL)
&&//IDA5.20
& & hWnd=CWnd::FindWindow(_T(&TIdaWindow&),NULL);
& & if (hWnd!=NULL)
&&//others
& & hWnd=CWnd::FindWindow(_T(&TESTDBG&),NULL);
& & if (hWnd!=NULL)
& & hWnd=CWnd::FindWindow(_T(&kk1&),NULL);
& & if (hWnd!=NULL)
& & hWnd=CWnd::FindWindow(_T(&Eew75&),NULL);
& & if (hWnd!=NULL)
& & hWnd=CWnd::FindWindow(_T(&Shadow&),NULL);
& & if (hWnd!=NULL)
&&//PEiD v0.94
& & hWnd=CWnd::FindWindow(NULL,&PEiD v0.94&);
& & if (hWnd!=NULL)
&&//RegMON
& & hWnd=CWnd::FindWindow(NULL,&Registry Monitor - Sysinternals: &);
& & if (hWnd!=NULL)
&&//File Monitor
& & hWnd=CWnd::FindWindow(NULL,&File Monitor - Sysinternals: &);
& & if (hWnd!=NULL)
&&//Import Rec v1.6
& & hWnd=CWnd::FindWindow(NULL,&Import REConstructor v1.6 FINAL (C)
MackT/uCF&);
& & if (hWnd!=NULL)
2.16 FD_Find_Debugger_Process();
&&与上面的方法类似，区别是这个反调试用通过查询进程名字与已知的常用调试器应用程序名字进行比对，以确定是否有调试器处于运行状态。
& & if(strcmp(pe32.szExeFile,&OLLYICE.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&IDAG.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&OLLYDBG.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&PEID.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&SOFTICE.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&LORDPE.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&IMPORTREC.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&W32DSM89.EXE&)==0)
& & if(strcmp(pe32.szExeFile,&WINDBG.EXE&)==0)
2.17 FD_Find_Device_Driver()
&&调试工具通常会使用内核驱动，因此如果尝试是否可以打开一些调试器所用到的设备，就可判断是否存在调试器。常用的设备名称如下：
\\.\SICE&&（SoftICE）
\\.\SIWVID（SoftICE）& &&&
\\.\NTICE&&（SoftICE）& &&&
\\.\REGVXG（RegMON）
\\.\REGVXD（RegMON）
\\.\REGSYS（RegMON）
\\.\REGSYS（RegMON）
\\.\FILEVXG（FileMON）
\\.\FILEM（FileMON）
\\.\TRW（TRW2000）
2.18 FD_Exception_Closehandle()
&&如果给CloseHandle()函数一个无效句柄作为输入参数，在无调试器时，将会返回一个错误代码，而有调试器存在时，将会触发一个EXCEPTION_INVALID_HANDLE (0xc0000008)的异常。
& & CloseHandle(HANDLE(0x));
&&__except(1)
2.19 FD_Exception_Int3()
&&通过Int3产生异常中断的反调试比较经典。当INT3 被执行到时, 如果程序未被调试, 将会异常处理器程序继续执行。而INT3指令常被调试器用于设置软件断点，int 3会导致调试器误认为这是一个自己的断点，从而不会进入异常处理程序。
& & push& &offset exception_ set exception handler
& & push&&dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& &eax,reset EAX invoke int3
& & int& & 3h
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& &esp,4
& & test& &eax, check the flag&&
& & je& & rt_label
& & jmp& & rf_label
exception_handler:
& & mov& &eax,dword ptr [esp+0xc];EAX = ContextRecord
& & mov& & dword ptr [eax+0xb0],0set flag (ContextRecord.EAX)
& & inc& &dword ptr [eax+0xb8];set ContextRecord.EIP
& & xor& &eax,eax
& & xor eax,eax
& & inc eax
& & mov esp,ebp
& & pop ebp
& & xor eax,eax
& & mov esp,ebp
& & pop ebp
2.20 FD_Exception_Popf()
我们都知道标志寄存器中的陷阱标志，当该标志被设置时，将产生一个单步异常。在程序中动态设置这给标志，如果处于调试器中，该异常将会被调试器捕获。
可通过下面的代码设置标志寄存器。
& & pushf&&
& & mov dword ptr [esp], 0x100
2.21 FD_OutputDebugString()
&&在有调试器存在和没有调试器存在时，OutputDebugString函数表现会有所不同。最明显的不同是， 如果有调试器存在，其后的GetLastError()的返回值为零。
&&OutputDebugString(&&);
&&tmpD=GetLastError();
&&if(tmpD==0)
2.22 FD_TEB_check_in_Vista();
&&这是从windows anti-debug reference里拷贝出来的，据说是适用于vista系统下检测调试器。我没有vista所以也没有测试。有条件的可以试下，有问题帮忙反馈给我。多谢。
& & //vista
& && &push& &offset exception_ set exception handler
& && &push&&dword ptr fs:[0h]
& && &mov& & dword ptr fs:[0h],esp& &
& && &xor& &eax,reset EAX invoke int3
& && &int& & 3h
& && &pop& & dword ptr fs:[0h];restore exception handler
& && &add& &esp,4
& && &mov eax, fs:[18h] ; teb
& && &add eax, 0BFCh&&
& && &mov ebx, [eax] ; pointer to a unicode string&&
& && &test ebx, (ntdll.dll, gdi32.dll,...)&&
& && &je& && &rf_label
& && &jmp& & rt_label
&&exception_handler:
& && &mov& &eax,dword ptr [esp+0xc];EAX = ContextRecord
& && &inc& &dword ptr [eax+0xb8];set ContextRecord.EIP
& && &xor& &eax,eax
& && &retn
2.23 FD_check_StartupInfo();
&&这是从pediy上拷贝来的。Window创建进程的时候会把STARTUPINFO结构中的值设为0,而通过调试器创建进程的时候会忽略这个结构中的值，也就是结构中的值不为0，所以可以利用这个来判断是否在调试程序。
&&STARTUPINFO
&&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) )
2.24 FD_Parent_Process1()
与前面的FD_Parent_Process原理一样，唯一不同的是使用ZwQueryInformationProcess检测父进程，而没有使用Process32Next，这有一个好处是可以绕过OD的HideOD插件。
2.25 FD_Exception_Instruction_count()
&&好像《软件加解密技术》中有提到这个反调试。
&&通过注册一个异常句柄，在特定地址设置一些硬件断点，当通过这些地址时都会触发EXCEPTION_SINGLE_STEP (0x)的异常，在异常处理程序中，将会调整指令指针到一条新指令，然后恢复运行。可以通过进入进程context结构来设置这些断点，有些调试器不能处理那些不是自己设置的硬件断点，从而导致一些指令将会被漏掉计数，这就形成了一个反调试。
& & xor& & eax,
& & push&&e_
& & push&&dword ptr fs:[eax];
& & mov& & fs:[eax],
& & int 3;
hwbp1:&&nop
hwbp2:&&nop
hwbp3:&&nop
hwbp4:&&nop
& & div& & edx
& & pop& & dword ptr fs:[0]
& & add& & esp,4
& & cmp& & al,4;
& & jne& & rt_
& & jmp& & rf_
e_handler:
& & xor& & eax,
& & ;ExceptionRecord
& & mov& & ecx,dword ptr[esp+0x04]
& & ;Contextrecord
& & mov& & edx,dword ptr[esp+0x0c]
& & ;ContextEIP
& & inc& & byte ptr[edx+0xb8];
& & ;ExceptionCode
& & mov& & ecx,dword ptr[ecx];
& & ;1.EXCEPTION_INT_DIVIDE_BY_ZERO
& & cmp& & ecx,0xc0000094;
& & jne& & Ex_next2;
& & ;Context_eip
& & inc& & byte ptr[edx+0xb8];
& & mov& & dword ptr[edx+0x04],dr0
& & mov& & dword ptr[edx+0x08],dr1
& & mov& & dword ptr[edx+0x0c],dr2
& & mov& & dword ptr[edx+0x10],dr3
& & mov& & dword ptr[edx+0x14],dr6
& & mov& & dword ptr[edx+0x18],dr7
& & ;2.EXCEPTION_BREAKPOINT
& & cmp& & ecx,0x;
& & jne& & Ex_next3;
& & mov& & dword ptr[edx+0x04],offset hwbp1;dr0
& & mov& & dword ptr[edx+0x08],offset hwbp2;dr1
& & mov& & dword ptr[edx+0x0c],offset hwbp3;dr2
& & mov& & dword ptr[edx+0x10],offset hwbp4;dr3
& & mov& & dword ptr[edx+0x18],0x155;dr7
& & ;3.EXCEPTION_SINGLE_STEP
& & cmp&&ecx,0x
& & jne& & rt_label
& & ;CONTEXT_Eax
& & inc& & byte ptr[edx+0xb0]
2.26 FD_INT_2d()
在windows anti-debug reference中指出，如果程序未被调试这个中断将会生产一个断点异常. 被调试并且未使用跟踪标志执行这个指令, 将不会有异常产生程序正常执行. 如果被调试并且指令被跟踪, 尾随的字节将被跳过并且执行继续. 因此, 使用 INT 2Dh 能作为一个强有力的反调试和反跟踪机制。
& && &&&int 2dh
& && &any opcode of singlebyte.
& && &;or u can put some junkcode,&0xc8&...&0xc2&...&0xe8&...&0xe9&
&&__except(1)
三、&&检测-专用调试器(FS_)
& & 这一部分是我比较喜欢的，但内容还不是很丰富，比如：
1、&&针对SoftIce的检测方法有很多，但由于我从没使用过Softice，也没有条件去测试，所以没有给出太多，有兴趣的可以自己查阅资料进行补充，针对softice网上资料较多，或查阅《软件加解密技术》。
2、&&同样，这里也没有给出windbg等等其它调试器的检测方法。
3、&&而针对Odplugin，也只给了几种HideOD的检测。事实上，目前OD的使用者通常都使用众多的强大插件，当OD的反调试越来越普遍时，自己设计几款常用的OD插件的反调试，将会是非常有效的反调试手段。
4、&&对VME的检测也只给出了两种，如想丰富这一部分可以参考Peter Ferrie的一篇anti-vme的文章（）。里面有非常多的anti-vme方法。
& & 针对专用调试器的函数列表如下：
//find specific debugger
bool FS_OD_Exception_GuardPages();
bool FS_OD_Int3_Pushfd();
bool FS_SI_UnhandledExceptionFilter();
bool FS_ODP_Process32NextW();
bool FS_ODP_OutputDebugStringA();
bool FS_ODP_OpenProcess();
bool FS_ODP_CheckRemoteDebuggerPresent();
bool FS_ODP_ZwSetInformationThread();
bool FS_SI_Exception_Int1();
bool IsInsideVMWare_();
bool FV_VMWare_VMX();
bool FV_VPC_Exception();
int FV_VME_RedPill();//0:none,1:2:3thers
3.1 FS_OD_Exception_GuardPages
& & “保护页异常”是一个简单的反调试技巧。当应用程序尝试执行保护页内的代码时，将会产生一个EXCEPTION_GUARD_PAGE(0x)异常，但如果存在调试器，调试器有可能接收这个异常，并允许该程序继续运行，事实上，在OD中就是这样处理的，OD使用保护页来实现内存断点。
最开始实现时忘记了free申请的空间，多谢sessiondiy提醒。
&&SYSTEM_INFO sSysI
&&LPVOID lpvB
&&BYTE * lptmpB;
&&GetSystemInfo(&sSysInfo);
&&DWORD dwPageSize=sSysInfo.dwPageS
&&DWORD flOldP
&&DWORD dwE
&&lpvBase=VirtualAlloc(NULL,dwPageSize,MEM_COMMIT,PAGE_READWRITE);
&&if(lpvBase==NULL)
&&lptmpB=(BYTE *)lpvB
&&*lptmpB=0xc3;//retn
&&VirtualProtect(lpvBase,dwPageSize,PAGE_EXECUTE_READ | PAGE_GUARD,&flOldProtect);
& & __asm&&call dword ptr[lpvBase];
& & VirtualFree(lpvBase,0,MEM_RELEASE);
&&__except(1)
& & VirtualFree(lpvBase,0,MEM_RELEASE);
3.2 FS_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异常处理会判断是否已经设置硬件断点，如果已经有硬件断点就不产生单步异常，所以不能正常执行。
& & 大家也可以仔细研究下OD下的pushfd,popfd等指令，相信利用它们可以构造很多反调试，下面是我实现的一个，不过现在看起来有点没看懂，不知当时为什么用了两个int3。
& & push& &offset e_ set exception handler
& & push&&dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& &eax,reset EAX invoke int3
& & int& & 3h
& & pushfd
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& &esp,4
& & test& &eax, check the flag&&
& & je& & rf_label
& & jmp& & rt_label
e_handler:
& & push& &offset e_handler1; set exception handler
& & push&&dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& &eax,reset EAX invoke int3
& & int& & 3h
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& &esp,4
& & ;EAX = ContextRecord
& & mov& & ebx,dr0=&ebx
& & mov& &eax,dword ptr [esp+0xc]
& & ;set ContextRecord.EIP
& & inc& &dword ptr [eax+0xb8];
& & mov& & dword ptr [eax+0xb0],dr0=&eax
& & xor& & eax,eax
e_handler1:
& & ;EAX = ContextRecord
& & mov& &eax,dword ptr [esp+0xc]
& & ;set ContextRecord.EIP
& & inc& &dword ptr [eax+0xb8];
& & mov& & ebx,dword ptr[eax+0x04]
& & mov& & dword ptr [eax+0xb0],dr0=&eax
& & xor& & eax,eax
& & xor&&eax,eax
& & inc eax
& & mov esp,ebp
& & pop&&ebp
& & xor eax,eax
& & mov esp,ebp
& & pop ebp
3.3 FS_SI_UnhandledExceptionFilter
& & 这个针对SoftIce的反调试很简单，好像是SoftIce会修改UnhandledExceptionFilter这个函数的第一个字节为CC。因此判断这个字节是否为cc，就是一种检查softice的简便方法。
BYTE tmpB = 0;
(FARPROC&) Uaddr =GetProcAddress ( GetModuleHandle(&kernel32.dll&),&UnhandledExceptionFilter&);
tmpB = *((BYTE*)Uaddr);& &// 取UnhandledExceptionFilter函数第一字节
tmpB=tmpB^0x55;
if(tmpB ==0x99)& && && &&&// 如该字节为CC，则SoftICE己加载
3.4 FS_ODP_Process32NextW
& & 当我在调试FD_parentprocess时，感觉总是怪怪的，使用OD时运行Process32NextW总是返回失败，搞了一个晚上，才搞懂原来是OD的插件HideOD在作怪。当HideOD的Process32NextW的选项被选中时，它会更改Process32NextW的返回值，使其始终返回false，这主要是HideOD针对FD_parentprocess这个反调试的一个反反调试。但也正是这一点暴露的它的存在。
&&FARPROC Func_
&&WORD tmpW;
&&//1.Process32Next
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule,&Process32NextW&);
&&if (Func_addr != NULL)&&
& & tmpW=*(WORD*)Func_
& & OSVersion=myGetOSVersion();
& & switch(OSVersion)
& & case OS_winxp:
& && &if(tmpW!=0xFF8B)//maybe option of Process32Next is selected.
& & default:
& && &if(tmpW==0xC033)
& & 但上面的代码并不完美，因为有跨平台问题，所以要先获得当前操作系统版本。目前只在win2k和winxp下进行了测试。
3.5 FS_ODP_OutputDebugStringA
& & 同样,HIDEOD的OutputDebugStringA选项，也对OutputDebugStringA这个api做了处理，具体修改内容我记不得了，大家可以自己比对一下。我的代码如下：
&&FARPROC Func_
&&WORD tmpW;
&&//2.OutputDebugStringA
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule,&OutputDebugStringA&);
&&if (Func_addr != NULL)&&
& & tmpW=*(WORD*)Func_
& & OSVersion=myGetOSVersion();
& & switch(OSVersion)
& & case OS_winxp:
& && &if(tmpW!=0x3468)//maybe option of OutputDebugStringAt is selected.
& & default:
& && &if(tmpW==0x01e8)
3.6 FS_ODP_OpenProcess
& & 这个据称这个是针对HideDebugger这个插件的，当这个插件开启时，它会挂钩OpenProcess这个函数，它修改了OpenProcess的前几个字节。因此检测这几个字节就可实现这个反调试。
&&FARPROC Func_
&&BYTE tmpB;
&&//OpenProcess
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule,&OpenProcess&);
&&if (Func_addr != NULL)&&
& & tmpB=*((BYTE*)Func_addr+6);
& & if(tmpB==0xea)//HideDebugger Plugin of OD is present
3.7 FS_ODP_CheckRemoteDebuggerPresent
& & 和前面提到的两个HideOD的反调试类似，不多说了。大家可以自行比对一下开启和不开启HideOD时，CheckRemoteDebuggerPresent函数的异同，就可以设计反这个插件的反调试了。
&&FARPROC Func_
&&BYTE tmpB;
&&//2.CheckRemoteDebuggerPresent
&&HMODULE hModule = GetModuleHandle(&kernel32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule,&CheckRemoteDebuggerPresent&);
&&if (Func_addr != NULL)&&
& & tmpB=*((BYTE*)Func_addr+10);
& & OSVersion=myGetOSVersion();
& & switch(OSVersion)
& & case OS_winxp:
& && &if(tmpB!=0x74)//HideOD is present
& & default:
3.8 FS_ODP_ZwSetInformationThread
& & 和前面提到的几个HideOD的反调试类似，大家可以自行比对一下开启和不开启HideOD时，ZwSetInformationThread函数的异同，就可以设计反这个插件的反调试了。
&&FARPROC Func_
&&WORD tmpW;
&&BYTE tmpB0,tmpB1;
&&//2.CheckRemoteDebuggerPresent
&&HMODULE hModule = 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)
& & case OS_winxp:
& && &if(tmpW!=0x0300)//HideOD is present
& & case OS_win2k:
& && &if((tmpB0!=0xcd)&&(tmpB1!=0x2e))
& & default:
3.9 FS_SI_Exception_Int1
& & 通常int1的DPL为0,这表示&cd 01&机器码不能在3环下执行。如果直接执行这个中断将会产生一个保护错误，windows会产生一个EXCEPTION_ACCESS_VIOLATION (0xc0000005)异常。然而，如果SOFTICE正在运行，它挂钩了int1，并调整其DPL为3。这样SoftICE就可以在用户模式执行单步操作了。
& & 当int 1发生时，SoftICE不检查它是由于陷阱标志位还是由软件中断产生，SoftICE总是去调用原始中断1的句柄，此时将会产生一个EXCEPTION_SINGLE_STEP (0x)而不是EXCEPTION_ACCESS_VIOLATION (0xc0000005)异常，这就形成了一个简单的反调试方法。
& & push& &offset eh_int1; set exception handler
& & push&&dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& &eax,reset flag(EAX) invoke int3
& & int& & 1h
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& &esp,4
& & cmp& & eax,0x; check the flag&&
& & je& & rt_label_int1
& & jmp& & rf_label_int1
& & mov& & eax,[esp+0x4];
& & mov& & ebx,dword ptr [eax];
& & mov& &eax,dword ptr [esp+0xc];EAX = ContextRecord
& & mov& & dword ptr [eax+0xb0],set flag (ContextRecord.EAX)
& & inc& &dword ptr [eax+0xb8];set ContextRecord.EIP
& & inc& &dword ptr [eax+0xb8];set ContextRecord.EIP
& & xor& &eax,eax
3.10 FV_VMWare_VMX
& & 这是一个针对VMWare虚拟机仿真环境的反调试，我从网上直接拷贝的代码。
& & VMWARE提供一种主机和客户机之间的通信方法，这可以被用做一种VMWare的反调试。Vmware将会处理IN （端口为0x5658/’VX’）指令，它会返回一个majic数值“VMXh”到EBX中。
& & 当在保护模式操作系统的3环下运行时，IN指令的执行将会产生一个异常，除非我们修改了I/O的优先级等级。然而，如果在VMWare下运行，将不会产生任何异常，同时EBX寄存器将会包含’VMXh’，ECX寄存器也会被修改为Vmware的产品ID。
& & 这种技巧在一些病毒中比较常用。
& & 针对VME的反调试，在peter Ferrie的另一篇文章&&Attacks on More Virtual Machine Emulators&&中有大量的描述，有兴趣的可以根据这篇文章，将FV_反调试好好丰富一下。
bool IsInsideVMWare_()
& & push& &edx
& & push& &ecx
& & push& &ebx
& & mov& & eax, 'VMXh'
& & mov& & ebx, 0 // any value but MAGIC VALUE
& & mov& & ecx, 10 // get VMWare version
& & mov& & edx, 'VX' // port number
& & in& &&&eax, dx // read port
& && && && && && & // on return EAX returns the VERSION
& & cmp& & ebx, 'VMXh' // is it a reply from VMWare?
& & setz& &[r] // set return value
& & pop& & ebx
& & pop& & ecx
& & pop& & edx
bool FV_VMWare_VMX()
& & return IsInsideVMWare_();
&&__except(1) // 1 = EXCEPTION_EXECUTE_HANDLER
3.11 FV_VPC_Exception
& & 这个代码我也是完整从网上拷贝下来的，具体原理在&&Attacks on More Virtual Machine Emulators&&这篇文章里也有详细描述。与VMWare使用一个特殊端口完成主机和客户机间通信的方法类似的是，VirtualPC靠执行非法指令产生一个异常供内核捕获。这个代码如下：
0F 3F x1 x20F C7 C8 y1 y2
& & 由这两个非法指令引起的异常将会被应用程序捕获，然而，如果VirtualPC正在运行，将不会产生异常。X1,x2的允许的数值还不知道，但有一部分已知可以使用，如0A 00,11 00…等等。
__declspec(naked) bool FV_VPC_Exception()
& & push ebp
& & mov&&ebp, esp
& & mov&&ecx, offset exception_handler
& & push ebx
& & push ecx
& & push dword ptr fs:[0]
& & mov&&dword ptr fs:[0], esp
& & mov&&ebx, 0 // Flag
& & mov&&eax, 1 // VPC function number
& & // call VPC&&
& &_asm __emit 0Fh
& &_asm __emit 3Fh
& &_asm __emit 07h
& &_asm __emit 0Bh
& & mov eax, dword ptr ss:[esp]
& & mov dword ptr fs:[0], eax
& & add esp, 8
& & test ebx, ebx
& & setz al
& & lea esp, dword ptr ss:[ebp-4]
& & mov ebx, dword ptr ss:[esp]
& & mov ebp, dword ptr ss:[esp+4]
& & add esp, 8
& & jmp ret1
exception_handler:
& & mov ecx, [esp+0Ch]
& & mov dword ptr [ecx+0A4h], -1 // EBX = -1 -& not running, ebx = 0 -& running
& & add dword ptr [ecx+0B8h], 4 // -& skip past the call to VPC
& & xor eax, eax // exception is handled
3.12 FV_VME_RedPill
& & 这个方法似乎是检测虚拟机的一个简单有效的方法，虽然还不能确定它是否是100%有效。名字很有意思，红色药丸（为什么不是bluepill,哈哈）。我在网上找到了个ppt专门介绍这个方法，可惜现在翻不到了。记忆中原理是这样的，主要检测IDT的数值，如果这个数值超过了某个数值，我们就可以认为应用程序处于虚拟环境中，似乎这个方法在多CPU的机器中并不可靠。据称ScoobyDoo方法是RedPill的升级版。代码也是在网上找的，做了点小改动。有四种返回结果，可以确认是VMWare，还是VirtualPC，还是其它VME，或是没有处于VME中。
& &//return value:&&0:none,1:2:3thers
& &unsigned char matrix[6];
& & unsigned char redpill[] =&&
& && &&&&\x0f\x01\x0d\x00\x00\x00\x00\xc3&;
& & HANDLE hProcess = GetCurrentProcess();
& & LPVOID lpAddress = NULL;
& & PDWORD lpflOldProtect = NULL;
& && &&&*((unsigned*)&redpill[3]) = (unsigned)
& && &&&lpAddress = VirtualAllocEx(hProcess, NULL, 6, MEM_RESERVE|MEM_COMMIT , PAGE_EXECUTE_READWRITE);
& && &&&if(lpAddress == NULL)
& && && && &return 0;
& && &&&BOOL success = VirtualProtectEx(hProcess, lpAddress, 6, PAGE_EXECUTE_READWRITE , lpflOldProtect);
& && &&&if(success != 0)
& && && && & return 0;
& && &&&memcpy(lpAddress, redpill, 8);
& && &&&((void(*)())lpAddress)();
& && &&&if (matrix[5]&0xd0)&&
& && && & if(matrix[5]==0xff)//vmvare
& && && && &return 1;
& && && & else if(matrix[5]==0xe8)//vitualpc
& && && && &return 2;
& && && & else
& && && && &return 3;
& && &&&else&&
& && && && &return 0;
& & __finally
& && &&&VirtualFreeEx(hProcess, lpAddress, 0, MEM_RELEASE);
四、&&检测-断点(FB_)
这一部分内容较少，但实际上可用的方法也比较多，我没有深入研究，不敢乱写，照抄了几个常用的方法：
//find breakpoint
bool FB_HWBP_Exception();
DWORD FB_SWBP_Memory_CRC();
bool FB_SWBP_ScanCC(BYTE * addr,int len);
bool FB_SWBP_CheckSum_Thread(BYTE *addr_begin,BYTE *addr_end,DWORD sumValue);
4.1 FB_HWBP_Exception
&&在异常处理程序中检测硬件断点，是比较常用的硬件断点检测方法。在很多地方都有提到。
& & push& &offset exeception_ set exception handler
& & push& &dword ptr fs:[0h]
& & mov& & dword ptr fs:[0h],esp& &
& & xor& & eax,reset EAX invoke int3
& & int& & 1h
& & pop& & dword ptr fs:[0h];restore exception handler
& & add& & esp,4
& & ;test if EAX was updated (breakpoint identified)&&
& & test& &eax,eax
& & jnz& &&&rt_label
& & jmp& & rf_label
exeception_handler:
& & ;EAX = CONTEXT record
& & mov& &&&eax,dword ptr [esp+0xc]
& & ;check if Debug Registers Context.Dr0-Dr3 is not zero
& & cmp& &&&dword ptr [eax+0x04],0
& & jne& &&&hardware_bp_found
& & cmp& &&&dword ptr [eax+0x08],0
& & jne& &&&hardware_bp_found
& & cmp& &&&dword ptr [eax+0x0c],0
& & jne& &&&hardware_bp_found
& & cmp& &&&dword ptr [eax+0x10],0
& & jne& &&&hardware_bp_found
& & jmp& &&&exception_ret
hardware_bp_found:
& & ;set Context.EAX to signal breakpoint found
& & mov& &&&dword ptr [eax+0xb0],0xFFFFFFFF
exception_ret:
& & ;set Context.EIP upon return
& & inc& && & dword ptr [eax+0xb8];set ContextRecord.EIP
& & inc& && & dword ptr [eax+0xb8];set ContextRecord.EIP
& & xor& &&&eax,eax
4.2 FB_SWBP_Memory_CRC()
&&由于在一些常用调试器中，比如OD，其是将代码设置为0xcc来实现普通断点，因此当一段代码被设置了普通断点，则其中必定有代码的修改。因此对关键代码进行CRC校验则可以实现侦测普通断点。但麻烦的是每次代码修改，或更换编译环境，都要重新设置CRC校验值。
&&下面的代码拷贝自《软件加解密技术》，里面完成的是对整个代码段的CRC校验，CRC校验值保存在数据段。CRC32算法实现代码网上有很多，就不列出来了。
DWORD FB_SWBP_Memory_CRC()
&&//打开文件以获得文件的大小
&&DWORD fileSize,NumberOfBytesRW;
&&DWORD CodeSectionRVA,CodeSectionSize,NumberOfRvaAndSizes,DataDirectorySize,ImageB
&&BYTE* pMZ
&&DWORD pPEheaderRVA;
&&TCHAR&&*pB
&&TCHAR szFileName[MAX_PATH];&&
&&GetModuleFileName(NULL,szFileName,MAX_PATH);
&&//打开文件
&&HANDLE hFile = CreateFile(
& & szFileName,
& & GENERIC_READ,
& & FILE_SHARE_READ,&&
& & OPEN_EXISTING,
& & FILE_ATTRIBUTE_NORMAL,
& & NULL);
& &if ( hFile != INVALID_HANDLE_VALUE )
& & //获得文件长度 :
& & fileSize = GetFileSize(hFile,NULL);
& & if (fileSize == 0xFFFFFFFF) return 0;
& & pBuffer = new TCHAR [fileSize];& &&&//// 申请内存,也可用VirtualAlloc等函数申请内存
& & ReadFile(hFile,pBuffer, fileSize, &NumberOfBytesRW, NULL);//读取文件内容
& & CloseHandle(hFile);&&//关闭文件
& &&&return 0;
&&pMZheader=(BYTE*)pB //此时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));///得到代码块的内存大小
&&delete pB&&// 释放内存
&&return CRC32((BYTE*)(CodeSectionRVA+ImageBase),CodeSectionSize);
4.3 FB_SWBP_ScanCC
扫描CC的方法，比照前面校验代码CRC数值的方法更直接一些，它直接在所要检测的代码区域内检测是否有代码被更改为0xCC，0xcc对应汇编指令为int3 ,对一些常用的调试器(如OD)其普通断点就是通过修改代码为int3来实现的。但使用时要注意是否正常代码中就包含CC。通常这个方法用于扫描API函数的前几个字节，比如检测常用的MessageBoxA、GetDlgItemTextA等。
bool FB_SWBP_ScanCC(BYTE * addr,int len)
&&FARPROC Func_
&&HMODULE hModule = GetModuleHandle(&USER32.dll&);&&
&&(FARPROC&) Func_addr =GetProcAddress ( hModule, &MessageBoxA&);
&&if (addr==NULL)
& & addr=(BYTE *)Func_//for test
&&BYTE tmpB;
& & for(i=0;i&i++,addr++)
& && &tmpB=*
& && &tmpB=tmpB^0x55;
& && &if(tmpB==0x99)// cmp 0xcc
&&__except(1)
4.4 FB_SWBP_CheckSum_Thread(BYTE *addr_begin,BYTE *addr_end,DWORD sumValue);
此方法类似CRC的方法，只是这里是检测累加和。它与CRC的方法有同样的问题，就是要在编译后，计算累加和的数值，再将该值保存到数据区，重新编译。在这里创建了一个单独的线程用来监视代码段。
DWORD WINAPI CheckSum_ThreadFunc( LPVOID lpParam )&&
&&DWORD dwThrdParam[3];
&&BYTE tmpB;
&&DWORD Value=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];
&&DWORD sumValue=dwThrdParam[2];
&&for(int i=0;i&(addr_end-addr_begin);i++)
& & Value=Value+*(addr_begin+i);
&&/* //if sumvalue is const,it should be substract.
&&DWORD tmpV
&&Value=Value-(sumValue&0x000000FF);
&&tmpValue=(sumValue&0x0000FF00)&&8;
&&Value=Value-tmpV
&&tmpValue=(sumValue&0x0000FF00)&&16;
&&Value=Value-tmpV
&&tmpValue=(sumValue&0x0000FF00)&&24;
&&Value=Value-tmpV*/
&&if (Value!=sumValue)
& & MessageBox(NULL,&SWBP is found by CheckSum_ThreadFunc&,&CheckSum_ThreadFunc&,MB_OK|MB_ICONSTOP);
& & return 1;&&
bool FB_SWBP_CheckSum_Thread(BYTE *addr_begin,BYTE *addr_end,DWORD sumValue)
& & DWORD dwThreadId;
&&DWORD dwThrdParam[3];
&&dwThrdParam[0]=(DWORD)addr_
&&dwThrdParam[1]=(DWORD)addr_
&&dwThrdParam[2]=sumV
& & HANDLE hT&&
& & hThread = CreateThread(&&
& && &&&NULL,& && && && && && && && &// default security attributes&&
& && &&&0,& && && && && && && && && &// use default stack size& &
& && &&&CheckSum_ThreadFunc,& && && &// thread function&&
& && &&&&dwThrdParam[0],& && && && && & // argument to thread function&&
& && &&&0,& && && && && && && && && &// use default creation flags&&
& && &&&&dwThreadId);& && && && && & // returns the thread identifier&&
& & // Check the return value for success.&&
& &if (hThread == NULL)&&
& && &Sleep(1000);
& && &CloseHandle( hThread );
五、&&检测-跟踪(FT_)
个人认为，反跟踪的一些技巧，多数不会非常有效，因为在调试时，多数不会被跟踪经过，除非用高超的技巧将关键代码和垃圾代码及这些反跟踪技巧融合在一起，否则很容易被发现或被无意中跳过。
函数列表如下：
//Find Single-Step or Trace
bool FT_PushSS_PopSS();
void FT_RDTSC(unsigned int * time);
DWORD FT_GetTickCount();
DWORD FT_SharedUserData_TickCount();
DWORD FT_timeGetTime();
LONGLONG FT_QueryPerformanceCounter(LARGE_INTEGER *lpPerformanceCount);
bool FT_F1_IceBreakpoint();
bool FT_Prefetch_queue_nop1();
bool FT_Prefetch_queue_nop2();
5.1 FT_PushSS_PopSS
这个反调试在&&windows anti-debug reference&&里有描述，如果调试器跟踪经过下面的指令序列：
& & push ss& & //反跟踪指令序列
& & pop&&ss& & //反跟踪指令序列
& & pushf& & //反跟踪指令序列
& & pop eax& & //反跟踪指令序列
Pushf将会被执行，同时调试器无法设置压进堆栈的陷阱标志，应用程序通过检测陷阱标志就可以判断处是否被跟踪调试。
& & push ebp
& & mov ebp,esp
& & push ss& & //反跟踪指令序列
& & pop&&ss& & //反跟踪指令序列
& & pushf& & //反跟踪指令序列
& & pop eax& & //反跟踪指令序列
& & and&&eax,0x
& & jnz&&rt_label
& & xor eax,eax
& & mov esp,ebp
& & pop ebp
& & xor eax,eax
& & inc eax
& & mov esp,ebp
& & pop ebp
5.2 FT_RDTSC
通过检测某段程序执行的时间间隔，可以判断出程序是否被跟踪调试，被跟踪调试的代码通常都有较大的时间延迟，检测时间间隔的方法有很多种。比如RDTSC指令，kernel32_GetTickCount函数，winmm_ timeGetTime 函数等等。
下面为RDTSC的实现代码。
&&int time_low,time_
& & mov& & time_low,eax
& & mov& & time_high,edx
5.3 FT_GetTickCount
&&GetTickCount函数检测时间间隔简单且常用。直接调用即可。具体可查MSDN。
5.4 FT_SharedUserData_TickCount
&&直接调用GetTickCount函数来检测时间间隔的方法，虽然简单却容易被发现。而使用GetTickCount的内部实现代码，直接读取SharedUserData数据结构里的数据的方法，更隐蔽些。下面的代码是直接从GetTickCount里扣出来的，其应该是在位于0x7FFE0000地址处的SharedUserData数据接口里面直接取数据，不过这个代码应该有跨平台的问题，我这里没有处理。大家可以完善下。
&&DWORD tmpD;
& & mov& &&&edx, 0x7FFE0000
& & mov& &&&eax, dword ptr [edx]
& & mul& &&&dword ptr [edx+4]
& & shrd& & eax, edx, 0x18
& & mov& & tmpD,eax
&&return tmpD;
5.5 FT_timeGetTime
&&使用winmm里的timeGetTime的方法也可以用来检测时间间隔。直接调用这个函数即可。具体可查MSDN。
5.6 FT_QueryPerformanceCounter
&&这是一种高精度时间计数器的方法，它的检测刻度最小，更精确。
&&if(QueryPerformanceCounter(lpPerformanceCount))
& && &&&return lpPerformanceCount-&QuadP
& &&&return 0;
5.7 FT_F1_IceBreakpoint
&&在&&Windows anti-debug reference&&中有讲述这个反跟踪技巧。这个所谓的&Ice breakpoint& 是Intel 未公开的指令之一, 机器码为0xF1.执行这个指令将产生单步异常.,如果程序已经被跟踪, 调试器将会以为它是通过设置标志寄存器中的单步标志位生成的正常异常. 相关的异常处理器将不会被执行到.下面是我的实现代码：
&&push& &offset eh_f1; set exception handler
& &&&push&&dword ptr fs:[0h]
& &&&mov& & dword ptr fs:[0h],esp& &
& &&&xor& &eax,reset EAX invoke int3
& &&&_emit 0xf1
& &&&pop& & dword ptr fs:[0h];restore exception handler
& &&&add& & esp,4
&&test&&eax,eax
&&jz& & rt_label_f1
&&jmp& & rf_label_f1
& &&&mov eax,dword ptr[esp+0xc]
&&mov& & dword ptr [eax+0xb0],0x;set flag (ContextRecord.EAX)
& &&&inc dword ptr [eax+0xb8]
& &&&xor eax,eax
rt_label_f1:
&&inc& & eax
&&mov& & esp,ebp
& &&&pop& & ebp
rf_label_f1:
&&xor& & eax,eax
&&mov& & esp,ebp
& &&&pop& & ebp
5.8 FT_Prefetch_queue_nop1
这个反调试是在&&ANTI-UNPACKER TRICKS&&中给出的，它主要是基于REP指令，通过REP指令来修改自身代码，在非调试态下，计算机会将该指令完整取过来，因此可以正确的执行REP这个指令，将自身代码完整修改，但在调试态下，则在修改自身的时候立即跳出。
这个反跟踪技巧个人觉得用处不大，因为只有在REP指令上使用F7单步时，才会触发这个反跟踪，而我个人在碰到REP时，通常都是F8步过。下面是利用这个CPU预取指令的特性的实现反跟踪的一种方法，正常情况下，REP指令会修改其后的跳转指令，进入正常的程序流程，但在调试态下，其无法完成对其后代码的修改，从而实现反调试。
& &DWORD oldP
& &DWORD tmpP
& & lea eax,dword ptr[oldProtect]
& & push eax
& & push 0x40
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & mov al,0x90
& & push 0x10
& & pop ecx
& & mov edi,offset label3
& & rep stosb
& & jmp rt_label
& & ;write back
& & mov dword ptr[label3],0x106a90b0
& & mov dword ptr[label3+0x4],0x205CBF59
& & mov dword ptr[label3+0x8],0xAAF30040
& & mov dword ptr[label3+0xc],0x
& & mov dword ptr[label3+0x6],offset label3
& & lea eax, dword ptr[tmpProtect];
& & ;restore protect
& & push eax
& & push oldProtect
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & xor eax,eax
& & mov esp,ebp
& & pop ebp
& & ;write back
& & mov dword ptr[label3],0x106a90b0
& & mov dword ptr[label3+0x4],0x205CBF59
& & mov dword ptr[label3+0x8],0xAAF30040
& & mov dword ptr[label3+0xc],0x
& & mov dword ptr[label3+0x6],offset label3
& & lea eax, dword ptr[tmpProtect];
& & ;restore protect
& & push eax
& & push oldProtect
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & xor eax,eax
& & inc eax
& & mov esp,ebp
& & pop ebp
5.9 FT_Prefetch_queue_nop2
&&与5.8节类似，这是根据CPU预取指令的这个特性实现的另一种反跟踪技巧。原理是通过检测REP指令后的ECX值，来判断REP指令是否被完整执行。在正常情况下，REP指令完整执行后，ECX值应为0；但在调试态下，由于REP指令没有完整执行，ECX值为非0值。通过检测ECX值，实现反跟踪。
&&DWORD oldP
&&DWORD tmpP
& & lea eax,dword ptr[oldProtect]
& & push eax
& & push 0x40
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & mov ecx,0
& & mov al,0x90
& & push 0x10
& & pop ecx
& & mov edi,offset label3
& & rep stosb
& & push ecx
& & ;write back
& & mov dword ptr[label3],0x106a90b0
& & mov dword ptr[label3+0x4],0x201CBF59
& & mov dword ptr[label3+0x8],0xAAF30040
& & mov dword ptr[label3+0xc],0x
& & mov dword ptr[label3+0x6],offset label3
& & lea eax, dword ptr[tmpProtect];
& & ;restore protect
& & push eax
& & push oldProtect
& & push 0x10
& & push offset label3;
& & call dword ptr [VirtualProtect];
& & pop ecx
& & test ecx,ecx
& & jne rt_label
六、&&检测-补丁(FP_)
这部分内容也较少，方法当然也有很多种，原理都差不多，我只选了下面三种。这几种方法通常在一些壳中较常用，用于检验文件是否被脱壳或被恶意修改。
函数列表如下：
//find Patch
bool FP_Check_FileSize(DWORD Size);
bool FP_Check_FileHashValue_CRC(DWORD CRCVALUE_origin);
bool FP_Check_FileHashValue_MD5(DWORD MD5VALUE_origin);
6.1 FP_Check_FileSize(DWORD Size)
&&通过检验文件自身的大小的方法，是一种比较简单的文件校验方法，通常如果被脱壳，或被恶意修改，就可能影响到文件的大小。我用下面的代码实现。需注意的是，文件的大小要先编译一次，将首次编译得到的数值写入代码，再重新编译完成。
&&DWORD Current_S
&&TCHAR szPath[MAX_PATH];
&&HANDLE hF
&&if( !GetModuleFileName( NULL,szPath, MAX_PATH ) )
& && &&&return FALSE;
&&hFile = CreateFile(szPath,&&
& & GENERIC_READ ,
& & FILE_SHARE_READ,&&
& & OPEN_ALWAYS,&&
& & FILE_ATTRIBUTE_NORMAL,&&
& & NULL);
&&if (hFile == INVALID_HANDLE_VALUE)
&&Current_Size=GetFileSize(hFile,NULL);
&&CloseHandle(hFile);
&&if(Current_Size!=Size)
6.2 FP_Check_FileHashValue_CRC
&&检验文件的CRC数值，是比较常用的文件校验方法，相信很多人都碰到过了，我是在《软件加解密技术》中了解到的。需注意的是文件原始CRC值的获得，及其放置位置，代码编写完成后，通常先运行一遍程序，使用调试工具获得计算得到的数值，在将这个数值写入文件中，通常这个数值不参加校验，可以放置在文件的尾部作为附加数据，也可以放在PE头中不用的域中。
&&下面的代码只是个演示，没有保存CRC的真实数值，也没有单独存放。
&&DWORD fileSize,NumberOfBytesRW;
&&DWORD CRCVALUE_
&&TCHAR szFileName[MAX_PATH];&&
&&TCHAR&&*pB
&&GetModuleFileName(NULL,szFileName,MAX_PATH);
&&HANDLE hFile = CreateFile(
& & szFileName,
& & GENERIC_READ,
& & FILE_SHARE_READ,&&
& & OPEN_EXISTING,
& & FILE_ATTRIBUTE_NORMAL,
& & NULL);
&&if (hFile != INVALID_HANDLE_VALUE )
& & fileSize = GetFileSize(hFile,NULL);
& & if (fileSize == 0xFFFFFFFF)
& & pBuffer = new TCHAR [fileSize];& &
& & ReadFile(hFile,pBuffer, fileSize, &NumberOfBytesRW, NULL);
& & CloseHandle(hFile);
&&CRCVALUE_current=CRC32((BYTE *)pBuffer,fileSize);
&&if(CRCVALUE_origin!=CRCVALUE_current)
联系我时，请说是在 外挂海论坛 上看到的，谢谢！
上一篇：下一篇：
阅读权限20
在线时间4 小时
积分主题听众
太强大了。佩服啊
阅读权限30
在线时间8 小时
积分主题听众
高手云集 马上来看看
阅读权限40
在线时间10 小时
积分主题听众
看完了 回复一下 不知道说什么
Powered by Discuz! X3.2
Comsenz Inc.}
我要回帖
更多关于 编译安装php5.6 的文章
更多推荐
- ·王成琪电视剧《追日全部演员表》原型
- ·海贼王天龙人二十个姓氏有哪些
- ·风水玄学自学入门零基础知识
- ·如何联系电商平台电话系统的客服？
- ·美册视频属于原创吗编辑软件为啥打不开？
- ·小米平板换屏幕多少钱2屏幕裂缝了，是要换外屏还是连总成一起换
- ·bc：3a：ea：4a：73：79这是一个什么手机的mac
- ·大家帮我看看，我这显卡能玩守望先锋显卡设置吗
- ·电竞游戏的开发者，为什么却不是游戏比赛冠军电竞经理游戏
- ·怎么查找陌陌如何查找聊天记录用户“挑战极限，创造奇迹”
- ·求大神，用谷歌浏览器双开三国杀双开不同ip怎么弄
- ·如何注册网络传媒公司文化传播公司
- ·联想ma388价格怎么样？联想ma388价格好吗
- ·google talkback手势
- ·我用了TPtplink无线路由器网址后上网变慢了怎么回事
- ·万达电商 您好登录！请问澳 =门vns官网如何正确引用功能设置？
- ·marmot nanopro是macbookpro涂层脱落还是薄膜
- ·真心求教 高阶祭司伊克赞的无线电我怎么找也找不到
- ·微信扫微信付款二维码被骗支付转账发现被骗了怎么办
- ·微软AX 在删除总账记账上年结转中一日记账后 再做凭证时发现凭证号码不连续，怎么回事 如何解决？
- ·怎么重新编译安装php5.6CE5.6
- ·达州市优程电子商务是干什么的有限公司怎么样，好不好？
- ·硬盘录像机怎么连接拾音器 连接 方法以及功放教程
- ·怎样在基于MFC单文档的vc6.0mfc串口通信信中遍历串口号
- ·为什么会取消关注微信公众平台取消关注号
- ·天津苹果macbook开机切换系统不开机系统安装多少钱
- ·微软vr头盔发布会又一神作，甩什么VR几条街了
- ·看来吧里的软件贴 把Xbox卸载了，xbox怎么卸载弄回来
- ·电脑被儿童锁电脑锁住了怎么解锁,打不开怎么办?
- ·网络慈善中的信任危机精准扶贫为主题议论文的议论文
- ·苹果5s屏幕重影抖动火爆抖屏软件下载
- ·求告知哪个听书软件能听无限恐怖 无限未来txt下载和无限曙光
- ·新买的电脑笔记本突然蓝屏屏是怎么回事
- ·android百度地图android 加载离线地图图可以多个开发app共用吗
- ·处了csdn mfc blog以外,还有什么地方可以提问mfc,VC++代码问题
- ·有没有读硬盘ID号api 取cpu序列号号之类的API，是什么，怎么用
