应用程序实现方法的猜测今天将向大家介绍一个比较有意思的内容，应用程序实现方法的猜测。
日常生活和工作中，我们总会接触到各种应用程序，这些应用程序往往给我们带来的很大的便利。也许有的人对于如何实现这个应用程序的方法非常好奇，但是要分析具体的实现方法，大家可能会受到一些夸大言论的误导，导致认为要分析出结果有相当大的困难。 实际上，详细的分析的确是非常困难的，需要和逆向工程紧密联系。但是大多数情况下我们对一个应用程序的实现方法的关注可能更多在于这个应用程序是如何对操作系统进行调用的，理解了一些关键的调用以后，就能够对这个应用程序的实现方法有比较好的认识了。 在月初的时候，我曾经发布了一个增强型重命名工具：RenamePlus。这个工具的目的就是支持将任意文件、文件夹在正常文件名和非正常文件名之间进行相互转换，例如：
以往碰到这种问题，大家一般会采用文件扇区修改级别的编辑工具或者利用KB320081所说的方法进行操作。问题在于文件扇区级别的编辑工具或者KB320081所说的方法在操作上都有很大的难道，特别是文件扇区级别的磁盘编辑工具，很容易导致正常数据的丢失。RenamePlus 出来以后，得益于我在 RenamePlus 里面使用的一种方法，或者技巧，成功的实现了将任意文件、文件夹在正常文件名和非正常文件名之间进行相互转换的功能。 回到正题，RenamePlus 是怎么实现这个功能的，今天我将通过此文揭开 RenamePlus 的实现之谜，同时向大家介绍如何猜测应用程序的实现方法。
在 Windows 操作系统上运行的应用程序基本上都存在了一种叫做Portable Executable （PE）格式的文件格式类型。而PE格式的文件类型里面有一张表叫做输入表，输入表的用处就是告诉系统该应用程序需要哪些系统库函数或者第三方函数的支持。
根据输入表的信息，我们可以大致的知道该应用程序和哪些系统库函数或者第三方函数函数有关。前文说到，大多数情况下我们对一个应用程序的实现方法的关注可能更多在于这个应用程序是如何对操作系统进行调用的，而输入表就是帮助我们的一个利器。 要查看PE文件的输入表，需要一些PE相关的工具，例如：Microsoft 在 Visual Studio 里面带的 Depends 工具，或者其他的一些免费工具，如PE TOOLS等。这里使用PE TOOLS做演示。 用PE TOOLS打开RemovePlus.EXE，然后依次点击 Directory — Import Directory，就可以看到RenamePlus的输入表内容了，如图：
在上图里面，我们看到了RenamePlus.EXE所依赖的系统DLL是Kernel32.DLL，依赖的系统函数有 MoveFileW、GetLastError等。完整的列表如下所示：
如 果对Windows API比较熟悉，会发现在上述API调用里面，大多数是一些很常见的、也就是基本上每个应用程序都会使用到的API，例如像 HeapAlloc、VirtualAlloc 等和系统内存管理相关的 API，ExitProcess等和进程相关的API，TlsAlloc 等和线程相关的API，基本上所有的应用程序都会涉及。除去这些 API 以外，RenamePlus 实现其功能的关键 API 是哪一个呢？
既然是叫做 RenamePlus， 那么就和文件或者目录的改名操作相关，改名操作对于 Windows 来说，可以理解为就是一个目标的移动操作。搜索上述列表，果然有一个叫做 MoveFileW 的 API 函数和移动有点相关。查询 MSDN Library 以后，得知 MoveFile 的用处是：Moves an existing file or a directory, including its children。The MoveFile function will move (rename) either a file or a directory (including its children) either in the same directory or across directories. 根据微软的描述，MoveFile 是能够作为改名使用的。 没错，RenamePlus 功能实现的关键性API就是MoveFile。 我们继续，MoveFile 会接收2个参数：源路径和目标路径。没啥特殊的。我们现在知道了 RenamePlus 是利用 MoveFile 函数实现的改名操作，但是直接使用 MoveFile 函数对含有系统保留关键字的目录进行操作，必将导致失败。那么 RenamePlus 是怎么做到的呢？ 仔细阅读MSDN会发现 Windows 对于文件命名的一个文档：Naming a File。 阅读完这个文档，有一句话比较特殊：It is possible to create a path with the API that the shell UI cannot handle。这句话的大意就是说：API创建的路径，UI界面可能无法进行控制。联系前文说到的对于含有Windows保留字符的路径，UI界面的确是 没法进行控制的，那么这句话的意思是不是说利用一些特殊的方法是可以进行控制的呢？ 根据Windows命名文档的描述，可以使用 \\?\ 前缀扩充Windows对于文件名长度的限制，实际上，RenamePlus 也正是利用了这个性质，利用 \\?\ 前缀绕过了Windows API 对于保留文件名的检查，使得在下面的一些调用能够完成并最终有文件系统对在文件系统上进行实际的操作。
|
|
|
