首先是开发包的安装：
1.安装Python
2.下载pefile，将得到的压缩包解压到python\lib\site-packages文件夹中
3.在命令行窗口，使用cd命令进入到解压出来的pefile文件夹中，执行python setup.py install
下面，我会使用代码分析的方式描绘出这个工具的工作流程。

一般来说，程序中的数据越无序，其熵值也越高，这个程序文件被加壳或混淆的可能性也越大。熵值的范围在0.0到8.0之间。更详细的介绍在这里http://blog.dkbza.org/2007/05/scanning-data-for-entropy-anomalies.html。

PEID的用户数据库(userdb.txt)在这里http://www.peid.info/BobSoft/Downloads.html下载。

这里用Sophos里包含的命令行式的扫描工具进行程序分析。

其他信息在代码及注释中已经表达得很清楚了。完整的代码如下所示：

来源：http://hooked-on-mnemonics.blogspot.com/2010/04/creating-your-own-virustotal-well-kind.html

O(1)

如果算法的执行总是需要相同的时间（或空间），而与输入数据的规模无关，那这个算法的复杂度为O(1)

O(N)

复杂度为O(N) 的算法，其执行所需的时间或空间呈线性增长并与输入数据的规模成正比。下面的例子说明了Big O应用在最坏情形下：在for循环的任何一次迭代中，匹配的字符串都可能被提前找到并使函数返回，但是Big O概念表示的是最坏情形下的算法复杂度，所以总是假定算法执行上限次数的运行，即最大次数的迭代。

O(N²)

O(N2)表示算法的复杂度与输入数据的规模的平方成正比。这在涉及嵌套循环的算法中常见。更深层次的循环则会使复杂度增加为O(N³), O(N⁴)……。

O(2^N)

O(2^N)则表示算法随输入数据规模的每增加一个，其复杂度也会翻番。其执行时间也会迅速地增加。

对数复杂度O(log N)

下面会通过一个例子说明对数复杂度。

二分法搜索（Binary search）是一项用于搜索已排序数据的技术。它通过选出数据的中项，与目标数值相比较。如果两数值相匹配，则返回成功。如果目标数值大于中项，则取出数据集合中大于中项的部分进行上面的操作。类似地，如果目标数值小于中项，则取出小于中项的部分进行相同的操作。这样，程序不断地二等分分数据集合，直到数值匹配或数据集合无法分解为止。

这种算法被描述为O(log N)。

重复地二等分数据集合的过程，如果绘制成图表，会发现开始时会达到一个顶峰，然后随着数据的增加，曲线会逐渐趋向平缓。使数据集合加倍对效率的影响也会很小，因为在一次迭代之后，所需处理的数据量会减少一半。这样使算法在处理规模较大的数据集合时会非常有效率。

内存管理是操作系统的核心；无论对于编程还是系统管理来说，内存管理都非常重要。在以后的几篇文章中，我将着眼于内存的实际应用方面，但是并不回避其内部机制。概念都是相通的，例子大部分来自于32位 x86平台上的Linux和Windows操作系统。第一篇文章讲述程序在内存中是如何安排的。

Each process in a multi-tasking OS runs in its own memory sandbox. This sandbox is the virtual address space, which in 32-bit mode is always a 4GB block of memory addresses. These virtual addresses are mapped to physical memory by page tables, which are maintained by the operating system kernel and consulted by the processor. Each process has its own set of page tables, but there is a catch. Once virtual addresses are enabled, they apply to all software running in the machine, including the kernel itself. Thus a portion of the virtual address space must be reserved to the kernel:

在多任务的操作系统中，每个进程运行在自己的内存沙盒中。这里的沙盒是指虚拟地址空间，在32位模式中，虚拟地址空间总是一个4GB大小的内存地址块。虚拟地址通过页表映射到物理内存上，页表由操作系统内核维护并由处理器查看。每个进程有它自己的页表集合，但是这里有个圈套。一旦虚拟地址启用，即被用到机器中的所有正在运行的软件上，包括内核本身。因此，一部分虚拟地址空间必须保留给内核：

This does not mean the kernel uses that much physical memory, only that it has that portion of address space available to map whatever physical memory it wishes. Kernel space is flagged in the page tables as exclusive to privileged code (ring 2 or lower), hence a page fault is triggered if user-mode programs try to touch it. In Linux, kernel space is constantly present and mapped to the same physical memory in all processes. Kernel code and data are always addressable, ready to handle interrupts or system calls at any time. By contrast, the mapping for the user-mode portion of the address space changes whenever a process switch happens:

这并非说明内核使用那块物理内存，只是说内核把那部分可用地址空间映射到它所希望的物理内存上。在页表中，内核空间只被标记为特权代码（privileged code ）(ring 2或更低），因此如果是用户模式下的程序试图执行它，一个页错误即被触发。内核代码和数据总是可寻址的，时刻准备处理中断或系统调用。相比之下，无论何时一个进程切换发生，用户模式下的部分地址空间即发生变化：

Blue regions represent virtual addresses that are mapped to physical memory, whereas white regions are unmapped. In the example above, Firefox has used far more of its virtual address space due to its legendary memory hunger. The distinct bands in the address space correspond to memory segments like the heap, stack, and so on. Keep in mind these segments are simply a range of memory addresses and have nothing to do with Intel-style segments. Anyway, here is the standard segment layout in a Linux process:

蓝色区域代表被映射到物理内存的虚拟地址，而白色区域并未被映射。上面的例子中，Firefox用掉了属于它的绝大部分虚拟地址空间，因为它是有名的内存吞噬者。地址空间中这些区分开来的条带对应着内存区段，比如堆，栈等等。记住，这些区段只是一块内存地址区域，并且和Intel式区段(Intel-style segments)无关。总之，下面是一个Linux进程的标准区段布局：

When computing was happy and safe and cuddly, the starting virtual addresses for the segments shown above were exactly the same for nearly every process in a machine. This made it easy to exploit security vulnerabilities remotely. An exploit often needs to reference absolute memory locations: an address on the stack, the address for a library function, etc. Remote attackers must choose this location blindly, counting on the fact that address spaces are all the same. When they are, people get pwned. Thus address space randomization has become popular. Linux does this for the stack in randomize_stack_top(), while the start of the memory mapping segment is shuffled around by mmap_base(). Unfortunately the 32-bit address space is pretty tight, leaving little room for randomization and hampering its effectiveness.

当计算欢快、安全的进行时，对于机器中几乎所有的进程来说，上图的区段起始虚拟地址都是完全相同的。这就让远程地利用(exploit)安全漏洞变得容易。一个利用经常需要引用绝对内存位置：栈上的地址，比如一个库函数的地址等等。远程攻击者必须以无分别的方式(blindly)来选择这个位置，依靠地址空间相同这个事实。当他们找到了这个地址，人们就输了。因此地址空间随机化变得流行起来。Linux通过随机化栈top()randomize_stack_top()为栈做到了这点,用 mmap_base()函数打乱内存映射区段的起始位置。不幸的是32位地址空间非常紧凑，致使留给用来随机化的空间几乎没有，约束了它的作用。

The topmost segment in the process address space is the stack, which stores local variables and function parameters in most programming languages. Calling a method or function pushes a new stack frame onto the stack. The stack frame is destroyed when the function returns. This simple design, possible because the data obeys strict LIFO order, means that no complex data structure is needed to track stack contents – a simple pointer to the top of the stack will do. Pushing and popping are thus very fast and deterministic. Also, the constant reuse of stack regions tends to keep active stack memory in the cpu caches, speeding up access. Each thread in a process gets its own stack.

进程地址空间最顶层的区段是栈，它存储了大多数编程语言形式的局部变量和函数形参。调用一个方法或函数，就会把一个新的栈帧推入到栈中。当函数返回时，这个栈帧就被销毁。这个简单的设计，可能是因为数据遵循严格( LIFO)的后进先出的顺序，这意味着没有复杂的数据结构需要跟踪栈内容-一个简单的指向栈的指针就能做到这点。因此入栈和出栈是非常快和必然可行的。并且，栈区域的不断地重用以使cpu缓存中(cpu caches)的栈内存保持活跃，加速了存取。一个进程的所有线程都有自己的栈。

It is possible to exhaust the area mapping the stack by pushing more data than it can fit. This triggers a page fault that is handled in Linux by expand_stack(), which in turn calls acct_stack_growth() to check whether it’s appropriate to grow the stack. If the stack size is below RLIMIT_STACK (usually 8MB), then normally the stack grows and the program continues merrily, unaware of what just happened. This is the normal mechanism whereby stack size adjusts to demand. However, if the maximum stack size has been reached, we have a stack overflow and the program receives a Segmentation Fault. While the mapped stack area expands to meet demand, it does not shrink back when the stack gets smaller. Like the federal budget, it only expands.

通过让超出栈所能承载的数据入栈，以此来耗尽映射到栈的空间是可能的。这会触发一个页错误，它由Linux中的expand_stack()函数控制，这个函数反过来调用acct_stack_growth() 函数检查增长栈是否合理。如果栈的大小低于RLIMIT_STACK(通常8MB)，栈就会正常地增长，程序也会顺利执行，对刚才发生了什么毫无知觉。这是正常的机制，栈大小借此调整以满足需要。然而，如果已经达到了最大的栈大小，就会发生栈溢出，程序会收到一个分段错误。当被映射的栈空间扩充到满足需要时，即使栈变小，它也不会收缩。就像联邦预算，只会增加。

Dynamic stack growth is the only situation in which access to an unmapped memory region, shown in white above, might be valid. Any other access to unmapped memory triggers a page fault that results in a Segmentation Fault. Some mapped areas are read-only, hence write attempts to these areas also lead to segfaults.

动态栈增长是唯一的情形下，读取一块未被映射的内存区域（上图白色区域）可能是有效的。以其他任何方式对未被映射的内存读取，都会触发一个页错误，从而导致分段错误。一些被映射的区域是只读的，因为尝试对这些区域进行写操作也会导致分段错误。

Below the stack, we have the memory mapping segment. Here the kernel maps contents of files directly to memory. Any application can ask for such a mapping via the Linux mmap() system call (implementation) or CreateFileMapping() / MapViewOfFile() in Windows. Memory mapping is a convenient and high-performance way to do file I/O, so it is used for loading dynamic libraries. It is also possible to create an anonymous memory mapping that does not correspond to any files, being used instead for program data. In Linux, if you request a large block of memory via malloc(), the C library will create such an anonymous mapping instead of using heap memory. ‘Large’ means larger than MMAP_THRESHOLD bytes, 128 kB by default and adjustable via mallopt().

在栈的下方，是内存映射段。这里，内核把文件内容直接映射到内存中。任何应用程序可以通过系统调用Linux的mmap()(implementation)或 Windows中的CreateFileMapping() / MapViewOfFile()。进行文件的I/O，内存映射是一种方便并且高效的方式，因此它被用作加载动态库。创建一个匿名内存映射，它不对应任何代替程序数据被使用的文件，这样也是可行的。在Linux中，如果你通过malloc()请求一大块内存，Ｃ库就会创建一个匿名映射，而不是使用堆内存。“大”表示大于MMAP_THRESHOLD字节，默认下是１２８ＫＢ，可通过 mallopt()调节。

Speaking of the heap, it comes next in our plunge into address space. The heap provides runtime memory allocation, like the stack, meant for data that must outlive the function doing the allocation, unlike the stack. Most languages provide heap management to programs. Satisfying memory requests is thus a joint affair between the language runtime and the kernel. In C, the interface to heap allocation is malloc() and friends, whereas in a garbage-collected language like C# the interface is the new keyword.

接下来，再说说地址空间中的堆。像栈一样，堆提供运行时内存分配，不同于栈的地方是，分配在堆中的数据必须比分配给函数的空间存活的更长久。大多数语言提供堆管理给程序。

因此，满足内存需要成了语言运行时和内核共同的任务。在Ｃ语言中，堆分配的接口是 malloc() 和friends，然而在有垃圾收集功能的语言中，比如Ｃ＃，则是一个新的关键字。

If there is enough space in the heap to satisfy a memory request, it can be handled by the language runtime without kernel involvement. Otherwise the heap is enlarged via the brk() system call (implementation) to make room for the requested block. Heap management is complex, requiring sophisticated algorithms that strive for speed and efficient memory usage in the face of our programs’ chaotic allocation patterns. The time needed to service a heap request can vary substantially. Real-time systems have special-purpose allocators to deal with this problem. Heaps also become fragmented, shown below:

如果在堆中有足够的空间满足对内存的需要，那么这个任务就交由语言运行时处理，而不需要内核的介入。否则，就要借助系统调用brk()(implementation)使堆增大。堆管理是复杂的，在面对程序混乱的分配模式时，要求精细高效的算法和内存使用。执行堆的分配要求所需要的时间可以有很大的不同。实时系统有特殊用途的分配器来解决这个问题。堆也是成碎片状的，如下图所示：

Finally, we get to the lowest segments of memory: BSS, data, and program text. Both BSS and data store contents for static (global) variables in C. The difference is that BSS stores the contents of uninitialized static variables, whose values are not set by the programmer in source code. The BSS memory area is anonymous: it does not map any file. If you say static int cntActiveUsers, the contents of cntActiveUsers live in the BSS.

最后，我们来了解最底层的内存分段：BSS，数据和程序本身。BSS和数据存储C语言中的静态（全局）变量中的内容。不同的是，BSS存储未初始化的静态变量，即变量的值未在程序源码中被设置。BSS内存区域是匿名的：它不映射任何文件。如果有static int cntActiveUsers这样的代码，则cntActiveUsers中的内容存储在BSS中。

The data segment, on the other hand, holds the contents for static variables initialized in source code. This memory area is not anonymous. It maps the part of the program’s binary image that contains the initial static values given in source code. So if you say static int cntWorkerBees = 10, the contents of cntWorkerBees live in the data segment and start out as 10. Even though the data segment maps a file, it is a private memory mapping, which means that updates to memory are not reflected in the underlying file. This must be the case, otherwise assignments to global variables would change your on-disk binary image. Inconceivable!

另一方面，数据段存储初始化了的静态变量。这个内存区域不是匿名的。它映射了部分程序的二进制映像，映像包含了已经在源码中初始化了的静态值。如果有static int cntWorkerbees=10,则cntWorkerbees中的内容存储在数据段中，并且初始值为10。即使数据段映射了文件，也是一个私有内存映射，即在基本的文件（underlying file）中，内存数据的更新并不受影响。这是必须的，否则全局变量的赋值将改变硬盘上二进制映像的数据。难以置信！

The data example in the diagram is trickier because it uses a pointer. In that case, the contents of pointer gonzo – a 4-byte memory address – live in the data segment. The actual string it points to does not, however. The string lives in the text segment, which is read-only and stores all of your code in addition to tidbits like string literals. The text segment also maps your binary file in memory, but writes to this area earn your program a Segmentation Fault. This helps prevent pointer bugs, though not as effectively as avoiding C in the first place. Here’s a diagram showing these segments and our example variables:

在示意图中，数据段的例子比较巧妙，因为其使用了一个指针。在这种情况下，指针gonzo的内容-一个4字节的内存地址-存储在数据段中。而指针所指的实际字符串却不在其中。这个字符串存储在正文段中。正文段是只读的并且存储所有的代码，外加其他一些琐碎的东西比如字符文字量。正文段也映射二进制文件，但是对这个区域进行写操作会导致程序发生段错误。这有助于防止指针bug的发生，当然起先就不使用C则更好。下面的图表描述了段和变量的对应关系:

You can examine the memory areas in a Linux process by reading the file /proc/pid_of_process/maps. Keep in mind that a segment may contain many areas. For example, each memory mapped file normally has its own area in the mmap segment, and dynamic libraries have extra areas similar to BSS and data. The next post will clarify what ‘area’ really means. Also, sometimes people say “data segment” meaning all of data + bss + heap.

你可以通过读取文件/proc/pid_of_process/maps来检视一个Linux进程的内存区。注意，一个段可能包含许多区。例如，每块映射到文件的内存，在mmap段中有属于自己的区，并且动态库有额外的区，类似于BSS和data段。下一篇文章会澄清“区”的真正含义。而且，有时所说的“数据段”意指所有的data+bss+heap。

You can examine binary images using the nm and objdump commands to display symbols, their addresses, segments, and so on. Finally, the virtual address layout described above is the “flexible” layout in Linux, which has been the default for a few years. It assumes that we have a value for RLIMIT_STACK. When that’s not the case, Linux reverts back to the “classic” layout shown below:

你可以通过使用nm 和 objdump命令检视二进制映像，来显示符号，地址，段等等。最终，上面所描述的虚拟地址的排布，在Linux中是“可变通的”排布，它作为默认情形已有好多年。它假设RLIMIT_STACK有一个值。当不是这样时，Linux则恢复经典排布，如下图：

That’s it for virtual address space layout. The next post discusses how the kernel keeps track of these memory areas. Coming up we’ll look at memory mapping, how file reading and writing ties into all this and what memory usage figures mean.

这就是虚拟地址空间的布局。下一篇文章会探讨内核如何跟踪内存区域，接着就是内存映射，文件如何读取和写入连接（ｔｉｅｓ）到内存中，还有内存使用数字（memory usage figures)是什么意思。

主页：http://code.google.com/p/ccons

reddit

1.2

(/ (+ 5 4 (- 2 (- 3 (+ 6 (/ 4 5)))))
    (* 3 (- 6 2) (- 2 7)))

1.3

 (define (big_num a b c)
  (cond ((> c (cond ((> a b) a
                     (else b)))
            c)
         (else (cond ((> a b) a
                      (else b)))))))

1.4 略

1.5 略

作者将bug的种类分为4种类型:mechanical（无意识型）, mental（思维型）, social（群体型） 和 environmental（环境型）。对这4种类型分别给出它们的成因，以及预防措施。

无意识型错误

这种类型的错误发生原因通常是，程序员因为注意力降低或“下意识”的习惯性错误，比如把经常写的某个单词用在错误的地方。这种错误和程序员的编程水平关系不大。解决方法或工具如下：

语法检查器
许多IDE都会提供语法检查功能。除了IDE以外，为C++提供这个功能的工具有：

• vim

代码嗅探器（Code Sniffers）
检查代码是否符合编码规范的工具(C++好像没有？）

同行评审
让你的代码被另一个程序员评审

思维型错误

主要为逻辑错误，比如边界条件和边缘情况(edge case)。这些错误起初不易被觉察，只有当碰到非常态，或被赋予意外的输入时才会被发现。用如下方法或工具可以防止其发生：

单元测试
写单元测试有两个优点：1.可以让程序员在写单元测试时，发现写代码时不曾觉察的边缘情况。2.更重要的一点，让已经发生的错误不出现在以后的开发中

• cppunit

代码格式化
让代码符合可视形式匹配。自动格式化工具可以做到这点

群体错误
群体错误更像是发生在多个开发者身上的思维型错误，也是不容易察觉

测试驱动开发/行为驱动开发（Test Driven Development/Behavior Driven Development）
TDD说白了就是在实现功能前，编写单元测试。用到的工具有

• Mockpp

编写文档（Doc Comments）

总体设计/团队计划(Big Design Up Front / Team Planning)
让意见之间的矛盾在计划的过程中解决，这可以使目标一致，减少错误。
在开发过程中，通过wiki或在线文档编辑保持文档的实时性(live)，当计划有所改变时，可以及时反映到文档说明中。

环境型错误
这种错误发生在代码以外-可能是在语言，操作系统，服务器或是网络的层面上，也是难以察觉，只有当某个因素被触发，比如过高的负载量，它才能被发现。

开发和试验(Development and preproduction)
使用虚拟机

加载测试(load testing)

Cross-functional team
拥有不同专长的人为同一个项目工作。

总结
作者介绍了一本书，Human Error by James Reason，里面很好地讲述了人们怎样犯错和为什么会犯错。