Jump to content
  • Advertisement
Sign in to follow this  
WISMAK

C++ access specifiers are binaries????

This topic is 4869 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I created a simple class for testing purposes to see how C++ is serious about memebr access specifiers. Inside the DLL module a simple class with a private/protected member. Inside the client EXE program I used the same header for class definition with a change to the protected/private member to public so that I thought I could access it breaking the C++ protection mechanism. Using Visual C++ toolkit 2003 the program still cannot resolve the public symbol in the class since it's declared in the DLL as protected/private. This is a good thing; however, it's not true for GCC and Intel C++ under Linux. Which behaviour is more accurate and is it possible to do the same under the Linux? It seems that MS has stronger programming platforma nd more secure. Thanks for your help in advance.

Share this post


Link to post
Share on other sites
Advertisement
public/protected/private are tools to prevent yourself from shooting yourself in the foot, not "anti-hack" tools. You want to see an easy way to break it?

#include <iostream>
using namespace std;

class foo {
private:
int variable;
public:
void set_variable( int v ) {
variable = v;
}
};

class bar {
public:
int variable;
};

int main() {
foo f;
f.set_variable( 21 );
//f.variable is protected, right?
//wrong:
std::cout << ((bar *)&f)->variable << std::endl;
}



As far as I know, the results of this code are officially "undefined" (something to do with POD types may apply, I don't know for certain). That said, I'd be suprised if the program didn't print out "21" and end with pretty much any compiler.

Share this post


Link to post
Share on other sites
Accessing a object in two different translation units using two different class definitions had undefined behavior. As such, saying one compilers definition being more correct than anothers is meaningless.

That being said, it's really meaningless to be trying to test your compilers level of protection against bypassing access restrictions. To quote Stroustrup himself "The C++ language access control mechanisms provide protection against accident - not against fraud". There are large number of ways to access a private or protected member without using different definitions in different translation units.

Share this post


Link to post
Share on other sites
Sorry I'm not asking about a way to hack a predefined class. I want to make sure is it a compiler feature in MS VC++ that it has more solid protection and integration with language semantics, or is it a result of undefined behaviour and I should not count on that?

And if so how should I PREVENT such hacking?

Share this post


Link to post
Share on other sites
Quote:
Original post by WISMAK
Sorry I'm not asking about a way to hack a predefined class. I want to make sure is it a compiler feature in MS VC++ that it has more solid protection and integration with language semantics, or is it a result of undefined behaviour and I should not count on that?
Not really. It's a little more tricky in MSVC++, because of the way it uses import libraries, but it's by no means impossible, nor even particularly hard.
Quote:
And if so how should I PREVENT such hacking?

You can't. They're running the software on THEIR processor, after all....the data's right there.

Share this post


Link to post
Share on other sites
You'd have to intentionally keep two seperate definitions of a class in order to be able to accidentally shoot yourself in the foot with this, and you've got bigger issues than this if you're doing that.

Here's the relevant questions with regards to this "feature":

Q1) Will it prevent me from accidentally shooting myself in the foot?
A1) Possibly, but I think you're more likely to be struck by lightning than be helped by this. Implementing this feature is a waste of time (my opinion).

Q2) Will it prevent me from intentionally shooting myself in the foot?
A2) No.

Q3) Will it prevent someone else from shooting myself in the foot?
A3) No.

Neither behavior is more "accurate", this "feature" will neither help you program or debug (make the platform "stronger"), nor will it protect your code from being hacked (make the platform "more secure").

Share this post


Link to post
Share on other sites
I'm not shooting myself and never intend to do so.

I'm asking for god sake about if it's a feature in MS VC++ or is it something results as an undefined behaviour. geeze.

Share this post


Link to post
Share on other sites
When a class declaration is compiled each attribute and method belonging to the class has it's name mangled....

class test {
int someval;
};


The compiler turns someval into something that looks like "??test@someval@i@@aexx". If you change the access qualifier from public to private the mangaled name (signature) of that attribute also changes. If you compile the dll with one header then compile an application with another header the symbol cannot be resolved at link time (because it's CHANGED).

Access qualifiers are applied at compile time (and link time due to mangled name signatures) NOT at runtime.


edit: the above applies to class names, method names, and static members. data members are offest from the pointer of an instantiated object.

Share this post


Link to post
Share on other sites
Quote:
Original post by WISMAK
I'm asking for god sake about if it's a feature in MS VC++ or is it something results as an undefined behaviour. geeze.


It's simply a difference between the compilers, not a bug, not a feature, just a difference. It dosn't help make the platform more secure nor stronger. That's what I'm trying to get at.

Would I leave the behavior as is for the Microsoft Compiler? Sure, don't fix what ain't broke.
Would I leave the behavior as is for the GNU Compiler Collection? Sure, don't fix what ain't broke.
Would I leave the spelling of my name as it is? Sure, don't fix what ain't broke.

I was simply trying to illustrate and provide sustinance to this opinion. If that offends you, well, I just hope you arn't planning to become a scientist. Or a polititian. Or a philosopher. Or religious. Or anything else that might involve trying to back up one's opinions/beliefs, or dealing with people who care to do the same.

-Mike

Share this post


Link to post
Share on other sites
No it does not offend me at all, but all the answers are totally irrelevant to the question.

In my opinion it's a very strong MS Visual C++ feature and it's not about name mangling.
It's about binary level protection mechanism which should be part of the standard.

Share this post


Link to post
Share on other sites

This topic is 4869 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!