混淆器和技术支持
我们正在考虑在向客户发布之前混淆一些代码。我们想知道这会对技术支持产生什么影响。客户能否向我们提供有意义的堆栈跟踪，或者它们也会被混淆吗？
我期待听到您的经历。提前致谢。
We are thinking about obfuscating some code before releasing it to customers. We are wondering about the impact it will that have on tech support. Can customers provide us with meaningful stack traces or will they be obfuscated too?
I look forward to hearing about your experience. Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你会得到混淆的堆栈跟踪。但是混淆器可以生成将混淆名称映射到真实姓名的映射文件。您必须将这些映射文件保存在安全的地方，并且可以在需要时使用它们再次“反混淆”堆栈跟踪。
对于技术支持 - 您可以创建一个简单的 Web 界面，技术支持人员可以在其中粘贴堆栈跟踪。这样，只有 Web 服务器需要访问映射文件，以便它可以恢复原始堆栈跟踪。
这里有两个链接解释了 dotfuscator 混淆器的过程：
http://www .preemptive.com/images/stories/dotfuscator_documentation/Dotfuscator/The_Map_File.html
http://www.preemptive.com/images/stories/dotfuscator_documentation/Dotfuscator/Decoding_Obfuscated_Stack_Traces.html
you will get obfuscated stack traces. but obfuscators can generate mapping files that map obfuscated names to real names.. you have to keep these mapping files in a safe place and you can use them to "deobfuscate" the stack traces again when required.
in the case of tech support - you could create a simple web interface where tech support people can paste stack traces. that way only the web server needs access to the mapping files so it can restore the original stack traces.
here are two links explaining the process with the dotfuscator obfuscator:
http://www.preemptive.com/images/stories/dotfuscator_documentation/Dotfuscator/The_Map_File.html
http://www.preemptive.com/images/stories/dotfuscator_documentation/Dotfuscator/Decoding_Obfuscated_Stack_Traces.html
如果堆栈上的方法在您的版本中被混淆，您将在任何堆栈跟踪中获得混淆的方法名称。
如果您在代码中添加任何内容来帮助您找出所涉及的方法，潜在的黑客就可以使用该信息来更好地理解您的代码。
一种常见的策略是仅混淆部分代码，包括（但不限于）进行许可证检查的部分。如果您仅混淆许可证检查，则很容易将需要黑客注意的部分归零。
If the methods on the stack are obfuscated in your release, you will get the obfuscated method names in any stack trace.
If you put anything into your code to help you figure out what methods were involved, potential hackers can use that information to gain a better understanding of your code.
One common strategy is to obfuscate only some of the code, including (but not limited to) the parts that do license checking. If you obfuscate JUST the license checks, it's pretty easy to zero in on the part that needs a hacker's attention.
这通常不是问题，因为大多数混淆器都提供将堆栈跟踪反混淆回其原始跟踪的能力。
This is not usually an issue since most obfuscators provide ability to de-obfuscate stack traces back to their original trace.
我们使用 BitHelmet。问题是，当使用最强的混淆技术时，堆栈跟踪无法被反混淆。 BitHelmet 使用完整签名重命名（某种过载感应，只会更好）。所发生的情况是，许多方法最终具有相同的名称但具有不同的返回类型（这在 C# 中无法完成，但对于 CLR 来说是可以的）。返回类型不会显示在堆栈跟踪中！因此实际上不可能使用最强的混淆来反混淆堆栈跟踪。
我们问了与您相同的问题，我们进行了讨论，并得出的结论是，实际上我们更喜欢更好的混淆。在提供技术支持时，堆栈跟踪实际上不如只有最终用户可以提供的其他一些数据那么有用。 “请告诉我你到底在做什么？？？” :)
We use BitHelmet. Problem is, when using strongest obfuscation technique, stack trace can not be deobfuscated. BitHelmet uses Full Signature renaming (some kind of overload induction, only better). What happens is, lots of methods end up with the same name but with different return type (this cannot be done in C#, but it is ok for the CLR). Return types are not shown in stack traces! so it is actually not possible to deobfuscate stack trace using strongest obfuscation.
We asked the same question than you did, we discussed it and we reached to the conclusion that actually we prefer the better obfuscation. Stack traces are actually not so useful when providing tech support as some other data that only the final user can provide. "please tell me exactly what you were you doing???" :)