AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

StringReplace verursacht AV

Ein Thema von EWeiss · begonnen am 7. Okt 2016 · letzter Beitrag vom 11. Okt 2016
Antwort Antwort
Seite 4 von 4   « Erste     234   
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#31

AW: StringReplace verursacht AV

  Alt 10. Okt 2016, 20:49
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.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#32

AW: StringReplace verursacht AV

  Alt 10. Okt 2016, 21:45
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
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#33

AW: StringReplace verursacht AV

  Alt 11. Okt 2016, 01:12
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
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.063 Beiträge
 
Delphi 12 Athens
 
#34

AW: StringReplace verursacht AV

  Alt 11. Okt 2016, 04:36
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.
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.

Geändert von himitsu (11. Okt 2016 um 04:43 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 4 von 4   « Erste     234   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:54 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz