单独列个帖。。。。
埋里面不好。。。。

辛苦!!!

欢迎修正。。。
欢迎跟帖。。。
继续翻译。。。
呵呵。。。。。

最初由 4nil 发布
欢迎修正。。。
欢迎跟帖。。。
继续翻译。。。
呵呵。。。。。

写壳 是如今蛮热门的一技术，谢谢翻译！

感谢并支持一下！

不错

期待下一部分。

支持

随便写一点，bug多多。。。。。。。。。。。。。。。。

Choice of Compressor
压缩选择

You can pretty much use whatever compressor library you want, so long as you build it in a way that doesn't spew out stuff via printf or other UI functions. There are plenty free compressors out there. You might want to start with something like zlib. It won't give you the best compression, but I know it works in this scenario. Also, another is UCL. This compresses better and is much smaller code-wise. It is GPL, however, and maybe you care about the licensing implications.
你可以选择自己喜欢的压缩库，获取他们的输出以供使用。现在有很多免费的压缩器。你或许打算采用zlib压缩库。这个压缩比并非最高，但是对我们来说比较适用（译注：估计是免费，使用也方面什么的）。另外一个叫做UCL的，这个压缩比更好，并且代码更加优化。但是这个是GPL，存在版权问题。

Check the docs to the compressor you want for configuration options and related stuff. For example, BZip2 requires BZ_NO_STDIO to be defined to have no printf stuff.
检查一下你所采用的压缩库的文档。例如，BZip2需要BZ_NO_STDIO来定义成不显示输出结果。

Configure the build to be compatible with the stub and compression library. For me, I disable RTTI and make sure I am linking the static runtime library, multithreaded. I optimize for size. The output should produce a static library, of course, rather than a dll, since the goal is to add no dependencies beyond the apps original ones.
配置好相应压缩库的初始资源。例如我这里，取消了RTTT并且连接上静态运行库，多线程，优化大小。这样便可以得到一个静态库，请注意不是一个DLL，因为我们不希望在在引入表里面显示（译：这句话有点深。。。）

Setting Up Projects -- and now for something completely different
设定工程 -- 以及一些明显不同的地方

OK, I am going to take a brief break from code and technological stuff and talk about project configuration. Normally I wouldn't since that's a personal choice, however this time I will because things I talk about later will be dependent upon some of the configuration assumptions. In real life you don't have to do it this way, but let's temporarily pretend we are and at the end of this series you'll know how you might like to do it different.
现在，我们不谈代码和技术，说一下工程配置。因为每个人都可能有自己的配置选择，而且我们下面的工作将会和这些配置选项有关。一般你或许不这么做，但是我们不妨尝试这么做一下，你就会明白这么做的好处。

Big picture is that there will be two projects, producing two distinct executables -- the packer stub and the packer application. Their configuration will be significantly different.
大的方向是2个工程，处理2种不同的可执行文件 --- 局部加壳和全部加壳。这2种配置有很大的区别。

We are going to do a bit of ledgerdemain with the stub project which will be explained later, but for now, configure a boiler plate project for your stub thusly:
现在说一下suub部分的配置：

* Produce a DLL
建立DLL
* Use static multithreaded runtime libraries
采用静态多线程运行库
* Disable RTTI and exception support
禁用RTTT和异常支持

If there are options for the boilerplate code it generates, make it simple, so that there is just DllMain being implemented. We're going to throw all that away anyway. Go ahead and build it as a sanity check, which should go through fine.
如果采用的样本代码有选项，那就尽量让他简单点，这样仅配置DLLMain就可以了。我们打算把这些多余的东西抛到一边，做一个比较完善的检测，就可以继续往下。

We're making the packer stub a DLL not because it will ultimately be a DLL -- it won't. We're doing this because we want the relocation records. You _can_ create it as an exe project and cause it to have relocation records (linker option /FIXED:no), but I find the Microsoft's linker will crash randomly in that configuration. Stick with the DLL config and you'll be OK.
之所以把局部加壳做成一个DLL，并非因为它只能是DLL，而是因为我们需要局部纪录。你也可以把它做成一个exe工程，并且让他有局部纪录（linker选项中/FIXSD: no），但是我发现M$的linker有时候会因此崩溃。处理好DLL配置，然后继续。

Next, change the config thusly (this is for Microsoft's tools, you'll have to look up the equivalents for Borland's or gcc):
下一步，配置编译选项（这里说的是M$工具，你可以自己查一下Borland和gcc相关部分）：

Linker options:
Likner 选项：

add any library paths your compressor lib will be needing
/nodefaultlib don't use default libs
/map(filename) DO generate a mapfile
remove /debug don't generate debug info
change /incremental:yes to /incremental:no disable incremental linking
添加压缩库的路径需要/nodefaultlib ，请不要采用默认库
/map(filename) 创建映象文件
移除 /debug 将不会创建debug信息
把/incremental 改变为 no， 将禁用增量连接

Compiler options:
编译选项：

add any defines or header paths your compressor lib will be needing
/FAcs generate listing files with source, assembly, and machine code
/Fa(filename) specify where these listings go
remove /GZ compiler-generated stack checks
remove any debug options, it won't help us where we're going
加入压缩库需要的定义和头文件路径
/FAcs 指定列出的代码文件，汇编和机器指令
/Fa(filename) 指定列表指向的文件
禁止 /GZ 编译选项 -- 指定堆栈检查
禁止任何Debug选项，因为这些对我们没有什么帮助

these options are probably available as checkboxes, so you won't have to manually add them.
这些选项一般都可以在GUI界面看到，因此也不必手工添加。

The gist is that we are not going to have normal debug capabilites so we turn off that stuff. Instead, we will be relying on the listing of the compiler-generated assembly to see code and the linker-generated mapfile to see actual addresses. All this is interesting stuff in any project really, but it is all we have for debugging in this one.
由于不需要一般的调试功能，因此我们关闭他们。但是我们需要借助编译器察看汇编代码，和用于察看代码地址的连接选项。在一般的项目看来这些都不比要，但对我们来说这些比较重要。

If you build now you will should get a linker error complaining about an unresolved external symbol DllMainCRTStartup@12. This is good! If you don't get that then the default libs are coming in. The symbol is possible different for Borland stuff. Other errors probably mean something else needs to be fixed; this is the only one you should get for Microsoft's compiler.
如果你建立创建项目，你或许会碰到类似错误提示：linker error complaining about an unresolved external symbol DllMainCRTStartup@12。这是正常的！如果你没有引入这个文件，系统会引入默认的库文件。在Borland编译环境下，调试符号或许有所不同。其他的错误或许是因为别的文件没有配置好。但M$编译器只会出现上面说到的错误。

Runtime dependencies
运行辅助

You cannot assume what runtime dependencies the original app has. Thus, you cannot make calls to funky dlls (vbrunX.dll, etc). You have no idea if they are there. You will do well to statically link your runtime library. You will do much (much) better, however, to not link any runtime libraries at all! ASM coders will take delight in this fact already, because they are hard-core, but this need not dissuade the C/C++ coders who are accustomed to malloc() strcmp() new std::vector<> or such. All this is doable. You will just have to provide your own implementation of these functions. Fortunately, this is pretty easy since you can call native functions exported by Kernel32.dll. /That/ dll is certainly present, and certainly one that is already used by the original app you are packing so feel free to use it when you like.
很难想象到被加壳程序运行时需要设计的其他文件。因此，你不能处理一些相关Dll文件（例如vbrunX.dll）。如果存在这些东西，我们也无能为力。你所作的是尽量处理好静态连接库。你或许会做的更好，而不需要连接运行库！事实上汇编程序员更乐意处理这些东西，因为他们受到的限制比较少，但并不是说要打击那些使用malloc() strcmp() new std:vector<>
等等的C/C++程序员。因为所有这些都可以完成工作，你只需要提供正确的函数就可以了。幸运的是，有了Kernel32.dll提供的函数，这些工作变得比较简单。由于被加壳软件肯定引用这个DLL，因此只要你愿意，可以处理这个dll。

Making a Trivial C Runtime to Link Instead of the Proper One
写一个小的 C 运行库进行连接而不是采用合适的（译注：这句话有点深。。。）

Replacing the C Runtime might sound scary but remember we only want to implement what is necessary; this will turn out to be a small set of things. The linker will help you figure out what these are. Recall that we turned off default library searching with the /nodefault switch (or equivalent for your linker, that's for Microsoft's). If you configured as I suggested above, we've got a linker error already: DllMainCRTStartup@12 We'll fix that one first.
替换C运行库或许听起来有点恐怖，但是由于我们仅仅处理需要的部分，因此工作量其实比较小。连接器可以提供一些相关帮助。请注意我们关闭了用于搜索默认库的 /nodefault 选项（对于M$编译器有其它相关选项）。由于按照我上面讲解的进行配置，那么就很正常会出现编译错误：
DllMainCRTStartup@12 We'll fix that one first.

Discard your boiler-plate DllMain. Replace it with:
扔掉那写破烂DllMain，用下面的进行替换：

BOOL WINAPI _DllMainCRTStartup ( HANDLE, DWORD, LPVOID )
{
//(program will go here)
return TRUE;
}

This should resolve the linker error and will be our entry point. The place our program will ultimately go is indicated by the comment. Ultimately we'll never hit the 'return TRUE' statement; it's just there to make the compiler happy, and the function signature is what it is to make the linker happy.
这段代码可以解决掉那个连接错误，同时也是程序入口。注释的地方就是程序的入口。这里返回的TRUE不需要再次改动，因为他仅仅被用来满足编译要求，并且前面的函数标记也是为了满足连接要求。

If you want to be more arty, you can do the following:
如果你想看起来更气派一些，不妨采用下面的：

#pragma comment ( linker, "/entry:\"StubEntryPoint\"" )
void declspec ( naked ) StubEntryPoint() {
//(program will go here)
}

which is syntactically clearer.
这样看起来更明了一些。

This is cosmetic so don't feel bad if you find the equivalent pragmas for your compiler/linker. Also, this perverts what the compiler normally thinks about and I have seen it crash randomly. I have found when the compiler gets in a crashing mood, that putting in:
这些并非是一成不变的，所以如果看到其他类似参数也是很正常的。并且这和一般编译器编译情况不太一样，所以经常会碰到崩溃的时候。我发现当编译器崩溃的时候，一般都会出现以下情况：

asm nop

in a couple places seems to get it back on track. Ain't that a laugh?! Whatever...
在2个看起来需要返回的地方。xxxxxx(译注：理解不了。。。。。，好像是淫笑之类)

As code is added, you should periodically build. The linker will add more and more complaints like above and we will have to implement the underlying methods the compiler is emitting references to. Here's a tip: when you installed your dev tools, you may have had the option to install the source to the C Runtime. It will be helpful in some cases since you can cut and paste some parts. In particular, a function:
随着代码的增加，你需要定期进行检测。连接器将会出现一些类似于上面的错误并且我们或许不得不严格采用编译器所要求的方法。这里有一条经验：当安装开发工具的时候，你或许注意到要求安装C运行库代码的选项。有时候的确或许会对其中一部分进行操作。一般来说，一个函数:

extern "C" declspec ( naked ) void _chkstk(void)

is sometimes emitted by the compiler quietly (if you have a large array on the stack, like for a buffer). Just cut-and-paste that one; it's funky.
有时候会被编译器进行扩展（如果你在堆栈中定义了一个大的数据，例如缓冲区）。只需要剪切/粘贴那段，这是很有趣的。（译注：这句也有点深。。。。。）

FYI, I typically have to implement:
一般，我会使用以下操作：

memcpy
memset
memcmp
malloc
free
realloc
calloc
operator new ( unsigned int nSize )
operator delete ( void* pv )

To get you going on what it means to do this sort of roll-your-own-C-runtime, please see the following article. It's good and will save me from repeating the infomation here. There's sample implementation as well.
其它常用函数可以参考下面的文档，我这里不再嗷述。

Reduce EXE and DLL Size with LIBCTINY.LIB
http://msdn.microsoft.com/msdnmag/i...od/default.aspx

OK, we're now setup to do the work!
好了，现在我们开始正式工作！

Unpacking Stub Responsibilities
解压部分的工作

I mentioned way back that the stub has the following duties:
我重新说以下这部分需要做的工作：

* Find the packed data
* Restore data contents
* Perform relocation fixups, if needed
* Resolve all imports since the Windows loader couldn't do it
* Perform thread local storage duties since the Windows loader couldn't do it
* Boink over to the original program
* You may also have to handle being reentered if you are packing a dll
找到压缩数据
重新存储数据内容
如果需要的话，重定位他们
解决Windows不能处理的输入表
解决WIndows不能处理的线程局部存储
Boink over to the original program
如果对DLL文件加壳，还需要处理相关句柄

It's important that the stub restore the original data to it's exact original location. This is because we don't know about what references are in the original code to things like global data structures and functions pointers in things like vtables.
将原始数据存储到附加部分是很重要的。因为我们不知道原始代码中针对全局结构和函数指针的接口。

Recall that the format of the PE file (links to good discussions were provided in the previous installment) is organized into sections, which have a location and size. This information is stored in the section headers, which describe where the sections go in memory (relative to the load address).
PE文件格式（上面的安装部分已经讨论过）由区段组成，这些区段都有地址和大小。这些信息都被保存在文件头。

To do this properly, we will be needing to know our load address. If we are a stub for an exe we can simply do a GetModuleHandle(NULL) and the returned module handle is the base load address. This won't work for a dll however. The module handle for the dll is on the stack. We can write some code to get it, or we can choose not to do the 'arty entry point' and it is referenceble as a parameter (do not attempt to reference those parameters if it is the stub for an exe unless you are fond of crashes).
为了确保正确，我们需要知道加载地址。如果是针对exe文件，那么GetModuleHandle(NULL)就可以返回加载地址。但是对于DLL文件却不可以这样做。DLL文件模块的句柄存放在堆栈中。我们可以写代码获取他，或者可以选择不处理这些“气派的入口”（译：有点深。。。，就是说不处理）并且让他作为参数入口（如果是exe文件，不要试图处理这些参数，否则会导致崩溃）。

My preferred technique, however, is to get the packer application to help me out. That way the same stub works for exes and dlls and in the same way. It involves a global variable, and there are going to be several of those, so let me discuss that first.
然而我比较倾向于让壳程序帮助我处理这个事情。如此一来，对于exes和dlls，头文件都是一样的。这涉及到一个全局变量，并且会有很多此类变量，所以我们先来讨论这个。

Packer Parameter Globals
壳的全局变量

There are going to be parameters that are computed by the packing application and that will be embedded in the stub so it can do it's work at runtime. These require a bit of special handling because the packer application needs to find these items at pack time. You could hard-code in the addresses into the packer. You would get these addresses from the mapfile generated by the linker. This is a bit tacky because you will have to double check it each time you alter the stub, which will be quite frequently while developing. Instead, I prefer to do a bit of legerdemain with structures, sections, and segments. This only needs to be done for the variables published to the packer. Regular globals you might want to have can be done as usual without concern.
壳程序会计算出很多参数并且放置在文件头中以供运行时候使用。这需要一些特殊的句柄，因为加壳程序在加壳时需要查找相应资源。你需要往壳相应地址中写入硬编码。这些地址可以用连接器提供的文件映象中获得。这种事情有点麻烦，因为每次改变该部分就需要检查2次，而且开发过程中这些事情都是很频繁的。如果不这样，可以在结构，区段和寄存器中是用一些小技巧，仅仅需要对壳中出现的变量进行处理就可以了。这样那些你需要的变量就会被自动处理。

First, simple stuff. I make one structure with all the important globals. Then one global instance of that structure. Thus there is only one object the packer has to locate at pack time. Let's call that structure:
首先，说一下基本素材。我写了一个关于重要变量的结构。然后定义了该全局变量的事例。这样，壳在加壳时候仅仅需要处理这个结构就可以了。这个结构如下：

//in a header, say GlobalExternVars.h
struct GlobalExternVars
{
//stuff goes here
};

Now we will do some kookiness in our main .cpp file:
然后我们在我们的 main.cpp 文件中作一些大的处理：

#pragma data_seg ( ".A$A" )
declspec ( allocate(".A$A") ) extern struct GlobalExternVars gev =
{
//initializers go here
};
#pragma data_seg ()

待续。。。。。。。。。。。。。

好象没翻译完，各位老大有最新翻译版吗？