恶意删库还能这样玩，太狠了！

背景

在交接的代码中做手脚进行删库等操作，之前只是网上听说的段子，没想到上周还真遇到了，并且亲自参与帮忙解决。

事情是这样的，一老板接手了一套系统，可能因为双方在交接时出现了什么不愉快的事情，对方不提供源代码，只是把生产环境的服务器打了一个镜像给到对方。

对方拿到镜像恢复之后，系统起来怎么也无法正常处理业务，于是就找到我帮忙看是什么原因。经过排查，原来交接的人在镜像中做了多处手脚，多处删除核心数据及jar包操作。下面来给大家细细分析排查过程。

排查过程

由于只提供了镜像文件，导致到底启动哪些服务都是问题。好在是Linux操作系统，镜像恢复之后，通过history命令可以查看曾经执行了哪些命令，能够找到都需要启动哪些服务。但服务启动之后，业务无法正常处理，很多业务都处于中间态。

原本系统是可以正常跑业务的，打个镜像之后再恢复就不可以了？这就奇怪了。于是对项目（jar包或war）文件进行排查，查看它们的修改时间。

在文件的修改时间上还真找到了一些问题，发现在打镜像的两个小时前，项目中一个多个项目底层依赖的jar包被修改过，另外还有两个class文件被修改过。

于是，就对它们进行了重点排查。首先反编译了那两个被修改过的class文件，在代码中找到了可疑的地方。

可疑代码

在两个被修改的类中都有上述代码。最开始没太留意这段代码，但直觉告诉我不太对，一个查询业务里面怎么可能出现删除操作呢？这太不符合常理了。

于是仔细阅读上述代码，发现上述红框中的代码无论何时执行最终的结果都是id=1。你是否看出来了？问题就出在三目表达式上，无论id是否为null，id被赋的值都是1。看到这里，也感慨对方是用心了。为了隐藏这个目的，前面写了那么多无用的代码。

但只有这个还不是什么问题，毕竟如果只是删除id为1的值，也只是删除了一条记录，影响范围应该有限。

紧接着反编译了被修改的jar包，依次去找上述删除方法的底层实现，看到如下代码：

删除操作

原来前面传递的id=1是为了配合where条件语句啊，当id=1被传递进来之后，就形成了where 1=1的条件语句。这个大家在mybatis中拼接多条件语句时经常用到。结果就是一旦执行了上述业务逻辑，就会触发删除T_QUART_DATA全表数据的操作。

而T_QUART_DATA表中是用于存储触发定时任务的表达式，到这里也就明白了，为啥前面的业务跑不起来，全部是中间态了。因为一旦在业务逻辑中触发开关，把定时任务的cron表达式全部删除，十多个定时任务全部歇菜，业务也就跑步起来了。

找到了问题的根源，解决起来就不是啥事了，由于没有源代码，稍微费劲的是只能把原项目整个反编译出来，然后将改修改地方进行了修改。

又起波折

本以为到此问题已经解决完毕了，没想到第二天又出现问题了，项目又跑不起来了。经过多方排查和定位，感觉还有定时任务再进行暗箱操作。

于是通过Linux的crontab命令查看是否有定时任务在执行，执行crontab -e或crontab -l，还真看到有三个定时任务在执行。跟踪到定时任务执行的脚本中，而且明目张胆的起名deleteXXX：

删除脚本

而在具体的脚本中，有如下执行操作：

删除核心依赖包

这下找到为什么项目中第二天为啥跑不起来了，原来Linux的定时任务将核心依赖包删除了，并且还会去重启服务。

为了搞破坏，真是煞费苦心啊。还好的是这个jar包在前一天已经反编译出来了，也算有了备份。

小结

原本以为程序员在代码中进行删库操作或做一些其他小手脚只是网络上的段子，大多数人出于职业操守或个人品质是不会做的。没想到这还真遇到了，而且对方为了隐藏删除操作，还做了一些小伪装，真的是煞费苦心啊。如果有这样的能力和心思，用在写出更优秀的代码或系统上或许更好。

当然，不知道他们在交接的过程中到底发生了什么，竟然用这样的方式对待昔日合作的伙伴。之所以写这篇文章，是想让大家学习如何排查代码问题的过程，毕竟用到了不少知识点和技能，但这并不是教大家如何去做手脚。无论怎样，最起码的职业操守还是要有的，这点不接受反驳。