有没有办法防止我们的应用程序被分析或注入？ （C＃）
有大量用于 C# 程序集的分析器和静态代码分析器。
只是想知道是否有什么方法可以防止被分析，因为它确实让我在被剥夺时感到有点紧张。
我已经在互联网和 stackoverflow 上进行了搜索。 似乎没有什么令我惊奇的。
我所得到的只是一些更可怕的标题，比如这些（抱歉，新用户不能发布超链接，请谷歌搜索它们）：
“汇编操作和 C#/VB.NET 代码注入”
“如何注入托管 . NET 程序集 (DLL) 到另一个进程中”
是我太担心还是什么？
顺便说一句，我们正在使用 C# 构建一个新的 winform 客户端，供银行客户进行在线交易。 我们不应该用 winform 的方式来做这件事，还是应该使用其他语言，比如 Delphi、C++？ 目前我们有一个用C++ Builder构建的winform客户端。
There are loads of profilers and static code analyzers out there for C# assemblies.
Just wonder if there are any methods to prevent being analyzed, because it does make me feel a bit nervous when being stripped.
I have searched all over the Internet and stackoverflow. There seems none for my wonder.
What I've got are only some even more scary titles like these (sorry, new user can't post hyper links, please google them):
"Assembly Manipulation and C#/VB.NET Code Injection"
"How To Inject a Managed .NET Assembly (DLL) Into Another Process"
Is it just me being too worried or what?
BTW, with C#, we are building a new winform client for a bank's customers to do online transactions. Should we not do this in the winform way or should we use some other language like Delphi, C++? Currently we have a winform client built with C++ Builder.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果“分析”是指有人反编译代码并查看它，那么 VS Pro 及更高版本附带的 Dotfucstor 是一个简单（免费）的工具，可以在这里提供帮助。 有一个功能更齐全（但需要付费）的版本可以做更多事情。
为了防止有人篡改您部署的组件，请使用强名称< /a>.
If by analyzed you mean someone decompiling the code and looking at it, then the Dotfucstor that ships with VS Pro and above is a simple (free) tool to help here. There is a fuller functionality (but paid for) version that can do more.
To prevent someone tampering with your deployed assmebliles, use Strong Names.
有志者事竟成，无论是托管代码还是本机程序集。 关键是将重要信息保留在服务器端并保持对其的控制。
Where there's a will, there's a way, whether it's managed code or native assembly. The key is to keep the important information on the SERVER end and maintain control of that.
几乎任何应用程序都可以“分析和注入”。 有些比其他更多。 这就是为什么你永远不相信用户输入。 您在服务器端完全验证用户的请求，确保您不易受到缓冲区溢出、sql 注入和其他攻击媒介的影响。
混淆器会使 .NET 程序集更难分析。 使用安全密钥对程序集进行强命名可以使更改代码变得更加困难。 但是，就像数字世界中的其他事物一样，有人可以利用漏洞并绕过您采取的任何保护措施。
Just about any application can be "analysed and injected". Some more than others. That's why you NEVER TRUST USER INPUT. You fully validate your user's requests on the server end, making sure you're not vulnerable to buffer overruns, sql injection and other attack vectors.
Obfuscators can make .NET assemblies harder to analyze. Using a secure key to strong-name your assemblies can make it much harder to alter your code. But, like everything else in the digital world, somebody can exploit a vulnerability and get around whatever safeguards you put in place.
您需要决定的第一件事是什么？
混淆器仅对保护“秘密武器”算法有用，但攻击者可以简单地提取代码并将其用作黑盒。 99% 的情况下，混淆器都是浪费钱。
如果攻击者具有物理访问权限，那么您无能为力。
The first thing you need to decide against what you are trying to protect?
Obfuscators are useful only to protect "secret sauce" algorithms, but the attacker can simply extract the code and use it as black-box. In 99% of cases obfuscators are waste of money.
If the attacker has physical access there is not much you can do.
如果最终用户以管理权限运行，那么他们将能够附加调试器并修改您的代码，包括目标帐户详细信息。 我当地友好的银行给了我一张芯片和一张卡片。 密码读取器，我必须输入目标帐户的最后 n 位数字，它会使用我的银行卡芯片对其进行哈希/加密； 然后，我将设备上的代码输入银行的网络应用程序，该应用程序也可以在银行端进行检查。 这减轻了“中间人”类型的攻击......
If the end user is running with administrative privileges then they will be able to attach a debugger, and modify your code, including target account details. My local friendly bank has given me a chip & pin reader that I have to enter the last n digits of the target account, which it hashes/encrypts with my bank card's Chip; I then enter the code from the device into the bank's web application which can checked at the bank's end as well. This mitigates "man in the middle" type attacks...
安全性只有在您物理控制访问的系统上才有可能，即使这样也不能保证，只是可以实现。 您必须假设任何不在您控制的系统上执行的代码都可能并且将会受到损害。 正如罗兰·肖（Rowland Shaw）所说，对于金融机构来说，最好的选择是某种物理代币，它可以有效地为所有交易添加离线独特的组件，而攻击者在受感染的系统中操作时无法（轻易）提前知道这些交易。 即使这样，您也应该意识到这样一个事实：如果用户的计算机已被入侵，并且从那时起他使用安全令牌登录，直到会话结束，攻击者就可以自由地执行用户有权执行的任何操作，但至少在这种情况下，用户更有可能注意到欺诈活动。
Security is only possible on systems you physically control access to, and even then not guaranteed, merely achievable. You must assume any code not executing on a system you control can and will be compromised. As Rowland Shaw stated, the best bet for a financial institution is some sort of physical token which effectively adds a offline unique component to all transactions that cannot be (easily) known ahead of time by an attacker operating from a compromised system. Even then you should be aware of the fact that if the users computer has been compromised and he logs in with his secure token from that point forward until the session ends the attacker is free to perform whatever actions the user has permission to, but at least in that case the user is more likely to notice the fraudulent activity.