NgIokWeng's Blog

注：本文使用了自編譯魔改的Frida！！！ 分析通過hook dlopen，打印加載的so，發現到libmsaoaidsec.so後frida就閃退，由此可知libmsaoaidsec.so中有檢測frida的邏輯。 通常很多檢測frida的邏輯都會使用fopen函數打開/proc/self/中的文件( 如/proc/self/maps )，以此來尋找是否存在frida的特徵。 而fopen底層的系統調用號是__NR_openat，嘗試使用https://github.com/ngiokweng/Frida-Seccomp來監控該系統調用。 Hook驗證猜想在保存的log裡搜索libmsaoaidsec.so，目標是調用棧中出現libmsaoaidsec.so的那些。 第一個打開了：/proc/15547/cmdline 第二個打開了：/proc/self/maps 第一個大機率不是檢測點，而是其他某些操作？因為不論是在注入frida前後，它的內容都不會變。 而第二個則大機率是檢測點，通過hook來驗證下。 由於0x18a34是由.init_proc裡的函數調用的，因此不能直 ...

Notion自帶導出功能： 導出的壓縮包裡，一個是md格式的notion筆記，一個是保存圖片的資料夾，如下所示： 在腳本同級目錄下創建一個target目錄，將壓縮包裡的東西放進去。 手動配置blogInfo，然後執行腳本即可 腳本如下： 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106import osimport refrom datetime import datetimedef removeSpaces(directory): for filename in os.listdir(directory): newFilename = filename.replace(" " ...

殼實現原理 & 方案概述 殼本身也是一個APP程序，只不過它的作用只是用來解密原APP程序，然後加載。 殼程序在完成dex的解密後，都需要通過ClassLoader來加載( APP本身的Dex文件 )，一般是通過DexClassLoader來加載，安卓8.0以後引入了InMemoryDexClassLoader從內存加載Dex文件 最終還需要修復ClassLoader和Application( 具體原因在下方給出 )，才能順利運行原APP的Activity。 修復ClassLoader為什麼需要修復ClassLoader？Android的系統組件如Activity、Service等都是由系統組件加載器( PathClassLoader )加載的，以這方式加載的系統組件會有一個所謂的組件生命周期，而我們直接用DexClassLoader加載的類是沒有組件生命周期的，即使能通過對APK的動態加載完成對組件類的加載，但當系統啟動該組件時( 如startActivity )時，依然會出現找不到該類的情況。 以如下代碼為例，通過loadClass加載test.dex裡的MainActi ...

前言這是一款挺老的遊戲了，以前身邊很多人在玩所以我也玩了一會，在遇然得知網上有這遊戲的免費外掛後去嘗試了一下，感覺很爽，畢竟是一款半單機的遊戲，就算開掛也不太會影響別人。 在那之後有試過研究一下這外掛的原理，但當時可謂是0基礎，只能按別人影片裡的教學一步一操作地嘗試自己寫外掛，最後不出意外地失敗了。再之後又嘗試了幾次，同樣以失敗告終… 雖說一直失敗，但不得不說我對寫外掛一直都很感興趣，大學選了計算機專業很大部份原因也是因為對外掛感興趣吧。 今天總算是圓了這以前的遺憾了^^ 前置操作利用MT管理器的APK共存功能複製一個APK出來：安裝包提取→選擇APK→APK共存 修改就只對新複製出來的那個APK進行修改，原APK不作任何修改，方便之後hook兩者來對比差異 閃退分析以前在修改這遊戲後發現會閃退，一直以為它有簽名校驗，但其實並沒有。 它真的會校驗的是libmonsterstrike.so這個so，如何發現的？當不進行任何修改直接重打包APK後，它不會閃退；而只要修改了libmonsterstrike.so任一地方後，APP會閃退，由此可知該APP會校驗libmonsterstrike ...

Target：aHR0cHM6Ly9qb2JzLjUxam9iLmNvbS9zdXpob3UtZ3l5cS8xNTMzMDczMjEuaHRtbA== ( 多刷新幾次就會觸發滑塊 ) 在調試前可先用fiddler等工具固定滑塊頁面，這樣會方便很多 跟n值生成位置第一種方法在滑動滑塊前先下個script斷點，然後會斷在這裡 這時去看網路面板，可以發現滑塊的驗證是通過nocaptcha/analyze.jsonp這個接口，其中最關鍵的參數就是n 簡單跟下棧就能找到n的生成位置，o.__fy_options固定就可以 第二種方法這種方法是在別的大佬的文章看到的，一開始我是用第一種方法找到的，但第二種方法感覺也挺好的，特此記錄一下 下個全局的的mousedown斷點 斷下後走幾步會到這裡，看到它添加了一個mousemove事件，跟入s看看 經過一些運算後，判斷是否進入i，繼續深入i看看 前面先移除了各種事件，最後進入了m函數 然後m函數就是n值生成的位置 本地&瀏覽器調試通常我找到密文生成位置後，會先嘗試導出相關函數，然後在本地運行，直到能利用出值為止( 雖然這 ...

好久沒更新blog了，也好久沒有玩CTF了，來水一篇好了^^ 分析易知具體邏輯在so層 分析後發現如下位置，最關鍵的就是那個與input異或的v13 並且這個v13高機率是固定的 異或完之後就與enc對比，全對才返回true 解法 由上述分析可知那個v13異或數組是最關鍵的 我選擇使用指令trace的方式來獲取這個v13，用的是這個項目來生成trace日志 生成的trace日志裡有以下這段，0xf3,0x3f...就是v13數組( 這其實少了第一個元素0xbb ) 12instruction 0x776a2c1430 0x776a2c13f8 4 ldr w12, [x12, w14, uxtw #2]statistics x12:0xf3,0x39,0xd4,0x9,0xb1,0xde,0xa7,0xf0,0x33,0xa,0xcf,0xa6,0x3d,0x8,0xa5,0x72,0x9e,0x9d,0x49,0xc9,0x68,0x7d,0xb5,0x59,0x1b,0xd5,0xb7,0x59,0xad,0xe3,0x6e 解密腳本： 123456789101112 ...

用1或9填充DOS頭、PE頭和節表中無用的部分 可以在這些地方見縫插針地填入所需的東西，如程序主要的代碼、Dll名稱和函數名稱等 DosStub可以整段刪掉，如下圖 暫時先不修改各個RVA，最後刪完再一次過重設所有需要修改的RVA 接下來修改可選PE頭的數據目錄表，因為只需要用到數據目錄表第2項的導入表，因此後面的14項都可以直接刪除 並將數據目錄表的項數設為2 節表只需留下.text節表，.rdata可以直接刪除 可以直接刪除的原因是，數據目錄表能直接定位到導入表，因此不需要依靠.rdata節表也行 分析一下.rdata對應的節區 可以先從原始文件中，找到.rdata對應節區的的起始位置和大小，從而在當前文件中找到.rdata對應節區 整個藍色部分就是.rdata對應的節區，紅框部分是IAT，這部分不重要，暫時以9填充，重要的是綠框部分，這是一個IDT結構的數組，以20個字節的0作為IDT數組的結尾 IDT結構體最重要的是OriginalFirstThunk、FirstThunk和Name這3個屬性，後續要手動將這3個屬性指向正確的地址 由於只需要Messa ...

Target：aHR0cHM6Ly93d3cuZGlnaWtleS5jbi8= 前言本文參考了以下文章和視頻，感謝大佬們的分享 https://www.bilibili.com/video/BV1d14y1h7P9/?spm_id_from=333.880.my_history.page.click&vd_source=999a37555f77c5995df6185262c99be3 https://blog.csdn.net/huangch135/article/details/130227868 基本分析 akm的目標是cookie裡的_abck這個值 當_abck裡的~-1~變成~0~時就算是有效 上述的_abck由類似1diI9T-4eS/HLR5GidZ/XH/YkNYXGfprwm5/cEMlcQYB/TnUjFxE/ZWTA這樣的接口返回 本網站屬於簡單類型的akm，因此在風控正常的情況下，第1個接口返回的cookie就已經是有效的 而對於其他難度的akm，則可能需要在第3次後，什至是在某些事件觸發後，才會返回有效的cookie 第一次請求 從上 ...

目標網站：aHR0cHM6Ly9mYW55aS5iYWlkdS5jb20vI2VuL2NodC9oZWxsbw== 請求參數跟值 下個XHR斷點，一步一步跟很容易可以來到這處 請求參數就是this.paramData 這時一個快捷的方法是先看看this.constructor，看paramData是否在構造函數裡就已經賦值 一看發現果然如此 然後向上一層就能找到參數生成的地方 慢慢調試，會發現除了sign外，其他參數都能固定 生成sign的函數也很容易扣，用一般webpack的扣法就能搞出來 Acs-Token跟值 在上述跟值的過程中就能看到Acs-Token賦值的地方 打個條件斷點跟到這裡，再往前就是異步 在異步的地方下斷點，測試後發現代碼會走2次這裡，若第2次時再按F8就會去到上一步條件斷點的位置 因此在第2次時按F11 然後發現n是生成好的Acs-Token，代表我們又更前了一步 繼續向前跟會發現Acs-Token在n.gs的回調函數中出現 跟進n.gs，來到另一個名為acs-2060.js?_=XXXX的代碼中，而n.gs就會下圖紅框的這 ...

無限debugger這題有個無限debugger，用下面這個腳本暫時過一過，能分析頁面邏輯就行 123456var Func = Function;Function = function(){ if(arguments[0].indexOf('debugger')!=-1)return function(){}; return Func.apply(this,arguments);} 定位加密函數 通過hook XMLHttpRequest.prototype.open，找到加密參數的位置 然後會跟到_yrxyA$這個函數，接下來就是要想辦法將它扣出來了 12345678910111213141516171819202122232425262728function _yrxyA$(_yrx7jl, _yrxcze) { try { if (typeof _yrx7jl !== _yrxQ9C[6]) _yrx7jl += &# ...