转储为黑客提供了太多信息来逆向工程或破解软件，比如启用功能或许可证？

在某些时候，转储必须以未加密的形式存在。具有完全本地控制权的攻击者可以在那一刻抓取转储文件 - 或者干脆忽略它们，并随意查看正在运行的应用程序的内存。

有些程序，例如 spotify，会尝试检测它们是否在调试环境中运行，并使用各种混淆方案来减慢逆向工程的速度。这可能会阻止没有经验的攻击者，或减慢有经验的攻击者。但它可能不会阻止攻击者。这基本上是微软等公司选择在线许可证验证的原因。

但是，传输中的加密是完全不同的事情。保护可能在转储中可用的客户资产，甚至是安装在客户计算机上的许可证，这是一个很好的建议——确保没有第三方可以访问转储。

它也很容易实现；提交转储例如 https。虽然由此获得的收益可能很小，但取决于转储的内容，实施起来也非常便宜，并降低了您和客户数​​据的风险。请记住，您的客户可能更重视他们的数据，而不是他们对您的产品的重视。

用户可能会向我们返回一个恶意格式错误的转储，当我们试图破译我们机器上的转储时会造成严重破坏。如果我们的应用程序对转储进行签名，至少我们可以自信地打开文件。

要签署文件，应用程序必须访问私钥。私钥必须存在于在某个阶段进行签名的机器的内存中。它必须与软件的每个实例一起分发。

攻击者可以访问密钥并签署他的恶意转储文件。

它无助于将转储用作攻击媒介。

[...] 我的故障转储 [...] 是否应该加密和签名？

有人可以使用各种工具创建任意数量的故障转储，例如任务管理器、进程资源管理器、ProcDump、WinDbg、Visual Studio、DebugDiag、WER、AdPlus（可能还有更多），而您没有机会拦截这些转储。攻击者不会使用您加密的 Breakpad 故障转储，而是创建自己的常规故障转储。

但是，您应确保遵守隐私法规并确保只有授权人员才能访问故障转储。在这种情况下，加密可能会有所帮助，但任何其他访问控制也可以。

转储为黑客提供了太多信息来逆向工程或破解软件，比如启用功能或许可证？

应用程序的实时实例提供了更多信息。可以这样想：您可以创建许多故障转储，因此您有更多信息要分析。

另外：您知道您可以影响故障转储的大小吗？根据MINIDUMP_TYPE选项，故障转储包含或多或少的信息。

用户可能会向我们返回一个恶意格式错误的转储，当我们试图破译我们机器上的转储时会造成严重破坏。

你的这些可能，但不太可能。在任何其他应用程序中，这将是调试器中与安全相关的错误。调试器只会从故障转储中读取信息，而不是执行它。

攻击者如何在不表明身份的情况下向您发送故障转储？

我个人的看法是，这将取决于您的成本/收益。

对文件进行数字签名是的。它将减少工作量，并允许您从真正的客户那里接收转储。对于信息的传输是的。您应该使用加密通道，如果不可能，它们会加密数据。 我相信使用 https 来交付它比尝试对可能失败的数据实施某种加密方法更容易。

在当地，这将取决于景观。

通常，默认情况下不应允许转储，并且仅应启用转储以解决生产服务器上的特定问题。

启用后，建议为转储配置特定分区，并允许特权用户访问该分区，并且永远不要将转储数据留在系统中，一旦生成它就应该从生产环境中移动分析。

在这种情况下，它是受控的，在这里实施加密不会增加任何真正的好处。

如果您有某种类型的自动化来生成转储并将它们交付给您的组织，那么我会说是的，如果转储可能包含 PII 数据，您必须特别在任何地方实施加密......未删除或覆盖的静止转储是一个很好的选择有关服务器上正在运行的内容的信息来源。

这不是最佳实践，因为生产服务器应该禁用 DUMPS 并且也禁用 DEBUG。仅在需要时才应启用此功能，并且某些系统管理员会对其进行实时监控。

加密会带来一些挑战，而这些挑战会让您花钱。

PKI infra：如果您拥有私钥，那么除非您共享密钥，否则您的任何客户都不会被允许在本地访问数据。

如果您希望让您的客户拥有私钥来访问他们的本地转储，那么您将输入一个可能很耗时的密钥管理问题，因为您必须为每个客户生成一个私钥。

撤销密钥将需要您所有客户的应用程序更新...

同步密钥：没有多大意义，因为密钥必须存在于系统中的某个位置以允许对数据进行加密。

更改密钥也将是一项挑战和耗时。