.Net漏洞？ （通过代表的方式） [英] .Net Loophole? (by way of delegates)

问题描述

对所有人的问题：人们会认为这是.net中的漏洞，对于嵌套（内部）类来说是

吗？


1）创建外部类Foo并创建一个嵌套类Yin（在Foo的类内部

定义的课程）。

2）让Foo拥有非静态保护（或公共）方法Bar（ ）和Yin有一个名为Yang（）的非静态方法

。

4）将一个成员对象添加到类Yin的Foo，名为yinObj。

5）创建一个名为fooObj的类Foo的对象。


现在如果尝试从yinObj（Yin'的）中访问Foo的方法Bar（）方法

Yang（），Visual Studio .Net编译器将正确生成错误：

无法通过嵌套类型访问外部类型''Foo''的非静态成员

''Foo \Yin''


但是，我可以通过创建一个代表BarWrapper来解决这个问题，这需要
服务作为包装函数。我所做的就是以下内容：


A）将外部类范围内的委托BarWrapper定义为public

delegate void BarWrapper。

B）创建名为BarWrap的BarWrapper实例作为嵌套的公共成员

类Yin。

C）在Foo构造函数中的BarWrap中包裹条，如下所示：

yinObj.BarWrap =新的BarWrapper（Bar）。

D）从Yin的Method Yang中调用BarWrap，如下所示：Yang（）
{BarWrap（）; }


现在编译时，我不会从编译器中得到错误。实际上我

已成功从

嵌套类Yin中访问非静态成员函数Bar。


它似乎我完成了语言打算阻止的东西。


这是一个语言漏洞（作为代表构造的结果）

或者是能力做我上面做的事情吗？

谢谢，

布拉德

Question for all: Would one consider this a loophole in .net with respect
to nested (inner) classes?

1) Create outer class Foo and create a nested class Yin (inside Foo''s class
definition ofcourse).
2) Let Foo have non-static protected (or public) method Bar() and Yin have a
non-static method called Yang().
4) Add a member object to Foo of Class Yin called yinObj.
5) Create an Object of Class Foo called fooObj.

Now if try to access from Foo''s method Bar() from yinObj''s (Yin''s) method
Yang(), Visual Studio .Net compiler will correctly generate the error:
Cannot access a non-static member of outer type ''Foo'' via nested type
''Foo\Yin''

However, I can get around this by creating a delegate BarWrapper which
serves as a wrapper function. All I do is the following:

A) Define Delegate BarWrapper from the scope of the outer class as public
delegate void BarWrapper.
B) Create instance of BarWrapper called BarWrap as a public member of nested
Class Yin.
C) Wrap Bar inside BarWrap in the Constructor of Foo as follows:
yinObj.BarWrap = new BarWrapper (Bar).
D) Place a call to BarWrap from within Yin''s Method Yang as follows: Yang()
{ BarWrap(); }

Now when I compile, I will NOT get an error from the compiler. In effect I
have successfully accessed the non-static member function Bar from the
nested Class Yin.

Its as if I accomplished something the language was intending to prevent.

Is this a loophole in the language (as a result of the Delegate construct)
or is the ability to do what I did above intended?
Thanks,
Brad

推荐答案

我没有尝试过，但听起来很可疑。我仍然试图处理的其中一件事是，任何人都可以拆解任何.NET组件并查看内容。更不用说

，如果你擅长IL，你可以对所写的任何东西进行逆向工程。

即使是像签名组件等内置的保护，

似乎不够充分，如果一个人知道足够的IL只是打破应用程序和所有的依赖性，然后重新编译，就会重新编译。


当然，没有多少人愿意花时间学习IL，更不用说b $ b少学习如何写纯带有它的.NET代码，但它不是

不可能。我个人甚至打破了受保护的应用程序

使用标准COM和正常编译的.exe'和黑客

他们。如果你可以阅读汇编程序足以找到保护和

循环它或其他任何东西，那么完全取消b / b
功能并不太难。

试用申请并永久保存。看起来像.NET将会更加轻松地实现
。在这一点上，考虑到我们已经完成了对IL的程序集的完全访问，因此担心类级别的保护似乎是一个没有实际意义的问题。并不是说你没有一点好处

在这里，我只是在寻找它。


" Brad" < BC **** @ socal.rr.com>在消息中写道

news：om ****************** @ twister.socal.rr.com ...

I haven''t tried it, but it sounds suspicious. One of the things that I
am still trying to deal with is, the fact that anyone can disassemble
any .NET components and get a look at the contents. Not to mention
that if you get good at IL, you can reverse-engineer anything written.
Even the protections that are built-in like signing assemblies, etc.,
do not seem to be adequate if one knows enough IL to just break
down the app and all of it''s dependancies, then recompile.

Granted, not many folks are going to spend the time to learn IL, much
less learn how to write "pure" .NET code with it, but it''s not an
impossibility. I, personally, have even broken down protected apps
using the standard COM and normal compiled .exe''s and "hacked"
them. If you can read assembler enough to find the protection and
loop around it or whatever, it''s not too difficult to take a fully
functional
trial application and make it yours forever. Seems like .NET will make
this ever so much easier. At this point, worrying about class-level
protection seems like a moot point, given that we have complete
access to an assembly with IL. Not that you don''t have a good point
here, I''m just looking beyond that.

"Brad" <bc****@socal.rr.com> wrote in message
news:om******************@twister.socal.rr.com...

对所有问题：人们会认为这是.net中的一个漏洞，对于嵌套（内部）类有什么意义吗？

1）创建外部类Foo并创建一个嵌套类Yin（在Foo内部） '
类定义的课程）。
2）让Foo有非静态保护（或公共）方法Bar（）和Yin有
a非静态方法叫杨（）。< 4）将一个成员对象添加到类Yin的Foo，名为yinObj。
5）创建一个名为fooObj的类Foo对象。

现在如果尝试从Foo'访问方法Bar（）来自yinObj''（Yin's）方法
Yang（），Visual Studio .Net编译器将正确生成错误：
无法访问外部类型的非静态成员' 'Foo''通过嵌套类型
''Foo \Yin''

但是，我可以通过创建一个代理BarWrapper来解决这个问题，它可以作为包装函数使用。我所做的就是以下内容：
A）将外部类范围内的委托BarWrapper定义为公共
委托void BarWrapper。
B）创建名为BarWrap的BarWrapper实例
嵌套类Yin的公共成员。
C）Foo构造函数中的BarWrap内部包装栏如下：
yinObj.BarWrap = new BarWrapper（Bar）。
D）在Yin的Method Yang中调用BarWrap，如下所示：
Yang（）{BarWrap（）;现在，当我编译时，我不会从编译器中得到错误。实际上
我已经成功地从
嵌套的类Yin中访问了非静态成员函数Bar。

就好像我完成了语言打算阻止的东西。这是语言中的漏洞（作为代表构造的结果）
还是能够做我上面所做的事情？

谢谢，
Brad

Question for all: Would one consider this a loophole in .net with respect
to nested (inner) classes?

1) Create outer class Foo and create a nested class Yin (inside Foo''s class definition ofcourse).
2) Let Foo have non-static protected (or public) method Bar() and Yin have a non-static method called Yang().
4) Add a member object to Foo of Class Yin called yinObj.
5) Create an Object of Class Foo called fooObj.

Now if try to access from Foo''s method Bar() from yinObj''s (Yin''s) method
Yang(), Visual Studio .Net compiler will correctly generate the error:
Cannot access a non-static member of outer type ''Foo'' via nested type
''Foo\Yin''

However, I can get around this by creating a delegate BarWrapper which
serves as a wrapper function. All I do is the following:

A) Define Delegate BarWrapper from the scope of the outer class as public
delegate void BarWrapper.
B) Create instance of BarWrapper called BarWrap as a public member of nested Class Yin.
C) Wrap Bar inside BarWrap in the Constructor of Foo as follows:
yinObj.BarWrap = new BarWrapper (Bar).
D) Place a call to BarWrap from within Yin''s Method Yang as follows: Yang() { BarWrap(); }

Now when I compile, I will NOT get an error from the compiler. In effect I have successfully accessed the non-static member function Bar from the
nested Class Yin.

Its as if I accomplished something the language was intending to prevent.

Is this a loophole in the language (as a result of the Delegate construct)
or is the ability to do what I did above intended?
Thanks,
Brad

Brad< bc **** @ socal.rr.com>写道：


< snip>

Brad <bc****@socal.rr.com> wrote:

<snip>

现在编译时，我不会从编译器中得到错误。实际上我已经成功地从
嵌套的类Yin中访问了非静态成员函数Bar。


是的，但只是因为该实例通过代表的目标有效地知道了关于Foo实例的
的路线。

就好像我完成了语言打算阻止的东西。


我不这么认为。

这是一个语言漏洞（代表建设的结果）
或是能做我上面所做的事情吗？

Now when I compile, I will NOT get an error from the compiler. In effect I
have successfully accessed the non-static member function Bar from the
nested Class Yin.
Yes, but only because that instance effectively has a route to know
about an instance of Foo, via the target of the delegate.
Its as if I accomplished something the language was intending to prevent.
I don''t think so.
Is this a loophole in the language (as a result of the Delegate construct)
or is the ability to do what I did above intended?

绝对有意 - 而且它与嵌套类无关，

真的。当然，除非我误解了一些事情。 （已经晚了......）

为什么你认为你不应该这样做？


-

Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet

如果回复小组，请不要给我发邮件

Absolutely intended - and it has nothing to do with nested classes,
really. Unless, of course, I''ve misunderstood something. (It''s late...)
Why do you think you shouldn''t be able to do this?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

" Jon Skeet [C＃MVP]" < SK *** @ pobox.com>在消息中写道

新闻：MP ************************ @ msnews.microsoft.c om ...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Brad< bc **** @ socal.rr.com>写道：

< snip>

Brad <bc****@socal.rr.com> wrote:

<snip>

现在编译时，我不会从编译器中得到错误。在
效果中，我已成功从
嵌套类Yin中访问非静态成员函数Bar。
是的，但仅仅因为该实例有效地知道了关于Foo的一个例子，通过代表的目标。

Now when I compile, I will NOT get an error from the compiler. In effect I have successfully accessed the non-static member function Bar from the
nested Class Yin.
Yes, but only because that instance effectively has a route to know
about an instance of Foo, via the target of the delegate.

就好像我完成了语言打算
阻止的东西。
我不认为那么。

Its as if I accomplished something the language was intending to prevent.
I don''t think so.

这是一个语言漏洞（作为代表

Is this a loophole in the language (as a result of the Delegate

构造的结果）还是能力做我上面所做的事情？

construct) or is the ability to do what I did above intended?

绝对有意 - 而且它与嵌套类无关，
真的。当然，除非我误解了一些事情。 （已经晚了......）
为什么你认为你不应该这样做？

Absolutely intended - and it has nothing to do with nested classes,
really. Unless, of course, I''ve misunderstood something. (It''s late...)
Why do you think you shouldn''t be able to do this?

我的理由是这样的。

某些语言（如C或C ++）允许绕过某些错误检查，例如

作为类型检查。例如，在C中，可以将任何类型的指针重新转换为另一种类型的指针，即使指针指向结果的数据为

。界限。我相信这是故意的。


像C＃及其前身Java这样的语言似乎已经为

创建，目的是通过严格的铸造规则来最小化编程错误，

删除依赖于释放动态分配的内存等。如果

的重点是严格执行某些访问规则，那么似乎如果

编译器告诉我，不允许嵌套类访问外部类的非静态方法（通过将其视为编译器错误），

我会我已经预料到语言会被设计成

的方式，因为无法为嵌套的

类指定备用路由来了解非静态方法吧。似乎通过在代表中包含

a方法，我可以绕过应该存在的限制

。


这是否真的很重要取决于嵌套的

类不允许访问外部类的非静态方法的原因。我需要调查一下。


-Brad

My reasoning was this.
Some languages, like C or C++ allow going around certain error checks such
as type checking. In C, for instance, one can recast a pointer of any type
to a pointer of another type even if the data the pointer points to results
in it being out of bounds. I believe this was intentional.

Languages like C# and its predecessor Java seemed to have been created for
the purpose of minimize programming errors through strict rules on casting,
removal of reliance on freeing dynamically allocated memory, etc. If the
focus was to strictly enforce certain access rules, it seems that if the
compiler is telling me that nested classes are not allowed to access
non-static methods of the outer class (by treating it as a compiler error),
I would have expected that the language would have been designed in such as
way that it is not possible to specify an alternate route for the nested
class to know about the non-static method Bar. It seems that by wrapping up
a method in a delegate I can bypass the restrictions that are supposed to be
present.

Whether or not this is really important depends on the reason why nested
classes are not allowed to access non-static methods of an outer class. I
will need to look into that.

-Brad

这篇关于.Net漏洞？ （通过代表的方式）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！