From（?書旗小說過簽名校驗 【?使用?DDMS?分析方法調用流程?】?）：https://www.cnblogs.com/LuLuLuHao/p/12874468.html

簽名校驗一般步驟：

• 1. 先查有沒有加殼，如果有殼，先脫殼
• 2. 如果沒加殼，則 apk 在不做任何修改的情況下重新簽名，然后安裝，看能不能打開 app

書旗小說.apk 過簽名校驗

1、根據啟動流程

：https://www.bilibili.com/video/BV1vE411c7Zj?p=62

2、簽名三兄弟

（ log?插樁方法?分析方法調用流程? ）：https://www.bilibili.com/video/BV1vE411c7Zj?p=63

簽名三兄弟：getPackageManager、getPackageInfo、getPackageName、（?signature?）

context.getPackageManager().getPackageinfo(context.getPackageName(), 64).signatures[0].hashCode()

視頻中是通過搜索簽名三兄弟，定位到 smali，然后 log 插樁，ddms 看 log 輸出，分析流程。。。

3、根據 ddms 中 log 信息判斷

1. 把書旗小說.apk（?下載地址：https://www.wandoujia.com/apps/288203/history_v175 ）通過?AndroidKiller?重新簽名，然后安裝，安裝發現閃退。

2. 打開 ddms 看看有什么信息? ?發現了一個 killProcess 方法

（ 滑動到最后，從下往上看！！！?默認按時間先后順序列出，最下面的是最新的 log ?）

3. 打開 jadx-gui 分析代碼，搜索 "KillProcess"? 根據 ddms 信息? 發現它調用了 com.shuqi.app.ShuqiApplication 包里面的方法? ?我們跳轉到里面去

?4. 他這個邏輯就很清晰了

5. 讓這個 handleToken 方法返回 true 即可? 我們打開 Androidkiller? 修改 smali

加這兩行代碼

6 .apk 完美運行

4、搜索 application 這個類

一個 APK 只有一個 Application。每個 Apk 運行時都需要有一個?Application對象，Application對象 執行 onCreate方法時APP就開始運行

一般做反調試或者簽名校驗都會在 入口點(即application)，每個 Apk 運行時都需要有一個?Application對象，所以直接搜索 application 這個類。

點擊進入 ，然后找到?onCreate 方法并查看，可以看到 一個?checkSigAsync 方法，

點擊進入?checkSigAsync 方法，可以看到就是進行簽名校驗的。。。

2022.03.18 新版書旗小說

2022.03.18 最新版的書旗小說 簽名校驗已經不再 java 層，而是放到了 so 層，

jadx 反編譯 書旗小說apk ，然后搜索 signature ，

?

Android 文檔：https://developer.android.google.cn/reference/android/content/pm/Signature?hl=en

?

浦發銀行 apk 過簽名校驗?

嗶哩嗶哩（?浦發銀行.apk?簽名校驗【so?文件修改】入口點?和?入口界面 ）：
https://www.bilibili.com/video/BV1UE411A7rW?p=64

最新版本有加殼。。。。。。。。。。所以下載老版本 apk

浦發銀行apk 下載地址（8.0 版本 ）：https://www.wandoujia.com/apps/31675/history_v83

這個簽名校驗是在 so 層。。。

1. 查殼

下載好 8.0 版本的 apk，首先使用 AndroidKiller 查下有沒有加殼

可以看到 8.0 版本的 apk 沒有加殼。

2. 根據 入口點? 或者 入口頁面

入口點 優先于 入口頁面 加載和執行。

圖示：

定位到入口點 smali 代碼，找到 onCreate 函數，查看對應邏輯，當不好分析時，可以轉換成java 代碼進行分析

提示：AndroidKiller?調用 jd-jui 查看 java 代碼出現 "未找到對應的APK源碼" 時，說明 jd-jui 無法把 smali 代碼轉換成 java 代碼，這時需要換個工具，例如：jadx-gui、Jeb 等

轉換成 java 代碼進行分析（ 這里使用?jadx-gui 轉換 ）

這里也看不出什么（ 其實 YTSafe 就是要找的 關鍵點?），打開 ddms 或者 monitor 看下 log 輸出，

查看??Java_com_yitong_safe_YTSafe_native_1init 對應的 java 代碼（靜態注冊）

可以看到就是在 libyt_safe.so 庫里面進行的校驗

到此，java 層分析結束，下面就是使用 IDA 分析這個 so 庫了。。。

使用 IDA? Pro 分析 so

使用 IDA Pro 打開提取到的 libyt_safe.so 文件。

拿到一個 so 庫后，首先分析 so 的 "導出函數"，

因為 init_array 比 JNI_onLoad 執行的時間更早，所以先看下 init_array 有沒有坑。。。

Ctrl + s? 打開 段選擇 窗口，選擇?init_array? 點擊進入?init_array? 對應代碼位置

發現 init_array 里面沒有什么函數，然后搜索 JNI_onLoad ，發現沒有?JNI_onLoad 這個函數，在搜索 java_? 開頭的函數（即 靜態注冊的函數），發現有很多靜態注冊的函數

可以看到 有個函數帶 init ，可以點進去看看。點擊 ---> ARM 匯編代碼 ---> F5 反編譯 ，查看偽代碼

雙擊 init_lib 函數，跳轉到函數對應位置，可以看到 init_lib 函數調用了 check_app 函數

查看 check_app 代碼，發現有個 get_sign 函數，字面意思理解就是? 得到簽名，

直接把這個函數去掉，或者 nop 掉，不調用這個簽名函數。

修改 so 文件，并保存（ 34' 45'' ）。也可以使用??winhex 打開并修改對應位置。 35' 25''

修改后，替換原來的 so 文件，安裝還是閃退，看下 check_app 代碼 邏輯，是在 while 循環里面 ，

可以 使用 IDA 動態調試 so ，然后打斷點進行分析，

int __fastcall check_app(int a1, int a2) {int v2; // r5int v3; // r4int v4; // r0int v5; // r0int v6; // r5int v7; // r6unsigned __int8 *v8; // r5char *v9; // r5char *v10; // r6int i; // r3char v12; // r3int v13; // r5int v14; // r6int v15; // r3int v17; // [sp+Ch] [bp-44h]int v18; // [sp+10h] [bp-40h]unsigned __int8 *v19; // [sp+14h] [bp-3Ch]int v20; // [sp+18h] [bp-38h]_BYTE *v21; // [sp+1Ch] [bp-34h]int v22; // [sp+20h] [bp-30h]int v23; // [sp+24h] [bp-2Ch]int v24; // [sp+28h] [bp-28h]unsigned __int8 *v25; // [sp+30h] [bp-20h]v2 = a2;v3 = a1;v4 = (*(int (**)(void))(*(_DWORD *)a1 + 668))();v5 = get_sign(v3, v2, v4);v6 = cert_encode(v3, v5);v7 = message_digest(v3, "MD5", v6);v22 = message_digest(v3, "SHA1", v6);v20 = (*(int (__fastcall **)(int, int))(*(_DWORD *)v3 + 684))(v3, v22);v23 = j_malloc(v20);(*(void (__fastcall **)(int, int, _DWORD, int, int))(*(_DWORD *)v3 + 800))(v3, v22, 0, v20, v23);v8 = (unsigned __int8 *)(*(int (__fastcall **)(int, int, _DWORD))(*(_DWORD *)v3 + 736))(v3, v7, 0);v24 = (*(int (__fastcall **)(int, int))(*(_DWORD *)v3 + 684))(v3, v7);inv_mix_key(v8, v24);v25 = (unsigned __int8 *)get_key(v8, v24);(*(void (__fastcall **)(int, int, unsigned __int8 *, _DWORD))(*(_DWORD *)v3 + 768))(v3, v7, v8, 0);v18 = 0;while ( !CHECK_APP ){if ( v18 >= ENC_COUNT )j_exit(0);v9 = &enc_sha1[65 * v18];v17 = j_strlen(v9) / 2;v19 = (unsigned __int8 *)j_malloc(v17);v10 = (char *)j_malloc(3);v10[2] = 0;for ( i = (int)v19; ; i = (int)(v21 + 1) ){v21 = (_BYTE *)i;if ( i - (signed int)v19 >= v17 )break;*v10 = *v9;v12 = v9[1];v9 += 2;v10[1] = v12;*v21 = hex2dec(v10);}j_free(v10);v13 = invCipherAll(v19, v17, v25, v24);j_free(v19);while ( !*(_BYTE *)(v13 + v17 - 1) )--v17;v14 = j_malloc(v17);j_memcpy();v15 = 0;if ( v17 == v20 ){while ( 1 ){if ( v15 >= v20 ){LOBYTE(v15) = 1;goto LABEL_16;}if ( *(unsigned __int8 *)(v14 + v15) != *(unsigned __int8 *)(v23 + v15) )break;++v15;}LOBYTE(v15) = 0;} LABEL_16:CHECK_APP = v15;++v18;}j___android_log_print(6, "YT_SAFE", &unk_695E);return (*(int (__fastcall **)(int, int, int, _DWORD))(*(_DWORD *)v3 + 768))(v3, v22, v23, 0); }

在看下 get_sign 函數

點擊

函數進入，可以看到和簽名相關的函數

方法 2（ 搜索字符串 ）：

在打開的 Strings window中搜索?getPackageManager、getPackageInfo、signatures。這里以搜索?getPackageManager 為例：

查看?getPackageManager 的調用：

可以看到只在 get_sign 里面調用了?getPackageManager，所以可以判定 get_sign 是關鍵函數。。。

或者 直接把 check_app 給去掉 。 40' 30''

按教程 上搞到這沒搞出來，換思路在搞。。。so 分析流程，ida 修改 so 文件

方法 2：

刪除 smali 代碼中的??

發現 apk 可以打開顯示界面

這里不在截圖。。。

總結

以上是生活随笔為你收集整理的安卓逆向_19（ 二 ） --- APK保护策略【重新签名后安装打开失败 --- 书旗小说.apk、浦发银行.apk的过签名校验【so 文件修改保存】】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。