『贝壳找房APP』反编译到底有多简单--反编译和调试实践

最新推荐文章于 2024-04-05 11:16:57 发布

weixin_34015566

最新推荐文章于 2024-04-05 11:16:57 发布

阅读量1k

点赞数 1

文章标签： java 嵌入式移动开发

原文链接：https://yq.aliyun.com/articles/638429

版权

最近，在朋友圈看到有人发贝壳找房在Appstore上的下载排行榜，已进入前三。于是，我在应用宝上下载了贝壳release apk。

点击此处下载贝壳找房Apk
点击此处下载反编译debug包

Apk存在的漏洞

下面进入正题，一文让你知道反编译贝壳APP到底有多简单！

首先下载上方链接的贝壳Apk，接下来进入简单的反编译工作！反编译技术请参考此处简书或个人博客。先上图，反编译并重新打debug包（可动态调试smali），修改string.xml的app_name和闪屏的背景（加上了博客地址，博客域名目前已改为gavinme.com），这里的修改很简单，只是为了演示重打包步骤。

dec-icon.png

dec-闪屏.png

备注，这也许是我见过的最容易反编译的apk（在top榜的app中）。值得注意的是（仅个人观点），贝壳apk有以下特点：

没加壳，无脱壳难度，不过市面上业务型有下载量的加壳的也是极少。
没有防apktool逆向，可使用apktool d命令反编译smali和xml，可直接修改xml达到debug的目的。这点支付宝和微信都针对apktool漏洞有做过处理。
apktool可重新打包，在修改debug后，就可以随意调试。可以修改任意代码，插入广告，甚至植入木马，前提是这个APP值得你去这么做。
没有防调试装置，比如签名校验、调试进程占坑、轮询等待调试状态，进程TracerPid等，反正都没有。
https明文传输。未校验根证书，可以轻易地通过代理抓包。不要认为有https就真的安全了，隐私信息要加密。
混淆的粒度太粗，没有开启混淆优化等，后面会详述。

当然，深究的话当然不止这些。不过已经能够反编译smali，可调试，可插桩，可植入，可dump，还要啥自行车呢！这对有些人来说已经是源码了（比如我- -！）。

以下为一些反编译截图。

调试smali，查看内存中信息：

动态调试贝壳app.png

代理抓包，所有的请求参数和响应：

代理抓包.png
重编译debug包通过logcat查看开发者日志：

通过logcat查看日志.png

反编译步骤

由于目标apk的安全性较低，步骤很简单：

通过apktool d反编译得到smali和AndroidManifest.xml文件
修改xml中application属性android:debuggable="true"
修改smali代码（如果你需要），重打包得到新的签名debug包

通过以上的步骤，就可以通过logcat查看各种敏感和打点信息了，当然也可以通过idea断点进行调试了。

Apk包分析

下面进行贝壳Apk包分析，因为代码价值的局限性，没有花过多时间分析。

反编译结构.png

Apk release包约50M，相对来说非常大，资源文件和asset占很大量。采用多dex打包，考虑到版本的问题（v1.4.2），这样的包大小已经远超出控制范围了。部分代码采用了kotlin编写。

贝壳包分析.png

第三方：x5（使用了x5webview内核，MTT）butterknife（注入框架）、in.srain.cube.views.ptr（cube SDK下拉和加载更多的框架）、io.fabric.sdk.android（api、统计）、okhttp3、okio、greenrobot、fastJson、pl.droidsonroids.gif、retrofit2、rx、tencent.tls、cn.shuzilm.core、picasso、igexin（推送）nineoldandroids、orhanobut.logger、com.zhy.adapter.recyclerview不一一列举
业务：由于第三开源代码（源码级拷贝）较多，所以业务代码占比较少，同时很难看出架构的影子。网络采用了retrofit+okhttp，我不认为开源的网络会完全符合需求（因为我们项目就不是- -）。
插件化：贝壳的插件化采用的是360一样hook和占坑的方式，在im和账户页做了部分工作。

总体来说，贝壳是一个业务快速增长的APP，基于链家的背景，通过业务和产品定位不难带动用户的增长。但是通过APP的分析可以看出技术上的一些问题。值得一提的是，通过查看apktool.yml查看：

sdkInfo:
  minSdkVersion: '19'
  targetSdkVersion: '21'

最低版本为19，但是却存在大量的低版本兼容库如nineoldandroids（兼容至level 9），加上大量冗余代码和未开起混淆优化（优化不使用的代码）导致包很大。
targetSdkVersion为21而不是23以上，或许是为了避免使用动态权限申请获取一些系统信息imei，mac，deviceId等。
值得注意的，cn.shuzilm.core（官网https://www.shuzilm.cn）是给设备提供反作弊和反调试的一站式解决方案的SDK。然而，反调试并没有开启（即使开启了通过修改代码也很容易绕过去）。或许是为了借助第三方获（这一点能看出贝壳移动端对技术的不自信）取更为真实的设备信息，虽然可以防xpose的java层hook，然而修改代码重新打包依然可以进行欺骗。其实，这一类重要信息通过第三方获取本身就是非安全的。