最近，在朋友圈看到有人发贝壳找房在Appstore上的下载排行榜，已进入前三。于是，我在应用宝上下载了贝壳release apk。
Apk存在的漏洞
下面进入正题，一文让你知道反编译贝壳APP到底有多简单！
首先下载上方链接的贝壳Apk，接下来进入简单的反编译工作！反编译技术请参考此处简书或个人博客。先上图，反编译并重新打debug包（可动态调试smali），修改string.xml的app_name和闪屏的背景（加上了博客地址，博客域名目前已改为gavinme.com），这里的修改很简单，只是为了演示重打包步骤。
备注，这也许是我见过的最容易反编译的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包分析，因为代码价值的局限性，没有花过多时间分析。
Apk release包约50M，相对来说非常大，资源文件和asset占很大量。采用多dex打包，考虑到版本的问题（v1.4.2），这样的包大小已经远超出控制范围了。部分代码采用了kotlin编写。
第三方：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，然而修改代码重新打包依然可以进行欺骗。其实，这一类重要信息通过第三方获取本身就是非安全的。
总结
贝壳本身没有什么安全机制，所以很容易破解。但是出于做平台的目的，数据和代码安全显得尤为重要（反数据抓取）。从这个角度，它离平台级APP还有一定的距离。
