.net反编译器的局限性

因此，我的雇主有一个旧的.NET/C程序，需要重写，其源代码已经丢失。它是由一位前雇员开发的，但他们已经好几年没来这里了。可能是他们的疏忽，也可能不是——在这一点上，这并不重要

不管怎样，我正试图弄清楚它的作用，这让我开始思考.NET反编译器的局限性

尝试反编译.NET是否像尝试使缩小的js文件可读？使用缩小的js，您可以将代码缩进一些预先确定的编码标准，您可以重命名变量，以匹配为其赋值的函数的名称，但您仍然会丢失大量信息。您将丢失实际的变量名和开发人员所做的任何注释

这是一个公平的类比吗

---

这似乎是我的情况，或者开发人员没有留下任何评论，他确实根据变量的类型而不是应用程序命名了一半的变量（我想这与匈牙利语系统一致）。

注意：我所说的大部分是基于Java的，但据我所知，CLR的运行方式基本相同

基本上，它的工作方式是编译器将源代码转换为字节码格式，然后由VM执行。一般来说，编译器不会费心优化它们生成的代码，因为无论如何VM都会在运行时对其进行优化。因此，如果代码是由标准编译器编译的，并且没有混淆，那么字节码的转换是非常直接和可预测的，这意味着您可以将其反编译为外观合理的源代码

然而，你仍然会失去任何基本上是语法糖的东西。编译器将只包含执行所需的内容。幸运的是，反射支持（以及调试，如果启用）意味着很多源代码级别的信息将保留在字节码中，可能是通过可选的元数据。但是像空白和注释这样的东西即使通过反射也无法访问，所以无法恢复它们

与缩小JS的类比并不精确，但仍然有用。在Javascript的情况下，源文件是VM的输入，因此没有可见的中间字节码阶段。缩小是优化器检查并重新格式化源代码的结果，但它仍然是源代码。另一方面，在这两种情况下，丢失的信息都是由于执行时没有必要使用工具而无法保存的结果

---

如果这些文件被混淆了，那么所有这些都会消失。混淆器故意弄乱编译器引入的模式，并将删除所有可选的元数据。您通常仍然可以反编译模糊的代码，但这将是一个混乱，并且不包含原始源代码的有用信息，例如格式和变量名。

局部变量名不是反射所必需的，因此它们会被丢弃。事实上，在字节码级别上没有实际的局部变量，只有堆栈位置。评论也一样-它们不会被保留

---

您可以使用MSIL反汇编程序（Ildasm.exe）查看可执行文件中实际保留的内容。名称strNN等由反编译器生成，试图帮助您恢复代码的逻辑。

您知道二进制文件是否被混淆了吗？您做了什么让您的老板如此讨厌您，以至于他给了您这个项目？有总比没有好。你为什么不试试？上的免费版本显示了一些非常干净的代码。@bum-我就是这么尝试的。它看起来做得很好，但我有六个变量匹配正则表达式“str\d”。即str1、str2、…、str6。然后我有一堆num1，num2，…，numx的东西。在某些情况下，它似乎是从.NET API调用中派生出来的名称。@Brian-我真的没有办法知道lol，但我很冒险地猜测不是。