一次反编译和注入进程调试经历带来的问题和思考

前情提要

接手了一个来自公司外部的support case。我们的公司也卖软件，然后这个公司外部的case就是我们自家的软件在外部用户的机器上的某个功能报错。由于报错的信息提供的非常有限，软件支持部门向我们IT部门求救希望我们能帮忙看一下。简单开个会和软件支持人员通个气，并且让支持人员创建一个给我们试用的软件License让我们先试试看。
对，没错。一听说这个程序的框架是C#的，一个曾经的程序员（我明锐的直觉告诉我，当一个基于C#编写的程序不仅没有参数可以打开log排错并且软件功能报错没throw Exception的时候，你就要使用非正常的手段去查问题了，也就是标题中说到的反编译(Decompile)和注入进程调试(Debug via process injection)。
结果，一个在软件支持部门很长时间没有解决的这个case，我通过上述的两种手段只花了两个小时就解决了。
当然，需要指出的是，软件功能的报错信息和软件出现错误的问题根源完全没有关系。
当一个软件功能的报错信息和问题根源没有关系的时候，你对这个问题的思考将会“从一开始就是错的”。
在向上级回报这个事件的情况的时候，上级了解到我使用的方法暴露了程序内部的结构，提出了一些担忧。
这些担忧，在我写代码的时候（这已经是很久远的事情了）就已经出现过。

其实最简单的担忧：对有专利，需要授权的软件和软件的任一部分进行逆向工程（包括但不限于反编译，调试，篡改功能）是否合规？

这是一个灰色地带。

中国刑法规定的关于计算机犯罪的具体罪名中，上述操作可以触发刑法第285条，非法侵入计算机信息系统罪的第二款：

违反国家规定，侵入除国家事务、国防建设、尖端科学技术领域以外的计算机信息系统或者采用其他技术手段，获取该计算机信息系统中存储、处理或者传输的数据，或者对该计算机信息系统实施非法控制，情节严重的，处三年以下有期徒刑或者拘役，并处或者单处罚金；情节特别严重的，处三年以上七年以下有期徒刑，并处罚金。

案件判例：传送门

根据我国《计算机软件保护条例》和美国的《美国版权局版权法关于计算机程序登记的实际规范》都明确规定计算机程序包括目标代码和源代码两种表达形式，将源程序编译或者汇编成目标程序，源代码和目标代码一一对应的关系；将目标代码反编译或者反汇编成源程序，无论进行多少次结果都是一样的，虽然反编译或者反汇编形成的源代码和真正的原始源代码还是有很大区别的，但是目标代码和结果源代码也是一一对应的关系。在著作权法上，只有复制行为才可以实现一对一的关系，目标代码反编译或者反汇编成源程序是一种复制行为，那么未经他人允许对他人合法软件进行反向工程研究构成对复制权的侵权行为。

节选自知乎

思考🤔

对于这次的case，之前的担忧变成：

当公司内部员工为了解决自己所在公司软件的技术问题对软件和软件的任一部分进行逆向工程（包括但不限于反编译，调试，篡改功能）是否合规？

因为我的逆向工程是通过远程完成的，外部客户是可以看到我进行逆向操作的过程的。所以这个操作并不合规。

但是先前提到了，软件功能的报错信息和软件出现错误的问题根源完全没有关系。也就是说，作为技术支持，如果你不在外部客户的机器上进行调试查出问题根源，这个问题能被解决的概率无限接近于0，也就是完全碰运气了。

这个锅需要程序员背么？要的。尤其是我遇到的这个案例，只有这个问题根源的Exception没有被软件的错误收集（Error Reporting）模块记录，其他的Exception都能够在这个软件的错误收集模块显示。既然这个软件有错误收集模块，为什么会有错误不被这个模块收集并报出一条和这个错误完全没关系的错误信息？

其实定罪定罚的标准很简单，你的动机(Motivation)。

我的上级有担心用户看到这个修复操作，以后把License模块给逆向工程了，我恰恰不担心这一点。原因很简单，要是出现这个情况被发现，这个问题不需要我们的软件支持部门出手，而是我们的Legal部门出手。这种以损害软件出售方利益的逆向工程，动机不纯。

我为了解决用户的软件使用问题对这个软件的出现错误的模块给逆向工程了，并且最后提出解决方案解决了问题，保证软件服务质量和SLA，保护了软件出售方和使用方利益的逆向工程，这就非常的安全。

结语

你管这个叫日记？😂

我也没啥好记的了。

晚安。