Slashdot Mirror
Hijacking .NET
In the .NET Framework, it's possible to access a private member of any class -- your own, another developer's, or even the classes in the .NET Framework itself! Appleman demonstrates this with a great example that uses private members to get the list of groups that the current user is a member of -- in a single line of code -- by accessing a private member that is not exposed by the .NET Framework.
Appleman also explains the tradeoffs of using this technique. The code you're using is not documented, and it's not guaranteed to be present in future versions. He describes how to deal with these problems, and how to make the most of the technique while remaining relatively safe.
Once the basic technique is explained, Appleman takes you into how to find out what private members are available, and how to call them. He shows how to use the object browser available in Visual Studio .NET and the Microsoft IL Disassembler, freely available in the Framework SDK, to discover the private members in a class and determine how to call them correctly.
The example is great -- Dan shows you how he used "hijacking" with a collection of private members to develop a FileAccessControlList class that can be used to manipulate ACL's on Windows files. This is a piece of functionality that is not included with the .NET Framework, but developers have a need for all the time. To write the code from scratch would take days, including translating Windows API declarations to C# or another .NET language and poring over MSDN documentation. As it turns out, all the pieces are in the Framework -- they're just not public. Appleman accomplishes the task in under 200 lines of code, all of which is included with the e-book. As a bonus, you get a great introduction to how Windows security works, and how the example could be extended to other ACL-controlled things like Registry keys.
The fact that private in .NET isn't really private is something that isn't well known, and even if you're not interested in security, this e-book is worth a read just to get some insight into what you can do with the .NET framework, and what other people might someday try to do to your code.
As far as the author's writing style, I will say that Dan has a great knack for intuiting what needs to be explained and what doesn't. His laid-back approach makes everything seem fun -- this is a book you could read on a Saturday afternoon in a hammock.
This e-book is not for beginning .NET programmers, but should be easy for intermediate developers to understand. The whole text weighs in at just under 50 pages, and is well worth the cost of $9.95. Sample code is provided in both C# and VB .NET.
This e-book can be purchased and downloaded immediately from amazon.com or through the author's web site.
you fucking faggot cumdumpster moderators - go ahead, use your mod points here. better here than modding down the opinions of people you don't agree with simply because they employ logic and aren't pansy faggots that worship all things linux and bash all things microsoft. by the way, you're commie scum you faggot moderators.
Use a memory hex editor!
Rocket science is easy. Neurosurgery, now *that's* difficult.
If you code in a Microsoft programming language, you can't even trust your own code!
Is this a limitation of C# or of .NET?
.NET programs? I thought it was supposed to be possible to run .NET programs in a sandbox, protecting you from malicious code. It seems that being able to access private members in the .NET framework opens up a whole new world of possibilities for security holes...
What does this mean for the security of
Isn't this a security bug, you think that you've hidden some code, but infact it isn't.
thank God the internet isn't a human right.
From microsoft, right?
Is this behaviour by design, or merely a side effect of the implementation? If it's a side effect, then don't rely on the support for this "feature" to continue in future releases of the .NET framework. MS has a nasty habit of changing undocumented features...
In Java, the bytecode interpreter makes sure you can't access private class members. This is needed for security - creating the 'sandbox' which is most well-known from applets, and IMHO isn't used enough elsewhere.
.NET you don't have the same raw hardware access, but it looks like for speed Microsoft omitted to check access qualifiers at run time. But I wonder, is this part of the .NET specifications, or is it just an implementation oversight? Does the same trick work on Mono for example?
OTOH in C++ the public/protected/private distinction is enforced solely by the compiler, and code has full access to the machine.
Obviously in
-- Ed Avis ed@membled.com
Anyone who's looking into reflection at any depth knows that private members can be found and used without too much trouble. The only thing he's done here is actively tried to use the private functions of code he didn't right. What a genuis :-/
This is nothing new - you can do the same thing in C++. It's easy to access private variables or functions by manipulating a pointer.
So what's the big deal?
Maybe the title of this book should be changed to "1001 ways to write bad code". Relying on undocumented private members of classes violates encapsulation and pretty much guarantees that your code will not work with (a) compatible implementations on other platforms, and probably also (b) future versions on the same platform. Just Say No, is my advice.
..and is a very old technique.
Java, Modula2, Lisp and smalltalk all allow
this.
RTFM
...and here I thought thatd den_member> = 0; was bad style.
((<sneaky_private_type_I_wanna_access> *)<void_starish_opaque_handle>)-><ha_take_that_hi
You could've hired me.
I suspect the most common use of this is not attempts at bypassing poorly thought out security. I hope MSFT programmers are not hiding passwords in .NET classes. The most common usage will be "tweaks" and such that will be dependent on a specific .NET framwork version/release.
.NET framework version 1.0 for Windows 2000/XP, but come next release, these tweaks are likely to break. That's why private members of classes are private, because they are not part of the documented API.
By delving into the private classes, you might be able to get speedups on a specific (or common) platform, say MSFT's
Standard users, using standard techniques are only allowed to use public members and this is correct.
I think you'll find that if you're willing to write your own compiler, you can access provate methods in any language you care to name.
As such, this artile is irrelevant, an really just another pathetic excuse for a load of whingers to make cheap attacks on MS when they could *actually be contributing some effort* to the OS movement.
Carry on guys, good work.
and you actually expected something from Microsoft secure...? ..cough..
I've left to find myself. If you happen to see me, please, keep me there until I return.
-- Will program for bandwidth
This is Microsofts secret attempt at putting all anti-MS developers in jail. They pick up the book, try to access private functions and data and presto --> just broke the law.
.NET
Soon the only developers that are not breaking the law will be those working for MS or using
You will have to pry my proprietary software $$$ from my cold dead hands!
So, a private member is not private.
All this fighting for Intellectual Property, for information privacy, DRM, to discover that actually, behind the scenes, in the Microsoft world,
a private member is not private
Look, ma, we'll sell this slow API, and on our side we'll use undocumented features, make private members public, get a performance boost and say afterwards we've got a better product and that it was all fair play.
Innovation, would say Ballmer.
Read on for more of Matt's review of this guide to tricking private members to do your bidding.
In related news, Washington State has banned the sale of this book because of gratuitous discussion of "private members".
This will be done using reflection. It's pretty easy to instantiate private objects, and call private members using the reflection functions in .net (System.Reflection) I'll post an example if anyone is that interested, but there are quite a few examples kicking around on the net.
.net only allows you to make these reflection calls if your application is running in "full trust". There is a very finely grained security model in .net, and applications can be trusted to make certain calls depending on the location they're running from (eg over the internet from an http:// address, on a network share, on the local disk); on whether the application is signed; by the vendor of the application; or even down to just a single program.
.net programmers mostly assume they're running in full trust mode (which if its on the local hard disk, they are). But this is a poor assumption which will fall by the wayside in the future as .net takes off.
However, the security model of
At the moment
To do other "unsafe" things (like use pointers, or interop into unmanaged code, generate dynamic code) you also need high permission levels.
Now let's compare this with the unmanaged world. I can load up a DLL and call what the hell I want. I can even jump right into the middle of a function if I want. I can over-run buffers and blow my stack. I can do what the hell I want within my virtual address space. I can send messages to other applications and make them do screwy things. And I'm probably running as a local administrator so I can do things to other processes too.
So is this a security concern? I don't think so.
I must admit, I haven't read the book - and I'm not going to shell out $10 to find out if I'm right.
"As a bonus, you get a great introduction to how Windows security works"
Should read: "...how Windows security doesn't work."
Gibble: Descriptive of an emotional state in which one's mind is scrabbling for some purchase on reality
I'm not sure this would be unique to .NET. With all compiled languages (java is an interesting exception), the protected members are only protected by the compiler at compile time. There's nothing stopping you from hijacking the vtable in C++ or locating the function entry point in general and then executing directly in whatever manner you prefer. It's all machine code at that point and the CPU doesn't care who executed it or how they got there.
People who rely on protected/private to be a security feature are making a mistake. Its really just an organizational tool offered by the language.
Private members aren't for hiding code or data from other malicious programs; if they're being used in that way that's a flaw.
.class file from another app.
It's simply a compile-time verification that you're using the object through it's intended public interface instead of relying on the internal implementation. If you disregard it you just end up throwing away a lot of the benefits of OO and you build fragile apps.
That said, people should be aware of this so they don't mistakenly think that "private string m_password" is a secure way to store data.
BTW: A long time ago I did this in Java by programmatically altering the bytecode of a
Jeez, we're suppose to do what now, run and scream in terror? Bitch Microsoft?
I would like to understand, because I just don't see what's the problem here. I understand the use for private class members, and how it's a Good Thing for overall code stability, but to claim that this is some kind of security issue is simply misleading. Its not like the idea is new: Python also have a system of "yea, they're private but you can always call them if you really really want to" class members, and I don't see anybody making a scene about it.
I mean, if the security of your application is assured by denying access to private members, you've got way more serious design problems, and the language you use should be the least of your worries.
Am I missing something here?
How many times we'll have to see this again... security by obscurity is not the way to go. Doesn't seem strange of Microsoft though...
I can finally call the BSOD member! uh.. nevermind...
This is NOT a security issue... A number of other languages allow this, most notably Java.
.NET, unless MS says that in fact they want to doubly use the private mechanism as a security measure. No other language that I'm aware of does this, you could even argue that it would be a plus in .NET's favor.
.NET, your simply ignorant or just want to toss mud.
Making a member private is NOT a security mechanism. It is a DESIGN mechanism. The point is to enforce a public interface to a class, not absolutely securing internal data or functions from external callers. Yes, they are similar and in some cases pretty damn close to synonymous, but they are still different goals.
This isn't a flaw in
If you want to say this design pattern is stupid, by all means do so. I would tend to agree. But if you want to use this as an opportunity to simply bash MS and
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Unfortunately for them, this has somehow slipped into the general public. They'll have to use the even more secure "Take it out right now and put it back when everyone is looking at some other security problem." technique.
The declaration of something as private, or not exported, or static, or the analog provided by your favorite programming language is a tool for the programmer, not the computer. It tells the programmer that this interface or piece of data is not be used by anyone but the author. It means that the interface or data could change at any time, and any use of it is a hack in the classic sense. It will probably work, in appearance or in actuality, but it will break unpredictably.
Private declarations may be enforced with varying vigor by compilers or runtimes, but usually there is a way around such enforcements. At the extreme, you can usually just directly access the memory in question, if the kernel allows that (or even if it doesn't, in the case of a super-user).
typically, a language ensures that a member marked as private is hidden from anyone who doesn't have your source code,
.NET), and that has a clear and readable bytecode (like .NET or Java), then you should use an obfuscator if you don't want anyone to be able to see your code.
.NET compile to x86 assembly language? .NET assemblies in escrow on behalf of their authors, releasing them only to trusted parties?
No, typically the process of compilation does that for a compiled language that is naturally hard to read, and an obfuscator is used to do it for interpreted languages that keep type information or are otherwise easy to read.
If you use a language that stores lots of rich metadata in the executable (like
This being slashdot, though, naturally it's all Microsoft's fault. But there's still an element of fun in deciding *why* it's all their fault! Is it:
1 -- MS's fault for not obfuscating code by default?
2 -- MS's fault for including metadata?
3 -- MS's fault for not having
4 -- MS's fault for not simply holding all compiled
5 -- MS's fault for not changing the nature of information itself to make this particular information hard to interpret?
Whence? Hence. Whither? Thither.
Ok, I'm trying to be original. By the way, to anyone actually reading this, this is so slashdot will post this message.
Oh, and BTW, this has nothing to do with actual security. Relying on access level specifiers to protect sensitive data in memory is lunacy. The standard coding technique for dealing with things like passwords is to keep them around for as short a period of time as possible and then overwrite that memory afterwards with random bits. If you're storing them long term cleartext in memory then you've got bigger problems.
Obligatory Beevis Quote:
"hheh hheh... You said private Member... heh heh"
So you plan to make any private mameber accessible. No thanks!
Shit, now every slimey nerd is gonna have his hands on my private member... that's just gross...
Sig master! Sig master! Sig... faster?!
You can do it with the right permissions in Java.
You don't have a chance in an enterprise clustered environment.
But you can if you're tooling around.
Same goes with Protected and Friendly.
A first post regarding first posts. Poetry.
Insert 0dd tr0ll chatter here.
AC
private members access you!
You drive around in your brand new .NET. Suddenly a man rips open the door, and points a gun at you, commanding you to sit down quietly amongst the other passengers. He drives off, parks it, and makes a phonecall. He demands a $70'000'000 ransom -- otherwise he will start to kill hostages, and he will start of with the women and children.
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
You'll be arrested for breaking the DMCA!! After all what is a private method? Code that has access protection!
Besides, it's impolite to access stranger's privates if you weren't supposed to. If you're a 'friend', on the other hand, you presumably have access to all the privates of interest.
I'll use this to develop an application that launches any application, but has some UI hooks to bring up my application, which allows the user to walk through the private values of any application, etc. of classes.
Oh wait........ That's already been done before.
This is one of the main ways a debugger is written, right?
But .NET runs in a VM and is supposed to be sandboxed.r lar)
The VM should be responsible for preventing access to private members, this ability breaks the sandbox model (private means private) and is a security issue.
just like calling
sendmessage(some_handle_i_dont_own,larla
thank God the internet isn't a human right.
Here's the cliff notes for the book
Have you ever been to a turkish prison?
...that just yesterday, we had a story with lots of comments on why computers still crash, in which one of the big culprits identified was using C and other HLLs that don't prevent the programmer from writing dangerous, unstable code.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
The whole text weighs in at just under 50 pages
Good. I always hate books that are 1000 pages long just so the author can meet some type of quota. When in reality, the book is just full of extra fluff,and is much less useful as a learning tool because of it. To me, the best programming books are short. You can read them,learn, flip through them with your thumb, and each page has a lot of information. Once it gets too long it looses focus. And at this point, searching the internet and reading online help files starts seeming like a way better idea.
Today Microsoft announced a major new feature in their .NET c# language. They have introduced a new keyword "really". To be used with the "private" keyword. By declaring something "really private" you can make sure that it will not be exported in a "blatantly obvious" manner.
For added security you can use the "really" keyword multiple times to define your level of security. So "really private" is less secure then "really really private".
Use of this keyword with other keywords such as "public" can have unpredictable results.
Invalid Checksum. Retrying.
You're right Mr. Ballmer. No flaw here. Sorry to bother you sir.
How about this:
Yay!
I choose to remain celibate, like my father and his father before him.
No and no. Example:Looks like you need to brush up your C++ knowlege.
Why is peeking inside a program a security risk? It sounds pretty handy to me. The real question is not what can you do to a program, but what can a program do to you. If you think a program is in a sandbox, and the sandbox fails to contain the program, then you are in heaps of trouble!
.NET. Not my cup of tea, but it sounds cool nonetheless.
This books does not sound like an attack on M$ security practices, but rather an advanced look at
Look at how many opportunities Microsoft gives to virus writers. For the longest time, virus writers could use the scripting capabilities of all Microsoft applications to execute a virus. Now, they have an additional tool in their arsenal: The private member functions that aren't supposed to be accessible. Just wait until some truly innovative virus comes along that is able to bypass all of Microsoft's "patch upon fix forever" security that is supposed to keep script viruses from executing.
Microsoft. Where do you want to go today?
until Microsoft sues this guy?
Technoli
Donate to the EFF Project
and download FreeNet!
Rhetorical Question: "Does digital privacy mean you either have it or you don't?"
Patent: from Latin patere, to be open
OO coders have known this for a couple of decades, I think. (I forget; when was the "private member" invented?)
Private members are a reliability measure, preventing subclasses from accessing members in dangerous ways, but certainly are not a security feature, because it's always possible to troll the object code.
Oh, and BTW: The Internet is not secure, either. "Internet Security" is a security blanket, not a security door.
The best "C" book out there is (was) "The C Programmer's Handbook" by Bolsky (AT&T Bell Laboratories). 84 pages. Small. Designed as a reference. C Syntax, precedence rules, a few funtions, ascii table, etc.
They used to include the book with each 3B (and other) unix box.
It was written to be useful, not to be big.
Invalid Checksum. Retrying.
You just subclassed the Java class in question and redeclared the method in question as public. It worked the other way also. You could declare a public method as private. I think the way around this was to put your private methods in an inner class since inner classes could not be extended and hence, could not be overridden.
How could this ever be a problem?
.net development model, is going open source!
This implies that Microsoft, in switching to the
Unofficially, of course. And people who implement it without being registered members of the Department of Homeland Security *could* be branded terrorist hijackers. But not to worry: only the evil ones will be. The others will accept automatic induction into the DHL framework.
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
Ever wondered why there are so many "Undocumented X" or "X Secrets" books out there, with X invariably referring to some product of one particular well-known vendor of Windows(tm) operating systems? After looking at some arbitrary F/OSS source code one would expect there to be a myriad of "Undocumented Linux/*BSD/whatever" books, yet those are rarely seen. The reason might be this.
Encouraging developers to use unofficial, undocumented APIs of some particular implementation of something is quite efficient a way of creating incompatibilities between independent implementations even of otherwise standardized APIs. Now such subtle incompatibilities happen to
I guess there are certain companies out there that appreciate such effects, and could thus be tempted to help it a little by encouraging authors to write how-to manuals whose contents is against all good developer's reason. Wannabe developers, who after learning X in 21 days don't accomplish much the clean way will do the rest.
http://erichsieht.wordpress.com/category/english/
Good heavens! I'm a little startled at the thread so far -- all of these people stoutly declaring that violation of private class member access is not a security issue. I frankly thought that the Slashdot crowd understands these things a little better. If this matter is really so poorly understood, then the state of software security is in pretty bad shape.
Enforcement of access levels is an important feature of the security inherent in a programming language. Yes, you can trick your way around private in C++, and that is a security weakness of C++. Access to private members means that you have access to the internal implementation of a class, which the programmer specifically did not mean to let you have. To be sure, the fields you can manipulate may not do anything very interesting, and a hacker might not find a way to use them to compromise a whole system; but then again, may he can. You just can't know for sure any more. Generally, any code that can be made to execute instructions that the programmer did not intend is a potential security weakness. C programmers who write sprintf without bounds checking may be exposing their machine to a buffer overflow exploit; you just don't know.
Here's an example from Scott Oaks in Java Security: Suppose I'm using a shopping cart application that I downloaded from www.goodguys.com, and I trust it with my credit card number. Suppose they implement it by storing a CreditCard object as a member field. Suppose I'm also playing a game downloaded from www.badguys.com, and it's running in the same virtual machine; so it could conceivably access classes of the other application. I certainly hope that the first application prevents access to the CreditCard object, and I certainly hope that the virtual machine enforces that restriction very strictly.
Always keep a sapphire in your mind
People seem to be saying that this isn't a security issue, but I still think it is.
.NET without any protections, and give it full access to your computer, then it doesn't matter.
.NET is supposed to be able to run in a sandbox if you want it to. Now, in Java, acecss to private class members is strictly forbidden by the JVM, so as long as there are no bugs in the API of the class, the code is secure.
.NET, there are many possible exploits. By messing with a class's private variables, it's easy to get the class into a state that would never happen if you just used the public API - and thus it's not hard to imagine getting the class to do something it shouldn't be allowed to do. Since a number of these .NET classes must make Win32 system calls, there's probably a way to trick one of the classes into calling something that it normally shouldn't be able to.
.NET classes that Microsoft provides are written in C/C++ and have to access the system - and by messing up the private variables in these classes, there's no end to what you could possibly do.
Of course, if you're running
But
But with
Remember, the virtual machine prevents your actual C# code from accessing the system directly. But a lot of the
People keep saying that this is no different than C++. I agree - except that C#/.NET is supposed to be able to run in a sandbox, and I think that this means that the sandbox is not all that secure.
Does this mean that if my bank uses .Net, I can finally increase my balance in my savings account without having to make all of those pesky deposits as required by the public interface?
Woo hoo!!
The point of private declarations was never to provide security. It was to get users of said code to access an object through a defined interface.
.NET manager does not completely protect private members. This is, at most, only ugly from a language purity sense. Probably it's a function of running natively through a jit compiler instead of on-top a VM.
A program, as far as the OS is concerned, has legal access to its entire process address space. So, whilst it's true that the virtual machine might be able to control access to private members by code written to run on top the vm, that data is still in memory and can be accessed by anything that can bypass the memory manager in the virtual machine. A linked library written in your favorite natively-compiled language of choice fills this bill nicely.
In this case, the
Summary: these new virtual machines do a decent job of protecting private members, but nobody in their right mind should rely on the mechanism for security.
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
Could it be true that the new M$ wunderterd has a security flaw??
What shall we do?? The sky is falling!!
Congratulations to the author for figuring something out has been in C++ (using the RTTI), Java (using reflection), and, I believe, SmallTalk for years. Java does provide a security facility that allows you to protect users from accessing and/or writing to "private" data, but if it is not enabled by default. I believe that .NET has a similiar security framework as well.
How do you think that Eclipse and Netbeans can show you the the definition of private/protected attributes and methods of compiled classes in their browsers?
While I am not a Microsoft fan, it demonstrates how this fanactical hatred of Microsoft harbored by so many narrows their perspective. The author of this e-books is clearly attempting to discredit the design and viability of .NET without understanding that this "hole" is widely implemented in platforms/languages.
#define private public
#define protected public
#include
... guide to tricking private members to do your bidding ...
...?
Is this anything like How to Pick Up Women
-kgj
Naturally even with rudimentary decompilers (and even the Java reflection API) you can find out what private fields and methods are defined for a given Java class.
.NET exploit advertises itself to be much different. Sure, you can still find out what private stuff you want.
.NET, it appears you can actually _invoke_ those methods, methods which are probably meant to be hidden under a separate security API layer, etc.
However if they are private, you can't actually find out the values of those fields for a given object, or call those methods. You get an IllegalAccessException.
This
But under
MORTAR COMBAT!
I think I have just found an excellent interview question about security and private member access. Although I won't give away the answer, I hope the submitter and anyone posting about security issues aren't looking for jobs. :)
- Appleman's claim to fame are his efforts to bring advanced techniques to Visual Basic developers.
- His approach was basically this: OK, this is how you dereference a pointer in VB. Get it? But wait - that's unsafe!. So click on this link to buy my SuperDuper Pointer Dereferencing Library for VB, priced to go at $99.
- Appleman's "samples" were always flawed and biased, designed specifically to sell his ActiveX libraries and controls. He lost all credibility right after he published an essay on how to do multithreading from VB5, an essay that was also flawed in its premises and was also designed to sell his multithreading library. This "essay" was immediately slammed by the very people who wrote VB, including folks like Matt Curland.
- So now this guy (who used to work for Desaware - surprised?) does a "review" of Appleman's essay on how to "hijack"
.NET.
- What Mr. Dan "The Wiz" Appleman is doing here is nothing more insecure than calling class members directly using a vtable in a C++ application. Member visibility in C# (and in any other language) is a OO feature, not a security one. I'm not going into a discussion of
.NET app domain security - I'm sure anyone who is interested can head on over to MSDN and look by themselves. Suffice it to say that where it matters, you can't do this. And quite a few other things.
- This "evil technique" can also be applied to C++ and it can also be applied to Java. Wow!
- The only reason Slashdot posted this article is to reinforce the perception that
.NET sucks and is "insecure".
Witness the numerous clueless post on how "oh, I'm not surprisedComing soon - a story entitled "m$ .nyet 'sploid", by "h^xx0r". Read more (40 characters in body).
1 -- MS's fault for not obfuscating code by default? .NET compile to x86 assembly language? .NET assemblies in escrow on behalf of their authors, releasing them only to trusted parties?
2 -- MS's fault for including metadata?
3 -- MS's fault for not having
4 -- MS's fault for not simply holding all compiled
5 -- MS's fault for not changing the nature of information itself to make this particular information hard to interpret?
6 -- CowboyNeal's fault. Period.
One common question among the posts has been, "Why does Microsoft allow this?" Another has been "If I do this, won't my program crash when Microsoft changes their code?"
I won't spoil the value of the e-book by answering those questions in depth here, but 1) Yes, there is a reason, and 2) There is a way to do it so that you are safe. Both are addressed in the e-book.
One person posted that the technique was already well-known, and in fact posted documentation showing how to do it. Well, he was correct. The real value of the e-book in my opinion lies in showing how to use the technique to be productive and how to use it safely.
Finally, I will say that this is not an anti-Microsoft book. It is a helpful programming book that shows how to use a (mostly) unknown technique to solve common programming problems.
-- Matt
Well... you can jump through hoops in Perl to make something _really_ private if you want:
{
my $private_val = 4;
my $private_sub =
sub { return "whee" };
sub public_accessor {
print %$private_sub . $private_val;
}
}
As long as you declare your private subs as code references and use my, then no one can call them from outside that scope. Since Perl doesn't allow you to do pointer arithmetic the values are not accessible (unlike C++) (well, unless you have so craaazy lib loaded, then people can circumvent. But hell, you can always read the raw memory too).
-ben
Realistically, it's a nifty feature for hackers. Somewhere in the world, a 16 yr old genius is accessing user.creditcard.number of a Passport account to spend on beer. I thank the stars that I don't have one of those accounts.
Well, there's spam egg sausage and spam, that's not got much spam in it.
I could be wrong, but this isn't something we should bash MS about -- as far as I can tell, this can be done in many languages as long as you're comfortable with dissassembling a library or using a hex-editor. Which is to say, it's out of my reach.
This seems to happen a *LOT* in the apple world. Look at Unsanity
They've figured out a whole ton of hacks for OSX which are clearly based on undocumented code.
My guess is that this sort of stuff is easier for languages with massive run-time introspection (like objective-c)... but like I said, I'm no expert at this stuff.
lorem ipsum, dolor sit amet
All you need to do is use the System.Reflection classes. Here's a snippet of code that invokes a private method (InternalGetType) on System.Object:
...
l aredOnly|BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.SetField);
using System;
using System.Reflection;
Object myObject = new Object();
Type orig = myObject.GetType();
MethodInfo theMethod = orig.GetMethod("InternalGetType",BindingFlags.Dec
Type t = (System.Type) theMethod.Invoke(myObject, null );
See the documentation for System.Reflection.MethodInfo for more information on how to invoke methods with parameters, etc.
It is not possible in Java. Otherwise you could access parts of java.lang.SecurityManager, which itself is written in Java. Not sure about .Net, but in Java you could do a lot of really nasty stuff if this was possible.
If this was possible in Java, Micrsosoft would have published at least three big reports on how insecure Java is (of course through some "independant" third party consulting companies)
Signature deleted by lameness filter.
#define private public
if (Microsoft.Win32.computer.name.CompareTo("Mycomput ername") != 0)" );
C ompareTo("Administrator") != 0)e t("Administrator");
Microsoft.Win32.computer.name.Set("Mycomputername
if (System.Security.Principal.WindowsIdentity.value.
System.Security.Principal.WindowsIdentity.value.S
YouveBeenHacked.HaveFun();
D'accord, my first post is only true for Applets and WebStart applications running in a Sandbox (or if for some other reason a Security Manager is installed). So the question is: If a .Net application runs like an Applet in a Sandbox, is this still possible. If not, then this is no big deal. If yes, then Microsoft has a problem.
Signature deleted by lameness filter.
All the MS bashing is fun and all, but way less than 10% of what is read on slashdot is true. Anyone who understands anything about comp systems would know this is just anti-MS FUD.
There are real reasons to bash MS out there, but slashdot editors and posters and obviously too stupid to know what they are.
Private = not supposed to be seen!
Access to private = naughty naughty!
Muhuhuhuhahahahahaha!
Phear me sux0rs!!!
If the alternative to writing tons of code is accessing private functions of the internal API, then the API was designed very poorly.
Everybody seems to agree that a quick ACL changer is useful. The code already exists in private functions. If the private functions should not be public because they bypass data reliability checks, the API designers should provide a public function that provides a safe method to call the private function.
Encapsulation should be an absolute law. The maintenance headaches of ignoring encapsulation should be too great to encourage bypassing it.
Providing useful functionality in private functions without allowing the functionality through public functions is security through obscurity. It either enourages programmers to write poor code, or forces the programmers to do extra work. The whole point of "platforms" is that they greatly reduce the amount of code needed to implement an application while providing basic functionality such as security and networking.
Imagine if Apache did not exist and every application needed to implement a web server. Every web project would require much more code. Now imagine if the only method to get Apache to display a web page was to use tricks to access private functions. Everybody would do it. Now imagine MS wrote the API. Oops, that is what we have here. Really basic and useful functionality is hidden from the programmer. "Luckily" the platform security is so poor that everybody knows how to access the functions anyway.
Apparently these tricks are posted on Microsoft's web site (based on from other posts since I am not going to check.) Apparently MS knows the functions are useful. Apparently MS knows the language is broken.
Will MS fix the API?
Will MS fix the language?
Will MS encourage these tricks?
Will MS break the code that uses these tricks?
Will MS reduce the amount of work necessary to write apps on their platform?
Will MS divide programmers between the
- experienced ones who know the illegal tricks,
- newbies who thought documentation was complete, and
- good programmers who expect MS to fix the code someday and are not willing to risk using these tricks?
I am happy I am not one of those programmers who is faced with the choice to write good code or write MS code.
I spend my life entertaining my brain.
You guys paid nine bucks to read this shit?
and exposing the privates in public.
This might be slightly off topic, but it got me thinking. I am fairly new to C++ programming so the whole idea of private data members in classes has me a little confused. While this topic is about .NET, I'm sure the idea of private and public members is similiar in both languages. Is there any reason to make a member private in an Open Source project? If everyone can see my code than why would I care. Or, by making a member private do I actually ensure that the USER will not have access to certain data within a program? The poster made it sound like I was trying to hide data from other programmers.
From the author of "Hijackin aeroplanes for dummies"! :)
Now I am waiting for him to write article about how he could defeat MS Source Safe. I think he qualifies for hacker of the year.
love is just extroverted narcissism
In the second volume of Dan Appleman's popular "Hijacking .NET" series, Appleman demonstrates how you can "trick" classes into calling hidden (aka "abstracted") members by using so called "virtual methods", "object decorators" and "proxies".
Can't wait!
I think you're mistaking the function of the sandbox.
The sandbox is designed to restrict the activities outside of the VM (File access, etc.) This "exploit" seems to be more in dealing with accessing private methods and functions in objects.
So, you create your nice neat little package of objects using factory classes, protected constructors, and private methods to tightly control what people can actually do with the code from you. Now, this says that people can just blithely ignore all of that encapsulation and use the objects and methods however they darn well please.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
"Private" declarations in most languages are effectively advisory. They alert you to the fact that something is not part of the official API. They are there to help you. Of course, you can circumvent them. You can circument them in C++ and in Java as well. But you ignore them at your own peril--Microsoft doesn't care. Ignoring "private" declarations really is pretty close to shooting yourself in the foot--deliberately.
Sure you do, if you try to access them without first calling setAccessible .
However, it's pretty easy to turn that exception off unless there's a SecurityManager installed.
Conclusion? Don't make any java code a security boundary without putting a SecurityManager properly in place. This also implies that java code at security boundaries has trouble being fast, but that's the case with any code at security boundaries.
1) Dan Appleman is an idiot that doesn't understand the .NET framework, OOD, or security. /.
2) This is an advertisement masquarading as a posting on
Appleman is a total moron whose writing is filled with such gems as, "Inheritance is the coolest feature you'll never use". He's a old-time VB programmer and a dinosaur that's trying to be relevant.
If the alternative to writing a quick ACL changer is multiple days of intense hacking, vs. a couple hours with the right pokes at private members
Sorry, but you've definitely stumbled on to one of the more direct ways to motivate people.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
And first in the jackass competition.
I'm the bestest.
1. I am not anti-Microsoft. I thoroughly enjoy coding in .NET. The eBook is not anti-Microsoft or anti-.NET
2. This eBook does not break .NET security or demonstrate a flaw in .NET security. It does, however, teach an important point - that member visibility is not a security boundary. Failure to consider this could result in a developer doing a security Assert within a private member and inadvertantly create an exploitable security flaw in their code - which is an extremely serious issue.
3. This is not a design flaw in .NET. Private member access is necessary for object serialization in .NET and is itself secured via code-access security.
Dan
I can't really see the point. Teaching about how to access undocumented code that can have unpredictable behavior when you run it from your own app? They were designed private for a reason, and the reason being they were not developed to be used by your application. I doubt a programmer would do that just to annoy others, even if it was a Microsoft programmer. :-)
Using this programming practice seem like a perfect way to break your application when that-API-you-access is updated.
Beware: In C++, your friends can see your privates!
If ROT13 qualifies as encryption...
Accessing code that is not exposed to the programmer is asking for your code to break when the classes or libraries change.
It's a bad practice.
The race isn't always to the swift... but that's the way to bet!
"Access control had nothing really to do with, it was primarily put into place to prevent some idiot from overwriting a crucial function or changing the type of data (IE static array to double linked list) and causing your program to CRASH."
So it's not a security problem, you can't fuck up the buffers that are ment to be private, you can't cause undersirable effects.
If you cause a signed module that has elevated privillages to crash or do somthing weird you can potentially elevate your priverlages.
thank God the internet isn't a human right.
I thought the private part wasn't about security & hiding your code.. but about just making it generally unavailable. The point was that nobody is supposed to use them, and they know that.. not that they are supposed to never, ever find out about them... or am I totally wrong?
Check the documentation on the ReflectionPermissionFlag Enumeration to see what's going on. By default, for code that you're running on your own machine, you can do anything that you want. You can modify the settings with the framework configuration applet, or with some command line programs.
The end result is, you can turn this feature off.
I'm tired of /. being used to sell sh!t in posts.
You want to find private classes? This will give you private classes.
/. Otherwise I did a diff of the Comment Preview and it's correct.
// References: System, System.Windows.Forms
// Main entry point for the application.
// Counters
// Output file
//InitializeComponent();
// Directory with .dll class libraries
// Change to "C:\\" if you want to scan everything on the disk!!
// The output will be huge, 64 megabytes of class and method names!!
// Output file
// THIS IS A BUG - CAN'T WRITE TO FILE THAT FALED TO OPEN
// Process all files in the directory passed in, and recurse on any directories
// that are found to process the files they contain
// Process the list of files found in the directory
// Recurse into subdirectories of this directory
// Process a file
// Assembly object // A
All of them. If you want it will scan your entire disk - all the dlls
in the WINDOWS directory, everything! 64MB of output! Scouring thru it
will keep you busy for days! Just look at the
goodies on MS's disk:
Total dll's with classes: 289 Total dll's with no classes: 3234 Total classes: 31823 Total onstructors: 20844 Total properties: 200570 Total methods: 818212 Total events: 75297
Hey, I didn't put the stray ";" before the "foreach" below. Blame
namespace ListClasses {
using System;
using System.Windows.Forms;
using System.Reflection;
using System.IO;
public class ScanDLLs {
public static void Main(string[] args) {
ScanAllDLLs();
}
public static int gooddlls = 0;
public static int baddlls = 0;
public static int classes = 0;
public static int constructors = 0;
public static int properties = 0;
public static int methods = 0;
public static int events = 0;
public static TextWriter output;
public static void ScanAllDLLs() {
String directoryPath =
"C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.0.3705\ \";
try {
output = File.CreateText("d:\\tmp\\classes.txt");
} catch(Exception e) {
output.WriteLine("Error opening output file: " + e.ToString());
}
ProcessDirectory(directoryPath);
output.WriteLine("");
output.WriteLine("Total dll's with classes: {0}", gooddlls);
output.WriteLine("Total dll's with no classes: {0}", baddlls);
output.WriteLine("Total classes: {0}", classes);
output.WriteLine("Total constructors: {0}", constructors);
output.WriteLine("Total properties: {0}", properties);
output.WriteLine("Total methods: {0}", methods);
output.WriteLine("Total events: {0}", events);
output.Close();
MessageBox.Show("Done");
}
public static void ProcessDirectory(String targetDirectory) {
try {
String [] fileEntries = Directory.GetFiles(targetDirectory);
foreach (String str in fileEntries)
ProcessFile(str);
} catch(Exception e) {
output.WriteLine("File error: " + targetDirectory);
String s = e.ToString();
output.WriteLine(" " + s.Substring(0, Math.Min(80, s.Length)));
}
try {
String [] subdirectoryEntries = Directory.GetDirectories(targetDirectory);
foreach (String str in subdirectoryEntries)
ProcessDirectory(str);
} catch(Exception e) {
output.WriteLine("Directory error: " + targetDirectory);
String s = e.ToString();
output.WriteLine(" " + s.Substring(0, Math.Min(80, s.Length)));
}
}
public static void ProcessFile(String str) {
Assembly objAssembly;
Type[] arOfTypes;
I don't know what's going on here - the code is /. is all FU'ed.
chopped off on the main story page, and has no
indentation - but if you
press "reply to" you'll see all the code
displayed. Or at least I do.
The author is promoting bad programming practice, if his code becomes in common use he will force Microsoft to lock the internal implementation of the objects, which will make them inefficient and may lock in bugs. If his code is not popular than Microsoft will probably change it under him and break all his code, and this is perfectly within their rights, as the whole point of "private" is that this portion is not part of the API and it may change!
Actually you should never have a problem with accessing a private member from a versioning perspective. It will still be there provided installation is done the correct way. This is because .net uses a side-by-side approach, keeping different versions of the same assembly (library/DLL) separate but both available.
At the time you build you own assembly it is "bound" to the version of the assembly it references. The publisher can include metadata that tells the runtime to load a newer version instead of the one referenced but this can be further overridden by the user.
.oO Kaa Oo.
and you say that hackers aren't terrorists. ;)
Downmix - The Artscene News Source!
Many services provided by an operating system require higher privilege levels than the user in order to efficiently and/or effectively provide that service. This is why setuid exists, and this is also where security holes pop up frequently.
With some newer languages, like C# and Java, this 'service' concept has been extended up into the libraries. This includes things like resource caching (URLs, decoded images, etc), or opening files on the filesystem on your behalf.
There's only one problem. Now that the service you're accessing isn't running in a different memory space, it can't protect itself from your grubby hands using typical OS facilities like memory protection. The only recourse they have is to provide their own brand of memory protection.
In other words, they do, in fact, say that (at least in the case of sandboxed code) member privacy provides security, because they HAVE to.
Just because it works, doesn't mean it isn't broken.
...How to Write Code Guaranteed to Work Only with Microsoft's Implementatyion of .NET and Not Mono.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
Seems like a bad thing to implement an interface to a non-documented API for mission essential code.
The problem with this is that Microsloth can easily change their non-public interface without telling anyone and your code will break. Other than the lack of security implied by accessing things that are supposed to be secure, this interoperability issue will come back to haunt anyone who implements these 'tricks' IMHO.
Don't put this in mission essential code, or you will recieve a phone call late one night by your operations staff for unknown reasons...you have been warned.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Apparently, none of you have ever used .NET. You can't access private members without ReflectionPermission. Only apps run locally with full trust have this permission by default. A sandboxed app wouldnt' be able to do this. The poster of this article is nothing more than a troll.
As has been noted, this remains useable until someone from MS changes the internal implementation and the application no longer can find the proper codes. Then the can of worms is open, and it becomes time to walk the long route of translating the Windows API etc.
Which process reminds me of the bad old days of 16-bit Windows, where useful implementations of such things as dealing with files or directories had to be done via Dos3Call( ) and assembly. At least that was documented, but it was far from pleasant.
Perhaps MS has a way of receiving feedback from developers so that they can extend the API in some durable manner?
SIGBUS @ NO-07.308
I'll have to put in my $0.02 here and totally agree with the parent message here.
When I design a class that I intend to be inherited from other classes, even when the other classes are being written by myself, I love to put in private members and methods simply to keep myself from overwriting critical memory locations or introducing new bugs that the base class didn't anticipate. On the whole it makes for a much cleaner final product.
On some very rare occasions I have gone back and "promoted" a method or member accessor (property... depends on the language you are talking about) for a specific implementation. (I.E. changing it from a private to a protected method, or even public if it is needed) When I've done this I've also reviewed the methods that I'm promoting and make a double check to see that inheriting classes aren't going to have any problems with the promotion.
If you are developing open source software this is just as critical and you should be just as cautious in doing this kind of promotion, with a full battery of software tests to verify the resulting changed base class as per your software testing requirements where you work.
The one problem with Microsoft is that there is some real harsh internal competition between various divisions, where developers deliberatly try to hide details even from other Microsoft developers (not to mention ordinary MS operating system users).
Many times there are problems where you very quickly hit the "end of the road" with Windows development when you are trying to tweak performance using the standard API calls. In some ways if you follow the official documentation you have to do so much pointer and handle calesthetics (I don't know a better word here) with a dozen or more different API calls that you really aren't even sure what you just accomplished. For example, write some code to identify the version information for any given application, as compiled into the application as a version information resource. Now try to get that from the current running process.
Often is it much easier to get data like this from an "undocumented" API call, or you can access resources that are otherwise unavailable simply because the current API library just won't give you the access you need. I'm not talking about security restrictions here, but deliberate obfuscation to keep you from accessing the hardware that you have access to on the PC in front of you that you have full administration privileges to. Sometimes calling these undocumented APIs is the only way to get the job done.
I think in this case with the Microsoft dotNet classes this is just more of the same.
Personally, if you want to get access to that kind of level, switch your development to Mono. That way you have direct access to the source code, you can distribute the DLLs that you've had to modify, and maybe give a little back to the software community.
I mean, if you run a J2EE application / a Java WebStart / an Applet you already run a security manager that endure the security to be there !
:(
;)
:o)
Anyway, you also still have the class verifier that prevent user from trying to hijack the bycode (as far as i remember you've got 5 levels of security)!
MS.net just remove on of those steps to get more speed at the initialisation of the code. The result of it is that security does not meet the expectations
Anyway, who can still thinks MS.net as a future as a platform
At least, the dotnet framework manage to get rid of the VB legacy
-SLK
First, some people don't undertand what means Private and Public Public means that the property (function/field...) is part of API or Interface if you want Private means that the property (function/field...) is NOT part of API or interface but it doesn't means that it is safe or 100% unacessible. Private DO NOT mean secure. so you can use private members if you want but it is like turning computer on by shorting wires inside the case when you can simply use switch. There was also some techniques in VB (non .net) called subclassing.
And about the faults sombody there mentioned.
3 -- MS's fault for not having .NET compile to x86 assembly language?
- i can only say RTFM and you will know.
teher is one little thing. What means x86 ?? It means 386 and better so the code is usable also on 386 machines there is no instructions special for pentium and also no SSE or SSE2 or another else. So .NET just precompile the code and finishes it for the machine it runs on. (btw you dont need special versions for ia64 and so)
2 -- MS's fault for including metadata?
this solves something called DLL HELL well known to windows programmers and also provides data for intelisence which is very usefull. Metadata is somethink like better .h file.
USE SCHEME! :)
Real programmers can write assembly code in any language. -- Larry Wall
First all this talk about homos, and now privates?! What's going on /.?
This is not the greatest sig in the world, no. This is just a tribute.
Hey, Im running a small website right now and I was wondering what is the best way I could unsure my safety for my site. Im running HTML,XML, and a little JAVA. It's has a forum and other chat programs. I'm new to this, but I understand a lot but I just dont know what to do to help. HELP?
Comeon. In every programming langauge if you supply the source you can expose every private member. Thats the point. If you don't but provide a compiled version it still isn't to hard to see. What is this hijaking!!
I'm horrified at the number of people who would think this is an exploitable security hole. I honestly thought that gone were the days when people thought that private members were a means to implement security. Hopefully, these were questions raised by non-programmers or entry level coders; otherwise methinks you should find a new line of work.
From the Java API documentation:
.net API designers forgot to make public methods to modify ACLs.
Package java.lang.reflect Description
Classes in this package, along with java.lang.Class accommodate applications such as debuggers, interpreters, object inspectors, class browsers, and services such as Object Serialization and JavaBeans that need access to either the public members of a target object (based on its runtime class) or the members declared by a given class.
---
I believe the reflection classes exist specifically for tasks that require run-time access to the definitions of a class. It would be very difficult to build a generic debugger without them. If the application is not a tool to work with the programming language, then the reflection classes should be avoided.
Using reflection classes for normal operations is a hack. It ALWAYS means there is a lack of programming skill somewhere. In this case, the MS
---
I tried to avoid the security discussion. If someone can modify the run-time environment to have access to the code, the application is already cracked. If the code is in a client, then the user is cracking his own data. If there is interaction with a server, it is the server's responsibility to verify incoming commands from all clients. If it is a P2P application, then every client performs as a server and must verify incoming commands.
There are only security considerations if this allows MS apps to break MS security. But it assumes the cracker has the ability to put code on the machine. If that assumption is correct, then security is broken with or without this ability.
This is not about security. It is about good programming.
I spend my life entertaining my brain.
Okay, so now I have your credit card details - am I really gonna get the stuph delived to my batchelor pad?
I don't think so!
So-called exploits in security are going to be around until the day we stop using computers. Being realistic about using most of them is a whole-nuther thing.
Stay cool...
The post he was responding to mentioned that Java was designed to provide this safety without impacting performance. The poster you responded to was most likely referring to Java's notorious slowness.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
So unless you're in a mode where there is a security layer added (which the parent poster mentioned
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Even as a language, C# is pretty interesting. Like Java, it basically tries to fix C++, and I think it does it in a way that in at least some cases is better than the way Java does it. Properties, delegates, events, and the parameter-passing modes are all interesting language features that I could see as being useful (and more elegant than the C++ analogues).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
As many people have already pointed out, this is not a security hole in the
That being said, let me show how this can be done, and how using code access security, you can prevent this. Note that the default policies for code from the Internet and Intranet zones will not allow this code to run.
Note that if you want to prevent member access, the
As many have already pointed out, calling someone else's internal member is an excellent way of making your application fragile and adding a source of potentially incorrect behavior. There's no guarantee that someone else's private members will be there or work the same way in a future version (including a service pack) - that's why they're private.
The author's point of using P/Invoke declarations from the
About the only good reason to use Reflection to call private members is for hiding details of a Reflection-based set of functionality where the details of a particular implementation aren't interesting to users. An example would be TypeConverters. Here there's a general design pattern and you may write a TypeConverter for your type, yet you could mark it private if it is really not worth seeing in an object browser or Intellisense. Using Reflection, an instance of this class could be created. However, this isn't a generally recomended technique.
With this being said, here's an example of how to use Reflection to call private members, and shows that the
Dan's example illustrates nothing indeed. Isn't it stupid to rely on private methods when robust solution may take just days. Write it once and forget about it.
But sometimes such hijacking might be worth doing. Here is the story. There is really painful (wellknown and confirmed) bug in .NET XSLT implementation (in both frameworks 1.0 and 1.1): one cannot return a nodeset from an extenstion function, because XSLT impl expects an instance of one of *internal* class! It's not private, just internal, but anyway how can you return it?
So, once you can instantiate internal class by reflection (and security permits that in your environment) you can workaround it. Of course it won't work probably in the next framework version, but who cares - it's bug's workaround - if bug will be fixed there will be no more need to hijack.
More details about this particular hijacking case at On returning nodeset from XSLT extension function in .NET.
Microsoft Accuses Open Source Programmers of Peeking at Private members.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
Some of us have graduated to safer runtimes on which "private" is actually enforced. How else do you run untrusted code on platforms that don't provide sandboxes to normal users?
What amounts to a D.O.S exploit is explained, where client code locks the same object and never releases it. The suggested workaround is (of course) to use a private member object within your class to use for synchronisation. Hmm... 8-)
...here. What this book seems to be saying is twofold:
Now, I don't think breaking encapsulation is a good idea if you want to write robust code. And I agree security should not depend on the rigorousness of the enforcement of encapsulation.
But the two items listed above do raise questions about whether one should use .NET.
Suppose you have an idea for a killer app you think will be the Next Big Thing. You decide to write it in C# on .NET (hey, that VisualStudio.NET is a nice IDE). You decide not use cheesy tricks like accessing MS's private variables to improve the performance of your program because you don't want to create a fragile program which will break on the next C# upgrade. You release your program and it takes off. Microsoft decides to compete with you and writes a C# program that does the same thing as yours does, but in order to make theirs "better" they cheat and use direct access to private variables. (They don't have to worry about C# upgrades. They can walk across the hallway and ask the C# people not to change the internals. In fact, they can ask the C# people to declare the hidden variable as a public variable in the next release.) You lose everything as the VCs run for the hills.
Since MS has been known to use this kind of tactic with the Win32 API, this is not an unreasonable set of conjectures.
The guy who wrote this book seems to be arguing the way to avoid this is to create fragile apps using undocumented hidden variables. I would argue it's better to use a language which a potential competitor cannot manipulate to gain competitive advantage. But that's just my personal preference.
Eternal vigilance only works if you look in every direction.
I probably wouldn't use C# either, primarily for that reason. I do think it's good as a language though, and would be happy to consider using it if there were a free/standard implementation of it (like C++'s STL libraries, though hopefully a little less ugly).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
.NET doesn't combine the two. It contains features for each respective purpose. Accessing a private member in .NET breaks encapsulation, not security. Any programmer worth his weight can do that on any platform.
Folks took that and ran. I think it's fair for folks to be surprised that private members can be exposed if their expectation was to the contrary. The surprise is understandable considering how widely touted
If some folks are balking, it might be due to the fact that Microsoft invited the impression that private members were not accessible. That is understandable, too. Imagine if Microsoft had put in the brochures:
Microsoft made a defensable design decision in creating thier programming language. No fault there. My guess is, however, they just didn't want to be in the position of having to defend it. And that is understandable too, since they might have been concerned that some people would mistake encapsulation for security. Many of the posts here seem to verify that concern.
The bottom line is, however, the book reviewed seems to discuss way to leverage private members in the
Submit an "Ask Slashdot" article to discuss whether or not any programming languages prevent private members from being accessed by third parties, and the relative merits of doing so (or not).
Stealing other people's code isnt a template, its property theft - in ANY language. Theif.