Erzwungene Friend Klasse

Simon2

volkard schrieb:

...

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

...

Superhack !
Gefällt mir !!

Gruß,

Simon2.

CStoll

Ich bin mal vorsichtig und bezweifle, daß du damit etwas korrektes herausbekommst. Der Standard schreibt afaik vor, daß Member einer Schutzebene in der richtigen Reihenfolge im Speicher stehen, aber nicht, in welcher Reihenfolge die einzelnen Schutzebenen aufeinander folgen - da könnte dieses "#define private public" dir recht schnell die Anordnung der Member verändern (und da andere Teile des Programms mit der Originalklasse arbeiten, erhältst du womöglich Datenmüll).

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.

Simon2

Hmmmm,

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.

Dravere

Hmmmm, also bei mir hat es nun funktioniert. Die Sache ist übrigens folgende. In diesem Programm arbeitet man nur mit den Shadowklassen. In einem anderen Programm arbeitet man mit den normalen. Die eigentlichen Klassen sind in einer DLL.

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

Simon2

Hi,

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.

Dravere

Simon2 schrieb:

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

volkard

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.

volkard

Dravere schrieb:

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).

volkard

Simon2 schrieb:

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.

Simon2

Hi Dravere,

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.

Simon2

volkard schrieb:

...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.

volkard

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.

Dravere

Die DLL ist aber von mir

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

volkard schrieb:

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.

Simon2

Dravere schrieb:

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.

Th

Welche IDE verwendest du denn?
Mit dem MS Visual Studio kannst du doch direkt die DLL debuggen, in dem du sie ausführen läßt (natürlich als Debug-Version kompiliert) und dann gibst du beim Start das Hauptprogramm an und los geht's mit der Fehlersuche...

HumeSikkins

volkard schrieb:

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).