Infos in exe

[Jan]

Wenn ich eine mit Xbase++ erstellte exe oder dll mit einem Editor ansehe, dann stehen da neben allen Ausgabetexten auch die vollständigen Pfade zu den obj-Dateien drin, die komplette Manifest-Datei, die Strings der Codeblöcke. Alles im Klartext. Irgendwie stört mich das ein wenig. Kann man das irgendwie umgehen?

Jan

[georg]

Hallo, Jan -


hast Du die in Frage kommenden Programme mit oder ohne Debug-Informationen erstellt? Bei Debug-Informationen stehen diese Informationen nämlich drin, um dem Debugger zu helfen, die Quellen zu lokalisieren.


Gruss,

Georg

[Jan]

Hallo Georg,

neu kompilieren und linken ohne Debuginfos ändert nichts daran. Nur die Codeblöcke sind raus, ansonsten ist weiterhin alles im Klartext drin.

Jan

[AUGE_OHR]

Kann man das irgendwie umgehen?

es gibt ja EXE "Packer" ... ob die mit Xbase++ EXE / DLL funktionieren ...

[UliTs]

Ich setze einen exe-Packer genau aus diesen Gründen ein.
Außerdem wird die exe-Datei dadurch bin 15 auf 1,6 Megabyte verkleinert .
Uli

[psp]

upx hilft da ungemein, kann man auch die DLLs packen und alles ist danach noch lauffähig (wird ja auch nur in den Arbeitsspeicher entpackt)

es hat auch den Vorteil, dass nur ein Teil der Daten durch das Netzwerk geschoben werden müssen, wenn man die Programme auf Servern startet

[brandelh]

Bei den Resourcen die Windows direkt anzeigen soll, kannst du nichts ändern, sonst zeigt der Explorer die Infos falsch an.
Ansonsten könntest du die Texte z.B. als HEX Wert oder codiert (crypt, base64 etc.) eingeben.
Am Besten macht man das mit einem Hilfsprogramm in das man den Klartext eingibt, diesen umsetzt und auch gleich die Gegenfunktion baut die man im Programm braucht.

Beispiel:

oXbp:caption( MeinText("48616c6c6f2057656c742021") ) => "Hallo Welt !"
function MeinText(cHexString)
... 2 Zeichen im cHexString, geben 1 chr. Pablo hat Umrechnungsfunktionen. 0x48 = "H"
... oder 3 Zeichen "072" => chr(val("072")) => "H"
... oder Crypt oder eine eigene Routine
return cNormalString

[Rolf Ramacher]

Ich habe es gerade mit meinem Programm editor ausprobiert. Es ist nicht mit debugger compliliert. -- habe ich auch, aber nur 1 kleinen Teil stücken. ab und zu - das meiste ist nicht zu lesen

[UliTs]

upx hilft da ungemein, kann man auch die DLLs packen und alles ist danach noch lauffähig (wird ja auch nur in den Arbeitsspeicher entpackt)
es hat auch den Vorteil, dass nur ein Teil der Daten durch das Netzwerk geschoben werden müssen, wenn man die Programme auf Servern startet

Funktioniert dies bei upx auch mit ALLEN xBase-Libraries?

Uli

[Tom]

UPX funktioniert nur mit statisch gelinkten Informationen und lauffähigen Dateien, also prinzipiell nicht mit den Laufzeitbibliotheken. Außerdem ist das kein wirklicher Schutz gegen Datenextraktionen, da man UPX-gepackte EXEn auch mit UPX wieder entpacken kann, ohne sie auszuführen. Zudem läuft man quasi automatisch in andere Probleme etwa mit Virenscannern, von denen nicht wenige UPX-"verpackte" EXEn standardmäßig in Quarantäne schieben. Viel Aufwand um etwas zu erreichen, das man ohnehin nie sicher erreicht. Und ausführbare Dateien sollte man nur dann vom Netzwerklaufwerk laden, wenn es wirklich nicht anders geht.

[UliTs]

Also ich packe auch die Laufzeitbibliotheken soweit möglich. Nur wenige gehen nicht .
Was für einen Vorteil siehst Du, wenn Du sie lokal startest? Was ist dann mit den zugehörigen DLLs?
-
Ist es nicht ein großer Nachteil, wenn man neue Versionen einspielen will?

Uli

[Tom]

Wenn ich lokal starte, erzeuge ich keinen Netzwerktraffic. Wenn ich übers Netz starte, müssen - je nach Ausstattung, Programmgröße und verwendeten 3rd-Party-Libs - mehrere hundert MB zu jedem Arbeitsplatz geschaufelt werden, und wenn das bei mehreren Arbeitsplätzen geschieht, zwinge ich damit das Netz in die Knie. Außerdem ist es so gut wie unmöglich, ausgelieferte ActiveX-Komponenten sicher von/auf einem Netzlaufwerk zu registrieren.

Die Anwendung verteilt sich bei/nach Installation eines Updates automatisch. Eine Spiegelung der Installation wird unterhalb des Datenbankverzeichnisses auf dem Server abgelegt, und jede Instanz, die gestartet wird, prüft, ob da was Neues liegt. Wenn das der Fall ist, aktualisiert sie sich.

[brandelh]

So habe ich das vor Citrix bei uns auch gemacht (Clipper und Xbase++ Anwendungen).

[Tom]

Bei Citrix- und TS-Kunden geschieht das zuweilen auch noch, wenn beispielsweise mit mehreren Servern gearbeitet wird. Fünfzig Remoteverbindungen auf einem Server sind gelegentlich ein bisschen viel.

[azzo]

Hallo Tom, hallo Uli,
unter anderem aus diesen Gründen habe ich meine Installationen auf Remote Desktop umgestellt.
Nur Bildpunkte werden übertragen, updaten ist einfach und zB ein Editieren der exe geht da auch nicht.
mfg
Otto

[Tom]

Hallo, Otto.

Wir haben von der Einzelinstallation auf einem lokalen Arbeitsplatz, der zugleich sein eigener Server ist, bis zur Serverfarm, die Multifilialbetriebe per TS oder Citrix hostet, alles, außerdem noch einige hundert Installationen mit ADS und knapp tausend ohne. Und zudem "Software as a Service" mit mehreren Partnern. Wir schreiben die Installationsweise nicht prinzipiell vor; theoretisch geht es auch, die Anwendung auf einem Server zu installieren, obwohl man im klassischen Netz arbeitet. Aber wir empfehlen das nicht.

[azzo]

Hallo Tom,
> Aber wir empfehlen das nicht.
Gibt es Gründe, warum du eine Remoteinstallation nicht empfiehlst.
Für uns wird damit vieles einfacher. Z.b. das Einbinden von Apple , Ipad, IPhone, Android, etc..
Bei den „Kellnerfunkterminals“ gibt es eigentlich keine andere Alternative. Der Funk ist zu störanfällig. Wenn man da seine Daten über das Funknetz hin und her schickt gibt es nur Probleme.
Vielleicht sind uns die „Schattenseiten“ noch nicht ausreichend bekannt. Deshalb frage ich nochmals.

Mfg
Otto

[Tom]

Missverständnis. Was wir nicht empfehlen, das ist die Installation der Anwendung auf dem Server in einem herkömmlichen Netzwerk. Das hat zwar auch (theoretische) Vorteile, etwa die einfachere Wartbarkeit, aber die Nachteile überwiegen. Remote ist eine andere Baustelle; hier ist zwingend, die Anwendung auf dem (fernzusteuernden) Server zu installieren.