Es gibt ja das friend statement. Dadurch kann man in einer Klasse festlegen, welche anderen Klassen volle Zugriffsrechte haben, auch auf private und protected. Ich hätte dies allerdings gerne andersrum. Ich möchte in einer Klasse deklarieren, dass dieser Klasse gewisse andere Klassen volle Zugriffsrechte geben. Mal ein wenig Code um es zu verdeutlichen:

class CTopSecret
{
    // ...
private:
    int m_nTopSecret;
}

class CAllesWissenWill
{
    // ...
    HasToBeAFriend CTopSecret;

    void Funktion(CTopSecret& s) { s.nTopSecret *= 4; };
}

Gibt es da irgendeine Möglichkeit?

Grüssli

Grüssli

#include <iostream>
using namespace std;

class CTopSecret
{
    char dummy[43];
private:
    int m_nTopSecret;
public:
    CTopSecret()
    {
        m_nTopSecret=4711;
    }
};

int main()
{
    CTopSecret s;
	cout << *(int*)((char*)&s+44) << '\n';
	return 0;
}

#include alles, was TopSecret.h includet
namespace ich{
#define private public
#include "TopSecret.h"
#undef private
}
typedef ich::CTopSecret CTopSecretShadow;

Aber das mit der Idee zum Abtippen, find ich richtig gut. Muss ich dann Morgen unbedingt testen. Vielen Dank für die Hilfe. Ich berichte dann sicherlich ob es geklappt hat oder nicht ^^

Einzige Frage vielleicht:
Wofür das Namespace? ^^

Grüssli

Einzige Frage vielleicht:
Wofür das Namespace? ^^

damit du nicht aus versehen zwei definitionen der selben klasse leist, wo einmal so und einmal anders ist. das würde den compiler meschugge machen.
wenn du aber eine im namcespace liest, könnte es gehen. dann ist ja die gesamte klasse im namespace und deswegen ne andewre klasse als die originale.

aber tut eigentlich nicht not.

#define TopSecret TopSecretShadow
#define private public
#include "TopSecret.h"
undev private
undef TopSecret

...

#define private public
#include "TopSecret.h"
#undef private

...

Superhack !
Gefällt mir !!

Gruß,

Simon2.

Außerdem gibt es einen Grund, warum die Klasse selber sagen muß, WER ihr Freund ist - stell dir mal vor, jeder könnte ohne weiteres deine Freundschaft erzwingen, das würde das Schutzkonzept von C++ komplett nutzlos machen.

ich weiß nicht, ob es für den Compiler sinnvoll wäre, diese Reinhenfolge zu verändern, weil sie immerhin der Initialisierungsreihenfolge entsprechen muß. Da wäre es für den Compiler sehr viel einfacher, die "Gesamtreihenfolge" zu bewahren - aber das ist nur eine Mutmaßung, weil ich nicht wirklich weiß, wie konkrete Compiler intern arbeiten.

CStoll schrieb:

...
Außerdem gibt es einen Grund, warum die Klasse selber sagen muß, WER ihr Freund ist - stell dir mal vor, jeder könnte ohne weiteres deine Freundschaft erzwingen, das würde das Schutzkonzept von C++ komplett nutzlos machen.

Das ist bestimmt unbestritten !
Hier geht es aber wirklich um "Hacks" für Untersuchungszwecke (hoffe ich) .... deswegen genügt es auch, die Attributreihenfolge im Speicher des konkreten Compilers herauszufinden.

Gruß,

Simon2.

Ich weiss das ganze ist nicht wirklich sauber. Aber ich habe ein Programm, mit welchen man Dateien erzeugt. Und diese Dateien möchte ich gerne manchmal analysiseren, wenn irgendwelche Fehler im Hauptprogramm aufgetreten sind. Und ich kann doch eigentlich nur so, auf alle möglichen Variablen den Zugriff bekommen. Da wenn ein Fehler aufgetreten ist, ich den in der Datei auch korrigieren möchte, damit man diese nicht wegwerfen muss. Sind halt eine Menge Daten. Das bleibt aber ein Entwicklertool und wird natürlich nie ein Kunde zu sehen bekommen. Deswegen ist die Sicherheit auch Gewährleistet.

Grüssli

sind denn diese generierten Klassen unveränderbar ? Also wir haben hier auch SW-Generatoren, aber die unterstützen alle entsprechende "Userbereiche", in denen man eine "showInternals()"-Funktion implementieren könnte...
Oder Du modellierst sie entsprechend rein (ich weiß nicht welches "Programm die Klassen erzeugt").

Mit den hier genannten Methoden mußt Dir halt immer bewusst sein, dass die Ergebnisse dieser Analysen recht unzuverlässig sind. ...

Gruß,

Simon2.

Hi,

sind denn diese generierten Klassen unveränderbar ? Also wir haben hier auch SW-Generatoren, ...

SW-Generatoren??

Simon2 schrieb:

aber die unterstützen alle entsprechende "Userbereiche", in denen man eine "showInternals()"-Funktion implementieren könnte...

Ich habe in meinen Klassen keine Userbereiche, oder was meinst du?

Simon2 schrieb:

Oder Du modellierst sie entsprechend rein (ich weiß nicht welches "Programm die Klassen erzeugt").

Die Klassen sind in einer DLL. Und ich möchte am liebsten nicht diesen Klassen die Möglichkeit geben sich jemandem vollständig mitzuteilen. Denn dies wäre dann wenn schon ein Sicherheitsrisiko
Aber eigentlich geht es darum, dass die DLL und das eigentliche Hauptprogramm völlig unabhängig vom Analysetool bleiben.

Simon2 schrieb:

Mit den hier genannten Methoden mußt Dir halt immer bewusst sein, dass die Ergebnisse dieser Analysen recht unzuverlässig sind. ...

Und wieso jetzt genau? Wenn etwas mit dem Speicherbereich nicht mehr stimmt fällt mir das schon auf, wenn da "anscheinend" irgendwelches Durcheinander in der entsprechenden Datei herrscht. Analysieren tue ich ja selber, das macht nicht das Programm ^^

Grüssli

Der Standard schreibt afaik vor, daß Member einer Schutzebene in der richtigen Reihenfolge im Speicher stehen

was? wozu das denn? nee, das glaub ich net. würde ja ohne not jeden optimierer ausbremsen.

Hmmmm, also bei mir hat es nun funktioniert.

fein.

Die Sache ist übrigens folgende. In diesem Programm arbeitet man nur mit den Shadowklassen.

ändern wir mal den namen. shadow ist ein doofer namen und sagt zu wenig aus. ich bin für spy (englisch für spion).

ich weiß nicht, ob es für den Compiler sinnvoll wäre, diese Reinhenfolge zu verändern, weil sie immerhin der Initialisierungsreihenfolge entsprechen muß.

irrelevant. der compiler kennt die reihenfolge, wie die attribute im code stehen. das speicherlayout kann er anders machen.

struct test{
  char a;
  double b;
  char d;
};

sizeof(test) ergibt 24
klar besteht hier ein wenig umordnungsbedarf, das sollte der compiler auch von alleine dürfen.

Hier geht es aber wirklich um "Hacks" für Untersuchungszwecke (hoffe ich) .... deswegen genügt es auch, die Attributreihenfolge im Speicher des konkreten Compilers herauszufinden.

bestimmt wurde die dll mit dem gleichen compiler gemacht, wie die anwendung, daher hab ich ein gutes gewissen. und natürlich geht der code besser nicht in die produktion.

da habe ich Dich wohl missverstanden.

Dravere schrieb:

...Aber ich habe ein Programm, mit welchen man Dateien erzeugt....

Das hatte ich verstanden als "... ich habe ein Programm, mit welchem man Source-Dateien erzeugt ..." und bin deswegen von einem Softwaregenerator ausgegangen. Wenn Du allerdings meinst, dass Du Dateien hast, in "Daten liegen, mit denen ein Programm Objekte befüllt", liegt die Sache natürlich anders.

Aber dann habe ich Deine Aufgabenstellung noch weniger verstanden....

Gruß,

Simon2.

...der compiler kennt die reihenfolge, wie die attribute im code stehen. das speicherlayout kann er anders machen. ...

Dass er es kann, habe ich auch nicht bezweifelt. Ob es allerdings sinnvoll ist, weiß ich nicht.

volkard schrieb:

...bestimmt wurde die dll mit dem gleichen compiler gemacht, wie die anwendung, ...

Da bin ich mir nach Draveres letzten Posts nicht so sicher. Wenn er ein Programm schreiben will, was ein anderes (gekauftes ?) Programm emuliert, ist das gar nicht so wahrscheinlich.

Gruß,

Simon2.

Da bin ich mir nach Draveres letzten Posts nicht so sicher. Wenn er ein Programm schreiben will, was ein anderes (gekauftes ?) Programm emuliert, ist das gar nicht so wahrscheinlich.

wenn du vor der dominanz des ms-compilers die augen nicht verschließt, ist es wieder wahrscheinlich.

Also für Simon2 nochmals, was ich genau machen will bzw. tue ^^

Ich habe ein Programm geschrieben, das absolute Hauptprogramm. Zu diesem Hauptprogramm gehört eine von mir geschriebene DLL, welche alle Klassen beinhaltet, welche in eine Datei gespeichert werden, wenn man die Daten aus dem Hauptprogramm abspeichern will. Mit der DLL kann man also, wenn du so willst, die abgespeicherte Datei lesen. Ist alles von mir programmiert. Das Hauptprogramm ist allerdings ein wenig was älter, wie auch die DLL. Das Programm ist aber ziemlich umfänglich und da ich eigentlich nur eine Testperson habe, kommen die Fehler immer nach und nach. Da das ganze eben auch ein wenig älter ist, ist es noch ein wenig schlechter programmiert. Und die Fehler treten durch falsche Zuweisung oder sogar falsche Funktionsaurufe auf. Nun sind in gewissen Klassen falsche Daten drin. Die Daten sind aber geschützt und man kommt nicht an diese ran. Also der prüft zum Beispiel ob Daten x vorhanden sind und gibt erst dann Daten y aus. Wenn jetzt aber ein Fehler passierte und beim Speichern in x nichts reingetan wurde, aber nur in y, kann man die Daten nicht mehr abrufen. Jetzt kann man also die Datei löschen und neu anlegen, was nicht unbedingt sehr angenehm wäre, da man sehr vieles neu eingeben müsste. Ist als wenn du 1000 Seiten in Word löschen müsstest um einen "geschützten" Buchstaben zu ändern

Daher möchte ich dieses Tool machen, um die Fehler 1. direkt zu sehen und 2. direkt in der Datei zu beheben.
Und natürlich dann auch im Quellcode des Hauptprogramms oder der DLL

Jetzt verstanden?

Grüssli

Simon2 schrieb:

Da bin ich mir nach Draveres letzten Posts nicht so sicher. Wenn er ein Programm schreiben will, was ein anderes (gekauftes ?) Programm emuliert, ist das gar nicht so wahrscheinlich.

wenn du vor der dominanz des ms-compilers die augen nicht verschließt, ist es wieder wahrscheinlich.

Hmmm, naja, die Programme, mit denen ich hauptsächlich zu tun habe, sind in der Mehrheit mit IBM-Compiler oder gcc gewandelt (allerdings stimmt natürlich, dass es sich dabei nicht um Windows-Anwendungen handelt) und nur die absolute Minderheit mit Microsoft (meist nur Mini-TestProgramme).
Deswegen bin ich halt nicht so drauf gekommen.

Gruß,

Simon2.

Die DLL ist aber von mir

Also für Simon2 nochmals, was ich genau machen will bzw. tue ^^
...
Jetzt verstanden?

Grüssli

Ja !
Vielen dank für Deine Erklärung !

Ich würde trotzdem versuchen, entweder mit Debugger oder mit Tracing zu arbeiten.

Für den Debugger muß man natürlich die Fehlersituationen einigermaßen rekonstruieren können - aber das gilt für Deine "Überwachungsklassen" auch. Eigentlich willst Du mit denen ja auch einen "Debugger" schreiben.

"Tracingmöglichkeiten" vorzusehen, ist eigentlich immer eine gute Idee, aber natürlich auch aufwendig - aber da Du anscheinend sowieso immer wieder das Programm anpasst (zur Fehlerbehebung), kannst Du das nach und nach erweitern.

Das Problem bei Deinen Hacks ist einfach, dass Du Dir nie ganz sicher sein kannst, ob das, was "Dein Debugger" Dir liefert, wirklich den Speicherinhalten entspricht, oder nur ein Problem mit Deinem Hack.

Aber ich denke, zu diesem Thema ist hier eigentlich alles gesagt und Du weißt alles, was Du brauchst.

Viel Erfolg und Spaß wünscht,

Simon2.

CStoll schrieb:

Der Standard schreibt afaik vor, daß Member einer Schutzebene in der richtigen Reihenfolge im Speicher stehen

was? wozu das denn? nee, das glaub ich net. würde ja ohne not jeden optimierer ausbremsen.

Guckst du 9.2/12:

Nonstatic data members of a (non-union) class declared without an
intervening access-specifier are allocated so that later members have
higher addresses within a class object. The order of allocation of
nonstatic data members separated by an access-specifier is unspecified
(11.1). Implementation alignment requirements might cause two adjacent
members not to be allocated immediately after each other; so might
requirements for space for managing virtual functions (10.3) and
virtual base classes (10.1).