"Schutz" vor Resource Hacker(ResHack) ?

[dizzy]

Ähem... seht doch mal auf das Datum des Threads...

[negaH]

Du möchtest die resourcen schützen weil du darin zb. den Klassennamen der Indy Komponenten siehst. Das nützt dir rein garnichts den im normalen Codesegment deiner Anwendung stehen diese Klassennamen auch drinnen, als RTTI. Du müsstest schon ALLE Sourcen vom Indy so abändern das sie andere Klassennamen benutzen, du würdest also die OpenSource schon stehlen müssen. Naja, ist ja dann auch leicht zu behaupten das das alles auf deinem Mist geachsen ist.

Sorry für die harten Worte, aber ich bin gerade bei meinen Freware Komponenten schön öffters sehr enttäuscht worden. Besonders weil gerade Anfänger meinen sie könnte erfahrene Programmierer austricksen indem sie die Sourcen leicht verändern. Falsch gedacht ! sage ich nur, im DEC zb. sind versteckte Signaturen im Sourcecode enthalten.

Gruß Hagen

[negaH]

Datum ? ähm ja, interessiert mich aber jetzt nicht Vielleicht schreckt ja mein persönlicher Appell andere Leute ab eine solche Frage nochmal zu stellen. Ich weis nich wie es dem Frager gehen würde wenn man seine Freeware nicht würdigen würde und im schlimmsten Falle sogar klaut.

Gruß Hagen

[bigg]

Kurz gesagt, es gibt keinen Weg deine Programme zu schützen.

[dizzy]

Meinte damit ja nur, dass sich des Fragers Einstellung mittlerweile geändert haben könnte . Er war zum Erstellzeitpunkt ja scheinbar noch sehr neu.

Nichtsdestotrotz hast natürlich Recht. Es ist schlicht eine Sauerei fremde Sources als eigene auszugeben! Nur mir persönlich z.B. war bis jetzt eben nicht so deutlich klar, dass Indys Freeware/OS sind. Es ging wohl nur darum, dass man sich schämte vorgefertigte Dinge aus der Komponentenpalette zu benutzen (wobei das falsche Scham war - es ist ja gradezu clever, da man nicht das Rad neu erfinden musste ).
Aber das ist wie gesagt knapp 2 Jahre her.

[negaH]

Man muß sich keineswegs dafür schämen das man die Arbeit anderer Programmierer würdigt. Zudem veröffentlichen diese Programmierer ihre Arbeit damit alle davon profitieren können. Nun, WIR profitieren davon weil wir das Rad nicht nochmal neu erfinden müssen und so viel Arbeit und Geistesschmalz einsparen, warum dann sich schämen dafür? warum nicht diese Arbeit würdigen ?

Zudem, falls ich eine Software sehe die Indy benutzt so weis ich auf was für eine Qualität ich stossen werde. Da ich selber Indy gut finde werde ich dieser Softare eine Chance geben.
Da ich selber Freeware bevorzuge und auch produziere werde ich lieber Freeware benutzen, auch wenn sie manchmal notgedrungener Weise nicht so gut ist wie prohibitäre kommerzielle Ware.
Es gibt also keinen driftigen Grund sowas geheimzuhalten.

Gruß Hagen

[himitsu]

Ich sollte wohl mal meine InfileDataBase veröffentlichen, deren Datenbank ist erstmal nicht in den Resourcen und so gut wie garnicht im Programm zu entdecken - derzeitiger Nachteil (aber für meine Zwecke so gewollt), man kann keine Daten darin ändern, nachdem das Programm kompiliert wurde.

[negaH]

Zitat:

Resourcen und so gut wie garnicht im Programm zu entdecken

verstehe ich nicht. Du kannst in deiner DB zb. eine Resource wie eine DFM speichern richtig ? Und ich zb. der dein Program analysiert sollte nicht in der Lage sein die Klassennamen die in dieser DFM verwendet werden zu analysieren ? Falsch gedacht, das ist jederzeit möglich MUSS es sogar auch denn OHNE Klassen und Klassennamen der Komponenten KANN kein Delphi Program funktionieren. Alleine schon das Laden der DFM Resource durch das VCL Streaming System benötigt die Klassennamen als Strings in der Resource um die zu erzeugenden Komponenten mit den Klassen der RTTI im Codesegment zu verknüpfen. WENN als in der DFM der Klassenname notwendig ist so MUSS es zwangzläufig in der RTTI auch einen Klassennamen im Codesegement der Anwendung geben. Alleine aus technischen Gründen schon. Mir ist es nun Brust ob ich die DFM's lesen kann, die interessieren überhaupt nicht, da ich einfach das Codesegment der Anwendung nach den Klassen scannen werde. Dort finde ich Strings der RTTI wie TCustomForm, TObject, TStream, TidServer, TCipher_Rijndael usw. usw. usw. ADs Codesegement muß irgendwann zur Laufzeit unverchlüsselt im Speicher liegen, da ansonsten der Code nicht ausführbar ist. Und exakt dort wo die Klasse deklariert wurde wird im gleichen Codesegement die RTTI durch den Compiler gespeichert. In der RTTI der Klassennamen, bzw. der Typname des deklarierten Types der identisch bei Klassen mit dem Klassennamen ist. Sogesehen findet man in einer Klassen-RTTI den Namen der Klasse sogar zweimal gespeichert vor.

Es gibt nur eine Möglichkeit die Analyse zu verhindern ob man zb. Indy verwendet hat (in Bezug auf das analysieren der RTTI und Klassen). Nämlich Source klauen, alle Typen und Klassen umbenennen und neu kompilieren.

Gruß Hagen

[MaBuSE]

Zitat von negaH:

Alleine schon das Laden der DFM Resource durch das VCL Streaming System benötigt die Klassennamen als Strings in der Resource um die zu erzeugenden Komponenten mit den Klassen der RTTI im Codesegment zu verknüpfen.

Darf ich mich mal zu dem Thema selbst zitieren?

ich schrieb in http://www.delphipraxis.net/internal_redirect.php?p=322312#322312

...
Die einfachste Möglichkeit habt Ihr übersehen.
Programme die die Resourcen anzeigen, können das nur tun, wenn es auch welche gibt
Es ist relativ leicht möglich die Forms aus den Resourcen Verschwinden zu lassen.
Man muss sie nur selbst im Source erzeugen. (oder teilweise erzeugen)
...

Abgesehen davon kann man seine Programme nicht "schützen". Es wird immer eine Möglichkeit geben in das Programm zu schauen. (und sei es mit einem Debugger / DisASM)

Zitat von negaH:

Es gibt nur eine Möglichkeit die Analyse zu verhindern ob man zb. Indy verwendet hat (in Bezug auf das analysieren der RTTI und Klassen). Nämlich Source klauen, alle Typen und Klassen umbenennen und neu kompilieren.

Hallo?
Ich glaube Ihr habt hier in dem Thread etwas in den falschen Hals bekommen.

Ich glaube nicht das Pseudemys Nelsoni kriminelle Absichten hat, wie den Source Code der Indy zu stehlen. Es war wohl nur etwas unglücklich formuliert. Der Beitrag ist auch schon etwas über 2 Jahre alt.

Ich gebe Dir Recht,

• dass man die verwendeten Open Source Projekte (Komponenten) in den Credits würdigen sollte. (Das mache ich in der Regel auch)
• dass man sich nicht schämen muss externe Komponenten wie z.B. Indy zu verwenden
• dass es zu verurteilen ist, wenn man Teile aus Open Source Projekten als sein eigenes Ideengut verkauft.

Aber ich finde diese Diskussion hier unsinnig.
Pseudemys Nelsoni war wohl nur etwas erschrocken, das man die DFMs aus der Exe rekonstruieren kann. Er wollte nicht, dass man sieht wie viel Programmiererfahrung er hat (Das war vor 2 Jahren).
Dass er Teile von Open Source als sein Gedankengut ausgeben wollte, unterstelle ich Ihm nicht.
Die Indy Komponenten sind in die Delphi 7 IDE so gut integriert, dass es auf den ersten Blick gar nicht ersichtlich ist, dass es sich hier um Open Source handelt. Ich habe keine "große rote Hinweisdialogbox" gesehen, die mich darauf aufmerksam macht. Wenn er Indy nicht kannte, woher soll er wissen, das es sich um Open Source handelt?

Ich hinterfrage ja auch nicht, ob das TEdit Feld von Borland erfunden wurde, oder ob da "nur" ein Microsoft Controll angezeigt wird. Oder hat das sogar Apple oder IBM erfunden?

In den Lizenzbedingungen von Delphi steht z.B. auch nicht, dass ich in meinem About Dialog (Readme.txt) erwähnen muss, das ich eine TEdit von Borland Delphi benutze.
In den Lizenzbedingungen steht auch nicht, das ich angeben muss Teile des Programms unterliegen dem Copyright von Borland und Microsoft (und Apple, AT&T, Sun, oder IBM).

Aus diesem Grund glaube ich nicht an die kriminelle Absichten und verurteile niemanden hier!

Es ist wohl nur etwas unglücklich ausgedrückt worden.

Abgesehen davon ist diese Diskussion OffTopic und somit nach dem ""12"" nicht erwünscht.

mfg
MaBuSE

ps: @Hagen, ich möchte Dich nicht ärgern, das ist nur meine Meinung.

[himitsu]

Zitat von negaH:

Du kannst in deiner DB zb. eine Resource wie eine DFM speichern richtig ?

Also ich könnte da alles reinpacken, was ich wöllte, also auch etwas, was normaler Weise in den Resourcen rumliegt.

Und da außer dem Code für den Zugriff auf die enhaltenen Daten keiner weiß, wo sich diese Daten innerhalb der Exe befinden, ist es "schwer" diese Daten auch zu finden, und ´wenn dann noch 'ne Verschlüsselung mit eingebaut würde, wird es ja noch schwerer...