久久久久九国产精品,中文字幕无码免费久久,18禁黄久久久AAA片

[转蝲]windows消息分流�?

saga.constantine — Tue, 04 Sep 2007 05:40:00 GMT

**转蝲**
自己看核心编�E�，�Ҏ��息分��器不太理解�Q�这��写的不错，所以�{载�?br>文章作者：�ƣ欣
原文链接�Q?a >http://blog.csdn.net/hopkins9961629/archive/2006/01/25/588184.aspx

很好理解,windows操作�pȝ��使用消息处理机制,那么,我们所设计的程序如何才能分辨和处理�pȝ��中的各种消息�?�q�就是消息分��器的作�?

��单来�?消息分流器就是一�D�代�?在我的讲�q�C��,��分7重来循序渐进的介�l�它.从最初的�W?重到最成熟的第7�?它的样子会有很大的变�?�?实现的功能都是一��L��,所不同�?仅仅是变得更加简�l��Ş�?

�E�序开始时�?会是main函数,然后会生成初始的�H�口,同时会调用WndProc函数.�q�是一个自定义的函�?名字也会有变�?但其功能是一��L��,��是�q�行消息分流�?WndProc函数如下:

LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,WPARAM wParam, LPARAM lParam)
{

//......

return DefWindowProc(hwnd, msg, wParam, lParam);

}

�q�其�?hwnd是窗口的句柄,msg是系�l�发送来的消息的名字.wParam和lParam则是随消息一起发送来的消息参�?

WndProc函数使用了消息分��器�Q�下面把消息分流器的内容解释一下：

一重，当不同的消息出现�Ӟ��在其中写入相应的�E�序语句卛_��?br>LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
  case WM_CREATE:
  // ...
  return 0;

  case WM_PAINT:
  // ...
  return 0;

  case WM_DESTROY:
  //...
  return 0;
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}

二重�Q�运用三个消息分��器�q�行处理�?br>LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CREATE:
return HANDLE_WM_CREATE(hwnd, wParam, lParam, Cls_OnCreate);

case WM_PAINT:
return HANDLE_WM_PAINT(hwnd, wParam, lParam, Cls_OnPaint);

case WM_DESTROY:
return HANDLE_WM_DESTROY(hwnd, wParam, lParam, Cls_OnDestroy);
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
�q�里的HANDLE_WM_CREATE�Q�HANDLE_WM_PAINT�Q�HANDLE_WM_DESTROY��是消息分流器�?br>与消息不同之处就是在前面增加�?#8220;HANDLE_”字符�Q�windows的消息分��器��是�q�样的模栗��?br>它的本质��是宏定义�?br>其中的四个参数有三个都是从本函数的入口参��C��直接得到的，即�ؓhwnd, wParam, lParam�?br>只有�W�四的参数是表明调用的函数�?br>消息分流器是在winowsx.h文�g中定义的。由此，可以看出�W�四个参数是调用的函敎ͼ�其定义如下：

#define HANDLE_WM_CREATE(hwnd, wParam, lParam, fn) ((fn)((hwnd), (LPCREATESTRUCT)(lParam)) ? 0L : (LRESULT)-1L)

#define HANDLE_WM_PAINT(hwnd, wParam, lParam, fn) ((fn)(hwnd), 0L)

#define HANDLE_WM_DESTROYCLIPBOARD(hwnd, wParam, lParam, fn) ((fn)(hwnd), 0L)

0L是表�C�int�c�d��的变量，其数��gؓ0�?br>int�c�d��Ӟ��可在后面加l或者L(��写和大写�Ş�?
表明无符��h��Ӟ��可在后面加u或者U(��写和大写�Ş�?
float�c�d��Ӟ��可在后面加f或者F(��写和大写�Ş�?
例如�Q?br>128u 1024UL 1L 8Lu 3.14159F 0.1f

LRESULT是一个系�l�的数据�c�d��Q�其定义如下�Q?br>typedef LONG_PTR LRESULT;

LONG_PTR也是一个系�l�的数据�c�d��Q�其定义如下�Q?br>#if defined(_WIN64)
typedef __int64 LONG_PTR;
#else
typedef long LONG_PTR;
#endif
由此可见�Q�LRESULT的实质就�?4的long�c�d��的变�?/p>

那么(LRESULT)-1L的实质�ƈ不是减法�Q�而是((LRESULT)(-1L))�Q�即强制�c�d��转换

三重�Q�把消息分流器的宏定义代换回去，��成了下面的样子
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
  case WM_CREATE:
  return Cls_OnCreate(hwnd, (LPCREATESTRUCT)(lParam)) ? 0L : (LRESULT)-1L;
  // 如果处理了消息，则Cls_OnCreate应返回TRUE�Q�导致WndProc�q�回0�Q�否则Cls_OnCreate�q�回FALSE�Q�导致WndProc�q�回-1�Q?/p>

  case WM_PAINT:
  return Cls_OnPaint(hwnd), 0L;
  // 逗号表达式；Cls_OnPaint是void�c�d��Q�这里返�?�Q?

case WM_DESTROY:
return Cls_OnDestroy(hwnd), 0L; // 同Cls_OnPaint
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
在逗号表达式，C++会计��每个表辑ּ��Q�但完整的逗号表达式的�l�果是最双��表达式的倹{�?br>所以，会return 0�?br>然后�Q�就可以手动的编写各个处理函��C��Q�Cls_OnCreate�Q�Cls_OnPaint�Q�WM_DESTROY�?/p>

四重�Q?br>LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
  HANDLE_MSG(hwnd, WM_CREATE, Cls_OnCreate);
  HANDLE_MSG(hwnd, WM_PAINT, Cls_OnPaint);
  HANDLE_MSG(hwnd, WM_DESTROY, Cls_OnDestroy);
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}

HANDLE_MSG也是一个宏�Q�它在windowsx.h中定义，如下�Q?br>#define HANDLE_MSG(hwnd, message, fn) case (message): return HANDLE_##message((hwnd), (wParam), (lParam), (fn))

�q�个宏要做的��是�Ҏ��不同的message�Q?#用来�q�接前后的字�W�串�Q�，把自�?#8220;变成”相应的HANDLE_XXXXMESSAGE形式的宏�Q�再通过相应的宏来执行消息处理代码�?br>说白了，��是把message的消息做为替换，##��是一个替换的标志�?br>如果没有##�Q�就成了HANDLE_message了，�q�样�Q�宏是不会被代换的�?br>如果��单独一个，则会代换�Q�如hwnd和fn�?/p>

比如实际代码中写入：
HANDLE_MSG(hwnd, WM_CREATE, Cls_OnCreate)
则经�q��{换就变成�Q?br>case (WM_CREATE): return HANDLE_WM_CREATE((hwnd), (wParam), (lParam), (Cls_OnCreate))
�q�与二重一模一栗��?/p>

以上四重�Q�是消息分离器的基本使用�Q�但�Q�这不完��_��消息分离器主要应用在对话框消息处理中�?br>�q�里�Q�窗口子�c�d��是我们经�怋�用的手段�Q�这也可以通过消息分流器实玎ͼ�

�W�五�?br>LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
HANDLE_MSG(hwnd, WM_INITDIALO , Cls_OnInitDialog); // 不能直接使用HANDLE_MSG�?br> HANDLE_MSG(hwnd, WM_COMMAND, Cls_OnCommand); // 不能直接使用HANDLE_MSG�?br> }
return false;
}
�׃��是窗口子�c�d��Q�所以，最后，�q�回的是false�Q�以表明�Q�如果没有约定响应的消息�Q?br>则返回父亲窗口false�Q�如果有�Q�则�q�回ture�Q�这是与前四重不同的地方�?br>一般情况下�Q�对话框�q�程函数应该在处理了消息的情况下�q�回TRUE�Q�如果没有处理，则返回FALSE�?br>如果对话框过�E�返回了FALSE�Q�那么对话框��理器�ؓ�q�条消息准备默认的对话操作�?/p>

但是�Q�这其中有错误，因�ؓ有的消息,需要单独处理。单独处理的消息列表见SetDlgMsgResult宏�?/p>

�W�六�?br>�q�点��问题，�q�就需要用到SetDlgMsgResult(hwnd, msg, result)宏�?

LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_INITDIALO:
return (SetDlgMsgResult(hwnd, Msg, HANDLE_WM_INITDIALO((hwnd), (wParam), (lParam), (fn)));

case WM_COMMAND:
return (SetDlgMsgResult(hwnd, Msg, HANDLE_WM_COMMAND((hwnd), (wParam), (lParam), (fn)));
}
return false;
}
�q�里�Q�就用直接用��C��W�二重的消息分流器，而抛弃了其他�?/p>

�q�个宏定义如下：
#define SetDlgMsgResult(hwnd, msg, result)
(
(
(msg) == WM_CTLCOLORMSGBOX ||
(msg) == WM_CTLCOLOREDIT ||
(msg) == WM_CTLCOLORLISTBOX ||
(msg) == WM_CTLCOLORBTN ||
(msg) == WM_CTLCOLORDLG ||
(msg) == WM_CTLCOLORSCROLLBAR ||
(msg) == WM_CTLCOLORSTATIC ||
(msg) == WM_COMPAREITEM ||
(msg) == WM_VKEYTOITEM ||
(msg) == WM_CHARTOITEM ||
(msg) == WM_QUERYDRAGICON ||
(msg) == WM_INITDIALOG
) ?
(BOOL)(result) :
(SetWindowLongPtr((hwnd), DWLP_MSGRESULT, (LPARAM)(LRESULT)(result)), TRUE)
)

��Z��表述清楚�Q�所以用了此格式�Q�这是一个三��表辑ּ��Q�首先对消息�c�d��q�行考察�?/p>

如果对话框过�E�处理的消息恰��y��回特定��g��的一个，则如实返回result�Q?br>不要被前面的BOOL蒙蔽�Q�BOOL在头文�g中的定义实际上是一个int型，
一旦需要返回非TRUE或FALSE的其他��|��照样可以�Q?/p>

�q�样�Q�我们的Cls_OnInitDialog��p��够正��的�q�回它的BOOL��g��Q?br>而Cls_OnCommand在处理之后，也可以由后面的逗号表达式正��的�q�回一个TRUE表示消息已处理�?/p>

�W�七�?br>我们�q�可以把case也包含进来，��成了如下的样子�?/p>

LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
chHANDLE_DLGMSG(hwnd, WM_INITDIALOG, Cls_OnInitDialog);
chHANDLE_DLGMSG(hwnd, WM_COMMAND, Cls_OnCommand);
}
return false;
}

chHANDLE_DLGMSG是牛人定义的一个宏�Q�它把case也包含进来了�?br>#define chHANDLE_DLGMSG(hwnd, message, fn) case (message): return (SetDlgMsgResult(hwnd, uMsg, HANDLE_##message((hwnd), (wParam), (lParam), (fn))))

�q�样�Q�程序中的语�?br> switch (uMsg)
{
  chHANDLE_DLGMSG(hwnd, WM_INITDIALOG, Dlg_OnInitDialog);
  chHANDLE_DLGMSG(hwnd, WM_SIZE,       Dlg_OnSize);
  chHANDLE_DLGMSG(hwnd, WM_COMMAND,    Dlg_OnCommand);
}

��p��译成：
switch (uMsg)
{
case (WM_INITDIALOG):
return (SetDlgMsgResult(hwnd, uMsg, HANDLE_WM_INITDIALOG((hwnd), (wParam), (lParam), (Dlg_OnInitDialog))));

case (WM_SIZE)
return (SetDlgMsgResult(hwnd, uMsg, HANDLE_WM_SIZE((hwnd), (wParam), (lParam), (Dlg_OnSize))));

case (WM_COMMAND)
return (SetDlgMsgResult(hwnd, uMsg, HANDLE_WM_COMMAND((hwnd), (wParam), (lParam), (Dlg_OnCommand))));
}

�q�样,消息分流�?��׃��l�完�?

saga.constantine 2007-09-04 13:40 发表评论

saga.constantine — Tue, 19 Jun 2007 15:46:00 GMT

在C++中，有一个stream�q�个�c�，所有的I/O都以�q�个“��?#8221;�c�Mؓ基础的，包括我们要认识的文�gI/O�Q�stream�q�个�c�L��两个重要的运��符�Q?/p>

1、插入器(<<)
　　向流输出数据。比如说�pȝ��有一个默认的标准输出��?cout)�Q�一般情况下��是指的昄��器，所以，cout<<"Write Stdout"<<' ';��p��C�把字符�?Write Stdout"和换行字�W?' ')输出到标准输出流�?/p>

2、析取器(>>)
　　从流中输入数据。比如说�pȝ��有一个默认的标准输入��?cin)�Q�一般情况下��是指的键盘�Q�所以，cin>>x;��p��C�Z��标准输入��中��d��一个指定类�?卛_��量x的类�?的数据�?/p>

　　在C++中，�Ҏ��件的操作是通过stream的子�c?a name=0>fstream(file stream)来实现的�Q�所以，要用�q�种方式操作文�g�Q�就必须加入头文�?strong style="COLOR: black; BACKGROUND-COLOR: #ffff66">fstream.h。下面就把此�cȝ��文�g操作�q�程一一道来�?/p>

一、打开文�g
　　�?strong style="COLOR: black; BACKGROUND-COLOR: #ffff66">fstream�c�M��Q�有一个成员函数open()�Q�就是用来打开文�g的，其原型是�Q?/p>

void open(const char* filename,int mode,int access);

参数�Q?/p>

filename�Q�　　要打开的文件名
mode�Q�　　　　要打开文�g的方�?
access�Q�　　　打开文�g的属�?br>打开文�g的方式在�c�ios(是所有流式I/O�cȝ��基类)中定义，常用的值如下：

ios::app�Q�　　　以追加的方式打开文�g
ios::ate�Q�　　　文�g打开后定位到文�g��，ios:app��包含有此属�?
ios::binary�Q?　�?a name=2>二进�?/strong>方式打开文�g�Q�缺省的方式是文本方式。两�U�方式的区别见前�?
ios::in�Q�　　　文�g以输入方式打开
ios::out�Q�　　　文�g以输出方式打开
ios::nocreate�Q?不徏立文�Ӟ��所以文件不存在时打开��p�|　
ios::noreplace�Q�不覆盖文�g�Q�所以打开文�g时如果文件存在失�?
ios::trunc�Q�　　如果文�g存在�Q�把文�g长度设�ؓ0
　　可以�?#8220;�?#8221;把以上属性连接�v来，如ios::out|ios::binary

　　打开文�g的属性取值是�Q?/p>
0�Q�普通文�Ӟ��打开讉K��
1�Q�只��L��?
2�Q�隐含文�?
4�Q�系�l�文�?
　　可以�?#8220;�?#8221;或�?#8220;+”把以上属性连接�v�?�Q�如3�?|2��是以只��d��隐含属性打开文�g�?/p>
　　例如�Q�以二进�?/strong>输入方式打开文�gc:config.sys

　　fstream file1;
　　file1.open("c:\config.sys",ios::binary|ios::in,0);

　　如果open函数只有文�g名一个参敎ͼ�则是以读/写普通文件打开�Q�即�Q?/p>
　　file1.open("c:\config.sys");<=>file1.open("c:\config.sys",ios::in|ios::out,0);

　　另外�Q?strong style="COLOR: black; BACKGROUND-COLOR: #ffff66">fstream�q�有和open()一��L��构造函敎ͼ�对于上例�Q�在定义的时侯就可以打开文�g了：

　　fstream file1("c:\config.sys");

　　特别提出的是�Q?strong style="COLOR: black; BACKGROUND-COLOR: #ffff66">fstream有两个子�c�：ifstream(input file stream)和ofstream(outpu file stream)�Q�ifstream默认以输入方式打开文�g�Q�而ofstream默认以输出方式打开文�g�?/p>

　　ifstream file2("c:\pdos.def");//以输入方式打开文�g
　　ofstream file3("c:\x.123");//以输出方式打开文�g

　　所以，在实际应用中�Q�根据需要的不同�Q�选择不同的类来定义：如果想以输入方式打开�Q�就用ifstream来定义；如果想以输出方式打开�Q�就用ofstream来定义；如果想以输入/输出方式来打开�Q�就�?strong style="COLOR: black; BACKGROUND-COLOR: #ffff66">fstream来定义�?/p>

二、关闭文�?br>　　打开的文件��用完成后一定要关闭�Q?strong style="COLOR: black; BACKGROUND-COLOR: #ffff66">fstream提供了成员函数close()来完成此操作�Q�如�Q�file1.close();��把file1相连的文件关闭�?/p>

三、读写文�?br>　　��d��文�g分�ؓ文本文�g�?strong style="COLOR: black; BACKGROUND-COLOR: #99ff99">二进�?/strong>文�g�?strong style="COLOR: black; BACKGROUND-COLOR: #a0ffff">��d��Q�对于文本文件的��d��比较��单，用插入器和析取器��可以了�Q�而对�?strong style="COLOR: black; BACKGROUND-COLOR: #99ff99">二进�?/strong>�?strong style="COLOR: black; BACKGROUND-COLOR: #a0ffff">��d��p��复杂些，下要��p��l�的介绍�q�两�U�方�?/p>

　　1、文本文件的��d��
　　文本文�g的读写很��单：用插入器(<<)向文件输出；用析取器(>>)从文件输入。假设file1是以输入方式打开�Q�file2以输出打开。示例如下：

　　file2<<"I Love You";//向文件写入字�W�串"I Love You"
　　int i;
　　file1>>i;//从文件输入一个整数倹{�?

　　�q�种方式�q�有一�U�简单的格式化能力，比如可以指定输出�?6�q�制�{�等�Q�具体的格式有以下一�?/p>

操纵�W?功能输入/输出
dec 格式化�ؓ十进制数值数�?输入和输�?
endl 输出一个换行符�q�刷新此��?输出
ends 输出一个空字符输出
hex 格式化�ؓ十六�q�制数值数�?输入和输�?
oct 格式化�ؓ八进制数值数�?输入和输�?
setpxecision(int p) 讄��点数的�_�ֺ�位数输出

　　比如要把123当作十六�q�制输出�Q�file1<

　　2�?strong style="COLOR: black; BACKGROUND-COLOR: #99ff99">二进�?/strong>文�g的读�?br>①put()
　　put()函数向流写入一个字�W�，其原型是ofstream &put(char ch)�Q��用也比较��单，如file1.put('c');��是向流写一个字�W?c'�?

②get()
　　get()函数比较灉|��Q�有3�U�常用的重蝲形式�Q?/p>

　　一�U�就是和put()对应的�Ş式：ifstream &get(char &ch);功能是从��中��d��一个字�W�，�l�果保存在引用ch中，如果到文件尾�Q�返回空字符。如file2.get(x);表示从文件中��d��一个字�W�，�q�把��d��的字�W�保存在x中�?/p>

　　另一�U�重载�Ş式的原型是： int get();�q�种形式是从��中�q�回一个字�W�，如果到达文�g��，�q�回EOF�Q�如x=file2.get();和上例功能是一��L��?/p>

　　�q�有一�U��Ş式的原型是：ifstream &get(char *buf,int num,char delim=' ')�Q�这�U��Ş式把字符��d��?buf 指向的数�l�，直到��d��?num 个字�W�或遇到了由 delim 指定的字�W�，如果没��?delim �q�个参数�Q�将使用�~�省值换行符' '。例如：

　　file2.get(str1,127,'A');//从文件中��d��字符到字�W�串str1�Q�当遇到字符'A'�?strong style="COLOR: black; BACKGROUND-COLOR: #a0ffff">��d��?27个字�W�时�l�止�?/p>

③读写数据块
　　要读�?strong style="COLOR: black; BACKGROUND-COLOR: #99ff99">二进�?/strong>数据块，使用成员函数read()和write()成员函数�Q�它们原型如下：

　　　　read(unsigned char *buf,int num);
　　　　write(const unsigned char *buf,int num);

　　read()从文件中��d�� num 个字�W�到 buf 指向的缓存中�Q�如果在�q�未��d�� num 个字�W�时��到了文件尾�Q�可以用成员函数 int gcount();来取得实�?strong style="COLOR: black; BACKGROUND-COLOR: #a0ffff">��d��的字�W�数�Q��?write() 从buf 指向的缓存写 num 个字�W�到文�g中，值得注意的是�~�存的类型是 unsigned char *�Q�有时可能需要类型�{换�?/p>

例：

　　　　unsigned char str1[]="I Love You";
　　　　int n[5];
　　　　ifstream in("xxx.xxx");
　　　　ofstream out("yyy.yyy");
　　　　out.write(str1,strlen(str1));//把字�W�串str1全部写到yyy.yyy�?br>　　　　in.read((unsigned char*)n,sizeof(n));//从xxx.xxx�?strong style="COLOR: black; BACKGROUND-COLOR: #a0ffff">��d��指定个整敎ͼ�注意�c�d��转换
　　　　in.close();out.close();

四、检��EOF
　　成员函数eof()用来��是否到达文件尾�Q�如果到达文件尾�q�回�?��|��否则�q�回0。原型是int eof();

例：　　if(in.eof())ShowMessage("已经到达文�g��！");

五、文件定�?br>　　和C的文件操作方式不同的是，C++ I/O�pȝ��理两个与一个文件相联系的指针。一个是��L��针，它说明输入操作在文�g中的位置�Q�另一个是写指针，它下�ơ写操作的位�|�。每�ơ执行输入或输出�Ӟ��相应的指针自动变化。所以，C++的文件定位分��位置和写位置的定位，对应的成员函数是 seekg()�?seekp()�Q�seekg()是设�|�读位置�Q�seekp是设�|�写位置。它们最通用的�Ş式如下：

　　　　istream &seekg(streamoff offset,seek_dir origin);
　　　　ostream &seekp(streamoff offset,seek_dir origin);

　　streamoff定义�?iostream.h 中，定义有偏�U�量 offset 所能取得的最大��|��seek_dir 表示�U�d��的基准位�|�，是一个有以下值的枚�D�Q?

ios::beg�Q�　　文�g开�?
ios::cur�Q�　　文�g当前位置
ios::end�Q�　　文�g�l�尾
　　�q�两个函��C��般用�?strong style="COLOR: black; BACKGROUND-COLOR: #99ff99">二进�?/strong>文�g�Q�因为文本文件会因�ؓ�pȝ��对字�W�的解释而可能与预想的��g��同�?/p>

例：

　　　　 file1.seekg(1234,ios::cur);//把文件的��L��针从当前位置向后�U?234个字�?br>　　　　 file2.seekp(1234,ios::beg);//把文件的写指针从文�g开头向后移1234个字�?

saga.constantine 2007-06-19 23:46 发表评论

saga.constantine — Sun, 20 May 2007 07:20:00 GMT

��g��?Day正引发信息安全新“地震”看不见的才是最可怕的
　　�q�就�?Day的真正威�?br>　　如果你是一家企业的�|�络安全�ȝ��Q�企业外�|�的安全代码、脚本分析、环境配�|�、维护补丁已做到无懈可击�Q�内�|�防火墙、防病毒、入侉|��、��n份认证等��g设施也齐全完备，从技术手�D�|��Ԍ��g��没有什么可担心的；但你考虑�q�你所使用的操作系�l�、网站��^台或其他�W�三方应用程序，是否存在着某个不�ؓ人知的重大漏�z�呢�Q�当你发��C��的网�l�已遭入侵，信息已被�H�取�Q�查遍所有漏�z�数据库和安全补丁资料却不得其解。这�Ӟ��你考虑�q?Day么？
　　什么是0Day
　　0Day的概忉|��早用于��Y件和游戏破解�Q�属于非盈利性和非商业化的组�l�行为，其基本内涉|��“��x��?#8221;。Warez被许多�h误认为是一个最大的软�g破解�l�织�Q�而实际上�Q�Warez如黑客一��P��只是一�U�行为�?Day也是。当时的0Day是指在正版��Y件或游戏发布的当天甚至之前，发布附带着序列��h��者解密器的破解版�Q�让使用者可以不用付费就能长期��用。因此，虽然Warez�?Dday都是反盗版的重要打击对象�Q�却同时受到免费使用者和业内同行的推崇。尽��Warez�?Day的拥护者对以此而谋利的盗版商不齿，但商业利益的驱动�q�是��破解行为的商业化推��C��高峰。而眼下的0Day�Q�正在对信息安全产生��来��严重的威胁�?br>　　信息安全意义上的0Day是指在安全补丁发布前而被了解和掌握的漏洞信息�?br>　　2005�q?2�?日，几乎影响Windows所有操作系�l�的WMF漏洞在网上公开�Q�虽然微软在8天后提前发布了安全补丁（微��Y的惯例是在每月的�W�一个周二）�Q�但��在�q?天内出现了二癑֤�个利用此漏洞的攻击脚本。漏�z�信息的公开加速了软�g生��企业的安全补丁更新进�E�，减少了恶意程序的危害�E�度。但如果是不公开�?Day呢？WMF漏洞公开之前�Q�又有多��h已经利用了它�Q�是否有很多0Day一直在�U�密��传�Q�例如，�l�全球网�l�带来巨大危害的“冲击�?#8221;�?#8220;震荡�?#8221;�q�两�U�病毒，如果它们的漏�z�信息没有公开�Q�自然也��没有这两种��病毒的��生。反�q�来惻I��有什么理��p��为眼下不存在�c�M��的有着重大安全隐患的漏�z�呢�Q�（Dtlogin�q�程溢出漏洞�?002�q�被发现�Q?004�q�公布。）
　　看不见的才是最可怕的�Q�这��是0Day的真正威胁�?br>　　不可避免�?Day
　　信息价值的飞速提升，互联�|�在全球的普及，数字�l�济的广泛应用，�q�一切都刺激着信息安全市场的不断扩大，软�g破解、口令解密、间谍��Y件、木马病毒全部都从早期的仅做研究和向他�h炫耀的目的�{化�ؓ�U�商业利益的�q�作�Q��ƈ�q�速地传播开来，从操作系�l�到数据库，从应用��Y件到�W�三方程序和插�g�Q�再到遍布全球的漏洞发布中心�Q�看看它们当中有多少0Day存在�Q�可以毫不夸张的��_��在安全补丁程序发布之前，所有的漏洞信息都是0Day�Q�但是从未发布过安全补丁的��Y件是否就意味着它们当中不存�?Day呢？
　　有�h��_��“每一个稍兯��模的应用软�g都可能存�?Day�?#8221;没错�Q�从理论上讲�Q�漏�z�必定存在，只是��未发现�Q�而��I补措施永�q�滞后而已�?br>　　只要用户方不独自开发操作系�l�或应用�E�序�Q�或者说只要使用�W�三方的软�g�Q?Day的出现就是迟早的事，无论你是使用数据库还是网站管理��^収ͼ�无论你是使用媒体播放器还是绘囑ַ��P��即便是专职安全防护的软�g�E�序本��n�Q�都会出现安全漏�z�，�q�已是不争的事实�Q�但最可怕的不是漏洞存在的先天性，而是0Day的不可预知性�?br>　　从开源的角度上来��_��Linux更容易比��闭源代码的Windows存在更多�?Day。那些自以�ؓ使用着安全操作�pȝ��的�h�Q�迟早会�?Day��d��弄得哑口无言。而微软呢�Q�远有IIS和IE�Q�近有WMF和Excel�Q�由于其操作�pȝ��应用的广泛性，如今已是补丁加补丁，更新再更斎ͼ�最新操作系�l�Vista竟然含有几万行的问题代码。尚未发行，已是满目疮痍�Q�谁又能保证微��Y的源代码没有丝毫泄露呢？
　　0Day走向何方
　　��来��多的破解者和黑客们，已经把目光从率先发布漏洞信息的荣誉感转变到利用这些漏�z�而得到的�l�济利益上，互联�|�到处充斥着��C��万计的充满入侉|��情的脚本��子�Q�更不用说那些以�H�取信息��业的商业间谍和情报�h员了。于是，0Day有了市场�?br>　　国外两年前就有了0Day的网上交易，黑客们通过�|�上报�h出售手中未公开的漏�z�信息，一个操作系�l�或数据库的�q�程溢出源码可以卖到上千��元甚至更高�Q�而国内的黑客同行�Q�前不久也在�|�上建立了一个专门出售入�늨�序号�U�C��国第一0Day的网站，��管�c�M��的提供黑客工��L��|�站很多�Q�但此网站与其它�|�站的区别在�?Day的特性十分明显：��h��较高的攻�ȝ��序的��d��对象�Q�还没有相应的安全补丁，也就是说�q�样的攻�ȝ��序很可能��h��一��d��中的效果。这个网站成立不久便在搜索引擎中消失了，也许已经关闭�Q�也许�{入地下。但不管怎样�Q?Day带来的潜在经��利益不可抹杀�Q�而其��来对信息安全的影响以及危害也绝不能轻视�?br>　　软�g上的0Day几乎不可避免�Q�那��g呢？��g是否存在0Day�Q�答案无疑是肯定的。近�q�来�Q�思科路由器漏�z�频�J�出玎ͼ�今年2月，已被曝光的某知名�|�络产品漏洞至今仍未被修复。对于那些基于IP协议�q�接�|�络的�\由、网兟뀁交换机�Q�哪个电信运营商敢百分之癑֜� 保证自己的网�l�设备万无一失？�Q?005�q?�?1日，全国��过二十个城市的互联�|�出现群发性故障；同年7�?2日，北京20万ADSL用户断网�Q��?br>　　早在两年前，��q��的首席技术官��提��互联�|�不能承受与日俱增的使用者这一��x��Q�当�Ӟ��被很多�h认�ؓ是无�E�之谈。今�q?月，在美国的商业圆桌会议上，包括惠普公司、IBM公司、Sun公司、通用汽�R公司、家得宝公司和可口可乐公司等在内�?60个企业代表呼吁政府要对发生大规模�|�络故障的可能性做好准备工�?#8230;…
　　当今的互联网�Q�病毒、蠕虫、僵��网�l�、间谍��Y件、DDoS犹如�z�水般泛滥，所有的�q�一切都或多或少��C��0Day走过�Q�可以预��，在不�q�的��来�Q�互联网瘫痪�l�不遥远�?br>　　那么政府��理者、电信运营商、安全厂商，�q�有全世界的互联�|�用��P��面对0Day�Q�我们准备好了吗�Q?

saga.constantine 2007-05-20 15:20 发表评论

[转蝲]用户层下拦截�pȝ��api的原理与实现

saga.constantine — Mon, 22 Jan 2007 08:49:00 GMT

**转蝲**
**我自��q��了看�q�片文章�Q�还不错�Q�程序也可以�~�译出来**

文章作者：kiki
信息来源�Q�邪恶八�q�制信息安全团队�Q?/font> www.eviloctal.com �Q?br />本文章首�?/font> 黑色��岸�U�网�l�安全技术论�?/font> �Q�后由kiki友情提交到邪恶八�q�制信息安全团队

拦截api的技术有很多�U�，大体分�ؓ用户层和内核层的拦截�Q�这里只说说用户层的拦截�Q�而用户层也分��多种�Q�修改PE文�g导入表，直接修改要拦截的api的内存（从开始到最后，使程序蟩转到指定的地址执行�Q�．不过大部分原理都是修改程序流�E�，使之跌��{��C��要执行的地方�Q�然后再�q�回到原地址�Q�原来api的功能必��还能实玎ͼ�否则拦截��失��M��用了�Q�修�Ҏ��件导入表的方法的�~�点是如果用��L��序动态加载（使用LoadLibrary和GetProcAddress函数�Q�，拦截��变得复杂一些．所以这里介�l�一下第二种�Ҏ��Q�直接修改api�Q�当然不是全局的．�Q�后面会说到�Q?br />
　　需要了解的一些知识：

　　�Q�．windows内存的结构属性和�q�程地址�I�间

　　�Q�．函数堆栈的一些知�?br />

一�Q�win2000和xp的内存结构和�q�程地址�I�间

windows采用4GB�q�_��虚拟地址�I�间的做法。即每个�q�程单独拥有4GB的地址�I�间。每个进�E�只能访问自��q��q?GB的虚拟空��_��而对于其他进�E�的地址�I�间则是不可见的。这样保证了�q�程的安全性和�E�_��性。但是，�q?GB的空间是一个虚拟空��_��在��用之前，我们必须先保留一�D�虚拟地址�Q�然后再��D�虚拟地址提交物理存储器。可是我们的内存大部分都�q�没�?GB�Q�那么这4GB的地址�I�间是如何实现的呢？事实上windows采用的内存映��这�U�方法，��x��物理��盘当作内存来��用，比如我们打开一个可执行文�g的时候，操作�pȝ��会�ؓ我们开辟这�?GB的地址�I�间�Q?x00000000--0xffffffff。其�?x00000000--0x7fffffff是属于用户层的空�?0x80000000--0xffffffff则属于共享内核方式分区，主要是操作系�l�的�U�程调度�Q�内存管理，文�g�pȝ��支持�Q�网�l�支持和所有设备驱动程序。对于用户层的进�E�，�q�些地址�I�间是不可访问的。�Q何访问都��导致一个错误。开辟这4GB的虚拟地址�I�间之后�Q�系�l�会把磁盘上的执行文件映��到�q�程的地址�I�间中去(一般是在地址0x00400000�Q�可以通过修改�~�译选项来修改这个地址)而一个进�E�运行所需要的动态库文�g则一般从0x10000000开始加载。但是如果所有的动态库都加载到�q�个位置肯定会引起冲�H�。因此必��d��一些可能引起冲�H�的dll�~�译旉��C��改基地址。但是对于所有的操作�pȝ��所提供的动态库windows已经定义好了映射在指定的位置。这个位�|�会随着版本的不同而会有所改变�Q�不�q�对于同一台机器上的映��地址来说都是一��L��。即在a�q�程里映��的kernel32.dll的地址和在�q�程b里的kernel32.dll的地址是一��L��。对于文件映��是一�U�特�D�的方式�Q��得程序不需要进行磁盘i/o��p��对磁盘文件进行操作，而且支持多种保护属性。对于一个被映射的文�Ӟ��主要是��用CreateFileMapping函数�Q�利用他我们可以讑֮�一些读写属�?PAGE_READONLY,PAGE_READWRITE,PAGE_WRITECOPY.�W�一参数指定只能对该映射文�g�q�行��L��作。�Q何写操作��导致内存访问错误。第二个参数则指明可以对映射文�g�q�行��d��。这时候，��M��Ҏ��件的��d��都是直接操作文�g的。而对于第三个参数PAGE_WRITECOPY��֐�思义��是写入时拷贝，��M��向这�D�内存写入的操作(因�ؓ文�g是映��到�q�程地址�I�间的，对这�D늩�间的��d��q��当于�Ҏ��件进行的直接��d��)都将被系�l�捕��P��q��新在你的虚拟地址�I�间重新保留�q�分配一�D�内存，你所写入的一切东襉K��在�q�里�Q�而且你原先的指向映射文�g的内存地址也会实际指向�q�段重新分配的内存，于是在进�E�结束后�Q�映��文件内容�ƈ没有改变�Q�只是在�q�行期间在那�D늧�有拷贝的内存里面存在着你修改的内容。windows�q�程�q�行所需要映��的一些系�l�dll��是以这�U�方式映��的�Q�比如常用的ntdll.dll,kernel32.dll,gdi32.dll.几乎所有的�q�程都会加蝲�q�三个动态库。如果你在一个进�E�里修改�q�个映射文�g的内容，�q�不会媄响到其他的进�E��用他们。你所修改的只是在本进�E�的地址�I�间之内的。事实上原始文�g�q�没有被改变�?br />�q�样�Q�在后面的修改系�l�api的时候，实际��是修改�q�些动态库地址内的内容。前面说到这不是修改全局api��是�q�个原因�Q�因��Z��们都是以写入时拷贝的方式来映��的。不�q�这已经��_��了，windows提供�?个强大的内存操作函数ReadProcessMemory和WriteProcessMemory.利用�q�两个函数我们就可以随便对�Q意进�E�的��L��用户地址�I�间�q�行��d��了。但是，现在有一个问题，我们该写什么，说了半天�Q�怎么实现跌��{呢？现在来看一个简单的例子�Q?br />MessageBox(NULL, "World", "Hello", 0);
我们在执行这条语句的时候，调用了系�l�api MessageBox�Q�实际上在程序中我没有定义UNICODE宏，�pȝ��调用的是MessageBox的ANSI版本MessageBoxA,�q�个函数是由user32.dll导出的。下面是执行�q�条语句的汇�~�代码：
0040102A push 0
0040102C push offset string "Hello" (0041f024)
00401031 push offset string "World" (0041f01c)
00401036 push 0
00401038 call dword ptr [__imp__MessageBoxA@16 (0042428c)]
前面四条指��o分别为参数压栈，因�ؓMessageBoxA是__stdcall调用�U�定�Q�所以参数是从右往左压栈的。最后再CALL 0x0042428c

看看0042428c�q�段内存的��|��
0042428C 0B 05 D5 77 00 00 00
可以看到�q�个�?x77d5050b,正是user32.dll导出函数MessageBoxA的入口地址�?br />
�q�是0x77D5050B处的内容�Q?
77D5050B 8B FF mov edi,edi
77D5050D 55 push ebp
77D5050E 8B EC mov ebp,esp
理论上只要改变api入口和出口的��M��机器码，都可以拦截该api。这里我选择最��单的修改�Ҏ��Q�直接修改api入口的前十个字节来实现蟩转。�ؓ什么是十字节呢�Q�其实修改多��字节都没有关系�Q�只要实��C��函数的蟩转之后，你能把他们恢复�ƈ让他�l�箋�q�行才是最重要的。在CPU的指令里�Q�有几条指��o可以改变�E�序的流�E�：JMP�Q�CALL�Q�INT�Q�RET�Q�RETF�Q�IRET�{�指令。这里我选择CALL指��o�Q�因��Z��是以函数调用的方式来实现跌��{的，�q�样可以带一些你需要的参数。到�q�里�Q�我该说说函数的堆栈了�?br />
�ȝ��Q�windows�q�程所需要的动态库文�g都是以写入时拯��的方式映��到�q�程地址�I�间中的。这��P��我们只能拦截指定的进�E�。修改目标进�E�地址�I�间中的指定api的入口和出口地址之间的�Q意数据，使之跌��{到我们的拦截代码中去�Q�然后再恢复�q�些字节�Q��之能��利工作�?br />

二：函数堆栈的一些知�?br />
正如前面所看到MessageBoxA函数执行之前的汇�~�代码，首先��四个参数压栈，然后CALL MessageBoxA�Q�这时候我们的�U�程堆栈看�v来应该是�q�样的：

| | <---ESP
|�q�回地址|
|参数1|
|参数2|
|参数3|
|参数4|
|.. |

我们再看MessageBoxA的汇�~�代码，
77D5050B 8B FF mov edi,edi
77D5050D 55 push ebp
77D5050E 8B EC mov ebp,esp
注意到堆栈的操作有PUSH ebp,�q�是保存当前的基址指针�Q�以便一会儿恢复堆栈后返回调用线�E�时使用�Q�然后再有mov ebp,esp��是把当前esp的��D��l�ebp�Q�这时候我们就可以使用 ebp+偏移来表�C�堆栈中的数据，比如参数1��可以表�C�成[ebp+8]�Q�返回地址��可以表�C�成[ebp+4]..如果我们在拦截的时候要对这些参数和�q�回地址做�Q何处理，��可以��用这�U�方法。如果这个时候函数有局部变量的话，��通过减小ESP的值的方式来�ؓ之分配空间。接下来��是保存一些寄存器�Q�EDI,ESI,EBX.要注意的是，函数堆栈是反方向生长的。这时候堆栈的样子�Q?br />|....|
|EDI| <---ESP
|ESI|
|EBX|
|局部变量|
|EBP |
|�q�回地址|
|参数1|
|参数2|
|参数3|
|参数4|
|.. |

在函数返回的时候，由函数自�w�来�q�行堆栈的清理，�q�时候清理的��序和开始入栈的��序恰恰相反�Q�类似的汇编代码可能是这��L��Q?br />
pop edi
pop esi
pop ebx
add esp, 4
pop ebp
ret 0010
先恢复那些寄存器的��|��然后通过增加ESP的值的方式来释攑ֱ�部变量。这里可以用mov esp, ebp来实现清�I�所有局部变量和其他一些空闲分配空间。接着函数会恢复EBP的��|��利用指��oPOP EBP来恢复该寄存器的倹{��接着函数�q�行ret 0010�q�个指��o。该指��o的意思是�Q�函数把控制权交�l�当前栈��的地址的指令，同时清理堆栈�?6字节的参数。如果函数有�q�回值的话，那在EAX寄存器中保存着当前函数的返回倹{��如果是__cdecl调用方式�Q�则执行ret指��o�Q�对于堆栈参数的处理交给调用�U�程��d��。如wsprintf函数�?br />
�q�个时候堆栈又恢复了原来的样子。线�E�得以��l�往下执�?..
在拦截api的过�E�之中一个重要的��d��是保证堆栈的正��性。你要理清每一步堆栈中发生了什么�?br />

三：形成思�\

呵呵�Q�不知道你现在脑��h��不是有什么想法。怎么��d��现拦截一个api�Q?br /> �q�里�l�出一个思�\�Q�事实上拦截的方法真的很多，理清了一个，其他的也��容易了。而且上面所说的2个关键知识，也可以以另外的�Ş式来利用�?br /> 我以拦截CreateFile�q�个api��Z��子来��单说下这个思�\吧：

首先�Q�既然我们要拦截�q�个api��应该知道这个函数在内存中的位置吧，臛_��需要知道从哪儿入口。CreateFile�q�个函数是由kernel32.dll�q�个动态库导出的。我们可以��用下面的�Ҏ��来获取他映射到内存中的地址�Q?br /> HMODULE hkernel32 = LoadLibrary("Kernel32.dll");
PVOID dwCreateFile = GetProcAddress(hkernei32, "CreateFileA");
�q�就可以得到createfile的地址了，注意�q�里是获取的createfile的ansic版本。对于UNICODE版本的则获取CreateFileW。这时dwCreateFile的值就是他的地址了。对于其他进�E�中的createfile函数也是�q�个地址�Q�前面说�q�windows指定了他提供的所有的dll文�g的加载地址�?br />
接下来，我们该想办法实现跌��{了。最��单的�Ҏ��是修改�q�个api入口处的代码了。但是我们该修改多少呢？修改的内容�ؓ什么呢�Q�前面说�q�我们可以��用CALL的方式来实现跌��{�Q�这�U�方法的好处是可以�ؓ你的拦截函数提供一个或者多个参数。这里只要一个参数就��_��了。带参数的函数调用的汇编代码是什么样子呢�Q�前面也已经说了�Q�类��g��调用MessageBoxA时的代码�Q?br />
PUSH 参数地址
CALL 函数入口地址(�q�里��Z��个偏�U�d��址)

执行�q?条指令就能蟩转到你要拦截的函��C��Q�但是我们该修改成什么呢。首先，我们需要知道这2条指令的长度和具体的机器代码的倹{��其中PUSH对应0x68�Q�而CALL指��o对应的机器码�?xE8,而后面的则分别对应拦截函数的参数地址和函数的地址。注意第一个是一个直接的地址�Q�而第二个则是一个相对地址。当然你也可以��?xFF0x15�q�个CALL指��o来进行直接地址的蟩转�?br />下面��是计算�q?个地址的��g��Q?br />对于参数和函��C��的地址�Q�要分情况而定�Q�对于对本进�E�中api的拦截，则直接取地址��可以了。对于参敎ͼ�可以先定义一个参数变量，然后取变量地址��ok了�?br />如果是想拦截其他�q�程中的api�Q�则必须使用其他一些方法，最典型的方法是利用VirtualAllocEx函数来在其他�q�程中申请和提交内存�I�间。然后用WriteProcessMemory来分别把函数体和参数分别写入甌��和分配的内存�I�间中去。然后再生成要修改的数据�Q�最后用WriteProcessMemory来修改api入口�Q�把入口的前10字节修改为刚刚生成的跌��{数据。比如在�q�程�q�程中你写入的参数和函数体的内存地址分别�?x00010000�?x00011000,则生成的跌��{数据�?68 00 00 01 00 E8 00 10 01 00(PUSH 00010000 CALL 00011000),�q�样�E�序�q�行createfile函数的时候将会先�q�行PUSH 00010000 CALL 00011000�Q�这样就辑ֈ�了蟩转的目的。此��L��们应该时��L��意堆栈的状态，对于CreateFile�?br />HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);
可以看到其有7个参敎ͼ�于是在调用之前，堆栈应该已经被压入了�q?个参敎ͼ�堆栈的样子：
|....| <---ESP
|createfile执行后的下一条指令地址|
|参数1|
|参数2|
|参数3|
|参数4|
|参数5|
|参数6|
|参数7|
|..|

�q�是执行到我们的跌��{语句�Q�PUSH 00010000,于是堆栈又变了：

|....| <---ESP
|00010000|
|createfile执行后的下一条指令地址|
|参数1|
|参数2|
|参数3|
|参数4|
|参数5|
|参数6|
|参数7|
|..|

接着执行CALL 00011000,堆栈变�ؓ�Q?br />|...| <---ESP
|api入口之后的第11个字节的指��o的地址|
|00010000|
|createfile执行后的下一条指令地址|
|参数1|
|参数2|
|参数3|
|参数4|
|参数5|
|参数6|
|参数7|
|..|

接下来就��C��我们的拦截函��C��拉，当然�Q�函数肯定也会做一些类似动作，把EBP压栈�Q��ؓ局部变量分配空间等。这时候堆栈的样子又变了：

|EDI| <---ESP
|ESI|
|EBX|
|局部变量|
|EBP| <---EBP
|api入口之后的第11个字节的指��o的地址|
|00010000|
|createfile执行后的下一条指令地址|
|参数1|
|参数2|
|参数3|
|参数4|
|参数5|
|参数6|
|参数7|
|..|

�q�时候，你想做什么就��情地做吧，获取参数信息�Q��g�~�执行CreateFile函数�{�等。拿获取打开文�g句柄的名字来说吧�Q�文件名是第一个参敎ͼ�前面说过我们可以用[EBP+8]来获取参敎ͼ�但是对照上面的堆栈�Ş�Ӟ��中间又加了另外一些数据，所以我们用[EBP+16]来获取第一个参数的地址。比如：
char* PFileName = NULL;
__asm{
MOV EAX,[EBP+16]
MOV [szFileName], EAX
}

比如我们用一个messagebox来弹��Z��个信息，说明该程序即��打开一个某谋�\径的文�g句柄。但是有一个要注意的是�Q�如果你��x��截远�E�进�E�的话，对于那个拦截函数中所使用到的��M��函数或者以��M��形式的相对地址的调用都要停止。因为每个进�E�中的地址分配都是独立的，比如上面的CALL MessageBoxA�Ҏ��直接地址的调用。对于��用messagebox�Q�我们应该定义一个函数指针，然后把这个指针的��D��gؓuser32.dll中导��函数的直接地址。然后利用这个指针来�q�行函数调用。对于messagebox函数的调用可以这��P��在源�E�序中定义一个参数结构体�Q�参��C��包含一个导出函数的地址,把这个地址设�ؓMessageBoxA的直接地址�Q�获取地址的方法就不说了。然后把�q�个参数传给拦截函数�Q�就可以使用拉。这也是利用一个参数的原因。类��g��码如下：

typedef struct _RemoteParam {
DWORD dwMessageBox;
} RemoteParam, * PRemoteParam;

typedef int (__stdcall * PFN_MESSAGEBOX)(HWND, LPCTSTR, LPCTSTR, DWORD);//定义一个函数指�?br />
//拦截函数
void HookCreateFile(LPVOID lParam)
{
RemoteParam* pRP = (RemoteParam*)lParam;//获取参数地址
char* PFileName = NULL;//定义一个指�?br />__asm{
MOV EAX,[EBP+16]
MOV [szFileName], EAX //把CreateFile�W�一个参数的��|��文�g的�\径的地址�? //�l�szFileName
}

//�?义一个函数指�?br />PFN_MESSAGEBOX pfnMessageBox = (PFN_MESSAGEBOX)pRP->dwMessageBox;

pfnMessageBox(NULL, PFileName, PFileName, MB_ICONINFORMATION |MB_OK);
//输出要打开的文件的路径
//.....
}

对于你要使用的其他函敎ͼ�都是使用同样的方式，利用�q�个参数来传递我们要传递的函数的绝对地址�Q�然后定义这个函数指针，��可以��用了�?br />

好了�Q�接下来我们该让被拦截的api正常工作了，�q�个不难�Q�把他原来的数据恢复一下就可以了。那入口�?0个字节。我们在改写他们的时候应该保存一下，然后也把他放在参��C��传递给拦截函数�Q�呵呵，参数的作用可多了。接着我们��可以用WriteProcessMemory函数来恢复这个api的入口了�Q�代码如下：
PFN_GETCURRENTPROCESS pfnGetCurrentProcess = (PFN_GETCURRENTPROCESS)pRP->dwGetCurrentProcess;
PFN_WRITEPROCESSMEMORY pfnWriteProcessMemory = (PFN_WRITEPROCESSMEMORY)pRP->dwWriteProcessMemory;

if(!pfnWriteProcessMemory(pfnGetCurrentProcess(),
(LPVOID)pfnConnect,
(LPCVOID)pRP->szOldCode,
10,
NULL))
pfnMessageBox(NULL, pRP->szModuleName1, pRP->szModuleName2, MB_ICONINFORMATION | MB_OK);
其中�q�些函数指针的定义和上面的类伹{�?br />而参��C��的szoldcode则是在源�E�序中在修改api之前保存好，然后传给拦截函数�Q�在源程序中是用ReadProcessMemory函数来获取他的前10个字节的�Q?br />ReadProcessMemory(GetCurrentProcess(),
(LPCVOID)RParam.dwCreateFile,
oldcode,
10,
&dwPid)
strcat((char*)RParam.szOldCode, (char*)oldcode);

接下来如果你�q��l�保持对该api的拦截，则又该用WriteProcessMemory 来修改入口了�Q�跟前面的恢复入口是一��L��Q�只不过把szOldCode换成了szNewCode了而已。这样你又能对CreateFile�l�箋拦截了�?br />
好了�Q�接下来该进行堆栈的清理了，也许你还要做点其他事情，��管做去。但是清理堆栈是必须要做的，在函数结束的时候，因�ؓ在我们放任api恢复执行之后�Q�他又return 到我们的函数中来了，�q�个时候的堆栈是什么样子呢�Q?br />|EDI| <---ESP
|ESI|
|EBX|
|局部变量|
|EBP| <---EBP
|api入口之后的第11个字节的指��o的地址|
|00010000|
|createfile执行后的下一条指令地址|
|参数1|
|参数2|
|参数3|
|参数4|
|参数5|
|参数6|
|参数7|
|..|

我们的目标是把返回��D��录下来放到EAX寄存器中去，把返回地址记录下来�Q�同时把堆栈恢复成原来的样子�?br />首先我们恢复那些寄存器的��|��接着释放局部变量，可以用mov esp, ebp.因�ؓ我们不清楚具体的局部变量分配了多少�I�间。所以��用这个方法�?br />

__asm
{POP EDI
POP ESI
POP EBX //恢复那些寄存�?br />MOV EDX, [NextIpAddr]//把返回地址攑ֈ�EDX中，因�ؓ待会�? //EBX被恢复后�Q�线�E�中的所有局部变量就不能正常使用了�?br />
MOV EAX, [RetValue]//�q�回值放到EAX中，当然也可以修改这个返回�?br />MOV ESP, EBP//清理局部变�?br />POP EBP//恢复EBP的�?br />ADD ESP, 28H //清理参数和返回地址�Q�注意一�?7+1+1+1)*4
PUSH EDX //把返回地址压栈�Q�这��h��中就只有�q�一个返回地址了，�q�回之后�? //��q��?br />RET
}

�q�样�Q�一切就完成了，堆栈恢复了应该有的状态，而你��x��截的也拦截到了�?br />

四：后记
拦截的方式多�U�多��P��不过大体的思�\却都相同。要时刻注意你要拦截的函数的堆栈状态以及在拦截函数中的�Ҏ��据的引用和函数的调用�Q�地址问题�Q��?br />

//////////////////////////////////////////////////////////////////////
附录�Q�一个拦截CreateFile函数的简单实�?br />//////////////////////////////////////////////////////////////////////

CODE:

#include
#include
#include

#pragma comment(lib, "psapi.lib")

typedef struct _RemoteParam {
DWORD dwCreateFile;
DWORD dwMessageBox;
DWORD dwGetCurrentProcess;
DWORD dwWriteProcessMemory;
unsigned char szOldCode[10];
DWORD FunAddr;
} RemoteParam, * PRemoteParam;

typedef HANDLE (__stdcall * PFN_CREATEFILE)(LPCTSTR,DWORD,DWORD,LPSECURITY_ATTRIBUTES,DWORD,DWORD,HANDLE);
typedef int (__stdcall * PFN_MESSAGEBOX)(HWND, LPCTSTR, LPCTSTR, DWORD);
typedef BOOL (__stdcall * PFN_WRITEPROCESSMEMORY)(HANDLE,LPVOID,LPCVOID,SIZE_T,SIZE_T*);
typedef HANDLE (__stdcall * PFN_GETCURRENTPROCESS)(void);

#define PROCESSNUM 128
#define MYMESSAGEBOX "MessageBoxW"
#define MYCREATEFILE "CreateFileW"

void HookCreateFile(LPVOID lParam)
{

RemoteParam* pRP = (RemoteParam*)lParam;

DWORD NextIpAddr = 0;
DWORD dwParamaAddr = 0;

HANDLE RetFpHdl = INVALID_HANDLE_VALUE;
LPCTSTR lpFileName;
DWORD dwDesiredAccess;
DWORD dwShareMode;
LPSECURITY_ATTRIBUTES lpSecurityAttributes;
DWORD dwCreationDisposition;
DWORD dwFlagsAndAttributes;
HANDLE hTemplateFile;
PFN_CREATEFILE pfnCreatefile = (PFN_CREATEFILE)pRP->dwCreateFile;

__asm
{
MOV EAX,[EBP+8]
MOV [dwParamaAddr], EAX
MOV EAX,[EBP+12]
MOV [NextIpAddr], EAX
MOV EAX,[EBP+16]
MOV [lpFileName], EAX
MOV EAX,[EBP+20]
MOV [dwDesiredAccess],EAX
MOV EAX,[EBP+24]
MOV [dwShareMode],EAX
MOV EAX,[EBP+28]
MOV [lpSecurityAttributes],EAX
MOV EAX,[EBP+32]
MOV [dwCreationDisposition],EAX
MOV EAX,[EBP+36]
MOV [dwFlagsAndAttributes],EAX
MOV EAX,[EBP+40]
MOV [hTemplateFile],EAX
}

PFN_MESSAGEBOX pfnMessageBox = (PFN_MESSAGEBOX)pRP->dwMessageBox;
int allowFlag = pfnMessageBox(NULL, lpFileName, NULL, MB_ICONINFORMATION | MB_YESNO);

if(allowFlag == IDYES)
{
unsigned char szNewCode[10];
int PramaAddr = (int)dwParamaAddr;
szNewCode[4] = PramaAddr>>24;
szNewCode[3] = (PramaAddr<<8)>>24;
szNewCode[2] = (PramaAddr<<16)>>24;
szNewCode[1] = (PramaAddr<<24)>>24;
szNewCode[0] = 0x68;

int funaddr = (int)pRP->FunAddr - (int)pfnCreatefile - 10 ;
szNewCode[9] = funaddr>>24;
szNewCode[8] = (funaddr<<8)>>24;
szNewCode[7] = (funaddr<<16)>>24;
szNewCode[6] = (funaddr<<24)>>24;
szNewCode[5] = 0xE8;

PFN_GETCURRENTPROCESS pfnGetCurrentProcess = (PFN_GETCURRENTPROCESS)pRP->dwGetCurrentProcess;
PFN_WRITEPROCESSMEMORY pfnWriteProcessMemory = (PFN_WRITEPROCESSMEMORY)pRP->dwWriteProcessMemory;
pfnWriteProcessMemory(pfnGetCurrentProcess(),
(LPVOID)pfnCreatefile,
(LPCVOID)pRP->szOldCode,
10,
NULL);

RetFpHdl = pfnCreatefile(lpFileName,
dwDesiredAccess,
dwShareMode,
lpSecurityAttributes,
dwCreationDisposition,
dwFlagsAndAttributes,
hTemplateFile);
pfnWriteProcessMemory(pfnGetCurrentProcess(),
(LPVOID)pfnCreatefile,
(LPCVOID)szNewCode,
10,
NULL);
}

__asm
{POP EDI
POP ESI
POP EBX
MOV EDX, [NextIpAddr]
MOV EAX, [RetFpHdl]
MOV ESP, EBP
POP EBP
ADD ESP, 28H
PUSH EDX
RET
}

}

BOOL AdjustProcessPrivileges(LPCSTR szPrivilegesName)
{
HANDLE hToken;
TOKEN_PRIVILEGES tkp;

if(!OpenProcessToken(GetCurrentProcess(),
TOKEN_ADJUST_PRIVILEGES|TOKEN_QUERY,&hToken))
{
return FALSE;
}

if(!LookupPrivilegeValue(NULL,szPrivilegesName,
&tkp.Privileges[0].Luid))
{
CloseHandle(hToken);
return FALSE;
}

tkp.PrivilegeCount = 1;
tkp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

if(!AdjustTokenPrivileges(hToken,FALSE,&tkp,sizeof(tkp),NULL,NULL))
{
CloseHandle(hToken);
return FALSE;
}

CloseHandle(hToken);
return TRUE;
}

void printProcessNameByPid( DWORD ProcessId )
{
HANDLE pHd;
HMODULE pHmod;
char ProcessName[MAX_PATH] = "unknown";
DWORD cbNeeded;
pHd = OpenProcess( PROCESS_QUERY_INFORMATION |PROCESS_VM_READ, FALSE, ProcessId );
if(pHd == NULL)
return;

if(!EnumProcessModules( pHd, &pHmod, sizeof(pHmod), &cbNeeded))
return;
if(!GetModuleFileNameEx( pHd, pHmod, ProcessName, MAX_PATH))
return;

printf( "%d\t%s\n", ProcessId, ProcessName);
CloseHandle( pHd );
return;
}

int main(void)
{

if(!AdjustProcessPrivileges(SE_DEBUG_NAME))
{
printf("AdjustProcessPrivileges Error!\n");
return -1;
}

DWORD Pids[PROCESSNUM];
DWORD dwProcessNum = 0;
if(!EnumProcesses(Pids, sizeof(Pids), &dwProcessNum))
{
printf("EnumProcess Error!\n");
return -1;
}

for( DWORD num = 0; num < (dwProcessNum / sizeof(DWORD)); num++)
printProcessNameByPid(Pids[num]);

printf("\nAll %d processes running. \n", dwProcessNum / sizeof(DWORD));

DWORD dwPid = 0;
printf("\n误��入要拦截的进�E�id:");
scanf("%d", &dwPid);

HANDLE hTargetProcess = OpenProcess(PROCESS_VM_OPERATION|PROCESS_VM_WRITE|PROCESS_VM_READ, FALSE, dwPid);
if(hTargetProcess == NULL)
{
printf("OpenProcess Error!\n");
return -1;
}

DWORD dwFunAddr = (DWORD)VirtualAllocEx(hTargetProcess, NULL, 8192,
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

if((LPVOID)dwFunAddr == NULL)
{
printf("甌��U�程内存��p�|!\n");
CloseHandle(hTargetProcess);
return -1;
}

DWORD dwPramaAddr = (DWORD)VirtualAllocEx(hTargetProcess, NULL, sizeof(RemoteParam),
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

if((LPVOID)dwPramaAddr == NULL)
{
printf("甌��参数内存��p�|!\n");
CloseHandle(hTargetProcess);
return -1;
}

printf("\n�U�程内存地址:%.8x\n"
"参数内存地址:%.8x\n",
dwFunAddr, dwPramaAddr);
RemoteParam RParam;
ZeroMemory(&RParam, sizeof(RParam));
HMODULE hKernel32 = LoadLibrary("kernel32.dll");
HMODULE hUser32 = LoadLibrary("user32.dll");

RParam.dwCreateFile = (DWORD)GetProcAddress(hKernel32, MYCREATEFILE);
RParam.dwGetCurrentProcess = (DWORD)GetProcAddress(hKernel32, "GetCurrentProcess");
RParam.dwWriteProcessMemory = (DWORD)GetProcAddress(hKernel32, "WriteProcessMemory");
RParam.dwMessageBox = (DWORD)GetProcAddress(hUser32, MYMESSAGEBOX);

unsigned char oldcode[10];
unsigned char newcode[10];
int praadd = (int)dwPramaAddr;
int threadadd = (int)dwFunAddr;
newcode[4] = praadd>>24;
newcode[3] = (praadd<<8)>>24;
newcode[2] = (praadd<<16)>>24;
newcode[1] = (praadd<<24)>>24;
newcode[0] = 0x68;

int offsetaddr = threadadd - (int)RParam.dwCreateFile - 10 ;
newcode[9] = offsetaddr>>24;
newcode[8] = (offsetaddr<<8)>>24;
newcode[7] = (offsetaddr<<16)>>24;
newcode[6] = (offsetaddr<<24)>>24;
newcode[5] = 0xE8;

printf("NewCode:");
for(int j = 0; j < 10; j++)
printf("0x%.2x ",newcode[j]);
printf("\n\n");

if(!ReadProcessMemory(GetCurrentProcess(),
(LPCVOID)RParam.dwCreateFile,
oldcode,
10,
&dwPid))
{
printf("read error");
CloseHandle(hTargetProcess);
FreeLibrary(hKernel32);
return -1;
}

strcat((char*)RParam.szOldCode, (char*)oldcode);
RParam.FunAddr = dwFunAddr;

printf(
"RParam.dwCreateFile:%.8x\n"
"RParam.dwMessageBox:%.8x\n"
"RParam.dwGetCurrentProcess:%.8x\n"
"RParam.dwWriteProcessMemory:%.8x\n"
"RParam.FunAddr:%.8x\n",
RParam.dwCreateFile,
RParam.dwMessageBox,
RParam.dwGetCurrentProcess,
RParam.dwWriteProcessMemory,
RParam.FunAddr);
printf("RParam.szOldCode:");
for( int i = 0; i< 10; i++)
printf("0x%.2x ", RParam.szOldCode[i]);
printf("\n");

if(!WriteProcessMemory(hTargetProcess, (LPVOID)dwFunAddr, (LPVOID)&HookCreateFile, 8192, &dwPid))
{
printf("WriteRemoteProcessesMemory Error!\n");
CloseHandle(hTargetProcess);
FreeLibrary(hKernel32);
return -1;
}

if(!WriteProcessMemory(hTargetProcess, (LPVOID)dwPramaAddr, (LPVOID)&RParam, sizeof(RemoteParam), &dwPid))
{
printf("WriteRemoteProcessesMemory Error!\n");
CloseHandle(hTargetProcess);
FreeLibrary(hKernel32);
return -1;
}

if(!WriteProcessMemory(hTargetProcess, (LPVOID)RParam.dwCreateFile, (LPVOID)newcode, 10, &dwPid))
{
printf("WriteRemoteProcessesMemory Error!\n");
CloseHandle(hTargetProcess);
FreeLibrary(hKernel32);
return -1;
}

printf("\nThat's all, good luck :)\n");
CloseHandle(hTargetProcess);
FreeLibrary(hKernel32);
return 0;
}

saga.constantine 2007-01-22 16:49 发表评论

[攉��]关于汇编80X87FPU��点�q�算

saga.constantine — Wed, 17 Jan 2007 06:46:00 GMT

80X87FPU��点数据的格式、��Q点寄存器的特�?br />
��点数据格式:
在计��机中，实数的��Q�Ҏ��式（Floating-Point Format�Q�所�C�，分成指数、有效数字和�W�号位三个部分�?br />· �W�号�Q�Sign�Q�——表�C�数据的正负�Q�在最高有效位�Q�MSB�Q�。负数的�W�号位�ؓ1�Q�正数的�W�号�?�?br />· 指数�Q�Exponent�Q�——也被称为阶码，表示数据�?为底的幂。指数采用偏�Uȝ��Q�Biased Exponent�Q�表�C�，恒�ؓ整数�?br />· 有效数字�Q�Significand�Q�——表�C�数据的有效数字�Q�反映数据的�_�ֺ�。有效数字一般采用规格化�Q�Normalized�Q��Ş式，是一个纯��数�Q�所以也被称为尾敎ͼ�Mantissa�Q�、小数或分数�Q�Fraction�Q��?br /> 80x87支持三种��点数据�c�d��Q�单�_�ֺ�、双�_�ֺ�和扩展精度；它们的长度依�ơ�ؓ32�?4�?0位，�?�?�?0个字节；
· 单精度��Q�Ҏ��Q?2位短实数�Q�——由1位符受��?位指数�?3位有效数�l�成�?br />· 双精度��Q�Ҏ��Q?4位长实数�Q�——由1位符受��?1位指数�?2位有效数�l�成�?br />· 扩展�_�ֺ��点敎ͼ�80位��时实敎ͼ�——由1位符受��?5位指数�?4位有效数�l�成。很多计��机中�ƈ没有80位扩展精度这�U�数据类型，80x87 FPU主要在内部��用它存贮中间�l�果�Q�以保证最�l�数值的�_�ֺ��?/p>

80x87的指令系�l?br />��点处理单元FPU��h��自己的指令系�l�，共有几十�U��Q�Ҏ��令，可以分成传送、算术运��、超��函数、比较、FPU控制�{�类。��Q�Ҏ��令归属于ESC指��o�Q�其�?位的操作码都�?1011b�Q�它的指令助记符均以F开头�?br />1. ��点传送类指��o
��点数据传送指令完成主存与栈顶st(0)、数据寄存器st(i)与栈��之间的��点格式数据的传送。��Q�Ҏ��据寄存器是一个首��接的堆栈�Q�所以它的数据传送实际上是对堆栈的操作，有些要改变堆栈指针TOP�Q�即修改当前栈顶�?br />2. ��术�q�算�c�L��?br /> �q�类��点指��o实现��点数�?6/32位整数的加、减、乘、除�q�算�Q�它们支持的��d��方式相同。这�l�指令还包括有关��术�q�算的指令，例如求绝对倹{��取整等�?br />3. ��越函数�c�L��?br /> ��点指��o集中包含有进行三角函数、指数和�Ҏ��q�算的指令�?br />4. ��点比较�c�L��?br /> ��点比较指��o比较栈顶数据与指定的源操作数�Q�比较结果通过��点状态寄存器反映�?br />5. FPU控制�c�L��?br /> FPU控制�c�L��令用于控制和��Q点处理单元FPU的状态及操作方式�?/p>

采用��点指��o的汇�~�语�a��E�序格式�Q�与整数指��o源程序格式是�c�M��的，但有以下几点需要注意：
· 使用FPU选择伪指�?br />      �׃��汇编�E�序MASM默认只识�?086指��o�Q�所以要加上.8087 / .287 / .387�{�伪指��o选择汇编��点指��o�Q�有�Ӟ��q�要加上相应�?238/.386�{�伪指��o�?br />· 定义��点数据
      数据定义伪指令dd(dword) / dq(qword) / dt(tbyte)依次说明32/64/80位数据；它们可以用于定义单精度、双�_�ֺ�和扩展精度��Q�Ҏ��。�ؓ了区别于整数定义�Q�MASM 6.11��采用REAL4、REAL8、REAL10定义单、双、扩展精度��Q�Ҏ��Q�但不能出现�U�整敎ͼ�其实�Q�整数后面补个小数点��可以了�Q�。相应的数据属性依�ơ是dword、qword、tbyte。另外，实常数可以用E表示10的幂�?br />· 初始化��Q点处理单�?
      每当执行一个新的��Q点程序时�Q�第一条指令都应该是初始化FPU的指令finit。该指��o清除��点数据寄存器栈和异常，为程序提供一个“干净”的初始状态。否则，遗留在��Q点寄存器栈中的数据可能会产生堆栈溢出。另一斚w��Q��Q�Ҏ��令程序段�l�束�Q�也最好清�I��Q�Ҏ��据寄存器�?/p>

��点寄存�?
��点执行环境的寄存器主要�?个通用数据寄存器和几个专用寄存器，它们是状态寄存器、控制寄存器、标记寄存器�{?br />8个��Q�Ҏ��据寄存器�Q�FPU Data Register�Q�，�~�号FPR0 ~ FPR7。每个��Q点寄存器都是80位的�Q�以扩展�_�ֺ�格式存储数据。当其他�c�d��数据压入数据寄存器时�Q�PFU自动转换成扩展精度；相反�Q�数据寄存器的数据取出时�Q�系�l�也会自动�{换成要求的数据类型�?br /> 8个��Q�Ҏ��据寄存器�l�成首尾相接的堆栈，当前栈顶ST(0)指向的FPRx��q��态寄存器中TOP字段指明。数据寄存器不采用随机存取，而是按照“后�q�先出”的堆栈原则工作�Q��ƈ且首��@环。向数据寄存器传送（Load�Q�数据时��是入栈�Q�堆栈指针TOP先减1�Q�再��数据压入栈��寄存器�Q�从数据寄存器取出（Store�Q�数据时��是出栈�Q�先��栈��寄存器数据弹出�Q�再修改堆栈指针使TOP�?。��Q点寄存器栈还有首��@环相�q�的特点。例如，若当前栈��TOP=0�Q�即ST(0) = PFR0�Q�，那么�Q�入栈操作后��׃��TOP=7�Q�即使ST(0) = PFR7�Q�，数据被压入PFR7。所以，��点数据寄存器常常被�U�Cؓ��点数据栈�?br /> ��Z��表明��点数据寄存器中数据的性质�Q�对应每个FPR寄存器，都有一�?位的标记�Q�Tag�Q�位�Q�这8个标记tag0 ~ tag7�l�成一�?6位的标记寄存器�?/p>

saga.constantine 2007-01-17 14:46 发表评论

saga.constantine — Sun, 28 May 2006 08:15:00 GMT

选择�?soloist �?Blog 作�?不详如原作者发现�ƈ不允许�{载请通知我，我会删除�Q?img src="../../Emoticons/QQ/41.gif" border="0" height="20" width="20" />

当在C中定义了一个结构类型时�Q�它的大��是否等于各字段(field)大小之和�Q�编译器��如何在内存中放�|�这些字�D�？ANSI C对结构体的内存布局有什么要求？而我们的�E�序又能否依赖这�U�布局�Q�这些问题或许对不少朋友来说�q�有�Ҏ��p�，那么本文��p��着探究它们背后的秘密�?/font>

首先�Q�至��有一点可以肯定，那就是ANSI C保证�l�构体中各字�D�在内存中出现的位置是随它们的声明顺序依�ơ递增的，�q�且�W�一个字�D늚�首地址�{�于整个�l�构体实例的首地址。比如有�q�样一个结构体�Q?br />
struct vector{int x,y,z;} s;
int *p,*q,*r;
struct vector *ps;

p = &s.x;
q = &s.y;
r = &s.z;
ps = &s;

assert(p < q);
assert(p < r);
assert(q < r);
assert((int*)ps == p);
// 上述断言一定不会失�?/font>

�q�时�Q�有朋友可能会问:"标准是否规定盔R��字段在内存中也相�?"�? 唔，对不��P��ANSI C没有做出保证�Q?/font>你的�E�序在�Q何时候都不应该依赖这个假设。那�q�是否意味着我们永远无法勑֋��Z��q�更清晰更精��的�l�构体内存布局图？哦，当然不是。不�q�先让我们从�q�个问题中暂时抽�w�，��x��一下另一个重要问题————内存对齐�?/font>

许多实际的计��机�pȝ��对基本类型数据在内存中存攄��位置有限�Ӟ��它们会要求这些数据的首地址的值是�?/font>个数k(通常它�ؓ4�?)的倍数�Q�这��是所谓的内存寚w��Q�而这个k则被�U�Cؓ该数据类型的寚w��模数(alignment modulus)。当一�U�类型S的对齐模��C��另一�U�类型T的对齐模数的比值是大于1的整敎ͼ�我们��q��c�d��S的对齐要�?/font>比T�?严格)�Q�而称T比S�?宽松)。这�U�强制的要求一来简化了处理器与内存之间传输�pȝ��的设计，二来可以提升��d��数据的速度。比如这么一�U�处理器�Q�它每次��d��内存的时候都从某�?倍数的地址开始，一�ơ读出或写入8�?/font>字节的数据，假如软�g能保证double�c�d��的数据都�?倍数地址开始，那么��L��写一个double�c�d��数据��只需�?/font>一�ơ内存操作。否则，我们��可能需要两�ơ内存操作才能完成这个动作，因�ؓ数据或许恰好横跨在两个符合对�?/font>要求�?字节内存块上。某些处理器在数据不满��寚w��要求的情况下可能会出错，但是Intel的IA32架构的处理器则不��数据是否对齐都能正��工作。不�q�Intel奉劝大家�Q�如果想提升性能�Q�那么所有的�E�序数据都应该尽可能�?/font>寚w��。Win32�q�_��下的微��YC�~�译�?cl.exe for 80x86)在默认情况下采用如下的对齐规�? ��M��基本数据�c�d��T的对齐模数就是T的大��，即sizeof(T)。比如对于double�c�d��(8字节)�Q�就要求该类型数据的地址��L��8的倍数�Q�而char�c�d��数据(1字节)则可以从��M��一个地址开始。Linux下的GCC奉行的是另外一套规�?在资料中查得�Q��ƈ未验证，如错误请指正):��M��2字节大小(包括单字节吗?)的数据类�?比如short)的对齐模数是2�Q�而其它所有超�q?字节的数据类�?比如long,double)都以4为对齐模数�?/font>

现在回到我们兛_��的struct上来。ANSI C规定一�U�结构类型的大小是它所有字�D늚�大小以及字段之间或字�D?/font>��N��的填充区大小之和。嗯�Q�填充区�Q�对�Q�这��是��Z��使结构体字段满��内存寚w��要求而额外分配给�l�构体的�I?/font>间。那么结构体本��n有什么对齐要求吗�Q�有的，ANSI C标准规定�l�构体类型的寚w��要求不能比它所有字�D�中要求最严格的那个宽松，可以更严�?但此非强制要求，VC7.1��׃��仅是让它们一样严�?。我们来看一个例�?以下所有试验的环境是Intel Celeron 2.4G + WIN2000 PRO + vc7.1�Q�内存对齐编译选项�?默认"�Q�即不指�?Zp�?/font>/pack选项):

typedef struct ms1
{
char a;
int b;
} MS1;

    假设MS1按如下方式内存布局(本文所有示意图中的内存地址从左臛_��递增):
       _____________________________
       |       |                   |
       |   a   |        b          |
       |       |                   |
       +---------------------------+
Bytes:    1             4

因�ؓMS1中有最强对齐要求的是b字段(int)�Q�所以根据编译器的对齐规则以及ANSI C标准�Q�MS1对象的首�?/font>址一定是4(int�c�d��的对齐模�?的倍数。那么上�q�内存布局中的b字段能满��int�c�d��的对齐要求吗�Q�嗯�Q�当然不能。如果你是编译器�Q�你会如何��y妙安排来满��CPU的癖好呢�Q�呵呵，�l�过1毫秒的艰苦思考，你一定得��Z��如下的方案：

       _______________________________________
       |       |\\\\\\\\\\\|                 |
       |   a   |\\padding\\|       b         |
       |       |\\\\\\\\\\\|                 |
       +-------------------------------------+
Bytes:    1         3             4

�q�个�Ҏ��在a与b之间多分配了3个填�?padding)字节�Q�这样当整个struct对象首地址满��4字节的对齐要�?/font>�Ӟ��b字段也一定能满��int型的4字节寚w��规定。那么sizeof(MS1)昄��应该是8�Q�而b字段相对于结构体首地址的偏�U�d��?。非常好理解�Q�对吗？现在我们把MS1中的字段交换一下顺�?

typedef struct ms2
{
int a;
char b;
} MS2;

或许你认为MS2比MS1的情况要��单，它的布局应该��是

       _______________________
       |             |       |
       |     a       |   b   |
       |             |       |
       +---------------------+
Bytes:      4           1

因�ؓMS2对象同样要满��?字节寚w��规定�Q�而此时a的地址与结构体的首地址相等�Q�所以它一定也�?字节寚w��。嗯�Q�分析得有道理，可是却不全面。让我们来考虑一下定义一个MS2�c�d��的数�l�会出现什么问题。C标准保证�Q?/font>��M��c�d��(包括自定义结构类�?的数�l�所占空间的大小一定等于一个单独的该类型数据的大小乘以数组元素的个数。换句话��_��数组各元素之间不会有�I�隙。按照上面的�Ҏ��Q�一个MS2数组array的布局��是:

|<- array[1] ->|<- array[2] ->|<- array[3] .....

__________________________________________________________
|             |       |              |      |
|     a       |   b   |      a       |   b |.............
|             |       |              |      |
+----------------------------------------------------------
Bytes: 4         1          4           1

当数�l�首地址�?字节寚w��Ӟ��array[1].a也是4字节寚w��Q�可是array[2].a呢？array[3].a ....呢？�?/font>见这�U�方案在定义�l�构体数�l�时无法让数�l�中所有元素的字段都满��_��齐规定，必须修改成如下�Ş�?

       ___________________________________
       |             |       |\\\\\\\\\\\|
       |     a       |   b   |\\padding\\|
       |             |       |\\\\\\\\\\\|
       +---------------------------------+
Bytes:      4           1         3

现在无论是定义一个单独的MS2变量�q�是MS2数组�Q�均能保证所有元素的所有字�D�都满��寚w��规定。那�?/font>sizeof(MS2)仍然�?�Q�而a的偏�U�Mؓ0�Q�b的偏�U�L��4�?/font>

好的�Q�现在你已经掌握了结构体内存布局的基本准则，��试分析一个稍微复杂点的类型吧�?/font>

typedef struct ms3
{
     char a;
     short b;
     double c;
} MS3;

    我想你一定能得出如下正确的布局�?

        padding
           |
      _____v_________________________________
      |   |\|     |\\\\\\\\\|               |
      | a |\| b |\padding\|       c       |
      |   |\|     |\\\\\\\\\|               |
      +-------------------------------------+
Bytes: 1 1   2       4            8

    sizeof(short)�{�于2�Q�b字段应从偶数地址开始，所以a的后面填充一个字节，而sizeof(double)�{�于8�Q�c字段要从8倍数地址开始，前面的a、b字段加上填充字节已经�? bytes�Q�所以b后面再填�?个字节就可以保证c字段的对齐要求了。sizeof(MS3)�{�于16�Q�b的偏�U�L��2�Q�c的偏�U�L��8。接着看看�l�构体中字段�q�是�l�构�c�d��的情�?

typedef struct ms4
{
char a;
MS3 b;
} MS4;

    MS3中内存要求最严格的字�D�|��c�Q�那么MS3�c�d��数据的对齐模数就与double的一�?�?)�Q�a字段后面应填�?/font>7个字节，因此MS4的布局应该�?
       _______________________________________
       |       |\\\\\\\\\\\|                 |
       |   a   |\\padding\\|       b         |
       |       |\\\\\\\\\\\|                 |
       +-------------------------------------+
Bytes:    1         7             16

昄��Q�sizeof(MS4)�{�于24�Q�b的偏�Uȝ��?�?/font>

在实际开发中�Q�我们可以通过指定/Zp�~�译选项来更改编译器的对齐规则。比如指�?Zpn(VC7.1中n可以�?�?�?�?�?6)��是告诉�~�译器最大对齐模数是n。在�q�种情况下，所有小于等于n字节的基本数据类型的寚w��?/font>则与默认的一��P��但是大于n个字节的数据�c�d��的对齐模数被限制为n。事实上�Q�VC7.1的默认对齐选项��q��当于/Zp8。仔�l�看看MSDN对这个选项的描�q�ͼ�会发现它郑重告诫了程序员不要在MIPS和Alpha�q�_��上用/Zp1�?Zp2�?/font>��，也不要在16位��^��C��指定/Zp4�?Zp8(��x��Z��么？)。改变编译器的对齐选项�Q�对照程序运行结果重新分�?/font>上面4�U�结构体的内存布局��是一个很好的复习�?/font>

��C��q�里�Q�我们可以回�{�本文提出的最后一个问题了。结构体的内存布局依赖于CPU、操作系�l�、编译器及编译时的对齐选项�Q�而你的程序可能需要运行在多种�q�_��上，你的源代码可能要被不同的人用不同的编译器�~�译(�?/font>想你为别人提供一个开放源码的�?�Q�那么除非绝对必需�Q�否则你的程序永�q�也不要依赖�q�些诡异的内存布局。顺便说一下，如果一个程序中的两个模块是用不同的寚w��选项分别�~�译的，那么它很可能会��生一些非常微妙的�?/font>误。如果你的程序确实有很难理解的行为，不防仔细��查一下各个模块的�~�译选项�?/font>

思考题:请分析下面几�U�结构体在你的��^��C��的内存布局�Q��ƈ试着��L��一�U�合理安排字�D�声明顺序的�Ҏ��以尽量节省内存空间�?/font>

    A. struct P1 { int a; char b; int c; char d; };
    B. struct P2 { int a; char b; char c; int d; };
    C. struct P3 { short a[3]; char b[3]; };
    D. struct P4 { short a[3]; char *b[3]; };
    E. struct P5 { struct P2 *a; char b; struct P1 a[2]; };

参考资�?

    �?】《深入理解计��机�pȝ��(修订�?》，
         (�?Randal E.Bryant; David O'Hallaron�Q?br />         (�?龚奕�?雯��春，
         中国电力出版�C�，2004

    �?】《C: A Reference Manual�?影印�?�Q?br />         (�?Samuel P.Harbison; Guy L.Steele�Q?br />         人民邮电出版�C�，2003

saga.constantine 2006-05-28 16:15 发表评论

saga.constantine — Sat, 27 May 2006 05:06:00 GMT

�?/span> MSND 上截下来的，帮助理解数据寚w��?/span>
�~�译出来的结构体怎么占用内存的�?/span> padding 为编译器填充的，不理解的可以看看我前面发的翻译的关于数据寚w��?/span>
alignment 寚w��Q?/span> Quadword �Q?/span> 8 byte �Q?/span> Doubleword �Q?/span> 4 byte

�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－

Example 2

�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－

�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q�－�Q?/span>

�Q�－�Q�－ saga.constantine

saga.constantine 2006-05-27 13:06 发表评论

saga.constantine — Fri, 26 May 2006 02:41:00 GMT

�l�习一下翻译能力！不当之处��h��出！�Q?/span>
原文�� MSDN �Q�链接�ؓ http://msdn2.microsoft.com/en-us/library/ms253949.aspx

       很多 CPU �Q�如��Z�� Alpha, IA-64, MIPS, �?/span> SuperH 体系的，拒绝��d��未对齐数据。当一个程序要求其中之一�?/span> CPU ��d��未对齐数据时�Q�这�?/span> CPU 会进入异常处理状态�ƈ且通知�E�序不能�l�箋执行。�D个例子，�?/span> ARM, MIPS, �?/span> SH ��g�q�_��上，当操作系�l�被要求存取一个未寚w��数据旉��认通知应用�E�序一个异常�?/span>

寚w��?/span>
      寚w��性是一�U�内存地址的特性，表现为内存地址模上 2 的幂。例如，内存地址 0x0001103F �?/span> 4 �l�果�?/span> 3 �Q�这个地址��叫做与 4n �Q?/span> 3 寚w��Q?/span> 4 指出了所选用�?/span> 2 的幂的倹{��内存地址的对齐性取决于所选择的关�?/span> 2 的幂倹{��同��L��地址�?/span> 8 �l�果�?/span> 7 �?/span>

       一个内存地址�W�合表达�?/span> Xn �Q?/span> 0 �Q�那么就说该地址寚w��?/span> X �?/span>

       CPU 执行指��o��是对存储于内存上的数据�q�行操作�Q�这些数据在内存上是以地址为标记的。对于地址来说�Q�单独的数据会有其占用内存的字节数。如果它的地址寚w��于它的字节数�Q�那么就�U�C��该数据自然对齐，否则�U�Cؓ未对齐。例如，一个标�?/span> 8 字节的��Q�Ҏ��据的地址寚w��?/span> 8 �Q�那么这个数据就自然寚w��?/span>

数据寚w��性的�~�译处理
       讑֤��~�译器以一�U�防止造成数据未对齐的方式来对数据�q�行地址分配�?/span>

       对于单个的数据类型，�~�译器�ؓ其分配的地址是数据类型字节数的倍数。因此，�~�译器分配给 long 型变量的地址�?/span> 4 的倍数�Q�就是说�?/span> 2 �q�制表示地址的话�Q�最后两位�ؓ 0 �?/span>

       另外�Q�编译器以一�U�自然对齐每个结构成员的方式来填充结构体。参看下面的代码里面的结构体 struct x_ �?br />
     struct x_
      {
            char a;     // 1 byte
            int b;      // 4 bytes
            short c;    // 2 bytes
            char d;     // 1 byte
      } MyStruct;

      �~�译器填充这个结构以使其自然寚w��?br />
例如
      下面的代码说明了�~�译器是如何在内存中填充的�?br />
      // Shows the actual memory layout
      struct x_
     {
           char a;            // 1 byte
           char _pad0[3];     // padding to put 'b' on 4-byte boundary
           int b;            // 4 bytes
           short c;          // 2 bytes
           char d;           // 1 byte
           char _pad1[1];    // padding to make sizeof(x_) multiple of 4
     }

     两种定义在作sizeof(struct x_)�q�算都会�q�回12字节�?br />
      �W�二�U�定义含有两�U�填充成分：

             *char _pad0[3]使得int b �?字节边界上对�?br />
             *char _pad1[1]使得�l�构数组struct _x bar[3]寚w��?br />             填充使得bar[3]各个变量能够自然寚w��?br />
             下面的代码显�C�Z��bar[3]的内存结构：

              adr
              offset   element
------   -------
0x0000   char a;         // bar[0]
0x0001   char pad0[3];
0x0004   int b;
0x0008   short c;
0x000a   char d;
0x000b   char _pad1[1];

0x000c   char a;         // bar[1]
0x000d   char _pad0[3];
0x0010   int b;
0x0014   short c;
0x0016   char d;
0x0017   char _pad1[1];

0x0018   char a;         // bar[2]
0x0019   char _pad0[3];
0x001c    int b;
0x0020   short c;
0x0022   char d;
0x0023   char _pad1[1];

saga.constantine 2006-05-26 10:41 发表评论

saga.constantine — Thu, 25 May 2006 14:20:00 GMT

�?img border="0" height="19" src="http://www.shnenglu.com/Emoticons/car.gif" width="19" />转脓�Q?br />
所有中国黑客和�U�客�Q�我的同胞们�Q?
首先声明�Q�我的计��机软�g技术、黑客功底，可能不会比你们�Q何�h差：

我通读�q?MINIX�Q�TCP/IP�Q�BSD,LINUX, PL1的源码，我拿�q�中国高�U�程序员证书�Q�SUN 的JAVA证书�Q�精通VC和UNIX�Q�对�~�冲区溢出，病毒�Q�DDK�{�均有研�IӞ��所以我��x��有资格对你们说几句话�?

(如果我提到的一些计��机名词和�h名，你们居然不知道，那只能证明你们的无知�Q�和不配�U�Cؓ黑客�?

如果是真正的黑客�Q�他会知�?

1.发明TCP/IP的是��国�?�?

2. LINUX的作者，linus大侠现在也在��国工作 �?

3. OPEN SOURCE的开创�h STALLMAN 也是��国人，他提倡��Y件不分国界的自由的精��?�?

4. FREE BSD 的作者是��国人，他的SOURCE 让真正的黑客受惠

5.世界�U��Y件科学大�?tanabaom�Q�也是美国的客��教授�Q�他的minix, ameba和教材教育了全世界几代黑客�?

提到�q�些�Q�不是崇��，不是恐美�Q�只惌��明：

1.很多大师�U�的��国黑客�Q�他们的理念恰恰是自由、开放、无国界�Q�他们的自由软�g�Q�开放源码，是与政治无关的，是超��国界的�Q�给全世界�h们带来福韟�?

2.真正的黑客精��，如stallman所��_��是要让�h�c�超��计��机�Q�成��机的主宎ͼ�从而成��q��?

所有的中国黑客和红客，我的同胞们：

当你们正通过下蝲��国人写的黑客工��P��来攻�ȝ��国网�l�，�q�且乐此不疲�Q�以��是爱国行动的时候，是否惌��Q?

此时此刻�Q�印度的软�g人士�Q�正在努力提高��Y件技术，他们的��Y件水�q�뀁��Y件��业已�l�超��了中国�Q�难道我们不应该痛苦地承认这个现实，�q�且奋�v直追吗？

中国发明了火药，但是�~�少研究�_��Q�结果是被西方�h研究改进了以后打中国�Q�这��L��教训�q�少吗？

中国向来不缺爱国热情�Q�但是我们缺��对�U�技的认真研�I�精��，知耻而后勇的�q�赶�_��。难道我们不愿意承认�q�一点吗�Q?

从战术上来说�Q�过早暴露自��q��实力是不聪明的；冒昧地问一句，如果真的战争爆发了，您的黑客技术完全掌握好了吗�Q�您已经为那一天的到来在进行技术储备吗�Q?

您有没有惛_��那些真正��Z��国科技做出杰出贡献的科学家如钱学森学习呢？

所有的中国黑客和红客，我的同胞们：

��h��你们的聪明才智用到真正提高你们的水��^�Q�对国家的强大有帮助的地方吧�Q?

如果您愿意对国家有所贡献�Q?

1.中国�?63计划中有一个重点研�I��目： �q�行计算�Q�分布计��，向量计算。您愿意研究它吗�Q?

2. 作�ؓ��C��通讯技术的一个根本数学基��Q�大合数的快速因子分解，�q�是一个难题。您愿意研究它吗�Q?

如果您想提高技术，对中国的软�g技术有所贡献�Q?

1.研究 VC�Q�JAVA

2.研究数据�l�构�Q�去考高�U�程序员

3. 研究操作�pȝ��Q�读minix source code

4. 研究tcp/ip, rfc文��

5. 通读linux, 才算辑ֈ�黑客境界

6. 学习 UML�Q�ROSE�Q��Y件工�E�，辑ֈ��pȝ��分析员水�q��?

如果您对提高中国的科技有兴��，计算机技术，航天技术…�?

我的同胞们，我愿大声呐喊�Q?

一个真正的民族��M��者，不是义和团，不是太��^天国�Q�不是闭关锁国，不是盲目仇外�Q�不是不敢正视自己民族和文化的丑陋和�~�点�?

真正的民族主义者是成熟的、清醒的、理智的、务实的民族��M��。真正的民族��M��者不是种族主义者，不是极端份子�Q�不是战争狂人�?

真正的民族主义者以�q�求本民族——中华民族的利益最大化为目标、准则、信��c��判断一个�h是不是真正的民族��M��者，判断标准很简单：看他是给本民族的整体利益带来好处�Q�还是损��x��族利益。真正的民族��M��者最务实�Q�因��Z��知道坚持原则�Q�同时又懂得�{�略。让我们成�ؓ真正的顶��黑客！让我们成为真正的民族��M��?

saga.constantine 2006-05-25 22:20 发表评论

久久久久九国产精品,中文字幕无码免费久久,18禁黄久久久AAA片

[转蝲]windows消息分流�?

[转蝲]用户层下拦截�pȝ��api的原理与实现

[攉���]关于汇编80X87FPU���点�q�算

�?img border="0" height="19" src="http://www.shnenglu.com/Emoticons/car.gif" width="19" />转脓�Q?br />所有中国黑客和�U�客�Q�我的同胞们�Q?首先声明�Q�我的计���机软�g技术、黑客功底，可能不会比你们�Q何�h差：

[攉��]关于汇编80X87FPU��点�q�算

�?img border="0" height="19" src="http://www.shnenglu.com/Emoticons/car.gif" width="19" />转脓�Q?br />
所有中国黑客和�U�客�Q�我的同胞们�Q?
首先声明�Q�我的计��机软�g技术、黑客功底，可能不会比你们�Q何�h差：