StringReplace verursacht AV

[EWeiss]

Zitat:

Was da gerade im Speicher steht den Du überschreibst ist "Zufall". Zufall aus Deiner Sicht, für den Speichermanager

Tja warum legt man dann nicht alles als Zufall aus?

Ihr wollt nicht verstehen das es Unit übergreifend passiert.
Egal wo ich Stringreplace verwende kracht es das hat nix mit dem Speicher zu tun.

Wenn ich in Unit 1 die länge eines Arrays falsch definiere.

Warum gibt mir dann Unit 3 und Unit 5 nur an den Stellen wo ich Stringreplace verwende einen AV aus?
Was hat das jetzt mit dem Speicher zu tun? Und Zufall ist das schon gar nicht.
Wenn ich nun an gleicher stelle im Code eine andere Funktion verwende passiert nichts.. das soll Zufall sein? Bei nichten.

Und ja wie schon gesagt das Array wird in einer privaten Classe generiert.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1350376)

Zitat:

Was da gerade im Speicher steht den Du überschreibst ist "Zufall". Zufall aus Deiner Sicht, für den Speichermanager

Tja warum legt man dann nicht alles als Zufall aus?

StringReplace erzeugt jedes Mal eine AV bei deiner speziellen Konstellation. Dennoch ist dies Zufall und du kannst nicht vorraussagen, ob andere Funktionen nicht auch zur selben AV führen würden. Wenn du philosophieren willst, dann kannst du natürlich gerne alles als Zufall betrachten, oder eben auch nicht. Könntest du die Position und den Impuls jedes Atoms im Universum feststellen, dann wäre es dir möglich die Zukunft vorrauszusagen. Das dies nicht geht hat Heisenberg bereits bewiesen, aber Zufall ist nunmal trotzdem der Begriff, den man verwendet, wenn ein Ergebnis von einer nicht zu überblickenden Anzahl an Variablen abhängt.

Zitat:

Zitat von EWeiss (Beitrag 1350376)

Ihr wollt nicht verstehen das es Unit übergreifend passiert.

Irrelevant ..

Zitat:

Zitat von EWeiss (Beitrag 1350376)

Und ja wie schon gesagt das Array wird in einer privaten Classe generiert.

Ebenfalls irrelevant ..

Wie schon erklärt wurde, ist es komplett egal in welcher Unit oder Klasse sich dein Code befindet. Letzten Endes steht alles im selben virtuellen Speicherbereich des Prozesses.

Zitat:

Zitat von EWeiss (Beitrag 1350376)

Wenn ich nun an gleicher stelle im Code eine andere Funktion verwende passiert nichts.. das soll Zufall sein? Bei nichten.

Doch! Nehmen wir an StringReplace erzeugt eine AV, wenn an Adresse 1234 die Zahl 1 steht. Normal steht an dieser Adresse 0, aber durch deinen Buffer Overflow schreibst du "zufällig" eine 1 dorthin. Ergebnis: StringReplace crasht. Auf der anderen Seite hast du die StripHotkey Funktion. Diese greift aber gar nicht auf Adresse 1234 zu und funktioniert deshalb trotzdem.

[EWeiss]

Zitat:

Doch! Nehmen wir an StringReplace erzeugt eine AV, wenn an Adresse 1234 die Zahl 1 steht. Normal steht an dieser Adresse 0, aber durch deinen Buffer Overflow schreibst du "zufällig" eine 1 dorthin. Ergebnis: StringReplace crasht. Auf der anderen Seite hast du die StripHotkey Funktion. Diese greift aber gar nicht auf Adresse 1234 zu und funktioniert deshalb trotzdem.

Ok das ist verständlich von der warte ausgesehen ist es ein Speicherproblem.
War halt nur verstutzt weil es immer nur bei StringReplace auftrat.

gruss

[Uwe Raabe]

Der Unterschied zwischen StringReplace und StripHotKey ist, daß StripHotKey ausschließlich mit Delete arbeitet und dabei den String im selben Speicherbereich hält, während StringReplace einen neuen String zurück gibt. Danach wird dann der alte String freigegeben - was auch problemlos funktioniert, wenn es denn ein richtiger String ist und nicht per string-Cast aus einem PWideChar entstanden ist.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1350402)

Der Unterschied zwischen StringReplace und StripHotKey ist, daß StripHotKey ausschließlich mit Delete arbeitet und dabei den String im selben Speicherbereich hält, während StringReplace einen neuen String zurück gibt. Danach wird dann der alte String freigegeben - was auch problemlos funktioniert, wenn es denn ein richtiger String ist und nicht per string-Cast aus einem PWideChar entstanden ist.

Ist ein WideString.
Das hätte das Problem nicht ausgelöst.

Aber gut ich weis nun bescheid das es kein StringReplace Problem ist.
Danke.

gruss

[Fritzew]

Zitat:

Zitat von Uwe Raabe (Beitrag 1350402)

wenn es denn ein richtiger String ist und nicht per string-Cast aus einem PWideChar entstanden ist.

Das must Du jetzt aber erklären. Wann führt ein String(pchar) zu einem Problem?

[Aviator]

Zitat:

Zitat von Fritzew (Beitrag 1350406)

Zitat:

Zitat von Uwe Raabe (Beitrag 1350402)

wenn es denn ein richtiger String ist und nicht per string-Cast aus einem PWideChar entstanden ist.

Das must Du jetzt aber erklären. Wann führt ein String(pchar) zu einem Problem?

Würde mich jetzt auch interessieren. Hatte das Thema auch gerade erst in einem meiner Threads. Und dort wurde bestätigt, dass das kein Problem macht. Siehe den Beitrag von Zacherl.

[himitsu]

Dein "Zufall":

Delphi-Quellcode:

const
  PositionVonStringReplace = 14346027;
  Gott: array[0..3] of AnsiChar = 'Himi';
var
  MeinSpeicherDenIchGleichÜberschreibenWill: {Pointer}Integer;
begin
  RandSeed := Integer(Gott);

  MeinSpeicherDenIchGleichÜberschreibenWill := Random(999999999);  // Zufällige Speicherposition suchen
  if MeinSpeicherDenIchGleichÜberschreibenWill = PositionVonStringReplace then
    ShowMessage('Gleich ist StringReplace kaputt :(');
end;

Rein theoretisch kann neu zu reservierender Speicher überall im RAM landen, genauso wie DLLs nicht immer an selber Stelle liegen müssen, ABER ...

Vorallem Delphi DLLs liegen gern nicht dort, wo sie sollen, denn fast niemand gibt eine ordentliche ImageBaseAddress an, womit fast alle Delphi-DLLs eigentlich an selber Stelle liegen würden und Windows sowieso Diese immer an dererer Stelle laden muß,
aber Windows cached sich gern gepatchte Module und läd die DLLs dann oftmals wieder an selber Sellte, wo sie schonmal geladen wurden. Bzw. wiederverwendet die selben Module, welche bereits in einer anderen Anwendung geladen sind.
FastMM/VirtualAlloc könnte jedesmal beim GetMem was Anderes liefern, aber es reagiert auch gern mal gleich, da das Programm beim Start ja auch jedesmal das Selbe macht.
Auch der ProgrammCode (EXE/DLL/...) liegt im Arbeitsspeicher ... eigentlich sollte der vorm Überschreiben geschützt sein, aber man kann ihn womöglch dennoch überschreiben und jetzt muß nur noch etwas von der Funktion StringReplace überschrieben werden.

Aber ganz genau kann man es letztendlich nur sagen, wenn man DEIN Programm analysiert, was es nun wirklich macht,
also z.B. die letzte falsche Schleife debuggen und gucken ob und was wo überschrieben wurde.

[Uwe Raabe]

Zitat:

Zitat von Aviator (Beitrag 1350407)

Zitat:

Zitat von Fritzew (Beitrag 1350406)

Das must Du jetzt aber erklären. Wann führt ein String(pchar) zu einem Problem?

Würde mich jetzt auch interessieren. Hatte das Thema auch gerade erst in einem meiner Threads. Und dort wurde bestätigt, dass das kein Problem macht. Siehe den Beitrag von Zacherl.

Ihr habt ja Recht! Ich hatte mich dadurch verleiten lassen, daß der erste Parameter von StringReplace als

Delphi-Quellcode:

const

deklariert ist, aber der Compiler legt dafür eine versteckte, lokale String-Variable an.

[EWeiss]

Ich habe es nochmal getestet mit meiner CTRL_Hook DLL.
Dort ist ja der Fehler mit der falschen Zuordnung der Array länge.

Dort tritt das Problem nicht auf trotz falscher länge.
Allerdings zeichne ich dort den String auch nicht mit GDI+.

Gut ohne einschalten der Bereichs Prüfung bekomme ich da auch keinen Fehler angezeigt.
Und krachen tut's auch nicht.

Zitat:

Vorallem Delphi DLLs liegen gern nicht dort, wo sie sollen, denn fast niemand gibt eine ordentliche ImageBaseAddress an

Ich gebe zu das ich diese auch nicht ändere sollte das nicht eigentlich automatisch geschehen?
Was bringt mir das diese ändern zu wollen.. bzw.. Von welchen Kriterien ist das abhängig.
Es muss ja irgendeinen sinn machen das diese von Borland oder wem auch immer mal festgelegt worden ist.

gruss