去除一个未加固APP的升级提示弹窗，我们先看看app 是否进行加壳，发现使用的是邦邦免费加壳

我们在测试机上安装这个APP，安装命令如下：

adb  installl C:\Users\Avenue\Desktop\AndroidFridaBeginnersBook-main\Chap05\com.hello.qqc.apk

我们可以发现在APP 手动跳过欢迎界面后会弹出升级提示弹窗， 无论点击任何位置都无法消除弹窗：

在Android 中常使用的实现弹窗有三种：Android.App.Dialog、Android.App.AlertDialog 和Android.widget.PopupWindows。

Objection快速自动化定位

我们使用objection 注入app， 搜索对应的弹窗的类，这个APP好像是多进程，需要是用 -d 参数， 同时关闭magisk 的 roothide 隐藏功能，不然会失败。

需要把app关闭之后，在注入它

注入命令如下：

objection -d  -g com.hello.qqc explore

在弹窗出现后，加载对应的插件，在内存中搜索对应的实例

plugin load  ./.objection/plugins/Wallbreaker

 plugin wallbreaker objectsearch  android.app.AlertDialog
 plugin wallbreaker objectsearch  android.app.Dialog
 plugin wallbreaker objectsearch  android.widget.PopupWindow

可以发现出现的弹窗类是android.app.Dialog

我们对这类来进行 hook，查看是否有对应的函数调用记录来判定是否使用了相应类。
发现这上面这个类比较可疑

我们使用如下命令对android.app.Dialog.setCancelable 函数进行Hook

android  hooking watch class_method android.app.Dialog.setCancelable --dump-args --dump-backtrace --dump-return

经过调用栈，发现APP中发起弹窗的函数如下图：

使用objection加载Wallbreaker搜索值得怀疑的地方

plugin wallbreaker objectsearch cn.net.tokyo.ccg.ui.fragment.dialog.UpdateDialogFragment

找到之后，打印该对象的属性

plugin wallbreaker objectdump --fullname 0x2702

看到[0x2aca]: cn. net. tokyo.ccg.bean.VersionBean$Version@2e81a62
然后将其打印出来

plugin wallbreaker objectdump --fullname 0x2aca

可以看到打印出的内容，与界面所展示的一致，验证了所见即所得原理。

我们使用脱壳工具Dexdunp 进行脱壳

脱壳出来的文件如下：

使用 jadx-gui 打开目标dex 并找到对应的UpdateDialogFragment类， 我们发现UpdateDialogFragment 继承了DialogFragment类

为了进一步确定这个类被哪个外部函数进行调用， 使用下面的命令进行Hook

android hooking watch class   cn.net.tokyo.ccg.ui.fragment.dialog.UpdateDialogFragment

打印调用栈

android hooking watch class_method xxx.ui.fragment.d
ialog.UpdateDialogFragment.b --dump-args --dump-backtrace --dump-return

xxx.ui.fragment.dialog.UpdateDialogFragment.b是从xxx.ui.activity.MainActivity.a该类过来

使用jadx-gui 定位这个函数，代码如下：

public void a(VersionBean.Version version, boolean z) {
        this.f1696a = version.url;
        if (version != null) {
            UpdateDialogFragment.b(version, z).show(getSupportFragmentManager(), UpdateDialogFragment.class.getSimpleName());
        }
    }

修改源码重打包去强制升级

我们重新打包时，由于这个app 是加固的，需要注意一些地方：
第一，重新打包时，应该使用脱壳后原始APP的dex替换原来的dex
第二，App在加固后的入口函数变成了壳的入口点，因此在重新打包之后需要修改AndroidMainifest.xml的入口类。
我们使用 apktool 反编译APK 时选择不反编译dex文件并删除壳的dex， 而 apktool 的 -s 参数提供了不编译APK中的dex文件的功能。

apktool -s d xxx.apk

删除apk原有的classes.dex文件，并将脱壳后的classes.dex放入， 按照文件的大小依次命名为classes.dex 、classes2.dex、classes3.dex

rm classes.dex

第二个问题，修改app 的入口类，使用jadx-gui打开包含关键类的dex文件，搜索extends Application

然后回编译、首次使用需先生成keytool、签名

apktool b xxx  生成的目录在 dist 目录下

然后进行签名： # 生成keytool

keytool -genkey -alias android.key -keyalg RSA -validity 20000 -keystore /<MY_PATH>/android.key

将dist目录下的apk拷贝到d:\apktool目录，执行下面命令

需要把apk 和签名文件放在jdk的bin 目录下

注意生成签名apk必须要 指定目录， 在当前目录没有权限生成签名的apk

 jarsigner -verbose -keystore abc.keystore -signedjar 目录/xxxsigned.apk xxx.apk abc.keystore

测试可以成功运行后，我们接着反编译，搜索之前定位的类名含MainActivity的smali文件，编辑查找UpdateDialogFragment找到之后修改判断语句

apktool d xxxsigned.apk

找到对应的代码文件
smali/cn/net/tokyo/ccg/ui/activity/MainActivity.smali

修改成如下：

改完之后回编译、签名、运行

apktool b xxx  生成的目录在 dist 目录下

在进行签名

jarsigner.exe -verbose -keystore lala.keystore -signedjar D:\APP-test\apktool/com_singn_tets.hello.qqc.apk  com_singn.hello.qqc.apk lala

然后我们进行尝试，看看发现已经没有了强制升级的弹窗。

来自：https://www.yuque.com/avenue-le/ybne4d/gex5gg