在win7 64位机子里，autohotkey转成exe了，也用管理员身份运行了，但是游戏里就是没反应。求高手相助。

被游戏拦截了，解决方法有3个，要么做过检的程序，要么把ahk 伪装成真实键盘工作，最后就是用游戏键盘自带的脚本功能了,找一找罗技的不过功能就比ahk少很多，而且经常突然启动脚本，关都没法关，只能按电源关机，前两个太难了实在搞不了，现在妥协在第3个。

客户机端 服务器端

======== ========

监听套接字 连接套接字

========== ==========

socket() socket()

bind() bind()

listen()

connect()----->accept()------>创建连接套接字

send()----------------------->recv()

recv()<-----------------------send()

.

.

.

closesocket() closesocket() closesocket()

我们可以看出，是客户机端的connect()执行实际的连接请求动作，我们再来看看connect函数的参数：

int connect(

SOCKET s, // 指定对哪个套接字进行 *** 作

const struct sockaddr FAR *name, // 这是一个描述服务器IP地址的结构

int namelen // 指明上面这个结构的大小

)

对于name参数，由于sockaddr结构内容依赖于具体的协议，所以对于TCP/IP协议，我们传递sockaddr_in这个结构，再来看看这个结构：

struct sockaddr_in{

short sin_family// 必须为AF_INET

unsigned short sin_port// IP端口号

struct in_addr sin_addr// 标识IP地址的一个结构体

charsin_zero[8]// 为了兼容sockaddr而设置的占位空间

}

到这儿，我们可以看出，对于一次连接请求的目的地信息，已经全部在传入的参数中描述清楚了，接下来要做的就设置一个全局API钩子，钩住所有程序的connect()调用，在进行实际的connect() *** 作之前，我们先分析传入的参数，如果发现连接目的地是我们不允许访问的，就不进行连接 *** 作，仅返回一个错误码就可以了。就这么简单，就能实现一夫当关，万夫莫开的效果。

同样的道理，也可以Hook其它函数而实现监控整个网络通讯各方面的内容，比如说截取发送和接收的数据包进行分析等等，这就取决于设计者的意图了，大家不妨动手试试看，感受一下Hook API的魅力。

Hook Win32 API 的应用研究之二：进程防杀

在WINDOWS *** 作系统下，当我们无法结束或者不知道怎样结束一个程序的时候，或者是懒得去找“退出”按钮的时候，通常会按“CTRL+ALT+DEL”呼出任务管理器，找到想结束的程序，点一下“结束任务”就了事了，呵呵，虽然有点粗鲁，但大多数情况下都很有效，不是吗？

设想一下，如果有这么一种软件，它所要做的工作就是对某个使用者在某台电脑上的活动作一定的限制，而又不能被使用者通过“结束任务”这种方式轻易地解除限制，那该怎么做？无非有这么三种方法：1.屏蔽“CTRL+ALT+DEL”这个热键的组合；2.让程序不出现在任务管理器的列表之中；3.让任务管理器无法杀掉这个任务。对于第一种方法，这样未免也太残酷了，用惯了“结束任务”这种方法的人会很不习惯的；对于第二址椒ǎ赪INDOWS 9X下可以很轻易地使用注册服务进程的方法实现，但是对于WINDOWS NT架构的 *** 作系统没有这个方法了，进程很难藏身，虽然仍然可以实现隐藏，但实现机制较为复杂；对于第三种方法，实现起来比较简单，我的作品：IPGate 网址过滤器 就是采用的这种方式防杀的，接下来我就来介绍这种方法。

任务管理器的“结束任务”实际上就是强制终止进程，它所使用的杀手锏是一个叫做TerminateProcess()的Win32 API函数，我们来看看它的定义：

BOOL TerminateProcess(

HANDLE hProcess// 将被结束进程的句柄

UINTuExitCode// 指定进程的退出码

)

看到这里，是不是觉得不必往下看都知道接下来要做什么：Hook TerminateProcess()函数，每次TerminateProcess()被调用的时候先判断企图结束的进程是否是我的进程，如果是的话就简单地返回一个错误码就可以了。真的是这么简单吗？先提出一个问题，如何根据hProcess判断它是否是我的进程的句柄？答案是：在我的进程当中先获得我的进程的句柄，然后通过进程间通讯机制传递给钩子函数，与hProcess进行比较不就行了？错！因为句柄是一个进程相关的值，不同进程中得到的我的进程的句柄的值在进程间进行比较是无意义的。

怎么办？我们来考察一下我的hProcess它是如何得到的。一个进程只有它的进程ID是独一无二的， *** 作系统通过进程ID来标识一个进程，当某个程序要对这个进程进行访问的话，它首先得用OpenProcess这个函数并传入要访问的进程ID来获得进程的句柄，来看看它的参数：

HANDLE OpenProcess(

DWORD dwDesiredAccess, // 希望获得的访问权限

BOOL bInheritHandle, // 指明是否希望所获得的句柄可以继承

DWORD dwProcessId // 要访问的进程ID

)

脉络渐渐显现：在调用TerminateProcess()之前，必先调用OpenProcess()，而OpenProcess()的参数表中的dwProcessId是在系统范围内唯一确定的。得出结论：要Hook的函数不是TerminateProcess()而是OpenProcess()，在每次调用OpenProcess()的时候，我们先检查dwProcessId是否为我的进程的ID(利用进程间通讯机制)，如果是的话就简单地返回一个错误码就可以了，任务管理器拿不到我的进程的句柄，它如何结束我的进程呢？

至此，疑团全部揭开了。由Hook TerminateProcess()到Hook OpenProcess()的这个过程，体现了一个逆向思维的思想。其实我当初钻进了TerminateProcess()的死胡同里半天出也不来，但最终还是蹦出了灵感的火花，注意力转移到了OpenProcess()上面，实现了进程防杀。喜悦之余，将这心得体会拿出来与大家分享。

Hook Win32 API 的应用研究之三：变速控制 <<<

这是Hook Win32 API的一个比较另类和有趣的应用方面。

这里所指的变速控制，并不是说可以改变任何程序的运行速度，只能改变符合这些条件的程序的运行速度：程序的运行速度依赖于定时控制，也就是说，程序的执行单元执行的频率是人为的依靠定时机制控制的，不是依赖于CPU的快慢。比如说，某个程序每隔1秒钟发出“滴答”声，它在快的电脑上和慢的电脑上所表现出来的行为是一致的。这样的依赖于定时控制的程序才是我们的研究“变速”对象。

一个WINDOWS应用程序的定时机制有很多。像上面提到的例子程序可以采用WM_TIMER消息来实现，通过函数SetTimer()可以设定产生WM_TIMER消息的时间间隔。其它的方法还有通过GetTickCount()和timeGetTime()等函数得到系统时间，然后通过比较时间间隔来定时，还有timerSetEvent()设置时钟事件等等方式。先来看看这些函数的定义：

UINT_PTR SetTimer(

HWND hWnd, // 接收WM_TIMER消息的窗口句柄

UINT_PTR nIDEvent, // 定时器的ID号

UINT uElapse, // 发生WM_TIMER消息的时间间隔

TIMERPROC lpTimerProc // 处理定时发生时的回调函数入口地址

)

MMRESULT timeSetEvent(

UINT uDelay, // 时钟事件发生的时间间隔

UINT uResolution, // 设置时钟事件的分辨率

LPTIMERCALLBACKlpTimerProc, // 处理时钟事件发生时的回调函数入口地址

DWORD dwUser, // 没峁┑幕氐魇?br /> UINT fuEvent // 设置事件的类型

)

DWORD GetTickCount(VOID) // 返回系统启动以来经过了多少毫秒了

DWORD timeGetTime(VOID) // 类似于GetTickCount()，但分辨率更高

那么我们来看，如果能控制SetTimer()的uElapse参数、timeSetEvent()的uDelay参数、GetTickCount()和timeGetTime()的返回值，就能实现变速控制，除非应用程序使用的是其它的定时机制，不过大多数应用程序采用的定时机制不外乎都是这些。

该轮到Hook大法出场了。因为我们一般只想改变某个程序的速度，比如是说某个游戏程序，所以我们不设置全局钩子。又因为我们不清楚那个应用程序到底使用的是那种定时机制，所以上述几个函数我们全部都要接管，然后把关于定时参数或返回值按比例缩放就可以了。

---