RawByteString in Exe modifizieren

[freimatz]

Weil bei Pos die Fehlerbehandlung fehlt?

[himitsu]

Abgesehn davon:
Warum kein RessourceString?

Delphi-Quellcode:

resourcestring
  deineKonstante = 'asdfasdfsda';  // wird über einen "zufälligen" String-Index in den Ressourcen gespeichert

bei Verwendung dieser Konstante wird intern LoadString vewendet

oder über den Ressourcen-Manager von Delphi (in die *.res jedes Projekte)
oder über eine eigene RC/RES-Datei
> hier jeweils über LoadString bzw. LoadResource/FindResource/... den String laden



und dann entweder selber mit UpdateResource oder über einen der vielen Resource-Editoren (teilweise lassen sie sich auch via Parameter steuern) diese Ressorce ändern, ohne bösswillig den "Programmcode" zu verändern.

und sowas lässt sich auch zur Laufzeit anpassen
* z.B. durch hooken der Load-Funktion (wird z.B. von einigen Lokalisierungskomponenten verwendet, um eine andere Sprache zu laden)
* oder über zusätzliche Dateien (z.B. siehe die .DE-Dateien neben den .BPL der Delphi-Packages)

[freimatz]

Warum? Vermutlich weil die "Exe-Datei 2" gar nicht von ihm ist.

[himitsu]

Nee nee, die Liebe Dolly macht sowas doch nicht.
Fremde Dateien hacken ist aber böse.
(vor allem wenn es gegen die Lizenzbedingen verstoßen könnte)



Sowas wie TEncoding.ANSI.xyz ist sowieso das Schlimmste, was man einer Binärdatei antun kann.

Wenn schon mit Unicode rumgepfuscht wird, dann besser ohne Zeichenübersetzungen.

Delphi-Quellcode:

E := TMBCSEncoding.Create($FFFF, 0, 0);  // $FFFF ist auch die CodePage, welche der RawByteString benutzt
E.GetString();

Ansonsten gibt es viele Wege, um Binärdaten auch binär zu behandeln.

Delphi-Quellcode:

var R: RawByteString;
M := TFileStream.Create('.\file.exe');
SetLength(R, M.Size);
M.ReadBuffer(R[1], M.Size);
...
Und dann besser niemals mit Unicode-Funktionen darauf zugreigen
Pos und Copy gibt es standardmäßig überladen, auch als "ANSI"-Version (für AnsiString und seine Verwandten ala RawByteString)
und ansonsten gibt es auch noch die Unit AnsiStrings.

--

M := TMemoryStream.Create;
M.LoadFromFile('.\file.exe'));
...
M.Memory // ein Pointer auf den Dateiinhalt
...
M.SaveToFile('.\newfile.exe'));
M.Free;

--

B := TFile.ReadAllBytes('file');
...  // B = ein Byte-Array
TFile.WriteAllBytes('newfile', B);

--

R := TFile.OpenText('file');  // bzw. direkt TStreamReader.Create
W := TFile.CreateText('file');  // bzw. TStreamWriter.Create
// geht nicht, weil hier der Encoding-Parameter fehlt,
// aber

E := TMBCSEncoding.Create($FFFF, 0, 0);
S := TFile.ReadAllText('file', E);
...
E.Free;

uvm.

Leider gibt es Pos/PosEx unverständlicher Weise nicht für normale Arrays.
Es gibt StrPos-Funktionen für PAnsiChar, die man auf Pointer/Arrays loslassen könnte, aber bei der ersten #0 brechen die ab.
Also bleibt nur selber was basteln.

Aber so oder so ist es immer besser Binärdaten niemals in Text-Strings zu speichern
und stattdessen "ordentlich" mit Streams oder Pointer bzw. ByteArrays zu arbeiten.

[DieDolly]

Ich sehe gerade alles hat jetzt seine Richtigkeit. Der Fehler lag an der Ausgabe. Die Ausgabe war nur für mich. Ich hab mich schon gewundert, wo die 4 zusätzlichen KB herkamen!
Zur Klarstellung. Ich bearbeite hier ausschließlich meine eigenen Dateien!

Zitat:

E := TMBCSEncoding.Create($FFFF, 0, 0); // $FFFF ist auch die CodePage, welche der RawByteString benutzt
E.GetString();

Wenn ich das so nutze, erhalte ich EEncodingError. Der Fehler kommt, sobald ich E := TMBCSEncoding.Create($FFFF, 0, 0); irgendwo schreibe.

[himitsu]

Mist, Windows weigert sich. (früher ging das mal )
Das GetCPInfo im Constructor zickt rum, aber die anschließenden MultiByteToWideChar arbeiten problemlos mit $FFFF.

Ich sehe in der Liste aber grade keine passenden CodePage https://docs.microsoft.com/de-de/win...ge-identifiers

Nja, man kann sich TEncoding auch selbst ableiten und dort eine 1-1-Übersetzung zusammenbauen.
Oder TMBCSEncoding erst mit einer anderen CodePage erstellen und anschließend böswillig die CodePage überschreiben.

[DieDolly]

Ich habe jetzt ein Teilergebnis.
Es muss wohl irgendwas mit str := TEncoding.ANSI.GetString(ByteStream.Bytes) ... zu tun haben. Auf einem System mit türkischem Windows, aber englishcer Benutzeroberfläche kommt da nicht das raus, was rauskommen soll. Ich kopiere eine bestimmte Anzahl Zeichen von einer Position A an bis zu einer Position B. Das funktioniert in 99% der Fälle einwandfrei nur hier scheinbar nicht. Es handelt sich übrigens um einen Kunden-PC.

Normalerweise soll eine normale Zeichenkette mit Zeichen von a bis z und 0 bis 9 rauskommen. Länge, sagen wir mal, 48 Zeichen. Ist aber egal wie lang.
Auf dem Kunden-PC kommt das raus, was im Bild zu sehen ist.

Hilft hier vielleicht ASCII statt ANSI weiter? Ich kann das Problem leider nicht reproduzieren. Der Kunde sagt auch selber, dass es auf dem einen PC auftaucht und auf dem anderen nicht.
Ich habe das Problem jetzt aber durch andere, benutzerfreundliche Mittel beseitigt.

[himitsu]

Zitat von himitsu:

Sowas wie TEncoding.ANSI.xyz ist sowieso das Schlimmste, was man einer Binärdatei antun kann.

Was soll man dazu noch weiteres sagen?

ASCII?

Nee, Binärdateien gehören binär behandelt ... jegliche Behandlung mit irgendwelche Texten und vor allem irgendwelches Umrechnen/Umcodieren in Unicode über Codepages hat hier einfach garnichts zu suchen.

ANSI ist bei uns und den Amis zugfällig 1 Byte pro Zeichen, aber das ist nicht überall so. (nur leider erfinden gerade die dann sowas Krankes, wie Binärdaten in Textstrings)
PS: UTF-8 ist ein gutes Beispiel dafür, was jeder verstehen können dürfte, wo also ein Index im Unicode nicht die selbe Position ist, wie in der Codierung.

[DieDolly]

Zitat:

Was soll man dazu noch weiteres sagen?

Irgendwie muss man die paar Bytes die man von Position X bis Y (maximal 48 wie gesagt, nicht die ganze Datei) ausliest ja lesbar machen.

Zitat:

ANSI ist bei uns und den Amis zugfällig 1 Byte pro Zeichen

Die Bytes die ich auslesen und umwandeln möchte ergeben mit absoluter Sicherheit immer Zeichen A bis Z und 0 bis 9.
Welche Möglichkeit gibt es denn sonst noch diese paar Bytes lesbar zu machen? Das ergeben am Ende ziemlich sicher rund 48 Zeichen.
Sonst hätte ich noch StringOf aus den System.SysUtils im Angebot. Ich denke das ist besser als selbst mit TEncoding zu spielen.

[himitsu]

ASCII, also das Ursprüngliche hat nur 7 Bit
EASCII (das was aktuell alle als ASCII bezeichnen) ist auch nur eine der vielen 8-Bit-Codepages.

und Default = ANSI

Zitat von DieDolly:

Die Bytes die ich auslesen und umwandeln möchte ergeben mit absoluter Sicherheit immer Zeichen A bis Z und 0 bis 9.

Aber der Rest nicht, somit ist es unmölich damit sicher die Position im Unicode zu bestimmen und dann 1:1 auf die Bytes der Datei umzurechnen.

Also egal was du machst, sobald auch nur irgendwie etwas mit Unicode im Spiel ist, war es dass, also im Prinzip ist alles mit Codepage und Encoding der falsche Weg.
Man kann zwar den Inhalt einer Datei 1:1 im einen AnsiString alle AnsiString, RawByteString usw. kopieren (SetLength+Stream.Read) und dann ANSI-Pos und Dergleichgen benutzen, aber der kleinste Fehler und schon gibt es massivr Probleme, sobald auch nur irgendwie ausversehn eine Umcodierung der Zeichen alles durcheinander bringt.

Darum ist es immer besser direkt bei ByteArrays bzw. ByteStreams zu bleiben.