混淆的优点/缺点？ [英] Pros/Cons of Obfuscation ?

问题描述

我正在玩一个名为Reflector的免费反编译器。我在.NET程序集中运行了它b / b
，并且非常惊讶于它将IL转换回C＃的能力。它让我想到了混淆。


我对混淆的有限理解是方法和变量

被随机重命名。名为''Stagmire''的属性可能被重命名为''xdFd''或

a方法名为''ComputeCorrelation（）''可能被重命名为''Fooodbone（）''。

虽然这种技术当然不能阻止逆向工程，但是它至少会使代码被盗和随后的人工解释变得更加困难，

这真的是我所有的一切我想要完成。


混淆有什么缺点？换句话说，为什么没有&b
VS2005默认情况下会混淆？肯定有一些缺点。


调试测试版应用程序时，我喜欢做的一件事是抓住未处理的异常，然后显示堆栈跟踪在弹出窗口中。然后

beta测试人员将堆栈跟踪复制/粘贴到我的电子邮件中，这样我就可以跟踪问题的根源。在我看来，如果代码被混淆了，那么堆栈跟踪将无法解释，因为

方法名称会被破坏，对吗？这对我来说是一个问题。


VS2005附带的混淆器是否适合大多数程序员

或者你建议使用第三方解决方案吗？


谢谢，


Johnny Drama

解决方案

恕我直言混淆是浪费时间。首先，甚至原生机器代码都可以反映出来。是的，这更难，但是你想要保护谁？b $ b你自己反对？如果它是普通用户，则不需要混淆。如果

它是树荫开发者，那么树荫开发者可能会使用这些工具来获取代码，但是什么样的对你来说威胁是一个

遮阳树开发者？如果它是一个专业人士，一个优秀的开发人员可以及时，以任何方式反编译你写的任何东西。在没有反编译的情况下，有很多方法可以获得软件的内部工作方式。但是

这需要投入大量时间，除非你的b / b
软件非常具有吸引力和/或创新，否则noboby会打扰/>
it。


现在，如果你为一家大公司工作，拥有一大批开发人员

创建一些非常受欢迎的商业软件采用创新的

技术，它可能值得你花时间。另一方面，您可以获得一项

专利，用于您提出的任何新技术。如果有人复制你的

代码，并且它们足够大，可以发现它们并不难识别它们并且因为专利侵权而起诉他们。如果他们没有足够大的注意，那么，如果他们这样做会对你的企业造成什么影响？


最后，最好的竞争方式是保持领先于竞争对手。它需要几个月甚至几年才能编写软件。当你发布它时，

你可以继续下一件事，任何抄袭你的人都已经落后了。

但如果你浪费太多时间试图制作你的软件很难复制，

这个时间可以用来继续前进。换句话说，我们有限时间资源

。我们应该把时间投入到最有利可图的活动中。


我可以采取同样的态度来帮助别人。为什么，通过帮助他们，我认为我可以认为它有助于竞争。但只要我分享我已经知道的东西，那些在我身后拿起我的b / b
信息的人将会留在我身后。根据定义，根本不可能超越你所追随的人。 OTOH，通过帮助其他人，我也受益于
。有时我必须做研究，并沿途学习。我是

积累良好的业力由于我的好作品。我已经做了很多朋友，当我需要帮助时，我可以打电话给他们。所以我分享了我自由了解的东西。继续前进。


这是我的2美分。


-

HTH，


Kevin Spencer

微软MVP

专业鸡肉沙拉炼金术士


你寻求什么你得到了什么。

" Johnny Drama" < gh **** @ englewood.com写信息

新闻：k4 ************************** ****@giganews.com ...

我正在玩一个名为Reflector的免费反编译器。我针对.NET程序集运行了

，并且非常惊讶于它将IL转换回C＃。它让我想到了混淆。


我对混淆的有限理解是方法和变量

被随机重命名。名为''Stagmire''的属性可能会被重命名为''xdFd''

或名为''ComputeCorrelation（）'的方法可能会被重命名为''Fooodbone（）''。

虽然这种技术肯定不能阻止逆向工程，但是它至少会使代码被盗和随后的人工解释变得更加困难，

这真的是全部我正在努力完成。


混淆有什么缺点？换句话说，为什么没有&b
VS2005默认情况下会混淆？肯定有一些缺点。


调试测试版应用程序时，我喜欢做的一件事是抓住未处理的异常，然后显示堆栈跟踪在一个弹出窗口中。

然后beta测试人员将堆栈跟踪复制/粘贴到我的电子邮件中，这样我就可以找到问题的根源。在我看来，如果代码

被混淆，堆栈跟踪将无法解释，因为

方法名称会被破坏，对吗？这对我来说是一个问题。


VS2005附带的混淆器是否足以满足大多数b / b
程序员的需要建议使用第三方解决方案吗？


谢谢，


Johnny Drama

说凯文，


Cor


" Kevin Spencer" < uc*@ftc.govschreef in bericht

news：eO ************** @ TK2MSFTNGP03.phx.gbl ...

恕我直言，混淆是浪费时间。首先，甚至原生机器代码都可以反映出来。是的，这更难，但是你想要保护谁？b $ b你自己反对？如果它是普通用户，则不需要混淆。如果

它是树荫开发者，那么树荫开发者可能会使用这些工具来获取代码，但是什么样的对你来说威胁是一个

遮阳树开发者？如果它是一个专业人士，一个优秀的开发人员可以及时地以任何方式反编译你写的任何东西。有很多方法可以在不反编译

的情况下获得软件的内部工作方式。但这需要花费大量时间投入，而且除非你的软件非常具有吸引力和/或创新性，否则noboby会花费很多时间来讨论这个问题。


现在，如果你为一家大公司工作，拥有一大批开发人员

用创新的方式创建一些非常受欢迎的商业软件

技术，它可能值得你花时间。另一方面，您可以获得

专利，以获得您提出的任何新技术。如果有人复制了你的代码，并且他们足够大，可以注意到，他们并不难确定他们是否因为专利侵权而起诉他们。如果他们不够大，请注意，如果他们这样做会对你的业务产生什么影响呢？


最后，最好的竞争方式是保持领先于竞争对手。它需要几个月甚至几年才能编写软件。当你发布它时，

你可以继续下一件事，任何抄袭你的人已经落后了。但如果你浪费太多时间试图让你的软件难以复制，那么可以花时间继续前进。换句话说，我们

的时间资源有限。我们应该把时间投入到最有利可图的活动中。


我可以采取同样的态度来帮助别人。为什么，通过帮助他们，

我想我可以认为它有助于竞争。但只要

我正在分享我已经知道的东西，那些在我身后拿起我的

信息的人将留在我身后。根据定义，根据你所追随的人提前获得
根本不可能。 OTOH，通过帮助其他人我也受益匪浅。有时候我必须做研究，并且沿途学习

。我正在积累良好的业力。由于我的好作品。并且

我已经结交了很多朋友，当我需要帮助时我可以打电话给他们。所以我

分享我所知的自由。继续前进。


这是我的2美分。


-

HTH，


Kevin Spencer

微软MVP

专业鸡肉沙拉炼金术士


你寻求什么是你得到的。


Johnny Drama < gh **** @ englewood.com写信息

新闻：k4 ************************** ****@giganews.com ...

>我正在玩一个名为Reflector的免费反编译器。我针对.NET程序集运行了它，并且非常惊讶于它将IL转换回C＃的能力。它让我想到了混淆。

我对混淆的有限理解是方法和变量随机重命名。名为''Stagmire''的属性可能会被重命名为''xdFd''
，或者名为''ComputeCorrelation（）''的方法可能会被重命名为''Fooodbone（）''。
虽然这种技术肯定它不能阻止逆向工程，它至少会使代码被盗和随后的人工解释变得更加困难，这真的是我想要完成的。

混淆的缺点是什么？换句话说，为什么VS2005默认不混淆？必须有一些缺点。

调试测试版应用程序时我喜欢做的一件事就是捕获未处理的异常，然后在弹出窗口中显示堆栈跟踪。
测试版测试人员然后将堆栈跟踪复制/粘贴到我的电子邮件中，以便我可以追踪问题的根源。在我看来，如果代码
被混淆，堆栈跟踪将无法解释，因为方法名称会被破坏，对吗？这对我来说是一个问题。

VS2005附带的混淆器是否足以满足大多数程序员的需求，或者您是否建议使用第三方解决方案？

谢谢，

Johnny Drama

嗨Johnny，


这个问题几乎每周就出现在这里。


然后你会得到你不应该担心混淆的回复/>
您的代码，因为它浪费时间，并且您必须通过处理下一个版本保持领先于

竞争。


这在某种程度上是正确的。但是如果你当前的软件版本已经足够满足大多数人的需求了。取决于您的市场是谁b $ b，免费已经让它的许可计划逆转的版本，可能是足够多的人使用，这可能会让你失去一些收入。


关键问题是这会给你带来多少收入？这取决于

您认为您的市场是多么诚实。在所有市场中，您几乎可以使用未经许可的版本来节省一些收入。问题

，您认为您的商业模式仍然可以通过

合法销售吗？


它可能如果您的软件产品的一半用户使用盗版版本，您仍然可以在使用的正确版本的

上获得良好的回报。


如果你想让逆向工程变得更难，那么混淆确实有一席之地。 - 为什么要将具有描述性名称的c＃代码交给你的竞争对手

？ - 我很欣赏由小型软件公司创建的许多这些专业软件

都处于竞争激烈的市场中，这可能是一个问题。 - 即使你的代码不是人们会打的话

开创性的。


重要的是不要让代码安全性陷入困境，找到

保护您的收入流之间的平衡（使用许可证

保护或人们能够非常轻松地破解您的代码），以及

使用您的软件的实际功能进行创新。


回到关于混淆代码调试的问题。我认为大多数专业级别的版本具有可以映射混淆代码的功能

符号用于调试等。


HTH


Jim

" Johnny Drama" < gh **** @ englewood.com写信息

新闻：k4 ************************** ****@giganews.com ...

我正在玩一个名为Reflector的免费反编译器。我针对.NET程序集运行了

，并且非常惊讶于它将IL转换回C＃。它让我想到了混淆。


我对混淆的有限理解是方法和变量

被随机重命名。名为''Stagmire''的属性可能会被重命名为''xdFd''

或名为''ComputeCorrelation（）'的方法可能会被重命名为''Fooodbone（）''。

虽然这种技术肯定不能阻止逆向工程，但是它至少会使代码被盗和随后的人工解释变得更加困难，

这真的是全部我正在努力完成。


混淆有什么缺点？换句话说，为什么没有&b
VS2005默认情况下会混淆？肯定有一些缺点。


调试测试版应用程序时，我喜欢做的一件事是抓住未处理的异常，然后显示堆栈跟踪在一个弹出窗口中。

然后beta测试人员将堆栈跟踪复制/粘贴到我的电子邮件中，这样我就可以找到问题的根源。在我看来，如果代码

被混淆，堆栈跟踪将无法解释，因为

方法名称会被破坏，对吗？这对我来说是一个问题。


VS2005附带的混淆器是否足以满足大多数b / b
程序员的需要建议使用第三方解决方案吗？


谢谢，


Johnny Drama

I was playing around with a free decompiler called "Reflector." I ran it
against a .NET assembly and was pretty amazed with how well it converted IL
back to C#. It got me thinking about obfuscation.

My limited understanding of obfuscation is that methods and variables
are renamed randomly. A property named ''Stagmire'' might be renamed ''xdFd'' or
a method named ''ComputeCorrelation()'' might be renamed ''Fooodbone()''.
Although this technique certainly can''t prevent reverse engineering, it at
least makes code theft and subsequent human interpretation a lot harder,
which is really all I''m trying to accomplish.

What are the drawbacks of obfuscation? In other words, why doesn''t
VS2005 just obfuscate by default? There must be some drawbacks.

One thing I''m fond of doing when debugging beta apps is to catch
unhandled exceptions and then display the stack trace in a popup window. The
beta tester then copy/pastes the stack trace into an email to me so I can
track down the source of the problem. It seems to me that if the code were
obfuscated, the stack trace would be impossible to interpret because the
method names would be mangled, correct? That would be a problem for me.

Is the obfuscator that comes with VS2005 sufficient for most programmers
or do you recommend going with a 3rd party solution?

Thanks,

Johnny Drama

解决方案

IMHO, obfuscation is a waste of time. First, even native machine code can be
decompiled. Yes, it''s more difficult, but who are you trying to protect
yourself against? If it''s the average user, obfuscation is unnecessary. If
it''s the shade-tree developer, it is possible that a shade-tree developer
could use the tools to get at your code, but what kind of a threat is a
shade-tree developer to you? If it''s a professional, a good developer could,
in time, decompile anything you write in any manner. There are a lot of ways
to get at the inner workings of software without decompiling as well. But
this is something that takes a good investment of time, and unless your
software is very attractive and/or innovative, noboby''s going to bother with
it.

Now, if you work for a large corporation, with a large team of developers
creating some highly-popular commerical software with innovative
technologies, it might be worth your while. On the other hand, you can get a
Patent for any new technologies you come up with. And if someone copies your
code, and they are big enough to notice, it isn''t hard to identify them and
sue them for patent infrigement. If they''re not big enough to notice, what
difference does it make to your business if they do?

Finally, the best way to compete is to stay ahead of the competition. It
takes months or even years to write software. By the time you release it,
you can move on to the next thing, and anyone copying you is already behind.
But if you waste too much time trying to make your software hard to copy,
that''s time that could be spent moving ahead. In other words, we have
limited time resources. We should invest our time in activities that will be
the most profitable.

I could take the same attitude about helping people. Why, by helping them, I
suppose I could think of it as helping the competition. But as long as I''m
sharing what I already know, those who are behind me picking up my scraps of
information will remain behind me. It is simply not possible to get ahead of
someone you are following, by definition. OTOH, by helping others I benefit
as well. Sometimes I have to do research, and learn along the way. I am
accumulating good "karma" as a result of my good works. And I have made
quite a few friends that I can call on when I need help. So I share what I
know freely. And keep moving forward.

That''s my 2 cents.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

What You Seek Is What You Get.
"Johnny Drama" <gh****@englewood.comwrote in message
news:k4******************************@giganews.com ...

I was playing around with a free decompiler called "Reflector." I ran
it against a .NET assembly and was pretty amazed with how well it
converted IL back to C#. It got me thinking about obfuscation.

My limited understanding of obfuscation is that methods and variables
are renamed randomly. A property named ''Stagmire'' might be renamed ''xdFd''
or a method named ''ComputeCorrelation()'' might be renamed ''Fooodbone()''.
Although this technique certainly can''t prevent reverse engineering, it at
least makes code theft and subsequent human interpretation a lot harder,
which is really all I''m trying to accomplish.

What are the drawbacks of obfuscation? In other words, why doesn''t
VS2005 just obfuscate by default? There must be some drawbacks.

One thing I''m fond of doing when debugging beta apps is to catch
unhandled exceptions and then display the stack trace in a popup window.
The beta tester then copy/pastes the stack trace into an email to me so I
can track down the source of the problem. It seems to me that if the code
were obfuscated, the stack trace would be impossible to interpret because
the method names would be mangled, correct? That would be a problem for
me.

Is the obfuscator that comes with VS2005 sufficient for most
programmers or do you recommend going with a 3rd party solution?

Thanks,

Johnny Drama

Well said Kevin,

Cor

"Kevin Spencer" <uc*@ftc.govschreef in bericht
news:eO**************@TK2MSFTNGP03.phx.gbl...

IMHO, obfuscation is a waste of time. First, even native machine code can
be decompiled. Yes, it''s more difficult, but who are you trying to protect
yourself against? If it''s the average user, obfuscation is unnecessary. If
it''s the shade-tree developer, it is possible that a shade-tree developer
could use the tools to get at your code, but what kind of a threat is a
shade-tree developer to you? If it''s a professional, a good developer
could, in time, decompile anything you write in any manner. There are a
lot of ways to get at the inner workings of software without decompiling
as well. But this is something that takes a good investment of time, and
unless your software is very attractive and/or innovative, noboby''s going
to bother with it.

Now, if you work for a large corporation, with a large team of developers
creating some highly-popular commerical software with innovative
technologies, it might be worth your while. On the other hand, you can get
a Patent for any new technologies you come up with. And if someone copies
your code, and they are big enough to notice, it isn''t hard to identify
them and sue them for patent infrigement. If they''re not big enough to
notice, what difference does it make to your business if they do?

Finally, the best way to compete is to stay ahead of the competition. It
takes months or even years to write software. By the time you release it,
you can move on to the next thing, and anyone copying you is already
behind. But if you waste too much time trying to make your software hard
to copy, that''s time that could be spent moving ahead. In other words, we
have limited time resources. We should invest our time in activities that
will be the most profitable.

I could take the same attitude about helping people. Why, by helping them,
I suppose I could think of it as helping the competition. But as long as
I''m sharing what I already know, those who are behind me picking up my
scraps of information will remain behind me. It is simply not possible to
get ahead of someone you are following, by definition. OTOH, by helping
others I benefit as well. Sometimes I have to do research, and learn along
the way. I am accumulating good "karma" as a result of my good works. And
I have made quite a few friends that I can call on when I need help. So I
share what I know freely. And keep moving forward.

That''s my 2 cents.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

What You Seek Is What You Get.
"Johnny Drama" <gh****@englewood.comwrote in message
news:k4******************************@giganews.com ...

> I was playing around with a free decompiler called "Reflector." I ran
it against a .NET assembly and was pretty amazed with how well it
converted IL back to C#. It got me thinking about obfuscation.

My limited understanding of obfuscation is that methods and variables
are renamed randomly. A property named ''Stagmire'' might be renamed ''xdFd''
or a method named ''ComputeCorrelation()'' might be renamed ''Fooodbone()''.
Although this technique certainly can''t prevent reverse engineering, it
at least makes code theft and subsequent human interpretation a lot
harder, which is really all I''m trying to accomplish.

What are the drawbacks of obfuscation? In other words, why doesn''t
VS2005 just obfuscate by default? There must be some drawbacks.

One thing I''m fond of doing when debugging beta apps is to catch
unhandled exceptions and then display the stack trace in a popup window.
The beta tester then copy/pastes the stack trace into an email to me so I
can track down the source of the problem. It seems to me that if the code
were obfuscated, the stack trace would be impossible to interpret because
the method names would be mangled, correct? That would be a problem for
me.

Is the obfuscator that comes with VS2005 sufficient for most
programmers or do you recommend going with a 3rd party solution?

Thanks,

Johnny Drama

Hi Johnny,

This question pops up on here almost weekly.

You''ll then get the response that you should not worry about obfuscating
your code, becuase its a waste of time, and that you must stay ahead of the
competition by working on the next version.

That''s true to an extent. But if your current version of the software is
already good enough for most people''s needs. depending on who your market
is, the "free" version that has had it''s licensing scheme reversed, may be
good enough for too many people to use, which could loose you some revenue.

The key question is how much revenue will this loose you? This depends on
how honest you think your market is. In all markets you will almost
certainly loose some revenue to unlicensed versions being used. The question
is, do you think that your business model will still be viable with the
legitimate sales?

It may be the case that even if half of the users of your software product
are using a pirated version, you could still make a good return on the
legitimate versions being used.

Obfuscation does have a place if you want to make reverse engineering a
little harder. - Why hand c# code with descriptive names to your competition
on a plate? - I appreciate that many of these specialist pieces of software
created by small software houses are in very competive markets, and that
this may be a concern. - even if your code is not what people would call
groundbreaking.

The important thing is not to get too bogged down in code security, and find
the balance between protecting your revenue stream (either with license
protection or people being able to rip off your code very easily), and that
of being creative with your software''s actual functionality.

Getting back to your question on obfuscated code debugging. I think most of
the pro level versions have features where they can map the obfuscated code
symbols for debugging etc.

HTH

Jim
"Johnny Drama" <gh****@englewood.comwrote in message
news:k4******************************@giganews.com ...

I was playing around with a free decompiler called "Reflector." I ran
it against a .NET assembly and was pretty amazed with how well it
converted IL back to C#. It got me thinking about obfuscation.

My limited understanding of obfuscation is that methods and variables
are renamed randomly. A property named ''Stagmire'' might be renamed ''xdFd''
or a method named ''ComputeCorrelation()'' might be renamed ''Fooodbone()''.
Although this technique certainly can''t prevent reverse engineering, it at
least makes code theft and subsequent human interpretation a lot harder,
which is really all I''m trying to accomplish.

What are the drawbacks of obfuscation? In other words, why doesn''t
VS2005 just obfuscate by default? There must be some drawbacks.

One thing I''m fond of doing when debugging beta apps is to catch
unhandled exceptions and then display the stack trace in a popup window.
The beta tester then copy/pastes the stack trace into an email to me so I
can track down the source of the problem. It seems to me that if the code
were obfuscated, the stack trace would be impossible to interpret because
the method names would be mangled, correct? That would be a problem for
me.

Is the obfuscator that comes with VS2005 sufficient for most
programmers or do you recommend going with a 3rd party solution?

Thanks,

Johnny Drama

这篇关于混淆的优点/缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！