记一次某App反编译分析

每次寻找漏洞的时候，我都喜欢从抓包开始

噢噢，这里有点尴尬~~请求和返回的数据都进行了加密处理，这波操作我挺喜欢的，证明人家公司的开发人员还是有点安全意识的，不过没有关系，他有张良计,我有过墙梯，先反编译一波看看，使用的工具是 jadx

很明显，app用了360加固了，哎，在以前，有加固的应用我基本会放弃的，不过现在没关系，脱壳呗

我用的脱壳源码在这里 https://github.com/dstmath/frida-unpack

用了Firda进行脱壳，不会使用Frida的可以看这里 https://blog.csdn.net/u014476720/article/details/83537843 ，过程就不说了

脱了壳 拿到了dex文件就可以分析了

根据上面抓包的情况，分析app包无非就是解决 t ，sign , n , options 这几个值加密和解密

这里我先从请求的数据开始入手，直接先搞到登录接口的

看了一下代码，很好很漂亮，文件名很清晰，没有怎么进行混淆处理

密码的参数传入了下面的方法进行拼接

格式：固定文本+密码+固定文本  最后以这种格式进行了MD5加密

到这里分析了登录携带的参数后，苦逼了

登录需要的参数都传入了下面的a方法，他的网络请求框架是retrofit2，这种我不熟悉啊，之后不知道怎么跑了

后来看了看工具类里面还有个 EncryptDES ，好像都没有看到在哪里有用到，于是抱着试一试的心态进行了一番全局搜索

噢噢 这么一搜索不得了，网络请求的数据结构全部都在此

响应返回参数

上面需要的相关参数用Xposed框架编写个插件就可以全部输出知道了

编写插件的时候需要注意的几个传入类型： byte[].class ， int.class

因为是加固过的，所有直接hook是找不到路径的，需要先hook 加载过原dex 的 ClassLoader ，再用hook到的ClassLoader进行其他hook

 final Class clazz1 = XposedHelpers.findClass("android.app.Application", lpparam.classLoader);
            XposedHelpers.findAndHookMethod(clazz1, "attach", Context.class, new XC_MethodHook() {

                @Override
                protected void afterHookedMethod(MethodHookParam param) throws Throwable {
                    super.afterHookedMethod(param);
                    Context context = (Context) param.args[0];
                    ClassLoader classLoader = context.getClassLoader();
}

总结：分析了上面的app之后，我觉得做ndk开发还真是有必要的，重要的参数都放进C代码里面处理，即使那些算法想用java层的也不要用的那么明显，可以用jni来处理， native通过反射调取java层的方法，虽然还是能够破解，但是至少能够增加多一点破解的难度吧