通过文本分类检测中的代码混淆

混淆是软件开发中常用的技术，用于使代码更难理解、分析和逆向工程。它将代码转化为一种复杂而纷繁的形式，同时保留其功能。混淆的主要目标是阻碍对代码的未经授权访问，保护软件的知识产权或者隐藏软件的真实行为。

在AndroidAPK中，常用多种混淆技术来保护代码，使其更难理解或逆向工程。其中一种技术是代码混淆，它将源代码转换为等效但更复杂的形式，使其难以解读和分析。另一种常用的技术是字符串加密，在这种技术中，敏感字符串（如API密钥或URL）被加密，以防止轻易提取。此外，还采用控制流混淆来干扰代码的逻辑流程，使其难以跟踪程序的执行路径和理解其功能。

混淆技术的使用增加了安全研究分析的难度，并使一些基于签名的检测方法失效。字符串加密使得追踪关键信息变得具有挑战性。这些措施使得恶意软件更难以识别和追踪。

出于这些原因，我们的公司——Liansecurity开发了一款名为"Incinerator"的产品，旨在提供高效、准确和自动化的逆向工程服务。通过对恶意软件的广泛分析和先前混淆检测技术的研究，在我们的AndroidAPK逆向工程产品“焚化炉"中实现了一种基于文本分类的混淆检测方法。根据我们的测试，我们的方法实现了98%的准确率，这超出了我们的期望。在接下来的章节中，我们将详细描述我们的方法。

在检测Android应用程序中的混淆技术方面，最先进的系统是"AndrODet"。在这项工作中，作者构建了一个混淆检测系统，针对每种混淆类型提取不同的特征，然后训练一个在线机器学习模型。下面列出了目标混淆类型和AndrODet实现后的测试结果：

标识符重命名：0.92

字符串加密：0.79

控制流混淆：0.67

在Android的背景下，AndrODet面临某些限制，影响其作为静态代码分析工具的准确性和有效性。主要集中在两个方面：

AndrODet计算其度量指标是基于整个APK，包括核心业务代码和关联的库文件。在Android生态系统中，依赖库可能会非常庞大，有时甚至比核心业务代码本身还要大。而且大多数情况下，依赖库并不需要进行混淆。当仅依靠整个APK进行计算时，这些大型未混淆的库的存在削弱了混淆部分的重要性，最终影响了AndrODet进行正确判断的准确性。

AndrODet计算距离的方法局限于ASCII编码。然而，使用Unicode编码进行混淆技术的使用越来越普遍。因此，AndrODet无法处理和分析使用Unicode编码进行混淆的代码。这个限制阻碍了该工具在真实生产场景中准确检测和评估混淆代码的安全性和质量方面的能力。

AndrODet的限制对其在真实生产场景中的准确性构成了挑战。了解这些限制及其对真实生产环境的影响对于寻求改进Android应用程序安全领域代码分析工具能力的研究人员和从业者至关重要。

我们的方法主要解决了代码混淆技术中最常见的标识符重命名的识别问题，这是恶意软件常用的混淆技术。我们的方法也可以扩展到字符串加密。在我们的研究中，我们观察到，当研究人员评估一个代码片段是否被混淆时，他们最初的判断依赖于类名、方法名和变量名的可理解性，以及可识别和常用的编码约定，即所谓的“编码英语”，与类似'a'、'Zb'、'c4'、'1li'、'0Oo'等不容易理解的名称进行对比。最初，我们尝试了算法方法来解决这个问题，但测试结果不怎么理想。然而，我们突然想到，这实际上是一个经典的自然语言（NLP）分类问题。

凭借这一灵感，我们将混淆检测问题转化为文本分类问题，而深度神经网络处理文本分类，已经非常成熟。我们的测试结果也证明了这种转换非常成功。“字符串加密”本质上也是一个文本分类问题，因此我们相信这种方法可以轻松扩展到字符串加密。

第1步涉及反编译AndroidAPK和提取Smali代码。在我们的实现中，我们使用我们自己的反编译引擎"Reactor”。其他开源工具，如AndroGuard或Apktools也可以。从每个类中，我们提取类名和类变量名，这些是下一步分析的输入。理论上可以提取更多特征，如函数参数名称和局部变量，但提取更多的特征对准确率没有太大的提升，因为前面的三个特征已经达到了很高的准确性。

创建两个不同的训练集。第1个训练集是混淆的类生成的数据，标记为1。第2个训练集是未混淆的类生成的数据，标记为0。

我们构建了一个文本分类神经网络。该神经网络使用步骤1中提取的特征和步骤2中的相应标签进行训练。通过利用深度学习网络模型进行训练。

该模型分成3层：嵌入层、LSTM层和密集层。

1）嵌入层：嵌入层将输入整数序列转换为密集矢量表示。

2）LSTM层：LSTM（长短期记忆）层是一种能够处理序列数据和捕获长期依赖关系的循环神经网络（RNN）。在该模型中，使用了具有128个单元的LSTM层。

3）Dense层：Dense层是一个全连接层，对LSTM层的输出进行线性变换并应用sigmoid激活函数。

我们从1000个数据样本开始，发现结果已经非常不错。随着我们将样本量增加到10000，准确率和验证准确率都变得非常令人满意。最终，我们的模型使用100000个数据样本进行了训练。我们试图进一步扩充数据集，但准确率和验证准确率没有提高。为了避免由单个APK生成的数据引起的偏差，我们从数据库中随机提取了几百个APK来生成我们的数据。从生成的数百万个数据样本中，我们随机选择了100000个进行训练。

训练结果如下：

训练准确率：99.75%

验证准确率：98.50%

在实际应用中，为了确定一个APK是否被混淆，我们使用了一种方法，该方法涉及检查APK内的每个类是否进行混淆。通过将混淆类的数量除以类的总数，我们可以计算APK中混淆代码的比例。尽管在理论，针对每个类，判断可能出现假阳或者假阴，但是在判断一个APK是否存在现象时，很难出错，因为一个被混淆的APK，需要确保它的大部分代码很难理解，这正是混淆的目的和最终呈现，大部分难以理解的类，是不能逃过模型的检测的。因此，我们的模型在确定APK中是否存在混淆时达到了接近100%的准确率。

第一轮训练后，我们从Fdroid和Abuse各获取了1000个APK，进行验证测试。FDroid代表良性apk，abuse代表恶意apks，测试后，我们发现有较高概率出现假阳，一些非常短的内部类，例如”Class:MainActivityExternalSyntheticLambda15;Method:initrunField:f$0f$1f$2“这样的情况，模型无法判断是否是混淆。为了解决这个问题，我们从假阳的apk中，抽取了3000条数据样本，加入训练集合。重新训练，再次训练后，极大的降低了假阳。

下面是我们抽取随机的100个测试样本，因为我们的模型校验准确率是98.5%，所以测试结果中，混淆覆盖率1%，2%这样的情况，应该判断为没有混淆。剩下结果中的4%(md5:8328cd96c931d06d25f67d42a50fd20d)这个是误报，分析原因是因为这个apk的类非常少，三条假阳数据导致了这个错误。其他的5%(923df6854199e999fdd274729b28a1ad)，7%(71e293f29e636112e0a00ebac8cf3eb8)都是真实存在的混淆。所以这个模型，判断混淆的准确率接近100%，而且APK中存在非常少量的混淆也是可以检测出来。

我们的训练集中并没有出现unicode的混淆样本，但是在测试的时候，这种情况也会被识别为混淆，因为模型对非混淆的文本有非常好的识别，所以即便出现样本中没有出现的其他混淆情况，也可以识别。

APK

APKMd5

ObfuscationCoverage

11c43f6d781457352e5e61e725998ea8

0%

8bbc3d9173e6d6b19e561a8651e83731

0%

8328cd96c931d06d25f67d42a50fd20d

4%

86f763c8cf4530e1c46c75d26374855a

99%

08cf9be157669f3e0f7dd88975fdc22c

1%

cf2f9963933457dcdd1f28fec054cd07

56%

c1ade85027c6178e43daac2e957ba9b1

96%

79ce98b9d38490625ad15f5948afe32f

0%

dc84f225fdb1c21071ee70d43af39224

50%

a394d3131303bd24bdcddc7e0a507f0d

1%

1d28e138a9ecf1c9b3240868879bbd54

10%

49619da57858ffdd6bd55bb5b962efe3

1%

c7dd9b418933ceea723527487bd94268

1%

cf1d9aa2d5eec5a8e0af76d9708a8da0

0%

e272df5c9abd7d4c03982bb506922428

15%

cd4acd78cf29adf56837e944c0ea3791

50%

0e728b50b101456d74329f97552ea2db

94%

782216c3d9db96da2ef0285daddbdcdb

0%

ee83d9a3c3fcffbd833f1b73d28d28cd

2%

8e5e7cc0e581fac6c5d83802dadc0095

98%

c31ca58e67d55bb20a06e0f986cf04c1

92%

22556b8c3b0f4196b0db777d64cac5ee

1%

a827ee829d6067eda9c19f1dee15b9af

1%

c0786ccbcfe7cb57f82f36a66040d452

1%

ef3c97b748088019dc986dce53ae0755

1%

b11e72c94d810958df65d8716d853bc3

46%

c9eeb111666c723e3a4f78e2e11ab10d

1%

376fc34c1eb64a348311156b1f22763e

45%

923df6854199e999fdd274729b28a1ad

5%

dc9f73c8ec88a8b493a15a3cbcb36f15

33%

dcb35395a9a3fa0aea0bd9c876c4fadc

1%

7ec247424733c287c3322fc49f1a7766

33%

4076db4387eb8ddf8f2010e3db8c8b07

59%

bb78d33aac9b1c0c741b9e66d1ad9710

96%

5f1d4d542004efd946a40a26166aed00

1%

3c0cccf2790ba49a122d0235225dbceb

26%

768ec2246d2c92330ba8fafe6513963e

5%

2f1570b5b5723d3f4ddd615905e8c08f

27%

1e5d955dabdd0ee548054c8cdc223653

1%

cb3726beeb870d96e2dd458da66af96b

97%

0be11a3a032b35e2ce8021d32780cf32

21%

6129cc4392d2e10ffdb80db67ca2534b

24%

2f03d669939c74b508a3959838fbba4c

94%

f25da1334e4db5d6c14c2361ba4defa8

1%

9849247aef1aa1ae82c4dc06a638f29d

1%

a3f79b347a1c06140697326acb04581a

1%

a6dcb00ee7482256f8070b2d2eb23f62

2%

d36cd1850f8dfec7298c08e8eed3f997

1%

d4054bf60b2fbcfc152b32397cb861b0

97%

a32c36009a37893be90e4f385b26b5ee

35%

_

42501430e5b199df00f0068b3bd59db4

92%

fec9d39eb80814e1eec29e52e0fede2d

50%

d0cf7f183b84ff040f237da0d7e89c58

90%

35923a4197bcd2efd8d22a167af3f028

1%

55774d1c8251ee3c12ce08af65000bd7

16%

85d0288b9b04c7d71bfd8185a916490b

1%

23e49cc28a5feeed4b9e362aa43e158a

65%

95d33595783ede50bd428a18823ca0a9

20%

_

0a3fa3b09980e629c6a983a2c33d0400

1%

be9d61e3363c3399b55a44895fd1cf60

47%

f140ec3c051717491aac1a477c0f453a

44%

9b1de8718bb348e74ecde66dfa7332a8

19%

c3c6f8ba040f1715d32ac7563d7d9b0c

33%

d79144a6e4aad73e78bc25af25e8f8d1

1%

7c1e243288ff30b602976d2ce634b0f3

0%

93a79a8f1b2ad1eb2b670782e571107d

1%

b1e0ad60b4113ecfdf74e930848dcab4

21%

702d0800421413f73f0f3d65a577986e

1%

d0118fe80f1af4cf2fad4579fa7f8741

1%

21ce417bd40a12c2333ab505a0095891

1%

52a5b10ae074459fbbeb1a0e8c297eac

1%

c4c0982149feaf5266d6b2a9c4634858

84%

7bff47951d893d50b7bf1bb151225006

1%

d7ffbdf8e491f0c3e53901cf830f10b2

9%

d59b366ab1870d17f9abdd4824461327

0%

1fd53adfc1ff5f6262567592dfc88fd4

70%

f0c84c3ffcc77a88ce344e7f632afb2d

67%

6e05b674fb8725a4f1faae9d39be1b94

14%

8b2df68517574eb0c7d1b42858403695

1%

889e1c52bdebe6e1ae952bcc38b5daf1

11%

b48f43a3c6b7c4ef07b7f87b62f64d61

1%

013a0f9ddc9db42f06ae2cd1b6228c8f

31%

f724e92bdf978fb3bbdac308d4ba800c

73%

6320c822ba4ce417ffb82746dbf6f6f8

27%

69d3cd2ef0e619193f145c89b22ce920

1%

29bf40b35ce52d6e44c61304fdd8561a

1%

71e293f29e636112e0a00ebac8cf3eb8

7%

f6e5f704bf5910b4d0aff44df2a77a8b

91%

1d51ef04566cc66661358f7708c0a9d3

1%

e9133a533614dafee5780d50b29484c3

91%

f942cf3de1107400be084ddd596016d9

1%

72dfae851b1c93838094fe3b059ac5b1

1%

87118a9b63adebe8ad642509ff76818b

16%

7041af61162329c4e2022d82939a2d2d

1%

8755ffdd6fe155593af77536bc8d1da1

1%

956659e2df6362a79e110fac0fda3534

65%

aa2099699b3c8b68aa33925899ad9e84

96%

4987ea46c3679a191434c1546231bade

1%

37f9a2a3e4c906bf2cc3c14895620b1e

1%

742aebc4c88564678e78276dbf29e935

1%

本文讨论的都是针对标识符重命名的混淆检测，相同的办法可以应用到字符串检测上。但是不能应用到控制流混淆检测。AndrODet的结果在这方面的表现也不尽如人意。未来我们会针对控制流检测专门设计新的模型。

与AndrODet相比，我们的模型需要相对更多的时间来确定APK是否被混淆，因为它需要单独检测每个类。虽然可以批量检测，但APK可能包含数千甚至数万个类。然而，在生产环境中，这是可以接受的，因为分析APK涉及静态分析、动态分析等各个方面，需要更长的时间来执行。因此，在我们的产品中，混淆检测的等待时间是合理的。此外，这个时间也可以通过并行架构处理来缓解。

我们提出了一种基于文本分类的方法来检测APK是否被混淆。这种方法以前在现有研究中没有应用过，可以扩展到其他软件中的混淆检测以及字符串加密检测。此外，我们建议APK中混淆的检测应该在类级别进行，因为这样可以达到基本100%的准确率。

我们已经在正式生产环境中实现了这种方法。