StringReplace verursacht AV

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

[EWeiss]

Zitat von 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.

Ok.. Hab zwar Win7 aber damit bisher keine Probleme gehabt denke das ich die eingestellte Standard Adresse weiterhin verwende.

gruss

[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

[himitsu]

Jo, die EXE ist halt das Erste, was geladen wird, drum ist ihre ImageBaseAddress eigentlich immer frei. (außer man setzt 'ne EXE-Komporimierung/Verschlüsselung ein, wo sich 'ne MiniEXE vorschaltet, die dann die eigentliche Anwendung nachlädt und entpackt/entschlüsselt)

Noch schöner ist aber das Ergebnis der Address-Reallocation.
Standardmäßig sind die Code- und Data-Segmente der DLL/EXE nur im RAM verlinkt (MemoryMappedFile auf die Datei), aber wird im Code rumgeschrieben, z.B. weil überall die Zeiger angepasst werden müssen, dann wird der umgebende Speicherbereich (je mindestens 4KB) in den RAM kopiert (CopyOnWrite) und das dann verändert.
Also belegt das Programm dann auch noch mehr physischen RAM. (zum Glück haben wir ja immer mehr RAM zur Verfügung)
Und noch besser wird das, wenn Windows durch ASLR für jede Anwendungsinstanz einen andere Position wählt, dann kann mindestens der Codeteil nicht mehr geshared werden, da jeder eine andere ImageBase und somit "anders" überschriebenen Code benötigt.

Aber eigentlich ist ASLR halt ein Schutz vor Schadprogrammen (Viren/Trojaner/Würmer) und selbst Hacker haben es bei Spielen bissl schwerer, um z.B. in die Variable "SoVielGoldHabeIch" eine 2.000.000.000 reinzuschreiben.
Denn sie können nicht "blind" auf eine bestimmte Speicheradresse zugreifen (ImageBase + Offset = Variable/Konstante/Programmcode), da die Adressen nicht statisch ist.
Man konnte früher z.B. im Browser/Acrobat/Flash/... einen Bug geziehlt ausnutzen, indem man z.B. einen Bufferoferflow ausnutzte und den "zufällig" fast immer dahinterligenden Code/Variablen "ausversehn" überschieb. Und wenn man das gut getroffen hatte, dann wurde später der so eingeschleußte Code heimlich ausgeführt.