StringReplace verursacht AV

[EWeiss]

Zitat von himitsu:

Es hätte auch schon in der FOR-Schleife knallen können.
Wenn der zu überschreibende Speicherbereich nicht reserviert ist, oder etwas überschrieben wird, was bereits in der Schleife verwendet wird.

Und ob es später knallt oder nicht, das hängt davon ab was überschrieben wird.

Das hätte ich verstanden da hier ja auch der Fehler produziert wurde.
Aber der andere Fall bleibt ein Rätzel.

Denn nach dem deaktivieren von StringReplace trat kein Fehler mehr auf.
Zu spekulieren es hätte auch woanders auftreten können ist eine Vermutung wie gesagt nach dem deaktivieren kam kein Fehler mehr.
Er hätte also dann an anderer stelle auftreten müssen wenn man der Behauptung nachgehen würde "Es hätte auch schon"

Zitat:

Und ob es später knallt oder nicht, das hängt davon ab was überschrieben wird.

Und das tut es eben nicht.
Immer nur an der gleichen stelle in Verbindung mit StringReplace.
Überall da wo es Verwendung findet.

Zitat:

Das ist auch garantiert nicht der Fall.

Aber 100% 'tig
Andernfalls erkläre mir mal warum es dann nirgends anders kracht nachdem ich diese Zeile/n deaktiviert habe.

gruss

[Fritzew]

Du willst es nicht verstehen oder?
Was da gerade im Speicher steht den Du überschreibst ist "Zufall". Zufall aus Deiner Sicht, für den Speichermanager
hat das alles Seine Richtigkeit. In Deiner Konstellation passiert es beim Stringreplace. Wenn Du aber sonst noch was änderst im Code kann der aktuelle Speicher schon wieder ganz anders aussehen.
Dr Fehler ist 100% Deiner und sonst nichts.

[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 von 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?

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 von EWeiss:

Ihr wollt nicht verstehen das es Unit übergreifend passiert.

Irrelevant ..

Zitat von EWeiss:

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 von EWeiss:

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

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

[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

[Zacherl]

Zitat von EWeiss:

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.

Nene, macht ab Win8 keinen Unterschied mehr, da die Dlls eh durch ASLR bei jedem Start an zufällige Adressen relocated werden.

[Luckie]

Beispiel. Wir haben die aufeinander folgenden Adressen 1, 2, 3, 4. Die Exe wird immer an Adresse 1 geladen, da Exe-Dateien standardmäßig die ImagebaseAddress 1 haben. DLLs haben standardmäßig die ImageBaseAddress 2. Dahin wird auch die erste DLL geladen. Wird jetzt eine zweite DLL geladen (standard ImageBaseAddress 2), kann sie nicht mehr an die Standardadresse geladen werden, denn da befindet sich ja schon die erste DLL. Also wird sie an Adresse 3 geladen. Jetzt beziehen sich aber alle Sprünge im Code auf die Adresse 2. Das hat zur Folge dass alle Sprungadressen in der DLL, wenn sie geladen wird neu berechnet werden müssen. Dazu existiert in der DLl der sogenannte Realocation Table mit den relativen Sprungadressen zur standard ImagebaseAddress. Auf Basis des Realocation Tables werden jetzt die Sprungadressen neu berechnet. Gibt man jetzt eine andere ImageBaseAddress an, entfällt diese neu Berechnung. Theoretisch. Denn man kann sich nicht sicher sein, ob nicht auch an der anderen ImageBaseAddress sich schon eine DLL befindet.

Es gibt Programme, die den Realocation Table entfernen, um die Exe zu verkleinern. (Gibt sich aber nicht viel.) Exe-Dateien funktionieren dann immer noch, da sie standardmäßig immer an Adresse 1 geladen werden. Es müssen also keine Sprünge neu berechnet werden. Bei DLLs sollte man den Realocation Table aber nicht entfernen, da er gegebenenfalls benötigt wird, wenn die DLL nicht an die vorgegebene Adresse geladen werden kann.

http://michael-puff.de/Programmierun...eAddress.shtml