ASLR und HighEntropy - Probleme

[himitsu]

Das CONST mit {$J+} könnte man als "private globale Inlinevariable" betrachten.
https://docwiki.embarcadero.com/RADS...tants_(Delphi)

Vom besseren "Verständnis" her, würde ich aber vom {$J+} bzw. {$WRITEABLECONST ON} abraten.
-> also stattdessen eine "richtige" globale Variable, bzw. als Private in eine Klasse, oder Dergleichen.

Aber wenn doch, wäre es wenigstens angebracht die "langen" Varianten solcher Settings zu verwenden, weil bissl "verständlicher".



Nja, auf "normalen" Windows-Versionen dürft ASLR doch standardmäßig deaktiviert sein.
Ich glaub nur auf Windows-Server wird sowas eventuell per Default auf Aktiv gestellt sein.
Somit kommen die meisten Nutzer damit nicht in Berührung.

Und da Windows normal versucht kleine Speicheradressen zu belegen, außer ASLR ist aktiv, oder z.B. VirtualAlloc+MEM_TOP_DOWN,
fallen Fehler seltener auf, wenn z.B. Pointer durch falsche Casts/Typen auf 32 Bit abgescnitten werden. (so wie es hier der Fall war)


Einen winzigen Nachteil hat ASLR noch.
* normal kann Arbeitsspeicher von Executables (EXE/DLL/BPL) wiederverwendet werden, was Ladezeit und bissl Speicher spart.
* wenn ASLR aktiv ist, liegt theoretsch jede EXE/DLL wo anders in den virtuellen Speichern, also wird sie überall exlusiv (mehrmals) geladen, weil dabei ja Adressen im Code überall anders übersetzt werden müssen.

* gut, dass es JETZT knallt, ist kein Fehler des ASLR ... bei vollem Programmspeicher hätte es so oder so geknallt

* der Vorteil ist dann aber dass "bösartige" Überläufe auf "feste" Adressen nun höchstwahrscheinlich nicht das kaputt machen, was sie wollten
* * wenn der Böse aber sich vorher die "richtige" Position besorgt, dann hilft ASLR auch nichts

https://learn.microsoft.com/de-de/wi...-in-windows-10

[DaCoda]

Counter wird aber immer 1 sein, weil 0 SHL 1 immer eine 0 bleibt.
Somit ist der Code ja eh unnütz...

[himitsu]

NEIN, weil es effektiv SO arbeitet:

Delphi-Quellcode:

var
  Counter: Byte = 0;

procedure DrawDots (x, y: Integer; c: TCanvas); StdCall;
begin

Es wird ein BIT in jedem Durchlauf reihum durch das Byte geschoben ... ähnlich einem ROL (wegen dem IF =0)

Delphi-Quellcode:

var
  Counter: Byte = 0;

procedure DrawDots (x, y: Integer; c: TCanvas); StdCall;
begin
  counter := counter shl 1;

  if counter = 0 then counter := 1;

  case counter of
    1, 2, 4, 8 : C.pixels[x,y] := clWhite;
  else
    C.pixels[x, y] := clBlack;
  end;
end;

Delphi-Quellcode:

var
  Counter: Byte = $1;

procedure DrawDots (x, y: Integer; c: TCanvas); StdCall;
begin
  case counter of
    1, 2, 4, 8 : C.pixels[x,y] := clWhite;
  else
    C.pixels[x, y] := clBlack;
  end;

  counter := counter rol 1;
end;

Delphi-Quellcode:

var
  Counter: Byte = 0;  // oder Integer oder egal (weil alles durch 8 teilbar)

procedure DrawDots (x, y: Integer; c: TCanvas); StdCall;
begin
  Inc(Counter)
  if not Ord(Counter shr 2) of
    C.pixels[x,y] := clWhite;
  else
    C.pix

Zusammen mit dem CASE ergibt es
* es wird von 1 bis 8 gezählt (1 Byte = 8 Bits)
* und wenn es 1 bis 4 ist, wird es weiß

-> 4 Mal Weiß, 4 Mal Schwarz, 4 Mal Weiß, 4 Mal Schwarz usw.

(mein Beispiel oben zählt von 0 bis 7, weil es so einfacher zu berechnen ist, aber effektiv kommt es auf's Gleiche raus)

[Harry Stahl]

Zitat von DaCoda:

Counter wird aber immer 1 sein, weil 0 SHL 1 immer eine 0 bleibt.
Somit ist der Code ja eh unnütz...

Da liegst Du falsch. Probier es doch selber aus und staune...