最近下载了某直播应用,其中某些直播间需要收费才能观看如图所示:
看到这里,激起了我浓厚的兴趣,试图将其破解。
1. 查找切入点
首先使用jadx打开这个apk,运气很好没有加固,甚至没有混淆。
点击文件-另存为Gradle项目,就可以在Android Studio中打开了,这样使用顺手的IDE可以更方便查看。
当然,这个项目是不能通过编译的,但是可以方便我们接下来的修改。
根据开头的对话框提示,可以查找其中的字符串来找到弹出这个对话框的位置。全局查找“本房间为收费房间”,发现并没有结果。
再找“您可预览”,这次找到了。
可以看到,在2个类中出现了这个字符串,分别是com.yunbao.phonelive.presenter.CheckVideoListPresenter
和com.yunbao.phonelive.presenter.LiveRoomCheckLivePresenter
。没有混淆真的是太幸运了,根据类的名字就可以猜测出多半是第二个类,即LiveRoomCheckLivePresenter
中检测收费情况。打开这个类,并且找到这个提示出现的地方,分别是类成员mHandler
和方法payTips()
中。
首先看payTips()
方法。这个方法只在LiveAudienceActivity
中调用过。看到这里,推测这个应用是使用的MVP结构,在Presenter中处理业务逻辑,而LiveRoomCheckLivePresenter
和LiveAudienceActivity
分别就是P和V。
查看调用payTips()
方法的地方:
发现是在LiveAudienceActivity
的checkLive
方法中创建LiveRoomCheckLivePresenter
时,通过一个Listener的回调传入的。所以问题还是回到了LiveRoomCheckLivePresenter
这个类中。在LiveRoomCheckLivePresenter
中找到这个Listener,并查找其onLivePay回调的调用。顺藤摸瓜查找下去:
↑↑↑注意,这里很重要,通过服务器返回的json数据,获取直播间类型mLiveType,根据这个类型来判断是普通房间、收费房间还是密码房间。
而checkLive
方法是在LiveAudienceActivity
的onCreate
中就调用,即进入这个Activity之后,就会调用这个checkLive
方法。所以理一下逻辑:
LiveAudienceActivity#onCreate()
-> LiveAudienceActivity#checkLive() // 进入Activity,检查直播状态
-> LiveRoomCheckLivePresenter#checkLive() // 调用Presenter来处理业务逻辑
-> HttpCallback#onSuccess() // 向服务器请求当前直播间数据,通过请求到的判断是否收费
-> LiveRoomCheckLivePresenter#forwardPayRoom() // 当前直播间为收费房间,进入收费逻辑
-> mActionListener#onLivePay() // 当前直播间为收费房间,进入收费逻辑
-> LiveRoomCheckLivePresenter#payTips() // 弹出收费对话框
通过理清以上逻辑,不难看出,需要修改的地方就是HttpCallback了。只要在这个判断中,将收费房间变成普通房间即可。接下来就是喜闻乐见的改代码时间。
2. 修改目标代码
在1中已经知道了,在HttpCallback回调的switch判断中动一下手脚就能达到目的,看看源代码:
private HttpCallback mCheckLiveCallback = new HttpCallback() {
public void onSuccess(int code, String msg, String[] info) {
if (code != 0) {
ToastUtil.show(msg);
} else if (info.length > 0) {
JSONObject obj = JSON.parseObject(info[0]);
LiveRoomCheckLivePresenter.this.mLiveType = obj.getIntValue("type");
LiveRoomCheckLivePresenter.this.mLiveTypeVal = obj.getIntValue("type_val");
LiveRoomCheckLivePresenter.this.mLiveTypeMsg = obj.getString("type_msg");
switch (LiveRoomCheckLivePresenter.this.mLiveType) {
case 0:
LiveRoomCheckLivePresenter.this.forwardNormalRoom();
return;
case 1:
LiveRoomCheckLivePresenter.this.forwardPwdRoom();
return;
case 2:
case 3:
LiveRoomCheckLivePresenter.this.forwardPayRoom();
return;
default:
return;
}
}
}
public boolean showLoadingDialog() {
return true;
}
public Dialog createLoadingDialog() {
return DialogUitl.loadingDialog(LiveRoomCheckLivePresenter.this.mContext);
}
};
也就是说,在这个switch语句中
switch (LiveRoomCheckLivePresenter.this.mLiveType) {
case 0:
LiveRoomCheckLivePresenter.this.forwardNormalRoom();
return;
case 1:
LiveRoomCheckLivePresenter.this.forwardPwdRoom();
return;
case 2:
case 3:
LiveRoomCheckLivePresenter.this.forwardPayRoom();
return;
default:
return;
}
可以考虑以下几个方案:
- 将
forwardPayRoom
和forwardPwdRoom
替换为forwardNormalRoom
即可; - 或者直接去掉这段判断,直接调用
forwardNormalRoom
方法。 - 再或者,甚至可以修改
forwardPayRoom
的实现:
public void forwardPayRoom() {
forwardNormalRoom();
}
当然,异曲同工不提。
将apktool.jar和待分析的xml.apk放在同一文件夹下,执行java -jar apktool.jar d xml.apk
,apk被反编译为一堆smali文件。当然我是看不懂smali代码的,不过只用替换一下的话还是不难办到。找到名为LiveRoomCheckLivePresenter.smali的文件,使用notepad++打开。Ctrl+F查找“forwardPayRoom”,发现一共有两处:
显然,第一处是这个方法的定义,略过不看;第二处这里应该就是上面的switch语句了。虽然看不懂代码,但是可以看出上面三段几乎是一模一样的,对应了switch的三个条件;那么把下面调用forwardPayRoom
方法和forwardPwdRoom
方法的地方都改成forwardNormalRoom
不就行了吗?事实证明的确可行。
PS:事实上,mCheckLiveCallback作为一个匿名类实现,对应文件LiveRoomCheckLivePresenter$1.smali。其中包含了onSuccess方法的实现,有100多行。其中switch的部分大概如下:
可以看出,在switch的三种情况下面,分别调用了
LiveRoomCheckLivePresenter
的
access$300
、
access400
、
access$500
,即是LiveRoomCheckLivePresenter.smali中的那三个相似的方法。
3. 重新打包
修改保存之后,使用java -jar apktool.jar b xml
重新打包。然后进行签名即可。
Apktool重打包Apk详细介绍
将重新打包好的apk安装好,发现能够正常进入付费房间,并且之后不会弹出充值提示,说明修改成功。
4. 反思
本文示例了一个最基本最简单的静态反编译重打包的例子。作为开发者,如何避免自己开发的应用被破解,或者使破解的成本大大增加?这是一个很大的话题,完全能够写一本书出来了。不过一些最基本的东西也是很有效的,如果能够做到也算是加了多层保险了:
- 混淆
- 加固
- NDK
- 敏感操作的字符串替代
- 检查签名
- ……
能够做到这些,虽不能保固若金汤,但也能让相当一部分的破解者也只能望而却步了。