基于中间语言的+JNI内存泄漏检查

计算机研究与发展ＤＯＩ：１０．７５４４桙ｉｓｓｎ１０００‐１２３９．２０１５．２０１３１９０９ＪｏｕｒｎａｌｏｆＣｏｍｐｕｔｅｒＲｅｓｅａｒｃｈａｎｄＤｅｖｅｌｏｐｍｅｎｔ５２（４）：８９８９０６，２０１５　收稿日期：２０１３－１２－１７；修回日期：２０１４－０５－１２　基金项目：国家自然科学基金项目（６１２７２０８６）；“核高基”国家科技重大专项基金项目（２０１２ＺＸ０１０３９‐００４‐０８）基于中间语言的ＪＮＩ内存泄漏检查蒋挺宇１　王　鹏１　杨　述１　褥　震１　董　渊１　王生原１　嵇智源２１（清华大学计算机科学与技术系　北京　１０００８４）２（科技部高技术研究发展中心　北京　１０００４４）（Ｊｉａｎｇｔｙ０８＠ｇｍａｉｌ．ｃｏｍ）ＤｅｔｅｃｔｉｏｎｏｆＪＮＩＭｅｍｏｒｙＬｅａｋｓＢａｓｅｄｏｎＥｘｔｅｎｄｅｄＢｙｔｅｃｏｄｅＪｉａｎｇＴｉｎｇｙｕ１，ＷａｎｇＰｅｎｇ１，ＹａｎｇＳｈｕ１，ＲｕＺｈｅｎ１，ＤｏｎｇＹｕａｎ１，ＷａｎｇＳｈｅｎｇｙｕａｎ１，ａｎｄＪｉＺｈｉｙｕａｎ２１（ＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，ＴｓｉｎｇｈｕａＵｎｉｖｅｒｓｉｔｙ，Ｂｅｉｊｉｎｇ１０００８４）２（ＨｉｇｈＴｅｃｈｎｏｌｏｇｙＲｅｓｅａｒｃｈａｎｄＤｅｖｅｌｏｐｍｅｎｔＣｅｎｔｅｒ，ＭｉｎｉｓｔｒｙｏｆＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，Ｂｅｉｊｉｎｇ１０００４４）Ａｂｓｔｒａｃｔ　ＴｈｅＪａｖａｎａｔｉｖｅｉｎｔｅｒｆａｃｅ（ＪＮＩ）ｅｎａｂｌｅｓＪａｖａｃｏｄｅｒｕｎｎｉｎｇｉｎａＪａｖａｖｉｒｔｕａｌｍａｃｈｉｎｅ（ＪＶＭ）ｔｏｂｅｃａｌｌｅｄｂｙｎａｔｉｖｅｃｏｄｅ，ｂｕｔｔｈｅｄｉｆｆｅｒｅｎｃｅｏｆｓｅｃｕｒｉｔｙｆｅａｔｕｒｅｓｂｅｔｗｅｅｎｌａｎｇｕａｇｅｓｍａｋｅｓｉｔａｓｅｃｕｒｉｔｙｗｅａｋｎｅｓｓ，ｗｈｉｃｈｃａｎｎｏｔｂｅｄｅｔｅｃｔｅｄｂｙｅｘｉｓｔｉｎｇａｎａｌｙｓｉｓｍｅｔｈｏｄｓ．Ｃｏｍｍｏｎｌｙｕｓｅｄｄｅｔｅｃｔｉｏｎｍｅｔｈｏｄｓａｒｅｍａｉｎｌｙｂａｓｅｄｏｎｔｈｅａｎａｌｙｓｉｓｏｆｉｎｔｅｒｍｅｄｉａｔｅｌａｎｇｕａｇｅ，ｗｈｉｃｈｉｓｉｎｖａｌｉｄｉｎｔｈｉｓＪＮＩｃａｓｅ，ｓｉｎｃｅｔｈｅｌａｃｋｏｆａｎｉｎｔｅｒｍｅｄｉａｔｅｒｅｐｒｅｓｅｎｔａｔｉｏｎｔｏｂｒｉｄｇｅＪａｖａａｎｄＣ＋＋．ＴｈｉｓｐａｐｅｒａｎａｌｙｚｅｓＪＮＩｆｒｏｍａＪａｖａ桙Ｃ＋＋ｃｒｏｓｓ‐ｌａｎｇｕａｇｅｐｅｒｓｐｅｃｔｉｖｅａｎｄｆｏｃｕｓｅｓｏｎｍｅｍｏｒｙｌｅａｋｓｗｈｉｃｈｆｒｅｑｕｅｎｔｌｙｏｃｃｕｒｉｎＪＮＩｃａｌｌｓ．Ｉｎｏｒｄｅｒｔｏｏｖｅｒｃｏｍｅｌａｎｇｕａｇｅｂａｒｒｉｅｒｓ，ｔｈｉｓｐａｐｅｒｐｒｏｐｏｓｅｓｅｘｔｅｎｄｅｄＢｙｔｅｃｏｄｅ（Ｂｙｔｅｃｏｄｅ倡）ｉｎｓｔｒｕｃｔｉｏｎｓａｓｉｎｔｅｒｐｒｅｔａｔｉｏｎｏｆＣ＋＋ｓｅｍａｎｔｉｃｓ．Ｏｕｒｃｏｎｔｒｉｂｕｔｉｏｎｓａｒｅｄｅｓｃｒｉｂｅｄａｓｆｏｌｌｏｗｓ：１）ＤｅｆｉｎｅａｂｌｏｃｋｍｅｍｏｒｙｍｏｄｅｌｗｈｉｃｈｉｓｃｏｍｐａｔｉｂｌｅｗｉｔｈｂｏｔｈＪａｖａａｎｄＣ＋＋；２）ＤｅｓｉｇｎｔｒａｎｓｌａｔｉｏｎｒｕｌｅｓｆｒｏｍＣ＋＋ｔｏｅｘｔｅｎｄｅｄＪａｖａＢｙｔｅｃｏｄｅｂａｓｅｄｏｎＬＬＶＭ桙ＬＬＪＶＭ；３）Ｃｏｎｓｔｒｕｃｔａｍｅｔｈｏｄｃａｌｌｇｒａｐｈ，ｅｘｔｒａｃｔａｂｓｔｒａｃｔａｎｄｄｅｔｅｃｔｍｅｍｏｒｙｌｅａｋｓｉｎＪＮＩｃａｌｌｓｂｙｉｎｔｅｒｐｒｏｃｅｄｕｒａｌａｎａｌｙｓｉｓ．ＥｘｐｅｒｉｍｅｎｔｓｏｎｔｙｐｉｃａｌＪＮＩｃｏｄｅｗｉｔｈｍｅｍｏｒｙｌｅａｋｆｅａｔｕｒｅｓｓｈｏｗｔｈａｔｏｕｒａｎａｌｙｓｉｓｗｏｒｋｃａｎｄｅｔｅｃｔｍｅｍｏｒｙｌｅａｋｓｉｎＪａｖａ桙Ｃ＋＋ａｃｃｕｒａｔｅｌｙ，ａｎｄｉｓｏｆｉｍｐｏｒｔａｎｔｓｉｇｎｉｆｉｃａｎｃｅｉｎｃｒｏｓｓ‐ｌｉｎｇｕｉｓｔｉｃｐｒｏｇｒａｍｍｉｎｇａｎｄｖｕｌｎｅｒａｂｉｌｉｔｙａｎａｌｙｓｉｓ．Ｋｅｙｗｏｒｄｓ　Ｊａｖａｎａｔｉｖｅｉｎｔｅｒｆａｃｅ（ＪＮＩ）；ｃｒｏｓｓ‐ｌｉｎｇｕｉｓｔｉｃａｎａｌｙｓｉｓ；ｓｅｍａｎｔｉｃｅｘｔｅｎｓｉｏｎ；Ｂｙｔｅｃｏｄｅ；ｍｅｍｏｒｙｌｅａｋ摘　要　ＪＮＩ技术支持Ｊａｖａ与本地Ｃ桙Ｃ＋＋的相互调用，在Ａｎｄｒｏｉｄ等混合语言实现的系统中有着广泛应用，但语言之间的安全特性差异使其成为安全薄弱环节，现有的分析方法难以处理多语言相互调用产生的安全缺陷．以ＪＮＩ调用中易产生的内存泄漏为例，开展Ｊａｖａ桙Ｃ＋＋ＪＮＩ跨语言分析的研究．采用扩展的ＪａｖａＢｙｔｅｃｏｄｅ（Ｂｙｔｅｃｏｄｅ倡）指令作为Ｃ＋＋语义的解释来消除跨语言分析的障碍．围绕ＪＮＩ调用中内存泄漏的问题，做了以下３方面工作：１）定义兼容Ｊａｖａ桙Ｃ＋＋语言的分块内存模型；２）基于ＬＬＶＭ桙ＬＬＪＶＭ，设计实现了Ｃ＋＋到Ｂｙｔｅｃｏｄｅ倡的翻译策略；３）建立方法调用图，提取方法摘要，利用过程间分析方法检测ＪＮＩ调用中的内存泄漏．针对具有典型内存泄漏特征的ＪＮＩ实例翻译检测表明，该工作能够准确检测出Ｊａｖａ桙Ｃ＋＋混合语言中的内存泄漏，对于ＪＮＩ混合语言编程的理解和漏洞分析具有重要价值．关键词　Ｊａｖａ本地调用；跨语言分析；语义扩展；字节码；内存泄漏中图法分类号　ＴＰ３１４ ＪＮＩ（Ｊａｖａｎａｔｉｖｅｉｎｔｅｒｆａｃｅ）编程是一项复杂的工作，其编程规范［１］中列出了多达１５种ＪＮＩ编程中容易出现的错误，这些错误很难通过编译器来发现．除了程序员使用ＪＮＩ调用失误而造成的程序错误之外，黑客们也开始针对软件系统中的ＪＮＩ接口缺陷，编写恶意代码来越过Ｊａｖａ虚拟机的保护机制，以达到非法的目的．Ａｎｄｒｏｉｄ操作系统基于Ｌｉｎｕｘ开源操作系统，是目前最为流行的移动操作系统［２］．为方便开发，Ａｎｄｒｏｉｄ采用Ｊａｖａ作为其应用程序开发语言，而底层库则由本地Ｃ代码实现，两者通过Ｄａｌｖｉｋ虚拟机以及ＪＮＩ机制进行通信．本文研究发现，Ａｎｄｒｏｉｄ２畅２系统中有ＪＮＩ接口３１８６个，其中４４３个采用Ｃ语言实现，其余２７４３个均采用Ｃ＋＋语言实现，Ｃ＋＋实现的ＪＮＩ接口中有１８３７个位于系统核心框架ｆｒａｍｅｗｏｒｋｓ中．由于Ｊａｖａ语言和Ｃ＋＋语言之间的安全特性差异，这些ＪＮＩ接口成为安全薄弱环节，一旦出现问题，后果可能十分严重．２０１０年Ｋａｓｐｅｒｓｋｙ首次发现了针对Ａｎｄｒｏｉｄ系统的ＳＭＳ木马，其危害是泄漏个人数据［３］．之后，Ａｎｄｒｏｉｄ平台上恶意代码呈井喷之势爆发，至今仍保持着较高的增长速度．Ｄａｖｉ等人［４］详细介绍了一种利用ＪＮＩ接口对本地Ｃ代码进行溢出攻击的原理和代码实例，该方法可以轻易突破Ａｎｄｒｏｉｄ的权限保护和ＪＶＭ（Ｊａｖａｖｉｒｔｕａｌｍａｃｈｉｎｅ）的沙箱保护，在不经过任何授权的情况下获取超级用户权限．由于ＪＶＭ桙Ｄａｌｖｉｋ对本地代码高度的信任，ＪＮＩ接口缺陷逐渐成为恶意软件利用的重灾区［５］．目前对于Ｊａｖａ程序的安全监测和验证工作主要是基于Ｂｙｔｅｃｏｄｅ开展研究，但这种方式无法针对混合语言开展分析，大多数的检测器选择完全忽略本地代码的危害，所以难以得到准确的结果．本文提出了一种从ＪＮＩ两端整体来分析程序的方案，针对ＪＮＩ接口的多语言编程模型，将整个程序翻译到扩展的ＪａｖａＢｙｔｅｃｏｄｅ中间表示，利用过程间分析达到跨语言检测的目的．１　相关工作综述１．１　现有分析检测技术在ＪＮＩ调用中，Ｊａｖａ代码和本地代码的交互是程序的主体，现有技术手段往往仅在一端开展安全检测，无法有效处理ＪＮＩ中由于跨语言控制流带来的安全问题．针对ＪａｖａＢｙｔｅｃｏｄｅ的开源静态检测工具有很多．Ｆｉｎｄｂｕｇｓ［６］采用Ｖｉｓｉｔｏｒ模式，查找代码中与某种缺陷模式匹配的错误．但是，Ｆｉｎｄｂｕｇｓ专注于过程内分析，对于跨过程分析的能力十分有限．Ｓｏｏｔ是一个Ｊａｖａ优化和分析框架，可以解析ｃｌａｓｓ文件，构建控制流图和调用图，执行指针指向和空指针分析，并且支持数据流分析．Ｓｏｏｔ［７］框架比较适合构建专门的ＪａｖａＢｙｔｅｃｏｄｅ分析器．另外一些检测技术仅在本地代码端展开．Ｌｉｎｔ［８］一类的工具采用类型分析方法，手工对访问内存的操作进行大量注释以辅助内存分析，且没有利用控制流信息，结果的准确性有限．Ｋｏｎｄｏｈ等人利用静态分析技术在缺陷查找工具ＢＥＡＭ［９］中实现了针对本地Ｃ代码的分析，对ＪＮＩ编程范例中所列包括资源泄漏在内的几项错误进行检测［１０］，可以分析特定接口函数导致的资源泄漏问题，但局限于函数过程内部，检测范围有限．这些方法在ＪａｖａＢｙｔｅｃｏｄｅ类型、语义、逻辑系统以及验证等方面取得了大量研究成果，如果能利用ＪａｖａＢｙｔｅｃｏｄｅ实现本地代码语义的解释，这些成果会大大降低Ｊａｖａ桙Ｃ＋＋ＪＮＩ跨语言分析的代价．１．２　ＪＮＩ接口的分析现状ＪＮＩ分析的最大难点就是如何消除多语言对分析器的影响．Ｚｈａｏ等人［１１］给出一种Ｂｉｔｃｏｄｅ中间表示的形式化模型，用于构造和验证可信的ＬＬＶＭ优化器，而ＬＬＪＶＭ项目还提供了一种将ＬＬＶＭＢｉｔｃｏｄｅ翻译为ＪａｖａＢｙｔｅｃｏｄｅ的框架，支持Ｃ语言特征［１２］．但是这些翻译通常并不提供针对ＪＮＩ问题检测的跨语言处理，给检测带来很大困难，在这些中间语言上重新构建ＪＮＩ缺陷分析器的代价又很大．Ｆｕｒｒ和Ｆｏｓｔｅｒ设计了ＪＳａｆｆｉｒｅ来寻找ＪＮＩ相关的类型错误［１３］；Ｋｏｎｄｏｈ和Ｏｎｏｄｅｒａ设计了一个类似的类型检测系统；Ｔａｎ等人建立了ＳａｆｅＪＮＩ［１４］和ＩＬＥＡ［１５］框架方法，寻找Ｊａｖａ桙ＣＪＮＩ接口中的安全错误．这些方法对ＪａｖａＢｙｔｅｃｏｄｅ进行了一定的扩展，将Ｃ语言翻译到扩展的ＪａｖａＢｙｔｅｃｏｄｅ，使Ｊａｖａ分析器可以理解Ｃ代码的语义，并对之进行形式化验证．该方法只需建立Ｃ语言到Ｂｙｔｅｃｏｄｅ的翻译器，省略了很多Ｃ语言的复杂特性，利用丰富的Ｊａｖａ分析技术，避免高昂的开销，对ＪａｖａＢｙｔｅｃｏｄｅ指令的扩展侧重于翻译后的可检查性．但上述方法局限于Ｃ语言，无法处理Ｃ＋＋代码，而本地代码中Ｃ＋＋的比例不断增大，而且包含更多的语言特性，因此需要进一步的研究．９９８蒋挺宇等：基于中间语言的ＪＮＩ内存泄漏检查１．３　本文研究内容为了检测Ｊａｖａ程序中ＪＮＩ调用涉及多语言交互所引发的问题，本文提出将不同语言向同一中间表示转换、然后基于中间表示展开分析的方案，构建如图１所示的Ｊａｖａ桙Ｃ＋＋跨语言静态分析与检测平台．Ｆｉｇ．１　Ｗｏｒｋｆｌｏｗｃｈａｒｔ．图１　工作流程图Ｊａｖａ应用程序中，本地代码实际比例相对Ｊａｖａ语言要低，而且ＪａｖａＢｙｔｅｃｏｄｅ作为编译后的二进制码可以保留足够的类型信息，并且有一些成熟的Ｂｙｔｅｃｏｄｅ分析框架可以利用．本文将本地语言向扩展的ＪａｖａＢｙｔｅｃｏｄｅ转换，称之为Ｂｙｔｅｃｏｄｅ倡．如图１所示，将Ｂｙｔｅｃｏｄｅ倡和ＪａｖａＢｙｔｅｃｏｄｅ作为一个整体开展分析．平台基于模式匹配的方式，针对不同的缺陷模式制定不同的翻译策略，将ＪＮＩ调用中的本地Ｃ＋＋代码翻译到Ｂｙｔｅｃｏｄｅ倡，消除不同语言的隔阂，然后扩展ＪａｖａＢｙｔｅｃｏｄｅ分析工具针对具体的缺陷开展分析．因为内存泄漏是较为常见的本地代码缺陷，而且由于多语言的交互变得更加隐蔽，所以本文以它为突破口先完成ＪＮＩ调用中的内存泄漏检测．２　Ｃ＋＋到Ｂｙｔｅｃｏｄｅ倡的翻译技术ＬＬＶＭ的Ｂｉｔｃｏｄｅ拥有简单、独立的类型系统，拥有地址计算指令和处理高级语言异常处理的功能，可以保留Ｃ＋＋的语言信息．ＬＬＪＶＭ项目提供了Ｂｉｔｃｏｄｅ到Ｂｙｔｅｃｏｄｅ转换的框架，采用运行时动态库的方式实现对Ｃ语言特征的支持．ＬＬＪＶＭ不能支持Ｃ＋＋，而且它的翻译策略引入很多不必要的复杂信息，所以不适合本文需要的静态分析和检测要求．但是，ＬＬＪＶＭ提供了一个可利用的Ｂｉｔｃｏｄｅ到Ｂｙｔｅｃｏｄｅ的翻译框架，只需在此框架上设计适合静态分析的翻译策略，提供对Ｃ＋＋语言的支持就可以实现Ｃ＋＋源码到Ｂｙｔｅｃｏｄｅ倡的翻译，本文设计的翻译策略如下：首先利用ＬＬＶＭ编译器Ｃ＋＋前端ｌｌｖｍ‐ｇ＋＋将Ｃ＋＋源码翻译到ＬＬＶＭＢｉｔｃｏｄｅ；然后用翻译器对Ｃ＋＋程序预处理，获取其中包含的类相关信息；最后结合对Ｂｉｔｃｏｄｅ语义的分析，使用本文设计的简洁翻译策略，将Ｂｉｔｃｏｄｅ翻译到Ｂｙｔｅｃｏｄｅ倡．２．１　内存模型Ｃ＋＋和Ｊａｖａ两种存储模型无法直接匹配，堆的操作也有很大差异，可能产生内存泄漏，需要设计合适的ＪＮＩ存储模型，实现两种语言之间的内存模型匹配．本文建立分块内存模型（ｂｌｏｃｋｍｏｄｅｌ）来解决Ｊａｖａ桙Ｃ＋＋的内存模型不同的问题．在分块模型中，存储堆由若干块组成，一个块可以被垃圾回收机制管理，与Ｊａｖａ内存模型匹配，可称为Ｊ堆；其他块必须通过显式的内存分配或释放指令操作与Ｃ＋＋的内存模型匹配，称为Ｃ堆．每个块是一个从地址到值的映射，允许地址加减，适合内存计算．这个模型与Ｂｉｔｅｃｏｄｅ的堆存储模型也是吻合的．在此模型基础上，可以使用Ｂｙｔｅｃｏｄｅ倡统一描述Ｊａｖａ桙Ｃ＋＋ＪＮＩ接口两端对内存的操作行为，为Ｃ＋＋到Ｂｙｔｅｃｏｄｅ的翻译建立基础．２．２　翻译策略与类型映射Ｂｙｔｅｃｏｄｅ倡是由Ｊａｖａ字节码Ｂｙｔｅｃｏｄｅ扩展而来，语言特性与Ｊａｖａ具有一定的一致性，要将Ｃ＋＋翻译到Ｂｙｔｅｃｏｄｅ倡关键在于Ｃ＋＋与Ｊａｖａ的类型映射．本文的思路是将Ｃ＋＋中包括基本类型在内的所有类型映射到Ｊａｖａ的数组、类或接口等拥有引用的类型上，通过引用来模拟Ｃ＋＋中的指针特性．为此，需要设计一套完整的Ｃ＋＋到Ｊａｖａ的类型映射，且尽量利用Ｊａｖａ现有的类型简化翻译及检测的复杂度．本文定义：ＭａｐＴｙｐｅ（ｃ）＝ｊ，其中，ｃ为Ｃ＋＋中的类型，ｊ为Ｊａｖａ中的类型．２．２．１　基本类型映射Ｃ＋＋与Ｊａｖａ的基本数据类型大致是相同的，例如ｉｎｔ，ｄｏｕｂｌｅ等，简单的做法就是直接对其映射，但考虑到Ｃ＋＋中的内存访问操作，基本类型间的直接映射是无法满足需求的，例如以下代码：ｉｎｔｉ＝５，倡ｐｉ＝＆ｉ；００９计算机研究与发展　２０１５，５２（４）倡ｐｉ＝８．Ｊａｖａ中无法通过指针对数据进行操作，可以将ｉｎｔ这样的基本类型对应到Ｊａｖａ中的类或数组来获得类似于指针或别名的效果，即ＭａｐＴｙｐｅ（ｉｎｔ）＝ｉｎｔ［］． 这样，使用数组下标可以模拟指针的加减运算以及内存操作．２．２．２　基本类型指针对于基本类型，本文可以用数组来模拟表示，但基本类型的指针仅使用数组已经无法满足要求，本文考虑设计Ｊａｖａ类来对应，以ｉｎｔ倡为例：ＣｌａｓｓｉｎｔＰ｛　ｉｎｔ［］ｄａｔａ；　ｉｎｔｉｎｄｅｘ；｝；ｄａｔａ对应ｉｎｔ的映射，ｉｎｄｅｘ用来处理指针加减运算．如下是Ｃ＋＋代码：ｉｎｔｉ［１０］；ｉｎｔ倡ｐｉ＝＆ｉ，倡ｐｉ２；ｐｉ２＝ｐｉ＋２；其中，ｐｉ，ｐｉ２对应的Ｊａｖａ类中，ｄａｔａ域相同，ｉｎｄｅｘ不同，可以通过ｉｎｄｅｘ模拟两者间的加减运算．２．２．３　对象指针指向对象的指针与指向基本类型的指针基本相同，只是因为Ｊａｖａ本身有对象引用，所以无需再利用数组封装了．对象指针可以用如下类表示：ＣｌａｓｓｏｂｊｅｃｔＰ｛　ｏｂｊｅｃｔ［］ｄａｔａ；　ｉｎｔｉｎｄｅｘ；｝；其中，ｏｂｊｅｃｔ为类名，基于此可递归构造诸如ｏｂｊｅｃｔ倡倡这样的多级对象指针．２．２．４　函数指针Ｃ＋＋中调用函数既可以直接调用，也可以通过函数指针调用；但在Ｊａｖａ中，函数均被封装在类和接口中．同样地，对于函数指针，可以通过Ｊａｖａ接口引用来模拟．Ｃ＋＋函数指针指向的具体函数行为，在Ｊａｖａ中可以通过继承特定接口的子类来实现．２．３　ＪＮＩ接口函数及库函数处理ＪＮＩ接口函数是连接Ｊａｖａ端和本地代码端的纽带，使Ｊａｖａ和本地代码能够相互调用通信．根据ＪＮＩ接口函数的功能和使用方式，分如下３种情况处理：１）用于注册本地函数入口的接口函数．由于该类函数并不影响分析过程，因而在ＪＮＩ两端合并到Ｂｙｔｅｃｏｄｅ倡之后不再需要，故不作翻译，最后在中间代码布局中体现即可．２）与内存泄漏无关的接口函数．这些函数的功能各样且实现复杂，但与内存泄漏无关，本文不对其具体翻译，只将其加入到白名单中即可．此外，为了不影响控制流桙数据流分析，对此类函数返回值取任意值，并对ＪａｖａＢｙｔｅｃｏｄｅ扩展一条指令以实现此功能，Ｃ＋＋标准库和第三方库函数也可采用此方式处理．３）可能导致内存泄漏的函数．类似ＧｅｔＳｔｒｉｎｇ‐Ｃｈａｒｓ桙ＲｅｌｅａｓｅＳｔｒｉｎｇＣｈａｒｓ这样的接口函数，翻译其具体操作比较复杂，若检测内存泄漏，则可以扩展ＪａｖａＢｙｔｅｃｏｄｅ的内存操作指令．设计ｎａｔｉｖｅ＿ｎｅｗ桙ｎａｔｉｖｅ＿ｄｅｌｅｔｅ指令，用于内存的显式分配与释放．这只需用ｎａｔｉｖｅ‐ｎｅｗ桙ｎａｔｉｖｅ‐ｄｅｌｅｔｅ来标记可能发生泄漏的接口函数，而不需要翻译具体的分配和释放过程．在分块内存模型上，完成上述对白名单函数的处理以及显式的内存分配释放，需要扩展以下３条Ｂｙｔｅｃｏｄｅ倡指令：１）ｎａｔｉｖｅ＿ｎｅｗ棟ｃｌａｓｓ棡．在Ｃ堆创建一个新对象，不受垃圾回收机制管理，必须通过ｎａｔｉｖｅ＿ｄｅｌｅｔｅ显式释放．２）ｎａｔｉｖｅ＿ｄｅｌｅｔｅ．释放当前栈顶通过ｎａｔｉｖｅ＿ｎｅｗ分配的对象．３）ｒａｎｄｏｍ棟ｔｙｐｅ棡．在当前栈顶放置一个ｔｙｐｅ类型的随机值．通过上述设计，就可以将ＪＮＩ两端基本对应，将Ｃ＋＋语言翻译到中间表示Ｂｙｔｅｃｏｄｅ倡．３　基于过程间分析的ＪＮＩ漏洞检测３．１　内存泄漏模式内存泄漏的本质都是失去对动态分配内存的控制．从检测角度来说，本文将内存泄漏总结为２种模式：１）分配内存后，没有释放；２）分配内存后，指向该块内存的变量发生变化，导致无法释放．对内存泄漏模式来说，根据本地代码的内存分配与释放的匹配建模，可以建立基于内存泄漏模式的有限状态机，将内存变量分为３个不同的状态｛ＵｎＡｌｌｏｃａｔｅｄ，Ａｌｌｏｃａｔｅｄ，Ｅｒｒｏｒ｝，各种状态的含义为：ＵｎＡｌｌｏｃａｔｅｄ表示变量未被分配内存；Ａｌｌｏｃａｔｅｄ表示变量已被分配内存；Ｅｒｒｏｒ是故障状态．１０９蒋挺宇等：基于中间语言的ＪＮＩ内存泄漏检查可以通过构造如图２所示的状态转换图描述和寻找这样的问题．Ｆｉｇ．２　Ｓｔａｔｅｔｒａｎｓｉｔｉｏｎｏｆｍｅｍｏｒｙｌｅａｋ．图２　内存泄漏状态转换图状态转移条件如表１所示：Ｔａｂｌｅ１　ＳｔａｔｅＴｒａｎｓｉｔｉｏｎＣｏｎｄｉｔｉｏｎｓ表１　状态转换条件ＳｔａｔｅＴｒａｎｓｉｔｉｏｎＳｔａｔｅＴｒａｎｓｉｔｉｏｎＣｏｎｄｉｔｉｏｎｓＵｎＡｌｌｏｃａｔｅｄ→ＡｌｌｏｃａｔｅｄＡｌｌｏｃａｔｅｍｅｍｏｒｙｆｏｒｖａｒｉａｂｌｅｓ．Ａｌｌｏｃａｔｅｄ→ＵｎＡｌｌｏｃａｔｅｄＲｅｌｅａｓｅｍｅｍｏｒｙｏｆｖａｒｉａｂｌｅｓ．Ａｌｌｏｃａｔｅｄ→ＡｌｌｏｃａｔｅｄＯｔｈｅｒｏｐｅｒａｔｉｏｎ．Ａｌｌｏｃａｔｅｄ→ＥｒｒｏｒＰｒｏｇｒａｍｅｘｉｔｓｏｒｖａｒｉａｂｌｅｓａｒｅｉｎａｃｃｅｓｓｉｂｌｅ．３．２　过程间ＪＮＩ内存泄漏检测设计根据分析的范围和目标，分析方法可以分为过程内分析和过程间分析；而ＪＮＩ调用可能涉及内存泄漏问题，其本质上是Ｃ＋＋函数和Ｊａｖａ方法互相调用的结果，并非局限于一个方法内，因此必须进行过程间分析．此外针对内存泄漏，只要有一条程序运行路径没有达成内存申请与释放的匹配，本文就可以认为程序有出现内存泄漏的风险，所以还需要进行路径敏感的分析策略．过程间分析［１６‐１８］与路径敏感分析［１９‐２１］已经有不少相关的研究和对应的工具出现，他们都有各自的关注点．本文的内存泄漏检测是基于数据流分析的，需要完成过程间的数据流分析，当遇到方法调用时如何处理方法对数据流产生的影响是解决问题的关键．基于摘要的过程间分析方法非常灵活，可以根据分析的需求定义不同的摘要信息，按照摘要的详细程度也可以控制分析的精度，具有较好的扩展性，能够很方便地扩展到大规模的程序分析中去．本文设计了如图３所示的基于摘要过程间分析框架．整个过程间分析系统可以分为３大块，分别是对Ｂｙｔｅｃｏｄｅ倡的预处理模块、过程内分析模块以及过程间分析与方法摘要模块，具体如下：１）预处理模块是对转化好的Ｂｙｔｅｃｏｄｅ倡进行分Ｆｉｇ．３　Ｉｎｔｅｒｐｒｏｃｅｄｕｒａｌａｎａｌｙｓｉｓ．图３　过程间分析框架图析，生成对应规模的调用图，对涉及到的所有方法进行排序，不考虑方法自身直接递归的情况，同时初始化方法摘要．２）过程内分析模块是整个系统的核心模块，因为过程间分析最终要通过方法摘要转化到过程内分析．该模块生成每个方法的控制流图，实施实际的内存泄漏检测，获取与应用方法摘要，保留分析后的结果．３）过程间分析与方法摘要模块是整个分析过程的连接枢纽，主要是提供过程间分析框架，按照顺序组织分析的过程，通过过程内分析的结果生成方法摘要，在分析结束后报告结果．３．３　基于Ｓｏｏｔ的过程间内存泄漏检测实现Ｓｏｏｔ是加拿大ＭｃＧｉｌｌ大学Ｓａｂｌｅ研究小组开发的针对ＪａｖａＢｙｔｅｃｏｄｅ的优化和分析工具，它面向不同的分析和优化目的建立了各种内部的中间表示，既可以辅助过程内分析，也能为过程间分析提供支持，而且具有较好的扩展性，所以本文选择Ｓｏｏｔ作为本文分析工具的基础框架．３．３．１　调用图生成和预处理Ｓｏｏｔ提供了多种不同调用图算法的具体实现，无论使用哪种调用图构建算法，只是相对地提高了精度，还需要自己实现调用图的修剪工作．读入原始调用图后，从调用图的入口节点按照调用关系做一个广度优先遍历，只有能从入口节点直接或间接到达而且没有被过滤器过滤的方法才会被加入辅助调用图中，它的前驱和后继都会被保存下来．为减少后期迭代的次数，需要对这些方法进行拓扑排序，由于调用图不保证无环，采用对辅助调用图节点倒序排序．２０９计算机研究与发展　２０１５，５２（４）３．３．２　过程内分析和摘要提取Ｓｏｏｔ中提供３种不同的数据流分析框架，由于内存缺陷是路径敏感，所以本文采用Ｆｏｒｗａｒｄ‐Ｂｒａｎｃｈｅｄ‐ＦｌｏｗＡｎａｌｙｓｉｓ框架，它具备不同的信息通过各分支的分支节点传播的分析能力，对应着路径敏感的数据流分析．检测方法通过扩展上述框架实现，对每一个程序语句节点ｓ的数据流值集合Ｉｎ［ｓ］，提供了２个数据流值集合来表述语句转换后的新数据流值集合———直接流向的集合（ｆａｌｌｔｈｒｏｕｇｈＯＵＴ）和分支流向的集合（ｂｒａｎｃｈＯＵＴ），用以保存语句不同分支的数据流值，达到路径敏感的目的．摘要提取在过程内分析的基础上进行，每个方法结束时我们保留必要的数据流状态信息，作为这个函数的摘要．３．３．３　过程间分析检测完成过程间分析，需要组织整个分析过程，建立过程间分析框架，对所有方法进行分析，定义过程间分析类．分析在类的成员方法中展开，基于经典的工作队列算法实现，具体过程是按拓扑排序对每个方法开展分析，执行过程内分析算法．当遇到方法调用时，获得被调用方法的摘要，将其对数据流状态的影响作用于上下文中，完成分析后生成方法的摘要，如果摘要信息与已保存的信息不同，就对所有调用过它的方法重新分析，获得新的摘要信息，如此迭代直到所有方法的摘要信息都不再改变时，就完成了分析过程．整个过程中，方法摘要信息以及进行过程间分析时的控制流处理对于检查方法的精度有着决定性的影响．详细的摘要信息能够扩大检测的覆盖率；精细的控制流处理对于加强大规模复杂程序的检测准确率、降低误判情况更有帮助．目前的分析检测策略能准确检测出典型内存泄漏，设计扩展更大规模更复杂的分析策略以应用到更复杂的场景中也是我们下一步的研究方向．４　典型内存泄漏检测过程实现了整个安全检测方法之后，本文对实际的Ｊａｖａ桙Ｃ＋＋ＪＮＩ调用混合语言程序进行检测，并简要介绍分析过程，如下是一个典型的ＪＮＩ环境中内存泄漏实例：１）Ｊａｖａ代码：…⑩ｐｒｉｖａｔｅｓｔａｔｉｃｎａｔｉｖｅｖｏｉｄａｌｌｏｃｏｂｊ（）；皕瑏瑡ｐｒｉｖａｔｅｓｔａｔｉｃｎａｔｉｖｅｖｏｉｄｒｅｌｅａｓｅｏｂｊ（）；皕瑏瑢ｐｕｂｌｉｃｖｏｉｄｔｅｓｔｒｕｎ（ｂｏｏｌｅａｎｆｌａｇ）｛皕瑏瑣ｆｏｒ（ｉｎｔｉ＝０；ｉ＜１０００００；ｉ＋＋）｛皕瑏瑤 ａｌｌｏｃｏｂｊ（）；皕瑏瑥 ｉｆ（ｆｌａｇ）ｒｅｌｅａｓｅｏｂｊ（）；桙倡ｍａｙｌｅａｋ倡桙皕瑏瑦　｝皕瑏瑧｝皕瑏瑨ｓｔａｔｉｃ｛Ｓｙｔｅｍ．ｌｏａｄＬｉｂｒａｒｙ（“ｌｅａｋ‐ｊｎｉ”）；｝…２）Ｃ＋＋代码：…⑤ｃｌａｓｓＣｌｏｃｋ｛…⑩ｐｒｉｖａｔｅ：皕瑏瑡ｉｎｔＡ［１００００］；皕瑏瑢｝皕瑏瑣ｓｔａｔｉｃＣｌｏｃｋ倡ｆ＝ＮＵＬＬ；皕瑏瑤ｅｘｔｅｒｎ“Ｃ”｛皕瑏瑥ＪＮＩＥＸＰＯＲＴｖｏｉｄＪＮＩＣＡＬＬＪａｖａ＿ｔｅｓｔ＿ＨｅｌｌｏＪＮＩ＿ａｌｌｏｃｏｂｊ（ＪＮＩＥｎｖ倡ｅｎｖ，ｊｏｂｊｅｃｔｔｈｉｚ）｛皕瑏瑦　ｆ＝ｎｅｗＣｌｏｃｋ（）；皕瑏瑧｝皕瑏瑨ＪＮＩＥＸＰＯＲＴｖｏｉｄＪＮＩＣＡＬＬＪａｖａ＿ｔｅｓｔ＿ＨｅｌｌｏＪＮＩ＿ｒｅｌｅａｓｅｏｂｊ（ＪＮＩＥｎｖ倡ｅｎｖ，ｊｏｂｊｅｃｔｔｈｉｚ）｛皕瑏瑩　ｄｅｌｅｔｅｆ；皕瑐瑠｝｝ＪＮＩ本地函数Ｊａｖａ＿ｔｅｓｔ＿ＨｅｌｌｏＪＮＩ＿ａｌｌｏｃｏｂｊ（），Ｊａｖａ＿ｔｅｓｔ＿ＨｅｌｌｏＪＮＩ＿ｒｅｌｅａｓｅｏｂｊ（）分别实现了内存申请和释放，Ａｎｄｒｏｉｄ应用程序Ｊａｖａ代码中函数ｔｅｓｔｒｕｎ（）通过ＪＮＩ接口调用这２个函数，内存释放与参数ｆｌａｇ的取值有关，并非所有执行路径上都能够调用内存释放操作，因此可能造成内存泄漏，大量的内存泄漏可能导致当前进程崩溃，采用已有的分析工具尚无法对此类跨语言跨过程的漏洞进行分析．如果仅在Ｊａｖａ端代码展开分析，结果如下：代ｉｃｏｎｓｔ＿０①ｉｓｔｏｒｅ＿２②ｇｏｔｏ１８（＋１６）…３０９蒋挺宇等：基于中间语言的ＪＮＩ内存泄漏检查⑤ｉｎｖｏｋｅｓｔａｔｉｃ　＃２７棟ｃｎ桙ｙｓｈ桙Ｙｔｏｏｌ桙ｔｅｓｔｓ桙Ｔｅｓｔ桙ａｌｌｏｃｏｂｊ（）Ｖ棡…⑧ｉｌｏａｄ＿１⑨ｉｆｅｑ１５（＋６）…皕瑏瑢ｉｎｖｏｋｅｓｔａｔｉｃ　＃２９棟ｃｎ桙ｙｓｈ桙Ｙｔｏｏｌ桙ｔｅｓｔｓ桙Ｔｅｓｔ桙ｒｅｌｅａｓｅｏｂｊ（）Ｖ棡…皕瑏瑥ｉｉｎｃ２ｂｙ１…皕瑏瑨ｉｌｏａｄ＿２皕瑏瑩ｓｉｐｕｓｈ１００００…皕瑐瑢ｉｆ＿ｉｃｍｐｌｔ５（－１７）…皕瑐瑥ｒｅｔｕｒｎＪａｖａ端对于ａｌｌｏｃｏｂｊ和ｒｅｌｅａｓｅｏｂｊ的分析仅限于２个本地方法声明，而对其实际的操作功能一无所知，所以在此基础分析难以找到问题．按照本文的方案，将Ｃ＋＋代码转化为Ｂｙｔｅｃｏｄｅ倡，并与Ｊａｖａ合并后ａｌｌｏｃｏｂｊ和ｒｅｌｅａｓｅｏｂｊ转化为本地静态方法，对应地调用了ｎａｔｉｖｅ＿ｎｅｗ和ｎａｔｉｖｅ＿ｄｅｌｅｔｅ指令，且有两者的具体实现：…皕瑔瑩ｓｗａｐ皕瑖瑠ｇｅｔｆｉｅｌｄ　＃９４棟ｏｒｇ桙ｔｈｕ桙ｌｌｊｖｍ桙ｈｅｌｐｅｒ桙＿ｊａｒｒａｙ＿ＪＮＩＴＹＰ２桙ｄａｔａＩｎｄｅｘ］…皕瑖瑣ａｌｏａｄ＿１皕瑖瑤ａａｓｔｏｒｅ皕瑖瑥ｉｎｖｏｋｅｓｔａｔｉｃ　＃１１７棟ｏｒｇ桙ｔｈｕ桙ｌｌｊｖｍ桙ｈｅｌｐｅｒ桙ＣｌｏｃｋＰ１桙ｎａｔｉｖｅ＿ｎｅｗ（）棡…皕瑖瑨ａｓｔｏｒｅ６…皕瑘瑠ａｌｏａｄ６…皕瑘瑢ａｓｔｏｒｅ７…经过分析可以得到２个方法的摘要分别为ａｌｌｏｃｏｂｊ（｛棟ｆ，ＣｌｏｃｋＰ２，｛ｆ｝，Ａ棡｝），ｒｅｌｅａｓｅｏｂｊ（Ｓｔａｔｅ（ｆ，Ａ）；｛棟ｆ，ＣｌｏｃｋＰ２，｛ｆ｝，Ｕ棡｝）．ａｌｌｏｃｏｂｊ的摘要表示该方法进行的操作：给类Ｃｌｏｃｋ的指针ｆ进行了分配内存操作；Ａ代表Ａｌｌｏｃａｔｅ．ｒｅｌｅａｓｅｏｂｊ的摘要，表示该方法进行的操作：给类Ｃｌｏｃｋ的指针ｆ进行了类型释放操作；Ｕ代表Ｕｎａｌｌｏｃａｔｅ，同时操作前状态是已为ｆ分配了内存；Ｓｔａｔｅ表示操作涉及的变量的内存状态．因而，通过摘要可以确定ａｌｌｏｃｏｂｊ方法和ｒｅｌｅａｓｅｏｂｊ需要配对出现．至此，问题被转化为Ｂｙｔｅｃｏｄｅ倡语言内过程间分析．分析流程如图４所示：Ｆｉｇ．４　Ａｎａｌｙｓｉｓｐｒｏｇｒｅｓｓｏｆｔｅｓｔｒｕｎ．图４　ｔｅｓｔｒｕｎ方法分析流程ａｌｌｏｃｏｂｊ方法结束后的数据流集为｛棟ｆ，ＣｌｏｃｋＰ２，｛ｆ｝，Ａ棡｝，ｒｅｌｅａｓｅｏｂｊ的数据流集为｛棟ｆ，ＣｌｏｃｋＰ２，｛ｆ｝，Ｕ棡｝，经过变换作为２个方法的摘要．在数据流合并操作ｍｅｒｇｅ（Ｔ，Ｆ）之后，数据流集为｛棟ｆ，ＣｌｏｃｋＰ２，｛ｆ｝，Ａ棡｝，此时ｔｅｓｔｒｕｎ退出，数据流状态为ｆ已分配内存，没有释放，报告一个可能内存泄漏的检查点．表２为对多种内存泄漏问题检测结果，所使用的例子来自现有的ＪＮＩ内存泄漏代码以及研究中设计的简单例子，经测试均可通过本文的分析方法找到问题所在．Ｔａｂｌｅ２　ＲｅｓｕｌｔｓｏｆＭｅｍｏｒｙＬｅａｋＤｅｔｅｃｔｉｏｎ表２　对多种内存泄漏问题的检测结果ＰｒｏｂｌｅｍｓＤｅｔｅｃｔｉｏｎＲｅｓｕｌｔｓＮｏｔａｔａｌｌｔｈｅｐｒｏｇｒａｍｅｘｅｃｕｔｉｏｎｐａｔｈｔｏｒｅｌｅａｓｅａｌｌｏｃａｔｅｄｍｅｍｏｒｙ．ＳｕｃｃｅｓｓＭｅｍｏｒｙｉｓａｌｌｏｃａｔｅｄｂｕｔｎｏｔｒｅｌｅａｓｅｄｉｎｍｅｔｈｏｄｃａｌｌ．ＳｕｃｃｅｓｓＭｅｍｏｒｙｉｓａｌｌｏｃａｔｅｄｍａｎｙｔｉｍｅｓｂｕｔｏｎｌｙｒｅｌｅａｓｅｄｏｎｃｅｉｎａｌｏｏｐ．ＳｕｃｃｅｓｓＡｌｌｏｃａｔｅａｎｄｒｅｌｅａｓｅａｃｔｉｏｎｎｏｔｍａｔｃｈｉｎｇｉｎｓｏｍｅｐａｔｈ．Ｓｕｃｃｅｓｓ通过对多个例子的分析对比，本文方法能够将ＪＮＩ两端语言转换到同一中间表示，且保留内存操４０９计算机研究与发展　２０１５，５２（４）作的语义特征，消除多语言带来的分析障碍．虽然大规模复杂样例的测试验证有待进一步研究完善，但通过典型例子的实验论证了方法的有效性和可行性．５　结论及未来工作展望随着使用Ｊａｖａ语言开发的应用程序日益增多，对性能的要求以及嵌入式操作系统的需要越来越高，ＪＮＩ本地接口技术发挥着越发重要的作用．由于ＪＮＩ接口所调用的本地语言如Ｃ＋＋，在安全机制上与Ｊａｖａ语言存在着明显的差异，导致两者交互调用的过程中可能存在安全隐患．现有的检测工具大多仅能在Ｊａｖａ或本地代码一端进行检测，已有的跨语言分析技术也局限于Ｊａｖａ桙Ｃ或者过程内分析，无法有效地处理ＪＮＩ中Ｊａｖａ桙Ｃ＋＋间由于跨语言控制流带来的安全问题．针对这一情况，本文设计实现了基于扩展的ＪａｖａＢｙｔｅｃｏｄｅ（Ｂｙｔｅｃｏｄｅ倡）中间语言的过程间分析检测方法，并以典型的内存泄漏代码为例进行了实验．结果表明，本文工作能够准确检测出Ｊａｖａ桙Ｃ＋＋混合语言中的内存泄漏问题．ＪＮＩ跨语言调用可能引发的安全缺陷并不局限于内存泄漏，目前的翻译和检测主要围绕内存泄漏，但整个方案的设计已经考虑到了将来的扩展性．因此，下一步的工作是在完善现有方法的基础上扩展跨语言检测平台的功能，并进行更大范围的量化分析和有效性验证，主要包括：Ｃ＋＋中强制类型转换等操作尚未进行扩展，接下来可根据不同安全缺陷特征进行完善；对于ＪａｖａＢｙｔｅｃｏｄｅ扩展指令进行形式化的验证；构建更多的跨语言检测模型，应用到更大规模的分析环境中去．致谢　在此，我们向对本文的工作给予建议的同行，特别是Ｉｎｔｅｌ中国研究院陈兴中先生、中国科学技术大学冯新宇教授和华保健副教授、Ｌｅｈｉｇｈ大学谭刚博士等人以及第十二届全国软件与应用学术会议（ＮＡＳＡＣ２０１３）的评审专家们表示感谢！参考文献［１］ＬｉａｎｇＳｈｅｎｇ．ＴｈｅＪａｖａＮａｔｉｖｅＩｎｔｅｒｆａｃｅＰｒｏｇｒａｍｍｅｒ摧ｓＧｕｉｄｅａｎｄＳｐｅｃｉｆｉｃａｔｉｏｎ［Ｍ］．Ｒｅａｄｉｎｇ，ＭＡ：Ａｄｄｉｓｏｎ‐Ｗｅｓｌｅｙ，１９９９［２］ＤｅｖｅｌｏｐｅｒｓｏｆＡｎｄｒｏｉｄ．ＷｈａｔｉｓＡｎｄｒｏｉｄ［ＥＢ桙ＯＬ］．２０１１［２０１２‐０２‐１０］．ｈｔｔｐ：桙桙ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ桙ｇｕｉｄｅ桙ｂａｓｉｃｓ桙ｗｈａｔ‐ｉｓ‐ａｎｄｒｏｉｄ．ｈｔｍ［３］ＰｅｒｅｚＳ．ＦｉｒｓｔｔｒｏｊａｎｆｏｒＡｎｄｒｏｉｄｐｈｏｎｅｓｇｏｅｓｗｉｌｄ［ＥＢ桙ＯＬ］．２０１２［２０１２‐０３‐１０］．ｈｔｔｐ：桙桙ｒｅａｄｗｒｉｔｅ．ｃｏｍ桙２０１０桙０８桙０９桙ｆｉｒｓｔ＿ｔｒｏｊａｎ＿ｆｏｒ＿ａｎｄｒｏｉｄ＿ｐｈｏｎｅｓ＿ｇｏｅｓ＿ｗｉｌｄ［４］ＤａｖｉＬ，ＤｍｉｔｒｉｅｎｋｏＡ，ＳａｄｅｇｈｉＡ‐Ｒ，ｅｔａｌ．Ｐｒｉｖｉｌｅｇｅｅｓｃａｌａｔｉｏｎａｔｔａｃｋｓｏｎａｎｄｒｏｉｄ［Ｇ］桙桙ＬＮＣＳ６５３１：Ｐｒｏｃｏｆｔｈｅ１３ｔｈＩｎｔＣｏｎｆｏｎＩｎｆｏｒｍａｔｉｏｎＳｅｃｕｒｉｔｙ．Ｂｅｒｌｉｎ：Ｓｐｒｉｎｇｅｒ，２０１１：３４６３６０［５］ＳｃｈｍｉｄｔＡＤ，ＳｃｈｍｉｄｔＨＧ，ＢａｔｙｕｋＬ，ｅｔａｌ．Ｓｍａｒｔｐｈｏｎｅｍａｌｗａｒｅｅｖｏｌｕｔｉｏｎｒｅｖｉｓｉｔｅｄ：Ａｎｄｒｏｉｄｎｅｘｔｔａｒｇｅｔ［Ｃ］桙桙Ｐｒｏｃｏｆｔｈｅ４ｔｈＩｎｔＣｏｎｆｏｎＭａｌｉｃｉｏｕｓａｎｄＵｎｗａｎｔｅｄＳｏｆｔｗａｒｅ．Ｐｉｓｃａｔａｗａｙ，ＮＪ：ＩＥＥＥ，２００９：１７［６］ＡｙｅｗａｈＮ，ＰｕｇｈＷ，ＭｏｒｇｅｎｔｈａｌｅｒＪＤ，ｅｔａｌ．ＵｓｉｎｇＦｉｎｄＢｕｇｓｏｎｐｒｏｄｕｃｔｉｏｎｓｏｆｔｗａｒｅ［Ｃ］桙桙Ｐｒｏｃｏｆｔｈｅ２２ｎｄＡＣＭＳＩＧＰＬＡＮＣｏｎｆｏｎＯｂｊｅｃｔ‐ＯｒｉｅｎｔｅｄＰｒｏｇｒａｍｍｉｎｇＳｙｓｔｅｍｓａｎｄＡｐｐｌｉｃａｔｉｏｎｓＣｏｍｐａｎｉｏｎ．ＮｅｗＹｏｒｋ：ＡＣＭ，２００７：８０５８０６［７］ＥｉｎａｒｓｓｏｎＡ，ＮｉｅｌｓｅｎＪＤ．Ａｓｕｒｖｉｖｏｒ摧ｓｇｕｉｄｅｔｏＪａｖａｐｒｏｇｒａｍａｎａｌｙｓｉｓｗｉｔｈＳｏｏｔ（Ｖｅｒｓｉｏｎ１．１）［ＥＢ桙ＯＬ］．（２００８‐０７‐１７）［２０１２‐０３‐１０］．ｈｔｔｐ：桙桙ｗｗｗ．ｂｒｉｃｓ．ｄｋ桙ＳｏｏｔＧｕｉｄｅ［８］ＤｅｖｅｌｏｐｅｒｓｏｆＡｎｄｒｏｉｄ．ＡｎｄｒｏｉｄＬｉｎｔ［ＥＢ桙ＯＬ］．２０１１［２０１２‐０２‐１０］．ｈｔｔｐ：桙桙ｔｏｏｌｓ．ａｎｄｒｏｉｄ．ｃｏｍ桙ｔｉｐｓ桙ｌｉｎｔ［９］ＢｒａｎｄＤ．Ｅｒｒｏｒｄｅｔｅｃｔｉｏｎｂｙｄａｔａｆｌｏｗａｎａｌｙｓｉｓｒｅｓｔｒｉｃｔｅｄｔｏｅｘｅｃｕｔａｂｌｅｐａｔｈｓ［ＥＢ桙ＯＬ］．ＮｅｗＹｏｒｋ：ＩＢＭＴＪＷａｔｓｏｎＲｅｓｅａｒｃｈＣｅｎｔｅｒ，１９９９［２０１２‐０３‐０４］．ｈｔｔｐ：桙桙ｗｗｗ．ｒｅｓｅａｒｃｈ．ｉｂｍ．ｃｏｍ桙ｄａ桙ｂｅａｍ．ｈｔｍｌｓ［１０］ＫｏｎｄｏｈＧ，ＯｎｏｄｅｒａＴ．ＦｉｎｄｉｎｇｂｕｇｓｉｎＪａｖａｎａｔｉｖｅｉｎｔｅｒｆａｃｅｐｒｏｇｒａｍｓ［Ｃ］桙桙Ｐｒｏｃｏｆｔｈｅ２００８ＩｎｔＳｙｍｐｏｎＳｏｆｔｗａｒｅＴｅｓｔｉｎｇａｎｄＡｎａｌｙｓｉｓ．ＮｅｗＹｏｒｋ：ＡＣＭ，２００８：１０９１１８［１１］ＺｈａｏＪｉａｎｚｈｏｕ，ＮａｇａｒａｋａｔｔｅＳ，ＭａｒｔｉｎＭＭ，ｅｔａｌ．ＦｏｒｍａｌｉｚｉｎｇｔｈｅＬＬＶＭｉｎｔｅｒｍｅｄｉａｔｅｒｅｐｒｅｓｅｎｔａｔｉｏｎｆｏｒｖｅｒｉｆｉｅｄｐｒｏｇｒａｍｔｒａｎｓｆｏｒｍａｔｉｏｎｓ［Ｊ］．ＡＣＭＳＩＧＰＬＡＮＮｏｔｉｃｅｓ，２０１２，４７（１）：４２７４４０［１２］ＲｏｂｅｒｔｓＤＡ．ＬＬＪＶＭ［ＥＢ桙ＯＬ］．２０１２［２０１２‐１０‐２３］．ｈｔｔｐ：桙桙ｄａ．ｖｉｄｒ．ｃｃ桙ｐｒｏｊｅｃｔｓ桙ｌｌｊｖｍ［１３］ＦｕｒｒＭ，ＦｏｓｔｅｒＪＳ．ＰｏｌｙｍｏｒｐｈｉｃＴｙｐｅＩｎｆｅｒｅｎｃｅｆｏｒｔｈｅＪＮＩ［Ｍ］．Ｂｅｒｌｉｎ：Ｓｐｒｉｎｇｅｒ，２００６：３０９３２４［１４］ＴａｎＧａｎｇ，ＡｐｐｅｌＡＷ，ＣｈａｋｒａｄｈａｒＳ，ｅｔａｌ．ＳａｆｅＪａｖａｎａｔｉｖｅｉｎｔｅｒｆａｃｅ［Ｃ］桙桙ＰｒｏｃｏｆＩＥＥＥＩｎｔＳｙｍｐｏｎＳｅｃｕｒｅＳｏｆｔｗａｒｅＥｎｇｉｎｅｅｒｉｎｇ．Ｐｉｓｃａｔａｗａｙ，ＮＪ：ＩＥＥＥ，２００６：９７１０６［１５］ＴａｎＧａｎｇ，ＭｏｒｒｉｓｅｔｔＧ．ＩＬＥＡ：Ｉｎｔｅｒ‐ｌａｎｇｕａｇｅａｎａｌｙｓｉｓａｃｒｏｓｓＪａｖａａｎｄＣ［Ｊ］．ＡＣＭＳＩＧＰＬＡＮＮｏｔｉｃｅｓ，２００７，４２（１０）：３９５６［１６］ＢｏｄｄｅｎＥ．Ｉｎｔｅｒ‐ｐｒｏｃｅｄｕｒａｌｄａｔａｆｌｏｗａｎａｌｙｓｉｓｗｉｔｈｉｆｄｓ桙ｉｄｅａｎｄｓｏｏｔ［Ｃ］桙桙ＰｒｏｃｏｆｔｈｅＡＣＭＳＩＧＰＬＡＮＩｎｔＷｏｒｋｓｈｏｐｏｎＳｔａｔｅｏｆｔｈｅＡｒｔｉｎＪａｖａＰｒｏｇｒａｍＡｎａｌｙｓｉｓ．ＮｅｗＹｏｒｋ：ＡＣＭ，２０１２：３８［１７］ＲｅｐｓＴ，ＨｏｒｗｉｔｚＳ，ＳａｇｉｖＭ．Ｐｒｅｃｉｓｅｉｎｔｅｒｐｒｏｃｅｄｕｒａｌｄａｔａｆｌｏｗａｎａｌｙｓｉｓｖｉａｇｒａｐｈｒｅａｃｈａｂｉｌｉｔｙ［Ｃ］桙桙Ｐｒｏｃｏｆｔｈｅ２２ｎｄＡＣＭＳＩＧＰＬＡＮ‐ＳＩＧＡＣＴＳｙｍｐｏｎＰｒｉｎｃｉｐｌｅｓｏｆＰｒｏｇｒａｍｍｉｎｇＬａｎｇｕａｇｅｓ．ＮｅｗＹｏｒｋ：ＡＣＭ，１９９５：４９６１［１８］ＳｈａｒｉｒＭ，ＰｎｕｅｌｉＡ．ＰｒｏｇｒａｍＦｌｏｗＡｎａｌｙｓｉｓ：ＴｈｅｏｒｙａｎｄＡｐｐｌｉｃａｔｉｏｎｓ［Ｍ］．ＥｎｇｌｅｗｏｏｄＣｌｉｆｆｓ，ＮＪ：Ｐｒｅｎｔｉｃｅ‐Ｈａｌｌ，１９８１：１８９２３３５０９蒋挺宇等：基于中间语言的ＪＮＩ内存泄漏检查［１９］ＣａｄａｒＣ，ＧａｎｅｓｈＶ，ＰａｗｌｏｗｓｋｉＰＭ，ｅｔａｌ．ＥＸＥ：Ａｕｔｏｍａｔｉｃａｌｌｙｇｅｎｅｒａｔｉｎｇｉｎｐｕｔｓｏｆｄｅａｔｈ［Ｊ］．ＡＣＭＴｒａｎｓｏｎＩｎｆｏｒｍａｔｉｏｎａｎｄＳｙｓｔｅｍＳｅｃｕｒｉｔｙ，２００８，１２（２）：１０２４［２０］ＤｉｌｌｉｇＩ，ＤｉｌｌｉｇＴ，ＡｉｋｅｎＡ．Ｓｏｕｎｄ，ｃｏｍｐｌｅｔｅａｎｄｓｃａｌａｂｌｅｐａｔｈ‐ｓｅｎｓｉｔｉｖｅａｎａｌｙｓｉｓ［Ｊ］．ＡＣＭＳＩＧＰＬＡＮＮｏｔｉｃｅｓ，２００８，４３（６）：２７０２８０［２１］ＤｏｒＮ，ＡｄａｍｓＳ，ＤａｓＭ，ｅｔａｌ．Ｓｏｆｔｗａｒｅｖａｌｉｄａｔｉｏｎｖｉａｓｃａｌａｂｌｅｐａｔｈ‐ｓｅｎｓｉｔｉｖｅｖａｌｕｅｆｌｏｗａｎａｌｙｓｉｓ［Ｊ］．ＡＣＭＳＩＧＳＯＦＴＳｏｆｔｗａｒｅＥｎｇｉｎｅｅｒｉｎｇＮｏｔｅｓ，２００４，２９（４）：１２２２ＪｉａｎｇＴｉｎｇｙｕ，ｂｏｒｎｉｎ１９９０．ＭａｓｔｅｒｃａｎｄｉｄａｔｅａｔｔｈｅＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，ＴｓｉｎｇｈｕａＵｎｉｖｅｒｓｉｔｙ．Ｈｉｓｍａｉｎｒｅｓｅａｒｃｈｉｎｔｅｒｅｓｔｓｉｎｃｌｕｄｅｓｙｓｔｅｍｓｏｆｔｗａｒｅａｎｄｓｏｆｔｗａｒｅｅｎｇｉｎｅｅｒｉｎｇ．ＷａｎｇＰｅｎｇ，ｂｏｒｎｉｎ１９８０．ＭａｓｔｅｒａｔｔｈｅＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，ＴｓｉｎｇｈｕａＵｎｉｖｅｒｓｉｔｙ．Ｈｉｓｍａｉｎｒｅｓｅａｒｃｈｉｎｔｅｒｅｓｔｓｉｎｃｌｕｄｅｓｙｓｔｅｍｓｏｆｔｗａｒｅａｎｄｓｏｆｔｗａｒｅｅｎｇｉｎｅｅｒｉｎｇ（ｗｐｈｆ１９８０＠１６３．ｃｏｍ）．ＹａｎｇＳｈｕ，ｂｏｒｎｉｎ１９７８．ＭａｓｔｅｒａｔｔｈｅＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，ＴｓｉｎｇｈｕａＵｎｉｖｅｒｓｉｔｙ．Ｈｉｓｍａｉｎｒｅｓｅａｒｃｈｉｎｔｅｒｅｓｔｓｉｎｃｌｕｄｅｓｙｓｔｅｍｓｏｆｔｗａｒｅａｎｄｓｏｆｔｗａｒｅｅｎｇｉｎｅｅｒｉｎｇ（ｃｏｍｅ＿ｇｏ＠１６３．ｃｏｍ）．ＲｕＺｈｅｎ，ｂｏｒｎｉｎ１９９１．ＭａｓｔｅｒｃａｎｄｉｄａｔｅａｔｔｈｅＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，ＴｓｉｎｇｈｕａＵｎｉｖｅｒｓｉｔｙ．Ｈｉｓｍａｉｎｒｅｓｅａｒｃｈｉｎｔｅｒｅｓｔｓｉｎｃｌｕｄｅｓｙｓｔｅｍｓｏｆｔｗａｒｅａｎｄｓｏｆｔｗａｒｅｅｎｇｉｎｅｅｒｉｎｇ（ｒｕｚｈｅｎ９９９９＠１６３．ｃｏｍ）．ＤｏｎｇＹｕａｎ，ｂｏｒｎｉｎ１９７３．ＰｈＤ，ａｓｓｏｃｉａｔｅｐｒｏｆｅｓｓｏｒａｔｔｈｅＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，ＴｓｉｎｇｈｕａＵｎｉｖｅｒｓｉｔｙ．ＭｅｍｂｅｒｏｆＣｈｉｎａＣｏｍｐｕｔｅｒＦｅｄｅｒａｔｉｏｎ．Ｈｉｓｍａｉｎｒｅｓｅａｒｃｈｉｎｔｅｒｅｓｔｓｉｎｃｌｕｄｅｏｐｅｒａｔｉｎｇｓｙｓｔｅｍ，ｃｏｍｐｉｌｅｒａｎｄｌａｎｇｕａｇｅ‐ｂａｓｅｄｓｅｃｕｒｉｔｙ（ｄｏｎｇｙｕａｎ＠ｔｓｉｎｇｈｕａ．ｅｄｕ．ｃｎ）．ＷａｎｇＳｈｅｎｇｙｕａｎ，ｂｏｒｎｉｎ１９６４．ＰｈＤ，ａｓｓｏｃｉａｔｅｐｒｏｆｅｓｓｏｒａｔｔｈｅＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，ＴｓｉｎｇｈｕａＵｎｉｖｅｒｓｉｔｙ．ＳｅｎｉｏｒｍｅｍｂｅｒｏｆＣｈｉｎａＣｏｍｐｕｔｅｒＦｅｄｅｒａｔｉｏｎ．Ｈｉｓｍａｉｎｒｅｓｅａｒｃｈｉｎｔｅｒｅｓｔｓｉｎｃｌｕｄｅｐｒｏｇｒａｍｍｉｎｇｌａｎｇｕａｇｅｓａｎｄｓｙｓｔｅｍｓ，ｐｅｔｒｉｎｅｔａｐｐｌｉｃａｔｉｏｎ（ｗｗｓｓｙｙ＠ｔｓｉｎｇｈｕａ．ｅｄｕ．ｃｎ）．ＪｉＺｈｉｙｕａｎ，ｂｏｒｎｉｎ１９５６．ＳｅｎｉｏｒＥｎｇｉｎｅｅｒｉｎｔｈｅＨｉｇｈＴｅｃｈｎｏｌｏｇｙＲｅｓｅａｒｃｈａｎｄＤｅｖｅｌｏｐｍｅｎｔＣｅｎｔｅｒ．Ｈｉｓｍａｉｎｒｅｓｅａｒｃｈｉｎｔｅｒｅｓｔｓｉｎｃｌｕｄｅｃｏｍｐｕｔｅｒｓｃｉｅｎｃｅａｎｄｅｍｂｅｄｄｅｄｓｏｆｔｗａｒｅ，ｔｅｃｈｎｏｌｏｇｙｍａｎａｇｅｍｅｎｔｏｆｔｈｅｎａｔｉｏｎａｌｓｃｉｅｎｃｅａｎｄｔｅｃｈｎｏｌｏｇｙｐｌａｎ（ｊｚｙ＠ｈｔｒｄｃ．ｃｏｍ）．６０９计算机研究与发展　２０１５，５２（４）。