ASLR und HighEntropy - Probleme

[Sherlock]

Ich bin ja nicht so der Held was direkte Bytemanipulationen betrifft, aber ist das Ergebnis hier nicht immer das selbe nämlich 1?

Delphi-Quellcode:

const
  Counter: Byte = 0;
begin
  counter := counter shl 1;

  if counter = 0 then counter := 1;

Aus Geschwindigkeitsgründen würde ich einfach nur
C.pixels[x,y] := clWhite; schreiben.

Und welchen Sinn macht es constanten änderbar zu machen?

Sherlock

[himitsu]

Ja, das perverse da dran ist {$J+} .
-> schreibbare Konstanten ... sowas wie eine globale Variable

typisierte Konstanten sind eigentlich schreibgeschützte Variablen, nur dass der Compiler den Schreibzugriff normalerweise verbietet ... außer man schaltet es ab.


aber mathematisch dürfte ein

Delphi-Quellcode:

{global} var
  counter: Byte = 0;
begin
  counter := counter shl 1;

  if counter = 0 then counter := 1;

  case counter of
    1, 2, 4, 8 :

Delphi-Quellcode:

{global} var
  counter: Byte = 0;
begin
  counter := (counter + 1) mod 8;

  if counter < 4 then

oder

Delphi-Quellcode:

{global} var
  counter: Byte = 0;
begin
  Inc(counter);
  if counter >= 8 then 
    counter := 0;

  if counter < 4 then

entsprechen

[Harry Stahl]

Zitat von Sherlock:

Ich bin ja nicht so der Held was direkte Bytemanipulationen betrifft, aber ist das Ergebnis hier nicht immer das selbe nämlich 1?

Delphi-Quellcode:

const
  Counter: Byte = 0;
begin
  counter := counter shl 1;

  if counter = 0 then counter := 1;

Aus Geschwindigkeitsgründen würde ich einfach nur
C.pixels[x,y] := clWhite; schreiben.

Und welchen Sinn macht es constanten änderbar zu machen?

Sherlock

Wie gesagt, ich habe mir das nicht ausgedacht. Aber ein gewisser Sinn wäre hier zu erkennen, indem man eine "globale" Variable hat, die aber nur in dieser Funktion zur Verfügung steht. Somit vermeidet man also die "globalen" Variablen, die an anderer Stelle von anderen Funktionen ungewollte verändert werden könnten.

Wie himitsu bereits schrieb ergibt es daher tatsächlich nicht jedesmal den gleichen Wert (weil der Zustand des letzten Aufrufs halt beibehalten wurde).

Aber zurück zum Thema ASLR: Anscheinend sind hier bislang noch keinem anderem Anwender Probleme mit ASLR untergekommen? Das wäre ja positiv...

[pustekuchen]

Eine änderbaren Konstante entspricht ein static variable, die es in Delphi nicht gibt.

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