外的題果然考得與眾不同

[secrypt_cen.html]

這次是HTML網(wǎng)頁，然后JS加密判斷

翻看JS代碼

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

很顯然，關(guān)鍵的代碼在checkPassword

JS混淆是必備的

去混淆一條龍走起

先將關(guān)鍵代碼提取出來

  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

得到去混淆后的結(jié)果

  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長(zhǎng)度21

發(fā)現(xiàn)了MD5加密，和兩個(gè)MD5字符串

看起來無關(guān)聯(lián)？

后來審計(jì)整個(gè)代碼發(fā)現(xiàn)，對(duì)輸入的flag分部分進(jìn)行判斷比較

寫出對(duì)應(yīng)的部分，在控制臺(tái)console輸出相關(guān)信息是一個(gè)不錯(cuò)的選擇

  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中的混淆

混淆是軟件開發(fā)中常用的技術(shù)，用于使代碼更難理解、分析和逆向工程。它將代碼轉(zhuǎn)化為一種復(fù)雜而紛繁的形式，同時(shí)保留其功能。混淆的主要目標(biāo)是阻礙對(duì)代碼的未經(jīng)授權(quán)訪問，保護(hù)軟件的知識(shí)產(chǎn)權(quán)或者隱藏軟件的真實(shí)行為。

在Android APK中，常用多種混淆技術(shù)來保護(hù)代碼，使其更難理解或逆向工程。其中一種技術(shù)是代碼混淆，它將源代碼轉(zhuǎn)換為等效但更復(fù)雜的形式，使其難以解讀和分析。另一種常用的技術(shù)是字符串加密，在這種技術(shù)中，敏感字符串（如API密鑰或URL）被加密，以防止輕易提取。此外，還采用控制流混淆來干擾代碼的邏輯流程，使其難以跟蹤程序的執(zhí)行路徑和理解其功能。

混淆對(duì)Android安全的影響

混淆技術(shù)的使用增加了安全研究分析的難度，并使一些基于簽名的檢測(cè)方法失效。字符串加密使得追蹤關(guān)鍵信息變得具有挑戰(zhàn)性。這些措施使得惡意軟件更難以識(shí)別和追蹤。

一種基于文本分類的軟件包混淆檢測(cè)方法

出于這些原因，我們的公司——Liansecurity開發(fā)了一款名為"Incinerator"的產(chǎn)品，旨在提供高效、準(zhǔn)確和自動(dòng)化的逆向工程服務(wù)。通過對(duì)惡意軟件的廣泛分析和先前混淆檢測(cè)技術(shù)的研究，在我們的Android APK逆向工程產(chǎn)品“焚化爐"中實(shí)現(xiàn)了一種基于文本分類的混淆檢測(cè)方法。根據(jù)我們的測(cè)試，我們的方法實(shí)現(xiàn)了98%的準(zhǔn)確率，這超出了我們的期望。在接下來的章節(jié)中，我們將詳細(xì)描述我們的方法。

背景

在檢測(cè)Android應(yīng)用程序中的混淆技術(shù)方面，最先進(jìn)的系統(tǒng)是"AndrODet"。在這項(xiàng)工作中，作者構(gòu)建了一個(gè)混淆檢測(cè)系統(tǒng)，針對(duì)每種混淆類型提取不同的特征，然后訓(xùn)練一個(gè)在線機(jī)器學(xué)習(xí)模型。下面列出了目標(biāo)混淆類型和AndrODet實(shí)現(xiàn)后的測(cè)試結(jié)果：

• 標(biāo)識(shí)符重命名：0.92
• 字符串加密：0.79
• 控制流混淆：0.67

AndrODet在Android環(huán)境中的局限性

在Android的背景下，AndrODet面臨某些限制，影響其作為靜態(tài)代碼分析工具的準(zhǔn)確性和有效性。主要集中在兩個(gè)方面：

基于APK的計(jì)算和特征弱化

AndrODet計(jì)算其度量指標(biāo)是基于整個(gè)APK，包括核心業(yè)務(wù)代碼和關(guān)聯(lián)的庫(kù)文件。在Android生態(tài)系統(tǒng)中，依賴庫(kù)可能會(huì)非常龐大，有時(shí)甚至比核心業(yè)務(wù)代碼本身還要大。而且大多數(shù)情況下，依賴庫(kù)并不需要進(jìn)行混淆。當(dāng)僅依靠整個(gè)APK進(jìn)行計(jì)算時(shí)，這些大型未混淆的庫(kù)的存在削弱了混淆部分的重要性，最終影響了AndrODet進(jìn)行正確判斷的準(zhǔn)確性。

無法處理Unicode編碼

AndrODet計(jì)算距離的方法局限于ASCII編碼。然而，使用Unicode編碼進(jìn)行混淆技術(shù)的使用越來越普遍。因此，AndrODet無法處理和分析使用Unicode編碼進(jìn)行混淆的代碼。這個(gè)限制阻礙了該工具在真實(shí)生產(chǎn)場(chǎng)景中準(zhǔn)確檢測(cè)和評(píng)估混淆代碼的安全性和質(zhì)量方面的能力。

AndrODet的限制對(duì)其在真實(shí)生產(chǎn)場(chǎng)景中的準(zhǔn)確性構(gòu)成了挑戰(zhàn)。了解這些限制及其對(duì)真實(shí)生產(chǎn)環(huán)境的影響對(duì)于尋求改進(jìn)Android應(yīng)用程序安全領(lǐng)域代碼分析工具能力的研究人員和從業(yè)者至關(guān)重要。

我們的方法

我們的方法主要解決了代碼混淆技術(shù)中最常見的標(biāo)識(shí)符重命名的識(shí)別問題，這是惡意軟件常用的混淆技術(shù)。我們的方法也可以擴(kuò)展到字符串加密。在我們的研究中，我們觀察到，當(dāng)研究人員評(píng)估一個(gè)代碼片段是否被混淆時(shí)，他們最初的判斷依賴于類名、方法名和變量名的可理解性，以及可識(shí)別和常用的編碼約定，即所謂的“編碼英語”，與類似'a'、'Zb'、'c4'、'1li'、'0Oo'等不容易理解的名稱進(jìn)行對(duì)比。最初，我們嘗試了算法方法來解決這個(gè)問題，但測(cè)試結(jié)果不怎么理想。然而，我們突然想到，這實(shí)際上是一個(gè)經(jīng)典的自然語言（NLP）分類問題。

憑借這一靈感，我們將混淆檢測(cè)問題轉(zhuǎn)化為文本分類問題，而深度神經(jīng)網(wǎng)絡(luò)處理文本分類，已經(jīng)非常成熟。我們的測(cè)試結(jié)果也證明了這種轉(zhuǎn)換非常成功。“字符串加密”本質(zhì)上也是一個(gè)文本分類問題，因此我們相信這種方法可以輕松擴(kuò)展到字符串加密。

方法說明

第1步：反編譯和Smali提取

第1步涉及反編譯AndroidAPK和提取Smali代碼。在我們的實(shí)現(xiàn)中，我們使用我們自己的反編譯引擎"Reactor”。其他開源工具，如AndroGuard或Apktools也可以。從每個(gè)類中，我們提取類名和類變量名，這些是下一步分析的輸入。理論上可以提取更多特征，如函數(shù)參數(shù)名稱和局部變量，但提取更多的特征對(duì)準(zhǔn)確率沒有太大的提升，因?yàn)榍懊娴娜齻€(gè)特征已經(jīng)達(dá)到了很高的準(zhǔn)確性。

第2步：創(chuàng)建訓(xùn)練集

創(chuàng)建兩個(gè)不同的訓(xùn)練集。第1個(gè)訓(xùn)練集是混淆的類生成的數(shù)據(jù)，標(biāo)記為1。第2個(gè)訓(xùn)練集是未混淆的類生成的數(shù)據(jù)，標(biāo)記為0。

第3步：文本分類神經(jīng)網(wǎng)絡(luò)訓(xùn)練

我們構(gòu)建了一個(gè)文本分類神經(jīng)網(wǎng)絡(luò)。該神經(jīng)網(wǎng)絡(luò)使用步驟1中提取的特征和步驟2中的相應(yīng)標(biāo)簽進(jìn)行訓(xùn)練。通過利用深度學(xué)習(xí)網(wǎng)絡(luò)模型進(jìn)行訓(xùn)練。

該模型分成3層：嵌入層、LSTM層和密集層。

1）嵌入層：嵌入層將輸入整數(shù)序列轉(zhuǎn)換為密集矢量表示。

2）LSTM層：LSTM（長(zhǎng)短期記憶）層是一種能夠處理序列數(shù)據(jù)和捕獲長(zhǎng)期依賴關(guān)系的循環(huán)神經(jīng)網(wǎng)絡(luò)（RNN）。在該模型中，使用了具有128個(gè)單元的LSTM層。

3）Dense層：Dense層是一個(gè)全連接層，對(duì)LSTM層的輸出進(jìn)行線性變換并應(yīng)用sigmoid激活函數(shù)。

第4步：訓(xùn)練

我們從1000個(gè)數(shù)據(jù)樣本開始，發(fā)現(xiàn)結(jié)果已經(jīng)非常不錯(cuò)。隨著我們將樣本量增加到10000，準(zhǔn)確率和驗(yàn)證準(zhǔn)確率都變得非常令人滿意。最終，我們的模型使用100000個(gè)數(shù)據(jù)樣本進(jìn)行了訓(xùn)練。我們?cè)噲D進(jìn)一步擴(kuò)充數(shù)據(jù)集，但準(zhǔn)確率和驗(yàn)證準(zhǔn)確率沒有提高。為了避免由單個(gè)APK生成的數(shù)據(jù)引起的偏差，我們從數(shù)據(jù)庫(kù)中隨機(jī)提取了幾百個(gè)APK來生成我們的數(shù)據(jù)。從生成的數(shù)百萬個(gè)數(shù)據(jù)樣本中，我們隨機(jī)選擇了100000個(gè)進(jìn)行訓(xùn)練。

訓(xùn)練結(jié)果如下：

訓(xùn)練準(zhǔn)確率：99.75%

驗(yàn)證準(zhǔn)確率：98.50%

實(shí)驗(yàn)結(jié)果與分析

在實(shí)際應(yīng)用中，為了確定一個(gè)APK是否被混淆，我們使用了一種方法，該方法涉及檢查APK內(nèi)的每個(gè)類是否進(jìn)行混淆。通過將混淆類的數(shù)量除以類的總數(shù)，我們可以計(jì)算APK中混淆代碼的比例。盡管在理論，針對(duì)每個(gè)類，判斷可能出現(xiàn)假陽或者假陰，但是在判斷一個(gè)APK是否存在現(xiàn)象時(shí)，很難出錯(cuò)，因?yàn)橐粋€(gè)被混淆的APK，需要確保它的大部分代碼很難理解，這正是混淆的目的和最終呈現(xiàn)，大部分難以理解的類，是不能逃過模型的檢測(cè)的。因此，我們的模型在確定APK中是否存在混淆時(shí)達(dá)到了接近100%的準(zhǔn)確率。

第一輪訓(xùn)練后，我們從Fdroid和Abuse各獲取了1000個(gè)APK，進(jìn)行驗(yàn)證測(cè)試。FDroid代表良性apk， abuse代表惡意 apks，測(cè)試后，我們發(fā)現(xiàn)有較高概率出現(xiàn)假陽，一些非常短的內(nèi)部類，例如”Class: MainActivity ExternalSyntheticLambda15; Method: <init> run Field: f>第一輪訓(xùn)練后，我們從Fdroid和Abuse各獲取了1000個(gè)APK，進(jìn)行驗(yàn)證測(cè)試。FDroid代表良性apk， abuse代表惡意 apks，測(cè)試后，我們發(fā)現(xiàn)有較高概率出現(xiàn)假陽，一些非常短的內(nèi)部類，例如”Class: MainActivity ExternalSyntheticLambda15; Method: <init> run Field: f$0 f$1 f$2 “ 這樣的情況，模型無法判斷是否是混淆。為了解決這個(gè)問題，我們從假陽的apk中，抽取了3000條數(shù)據(jù)樣本，加入訓(xùn)練集合。重新訓(xùn)練，再次訓(xùn)練后，極大的降低了假陽。< f f “ 這樣的情況，模型無法判斷是否是混淆。為了解決這個(gè)問題，我們從假陽的apk中，抽取了3000條數(shù)據(jù)樣本，加入訓(xùn)練集合。重新訓(xùn)練，再次訓(xùn)練后，極大的降低了假陽。

下面是我們抽取隨機(jī)的100個(gè)測(cè)試樣本，因?yàn)槲覀兊哪Ｐ托ｒ?yàn)準(zhǔn)確率是98.5%，所以測(cè)試結(jié)果中，混淆覆蓋率1%，2%這樣的情況，應(yīng)該判斷為沒有混淆。剩下結(jié)果中的4%(md5:8328cd96c931d06d25f67d42a50fd20d)這個(gè)是誤報(bào)，分析原因是因?yàn)檫@個(gè)apk的類非常少，三條假陽數(shù)據(jù)導(dǎo)致了這個(gè)錯(cuò)誤。其他的5%(923df6854199e999fdd274729b28a1ad)，7%(71e293f29e636112e0a00ebac8cf3eb8)都是真實(shí)存在的混淆。所以這個(gè)模型，判斷混淆的準(zhǔn)確率接近100%，而且APK中存在非常少量的混淆也是可以檢測(cè)出來。

我們的訓(xùn)練集中并沒有出現(xiàn) unicode的混淆樣本，但是在測(cè)試的時(shí)候，這種情況也會(huì)被識(shí)別為混淆，因?yàn)槟Ｐ蛯?duì)非混淆的文本有非常好的識(shí)別，所以即便出現(xiàn)樣本中沒有出現(xiàn)的其他混淆情況，也可以識(shí)別。

限制和未來方向

本文討論的都是針對(duì)標(biāo)識(shí)符重命名的混淆檢測(cè)，相同的辦法可以應(yīng)用到字符串檢測(cè)上。但是不能應(yīng)用到控制流混淆檢測(cè)。AndrODet的結(jié)果在這方面的表現(xiàn)也不盡如人意。未來我們會(huì)針對(duì)控制流檢測(cè)專門設(shè)計(jì)新的模型。

與AndrODet相比，我們的模型需要相對(duì)更多的時(shí)間來確定APK是否被混淆，因?yàn)樗枰獑为?dú)檢測(cè)每個(gè)類。雖然可以批量檢測(cè)，但APK可能包含數(shù)千甚至數(shù)萬個(gè)類。然而，在生產(chǎn)環(huán)境中，這是可以接受的，因?yàn)榉治鯝PK涉及靜態(tài)分析、動(dòng)態(tài)分析等各個(gè)方面，需要更長(zhǎng)的時(shí)間來執(zhí)行。因此，在我們的產(chǎn)品中，混淆檢測(cè)的等待時(shí)間是合理的。此外，這個(gè)時(shí)間也可以通過并行架構(gòu)處理來緩解。

結(jié)論

我們提出了一種基于文本分類的方法來檢測(cè)APK是否被混淆。這種方法以前在現(xiàn)有研究中沒有應(yīng)用過，可以擴(kuò)展到其他軟件中的混淆檢測(cè)以及字符串加密檢測(cè)。此外，我們建議APK中混淆的檢測(cè)應(yīng)該在類級(jí)別進(jìn)行，因?yàn)檫@樣可以達(dá)到基本100%的準(zhǔn)確率。

我們已經(jīng)在正式生產(chǎn)環(huán)境中實(shí)現(xiàn)了這種方法。

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