在加密与解密P59页 的实例1 使用IDC脚本实现“查看输入函数”，本人会点python，就对比用Python实现了，python脚本应该是趋势，希望加密与解密第4版能使用python吧。
def GetImportSeg():
ea=FirstSeg()
next=ea
count=0
while next != BADADDR: #判断是否为".idata"段
next=NextSeg(next)
name=SegName(next)
if name[0:6]=='.idata':
break
return next
def main():
BytePtr=SegStart(GetImportSeg()) #确定idata段VA
EndImports=SegEnd(BytePtr)
print('\n Parsing import table...')
while BytePtr<EndImports:
if LineA(BytePtr,1):
print( '__'+LineA(BytePtr,1)+'__')
if Name(BytePtr):
print(Name(BytePtr)+'\n') #显示当前地址的函数名
BytePtr=NextAddr(BytePtr)
print('Import table parsing complete\n')
由看雪论坛转载，那篇文章可读性太差，我重新排版，并对关键字标注，附件中为*.mht网页格式，方便阅读。
使用FLIRT签名识别库（Library recognition using flirt signatures）
在“The initial autoanalysis has been finished”[1]之后，该是到了探索IDA更高级功能的时候了。这一章中我们将讨论一些识别标准代码序列的技术，如包含在静态链接二进制中的库代码，或者编译器插入的标准初始化和辅助函数。
当逆向二进制时，您要做的最后一件事就是花费时间去逆向库函数了，然而这些函数的功能却可以很轻松的通过阅读帮助文档、源代码，或是在互联网上搜索了解到。静态链接二进制所带来的难题是应用程序代码和库代码的区分很模糊。在静态链接二进制中，整个库与应用程序代码互相结合，形成一个密不可分的可执行文件。不过幸运的是，有些工具可以让IDA识别并且标记出库代码，使我们把注意力集中在应用程序自身的代码上。
库文件快速识别与鉴定技术（Fast Library Identification and Recognition Technology）
库文件快速识别与鉴定技术（Fast Library Identification and Recognition Technology），简称为FLIRT，包含了一组IDA用来标识库代码序列的方法。FLIRT的核心技术是模式匹配算法，这使得IDA能够迅速确定一个反汇编后的函数是否匹配IDA中许多已知签名的一个。
<IDA_DIR>/sig目录包含了IDA附带的签名文件，在大多数情况下，这些签名与常见的Windows编译器生成的库相关，但少数非Windows的签名也包括在内。
签名文件使用自定义格式，其中大部分签名数据被压缩和包含在一个IDA指定的头文件中。多数情况下，签名文件的名称不能清楚地表明这个签名文件是由哪个库产生的，签名文件可以包含一个库名字的注释来描述其内容，这取决于它们的创建过程。如果我们从签名文件中提取ASCII内容，查看它们的前几行，往往就能够发现这个注释。下面的Unix风格命令[3] 可以用于输出这些注释，注释一般在第二或第三行：
# strings sigfile | head -n 3
IDA两种办法查看相关签名文件：
第一，通过View -> Open Subviews -> Signatures(Shift+F5)，可以查看到已经应用于二进制的签名列表；
第二，通过 File -> Load File -> FLIRT Signature File，作为手动签名应用程序流程的一部分，显示出所有的签名文件列表。
应用FLIRT签名(Applying FLIRT Signatures)
当一个二进制第一次打开时，IDA尝试对入口点应用startup签名指定的相关签名文件。原来，各种不同的编译器所产生的入口点代码是相当不同的，入口点签名匹配技术可以有效的鉴定出一个给定的二进制的编译器类型。
MAIN VS. _START
我们知道，一个程序的入口点就是将被执行的第一条指令的地址。长期以来，许多C程序员错误地认为这是main函数的地址，实际上并非如此。程序的文件类型，但不是创建这个程序的语言类型，决定了以何种方式提供命令行参数给程序。为解决加载器传递命令行参数的方式和程序期望的接收方式之间的差异（例如，传递参数给main），在转移控制权给main之前必须执行一些初始化代码。正是这段初始化代码被IDA指定为程序的入口点，并且定义为标签_start。
这段始化代码还负责其它任何允许main运行前的初始化任务。在C++程序中，该代码负责在main执行前保证全局定义对象的构造函数被调用。同样，为了在程序真正结束前调用全局对象的析构函数，释放代码被插入在执行main之后。
如果IDA确定了创建一个二进制的编译器类型，将会载入和该编译器库相对应的签名文件，并且应用到二进制的剩余部分。
随IDA发布的签名文件趋向于某些私有的编译器，如Microsoft Visual C ++或Borland Delphi。幕后的原因是因为与这些编译器相关的二进制库的数量有限。而开源的编译器如GNU gcc，与它相关的二进制库数量和操作系统一样众多，比如每个版本的FreeBSD都有个唯一的C标准库版本。由于最佳模式匹配的原因，签名文件需要与每个不同版本的库相对应，考虑到要收集随每一个Linux发行版而发行的每一个libc.a[4]的版本非常困难，是不切合实际的。从某种程度上说，这些差异是由于改变了库的源代码，因而编译后代码不一样。但是使用不同的编译选项，如优化设置和不同的编译器版本来创建库，也可能会导致巨大的差异。最终的方案是，IDA附带了非常少的开源编译器库的签名文件。不过你将很快看到的好消息是，Hex-Rays生成工具允许你从静态库中创建你自己的签名文件。
ibc.a是类Unix操作系统中静态链接版本的C标准库的二进制文件。
那么，在什么情况下需要手动应用签名到您的数据库中呢？某些情况下，IDA正确识别出了生成二进制的编译器，但没有编译器库相关的签名文件可用，这时候，您既可以工作在没有签名的世界中，也可以去获取一份该二进制使用的静态库文件副本，然后生成你自己的签名。其他情况下，IDA可能只是简单地表明识别编译器失败，因此无法确定哪些签名应该应用于数据库。在分析初始化函数被完全破坏以便去除编译器标识的混淆代码时，通常会发生这种情况。那么，在你还抱有希望去匹配任何库签名之前，要做的第一件事就是去充分地反混淆该二进制。我们将在第21章讨论处理混淆代码的技术。
不管何种原因，如果您想手动应用签名到一个数据库，可以通过 File -> Load File -> FLIRT Signature File，打开的签名选择对话框如图12-1所示。
注意：sigmake的说明文档sigmake.txt中建议，签名文件的名字最好遵守MS-DOS 8.3名称长度规范。这不是一个硬性的要求，但是，如果使用了长文件名，将会只有文件名称的前8个字符能够显示在签名选择对话框中。
创建签名往往是个反复的过程，因为在这一阶段有冲突发生时必须处理。任何时候如果两个函数有相同的模式就会发生冲突。如果冲突不以某种方式解决，在应用签名的过程中就无法确定事实上匹配了哪个函数。因此，sigmake必须使产生的每一个签名正好对应一个函数名。如果这个基本条件没有满足，导致一个或多个函数有着相同的签名，sigmake就会拒绝生成签名文件，取而代之生成一个排斥文件（.exc）。第一次使用sigmake传递一个新的.pat文件（或一组.pat文件）时，更典型的输出可能如下。
$ ./sigmake libc_FreeBSD61.pat libc_FreeBSD61.sig
See the documentation to learn how to resolve collisions.
: modules/leaves: 13443631/970, COLLISIONS: 911
文档文件sigmake.txt叙述了sigmake的使用及解决冲突的过程。事实上，每次sigmake执行时，先搜索相应的排斥文件，因为该文件中包含了sigmake在处理已命名模式文件中可能会遇到的冲突，及怎样解决冲突的有用信息。如果没有这个排斥文件，当冲突发生时，sigmake就会生成一个排斥文件，而不是生成一个签名文件。在前面的例子中，我们会找到一个新产生的名为libc_FreeBSD61.exc的文件。当第一次被创建时，排斥文件是个文本文件，包含了sigmake在处理模式文件中遇到的冲突细节，排斥文件必须被修改以提供sigmake关于如何解决模式冲突的指示。编辑一个排斥文件的一般过程如下。
11更多信息请访问：https://www.hex-rays.com/products/ida/tech/flirt/index.shtml
sigmake生成的所有排斥文件开头几行都如下所示：
;--------- (delete these lines to allow sigmake to read this file)
; add '+' at the start of a line to select a module
; add '-' if you are not sure about the selection
; do nothing if you want to exclude all modules
这几行的目的是提醒你应该怎样做，才能解决冲突以成功地生成签名。首要事情就是删除以分号开头的这四行，否则sigmake在随后的执行中将无法解析排斥文件。接下来的步骤是告诉sigmake您想要解决的冲突。从libc_FreeBSD61.exc提取出来的几行示例如下：
___ntohs 00 0000 0FB744240486C4C3................................................
___htons 00 0000 0FB744240486C4C3................................................
hDlg [in]
Type: HWND
A handle to the dialog box that contains the control.
什么是Dialog box?于是又去百度。。。首先还是看下Windows的所有窗体吧！如下图所示，自己可浏览所有窗体，附件有PPT介绍Windows窗体应用开发。不过，如果时间充足，还是建议学习下window API编程之类的。
