混淆可能看起来是显而易见的第一步，但混淆必须保护代码中的某些内容，并且某些内容不能成为 Web 服务功能，因为即使流量经过 SSL 加密，也会通过拦截流量进行逆向工程。证书固定可以通过信任预定义的证书来防止简单的 SSL 拦截。

您可以对称地加密通信数据并将密钥存储在客户端中，然后使用混淆来使对该密钥和加密算法的访问更加困难。您还可以通过使反编译更加困难来保护混淆。Flash 混淆器和反反编译器的一个示例是SWFencrypt和BISguard。

前面是静态源代码保护，但它们不能防范实时/动态攻击。防止这些攻击的一种方法是让客户端对内存和资源使用完整性检查。还有一些反逆向工程技术可以使实时调试更加困难。

防止实时攻击的另一种方法是使用软件来查找可能用于客户端软件篡改的任何系统篡改。这是类似 rootkit 的反作弊引擎的领域，例如 Punkbuster、魔兽争霸的 Warden 和 Valve 的 VAC。

另一种保护是在 iOS 和 Android 等封闭平台上的代码签名和内存签名（一直到内存页面）。这样，您可以限制对客户端二进制文件的静态修改和对其内存和操作系统的动态修改。

即使是旧的 CAPTCHA 也可以用作自动化保护，但它会损害用户友好性。您还可以通过用户行为和使用模式检测服务器上的自动化，然后将其与 CAPTCHA 结合以减少误报。

除了技术保护之外，您还可以通过法律手段甚至激励措施来使用。提供最好的客户端，这样用户就不会倾向于破解您的客户端或编写自己的客户端。或者让自定义或被黑客户端不会给黑客带来更大的优势。法律手段不是我的强项，并且会因国家/地区而异，但我听说过有关逆向工程的诉讼。法律威胁可能会阻止公司和个人出售或提供定制客户。

最后，您可以扭转整个问题，通过灵活的 API 轻松访问 Web 服务，并防止服务器上的滥用。您还可以为黑客渴望的高级功能收取少量费用。:)

从根本上说，您无法保护您的客户。充其量你可以模糊和混淆，以使攻击者更难修改客户端。

您提到这不是安全问题，因为服务器得到了适当的保护，而只是一个烦恼。试图掩盖你的客户端可能比让一些修改过的客户端发出被服务器拒绝的错误请求更烦人。

这实际上取决于您的威胁模型。在我工作过的大多数客户端中，我没有为任何模糊或混淆而烦恼，因为服务器是完全安全的，修改客户端不会有任何收获。

现在，如果我们谈论的是尝试保护客户本身（即出于 IP 问题，您不希望有人窃取客户），花时间让这件事难以完成可能更有意义（同时仍然牢记你将永远无法完全保护客户端 - 充其量你可以让没有动机的攻击者放弃并延迟有动机的攻击者）。

没有任何。如果他们不反编译您的应用程序，他们只会将其通过具有自己的 SSL 证书的代理。您的客户端无法为您的后端提供安全性。

您将采取哪些措施来限制人们篡改您的客户端软件的风险？

这里有一个只有你才能衡量的平衡。假设您的保护不会打扰有效用户，那么您只需要平衡保护软件的价值与攻击者破坏保护的价值。

如果您谈论的是不是很昂贵的软件或服务，并且客户不是那种超越简单手段的类型，那么混淆可能就足够了。

如果您谈论的服务或软件要么非常昂贵，要么如果被滥用会很有价值，并且客户决定将服务与他们自己的软件一起使用，那么您将不得不使用更严格的手段。

在第一种情况下，工具已经存在。

在第二种情况下，最好的选择是使用 Adob​​e Air，它允许签名的应用程序不在浏览器中运行。您可以使用公钥密码术来验证您正在 1) 与您的应用程序对话以及 2) 应用程序没有被更改。如果您必须阻止非常勤奋的攻击者（老实说，没有什么是绝对无法攻破的），这很复杂，但是通过精心设计和频繁的强制更新，您可以通过简单地进行大量攻击来消除大多数攻击。