【安卓逆向】如何简单快速去除云注入（另附MT论坛某佬的方法对比）

0、相关工具链接：

先说我的解决办法：

1、使用算法助手分析出原作者自己写的那个Application类名
2、把这个类名替换AndroidManifest文件中的<application的android:name属性即可
3、（可选）把云注入文件删除，删不删都不影响。

其中使用到的工具备份百度云链接:（工具仅供学习交流使用，切勿用于非法用途）

因为虚拟机有点大，所以提供两种选择：
1、带虚拟机（大文件）：
链接:https://pan.baidu.com/s/1nuhMH1QjrggwhFMek8N5Ow
提取码:4848
2、不带虚拟机（小文件）：
链接:https://pan.baidu.com/s/1NGtp7VqpRXQpKfi49dEr5w
提取码:4848

1、需求分析：

因为最近使用的虚拟机突然不能用了，被人云注入强制弹窗，如下图：（这一看就是云注入了）

2、原理分析：

前提知识：
1、安卓中的每一个应用程序真正的入口点是Application类实例(如果你做过安卓开发你就会知道)。
2、一个应用最多只能有一个Application类实例。开发者通过继承Application类来实现，在Java中写法为：public class App extends Application，这个Application来自android.app.Application包。
3、如果用户继承Application类并使用，必须要在AndroidManifest文件中的<application标签内的android:name属性写上这个自定义类的包名（路径）。

比如：
（1）假设原来作者写了一个Application类（类名为App）：
public class App extends Application{ .... }
（2）那么作者必须要在AndroidManifest文件的<application标签的出现这个东西：android:name="com.xxx...App"
但是你如果要加上自己的Application，那你必须继承上面的App类（类名为App2）：
public class App2 extends App{ .... }
（3）然后对应修改在AndroidManifest文件的<application标签的改成新的类：android:name="com.xxx...App2"

关于这个Application类的具体细节请自行查看官网文档（英文，自己翻译）
https://developer.android.google.cn/reference/android/app/Application

也就是说如果原来的应用作者已经写一个了，你逆向修改的时候想直接再加一个自己的Application类是不行的。如果你想加，就必须要继承原来作者写的那个Application类。也就是说，你首先要知道原来作者写的这个Application的类名。一般在AndroidManifest文件中的<application的android:name属性就能看到目前程序的那一个Application类名路径了。

通过反编译，我们发现
1、在AndroidManifest文件的<application标签的出现这个东西：android:name=“com.cloudinject.feature.App”
比如：
这就说明可能存在两种情况：
1、原作者没继承Application，但是有人通过修改继承Application类加入的
2、原作者已经继承Application，但是有人通过修改继承原作者的Application那个类名加入的

---

2、分析这个com.cloudinject.feature.App包对应的代码
其实你会发现就是多了一个com.cloudinject的目录。
cloudinject这个单词的意思就是云注入。这个目录中强行继承了作者原来的Application类，然后在在AndroidManifest文件的<application标签的android:name属性改成自己的。为了防止云注入被破解，还对自己继承的这个原来作者的这个Application类名加密了。

3、解决办法：

根据上面的【原理分析】，
（1）我的解决方法：

0、把cloudinject目录删了（其实删不删都无所谓）。
1、寻找原来作者的Application类名
2、在AndroidManifest文件的\<application标签的android:name属性改回作者原来的

最后自己保存回编译重新签名安装（使用MT管理器都没啥问题）。

（2）MT论坛某大佬的解决办法：

0、不要删cloudinject目录（其实反倒是需要修改）。
1、寻找原来作者的Application类名
2、修改其中的继承自原作者Application类的子类改为空壳代码

也就是说，大佬的方法需要修改smali代码，但是不需要修改AndroidManifest的代码，稍微有点麻烦，但是可能在某种情况下有更好的作用，所以此处只是作一个记录扩展。个人推荐使用我的方法。

所以唯一的难点就是如何去寻找这个原来作者的Application类名，目前总结的部分方法如下：
（3）如何去寻找这个原来作者的Application类名:

1、通过解密的方式获取（MT大佬的方法，具体看文末，此处简单写出方法和工具）
	（1）通过分析smali代码，找到云注入的代码。然后复制A变量和app_id变量的值。
	（2）使用大佬的解密工具解密出类名。（此方法可行）
		工具可以去MT搜大佬的文章，获取链接。
		但是为了方便大家，我把自己保存的备份给你们。
2、通过MT的注入日志log来打印出来。
此方法感觉不简单，感兴趣的请自行尝试，此处我不做进一步探讨。

3、使用逆向中最常用的【算法助手】，使用其中的【Application监听】分析一下即可看到。但是此处需要lsp/xposed框架。

4、MT某大佬的方法

感兴趣的翻到文章末尾。

5 【算法助手】寻找作者的Application类名（路径）

我的解决办法：

然后就可以知道我们后面需要的原来的Application的类名``arm.StubApp了，记住她。如果使用我的办法，就直接去修改AndroidManifest的那个属性就行了，就不需要往下看了：

----------END分割线：如果你使用我的方法，就不需要往下看了--------

6 【使用MT-DL方法】找到云注入启动代码路径并修改

！注意：如果你使用我的方法，就不需要往下看了

找到云注入（cloudinject）的代码，

这里就放着云注入cloudinject所启动的代码。

7、修改这个类。

按照大佬的意思，就是改成空壳代码即可。
这里需要用到前面我们苦苦寻找的Application类名
【arm.StubApp】对应的smali代码写法是
【Larm/StubApp】前面加个L，点化成斜杠

修改模板：
.super L路径;// 修改处注意1
# direct methods
.method public constructor <init>()V    
    .registers 1    
    invoke-direct {p0}, L路径;-><init>()V    // 修改处注意2
    return-void
.end method

改成：

.class public Lcom/cloudinject/feature/App;

.super Larm/StubApp;
# direct methods
.method public constructor <init>()V    
    .registers 1    
    invoke-direct {p0}, Larm/StubApp;-><init>()V    
    return-void
.end method

如图：

然后保存退出重新签名即可。

因为替换成空壳代码，云注入就彻底没用了。

结束。

8 【最后】扩展：大佬的方法

如图（MT大佬分享的，感兴趣的朋友可以去大佬主页看看他其他文章）：