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

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

---

背景

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

过程

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 分

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