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