沉沦代挂是一款适用于《沉沦》游戏的辅助工具,它可以帮助玩家在游戏中获得优势。此前,该软件的源码被泄露,导致许多玩家使用非法修改后的版本。官方团队已修复了源码中的漏洞,并更新了软件版本。
原因
沉沦代挂源码泄露的原因尚不清楚,但可能是由于以下原因之一:
- 开发者的疏忽
- 恶意黑客的攻击
- 内部人员的泄露
后果
沉沦代挂源码泄露导致了许多负面后果,包括:
- 非法修改版本在玩家中广泛传播
- 游戏平衡遭到破坏
- 玩家的账户安全受到威胁
修复
官方团队已修复了源码中的漏洞,并更新了软件版本。新版本修复了允许非法修改版本在玩家中传播的漏洞。官方团队还加强了安全措施,以防止类似事件再次发生。
预防
为了防止类似事件再次发生,玩家应采取以下预防措施:
- 仅从官方网站下载沉沦代挂
- 定期更新软件
- 使用强密码并启用双重认证
结论
沉沦代挂源码泄露是一个严重的问题,但官方团队已采取快速行动来修复漏洞。玩家应采取预防措施以保护自己的账户并维护游戏的平衡。
热修复Tinker(二)补丁包加载源码分析
前面一篇Tinker相关的文章已经介绍了Tinker热修复框架的使用与整个的修复流程,那么这一篇就要开启Tinker的源码解析之路了。
首先简单说一下Tinker的原理,Tinker其实也是类似multidex的dex方式,将目标dex插入到数组最前面,主要是通过对比原dex文件(存在bug)与现dex文件(bug已修复)生成差异包,生成的差异包作为补丁包下发给客户端,客户端做一系列校验之后,将下发的差异包与本应用的dex文件合并成成全量的dex文件,并进行opt优化,当再次启动APP时候则加载优化过的全量dex文件,将dex文件插入到DexPathList 中 dexElements的前面。
所以Tinker其实是两个流程,一个是加载补丁包,另外一个是加载dex文件,两个的加载流程相对较长,这里分开说明,这一篇呢,主要介绍加载补丁包的流程。
加载补丁包的方法如下
往下看发现调用了TinkerInstaller的onReceiveUpgradePatch方法
这里调用了PatchListener的onPatchReceived方法
而PatchListener是一个接口,他的具体实现为SamplePatchListener方法,onPatchReceived在SamplePatchListener的父类DefaultPatchListener有实现,我们看下DefaultPatchListener中的onPatchReceived方法 如下
首先这个检测了一下这个插件是否可用,通过SamplePatchListener的patchCheck方法来检测
这里对插件是否可用进行了判断,就不进行详细分析了
当插件可用时候returnCode为ERROR_PATCH_OK,当不可用则会log出来失败的errorcode
成功则调用
来启动TinkerPatchService这个IntentService,并且把插件的路径给传递到IntentService
TinkerPatchService通过onHandleIntent来接收传递过来的数据
这里首先调用了PatchReporter的onPatchServiceStart方法,而PatchReporter的实现为SamplePatchReporter
这里主要看UpgradePatchRetry的onPatchServiceStart方法
这里主要也做了一些验证,并且把文件复制一份到/data/data//tinker_temp/路径下,然后把相关信息写入到配置文件中
在回到TinkerPatchService的onHandleIntent方法
主要看
这个方法的实现在UpgradePatch中
这里首先初始化相关数据与相关验证,再将补丁文件拷贝到目标目录中
路径为/data/data//tinker/patch-xxxxxx/
接下来就是调用DexDiffPatchInternal,BsDiffPatchInternal,ResDiffPatchInternal这些类的方法进行dexDiff差分的计算相关
至于相关差分的计算,由于比较复杂,我暂时还没有深入去看,暂时埋个坑在这里,等后面找时间去填上这个坑
在回到TinkerPatchService的onHandleIntent方法
后面调用了PatchReporter的onPatchResult,这个方法主要删除了上面拷贝在/data/data//tinker_temp/的文件
接下来启动了AbstractResultService,并把插件的路径传递过去了
AbstractResultService的实现在SampleResultService类里面,SampleResultService的onPatchResult删除了原始的插件文件。
到这里插件加载分析就基本结束了
插件加载分析结束了,但是却没有去分析dexDiff差分的计算,而这个dexDiff差分计算则是区分的Tinker与其他相同方案的热修复库,dexDiff是基于 Dex 的文件结构来下手,将产生变化的结构提取出来,产生的补丁非常小,而且在 diff 的过程中也处理了一些会造成补丁包很大的场景,所以等后面有时间将这一块补上,下一篇文章则是对dex文件加载进行源码分析了,peace~~~