我的一次十四小时极限黑盒调试经历

imiskolee 2019-11-15 01:35:17
原文地址:https://segmentfault.com/a/1190000020853515

十四小时极限调试挑战 - 流水账


背景

本文以流水线的方式记录了一次难以忘怀的调试经历。

过程

2019-10-29 13:02 分

接到紧急报告,某商业软件在解析特定数据格式时候出现故障,需要立即解决。而无法联系到供应商。

2019-10-29 13:20 分

开始进行问题复现。

2019-10-29 14:26 分

问题复现成功,打开debug级别日志,希望从日志中找出线索。

2019-10-29 14:40 分

日志没有记录到更有效的信息,开始对程序安装目录进行结构分析。

2019-10-29 15:30 分

基本完成对程序的分析,主要使用Java和so进行链接,由于程序是非常模块化的,基本可以定位到某几个Jar包有Bug.

2019-10-29 15:50 分

从Jar包的名称中发现在一个关键位置可能是引入了一个开源库,通过Google 找到该项目源码,希望通过修改这个库以避免这个Bug。

2019-10-29 17:10 分

第一个版本的修改版完成,尝试替换,解决了一定的问题,缩小了问题发生几率,但仍旧没有实际的进展。

2019-10-29 19:00 分

吃了个晚餐。

2019-10-29 19:20 分

经过两个小时的奋战,基本宣告这个方案失败,开始预备尝试对某个私有内部JAR包进行修改的方案。

2019-10-29 21:30 分

通过JBE将JAR包进行反编译,开始尝试直接修改Class文件。

2019-10-29 22:30 分

完成了Class文件修改版,进行替换后无法正常工作,造成了运行时的直接崩溃。

2019-10-29 22:50 分

喝了一杯焦糖加浓美式。

2019-10-29 23:10 分

通过上一个步骤对Jar的反编译已经发现源码没有进行加密与混淆,开始将整个JAR包进行反编译得到源代码,并且直接将该程序的所有JAR包都纳入lib中,开始直接编译。

2019-10-30 01:15 分

项目构成完成,解决了源代码中的一些问题,对代码进行非破坏性的增加日志。上线一个版本。

2019-10-30 01:30 分

拿到更完整的日志,进行日志分析。对代码进行保护性调整,进行了多次Debug。

2019-10-30 02:20 分

基本宣告调试完成,进行完整验证。在验证过程中,发现有部分逻辑遗漏。

2019-10-30 03:20 分

完成了最终版本,调试通过。

2019-10-30 03:30 分

正式投入使用,替代旧版程序。将整个问题Email复现给了供应商。

2019-10-30 04:00 分

记录下来了这次难得可贵的经历。

声明:该文章系转载,转载该文章的目的在于更广泛的传递信息,并不代表本网站赞同其观点,文章内容仅供参考。

本站是一个个人学习和交流平台,网站上部分文章为网站管理员和网友从相关媒体转载而来,并不用于任何商业目的,内容为作者个人观点, 并不代表本网站赞同其观点和对其真实性负责。

我们已经尽可能的对作者和来源进行了通告,但是可能由于能力有限或疏忽,导致作者和来源有误,亦可能您并不期望您的作品在我们的网站上发布。我们为这些问题向您致歉,如果您在我站上发现此类问题,请及时联系我们,我们将根据您的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。