嘿，针对你的两个问题，我来分享一些实际开发中常用的方案和思路：

没有100%绝对安全的方案，但可以通过多层验证大幅降低伪造请求的概率，常用的方法有这些：

• API密钥+请求签名机制
  给你的C#程序嵌入一个仅你知道的密钥，每次请求API时，用这个密钥对请求的关键参数（比如请求路径、时间戳、请求体哈希）生成HMACSHA256之类的签名，把签名和时间戳一起放到请求头里。API端收到请求后，先检查时间戳是否在有效窗口（比如5分钟）内防止重放攻击，再用相同的密钥和参数重新计算签名，和请求头里的签名对比，一致才处理请求。
  注意：密钥要硬编码在程序里的话，最好结合代码混淆，降低被逆向提取的概率，但还是要做好心理准备——没有绝对防提取的方法。

• TLS客户端证书验证
  生成一张客户端证书，把证书（带私钥）嵌入到你的C#程序中（可以加密存储，运行时解密加载）。API服务器配置为仅接受携带有效客户端证书的请求，并且验证证书的颁发者、有效期等信息。这种方式比单纯的API密钥更安全，因为私钥很难被逆向提取（只要你存储得当）。

• 程序特征指纹校验
  让你的C#程序在请求时带上一些只有原版程序才会生成的特征，比如程序的文件哈希（可以在运行时计算自身程序集的哈希），API端对这些特征进行校验。不过这种方法的可靠性较低，因为攻击者可以模拟这些特征。

先说说代码混淆：
代码混淆确实能大幅提高逆向工程的难度，让攻击者很难理解和修改你的代码，但没法完全阻止篡改。如果攻击者花足够的时间破解混淆，还是能修改代码并重新编译。但如果你的API已经用上了前面说的请求签名或客户端证书机制，篡改后的程序大概率无法生成正确的签名或使用合法的客户端证书，这时API端就能识别出这不是原版程序的调用——因为攻击者没法拿到你嵌入的密钥或私钥。

再聊代码签名：
代码签名对你的场景是有帮助的，但要分清楚它的作用：

• 代码签名主要是客户端侧的完整性验证：当用户运行你的程序时，Windows系统会检查程序的签名是否有效，防止程序被篡改后未经授权运行。但如果攻击者篡改程序后用自己的证书重新签名，系统还是会运行（除非用户的系统只信任你的根证书）。
• 要让代码签名帮到API验证，你可以结合前面的客户端证书机制：把你的代码签名证书作为客户端证书使用，API端验证请求携带的证书是否是你签发的、且证书对应的程序哈希是否匹配原版。这样即使攻击者篡改程序，也没法用你的证书重新签名（因为他们没有你的私钥），API端就能拒绝这类请求。

最后要强调：所有的安全措施都是分层的，结合多种方法（混淆+请求签名+客户端证书+代码签名）才能最大化安全性，没有单一方案能做到绝对防护。

内容的提问来源于stack exchange，提问作者Nitish Kr