IL代码安全 [英] IL Code Security

问题描述

这个帖子更多的是一个讨论主题 - 因为我重视这个新闻组中海报的意见，特别是像MV这样的MVP Nicholas Paladino和Jon Skeet（感谢各位对你们的帮助超过

年）。


我的公司一直在努力将我们的应用程序移动到很多地方。 NET / C＃

（这让我非常开心）。我已经成功地让他们使用C＃开始了新的

项目，我们对目前的结果非常满意。


但是，一个主要的关注我在这个pro-.NET中遇到的问题

推动的是我的老板，以及一些编写旧的人。 C ++

代码，不希望他们在我们的

更重要的应用程序中使用的一些更重要的算法可以通过反汇编程序轻松读取（甚至

ILDASM）甚至可以通过一些应用程序转回到C＃代码中

那里有可用的。


我是在这种情况下对他们的回答有点不知所措，所以截至目前，我还没有获得多少奖金。我到目前为止提出的可能的解决方案（以及为什么我不喜欢它们b / b $ b $），如下：


1）混淆：虽然这使得阅读起来更加困难，但是它不会完全隐藏

程序集中类/函数的算法/理论。我也听说过它给人们带来了一些问题，那些

程序集在被混淆之后就不会执行。

2）使用托管C ++并包含本机C ++ lib文件：我不记得当我自己尝试的时候是否有这个工作，但我确实记得它是非常痛苦的。其中一部分原因是我不喜欢C ++中的.NET实现（与C＃相比） - 看起来非常糟糕。如果

这确实有用，那么它有可能，虽然不是很干净

一个。

3）创建本机C ++ DLL并使用互操作从C＃到达他们：这个

是我最成功的方法，但是，部分是因为我们以前的一些功能/类的复杂性应用程序使用

，部分是因为我不太熟悉编组/互操作，我的b $ b最终得到了一些不太好看的代码以允许C＃工作好吧

的功能。


＃2和＃3对于某些
$来说似乎也不是很好的选择b $ b thigns我正在转换，因为我试图隐藏的算法是

与应用程序的主要操作紧密相关（

部分将在.NET）。


基本上，我很想知道其他人对这一切的看法，以及

其他人在做什么他们自己的工作场所。我很喜欢C＃/ .NET而且我会想要让公司尽可能多地转移到公司，但我不会这么做。 b知道从哪里开始。


提前感谢任何意见/建议！

解决方案

我忘记了我要说的其他部分。


我很惊讶微软没有提供任何东西（优于

dotfuscator社区版）以防止此问题。凭借强大的

..NET推动他们已经拥有，并且他们打算在最初的几年内对.NET应用程序进行非常快速和强大的b $ b吸收 - 看起来好像这个问题将成为他们的主要绊脚石之一。


因为汇编代码可能不会出现在

反汇编（参见在托管C ++应用程序中使用__asm），它似乎必须有一种隐藏的方法。这些信息，甚至允许开发人员选择（可能带有一个属性）哪些函数是预编译的，而其余的都像IL一样转向IL。这可能显然是可选的 - b $ b因此纯粹的IL .NET

应用程序的所有巨大好处都存在，但是如果开发人员需要额外的代码< b / b
安全性，他们已经拥有它了。


我确定之前已经讨论过这个问题了，我肯定有好的/>
原因 - 我只是没有看到这些讨论或原因。

再次感谢！

Tim Mulholland写道：

基本上，我很想知道其他人对这一切的看法，

让你的老板知道拆解一个C / C ++

应用程序是相当简单的，如果你正在寻找一个特别的算法，那么它更容易从中得到
生成的汇编程序。


同样，您可以对.NET IL进行反向工程。我使用Thinstall来混淆

并防止内存偷看，这是一种方法来解决.NET

程序集的混淆。


.NET或旧版本没有完美的解决方案。


-

gabriel

< blockquote> Tim Mulholland写道：

我很惊讶微软没有提供任何东西（比dotfuscator社区版本更好）来防止这个问题。随着

这是因为你不能真正阻止一个真正坚定的黑客来反向工程。指令最终必须位于

内存位置，以便CPU可以跟随它们。无论加密什么，

混淆，编码或者whtever，指令最终都会在那里

和反向工程。你所能希望的就是让它变得足够困难

让他们进行逆向工程。


如果你有真正的秘密算法，那么建立一个Web服务

密钥算法在您公司的服务器上运行，远离客户在

客户站点。这是你能做的最好的事情。


-

gabriel

This thread is intended to be more of a discussion thread - because i value
the opinions of the posters in this newsgroup, and especially the MVPs like
Nicholas Paladino and Jon Skeet (thanks to all of you for your help over the
years).

My company has been toying with moving alot of our applications to .NET/C#
(which makes me _very_ happy). I''ve successfully gotten them to start new
projects using C# and we have been very happy with the results so far.

However, the one primary concern i am running up against in this pro-.NET
push is that my boss, as well as some of the people that wrote the "old" C++
code, doesn''t want some of the more important algorithms they use in our
more critical applications to be easily read via a disassembler (even
ILDASM) or even turned back into C# code by some of the applications out
there that are available for that.

I''m kind of at a loss for an answer to them on this, so as of now, i haven''t
gained much ground. The possible solutions (and reasons why i don''t like
them) that i''ve come up with so far, are as follows:

1) Obfuscation: Although this makes it more difficult to read, it doens''t
completely hide the algorithms/theory of the classes/functions in the
assembly. I''ve also heard that it has caused people some issues where
assemblies wouldn''t execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can''t remember if
i ever got this working when i tried it myself, but i do remember it being
quite a pain. part of that came from the fact that i don''t like the .NET
implementation in C++ (compared to the C# one) - it seems very kludgy. If
this does actually work, then its a possibility, though not a very clean
one.
3) Creating native C++ DLLs and using interop to get to them from C#: This
was the method i was most successful with, but, partially because of the
complexity of some of the functions/classes our old applications were using
and partially because i''m not all too familiar with marshalling/interop, i
ended up with some not very nice looking code to allow C# to work well with
the functions.

#2 and #3 also just didn''t seem like very good options for some of the
thigns i was converting because the algorithms i was trying to hide were
fairly closely tied in with the main operation of the applications (the
parts that would be in .NET).

Basically, i''m curious to find out what others think about all this, and
what others are doing in their own workplaces. I''m big on C#/.NET and i''d
love to get the company moving to as much of this as possible, but i don''t
know where to go from here.

Thanks in advance for any comments/suggestions!

解决方案

I forgot one other part of what i was going to say.

I''m sort of surprised that Microsoft hasn''t provided something (better than
the dotfuscator community edition) to prevent this issue. With the strong
..NET push they''ve had, and their intentions of having a very fast and strong
uptake on .NET applications over the first couple years - it would seem that
this issue would be one of the major stumbling blocks for them.

Because it is possible for the assembly code to not show up when
disassembled (see the use of __asm in Managed C++ applications), it would
seem that there must be a way to "hide" this information, or even to allow
developers to choose (possibly with an Attribute) which functions are
pre-compiled, while the rest are turned to IL like normal. This could
obviously be optional - so all the tremendous benefits of a pure-IL .NET
application would be there, but if a developer needed that extra bit of code
security, they''d have it.

I''m sure this has been discussed before, and i''m sure there are good
reasons - i just haven''t seen these discussions or the reasons.

Thanks again!

Tim Mulholland wrote:

Basically, i''m curious to find out what others think about all this,

Let your boss know that it is rather straightforward to disassemble a C/C++
application and if you are looking for an algorithm in particular, it is
even easier to get from the generated assembler.

Likewise, you can reverse engineer .NET IL. I use Thinstall to obfuscate
and prevent memory-peeking which is a way to get aroung obfuscation of .NET
assemblies.

There is no perfect solution for either .NET or older stuff.

--
gabriel

Tim Mulholland wrote:

I''m sort of surprised that Microsoft hasn''t provided something (better
than the dotfuscator community edition) to prevent this issue. With

That''s because you can''t really prevent a truly determined hacker from
reverse engineering anything. The instructions eventually have to be on a
memory location so the CPU can follow them. No matter what encryption,
obfuscation, encoding or whtever, the instructions will eventually be there
and reverse-engineerable. All you can hope for is to make it hard enough
for them to reverse engineer.

If you have truly secret algorithms, then set up a web service where the
key algorithm runs on your company''s server away from the client at the
customer site. This is pretty much the best you can do.

--
gabriel

这篇关于IL代码安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！