Generierung einer MachineID: aktualisieren?

[Andreas13]

Hallo Community,
beim Versuch, ein Programm für die Generierung einer MachineID aus dem Jahr 2005 https://www.delphipraxis.net/54640-g...machineid.html unter XE5 zu kompilieren und unter Win-10 zum Laufen zu bringen, erhalte ich eine EConvertError - Exzeption und damit auch keine MachineID...

Hat jemand von Euch evtl. eine aktualisierte und vor allem funktionierende Version des Programms?
Danke im Voraus!
Gruß, Andreas

[himitsu]

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.

[Uwe Raabe]

Das ist aber noch nicht alles! Da werden reihenweise TRegistry.Create Aufrufe gemacht, bei denen dann das OpenKey wegen fehlender Zugriffsrechte in HKLM fehlschlägt - wird aber nicht überprüft - und die TRegistry-Instanzen werden auch nicht wieder freigegeben. Da liegt meines Erachtens zu viel im Argen.

[JanWe]

Zitat von himitsu:

Unicode, seit jahrzehnten. (2009)
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)
[...]

Moin,

nur mal ne Frage:
Was heißt das genau?

daß unter Windowssystemen mit 64Bit der als Win32 compilierten Exe der verwendete/implementierte Inlineasm Code bei der Ausführung übersprungen wird
oder daß, wenn man als 64Bit Anwendung compiliert, bei der Erstellung der InlineAssemblerCode nicht mehr übernommen wird?

Sorry. Klingt vielleicht naiv.
Aber gerade bei sicherheitsrelevanten [z.B. Hash] Funktionen find ich die Frage schon interessant.

[Uwe Raabe]

Zitat von JanWe:

daß, wenn man als 64Bit Anwendung compiliert, bei der Erstellung der InlineAssemblerCode nicht mehr übernommen wird?

Als 64-Bit Anwendung compiliert das gar nicht erst.

[himitsu]

Das betrifft das Compilat, also was Delphi erstellt.
* Inline-Assembler (asm...end innerhalb von Pascal-Funktionen) gibt es nur in Win32. (dieser Feature wurde in neueren Platformen nicht integriert)
* ein Win32-Programm läuft natürlich in Windows 64 (so lange das Win32-Subsystem nicht rausgeworfen wird, so wie schon das Windows16-Subsystem in Windows64 nun nach vielen 10 Jahren verschwand)