技术报告
This commit is contained in:
parent
3a0254adfa
commit
ca8d2d4e75
203
技术报告/技术总结报告_袁金沙(1).docx
Normal file
203
技术报告/技术总结报告_袁金沙(1).docx
Normal file
@ -0,0 +1,203 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
技术总结报告
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
服务名称:XXXXXX
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
目 录
|
||||||
|
二、 研究内容 4
|
||||||
|
2.1 恶意软件特征提取 4
|
||||||
|
2.1.1 恶意软件相关概念 4
|
||||||
|
2.1.2 恶意软件汇编信息介绍 5
|
||||||
|
2.1.3 特征提取:恶意软件汇编信息 6
|
||||||
|
2.2 复杂恶意软件分类检测 7
|
||||||
|
2.2.1 Kaggle数据集介绍 7
|
||||||
|
2.2.2 恶意软件数据集介绍 8
|
||||||
|
2.2.3 操作码Opcode n-gram序列特征进行恶意家族分类技术实现 9
|
||||||
|
2.2.4 灰度图ASM-image特征进行恶意家族分类技术实现 11
|
||||||
|
三、 研究内容实现情况 14
|
||||||
|
四、 功能测试 15
|
||||||
|
4.1测试方法及步骤 15
|
||||||
|
4.2测试过程及结果 15
|
||||||
|
4.3 测试结论 24
|
||||||
|
|
||||||
|
一、 研究目标实现情况
|
||||||
|
依据课题研究任务,为了更好地了解威胁、更快速地识别和响应攻击、更准确地预测攻击趋势和未来的攻击类型、设计和实施更有效的安全防御措施、更好地促进威胁情报共享,因此需要研究大规模复杂软件家族分类技术。
|
||||||
|
针对大规模复杂软件家族分类技术,主要实现了以下2个子任务的研究:
|
||||||
|
完成恶意软件特征提取任务,本技术利用恶意软件的汇编信息进行恶意软件分类,提取软件的深层行为特征。
|
||||||
|
完成对复杂恶意软件分类检测任务,并实现不少于9种的恶意家族分类,包括Ramnit、Lollipop、Kelihos_ver3、Vundo、Simda、Tracur、Kelihos_ver1等恶意家族。
|
||||||
|
|
||||||
|
二、 研究内容
|
||||||
|
本技术总结报告主要介绍大规模复杂软件家族分类技术完成情况及技术细节,详细内容如下:
|
||||||
|
2.1 恶意软件特征提取
|
||||||
|
2.1.1 恶意软件相关概念
|
||||||
|
恶意软件家族分类是指将具有相似行为和功能的恶意软件归为同一类别。由于恶意软件样本通常都是二进制文件,其内容非常复杂,很难直接分析和理解。如果直接对恶意软件进行操作,可能会面临以下风险和困难:
|
||||||
|
安全性风险:恶意软件样本中包含恶意代码和脚本,这些代码和脚本可能自动执行并攻击分析者的计算机系统,会影响分析者的系统和网络安全。
|
||||||
|
可操作性困难:对于某些恶意软件,它们的运行需要特定的环境和条件,而这些条件可能非常难以在实验室中模拟和操作。此外,对于一些高级的恶意软件,分析者可能需要花费大量的时间和精力才能进行分析和理解。
|
||||||
|
不可重复性:在对恶意软件进行操作的过程中,可能会出现一些不可预测的结果,这些结果可能会对分类和分析产生影响,导致分析结果不可重复和不可靠。而通过对特征进行提取和分析,可以保证结果的可靠性和重复性。
|
||||||
|
因此,需要从这些样本中提取特征,以便更好地了解其行为和功能,从而进行分类和分析。
|
||||||
|
2.1.2 恶意软件汇编信息介绍
|
||||||
|
恶意软件的汇编指令包含了恶意软件的运行机制和行为,因此,利用恶意软件的汇编信息可以更好地理解和分类恶意软件。本技术利用反汇编工具IDA pro自动识别汇编代码,将二进制代码转换为汇编代码,在反汇编工具中,可以找到每个指令的操作码序列,通过序列了解恶意软件的具体操作,并生成反汇编asm文件,用于后续的特征提取信息,如图1所示。
|
||||||
|
|
||||||
|
图1 二进制文件反汇编
|
||||||
|
利用恶意软件的汇编信息进行恶意软件分类具有以下优点:
|
||||||
|
更为准确:汇编信息包含了恶意软件的运行机制和行为,因此可以更准确地识别和分类恶意软件。相比于其他分类方法,如基于签名的分类方法,汇编信息可以检测到具有相同功能但代码不同的恶意软件。
|
||||||
|
不易受到恶意软件保护机制的影响:一些恶意软件会使用加密、混淆和虚拟化等技术来保护其代码,从而避免被静态分析。而汇编信息是恶意软件运行的结果,不受这些保护机制的影响,因此可以更好地识别和分类这些恶意软件。
|
||||||
|
更有针对性:汇编信息可以帮助更好地理解恶意软件的运行机制和行为,从而有针对性地采取措施来应对这些恶意软件。
|
||||||
|
2.1.3 特征提取:恶意软件汇编信息
|
||||||
|
(1) 操作码提取
|
||||||
|
从二进制文件反编译的.asm文件中提取操作码。由于asm文件中只有以.text部分的代码段中存在操作码,故只需要在.asm文件中以.text开头进行逐行提取操作码,利用正则表达式来匹配获取操作码,提取操作码的流程如图2所示。然后统计文件中各个操作码出现的频数,利用特征选择算法选择出与类标签相关性强的操作码序列作为特征。
|
||||||
|
|
||||||
|
图2 提取操作码序列流程
|
||||||
|
(2) ASM-image提取
|
||||||
|
同一家族恶意软件的代码存在很高的复用性,通过复用的代码添加新的代码就会生成新的恶意软件,因此将同一家族的.asm文件转化为灰度图时,灰度图之间会存在较高相似性,如图3所示。
|
||||||
|
|
||||||
|
|
||||||
|
图3 不同家族的灰度图
|
||||||
|
生成ASM-image特征向量的方法如图4所示。首先将.asm字符文件转化为ACSII值,其次将ASCII码值转化为二进制向量按8位存储在数组中,生成的二进制数组,取值范围0~255,每个元素作为一个字节形成字节向量,然后生成的字节向量转化为灰度图,使用GIST特征描述符生成相应的特征向量。
|
||||||
|
|
||||||
|
图4 ASM文件灰度图生成流程图
|
||||||
|
2.2 复杂恶意软件分类检测
|
||||||
|
2.2.1 Kaggle数据集介绍
|
||||||
|
在本恶意软件家族分类技术中使用了Kaggle数据集中的恶意软件数据集。Kaggle数据集是指存储在Kaggle平台上的大量结构化和非结构化数据集。Kaggle是一个面向数据科学家和机器学习工程师的开放性社区,提供了各种数据挖掘和机器学习比赛以及数据集的共享平台。通过Kaggle数据集,用户可以访问各种真实世界的数据集,进行数据探索、模型开发和分析应用等操作。
|
||||||
|
使用Kaggle数据集进行恶意软件分类的优势包括:
|
||||||
|
大规模的数据集:Kaggle数据集是由全球数据科学家和研究者共同上传和分享的,包含了大量的恶意软件样本和相关特征数据,可以更好地训练和评估恶意软件分类模型。
|
||||||
|
高质量的数据:Kaggle平台严格要求数据集的质量和完整性,所有的数据集都经过了多次审核和验证,可以保证数据的可靠性和准确性。
|
||||||
|
多样化的数据类型:Kaggle数据集包含了各种类型的恶意软件数据,包括二进制文件、程序代码、系统日志等,可以更好地展示恶意软件的多样性和复杂性。
|
||||||
|
2.2.2 恶意软件数据集介绍
|
||||||
|
数据集解压后为400G大小,包括训练样本,测试样本,以及训练样本的标签,标签为一个csv文件,其中详细的标注了训练样本中每一个恶意代码样本的名称以及它所对应的家族种类。
|
||||||
|
系统样本库中所使用的九类恶意代码家族种类为:Ramnit,Lollipop,Kelihos_ver3,Vundo,Simda,Tracur,Kelihos_ver1,Obfuscator.ACY,Gatak。
|
||||||
|
以下是每个家族的详细介绍:
|
||||||
|
Ramnit家族所具备的危害为感染Windows可执行文件和HTML文件并尝试允许远程访问的病毒的检测。
|
||||||
|
Lollipop家族所具备的危害为此广告软件程序会在用户浏览网页时显示广告。它还可以重定向搜索引擎结果,监控用户在PC上执行的操作,下载应用程序以及将有关PC的信息发送给黑客。
|
||||||
|
Kelihos_ver3家族所具备的危害为可以分发垃圾邮件,其中可能包含自身安装程序的Web链接。它还可以连接到远程计算机以交换配置数据以及下载和执行任意文件。
|
||||||
|
Vundo所具备的危害为提供"脱离上下文"的弹出式广告,下载和运行文件,经常作为DLL文件传播,并在未经用户同意的情况下作为浏览器帮助对象(BHO)安装在用户的PC上。
|
||||||
|
Simda所具备的危害为威胁可以为用户的PC提供恶意黑客后门访问和控制。然后,他们可以窃取用户的密码并收集有关用户PC的信息。
|
||||||
|
Tracur所具备的危害为运行时,此脚本会将" explorer.exe "进程添加到Windows防火墙例外列表中,以故意降低系统安全设置。
|
||||||
|
Kelihos_ver1所具备的危害为可以分发垃圾邮件,其中可能包含自身安装程序的Web链接。它还可以连接到远程计算机以交换配置数据以及下载和执行任意文件。
|
||||||
|
Obfuscator.ACY所具备的危害为这种威胁一直是"obfuscated",这意味着它试图隐藏其目的,因此用户的安全软件无法检测到它。混淆之下的恶意软件几乎可以用于任何目的。
|
||||||
|
Gatak所具备的危害为收集有关用户的PC的信息并将其发送给黑客。它可以作为密钥生成器应用程序的一部分到达用户的PC,或者看起来是合法应用程序的更新。
|
||||||
|
2.2.3 操作码Opcode n-gram序列特征进行恶意家族分类技术实现
|
||||||
|
(1) 操作码 n-gram 序列进行恶意家族分类
|
||||||
|
操作码 n-gram 序列是计算机恶意软件(恶意家族)分类的一种常见特征表示方法。使用操作码 n-gram 序列进行恶意家族分类的具体过程如下:
|
||||||
|
① 首先,将收集的恶意软件样本进行反汇编操作,得到样本的asm反汇编文件。
|
||||||
|
② 特征提取:从每个恶意软件样本的asm反汇编文件中提取操作码 n-gram 序列。n-gram 是指连续 n 个操作码的序列。例如,一个 2-gram 操作码序列是指每两个连续的操作码组成一个序列。本技术报告中使用的是3-gram操作码序列。提取操作码 n-gram 序列的目的是为了捕获恶意软件中的行为模式和功能。
|
||||||
|
③ 特征选择:从提取的操作码 n-gram 序列中选择最具有区分性的特征。本技术报告中使用随机森林的特征重要性评估方法来确定最具有区分性的特征。
|
||||||
|
③ 特征表示:使用选择的特征来表示每个恶意软件样本。本技术报告中使用一个向量表示每个样本,向量的每个元素表示一个选择的特征,元素的值表示该特征在该样本中的出现频率。
|
||||||
|
④ 分类器训练:使用标记的恶意软件样本和其对应的特征向量来训练分类器模型。本技术报告中使用支持向量机、随机森林等分类器模型,在训练过程中使用交叉验证来评估模型性能并进行参数调整。
|
||||||
|
⑤ 恶意家族分类:使用训练好的分类器模型来对新的未知恶意软件样本进行分类。提取操作码 3-gram 序列,并使用训练好的特征选择和特征表示方法来得到其特征向量。然后,将该特征向量输入到分类器模型中,得到该样本所属的恶意家族分类。
|
||||||
|
(2) 使用操作码n-gram进行恶意家族分类的优点
|
||||||
|
① 高效性:操作码 n-gram 序列提取可以在较短的时间内完成,使得恶意家族分类的过程更加高效。
|
||||||
|
② 可靠性:操作码 n-gram 序列提取可以捕获恶意软件的关键行为和功能,因此具有很高的可靠性。
|
||||||
|
③ 泛化性:由于操作码 n-gram 序列提取是基于功能和行为,因此对于不同变种的恶意软件,它们的操作码 n-gram 序列可能会存在一些共性,从而可以实现一定程度的泛化,使得分类器具有更好的适应性和泛化性能。
|
||||||
|
④ 可解释性:操作码 n-gram 序列提取是比较直观和可解释的,可以帮助安全分析人员了解恶意软件的行为和功能,从而更好地进行安全风险评估和应对措施制定。
|
||||||
|
⑤ 安全性:由于操作码 n-gram 序列提取不需要运行恶意软件样本,因此不会对系统安全造成任何风险。
|
||||||
|
2.2.4 灰度图ASM-image特征进行恶意家族分类技术实现
|
||||||
|
(1)使用灰度图特征进行恶意家族分类
|
||||||
|
使用灰度图特征进行恶意家族分类的具体过程如下:
|
||||||
|
① 首先,将收集的恶意软件样本进行反汇编操作,得到样本的asm反汇编文件。
|
||||||
|
② 特征提取:从每个恶意软件样本中提取灰度图特征。灰度图是指将恶意软件文件二进制代码以像素形式表示的图像。通过将二进制代码按照一定的宽度转换为灰度图像,然后提取该灰度图像的特征,本技术报告中提取前1500个维度的灰度图像特征。
|
||||||
|
③ 特征选择:从提取的灰度图特征中选择最具有区分性的特征。本技术报告中使用随机森林的特征重要性评估方法来确定最具有区分性的特征。
|
||||||
|
④ 特征表示:使用选择的特征来表示每个恶意软件样本。本技术报告中使用一个向量表示每个样本,向量的每个元素表示一个选择的特征,元素的值表示该特征在该样本灰度图中的像素值。
|
||||||
|
⑤ 分类器训练:使用标记的恶意软件样本和其对应的特征向量来训练分类器模型。本技术报告中使用支持向量机、随机森林等分类器模型,在训练过程中使用交叉验证来评估模型性能并进行参数调整。
|
||||||
|
⑥ 恶意家族分类:使用训练好的分类器模型来对新的未知恶意软件样本进行分类。将恶意软件文件转换成灰度图像,并提取其特征。然后,将该特征向量输入到分类器模型中,得到该样本所属的恶意家族分类。
|
||||||
|
(2) 使用灰度图特征进行恶意家族分类的优点
|
||||||
|
① 快速捕获恶意软件的全貌:灰度图可以将恶意软件文件表示为一个图像,展示出整个恶意软件文件的全貌,相较于仅使用二进制代码或API调用序列等局部信息,可以更全面地了解恶意软件的结构和行为。
|
||||||
|
② 特征提取简单:使用灰度图进行特征提取,只需要使用基本的图像特征提取算法即可,不需要对二进制代码进行复杂的语法分析或解析,因此特征提取的过程相对简单。
|
||||||
|
③ 鲁棒性高:灰度图像对于不同的操作系统和编译器等环境变化不敏感,因此灰度图像特征提取的结果相对稳定,能够更好地应对恶意软件的变异和欺骗行为。
|
||||||
|
④ 易于可视化和理解:灰度图作为一种图像形式,易于可视化和理解,可以直观地呈现特征提取的结果,有助于安全研究人员或其他领域专家对分类结果进行进一步分析和判断。
|
||||||
|
⑤ 可用性广泛:灰度图作为一种基本的图像形式,在计算机视觉、图像处理等领域有广泛的应用,因此使用灰度图进行恶意软件分类的技术也可以借鉴这些领域的成果和方法。
|
||||||
|
|
||||||
|
三、 研究内容实现情况
|
||||||
|
课题组已完成所有上述研究内容,各任务研究内容完成情况及提供支撑材料见表Ⅰ。
|
||||||
|
表Ⅰ 支撑材料表
|
||||||
|
研究内容
|
||||||
|
任务完成情况
|
||||||
|
提供
|
||||||
|
材料
|
||||||
|
备注
|
||||||
|
研究内容1:恶意软件分类特征提取
|
||||||
|
完成恶意软件的汇编信息提取。使用IDA对kaggle恶意样本集样本信息进行反汇编,得到单个样本的asm汇编信息,用于恶意家族分类。
|
||||||
|
Kaggle恶意样本集一份、反汇编样本、特征提取源代码各一份
|
||||||
|
完成
|
||||||
|
研究内容2:复杂恶意软件分类检测
|
||||||
|
完成对复杂恶意软件分类检测任务,对kaggle恶意样本集的2w+个恶意样本实现家族分类。
|
||||||
|
恶意家族分类源代码一份
|
||||||
|
完成
|
||||||
|
|
||||||
|
四、 功能测试
|
||||||
|
为验证项目组提供的支撑材料可靠性,本文档提供了大规模复杂软件家族分类技术源代码测试流程及结果。
|
||||||
|
4.1测试方法及步骤
|
||||||
|
打开pycharm,新建一个conda环境,设置python版本为3.7,导入malware_family_classifiction项目文件。
|
||||||
|
运行PE_to_ASM.py可将PE样本进行反汇编,获取样本的汇编信息。
|
||||||
|
运行asmimage.py可获取样本的灰度图特征。
|
||||||
|
运行opcode_n-gram.py可获取样本的opcode-n-gram特征。
|
||||||
|
运行firstrandomforest.py可使用灰度图对样本集进行恶意家族分类。
|
||||||
|
运行secondrandomforest.py可使用操作码3-gram对样本集进行恶意家族分类。
|
||||||
|
运行combine.py可使用特征融合进行样本的恶意家族分类。
|
||||||
|
4.2测试过程及结果
|
||||||
|
样本反汇编操作:新建一个文件用于存放进行恶意家族分类的PE样本集,在PE_to_ASM.py中,修改文件路径:file_path为新建的样本集文件路径,修改IDA路径:IDA_PATH为idat64.exe的路径,再运行该脚本,得到每个样本的asm反汇编文件,具体操作如图5所示:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
图5 PE样本反汇编操作
|
||||||
|
获取样本asm列表:修改get_Samples_name.py中的文件路径:gswo_path为上述asm文件所在的文件夹路径,再运行get_Samples_name.py,得到样本asm列表的csv文件,用于后续特征提取。具体操作如图6所示:
|
||||||
|
|
||||||
|
|
||||||
|
图6 获取样本asm列表操作
|
||||||
|
asm_image特征提取:修改asmimage.py中的训练样本路径:basepath为训练样本集所在文件夹路径和测试样本路径:basepath_test为测试样本集所在文件夹路径,再运行该脚本,生成样本灰度图特征列表文件imgfeature.csv和imgfeature_demo.csv。具体操作如图7所示:
|
||||||
|
|
||||||
|
(a)asm_image特征提取操作
|
||||||
|
|
||||||
|
(b)asm_image特征提取操作结果显示
|
||||||
|
图7 asm_image特征提取
|
||||||
|
操作码n-gram 特征提取:修改opcode_n-gram.py中的训练样本路径basepath为训练样本集所在文件夹路径和测试样本路径:basepath_test为测试样本集所在文件夹路径,再运行该脚本,生成样本操作码3-gram特征列表文件3gramfeature.csv和3gramopcode_demo.csv。具体操作如图8所示:
|
||||||
|
|
||||||
|
(a)操作码3-gram 特征提取操作
|
||||||
|
|
||||||
|
(b)操作码3-gram 特征提取操作结果显示
|
||||||
|
图8 操作码3-gram 特征提取
|
||||||
|
恶意家族分类:
|
||||||
|
① 根据灰度图特征进行家族分类:
|
||||||
|
修改firstrandomforest.py中的basepath为测试样本文件夹路径,newpath为分类后的样本保存文件夹路径(共有九类恶意家族,文件夹命名为1-9,序号分别对应本文档第二部分2.2.2中的各个家族顺序),再运行脚本,具体操作如图9所示:
|
||||||
|
|
||||||
|
图9 根据灰度图特征进行家族分类结果显示
|
||||||
|
利用灰度图进行家族分类,准确度高达98.28%(图9中红框显示结果),将测试样本放入对应的恶意家族文件夹中,如图10所示:
|
||||||
|
|
||||||
|
图10 利用灰度图进行家族分类结果显示
|
||||||
|
② 根据操作码3-gram特征进行家族分类:
|
||||||
|
修改secondrandomforest.py中的basepath为测试样本文件夹路径,newpath为分类后的样本保存文件夹路径(共有九类恶意家族,文件夹命名为1-9,序号分别对应本文档第二部分2.2.2中的各个家族顺序),再运行脚本,具体操作如图11所示:
|
||||||
|
|
||||||
|
图11 操作码3-gram特征进行家族分类
|
||||||
|
利用操作码3-gram进行家族分类,准确度高达97.91%(图11中红框显示结果),将测试样本放入对应的恶意家族文件夹中,如图12所示:
|
||||||
|
|
||||||
|
图12 操作码3-gram特征进行家族分类结果显示
|
||||||
|
3.根据特征融合进行家族分类:
|
||||||
|
修改combine.py中的basepath为测试样本文件夹路径,newpath为分类后的样本保存文件夹路径(共有九类恶意家族,文件夹命名为1-9,序号分别对应本文档第二部分2.2.2中的各个家族顺序),再运行脚本,具体操作如图13所示:
|
||||||
|
|
||||||
|
图13 根据特征融合进行家族分类
|
||||||
|
利用特征组合进行家族分类,准确度高达99.52%(图13中红框显示结果),将测试样本放入对应的恶意家族文件夹中,如图14所示:
|
||||||
|
|
||||||
|
图14 根据特征组合进行家族分类结果显示
|
||||||
|
4.3 测试结论
|
||||||
|
本恶意家族分类技术主要是利用恶意软件的汇编信息,首先,通过IDA pro自动反编译工具,提取恶意样本的汇编信息,生成反编译asm文件;其次,从反编译asm文件中提取样本的灰度图、操作码序列作为样本的特征向量;最后,利用单一特征向量和融合特征向量进行恶意软件的恶意家族分类,其中,使用PE恶意软件的单一汇编特征进行恶意家族分类,准确率可以达97.9%以上,使用融合汇编特征进行恶意家族分类效果更佳,准确率高达99.5%。通过测试,本恶意家族分类技术代码功能正常且分类准确率高。
|
||||||
|
|
353
技术报告/技术总结报告模板_廖晋湘.docx
Normal file
353
技术报告/技术总结报告模板_廖晋湘.docx
Normal file
@ -0,0 +1,353 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
技术总结报告
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
服务名称:XXXXXX
|
||||||
|
目 录
|
||||||
|
一、 研究目标实现情况 1
|
||||||
|
二、 研究内容 2
|
||||||
|
2.1 信息库的搭建 2
|
||||||
|
2.1.1 软件基础信息介绍 2
|
||||||
|
2.1.2 搭建过程中的难点与解决方法 12
|
||||||
|
2.1.3 搭建过程中的技术问题 17
|
||||||
|
2.2 软件原始信息的等级评判 18
|
||||||
|
2.2.1 PE文件的评判标准 18
|
||||||
|
2.2.2 ELF文件的评判标准 18
|
||||||
|
三、 研究内容实现情况 19
|
||||||
|
四、 功能测试 21
|
||||||
|
4.1 测试方法与步骤 21
|
||||||
|
4.2 测试过程 21
|
||||||
|
4.2.1 文件信息获取 21
|
||||||
|
4.2.2 数据库初始化设置 22
|
||||||
|
4.2.3 数据库的写入操作 23
|
||||||
|
4.2.4 文件分级 24
|
||||||
|
4.3 测试结果 25
|
||||||
|
|
||||||
|
|
||||||
|
研究目标实现情况
|
||||||
|
依据课题研究任务,大规模的复杂软件数量庞大,需要对其进行筛选,在筛选前也需要对其基本信息进行获取,所以需要对大规模复杂软件的原始信息库进行搭建并对其进行等级划分。
|
||||||
|
针对大规模复杂软件原始信息库的搭建与等级划分,主要实现了以下6个子任务的研究:
|
||||||
|
(1)完成对checksec开源项目的原代码拆分,使用其对文件进行分析。
|
||||||
|
(2)完成对文件MD5、SHA256、文件的段信息、是否经过壳加密等信息的获取与记录。
|
||||||
|
(3)完成了构建对应的数据库,并且对已获取到的信息进行记录与写入数据库。
|
||||||
|
(4)完成ELF文件在Windows平台下的跨平台分析记录。
|
||||||
|
(5)完成了识别程序的具体的等级划分,通过不同的维度对软件的等级进行划分。
|
||||||
|
研究内容
|
||||||
|
本技术总结报告主要介绍大规模复杂软件信息库的原始搭建与等级划分,详细相信如下:
|
||||||
|
2.1 信息库的搭建
|
||||||
|
2.1.1 软件基础信息介绍
|
||||||
|
对于软件信息,主要从是否有壳加密,软件类型,软件大小,软件的SHA256值,软件的MD5值,软件段信息等方面进行记录。
|
||||||
|
(1) 壳加密和内存保护
|
||||||
|
壳加密是一种用于保护软件安全的技术。在软件开发完成后,开发者可以使用壳程序来对软件进行加密和保护。壳程序是一种额外的程序层,可以将软件本身进行加密,使其难以被破解和逆向工程。在软件运行时,壳程序会解密软件本身,使其能够正常运行。
|
||||||
|
如表2.1,是常见的壳类型与几种典型的壳加密:
|
||||||
|
表 2.1 常见的壳类型与典型壳
|
||||||
|
壳类型
|
||||||
|
典型壳
|
||||||
|
压缩壳
|
||||||
|
Aspack, UPX, PeCompact
|
||||||
|
简单加密壳
|
||||||
|
Hying's pearmor 0.4x, Yoda's Cryptor & Protector
|
||||||
|
一般难度加密壳
|
||||||
|
Pelock, Telock, Svk Protector
|
||||||
|
中等复杂加密壳
|
||||||
|
Hying's Pearmor 0.7x
|
||||||
|
稍复杂加密壳
|
||||||
|
Acpr, Aspr, Armadillo(单进程), pespin 1.1, enigma Protecotr
|
||||||
|
双进程简单保护壳
|
||||||
|
pespin 1.3x, xikug's Protector, Ipb Protector
|
||||||
|
双进程cc保护壳
|
||||||
|
Armadillo, safedisc
|
||||||
|
注入型壳
|
||||||
|
safeguard, EncryptPE
|
||||||
|
驱动+VM壳
|
||||||
|
ProActive,Securom
|
||||||
|
强Anti + Vm壳
|
||||||
|
Themida新版
|
||||||
|
内存保护是一种软件安全机制,旨在保护计算机内存免受恶意软件或攻击者的破坏。内存保护技术可以通过一系列技术手段来防止缓冲区溢出、代码注入等攻击。常见的内存保护技术包括地址空间布局随机化(ASLR)、堆栈保护、数据执行保护(DEP)等。
|
||||||
|
如表2.2是常见的windows下的内存保护:
|
||||||
|
表 2.2 Windows的内存保护机制
|
||||||
|
|
||||||
|
内存保护
|
||||||
|
基本介绍
|
||||||
|
nx
|
||||||
|
No-eXecute,基本原理是将数据所在内存页标识为不可执行,当程序溢出成功转入shellcode时,程序会尝试在数据页面上执行指令,此时CPU就会抛出异常,而不是去执行恶意指令。
|
||||||
|
canary
|
||||||
|
栈保护功能,启用栈保护后,函数开始执行的时候会先往栈里插入cookie信息,当函数真正返回的时候会验证cookie信息是否合法,如果不合法就停止程序运行。
|
||||||
|
aslr
|
||||||
|
ASLR是一种针对缓冲区溢出的安全保护技术,借助ASLR技术,PE文件每次加载到内存的起始地址都会随机变化,并且每次运行程序时相应进程的栈以及堆的起始地址也会随机改变。
|
||||||
|
isolation
|
||||||
|
核心隔离与内存完整性,它们使用基于虚拟化的安全性来保护您的核心操作系统进程免遭篡改,但是默认情况下,升级人员的内存保护处于关闭状态。
|
||||||
|
如表2.3是常见的Linux下的内存保护:
|
||||||
|
表 2.3 Linux常见的内存保护机制
|
||||||
|
内存保护
|
||||||
|
基本介绍
|
||||||
|
canary
|
||||||
|
当启用栈保护后,函数开始执行的时候会先往栈里插入cookie信息,当函数真正返回的时候会验证cookie信息是否合法,如果不合法就停止程序运行。
|
||||||
|
nx
|
||||||
|
NX即No-eXecute(不可执行)的意思,NX的基本原理是将数据所在内存页标识为不可执行,当程序溢出成功转入shellcode时,程序会尝试在数据页面上执行指令,此时CPU就会抛出异常,而不是去执行恶意指令。NX和windows下的DEP原理相同。
|
||||||
|
pie
|
||||||
|
PIE(Position-Independent Executable, 位置无关可执行文件) 技术,在编译时将程序编译为位置无关,即程序运行时各个段加载的虚拟地址也是在装载时才确定。
|
||||||
|
fortify_source
|
||||||
|
适用于非常轻微的检查,用于检查是否存在缓冲区溢出的错误。适用情形是程序采用大量的字符串或者内存操作函数
|
||||||
|
壳加密和内存保护都是软件安全中的一部分,但是它们的应用场景和实现方式是不同的。壳加密主要应用于软件保护,以保护软件的知识产权和商业机密;而内存保护主要应用于防御恶意软件和攻击者的攻击,以保护计算机系统的安全。
|
||||||
|
(2) 软件类型和软件大小
|
||||||
|
软件类型主要分为PE文件与ELF文件,PE文件和ELF文件是两种不同的可执行文件格式,分别对应Windows和Linux操作系统。
|
||||||
|
PE文件(Portable Executable)是一种Windows操作系统下的可执行文件格式,用于存储Windows程序。它包含程序代码、资源、数据、符号表等信息。PE文件有两种类型,分别是PE32和PE64,它们的区别在于PE32使用32位的地址空间,而PE64使用64位的地址空间。PE文件有一个特殊的头部,包含了很多重要的信息,如程序入口点、代码段大小、数据段大小、可选头部等。PE文件也支持动态链接库(DLL)。
|
||||||
|
如图2.1为PE文件的文件结构所示。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
false
|
||||||
|
图 2.1 PE文件的文件结构
|
||||||
|
|
||||||
|
ELF文件(Executable and Linkable Format)是一种用于Linux和Unix操作系统的可执行文件格式。它与PE文件相似,包含程序代码、资源、数据、符号表等信息。ELF文件也有一个头部,其中包含了很多信息,如程序入口点、代码段大小、数据段大小、段表等。与PE文件不同的是,ELF文件也支持动态链接库,以便于共享代码和库文件,从而减少内存和磁盘空间的使用。此外,ELF文件还支持对可执行文件的动态重定位,以便于程序在不同的内存地址上运行。
|
||||||
|
如图2.2为ELF的文件结构。
|
||||||
|
false
|
||||||
|
图 2.2 ELF的文件结构
|
||||||
|
PE文件和ELF文件是不同操作系统下的可执行文件格式,都包含了程序代码、资源、数据、符号表等信息。它们的差别在于头部信息的不同以及支持的特性不同。
|
||||||
|
软件大小指的是软件文件占用的磁盘空间大小,通常以字节(Byte)为单位。软件大小是指软件代码、图像、音频、视频等各种文件所占用的存储空间的总和,因此软件大小的大小取决于软件本身的复杂度和功能。同时,软件大小是评估软件的重要指标,通常会影响到软件的运行效率和可靠性。
|
||||||
|
软件类型与软件大小这些信息可以通过查看软件的属性或者使用专门的软件工具来获取。
|
||||||
|
(3) SHA256和MD5
|
||||||
|
SHA-256和MD5都是哈希算法,用于将输入数据转换成固定长度的哈希值。哈希值通常用于验证数据的完整性和确定性,因为即使输入数据有微小的改动,哈希值也会发生很大的变化,从而可以检测到数据是否被篡改。
|
||||||
|
SHA-256是一种比MD5更安全的哈希算法。SHA-256使用更长的哈希值(256位),相对于MD5的128位哈希值,它提供了更高的安全性,因为它更难被攻击者破解。SHA-256是SHA-2哈希函数族的一部分,它比SHA-1更安全,因为SHA-1已经被证明存在漏洞。
|
||||||
|
如图2.3为SHA256的计算过程。
|
||||||
|
false
|
||||||
|
图 2.3 SHA256的计算过程
|
||||||
|
MD5是一种广泛使用的哈希算法,它可以快速生成哈希值。它使用128位哈希值,可以用于验证文件的完整性,因为即使文件被修改了一点,其哈希值也会发生很大的变化。尽管MD5易受到碰撞攻击,但它仍然被广泛用于文件完整性校验等方面。
|
||||||
|
如图2.4为MD5的计算过程。
|
||||||
|
false
|
||||||
|
图 2.4 MD5的计算过程
|
||||||
|
在实际的使用过程中,如果需要更高的安全性,应该选择SHA-256而不是MD5。但如果只需要一种快速、可靠的哈希算法来验证文件的完整性,MD5仍然是一个很好的选择。
|
||||||
|
(4) 段信息
|
||||||
|
可执行文件的段信息指的是可执行文件在内存中的布局,即可执行文件被加载到内存中时,如何被划分成不同的区域。在操作系统中,每个进程都会有一个自己的虚拟地址空间,用于存储该进程的代码、数据和堆栈等信息。可执行文件在被加载到内存中时,就会被映射到该进程的虚拟地址空间中,每个段就会对应着该空间中的一个区域,用于存储不同类型的数据。
|
||||||
|
在Windows操作系统中,可执行文件的段信息一般被存储在PE文件头中,其中包括以下几个主要段信息,如表2.4所示:
|
||||||
|
|
||||||
|
表 2.4 PE文件的主要段信息
|
||||||
|
|
||||||
|
常见代码段名称
|
||||||
|
主要功能
|
||||||
|
.text
|
||||||
|
该段用于存储代码。在可执行文件被加载到内存中时,该段被映射到进程的代码区域。
|
||||||
|
.data
|
||||||
|
该段用于存储全局变量和静态变量等数据。在可执行文件被加载到内存中时,该段被映射到进程的数据区域。
|
||||||
|
.rsrc
|
||||||
|
该段用于存储资源,如图标、位图、字符串等。在可执行文件被加载到内存中时,该段被映射到进程的资源区域。
|
||||||
|
.bss
|
||||||
|
该段用于存储未初始化的全局变量和静态变量等数据。在可执行文件被加载到内存中时,该段被映射到进程的数据区域。
|
||||||
|
在Linux操作系统中,可执行文件的段信息一般被存储在ELF文件头中,其中包括以下几个主要段信息,如表2.5所示:
|
||||||
|
|
||||||
|
表 2.5 ELF文件的主要段信息
|
||||||
|
常见代码段名称
|
||||||
|
主要功能
|
||||||
|
.data
|
||||||
|
该段用于存储全局变量和静态变量等数据。在可执行文件被加载到内存中时,该段被映射到进程的数据区域。
|
||||||
|
.rodata
|
||||||
|
该段用于存储只读数据,如常量字符串等。在可执行文件被加载到内存中时,该段被映射到进程的只读数据区域。
|
||||||
|
.bss
|
||||||
|
该段用于存储未初始化的全局变量和静态变量等数据。在可执行文件被加载到内存中时,该段被映射到进程的数据区域。
|
||||||
|
除了以上几个主要段信息,可执行文件还可能包括其他一些段信息,如debug段、符号表段等。这些段信息的具体含义和作用,可能会因不同的操作系统或编译器而有所不同。
|
||||||
|
2.1.2 搭建过程中的难点与解决方法
|
||||||
|
在搭建大规模复杂软件原始信息库时,可能会遇到一些难点,如表2.6所示:
|
||||||
|
|
||||||
|
|
||||||
|
表 2.6 搭建大规模数据库遇到的困难
|
||||||
|
遇到的困难
|
||||||
|
困难的原因
|
||||||
|
数据处理难度大
|
||||||
|
原始信息库需要对大量的数据进行处理和分析,包括文件大小、软件类型、段信息等。
|
||||||
|
数据存储难度大
|
||||||
|
大规模复杂软件原始信息库包含大量的数据,如何进行高效、安全、稳定的存储是一项重要的挑战。
|
||||||
|
数据安全性高要求
|
||||||
|
在原始信息库中,包含了大量的敏感信息,如软件的加密信息和哈希值。因此,数据的安全性是一个重要的难点,需要考虑如何保证数据的安全性和隐私性。
|
||||||
|
算法选择难度大
|
||||||
|
在对原始信息库进行分析和挖掘时,需要选择合适的算法和工具。不同的算法有不同的优缺点,选择合适的算法能够提高数据处理和分析的效率。
|
||||||
|
|
||||||
|
为了解决上述问题,可以采取以下方法:
|
||||||
|
(1)壳加密的问题:对已知文件的段信息进行加载,根据信息库对段信息进行对比,可知段是否被加密。
|
||||||
|
识别程序是否被壳加密过是一个比较复杂的过程,需要仔细的分析和研究。以下是一些常用的识别方法:文件大小:壳加密的文件通常会比未加密的文件要大。这是因为壳程序需要在文件中插入一些额外的代码和数据。因此,比较同一程序的加密前后的文件大小可以帮助识别程序是否被壳加密过。
|
||||||
|
可执行文件头:壳程序通常会在可执行文件头中进行修改,以便在程序运行时加载壳程序并执行。因此,比较同一程序的加密前后的可执行文件头信息可以帮助识别程序是否被壳加密过。
|
||||||
|
导入表和导出表:壳程序通常会修改可执行文件中的导入表和导出表,以便在程序运行时加载和执行加密的代码。因此,比较同一程序的加密前后的导入表和导出表信息可以帮助识别程序是否被壳加密过。
|
||||||
|
反汇编和调试:使用反汇编工具和调试器可以帮助识别程序是否被壳加密过。因为壳程序通常会在程序运行时解密和加载加密的代码,所以在反汇编和调试程序时可以观察程序的行为和代码,从而推断程序是否被壳加密过。
|
||||||
|
需要注意的是,有些壳程序会采取反调试和反反汇编等技术,使得识别壳加密变得更加困难。因此,识别壳加密需要结合多种方法和技术,进行深入的分析和研究。
|
||||||
|
(2)内存保护的问题:可以通过静态分析、动态分析与使用工具来对程序是否有内存保护进行识别:
|
||||||
|
静态分析:通过反汇编、反编译等静态分析技术,查看程序的代码中是否包含一些保护指令,如 DEP(数据执行保护)、ASLR(地址空间布局随机化)等。同时,也可以通过查看程序的导入表、导出表等信息,了解是否存在反调试、反病毒等保护措施。
|
||||||
|
动态分析:通过动态调试、动态注入等技术,监控程序的运行行为,了解是否存在内存保护。例如,可以通过尝试修改程序的代码、数据等,观察程序是否会崩溃或提示错误信息,从而推测程序是否存在内存保护措施。
|
||||||
|
使用工具:一些专门用于检测和绕过内存保护的工具,如 OllyDbg、Immunity Debugger、IDA Pro 等,可以帮助分析人员更快地发现和绕过内存保护。
|
||||||
|
需要注意的是,一些恶意软件会使用多种保护措施来保护自己,例如壳加密、加壳、虚拟机等,这些保护措施可能会使上述方法失效。因此,在实际应用中,需要结合多种技术手段,综合分析程序的行为,才能更准确地判断程序是否存在内存保护。
|
||||||
|
在本文中,由于需要大量对文件进行分析,故无法使用人工分析的方法,直能借助工具来实现内存检测任务的任务。
|
||||||
|
(1)软件类型和大小的问题:
|
||||||
|
通过查看软件的文件头信息,可以了解软件的类型、大小等相关信息。不过,有些软件可能会在文件头中进行伪装,因此需要进行深入的分析才能得到准确的结果。
|
||||||
|
(2)SHA256和MD5的问题:对被分析文件的MD5与SHA256两个值进行计算与记录,可以节省很多后续使用中计算资源,防止对文件的重复计算。
|
||||||
|
Python库文件hashlib中可以对文件的md5与sha256值进行计算,但在文件过长时,无法简单的完成任务,需要对整个计算过程进行封装才能得出最终结果。
|
||||||
|
(3)段信息的问题:
|
||||||
|
对于可执行文件的段信息进行整理和分析,可以更好的了解程序的结构和功能,有助于进行逆向工程和漏洞分析。
|
||||||
|
如图2.5是对可执行文件的段信息进行整理分析的一般步骤:
|
||||||
|
false
|
||||||
|
图 2.5 查看段信息的基础方法
|
||||||
|
如表2.7是对于各个步骤的具体步骤:
|
||||||
|
表 2.7 分析段信息的具体措施
|
||||||
|
分析操作
|
||||||
|
具体分析内容
|
||||||
|
使用工具打开可执行文件
|
||||||
|
使用二进制编辑器、反汇编器或专业的逆向工程工具打开可执行文件,以便查看和分析其段信息。
|
||||||
|
查看段表
|
||||||
|
在程序头部有一个段表(Section Header Table),记录了可执行文件中各个段的位置、大小、属性等信息。通过查看段表,可以了解可执行文件中各个段的名称、大小、属性等信息。
|
||||||
|
查看代码段
|
||||||
|
代码段(Code Section)包含了程序的指令和处理函数,是程序的核心部分。通过分析代码段,可以了解程序的算法、逻辑和实现细节。
|
||||||
|
查看数据段
|
||||||
|
数据段(Data Section)包含了程序中声明的全局变量、静态变量、常量等数据。通过分析数据段,可以了解程序中的数据结构、常量、字符串等信息。
|
||||||
|
查看堆栈段
|
||||||
|
堆栈段(Stack Section)是用来保存函数调用时的参数和返回地址,以及函数内部的局部变量和中间结果。通过分析堆栈段,可以了解程序的函数调用关系、参数传递方式、以及内存使用情况。
|
||||||
|
其他段信息
|
||||||
|
除了代码段、数据段和堆栈段,还有其他一些段信息,例如符号表、重定位表、调试信息等。这些信息可以帮助我们更好地理解程序的结构和功能。
|
||||||
|
分析程序特征
|
||||||
|
在了解了可执行文件的各个段信息后,可以分析程序的特征,例如程序的加密方式、防护措施、调用的库函数等。这些特征可以帮助我们判断程序的用途和安全性。
|
||||||
|
对可执行文件的段信息进行整理和分析需要具备一定的逆向工程和汇编语言基础,也需要借助一些专业工具和技巧。
|
||||||
|
2.1.3 搭建过程中的技术问题
|
||||||
|
以上问题为数据库建立前的需要考虑的结构问题,还有一些在信息库建立过程中的一些程序问题:
|
||||||
|
(1)程序的效率问题:
|
||||||
|
在大规模建库过程中,程序不能按单线程执行,多线程执行时必要的,但在实际的运行过程中,多线程的运行偶尔会造成系统的崩溃。
|
||||||
|
(2)后续的可扩展性问题:
|
||||||
|
对于软件的信息而言,后续可能会出现新的评判指标,不能只局限于当前的评判指标,但在加入新的评判指标时,需要考虑添加评判指标是否方便,软件的扩展能力是否足够强。
|
||||||
|
2.2 软件原始信息的等级评判
|
||||||
|
2.2.1 PE文件的评判标准
|
||||||
|
在PE文件中,对软件的分类从以下的四个方面进行:
|
||||||
|
(1) 文件的大小;
|
||||||
|
(2) 文件的加壳操作;
|
||||||
|
(3) 文件的段总数;
|
||||||
|
(4) 文件的内存保护
|
||||||
|
具体的评判标准如下图2.8所示:
|
||||||
|
表 2.8 PE文件的具体评判标准
|
||||||
|
评判标准
|
||||||
|
评判条件
|
||||||
|
满足条件
|
||||||
|
不满足条件
|
||||||
|
文件大小
|
||||||
|
>=10KB
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
文件的加壳操作
|
||||||
|
有加壳操作
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
文件的段总数
|
||||||
|
段总数>=3
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
文件的内存保护
|
||||||
|
0<保护数<=3
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
|
||||||
|
保护数>3
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
2.2.2 ELF文件的评判标准
|
||||||
|
在ELF文件中,其中的检测需要使用到Linux系统下的系统文件,故无法在Windows平台下对ELF作完整的评判,如果需要完整的评判,还需要在Linux平台下运行评判程序。
|
||||||
|
在ELF文件中,对软件的分类从以下的四个方面进行:
|
||||||
|
(1) 文件的大小
|
||||||
|
(2) 文件的段总数
|
||||||
|
(3) ELF文件的常用函数检查分数
|
||||||
|
(4) 文件的内存保护
|
||||||
|
具体的评判标准如下图2.9所示:
|
||||||
|
评判标准
|
||||||
|
评判条件
|
||||||
|
满足条件
|
||||||
|
不满足条件
|
||||||
|
文件大小
|
||||||
|
>=10KB
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
文件的常用函数检查分数
|
||||||
|
>10
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
文件的段总数
|
||||||
|
段总数>=3
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
文件的普通内存保护
|
||||||
|
保护数>1
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
Relro与PIE保护
|
||||||
|
保护数>1
|
||||||
|
加1
|
||||||
|
不加
|
||||||
|
表 2.9 ELF文件的具体评判标准
|
||||||
|
|
||||||
|
研究内容实现情况
|
||||||
|
课题组已完成所有上述研究内容,各任务研究内容完成情况及提供支撑材料见表3.1。
|
||||||
|
表 3.1 支撑材料表
|
||||||
|
研究内容
|
||||||
|
任务完成情况
|
||||||
|
提供材料
|
||||||
|
备注
|
||||||
|
研究内容1:分离Checksec开源项目
|
||||||
|
Checksec开源项目位于github上,源程序为基于Python的跨平台内存保护分析软件,将其中的主程序进行提取并进行集成。
|
||||||
|
Checksec提取代码一份
|
||||||
|
完成
|
||||||
|
研究内容2:对软件 的各个信息进行提取
|
||||||
|
完成对文件信息的提取,对于PE与ELF的文件来说,其文件的各种信息需要对文件进行具体分析,才能得到最终结果。
|
||||||
|
软件信息提取代码一份
|
||||||
|
完成
|
||||||
|
研究内容3:文件信息数据库搭建
|
||||||
|
完成对文件信息的数据库写入工作。文件的信息提取过后需要对文件的信息进行记录,需要数据库对文件的信息进行记录。
|
||||||
|
样本集一份,数据库记录表一份
|
||||||
|
完成
|
||||||
|
研究内容4:文件的等级划分
|
||||||
|
完成对文件的等级划分,根据文件的提取信息,对文件的具体信息进行个分析后,对文件的等级进行分类。
|
||||||
|
分类代码一份,数据库记录表异一份
|
||||||
|
完成
|
||||||
|
功能测试
|
||||||
|
为验证项目组提供的支撑材料可靠性,本文档提供了大规模复杂软件信息库的原始搭建与等级划分源代码测试流程及结果。
|
||||||
|
4.1 测试方法与步骤
|
||||||
|
将需要分类的数据集复制到项目文件夹下,在main.py脚本中,对信息进行初始化,包括数据集文件名,mysql数据库的host,用户名与密码,且在使用mysql数据库前,使用utils/sql文件夹下的database.sql文件对数据库进行初始化建库。数据初始化完成后运行脚本,脚本自动将文件的信息写入数据库中,并按等级将文件进行分类。脚本的信息初始化的如图4.1所示。
|
||||||
|
|
||||||
|
图 4.1 脚本数据初始化
|
||||||
|
4.2 测试过程
|
||||||
|
4.2.1 文件信息获取
|
||||||
|
通过项目utils文件夹下的各种文件信息获取的工具,获取到文件信息后,通过函数将其整合,再讲文件进行存储,最终输入到数据库中。具体代码如图4.2所示。
|
||||||
|
图 4.2 文件信息整合
|
||||||
|
4.2.2 数据库初始化设置
|
||||||
|
在对文件信息写入之前,需要对数据库进行初始化,才能进行使用,对于数据库的参数,从启动函数处进行获取,使用获得的参数对数据库进行初始化,另外,保证数据的数据写入的安全,对数据库的操作采用单例模式,具体操作如图4.3。
|
||||||
|
|
||||||
|
图 4.3 数据库的初始化操作
|
||||||
|
4.2.3 数据库的写入操作
|
||||||
|
将数据写入数据库,还需将写入结果显示出来,另外考虑到数据库的频繁写入操作对磁盘性能有较大需求,采用缓存队列的方式进行写入。本操作中,共含11460个PE文件与20个ELF文件。此处以PE文件作为参考,具体写入过程如图4.4所示。
|
||||||
|
|
||||||
|
图 4.4 将PE文件信息写入数据库
|
||||||
|
写入的结果如图4.5所示。
|
||||||
|
图 4.5 PE文件写入数据库结果
|
||||||
|
写入过程的信息参考如图4.6所示。
|
||||||
|
图 4.6 写入过程的信息
|
||||||
|
4.2.4 文件分级
|
||||||
|
利用获取到的文件信息,综合各个方面,对文件进行分级操作。以PE文件为例,具体的分级代码如图4.7所示。
|
||||||
|
图 4.7 PE文件分级
|
||||||
|
将文件的等级分好好存入数据库中,并根据具体的分级情况对文件进行样本划分,存入项目res文件夹下,具体分类如图4.8所示。
|
||||||
|
|
||||||
|
图 4.8 PE样本划分
|
||||||
|
4.3 测试结果
|
||||||
|
对于11460个PE文件与20个ELF文件共11480个文件进行信息获取与等级划分。具体测试结果如下表4.1所示:
|
||||||
|
表 4.1测试结果表
|
||||||
|
研究内容
|
||||||
|
测试结果
|
||||||
|
完成情况
|
||||||
|
PE文件分类
|
||||||
|
从11480个文件中分类出4个等级的PE文件,共11460个。
|
||||||
|
PE文件分类成功。
|
||||||
|
ELF文件分类
|
||||||
|
从11480个文件中分类出3个等级的ELF文件,共20个。
|
||||||
|
ELF文件分类成功。
|
||||||
|
数据库记录文件信息
|
||||||
|
共记录数据11480条数据,其中PE数据11460条,ELF数据20条。
|
||||||
|
数据库数据记录成功。
|
||||||
|
|
270
技术报告/技术总结报告模板_石磊.docx
Normal file
270
技术报告/技术总结报告模板_石磊.docx
Normal file
@ -0,0 +1,270 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
技术总结报告
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
服务名称:XXXXXX
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
目 录
|
||||||
|
技术总结报告 1
|
||||||
|
一、 研究目标实现情况 3
|
||||||
|
二、 研究内容 4
|
||||||
|
2.1 非可执行程序清洗 4
|
||||||
|
2.1.1 可执行程序 4
|
||||||
|
2.2.1 可执行文件判断原理 6
|
||||||
|
2.1.2 非可执行程序清洗技术实现 8
|
||||||
|
2.2 加壳程序分离 9
|
||||||
|
2.2.1 加壳程序 9
|
||||||
|
2.2.2 分离出加壳程序的必要性 10
|
||||||
|
2.2.3 加壳程序检测方法 11
|
||||||
|
2.2.4分离加壳技术实现 12
|
||||||
|
2.3 过大过小样本清洗 12
|
||||||
|
2.3.1 清洗过大过小样本必要性 12
|
||||||
|
2.3.2 过大过小样本分离技术实现 14
|
||||||
|
2.4 不可表征CFG样本清洗 15
|
||||||
|
2.4.1 CFG相关概念 15
|
||||||
|
2.4.2 清洗不可表征CFG样本的必要性 15
|
||||||
|
2.4.3 不可表征CFG样本清洗技术实现 16
|
||||||
|
2.5 重复样本清洗 17
|
||||||
|
2.5.1 清洗重复样本必要性 17
|
||||||
|
2.5.2 清洗重复样本的技术实现 17
|
||||||
|
三、 研究内容实现情况 19
|
||||||
|
四、 功能测试 21
|
||||||
|
4.1.1 测试方法及步骤 21
|
||||||
|
4.1.2测试过程及结果 22
|
||||||
|
4.1.3测试结论 28
|
||||||
|
|
||||||
|
|
||||||
|
一、 研究目标实现情况
|
||||||
|
依据课题研究任务,需收集大量可执行复杂软件作为基础数据集,然而网上公开的复杂软件数据集质量通常较低,混杂着大量无效复杂软件,因此需要研究大规模复杂软件无效样本清洗技术。
|
||||||
|
针对大规模复杂软件无效样本清洗技术,主要实现了以下6个子任务的研究:
|
||||||
|
(1)完成非可执行程序清洗任务,解决技术难点:识别出可执行文件如PE文件和ELF文件,对基础数据集中的非可执行文件(如pdf,txt,DLL,空文件夹)进行删除。
|
||||||
|
(2)完成对加壳程序分离任务,解决技术难点:在基础数据集中对可执行程序进行加壳检测。
|
||||||
|
(3)完成对过大或过小文件分离任务,解决技术难点:在基础数据集中筛选出不符合要求大小的样本文件。
|
||||||
|
(4)完成不可表征CFG样本分离任务,解决技术难点:在基础数据集中筛选出不可表征CFG的样本文件。
|
||||||
|
(5)完成重复样本分离任务,解决技术难点:在基础数据集中去识别重复的样本。
|
||||||
|
|
||||||
|
二、 研究内容
|
||||||
|
本技术总结报告主要介绍大规模复杂软件无效样本清洗技术完成情况及技术细节,具体原理及技术实现详细如下:
|
||||||
|
2.1 非可执行程序清洗
|
||||||
|
2.1.1 可执行程序
|
||||||
|
可执行文件指的是可以由操作系统进行加载执行的文件。Windows程序,脚本及宏均被视为可执行文件。在不同的操作系统环境下,可执行程序的呈现方式不一样,在windows系统中,可执行文件主要是PE文件结构。在linux系统中可执行文件格式主要是ELF格式。在Mac系统中PE(Portable Executable)文件结构。
|
||||||
|
PE文件是Windows下可执行文件的总称,常见的有.DLL,.EXE,.OCX,.SYS等。它是微软在UNIX平台的COFF(通用对象文件格式)基础上制作而成。最初设计用来提高程序在不同操作系统上的移植性,但实际上这种文件格式仅用在Windows系列操作系统下。PE文件是指32位可执行文件,也称为PE32。64位的可执行文件称为PE+或PE32+,是PE(PE32)的一种扩展形式。PE文件是Windows操作系统和Windows平台上所有软件和程序能够正常运行的重要基础。
|
||||||
|
PE文件的结构一般来说如图1所示:从起始位置开始依次是DOS头,NT头,节表以及具体的节。
|
||||||
|
PE文件结构说明如下:
|
||||||
|
DOS头:是用来兼容MS-DOS操作系统的,目的是当这个文件在MS-DOS上运行时提示一段文字,大部分情况下是:This program cannot be run in DOS mode。还有一个目的,就是指明NT头在文件中的位置。
|
||||||
|
NT头:包含windows PE文件的主要信息,其中包括一个PE字样的签名,PE文件头IMAGE_FILE_HEADER和PE可选头IMAGE_OPTIONAL_HEADER32。
|
||||||
|
节表:是PE文件后续节的描述,windows根据节表的描述加载每个节。
|
||||||
|
节:每个节实际上是一个容器,可以包含代码、数据等等,每个节可以有独立的内存权限,比如代码节默认有读/执行权限,节的名字和数量可以自己定义。
|
||||||
|
|
||||||
|
图 1 PE文件结构图
|
||||||
|
ELF文件是一种用于二进制文件、可执行文件、目标代码、共享库和core转存格式文件。是UNIX系统实验室作为应用程序二进制接口而开发和发布的,也是Linux的主要可执行文件格式。ELF文件格式如图2所示。
|
||||||
|
|
||||||
|
图 2 ELF文件格式
|
||||||
|
2.2.1 可执行文件判断原理
|
||||||
|
文件判断原理
|
||||||
|
PE是Windows操作系统上常见的一种二进制文件格式,用于存储可执行文件、动态链接库和驱动程序等程序文件。以下是PE文件的识别原理:
|
||||||
|
DOS头:PE文件的前64个字节是一个DOS头,其中包含了一个DOS的MZ头和一个指向PE头的偏移量。程序可以读取DOS头来确定该文件是否为PE文件,并获取指向PE头的偏移量。
|
||||||
|
PE头:PE头包含了文件的文件头、节表和导入表等信息。文件头中包括了文件类型、机器架构、程序入口地址、节表的数量和大小等信息,节表包含了各个节区的信息,导入表包含了需要在运行时动态链接的库函数等信息。程序可以读取PE头来确定文件中包含的各种信息。
|
||||||
|
节区:PE文件包含一个或多个节区,每个节区包含了特定类型的数据,例如代码、数据、符号表、重定位信息等等。程序可以读取节区来确定文件中包含的各种信息。
|
||||||
|
通常PE文件的判断依据:
|
||||||
|
(1)首先检验文件头部第一个字的值是否等于IMAGE_DOS_SIG-
|
||||||
|
NATURE,是则DOS MZ header有效。
|
||||||
|
证明文件的 DOS header 有效后,就可用e_lfanew来定位P
|
||||||
|
E header。
|
||||||
|
比较PE header的第一个字的值是否等于IMAGE_NT_HEAD-
|
||||||
|
ER如果前后两个值都匹配,那就认为该文件是一个有效的PE文件。
|
||||||
|
综上所述,识别PE文件的原理是通过读取DOS头和PE头等信息,来确定该文件是否为PE文件以及包含的各种信息。
|
||||||
|
2.2.1.2 ELF文件判断原理
|
||||||
|
识别ELF文件的原理:ELF是一种常见的二进制文件格式,用于存储可执行文件、共享库和目标文件等程序文件。以下是ELF文件的识别原理:
|
||||||
|
(1) 魔数:ELF文件的前4个字节是一个特定的魔数,它可以帮助程序确定该文件是否为ELF文件。在32位ELF文件中,魔数的值为0x7F, 'E', 'L', 'F',而在64位ELF文件中,魔数的值为0x7F, 'E', 'L', 'F', 2。
|
||||||
|
(2) 文件头:ELF文件的文件头包含了关于文件本身的信息,包括文件类型、机器架构、程序入口地址等等。程序可以读取文件头来确定该文件的类型和其他相关信息。
|
||||||
|
(3) 节区:ELF文件包含一个或多个节区,每个节区包含了特定类型的数据,例如代码、数据、符号表、重定位信息等等。程序可以读取节区来确定文件中包含的各种信息。
|
||||||
|
(4) 符号表:ELF文件中的符号表用于保存符号名称和符号地址等信息,用于在程序链接时解析符号引用。程序可以读取符号表来确定文件中包含的各种符号。
|
||||||
|
(5) 重定位表:ELF文件中的重定位表用于保存需要在程序加载时进行修正的地址信息,例如全局变量、函数等的地址。程序可以读取重定位表来确定需要进行哪些修正操作。
|
||||||
|
综上所述,识别ELF文件的原理是通过读取文件头、节区、符号表和重定位表等信息,来确定该文件的类型和包含的各种信息。
|
||||||
|
2.1.2 非可执行程序清洗技术实现
|
||||||
|
在大规模复杂软件样本中清理出非可执行程序无效样本的任务首先是判断改样本是不是可执行程序,需要从样本中识别出PE文件或者是ELF文件,对PE文件和ELF文件进行保留,将非可执行程序删除。
|
||||||
|
进行大规模复杂软件无效样本清洗技术对PE可执行程序的判断依据:使用Python的pefile模块。该模块提供了对PE文件的解析和分析功能,可以用来确定文件是否是PE文件。
|
||||||
|
PE可执行程序的判断具体实现:首先尝试使用pefile模块解析文件,如果解析成功,则认为文件是一个PE文件,返回True,否则返回False。如果文件不是PE文件,则pefile.PEFormatError异常将被引发,可以用它来判断文件类型是否为PE文件。
|
||||||
|
ELF可执行程序的判断具体实现:要判断一个文件是否为ELF文件,可以通过检查文件头信息来确定。在Linux和Unix系统中,ELF文件头的前几个字节包含了一个特定的魔数,可以通过检查这个魔数来判断一个文件是否为ELF文件。ELF文件的前4个字节是一个特定的魔数,它可以帮助程序确定该文件是否为ELF文件。在32位ELF文件中,魔数的值为0x7F, 'E', 'L', 'F',而在64位ELF文件中,魔数的值为0x7F, 'E', 'L', 'F', 2。
|
||||||
|
非可执行程序清洗流程:首先使用Python对大规模复杂软件目录中的样本进行依次遍历,遍历文件非常简单,核心函数是使用os.walk(folder)函数,folder就是想要搜索的文件夹的最顶层(大规模复杂软件目录)。对遍历的样本调用已经编写好的PE或ELF文件判断函数,同一个标记(PEflag或ELFflag)在标记该文件是否是可执行程序,若该程序是可执行程序则保留文件,若为非可执行程序则将该样本删除。具体流程如图3所示:
|
||||||
|
2.2 加壳程序分离
|
||||||
|
2.2.1 加壳程序
|
||||||
|
壳的概念:程序壳(也称为软件壳、应用程序壳、程序包装器等)是一种软件开发工具,用于包装一个程序,使其更难以被破解、修改或复制。通常,程序壳会将程序代码加密或压缩,并添加一些反破解技术,如代码混淆、虚拟机技术等,以提高程序的安全性。
|
||||||
|
壳的分类:
|
||||||
|
(1) 压缩加壳:注重减小软件体积大小,加密保护不是其重点。
|
||||||
|
(2) 加密加壳:重点加密保护。
|
||||||
|
(3) 伪装壳:扰乱检测。
|
||||||
|
|
||||||
|
|
||||||
|
图 3 PE,ELF文件清洗流程
|
||||||
|
(4) 多层壳:重点加密保护。
|
||||||
|
程序加壳:加壳是指将计算机程序文件进行加密和压缩,以使其在运行时难以被分析和修改,从而增加其安全性和保护性。通过加壳,程序文件会被加上一个额外的外壳,通常由专门的软件工具生成。这个额外的外壳包含了程序代码的解密和执行所需的信息,同时还可以包括一些反调试和反逆向技术,以防止对程序的分析和修改。加壳可以用于保护商业软件的知识产权,防止软件盗版和逆向工程攻击,也可以用于恶意软件的编写和传播。
|
||||||
|
2.2.2 分离出加壳程序的必要性
|
||||||
|
在样本中分离加壳程序是因为这些程序可能会干扰对样本进行分析的过程。
|
||||||
|
以下是一些原因:
|
||||||
|
(1) 加壳程序可能会使分析工具失效:许多分析工具只能处理未经加密或加壳的程序代码。如果样本中存在加壳程序,这些工具可能无法识别代码或数据,从而导致分析失败或产生错误的结果。
|
||||||
|
(2) 加壳程序可能会对分析造成噪声:加壳程序通常会添加许多不必要的代码或数据,或者改变程序的执行方式。这些额外的信息可能会对分析过程产生噪声或干扰,从而使结果失真。
|
||||||
|
(3) 加壳程序可能会包含恶意代码:一些加壳程序可能会包含恶意代码,如恶意软件或病毒。这些程序可能会危及分析者的计算机系统或数据。
|
||||||
|
因此,在分析样本之前,最好将加壳程序从样本中分离出来,并对未加密的代码进行分析。这可以确保分析过程的准确性和安全性,并使得分析者可以更好地理解程序的功能和行为。
|
||||||
|
2.2.3 加壳程序检测方法
|
||||||
|
Python实现加壳程序检测,但具体实现取决于加壳程序的类型和具体的检测策略。
|
||||||
|
一些常见的加壳程序检测策略包括:
|
||||||
|
(1) 静态分析:使用Python的反汇编库或者反编译工具来分析加壳程序的代码。这种方法可以检测加壳程序中的特征代码,例如壳代码、解壳代码、反调试代码等。
|
||||||
|
(2) 动态分析:使用Python的调试库或者动态分析工具来监视加壳程序的行为。这种方法可以检测加壳程序的运行行为,例如壳程序对内存的读写、解壳程序的加载和执行等。
|
||||||
|
(3) 特征匹配:使用Python的正则表达式库或者字符串匹配工具来查找加壳程序中的特征字符串。这种方法可以检测加壳程序中的特征字符串,例如壳程序的名称、版本号、厂商信息等。
|
||||||
|
2.2.4分离加壳技术实现
|
||||||
|
此研究内容使用特征匹配的方法来实现加壳程序的检测。具体来说,首先定义了几个加壳程序的特征,例如UPX、ASPack、Petite、FSG等,并将其保存在文本文件中。只有PE文件或者ELF文件才可以加壳,所以在进行加壳检测时,先检测样本文件是否为PE文件或ELF文件。进行加壳检测时,先读取出加壳文件的特征,然后,代码遍历PE文件的所有节,接着,代码判断特征是否存在于节的二进制内容中,如果存在,就可能被加壳或混淆了。对于被加壳或被混淆的文件将其清洗,留下未加壳或未被混淆的程序。加壳清洗的具体流程如图4所示。
|
||||||
|
2.3 过大过小样本清洗
|
||||||
|
2.3.1 清洗过大过小样本必要性
|
||||||
|
在进行软件开发和测试时,使用真实的软件样本对系统进行评估和测试是非常重要的。然而,有些软件样本可能太大或太小,不适合作为测试数据。以下是需要清洗过大过小的软件样本的原因:
|
||||||
|
(1) 资源消耗:过大的软件样本可能会占用过多的系统资源,导致测试效率下降甚至系统崩溃。过小的软件样本可能无法提供充分的测试覆盖率。
|
||||||
|
false
|
||||||
|
图 4加壳检测流程
|
||||||
|
(2)测试覆盖率:过大的软件样本可能包含大量冗余或不必要的代码,使得测试覆盖率降低,测试效果不佳。过小的软件样本可能无法覆盖所有测试场景,导致测试不够全面。
|
||||||
|
(3)安全性:过大的软件样本可能包含恶意代码,对测试系统造成威胁。过小的软件样本可能不足以检测出潜在的安全漏洞。
|
||||||
|
因此,清洗过大过小的软件样本可以提高测试效率和测试覆盖率,保障测试的安全性和准确性。
|
||||||
|
2.3.2 过大过小样本分离技术实现
|
||||||
|
首先使用Python对大规模复杂软件目录中的样本进行依次遍历,遍历文件非常简单,核心函数是使用 os.walk(folder) 函数,folder就是想要搜索的文件夹的最顶层(大规模复杂软件目录)。对遍历的文件调用os.stat()函数获取文件基本信息,获取st_size属性获取文件大小,将遍历的文件大小与所需要保留的文件大小上下限值进行比较,将不符合要求的文件剔除。具体流程如图5所示。
|
||||||
|
|
||||||
|
图 5过大过小样本清洗流程图
|
||||||
|
2.4 不可表征CFG样本清洗
|
||||||
|
2.4.1 CFG相关概念
|
||||||
|
可执行程序的CFG(Control Flow Graph,控制流程图)是一个有向图,用于描述程序控制流程,即程序中各个指令之间的执行顺序和跳转关系。在CFG中,每个节点代表程序的一个基本块,基本块是一个连续的指令序列,其中只有第一个指令可以通过条件或无条件跳转到其他基本块。基本块之间的边表示控制流程的转移关系,即从一个基本块到另一个基本块的跳转。
|
||||||
|
可执行程序的CFG可以通过多种方式构建,比如静态分析、动态分析和混合分析等。其中,静态分析是最常用的方法之一,它通常通过反汇编器将程序二进制代码转换为汇编代码,然后将汇编代码转换为 CFG。构建好的CFG可以用于程序分析、漏洞挖掘、代码优化等多个方面。
|
||||||
|
通过CFG,可以对程序的控制流程进行可视化和分析,识别程序中的潜在漏洞和错误,以及进行代码重构和优化等。在反恶意软件分析和漏洞挖掘等领域,可执行程序的CFG是非常重要的分析工具。
|
||||||
|
2.4.2 清洗不可表征CFG样本的必要性
|
||||||
|
清洗不可表征CFG样本的必要性主要是为了确保从样本中提取的CFG能够准确地反映程序的控制流程,避免对后续分析和应用产生误导。不可表征CFG指的是那些无法正常构建或构建出来的CFG,如存在无法解析的二进制指令、缺失重要信息、被加密或混淆的代码等。这些CFG不能提供准确的控制流程信息,因此在分析和应用过程中可能会产生误导。
|
||||||
|
清洗不可表征CFG样本的方法主要包括以下几个方面:
|
||||||
|
(1) 去除存在无法解析的二进制指令的样本,避免这些指令对CFG的构建造成干扰。
|
||||||
|
(2) 对缺失重要信息的样本进行补全或修复,确保CFG能够完整地反映程序的控制流程。
|
||||||
|
(3) 对加密或混淆的代码进行解密或反混淆,以便正确地构建CFG。
|
||||||
|
通过清洗不可表征CFG样本,可以获得准确的CFG,并能够更好地应用于后续的程序分析、漏洞挖掘、代码优化等工作中,提高分析结果的准确性和可信度。
|
||||||
|
2.4.3 不可表征CFG样本清洗技术实现
|
||||||
|
Angr是一个二进制分析工具包,可以用来分析和处理二进制程序。对于无法表征CFG的样本,可以使用Angr进行清洗。angr中的CFG分为2种:CFGFast和CFGAccurate。两者的区别在于前者计算的东西更少,从而也就更快。一般情况下CFGFast就够了,但在研究中若要依靠CFG进一步分析的话可能就需要CFGAccurate了,更精准当然也就更慢,需在两者间加以权衡。考虑到样本规模非常大,为了对大规模复杂软件无效样本清洗节约更多的时间,因此使用CFGFast完成对样本文件的CFG提取。
|
||||||
|
不可表征CFG样本清洗技术过程,首先判断样本文件是否是PE或者是ELF文件,因为只有PE或者ELF文件才可以表征成CFG,对非PE或者非ELF文件进行清洗。然后PE文件或对ELF文件进行是否可以表征成CFG判断,对不可表征成CFG的样本进行清洗。
|
||||||
|
2.5 重复样本清洗
|
||||||
|
2.5.1 清洗重复样本必要性
|
||||||
|
清洗重复的软件样本是信息安全和计算机安全领域中的一个重要步骤,具有以下几个原因:
|
||||||
|
(1) 节省存储空间:在处理大量软件样本时,可能会存在许多相同或类似的样本。如果不去重,则会浪费大量的存储空间,增加存储成本。
|
||||||
|
(2) 提高分析效率:在对软件样本进行分析时,重复的样本可能会影响分析效率。删除重复的样本可以减少分析的工作量,并使分析结果更加准确和可靠。
|
||||||
|
(3) 避免误报:在进行恶意软件检测时,重复的样本可能会导致误报,即将正常软件误判为恶意软件。清洗重复的样本可以降低误报率,提高检测的准确性。
|
||||||
|
(4) 避免安全风险:重复的软件样本可能存在漏洞和安全风险,如果不及时清理,则可能会给系统带来潜在的安全隐患。清洗重复的样本可以降低系统受到攻击的风险。
|
||||||
|
因此,清洗重复的软件样本是信息安全和计算机安全领域中一项重要的工作,可以帮助保障系统的安全和稳定。
|
||||||
|
2.5.2 清洗重复样本的技术实现
|
||||||
|
首先定义了一个find_duplicate_files函数,它接受一个文件夹路径作为输入,并返回一个包含所有重复文件路径列表的列表。在该函数中,使用了hashlib.md5函数计算文件的哈希值,并将哈希值与文件路径相关联,将哈希值作为字典的键,文件路径列表作为值。最后,返回其中包含两个或更多文件路径的文件路径列表。
|
||||||
|
然后定义了remove_duplicate_files函数,它接受一个文件夹路径作为输入,并使用find_duplicate_files函数查找所有重复文件,然后删除这些文件中的副本。在该函数中,我们遍历每个重复文件的路径列表,并保留第一个文件,删除所有其他文件。
|
||||||
|
|
||||||
|
三、 研究内容实现情况
|
||||||
|
课题组已完成所有上述研究内容,各任务研究内容完成情况及提供支撑材料见表1。
|
||||||
|
表 1支撑材料表
|
||||||
|
研究内容
|
||||||
|
任务完成情况
|
||||||
|
提供材料
|
||||||
|
备注
|
||||||
|
研究内容1:非可执行程序清洗
|
||||||
|
完成非可执行程序清洗工作,从11538个恶意样本中清洗出51个非可执行程序。对于PE文件使用pefile对样本集结构信息进行解析,判断magic属性,判断PE文件。对于ELF文件,前4个字节是一个特定的魔数,将其与ELF文件的魔数进行对比,判断ELF文件。对非PE文件或非ELF文件剔除出样本集。
|
||||||
|
非可执行程序清洗源代码一份、样本集一份
|
||||||
|
完成
|
||||||
|
研究内容2:加壳程序清洗
|
||||||
|
完成加壳程序分离工作,从11474个恶意样本中分离出623个加壳样本。搜集常见的壳加密段名信息保存为壳加密段字典。使用xxx解析工具提取目标样本。
|
||||||
|
加壳程序分离源代码一份、样本集一份
|
||||||
|
完成
|
||||||
|
研究内容3:过大或过小样本文件清洗
|
||||||
|
完成对过大或过小样本文件清洗任务,从11505个恶意样本中分离出超过所设置阈值的最大文件大小,或低于最小样本大小的样本。
|
||||||
|
过大过小样本分离源代码一份、样本集一份
|
||||||
|
完成
|
||||||
|
研究内容4:不可表征CFG样本清洗
|
||||||
|
完成对不可表征CFG的样本文件清洗,从352个恶意样本中分离不可表征CFG的样本文件,使用angr二进制分析工具完成对样本文件的CFG提取,对不可提取CFG的样本文件进行清洗。
|
||||||
|
不可表征CFG样本分离源代码一份、样本集一份
|
||||||
|
完成
|
||||||
|
研究内容5:重复样本清洗
|
||||||
|
完成对大规模复杂软件样本中重复样本的清洗,从11484个恶意样本中分离25个重复样本,并进行清洗。使用hashlib.md5 函数计算文件的哈希值,并将哈希值与文件路径相关联,将哈希值作为字典的键,文件路径列表作为值,删除重复文件。
|
||||||
|
重复样本分离源代码一份、样本集一份
|
||||||
|
完成
|
||||||
|
四、 功能测试
|
||||||
|
为验证项目组提供的支撑材料可靠性,本文档提供了大规模复杂软件无效样本清洗技术源代码测试流程及结果。
|
||||||
|
4.1 测试方法及步骤
|
||||||
|
运行de_PE.py脚本对非可执行程序样本文件进行清洗。非可执行程序样本清洗脚本使用如图6所示。
|
||||||
|
|
||||||
|
图 6非可执行程序样本清洗脚本使用
|
||||||
|
运行de_shell.py脚本对加壳样本文件进行清洗。加壳样本清洗脚本使用如图7所示。
|
||||||
|
|
||||||
|
图 7加壳样本清洗脚本使用
|
||||||
|
运行de_oversize.py脚本对过大过小样本文件进行清洗。过大过小样本清洗脚本使用如图8所示。
|
||||||
|
|
||||||
|
图 8过大过小样本清洗脚本使用
|
||||||
|
运行de_cfg.py脚本对不可表征CFG的样本文件进行清洗。对不可表征CFG样本文件清清洗脚本使用如图9所示。
|
||||||
|
|
||||||
|
图 9不可表征CFG样本文件清清洗脚本使用
|
||||||
|
运行de_repeatSample.py脚本对重复的样本文件进行清洗。重复文件清洗脚本使用如图10所示。
|
||||||
|
|
||||||
|
图 10重复文件清洗脚本使用
|
||||||
|
4.2 测试过程及结果
|
||||||
|
非可执行程序样本文件清洗方法:首先准备好含11474个样本文件的基础样本数据集,该样本集包含32个ELF文件,10个pdf文件,15个空文件夹,15个txt文件。运行de_PE.py脚本对基础样本数据集进行清洗。样本清洗分离结果如图11,12所示。
|
||||||
|
|
||||||
|
图 11非可执行程序清洗结果
|
||||||
|
|
||||||
|
图 12非可执行程序样本分离
|
||||||
|
加壳样本文件清洗:首先准备好含11474个样本文件的基础样本数据集,该样本集包含623个加壳文件样本。运行de_shell.py脚本对基础样本数据集进行清洗。样本清洗分离结果如图13,14所示。
|
||||||
|
|
||||||
|
图 13加壳样本清洗结果
|
||||||
|
|
||||||
|
图 14加壳样本分离
|
||||||
|
非过大过小样本文件清洗方法:首先准备好含11505个样本文件的基础样本数据集。运行de_oversize.py脚本对基础样本数据集进行清洗。样本清洗分离结果如图15,16所示。
|
||||||
|
|
||||||
|
图 15过大过小样本清洗
|
||||||
|
|
||||||
|
|
||||||
|
图 16过大过小样本文件分离
|
||||||
|
非不可表征CFG样本文件清洗方法:首先准备好含352个样本文件的基础样本数据集,该样本集包含295个PE文件,32个ELF文件,10个pdf文件,15个txt文件。运行de_cfg.py脚本对基础样本数据集进行清洗。样本清洗分离结果如图17,18所示。
|
||||||
|
|
||||||
|
图 17不可表征CFG样本清洗结果
|
||||||
|
|
||||||
|
图 18不可表征CFG样本分离
|
||||||
|
重复样本文件清洗测试方法:首先准备好含11484个样本文件的基础样本数据集,该样本集包含25个重复样本。运行de_repeatSample.py脚本对基础样本数据集进行清洗。样本清洗分离结果如图19,20所示。
|
||||||
|
样本清洗结果如图所示:
|
||||||
|
|
||||||
|
图 19重复样本文件清洗
|
||||||
|
分离重复样本文件如图所示:
|
||||||
|
|
||||||
|
图 20重复样本文件分离
|
||||||
|
4.3 测试结论
|
||||||
|
对项目进行严格测试后,分析测试结果。本项目总体评估结果见表2:
|
||||||
|
表 2测试结果表
|
||||||
|
研究内容
|
||||||
|
测试结果
|
||||||
|
完成情况
|
||||||
|
非可执行程序清洗
|
||||||
|
从11538个基础样本数据集中分离51个非可执行样本文件,并进行成功清洗。
|
||||||
|
非可执行样本文件分离成功。
|
||||||
|
加壳程序清洗
|
||||||
|
从11474个基础样本数据集中分离623个加壳样本文件,并进行成功清洗。
|
||||||
|
加壳样本文件分离成功。
|
||||||
|
过大或过小样本文件清洗
|
||||||
|
从11505个基础样本数据集中分离194个过大过小样本文件,并进行成功清洗。
|
||||||
|
过大过小样本文件分离成功。
|
||||||
|
不可表征CFG样本清洗
|
||||||
|
从352个基础样本数据集中分离33个不可表征CFG样本文件,并进行成功清洗。
|
||||||
|
不可表征CFG样本文件分离成功。
|
||||||
|
重复样本清洗
|
||||||
|
从11484个基础样本数据集中分离25个重复样本文件,并进行成功清洗。
|
||||||
|
重复样本文件分离成功。
|
||||||
|
|
689
技术报告/测试文档2.0.docx
Normal file
689
技术报告/测试文档2.0.docx
Normal file
@ -0,0 +1,689 @@
|
|||||||
|
目 录
|
||||||
|
一、简介 2
|
||||||
|
1.1 编写目的 2
|
||||||
|
1.2 项目背景 2
|
||||||
|
1.3测试简介 2
|
||||||
|
二、测试概要 2
|
||||||
|
2.1 测试环境 2
|
||||||
|
2.1.1 硬件环境 2
|
||||||
|
2.1.2 软件环境 2
|
||||||
|
2.1.3 测试环境拓扑图 2
|
||||||
|
2.2 测试内容 3
|
||||||
|
2.2.1 测试样本 3
|
||||||
|
2.2.2 变异策略 4
|
||||||
|
2.3 主要任务指标和测试过程 5
|
||||||
|
2.3.1主要任务指标 5
|
||||||
|
2.3.2实现变异策略种类及数量 5
|
||||||
|
2.3.3测试过程 6
|
||||||
|
三、结果分析 15
|
||||||
|
四、检测结论 17
|
||||||
|
五、检测人员 17
|
||||||
|
|
||||||
|
|
||||||
|
一、简介
|
||||||
|
1.1 编写目的
|
||||||
|
本测试报告,为xxxxxxx项目的节点测试报告。本文档用于记录测试过程,系统是否符合xxxxxxx的相关需求,总结测试情况,分析测试数据,归纳测试结果。
|
||||||
|
1.2 项目背景
|
||||||
|
本项目为xxxxxxx,项目的主要目的是探索和研究xxxxxxx,为xxxxxxx提供技术保障,从而提高xxxxxxx。
|
||||||
|
1.3测试简介
|
||||||
|
本项目第一阶段研究的理论与技术指标要求如下:
|
||||||
|
实现变异策略种类不少于10种,变异策略所覆盖的目标文件类型包含PE文件(Portable Executable,Windows下可执行文件)、ELF文件(Executabe and Linnking,Linux下可执行文件)。基于变异策略对原始恶意软件进行变异,生成的样本可以保持原始功能。
|
||||||
|
二、测试概要
|
||||||
|
2.1 测试环境
|
||||||
|
2.1.1 硬件环境
|
||||||
|
本项目课题所研制的xxxxxxxxxx研究与设计的测试需要终端1台,用于提供测试环境的构建、代码调试和测试用例调试。测试终端的推荐硬件配置与规格描述见表1:
|
||||||
|
表1 测试设备的硬件环境
|
||||||
|
序号
|
||||||
|
设备名称
|
||||||
|
数量/台
|
||||||
|
用途
|
||||||
|
硬件规格
|
||||||
|
1
|
||||||
|
测试终端
|
||||||
|
1
|
||||||
|
测试环境构建、代码调试
|
||||||
|
台式电脑*1,数据存储U盘不少于10G。
|
||||||
|
2.1.2 软件环境
|
||||||
|
测试终端的推荐软件配置与运行环境描述见表2:
|
||||||
|
表2 测试设备的软件环境
|
||||||
|
序号
|
||||||
|
设备名称
|
||||||
|
软件配置与执行环境
|
||||||
|
备注
|
||||||
|
1
|
||||||
|
测试终端
|
||||||
|
Ubuntu18.04/Windows 10, Anaconda, python, torch等主要环境
|
||||||
|
根据工具的具体需要有所增减
|
||||||
|
2.1.3 测试环境拓扑图
|
||||||
|
"xxxxxxxxxx"测试环境拓扑图如图1所示,包含实验数据U盘、台式电脑硬件接口、操作系统、Python运行环境、数据载入与项目运行、指标对比这六个部分。
|
||||||
|
false
|
||||||
|
图1 测试环境拓扑图
|
||||||
|
2.2 测试内容
|
||||||
|
本次测试主要针对xxxx项目合同书中的第一阶段任务指标进行测试。
|
||||||
|
2.2.1 测试样本
|
||||||
|
本次测试所用样本信息如表3所示:
|
||||||
|
表3 测试样本表
|
||||||
|
序号
|
||||||
|
名称
|
||||||
|
恶意功能
|
||||||
|
适用平台
|
||||||
|
1
|
||||||
|
黑人抬棺病毒
|
||||||
|
删除系统配置文件,导致系统崩溃。
|
||||||
|
Windows
|
||||||
|
2
|
||||||
|
王境泽病毒
|
||||||
|
删除系统配置文件,导致系统崩溃。
|
||||||
|
Windows
|
||||||
|
3
|
||||||
|
永恒之绿
|
||||||
|
勒索软件,用户无法关闭软件进行其他操作。
|
||||||
|
Windows
|
||||||
|
4
|
||||||
|
Windows XP Horror
|
||||||
|
删除原始系统,安装病毒系统,使得用户原始系统中的信息全部丢失。
|
||||||
|
Windows
|
||||||
|
5
|
||||||
|
BluescreenSimulator
|
||||||
|
引发电脑蓝屏。
|
||||||
|
Windows
|
||||||
|
6
|
||||||
|
卢本伟病毒
|
||||||
|
删除系统配置文件,导致系统崩溃。
|
||||||
|
Windows
|
||||||
|
7
|
||||||
|
MEMZ-Clean
|
||||||
|
使系统出现花屏、图标错误等问题。
|
||||||
|
Windows
|
||||||
|
8
|
||||||
|
Virus.out
|
||||||
|
感染同文件夹下的elf文件,使其section读取异常。
|
||||||
|
Linux
|
||||||
|
9
|
||||||
|
荒野行动盒子
|
||||||
|
游戏外挂。
|
||||||
|
Android
|
||||||
|
10
|
||||||
|
叉叉酷跑助手
|
||||||
|
游戏外挂。
|
||||||
|
Android
|
||||||
|
11
|
||||||
|
刺激战场超强辅助
|
||||||
|
游戏外挂。
|
||||||
|
Android
|
||||||
|
12
|
||||||
|
叉叉节奏大师助手
|
||||||
|
游戏外挂。
|
||||||
|
Android
|
||||||
|
13
|
||||||
|
Inject
|
||||||
|
将冗余代码注入到正常文件中。
|
||||||
|
ELF
|
||||||
|
2.2.2 变异策略
|
||||||
|
本次测试所用变异策略信息如表4所示:
|
||||||
|
表4 变异策略表
|
||||||
|
序号
|
||||||
|
名称
|
||||||
|
描述
|
||||||
|
适用类型
|
||||||
|
1
|
||||||
|
指定段追加
|
||||||
|
在文件末尾添加新的随机段。
|
||||||
|
PE
|
||||||
|
2
|
||||||
|
指定外部调用追加
|
||||||
|
在导入表中添加随机外部调用函数。
|
||||||
|
PE
|
||||||
|
3
|
||||||
|
删除调试信息
|
||||||
|
删除文件的调试信息。
|
||||||
|
PE
|
||||||
|
4
|
||||||
|
破坏校验和
|
||||||
|
可选头中校验和设置为0。
|
||||||
|
PE
|
||||||
|
5
|
||||||
|
修改时间戳
|
||||||
|
可选头中时间戳将被更改为随机值。
|
||||||
|
PE
|
||||||
|
6
|
||||||
|
末尾字节追加
|
||||||
|
在文件的末尾追加若干随机或良性字节。
|
||||||
|
PE、ELF
|
||||||
|
7
|
||||||
|
文件空隙填充
|
||||||
|
在文件内部空白位置添加随机字节。
|
||||||
|
PE
|
||||||
|
8
|
||||||
|
段重命名
|
||||||
|
重命名文件中的段。
|
||||||
|
PE、ELF
|
||||||
|
9
|
||||||
|
插入花指令
|
||||||
|
在文件中添加花指令代码。
|
||||||
|
PE
|
||||||
|
10
|
||||||
|
指定活函数插入
|
||||||
|
在文件执行路径中添加可执行函数。
|
||||||
|
PE
|
||||||
|
11
|
||||||
|
压缩壳加壳
|
||||||
|
使用UPX壳对文件进行加密。
|
||||||
|
PE
|
||||||
|
12
|
||||||
|
加密壳加壳
|
||||||
|
使用VMP壳对文件进行加密。
|
||||||
|
PE
|
||||||
|
13
|
||||||
|
重新排列
|
||||||
|
重新排列AndroidManifest.xml中的条目,而不修改XML树结构。
|
||||||
|
APK
|
||||||
|
14
|
||||||
|
APK调用添加
|
||||||
|
添加了调用原始方法的新方法。
|
||||||
|
APK
|
||||||
|
15
|
||||||
|
方法重命名
|
||||||
|
重新对方法进行命名。
|
||||||
|
APK
|
||||||
|
16
|
||||||
|
字段重命名
|
||||||
|
重新对变量进行命名。
|
||||||
|
APK
|
||||||
|
17
|
||||||
|
插入垃圾代码
|
||||||
|
插入随机垃圾指令。
|
||||||
|
APK
|
||||||
|
18
|
||||||
|
插入跳转
|
||||||
|
在一个方法末尾加入GOTO指令,在第一个goto指令后插入另一个指向该指令的goto指令。
|
||||||
|
APK
|
||||||
|
19
|
||||||
|
算术分支
|
||||||
|
向代码中添加一些无用的和语义保留的指令。
|
||||||
|
APK
|
||||||
|
20
|
||||||
|
方法重载
|
||||||
|
给定一个已经存在的方法,创建一个具有相同名称和参数的新void方法,但它也添加了新的随机参数。
|
||||||
|
APK
|
||||||
|
21
|
||||||
|
LLVM代码混淆
|
||||||
|
将文件代码转换为一种中间表示,对中间表示进行混淆,再转换为原始语言。
|
||||||
|
ELF
|
||||||
|
|
||||||
|
2.3 主要任务指标和测试过程
|
||||||
|
2.3.1主要任务指标
|
||||||
|
本项目第一阶段主要实现以下两个指标任务:
|
||||||
|
(1)实现变异策略种类不少于10种。各类型变异策略变异目标不同、优势不同,协同多种类变异策略,可提高组合与对抗策略的训练效果,实现策略涵盖以下四个主要类别:
|
||||||
|
①直接修改类:段追加类、外部调用追加类、属性修改类、良性数据填充类、字节填充类等;
|
||||||
|
②代码微创类:活函数插入类、花指令类等;
|
||||||
|
③代码全翻译类;
|
||||||
|
④壳加密类:压缩壳类、加密壳类等。
|
||||||
|
(2)可变异复杂对抗性软件种类覆盖PE ( Portable Executable,Windows下可执行文件)、ELF (Executabe and Linnking, Linux下可执行文件)等多种类型。
|
||||||
|
2.3.2实现变异策略种类及数量
|
||||||
|
该阶段实现变异策略种类16种,共实现21个变异策略。实现种类与策略对应关系如下:
|
||||||
|
(1)Windows变异策略:
|
||||||
|
直接修改类:
|
||||||
|
①段追加类:指定段追加;
|
||||||
|
②外部调用追加类:指定外部调用追加;
|
||||||
|
③属性修改类:删除调试信息, 破坏校验和, 修改时间戳,段重命名;
|
||||||
|
④良性数据填充类:文件空隙填充;
|
||||||
|
⑤字节填充类:末尾字节追加;
|
||||||
|
代码微创类:
|
||||||
|
①活函数插入类:指定活函数插入;
|
||||||
|
②花指令类:花指令插入;
|
||||||
|
壳加密类:
|
||||||
|
①压缩壳类:压缩壳加壳;
|
||||||
|
②加密壳类:加密壳加壳。
|
||||||
|
(2)Linux变异策略:
|
||||||
|
字节填充类:末尾字节追加;
|
||||||
|
属性修改类:段重命名;
|
||||||
|
代码全翻译类:LLVM代码混淆;
|
||||||
|
(3)Andriod变异策略:
|
||||||
|
属性修改类:方法重命名,字段重命名;
|
||||||
|
外部调用追加类:APK调用添加;
|
||||||
|
活代码插入类:插入随机垃圾指令,插入跳转,算术分支,方法重载;
|
||||||
|
2.3.3测试过程
|
||||||
|
本次测试过程涉及PE文件测试、Andriod文件测试、FLE文件测试、活代码插入测试、LLVM全翻译测试、加壳测试的过程。
|
||||||
|
(1)PE文件测试过程:
|
||||||
|
打开测试demo,选择样本文件作为待修改样本,如图2所示。
|
||||||
|
|
||||||
|
图2 样本的选择过程
|
||||||
|
在参数设置中选择一个良性文件,再从良性文件中选择其中一个段作为待追加段,点击开始添加按钮执行指定段追加变异策略,点击下载按钮下载文件,如图3所示。
|
||||||
|
|
||||||
|
图3 指定段追加变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,在参数设置中选择一个良性文件,再从良性样本中选择一个良性lib,点击开始攻击执行外部调用追加变异策略,将指定外部调用添加至待修改文件中,点击下载按钮下载文件,如图4所示。
|
||||||
|
|
||||||
|
图4 指定外部调用追加变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,点击开始攻击按钮执行删除调试信息变异策略,点击下载按钮下载文件,如图5所示。
|
||||||
|
|
||||||
|
|
||||||
|
图5 删除调试信息变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,点击开始攻击按钮执行破坏校验和变异策略,点击下载按钮下载文件,如图6所示。
|
||||||
|
|
||||||
|
图6 破坏校验和变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,点击开始攻击按钮执行修改时间戳变异策略,点击下载按钮下载文件,如图7所示。
|
||||||
|
|
||||||
|
图7 修改时间戳变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,在参数设置中输入添加的字节数量、执行次数、ascii码上限,点击开始攻击按钮执行末尾字节追加变异策略,点击下载按钮下载文件,如图8所示。
|
||||||
|
|
||||||
|
图8 末尾字节追加变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,在参数设置中选择一个良性样本,再从良性样本中选择一个段,之后从待修改文件中选择一个段后空隙,点击开始攻击按钮执行文件空隙填充变异策略,将从良性样本中选择的段添加到选择的段后空隙中,点击下载按钮下载文件,如图9所示。
|
||||||
|
|
||||||
|
图9 文件空隙填充变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,在参数设置页面中,从待修改文件中选择一个段并输入修改后的段名,点击开始攻击按钮执行段重命名变异策略,点击下载按钮下载文件,如图10所示。
|
||||||
|
|
||||||
|
图10 段重命名变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,在参数设置页面中,输入新插入段的名称并选择插入段中装载的花指令,点击开始攻击按钮执行插入花指令变异策略,点击下载按钮下载文件,如图11所示。
|
||||||
|
|
||||||
|
图11 插入花指令
|
||||||
|
将生成的文件移动到虚拟机中,拍摄虚拟机快照,依次执行修改后的文件,每次执行都通过快照回溯到执行前的环境中,恶意软件能正常运行,如图12所示。
|
||||||
|
|
||||||
|
图12 PE恶意软件运行
|
||||||
|
其他PE文件测试与上述测试过程相同。
|
||||||
|
(2)ELF文件测试过程:
|
||||||
|
打开测试demo,选择样本文件作为待修改样本,如图13所示。
|
||||||
|
|
||||||
|
图13 选择样本
|
||||||
|
在参数设置中输入添加的字节数量、执行次数、ascii码上限,点击开始攻击按钮执行末尾字节追加变异策略,点击下载按钮下载文件,如图14所示。
|
||||||
|
|
||||||
|
图14 末尾字节追加变异策略
|
||||||
|
点击重置按钮使文件回到原始状态,在参数设置页面中,从待修改文件中选择一个段并输入修改后的段名,点击开始攻击按钮执行段重命名变异策略,点击下载按钮下载文件,如图15所示。
|
||||||
|
|
||||||
|
图15 段重命名变异策略
|
||||||
|
将生成的文件移动到虚拟机中,拍摄虚拟机快照,依次执行修改后的文件,每次执行都通过快照回溯到执行前的环境中,恶意软件能正常运行,如图16所示。
|
||||||
|
|
||||||
|
图16 ELF恶意软件运行
|
||||||
|
(3)Android文件测试过程:
|
||||||
|
首先调用apktool对原始apk文件进行反编译,反编译后的文件如图17所示,得到AndroidManifest.xml\resource文件\assets文件\so文件等等信息,对smali文件调用正则表达式匹配得到方法\变量\类等等信息。
|
||||||
|
|
||||||
|
图17 apk文件反编译
|
||||||
|
然后对APK需要进行的混淆指定参数;其中,-o RandomManifest为方法重命名;-o Nop是在smali代码中添加nop指令;-o Goto是在方法的开头加上goto跳转到方法的最后一行,然后在方法的最后一行加上goto跳转回来;-o MethodRename是对方法重命名,-o FieldRename重新对变量进行命名;-o CallIndirection修改了控制流图,添加了调用原始方法的新方法;-o MethodOverload利用Java编程语言的重载特性将相同的名称分配给不同的方法,使用不同的参数;-o ArithmeticBranch向代码中添加一些无用的和语义保留的指令。
|
||||||
|
|
||||||
|
图18 对apk文件进行混淆
|
||||||
|
将生成的文件移动到模拟器中执行,恶意软件能正常运行如图19所示。
|
||||||
|
|
||||||
|
图19 安卓恶意软件正常运行
|
||||||
|
(4)LLVM全翻译测试过程:
|
||||||
|
首先,使用GCC编译器和LLVM编译器分别对该恶意代码进行编译,分别编译成main1和main2文件,如图20所示。
|
||||||
|
|
||||||
|
图20 全翻译扰动过程
|
||||||
|
再对main1和main2分别进行逆向反汇编,使用GCC编译器编译的程序流程图如图21所示,使用LLVM混淆编译器编译的程序流程图如22所示,可以发现同一个代码编译出的程序流程图有很大的差异。
|
||||||
|
|
||||||
|
图21 gcc编译的恶意文件程序流程图
|
||||||
|
|
||||||
|
图22 LLVM编译器编译的恶意文件程序流程图
|
||||||
|
测试main1、main2的对elf文件注入功能,注入目标为编译的helloworld输出elf文件,main1、main2对helloworld文件注入后文件大小发生变化且均可正常运行,表示main1、main2的功能可以正常实现,测试如图23所示。
|
||||||
|
|
||||||
|
图23 恶意样本功能正常执行
|
||||||
|
(5)活函数插入测试过程:
|
||||||
|
打开random_modify_insert_point.py文件,只需修改981行的待修改文件路径即可对文件进行活函数插入,如图24所示。
|
||||||
|
|
||||||
|
图24 活函数插入过程
|
||||||
|
(6)加壳测试过程:
|
||||||
|
打开加密壳加壳.py文件或压缩壳加壳.py文件并运行,只需输入待加壳文件的路径,即可对文件进行加壳,如图25所示。
|
||||||
|
|
||||||
|
图25 加壳过程
|
||||||
|
三、结果分析
|
||||||
|
本次测试的结果如表5所示,其中表示对应编号的恶意软件样本应用了对应的变异策略且能保证变异后样本恶意功能的完整性,表示对应编号的恶意软件样本应用了对应的变异策略但变异后样本的恶意功能完整性受到破坏,表示所选样本类型与变异策略不适配,或因为某种原因无法采用该变异策略。
|
||||||
|
表5 测试结果
|
||||||
|
|
||||||
|
|
||||||
|
变异策略
|
||||||
|
样本编号
|
||||||
|
1
|
||||||
|
2
|
||||||
|
3
|
||||||
|
4
|
||||||
|
5
|
||||||
|
6
|
||||||
|
7
|
||||||
|
8
|
||||||
|
9
|
||||||
|
10
|
||||||
|
11
|
||||||
|
12
|
||||||
|
13
|
||||||
|
段追加
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
外部调用追加
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
删除调试信息
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
破坏校验和
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
修改时间戳
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
末尾字节追加
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
文件空隙填充
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
段重命名
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
插入花指令
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
活函数插入
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
压缩壳加壳
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
加密壳加壳
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
重新排列
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
添加调用
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
方法重命名
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
字段重命名
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
插入垃圾代码
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
插入跳转
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
算术分支
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
方法重载
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
全翻译
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
5号样本不适配活函数插入变异策略:缺少插入点;
|
||||||
|
5号样本不适配压缩壳加壳、加密壳加壳:指令集不兼容
|
||||||
|
四、检测结论
|
||||||
|
对项目进行严格测试后,分析测试结果。本项目总体评估结果见表6:
|
||||||
|
表6 项目总体评估结果
|
||||||
|
合同要求指标
|
||||||
|
测试结果
|
||||||
|
符合情况
|
||||||
|
备注
|
||||||
|
实现变异策略种类不少于10种。各类型变异策略变异目标不同、优势不同,协同多种类变异策略,可提高组合与对抗策略的训练效果,实现策略涵盖以下四个主要类别:
|
||||||
|
(1)直接修改类:段追加类、外部调用追加类、属性修改类、良性数据填充类、字节填充类等;
|
||||||
|
(2)代码微创类:活函数插入类、花指令类等;
|
||||||
|
(3)代码全翻译类;
|
||||||
|
(4)壳加密类:压缩壳类、加密壳类等。
|
||||||
|
|
||||||
|
实现变异策略种类16种,共实现22个变异策略,实现策略种类与数量超过指标1中"实现变异策略种类不少于10种"的描述,符合预期。实现种类为涵盖指标1中所列出的策略类型,符合预期。
|
||||||
|
详细实现如下:
|
||||||
|
Windows变异策略:
|
||||||
|
段追加类、外部调用追加类、属性修改类、良性数据填充类、字节填充类、活函数插入类、花指令类、压缩壳类、加密壳类。
|
||||||
|
Linux变异策略:
|
||||||
|
字节填充类、属性修改类、代码全翻译类。
|
||||||
|
Andriod变异策略:
|
||||||
|
重组类、属性修改类、外部调用追加类、活代码插入类。
|
||||||
|
符合
|
||||||
|
达成
|
||||||
|
任务指标
|
||||||
|
可变异复杂对抗性软件种类覆盖PE ( Portable Executable,Windows下可执行文件)、ELF (Executabe and Linnking, Linux下可执行文件)等多种类型。
|
||||||
|
可变异的对抗性软件种类有PE、ELF、Android,覆盖指标中的类别。
|
||||||
|
符合
|
||||||
|
达成
|
||||||
|
任务指标
|
||||||
|
五、检测人员
|
||||||
|
表7 测试人员表
|
||||||
|
序号
|
||||||
|
角色
|
||||||
|
姓名
|
||||||
|
1
|
||||||
|
|
||||||
|
|
||||||
|
2
|
||||||
|
|
||||||
|
|
||||||
|
3
|
||||||
|
|
||||||
|
|
||||||
|
4
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user