"Automatischen" Zugriff auf die Registry unterbinden?

[widaMaDelphi]

Hallo,

ich habe eine Anwendung in einem sicheren Umfeld, in dem jeder Zugriff aufs System gerechtfertigt sein muss.
Nun greift mein Delphi-Programm ohne mein Zutun auf die folgenden Registry-Keys zu:
HKCU\Software\CodeGear\Locales
HKCU\Software\Borland\Locales
HKCU\Software\Embarcadero\Locales
HKCU\Software\Borland\Delphi\Locales

Der Grund ist mir schon klar. Ich suche nach einem Weg, dies zu unterbinden (Multi-Lang-Unterstützung ist nicht nötig).
In den Projektoptionen habe ich dazu nichts gefunden, Google schweigt, und selbst wenn ich meine Executable im Hex-Editor ansehe sind diese Schlüssel zumindest nicht im Klartext eingebunden.

Habt ihr eine Idee?

LG

[dummzeuch]

Zitat:

Zitat von widaMaDelphi (Beitrag 1498268)

Hallo,

ich habe eine Anwendung in einem sicheren Umfeld, in dem jeder Zugriff aufs System gerechtfertigt sein muss.
Nun greift mein Delphi-Programm ohne mein Zutun auf die folgenden Registry-Keys zu:
HKCU\Software\CodeGear\Locales
HKCU\Software\Borland\Locales
HKCU\Software\Embarcadero\Locales
HKCU\Software\Borland\Delphi\Locales

Der Grund ist mir schon klar. Ich suche nach einem Weg, dies zu unterbinden (Multi-Lang-Unterstützung ist nicht nötig).

Dein Programm greift auf Registry-Einträge von BorCoDero zu? Da ist was faul. Diese Einträge gibt es doch nur auf Entwickler-Rechnern.

Wenn Du sie unterbinden willst, kannst Du die entsprechenden WinAPI-Funktionen hooken. Aber ich würde dort erstmal einen Breakpoint setzen und schauen, woher die Aufrufe überhaupt kommen.

[hoika]

Hallo,
tja, das kannst du wohl nicht verhindern

https://www.delphipraxis.net/1236697-post6.html

[Dalai]

Die Schlüssel sind im Klartext im Kompilat zu finden, wenn man in Unicode (UTF-16) danach sucht. Hier mal ein Beispiel eines mit XE2 kompilierten Konsolenprogramms:

Code:

Software\Embarcadero\Locales
Software\CodeGear\Locales
Software\Borland\Locales
Software\Borland\Delphi\Locales

Selbst bei alten Kompilaten aus Delphi 5 finden sich die beiden Borland-Schlüssel, dort natürlich als ANSI/ASCII.

Definiert sind die Schlüssel in der System.pas, zugewiesen an verschiedene Variablen. Verwendet werden die Variablen in

Delphi-Quellcode:

function InternalGetLocaleOverride

und dann

Delphi-Quellcode:

function GetLocaleOverride

. Weiter folgen kannst du dem Code sicherlich selbst. Da die System.pas aber soweit ich weiß immer implizit mit eingebunden wird, sehe ich kaum Chancen, den Zugriff auf die Schlüssel zu unterbinden - außer vielleicht durch Ausnullen der Schlüssel im Kompilat.

Grüße
Dalai

[widaMaDelphi]

Danke erstmal :)

Auch in Unicode UTF-16 finde ich den String nicht?
Ich habe UTF-16LE und UTF-16BE probiert (notepad++).

Wobei ich merkwürdig finde, dass ich auch z.B. VCLSTYLE nicht im Kompilat finde, obwohl es ja default-mäßig so eine Resource geben muss (und die sehe ich auch mit einem Resourcen-Explorer in der exe).
Das "Nullen" wäre nämlich auch mein Mittel der Wahl gewesen.
Manchmal habe ich Strings gesehen, die so wirken, als wären Leerzeichen dazwischen (z.B. K E R N E L 3 2 . D L L)...

LG

[himitsu]

siehe System.pas

Delphi-Quellcode:

  OlderLocaleOverrideKey = 'Software\Borland\Delphi\Locales'; // do not localize
  OldLocaleOverrideKey = 'Software\Borland\Locales'; // do not localize
  NewLocaleOverrideKey = 'Software\CodeGear\Locales'; // do not localize
  NewerLocaleOverrideKey = 'Software\Embarcadero\Locales'; // do not localize

für

Delphi-Quellcode:

function InternalGetLocaleOverride(AppName: string): string;
function GetLocaleOverride(const AppName: string): string;

Und kann man via

Delphi-Quellcode:

procedure SetLocaleOverride(const NewPreferredLanguages: string);

auch überschreiben/umgehen.

Zitat:

als wären Leerzeichen dazwischen

Das sind Nullen und es nennt man Unicode (UTF-16 ... früher auch mal als UCS2)

[Redeemer]

Zitat:

Zitat von widaMaDelphi (Beitrag 1498279)

Manchmal habe ich Strings gesehen, die so wirken, als wären Leerzeichen dazwischen (z.B. K E R N E L 3 2 . D L L)...

Das ist eben die Darstellung von UTF-16 als ANSI (CP1252), weil ANSI/ASCII-Nullzeichen dazwischen sind. Binärdateien als UTF-16 darstellen ergibt wenig Sinn, weil UTF-16 erfordert, dass wenn als höherwertiges Byte die Werte 0xD8-0xDB vorkommen, das übernächste Byte 0xDC-0xDF sein muss. In UCS2 sind beide Wertbereiche als höherwertiges Byte verboten. Ein beiden ist zudem verboten, dass das höherwertige Byte 0xFF und das niedrigwertige 0xFE ist.

Zitat:

Zitat von himitsu (Beitrag 1498281)

siehe System.pas

Delphi-Quellcode:

  OlderLocaleOverrideKey = 'Software\Borland\Delphi\Locales'; // do not localize
  OldLocaleOverrideKey = 'Software\Borland\Locales'; // do not localize
  NewLocaleOverrideKey = 'Software\CodeGear\Locales'; // do not localize
  NewerLocaleOverrideKey = 'Software\Embarcadero\Locales'; // do not localize

für

Delphi-Quellcode:

function InternalGetLocaleOverride(AppName: string): string;
function GetLocaleOverride(const AppName: string): string;

Und kann man via

Delphi-Quellcode:

procedure SetLocaleOverride(const NewPreferredLanguages: string);

auch überschreiben/umgehen.

Kann es den Zugriff auch verhindern, wenn man es früh genug aufruft?

[himitsu]

Zitat:

Zitat von Redeemer (Beitrag 1498282)

Kann es den Zugriff auch verhindern, wenn man es früh genug aufruft?

Das würde ich so mal annehmen?
Da

Zitat:

Delphi-Quellcode:

function GetLocaleOverride(const AppName: string): string;
begin
  if PreferredLanguagesOverride = nil then
    SetLocaleOverride(InternalGetLocaleOverride(AppName));
  Result := PreferredLanguagesOverride;
end;

[Dalai]

Zitat:

Zitat von widaMaDelphi (Beitrag 1498279)

Auch in Unicode UTF-16 finde ich den String nicht?
Ich habe UTF-16LE und UTF-16BE probiert (notepad++).

In einem Texteditor wirst du das auch nicht finden können, es sei denn, du gibst Nullbytes mit ein oder der Editor kann auch Hex editieren (für Notepad++ gibt's ein Hex-Plugin). Mit einem Hex-Editor wie HxD ist man aber definitiv besser beraten.

Grüße
Dalai

[Uwe Raabe]

Zitat:

Zitat von dummzeuch (Beitrag 1498273)

Dein Programm greift auf Registry-Einträge von BorCoDero zu? Da ist was faul. Diese Einträge gibt es doch nur auf Entwickler-Rechnern.

Das stimmt so nicht. Diese Einträge verwendet (nahezu) jede VCL-Applikation um eine mögliche Vorgabe für die Sprache der Ressource-DLLs zu ermitteln. Wenn die Regkeys nicht existieren, findet die App eben dort auch keine Werte. Das hat nichts mit einem Entwickler-System zu tun.

[himitsu]

Im Normalfall gibt es in diesen Verzeichnissen aber doch keine Einträge für eigene Programme.

Gut, ich sehe dort einen Eintrag für die msbuild.exe ... wieso eigentlich? Die wird doch garantiert nichtmal etwas von diesen Verzeichnissen wissen, um dort nachzugucken.

Und wer erstellt dort eigentlich einen Eintrag?


Drum kam ja wohl auch die "Vermutung" auf, dass "normale" eigene Programme dort eh nie etwas finden würden und sie daher auch nie dort etwas zu suchen hätten ... denke ich mal.

[widaMaDelphi]

Danke euch allen.

Beide Lösungen funktionieren übrigens (SetLocaleOverride + Nullen im Kompilat, wenn man erstmal die richtige Zeichenkodierung erwischt hat ;) ).

LG

[dummzeuch]

Zitat:

Zitat von Uwe Raabe (Beitrag 1498287)

Zitat:

Zitat von dummzeuch (Beitrag 1498273)

Dein Programm greift auf Registry-Einträge von BorCoDero zu? Da ist was faul. Diese Einträge gibt es doch nur auf Entwickler-Rechnern.

Das stimmt so nicht. Diese Einträge verwendet (nahezu) jede VCL-Applikation um eine mögliche Vorgabe für die Sprache der Ressource-DLLs zu ermitteln.

WTF? Wer kam denn auf diese dämliche Idee? Und wieso hat das noch keiner entfernt?

Man wird alt wie 'ne Kuh ...

[Uwe Raabe]

Zitat:

Zitat von dummzeuch (Beitrag 1498301)

WTF? Wer kam denn auf diese dämliche Idee? Und wieso hat das noch keiner entfernt?

Wieso entfernt? Das ist eine häufig verwendete Funktionalität bei lokalisierten Anwendungen. Man legt einfach die passenden Sprach-Ressourcen neben die EXE und stellt in dem Registry-Key die gewünschte Sprache ein (macht BdsSetLang auch so). Alles Weitere macht die RTL von alleine. Du stellst gerade die Funktionalität so mancher Lokalisierungstools in Frage.

[himitsu]

Nja, aber für eigene Programme dieses Setting nicht in einem eigenen Registry-Pfad, einer INI oder Sonstwo zu haben .....

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1498306)

Nja, aber für eigene Programme dieses Setting nicht in einem eigenen Registry-Pfad, einer INI oder Sonstwo zu haben .....

Dort schaut die RTL aber eben nicht nach. Der Charme der integrierten Lösung ist halt, dass sie vollkommen ohne weiteren Lokalisierungscode in der Anwendung auskommt und quasi out-of-the-box funktioniert.

Daneben finde ich es auch ganz praktisch, dass die Spracheinstellungen für alle meine mit Delphi erstellten Programme an der gleichen Stelle in der Registry verwaltet werden können.

[KodeZwerg]

Also wenn ich Delphi's integrierte Übersetzer anwende, werden auf dem Zielsystem automatisch Registry Keys erstellt??
Sowas sollte man schon wissen für einen Deinstaller.

[Uwe Raabe]

Zitat:

Zitat von KodeZwerg (Beitrag 1498310)

Also wenn ich Delphi's integrierte Übersetzer anwende, werden auf dem Zielsystem automatisch Registry Keys erstellt??

Nein, nicht solange du die nicht selbst anlegst (um z.B. die Sprache deiner Anwendung festzulegen). Aber danach gesucht wird halt.

[Sinspin]

Zitat:

Zitat von Uwe Raabe (Beitrag 1498304)

Zitat:

Zitat von dummzeuch (Beitrag 1498301)

WTF? Wer kam denn auf diese dämliche Idee? Und wieso hat das noch keiner entfernt?

Wieso entfernt? Das ist eine häufig verwendete Funktionalität bei lokalisierten Anwendungen. Man legt einfach die passenden Sprach-Ressourcen neben die EXE und stellt in dem Registry-Key die gewünschte Sprache ein (macht BdsSetLang auch so). Alles Weitere macht die RTL von alleine.

Ja, WTF! Das dachte ich mir auch.
Wer kommt auf die behämmerte Idee sowas fest einzubauen!?
Es ist ja schön das es was gibt zum automatisch übersetzen. Aber ich möchte schon gerne selber entscheiden wo ich mir meine Daten merke.
Aber wenn die Pfade immer gleich (Falsch) sind, wie merke ich mir dann unterschiedliche Einstellungen für unterschiedliche Programme?

Zitat:

Zitat von Uwe Raabe (Beitrag 1498304)

Du stellst gerade die Funktionalität so mancher Lokalisierungstools in Frage.

Unser Lokalisierungstool (von SiComponents) gehört da aber nicht dazu, das nimmt sich nicht heraus ungefragt in die Registry zu malen.

[Uwe Raabe]

Zitat:

Zitat von Sinspin (Beitrag 1498331)

Aber wenn die Pfade immer gleich (Falsch) sind, wie merke ich mir dann unterschiedliche Einstellungen für unterschiedliche Programme?

Hättest du schnell selbst gesehen, wenn du dir die Einträge mal angesehen hättest. Die Programme werden mit vollständigem Pfad mit dem Sprachkürzel as Wert eingetragen.

Zitat:

Zitat von Sinspin (Beitrag 1498331)

Unser Lokalisierungstool (von SiComponents) gehört da aber nicht dazu, das nimmt sich nicht heraus ungefragt in die Registry zu malen.

Das mag ja durchaus sein. Allerdings wird dann vermutlich irgendwelcher Code mit dem Programm zu compilieren sein, damit dann auch die eingestellte Sprache verwendet wird.

Der Built-In Ansatz funktioniert halt ganz ohne irgendwelchen 3rd-Party Code im Programm.

Und wie schon gesagt: Da wird auch nichts in die Registry geschrieben. Das muss schon ganz bewusst von außen kommen oder vom Entwickler im Programmcode vorgesehen sein (z.B. "verwende ab dem nächsten Programmstart die Japanischen Sprachmodule").

Ehrlich gesagt, verstehe ich die ganze Aufregung nicht. Dieses Verhalten gibt es schon seit Jahrzehnten in jedem Delphi-Programm (kann aktuell nicht vor D5 prüfen, war aber definitiv schon früher da). Jetzt hat jemand festgestellt, dass solche Programme beim Start einen bestimmten Registry-Schlüssel abfragen und die halbe Entwicklergemeinde springt im Dreieck. Leute, habt ihr denn die VCL/RTL-Sourcen noch nie gelesen?

[Rolf Frei]

Verstehe das Theater auch nicht. Die integrierte Übersetzungsmechanik in Delphi (ITM/ETM genannt) nutze ich auch selber und das ist schon ein feines Feature. Das gibt es schon seit glaube ich Delphi 3.

Nutzt ihr den keine resourcestrings in eurem Code? Dass Delphi dauraus automatisch die entsprechenden Resourcenfiles erzeugt ist doch eine feine Sache.

Wer davon noch nie was gelesen hat, sollte sich vieleicht mal die Emba Doku dazu anschauen: https://docwiki.embarcadero.com/RADS...ger_in_the_IDE

[dummzeuch]

Zitat:

Zitat von Uwe Raabe (Beitrag 1498332)

Leute, habt ihr denn die VCL/RTL-Sourcen noch nie gelesen?

Wenn ich die VCL/RTL-Sourcen komplett gelesen hätte, hätte ich längst einen Herzkasper bekommen. Es reichen schon die ganzen Seltsamkeiten und Bugs, die man dort während des Debuggings findet.

Aber immerhin kann man die bei Delphi finden, bei anderen Entwicklungsumgebungen hat man die Sourcen ja gar nicht erst.

[jaenicke]

Zitat:

Zitat von Rolf Frei (Beitrag 1498368)

Verstehe das Theater auch nicht. Die integrierte Übersetzungsmechanik in Delphi (ITM/ETM genannt) nutze ich auch selber und das ist schon ein feines Feature. Das gibt es schon seit glaube ich Delphi 3.

Ja, das kommt hin. Es war auf jeden Fall eine uralte Version und noch in meiner Studienzeit als ich damit experimentiert habe. Besonders schön fand ich es nicht, aber immerhin funktionierte es gut.

Zitat:

Zitat von dummzeuch (Beitrag 1498374)

Wenn ich die VCL/RTL-Sourcen komplett gelesen hätte, hätte ich längst einen Herzkasper bekommen. Es reichen schon die ganzen Seltsamkeiten und Bugs, die man dort während des Debuggings findet.

Ich habe schon genug darin gelesen um mich zu fragen was man rauchen muss um eine zur Verfügung gestellte Bibliothek ohne Not so unflexibel zu machen, indem man viele Annahmen über die Verwendung hart in Code gießt. Würde man das aus Sicht der Benutzer dieser Bibliotheken betrachten, sähen diese sicher anders aus...
Es ist echt schade, dass man das bei Embarcadero offenbar anders sieht.

[Sinspin]

Zitat:

Zitat von Uwe Raabe (Beitrag 1498332)

Ehrlich gesagt, verstehe ich die ganze Aufregung nicht. Dieses Verhalten gibt es schon seit Jahrzehnten in jedem Delphi-Programm (kann aktuell nicht vor D5 prüfen, war aber definitiv schon früher da). Jetzt hat jemand festgestellt, dass solche Programme beim Start einen bestimmten Registry-Schlüssel abfragen und die halbe Entwicklergemeinde springt im Dreieck. Leute, habt ihr denn die VCL/RTL-Sourcen noch nie gelesen?

Die Aufregung (der Aufreger) ist das mein Programm auf die Registry zugreift, ob das nun nur lesend ist oder nicht, ist erstmal wurscht.
Das mir das bekannt sein müsste?? Die Quelltexte lesen?
Wie bei anderen Komponentenherstellern bezahle ich dafür das die Komponenten funktionieren wie es im Handbuch beschrieben ist. Denn ich habe was besseres zu tuen als die Quelltexte zu lesen.
Und wenn ich die Übersetzung nicht verwende, dann erwarte ich auch das die nicht im Hintergrund rumwerkelt! Das ist der Aufreger.

Ich habe mir die Delphi eigene Übersetzung vor sehr langer Zeit (mindestens 15 Jahre) mal angesehen und als viel zu steif eingestuft.

Zitat:

Zitat von Rolf Frei (Beitrag 1498368)

Nutzt ihr den keine resourcestrings in eurem Code? Dass Delphi dauraus automatisch die entsprechenden Resourcenfiles erzeugt ist doch eine feine Sache.

Was soll ich bitte mit Übersetzungen anstellen die in Resourcefiles gesperrt werden? In meinen Programmen ist eine Schnittstelle die es dem Nutzer erlaubt selber die Texte anzupassen. Zur Laufzeit. So kann man gleich testen ob alles passt. Und zwar in allen Sprachen die enthalten sind.
Wie soll das via Resourcestrings aus der exe oder einer dll funktionieren?

[Uwe Raabe]

Zitat:

Zitat von Sinspin (Beitrag 1498397)

Wie bei anderen Komponentenherstellern bezahle ich dafür das die Komponenten funktionieren wie es im Handbuch beschrieben ist. Denn ich habe was besseres zu tuen als die Quelltexte zu lesen.
Und wenn ich die Übersetzung nicht verwende, dann erwarte ich auch das die nicht im Hintergrund rumwerkelt! Das ist der Aufreger.

In Bezug auf wie es im Handbuch beschrieben ist verweise ich einfach mal auf die entsprechende Doku: Using Resource DLLs

Zitat:

If you want your application to use a different resource module than the one that matches the locale of the local system, you can set a "locale override" entry in the Windows registry. Under the HKEY_CURRENT_USER\Software\Embarcadero\Locales key, select the New > String Value command to add a new key. In the Name column, insert your application's path and executable file name as a string value, and in the Data value, insert the desired extension of your resource DLLs. At startup, the application looks for resource DLLs with this extension before trying the system locale. Setting this registry entry allows you to test localized versions of your application without changing the locale on your system. (For more information about usage of "locale override" registry keys see Localizing Applications and Deploying Localized Applications.)

Zitat:

Zitat von Sinspin (Beitrag 1498397)

In meinen Programmen ist eine Schnittstelle die es dem Nutzer erlaubt selber die Texte anzupassen. Zur Laufzeit. So kann man gleich testen ob alles passt. Und zwar in allen Sprachen die enthalten sind.

Offenbar sind deine Anforderungen anders als bei anderen, was ja durchaus legitim ist. Daraus jetzt abzuleiten, dass das intrinsische Verhalten der Delphi RTL dann ja auch weg kann, ist m.E. etwas egozentrisch.