外的题果然考得与众不同

[secrypt_cen.html]

这次是HTML网页，然后JS加密判断

翻看JS代码

{width="5.75in" height="3.375in"}

很显然，关键的代码在checkPassword

JS混淆是必备的

去混淆一条龙走起

先将关键代码提取出来

  JavaScript
  function _0x4857(_0x398c7a, _0x2b4590) { const _0x104914 =
  _0x25ec(); _0x4857 = function (_0x22f014, _0x212d58) { _0x22f014 =
  _0x22f014 - (0x347 + 0x46a * -0x7 + 0x1cc6); let _0x321373 =
  _0x104914[_0x22f014]; return _0x321373; }; return
  _0x4857(_0x398c7a, _0x2b4590); } (function (_0x414f9c, _0x3d4799)
  {
  //...................省略大量代码
  } function safe_add(a, b) { var c = (65535 & a) + (65535 & b); return
  (a >> 16) + (b >> 16) + (c >> 16) << 16 | 65535 & c } function

  bit_rol(a, b) { return a << b | a >>> 32 - b }

使用在线的javascript去混淆即可

deobfuscate.relative.im

得到去混淆后的结果

  function checkPassword(_0x38d32a) {
  try {
  if (_0x38d32a.length !== 21) {
  return false
  }
  if (
  //......省略大量代码
  return [c, d, j, k]
  }
  function md5_cmn(a, b, c, d, e, f) {
  return safe_add(bit_rol(safe_add(safe_add(b, a), safe_add(d, f)), e),
  c)
  }
  function md5_ff(a, b, c, d, e, f, g) {
  return md5_cmn((b & c) | (~b & d), a, b, e, f, g)
  }
  function md5_gg(a, b, c, d, e, f, g) {
  return md5_cmn((b & d) | (c & ~d), a, b, e, f, g)
  }
  function md5_hh(a, b, c, d, e, f, g) {
  return md5_cmn(b ^ c ^ d, a, b, e, f, g)
  }
  function md5_ii(a, b, c, d, e, f, g) {
  return md5_cmn(c ^ (b | ~d), a, b, e, f, g)
  }
  function safe_add(a, b) {
  var c = (65535 & a) + (65535 & b)
  return (((a >> 16) + (b >> 16) + (c >> 16)) << 16) | (65535 &
  c)
  }
  function bit_rol(a, b) {
  return (a << b) | (a >>> (32 - b))

  }

flag长度21

发现了MD5加密，和两个MD5字符串

看起来无关联？

后来审计整个代码发现，对输入的flag分部分进行判断比较

写出对应的部分，在控制台console输出相关信息是一个不错的选择

  function checkPassword(_0x38d32a) {
  try {
  // Password length is 21.
  if (_0x38d32a.length !== 21) {
  return false;
  }
  if (
  _0x38d32a.slice(1, 2) !==
  (String.fromCodePoint + "")[
  parseInt((parseInt + "").charCodeAt(3), 16) - 147
  ] /* password[1] = 'o' */ ||
  _0x38d32a[(parseInt(41, 6) >> 2) - 2] !==
  String.fromCodePoint(123) /* password[4] = '{' */ ||
  _0x38d32a[4].charCodeAt(0) !==
  _0x38d32a[7].charCodeAt(0) + 72 /* password[7] = '3'. */ ||
  JSON.stringify(
  Array.from(
  _0x38d32a.slice(5, 7).split("").reverse().join(),
  (_0x2d4d73) => _0x2d4d73.codePointAt(0)
  ).map((_0x5b85c5) => _0x5b85c5 + 213)
  ) !==
  JSON.stringify([
  285, 257, 297,
  ]) /* password[5] = 'T', password[6] = 'H' password[7] =
  '3'*/
  ) {
  return false;
  }
  /* For password[8], password[9], password[10], password[11]
  */
  let _0x3c7a5c = _0x38d32a.slice(8, 12).split("").reverse();
  
  try {
  for (let _0x396662 = 0; _0x396662 < 5; _0x396662++) {
  _0x3c7a5c[_0x396662] =
  _0x3c7a5c[_0x396662].charCodeAt(0) + _0x396662 +
  getAdder(_0x396662);
  }
  } catch (_0x1fbd51) {
  _0x3c7a5c = _0x3c7a5c.map(
  (_0x24cda7) => (_0x24cda7 += _0x1fbd51.constructor.name.length -
  4)
  );
  }
  
  if (
  MD5(String.fromCodePoint(..._0x3c7a5c)) !==
  "098f6bcd4621d373cade4e832627b4f6" /* password[8] = '0',
  password[9] = 'R', password[10] = '3', password[11] = 'M'
  */
  ) {
  return false;
  }
  
  if (
  MD5(_0x38d32a.charCodeAt(12) + "") !==
  "812b4ba287f5ee0bc9d43bbf5bbe87fb" /* password[12] = '_' */
  ) {
  return false;
  }
  _0x3c7a5c = (_0x38d32a[8] + _0x38d32a[11]).split("");
  _0x3c7a5c.push(_0x3c7a5c.shift());
  if (
  _0x38d32a.substring(14, 16) !==
  String.fromCodePoint(
  ..._0x3c7a5c.map((_0x5b5ec8) =>
  Number.isNaN(+_0x5b5ec8) ? _0x5b5ec8.charCodeAt(0) + 5 : 48
  )
  ) /* password[14] = 'R' password[15] = '0' */ ||
  _0x38d32a[_0x38d32a[7] - _0x38d32a[10]] !==
  atob("dQ==") /* password[0] = 'u' */ ||
  _0x38d32a.indexOf(String.fromCharCode(117)) !==
  _0x38d32a[7] - _0x38d32a[17] /* password[17] = '3' */ ||
  JSON.stringify(
  _0x38d32a
  .slice(2, 4)
  .split("")
  .map(
  (_0x7bf0a6) =>
  _0x7bf0a6.charCodeAt(0) ^
  getAdder.name[_0x38d32a[7]].charCodeAt(0)
  )
  ) !==
  JSON.stringify(
  [72, 90].map(
  (_0x40ab0d) =>
  _0x40ab0d ^
  String.fromCodePoint.name[_0x38d32a[17] - 1].charCodeAt(0)
  )
  ) /* password[2] = 'f', password[3] = 't' */
  ) {
  return false;
  }
  if (
  String.fromCodePoint(
  ..._0x38d32a
  .split("")
  .filter(
  (_0x5edfac, _0x2965d2) => _0x2965d2 > 15 && _0x2965d2 % 2 == 0
  )
  .map(
  (_0x2ffa6d) =>
  _0x2ffa6d.charCodeAt(0) ^ (_0x38d32a.length + _0x38d32a[7])
  )
  ) !==
  atob(
  "g5Go"
  ) /* password[16] = 'V', password[18] = 'D', password[20] =
  '}' */
  ) {
  return false;
  }
  if (
  _0x38d32a[_0x38d32a.length - 2] !==
  String.fromCharCode(Math.floor((({} + "").charCodeAt(0) + 9) / 3))
  ||
  _0x38d32a[1 + _0x38d32a[7]] !== giggity()[5] /* password[19]
  = ! */
  ) {
  return false;
  }
  return true;
  } catch (_0x4d4983) {
  return false;
  }
  }
  function getAdder(_0x430c9d) {
  switch (_0x430c9d) {
  case 0:
  return 34;
  case 1:
  return 44;
  case 2:
  return 26;
  case 3:
  return 60;
  }
  return 101;
  }
  function giggity() {
  return giggity.caller.name;

  }

得到flag

uoft{TH30R3M_PR0V3D!}

http://jsnice.org/

述

安卓APK中的混淆

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

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

混淆对Android安全的影响

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

一种基于文本分类的软件包混淆检测方法

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

背景

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

• 标识符重命名：0.92
• 字符串加密：0.79
• 控制流混淆：0.67

AndrODet在Android环境中的局限性

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

基于APK的计算和特征弱化

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

无法处理Unicode编码

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

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

我们的方法

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

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

方法说明

第1步：反编译和Smali提取

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

第2步：创建训练集

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

第3步：文本分类神经网络训练

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

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

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

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

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

第4步：训练

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

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

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

限制和未来方向

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

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

结论

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

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

from https://www.freebuf.com/articles/mobile/370247.html