Einzelnen Beitrag anzeigen

Benutzerbild von himitsu
himitsu

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

AW: Generierung einer MachineID: aktualisieren?

  Alt 28. Jan 2021, 05:04
Unicode, seit jahrzehnten. (2009)
Ein Char ist nun 2 Byte groß.

Man könnte jetzt einfach und billig alle Char/String gegen AnsiChar/AnsiString erstzen
oder muß überall mal prüfen, dass die Größen passen.

z.B.
Zitat:
Delphi-Quellcode:
function MD5String(M: string): MD5Digest;
var
   Context: MD5Context;
begin
   MD5Init(Context);
   MD5Update(Context, pChar(M), length(M));
   MD5Final(Context, Result);
end;
A) Hier wird jetzt ein anderer Hash berechnet, denn der UnicodeString hat andere Bytes, als wie früher der gleiche AnsiString
B) Und hier wird der Hash falsch berechnet, da nur die erste Hälfte der Bytes des String verrechnet werden -> Lösung: Length(M) * SizeOf(Char)
C) Wenigstens "knallt" es hier nicht, da nur gelesen wird, und zwar weniger als Vorhanden ist. Würde dagen nun z.B. ein UnicodeString komplett in einen nun halb so großen ANSI-Speicherplatz geschrieben, dann hast hinten einen wunderschönen Buffer-Overflow.

D) InlineAssembler funktioniert auch nur in Win32. Für Win64 oder gar andere Platformen ist diese Unit somit auch nichts. (Assembler geht, aber nur als komplette Funktion)

E) Abgesehn davon, dass es MD5 auch schon ferig überall im Delphi versteckt gibt und man es nicht mehr selbst machen muß.


Das Beispiel beim MD5 war nur als Erstes aufgefallen ... davon gibt es bestimmt überall noch viel mehr, überall in dieser Unit.

Weiteres Beispiel: CHAR im TIdSector ist definitiv falsch, denn nur weil Delphi jetzt anders arbeitet, hat sich der Record im Windows nicht geändert, also der ist und bleibt immernoch ANSI.


Ach ja, hier wird auch das "gemessene" CPU-Tempo eingerechnet.
* erstmal sind CPUs/Kerne schon seit ewig dynamisch getaktet, also verändern ständig den Takt, je nach Auslastung
* dann ist die Messung mit Sleep nicht sehr genau
* 500ms ist schon recht lang und es könnte glatt sein, dass auf einem Kern die Messung begonnen wird und auf einem Anderen beendet.
* * zum Glück arbeitet der TimeStampCounter (RdTSC) nicht mehr mit dem echten Takt der Kerne, sondern bei den meisten CPUs nur noch virtell mit dem selben Zähler (eigenem Takt) neben allen Kernen, so dass es nicht auffällt, dass hier die Messung nicht auf einen Kern begrenzt wurde

Dieses GetHardwareID würde schon alleine deswegen bei jedem Aufruf ein anderes Ergebnis liefern und würde somit doch eh nichts Brauchbares liefern?

[EDIT]
Warum wird überhaupt der CPUSpeed gemessen, wenn er nirgendwo verwendet wird?

Da wird massenhaft sinnlos Zeugs bestimmt/ausgelesen/gemessen,
dann sind diese Variablen nichtmal öffentlich (nur im Implementation)
und sie werden auch nicht in result:=MD5Print(MD5String(CPUID+HDDManufactur+HDDSerialno+Winproductid)); verwendet.

Und HDDManufactur/GetIdeSerialNumber wird auch nur etwas "vernünftiges" liefern, wenn das Programm als Admin läuft, da sonst der direkte Zugriff auf die Festplatte zurecht verboten ist. (aber egal, weil wenn nicht als Admin ausgeführt, arbeitet das eh nicht)


Tipp: Via WMI kommst auch an all diese Infos.
Such dir dort ein paar passende Werte raus. Darüber dann ein Hash gebildet (mit einer der Hashfunktionen im Delphi), damit wirst bestimmt mehr/länger Freude haben.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (28. Jan 2021 um 05:33 Uhr)
  Mit Zitat antworten Zitat