Puis-je accéder aux membres privés de l'extérieur de la classe, sans l'aide d'amis?

J'ai ajouté un l'entrée de mon blog (voir ci-dessous) qui montre comment il peut être fait. Voici un exemple sur la façon dont vous l'utilisez pour la classe suivante

struct A {
private:
  int member;
};

Il suffit de déclarer une structure pour l'endroit où vous le décrire et l'instanciation de la classe d'implémentation utilisée pour vol

//tag used to access A::member
struct A_member { 
  typedef int A::*type;
  friend type get(A_member);
};

template struct Rob<A_member, &A::member>;

int main() {
  A a;
  a.*get(A_member()) = 42; //write 42 to it
  std::cout << "proof: " << a.*get(A_member()) << std::endl;
}

La Rob modèle de classe est définie comme ceci, et ne doit être défini une fois, quel que soit le nombre de membres privés vous envisagez d'accéder à

template<typename Tag, typename Tag::type M>
struct Rob { 
  friend typename Tag::type get(Tag) {
    return M;
  }
};

Toutefois, cela ne montre pas que le c++de règles d'accès ne sont pas fiables. Les règles de la langue sont conçus pour protéger contre les chocs, les erreurs - si vous essayez de voler les données d'un objet, la langue de par sa conception ne prend pas de détours pour vous empêcher de vous.

Hmmm, je ne sais pas si ça allait fonctionner, mais peut être vaut la peine d'essayer. Créer une autre classe avec la même mise en page que l'objet avec les membres privés mais avec privé changé pour le public. Créer une variable de pointeur vers cette classe. Utiliser une distribution simple à ce point votre objet avec les membres privés et essayez d'appeler une fonction privée.

S'attendre à des étincelles et peut-être un accident 😉

Si vous pouvez obtenir un pointeur vers un membre d'une classe, vous pouvez utiliser le pointeur peu importe ce que les spécificateurs d'accès (même méthode).

class X;
typedef void (X::*METHOD)(int);

class X
{
    private:
       void test(int) {}
    public:
       METHOD getMethod() { return &X::test;}
};

int main()
{
     X      x;
     METHOD m = x.getMethod();

     X     y;
     (y.*m)(5);
}

Bien sûr, mon petit favori hack est l'ami de modèle de porte arrière.

class Z
{
    public:
        template<typename X>
        void backDoor(X const& p);
    private:
        int x;
        int y;
};

En supposant que le créateur de la ci-dessus a défini une porte dérobée pour ses utilisations normales. Mais vous voulez accéder à l'objet et regardez les variables de membre privées. Même si la classe ci-dessus a été compilé dans une bibliothèque statique, vous pouvez ajouter votre propre modèle de spécialisation pour backDoor, et donc l'accès aux membres.

namespace
{
    //Make this inside an anonymous namespace so
    //that it does not clash with any real types.
    class Y{};
}
//Now do a template specialization for the method.
template<>
void Z::backDoor<Y>(Y const& p)
{
     //I now have access to the private members of Z
}

int main()
{
    Z  z;   //Your object Z

    //Use the Y object to carry the payload into the method.
    z.backDoor(Y());
}

cool question btw... voici mon morceau:

using namespace std;

class Test
{

private:

  int accessInt;
  string accessString;

public:

  Test(int accessInt,string accessString)
  {
    Test::accessInt=accessInt;
    Test::accessString=accessString;
  }
};

int main(int argnum,char **args)
{
  int x;
  string xyz;
  Test obj(1,"Shit... This works!");

  x=((int *)(&obj))[0];
  xyz=((string *)(&obj))[1];

  cout<<x<<endl<<xyz<<endl;
  return 0;
}

Espère que cette aide.

Si vous savez comment le compilateur C++ mangles noms, oui.

Sauf, je suppose, c'est une fonction virtuelle. Mais alors, si vous savez comment votre compilateur C++ construit la VTABLE ...

Edit: en regardant les autres réponses, je me rends compte que j'ai mal lu la question et pensé qu'il était sur les fonctions de membres, pas de données sur les membres. Toutefois, le point est toujours debout: si vous savez comment votre compilateur dispose de données, alors vous pouvez accéder à ces données.

Comme une alternative au modèle de porte dérobée de la méthode, vous pouvez utiliser un modèle de porte dérobée de la classe. La différence est que vous n'avez pas besoin de mettre cette porte dérobée classe en zone publique de la classe de votre allons tester. J'utilise le fait que de nombreux compilateurs permettent classes imbriquées pour accéder à la zone privée de la classe englobante (qui n'est pas exactement 1998 standard mais considérés comme étant "de droite" comportement). Et bien sûr, en C++11 c'est devenu légal comportement.

Voir cet exemple:

#include <vector>
#include <cassert>
#include <iostream>
using std::cout;
using std::endl;
/////////SystemUnderTest.hpp
class SystemUnderTest
{
//...put this 'Tested' declaration into private area of a class that you are going to test
template<typename T> class Tested;
public:
SystemUnderTest(int a): a_(a) {}
private:
friend std::ostream& operator<<(std::ostream& os, const SystemUnderTest& sut)
{
return os << sut.a_;
}
int a_;
};
/////////TestFramework.hpp
class BaseTest
{
public:
virtual void run() = 0;
const char* name() const { return name_; }
protected:
BaseTest(const char* name): name_(name) {}
virtual ~BaseTest() {}
private:
BaseTest(const BaseTest&);
BaseTest& operator=(const BaseTest&);
const char* name_;
};
class TestSuite
{
typedef std::vector<BaseTest*> Tests;
typedef Tests::iterator TIter;
public:
static TestSuite& instance()
{
static TestSuite TestSuite;
return TestSuite;
}
void run()
{
for(TIter iter = tests_.begin(); tests_.end() != iter; ++iter)
{
BaseTest* test = *iter;
cout << "Run test: " << test->name() << endl;
test->run();
}
}
void addTest(BaseTest* test)
{
assert(test);
cout << "Add test: " << test->name() << endl;
tests_.push_back(test);
}
private:
std::vector<BaseTest*> tests_;
};
#define TEST_CASE(SYSTEM_UNDER_TEST, TEST_NAME) \
class TEST_NAME {}; \
template<> \
class SYSTEM_UNDER_TEST::Tested<TEST_NAME>: public BaseTest \
{ \
Tested(): BaseTest(#SYSTEM_UNDER_TEST "::" #TEST_NAME) \
{ \
TestSuite::instance().addTest(this); \
} \
void run(); \
static Tested instance_; \
}; \
SYSTEM_UNDER_TEST::Tested<TEST_NAME> SYSTEM_UNDER_TEST::Tested<TEST_NAME>::instance_; \
void SYSTEM_UNDER_TEST::Tested<TEST_NAME>::run()
//...TestSuiteForSystemUnderTest.hpp
TEST_CASE(SystemUnderTest, AccessPrivateValueTest)
{
SystemUnderTest sut(23);
cout << "Changed private data member from " << sut << " to ";
sut.a_ = 12;
cout << sut << endl;
}
//...TestRunner.cpp
int main()
{
TestSuite::instance().run();
}

tout simplement créer votre propre accès à la fonction membre pour étendre la classe.

"à l'aide de variables privées n'est pas 100% fiable pour faire respecter l'encapsulation, même en C++."
Vraiment? Vous pouvez démonter la bibliothèque dont vous avez besoin, trouvez tous les décalages nécessaires et de les utiliser.
Qui vous donnera la possibilité de modifier à tout membre privé que vous aimez... MAIS!
Vous ne pouvez pas accéder aux membres privés sans une sale de piratage.
Permettez-nous de dire que l'écriture const ne fera pas votre constante d'être vraiment constante, parce que vous pouvez
cast const ou tout simplement utiliser l'adresse de l'invalider. Si vous êtes à l'aide de MSVC++ et que vous avez spécifié "-fusion:.rdata=.les données" pour un éditeur de liens, l'astuce fonctionne sans aucun accès à la mémoire de défauts.
On peut même dire que l'écriture d'applications en C++ n'est pas fiable pour écrire des programmes, parce que résultant code bas-niveau peut être corrigée à partir de quelque part à l'extérieur lorsque votre application est en cours d'exécution.
Alors qu'est-ce que fiable documenté de façon à respecter l'encapsulation? Peut-on cacher les données quelque part dans la mémoire RAM et d'empêcher tout accès à l'exception de notre code? La seule idée que j'ai est de chiffrer les membres privés et de les sauvegarder, parce que quelque chose peut corrompre les membres.
Désolé si ma réponse est trop impoli, je ne veux pas offenser personne, mais je ne pense vraiment pas que la déclaration est sage.

Par le référencement *ce vous activez une porte dérobée pour toutes les données privées à l'intérieur d'un objet.

class DumbClass
{
private:
int my_private_int;
public:
DumbClass& backdoor()
{
return *this;
}
}

J'ai utilisé une autre approche utile (et la solution) pour accéder à une c++ privé/protégé membre.

La seule condition est que vous êtes en mesure d'hériter de la classe à laquelle vous souhaitez accéder.

Puis tout le crédit va à reinterpret_cast<>().

Un problème possible est que cela ne fonctionnera pas si vous insérez une fonction virtuelle, qui va modifier la table virtuelle, et donc, la taille de l'objet/l'alignement.

class QObject
{
Q_OBJECT
Q_DECLARE_PRIVATE(QObject)
void dumpObjectInfo();
void dumpObjectTree();
...
protected:
QScopedPointer<QObjectData> d_ptr;
...
}
class QObjectWrapper : public QObject
{
public:
void dumpObjectInfo2();
void dumpObjectTree2();
};

Ensuite, vous avez juste besoin d'utiliser la classe comme suit:

QObject* origin;
QObjectWrapper * testAccesor = reinterpret_cast<QObjectWrapper *>(origin);
testAccesor->dumpObjectInfo2();
testAccesor->dumpObjectTree2();

Mon problème d'origine était comme suit: j'ai besoin d'une solution qui ne signifie pas recompiler les bibliothèques QT.

Il existe 2 méthodes de QObject, dumpObjectInfo() et dumpObjectTree(), qui
travail juste si QT libs sont compilé en mode debug, et ils ont besoin de l'accès à d_ptr proteted membre (parmi d'autres structures internes).

Ce que j'ai fait a été d'utiliser la solution proposée pour ré-écrire (avec le copier-coller) ces méthodes de dumpObjectInfo2() et dumpObjectTree2() dans ma classe (QObjectWrapper), la suppression de ces debug preprocesor gardes.

but de l'étude seulement....
essayez ceci ....peut être utile je pense.....
ce programme peut accéder aux données privées juste en sachant les valeurs...

//GEEK MODE....;)
#include<iostream.h>
#include<conio.h>
class A
{
private :int iData,x;
public: void get()             //enter the values
{cout<<"Enter iData : ";
cin>>iData;cout<<"Enter x : ";cin>>x;}
void put()                               //displaying values
{cout<<endl<<"sum = "<<iData+x;}
};
void hack();        //hacking function
void main()
{A obj;clrscr();
obj.get();obj.put();hack();obj.put();getch();
}
void hack()         //hack begins
{int hck,*ptr=&hck;
cout<<endl<<"Enter value of private data (iData or x) : ";
cin>>hck;     //enter the value assigned for iData or x
for(int i=0;i<5;i++)
{ptr++;
if(*ptr==hck)
{cout<<"Private data hacked...!!!\nChange the value : ";
cin>>*ptr;cout<<hck<<" Is chaged to : "<<*ptr;
return;}
}cout<<"Sorry value not found.....";
}

class Test{
int a;
alignas(16) int b;
int c;
};
Test t;

méthode A : intrusif de l'humeur.
depuis qu'on a accès au code source et recomplie, nous pouvons utiliser
beaucoup d'autres comme ami de la classe pour accéder membre privé, ils sont tous des backdoor.

méthode B : brute de l'humeur.

int* ptr_of_member_c = reinterpret_cast<int*>(reinterpret_cast<char*>(&t) + 20);

nous utilisons un nombre magique (20) , et Il n'est pas toujours droit. Lors de la mise en page de la classe de Test changé, le nombre magique est un gros bug source.

méthode C : super hacker humeur.
est-il un non-intrusive et non-brute de l'humeur ?
depuis la classe de Test de mise en page de l'information est cacher par le compilateur,
nous ne pouvons pas obtenir des informations d'offset de la complie de la bouche.
ex.

offsetof(Test,c); //complie error. they said can not access private member.

nous aussi ne peut pas obtenir pointeur de membre de la classe de Test.
ex.

&Test::c ;  //complie error. they said can not access private member.

@Johannes Schaub - litb a un blog, il a trouvé un moyen de rob privé pointeur de membre.
mais je pensais que ce doit être complier de bug ou d'une langue piège.
je peux complie sur gcc4.8, mais pas sur vc8 complier.

donc la conclusion pourrait être :
le propriétaire de construire tous les de porte dérobée.
le voleur a toujours brute et une mauvaise façon de briser dans.
le hacker accidentelle est élégant et de manière automatisée à percer.