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:

Delphi-Quellcode:

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

Delphi-Quellcode:

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

Delphi-Quellcode:

TRegistry.Create

Aufrufe gemacht, bei denen dann das

Delphi-Quellcode:

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:

Zitat von himitsu (Beitrag 1481659)

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:

Zitat von JanWe (Beitrag 1481670)

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)

[Andreas13]

Danke für Antworten und Tipps!
Ich habe am alten Programm-Code etliches modifiziert, angepaßt, auskommentiert, hinzugefügt und verbessert (? :oops:), so daß er wenigstens für die 32-Bit Zielplattform kompiliert werden kann.

D.h. es entsteht ein 32-Bit Programm, welches aber auch unter Windows 64 läuft und größtenteils funktioniert. Neu hinzugefügte Routinen sind u.a.: GetTotalPhysMemory und GetWinVer, weil die vorhandenen nicht funktionierten. Auch an den Registry-Aufrufen mußte vieles angepaßt und verbessert werden.
Mein Ziel war, daß die Routinen wenigstens unter Windows 10 korrekte Ergebnisse liefern. Keine Garantie für frühere Windows-Versionen.

NICHT funktionieren trotz aller meiner bescheidenen Bemühungen die Bestimmung von
- HDD Manufactur No
und
- WinproductID

Ich habe viele Kommentare hinzugefügt, so daß eine Weiterpflege möglich ist. Auch wenn die vom Programm generierte MachineID nicht immer sinnvoll ist, läßt sich jedoch aus den vorhandenen und größtenteils nicht benutzten Detailergebnissen ein Fingerprint für eine Hardware leicht erstellen und bei Installationsrutinen verwenden. Vielleicht kann jemand etwas davon benutzen.

Gruß, Andreas

[himitsu]

Tipp, ich würde nicht den Hash über alles bilden,
sondern in der ID die Teile trennen.
z.B. bei der MD5-Darstellung die ersten Bytes eine Eigenschaft, die nächsten Bytes das Nächste usw. (wichtige Eigenschaften bekommen mehr Bytes)

Und am Ende eine Check-Funktion, welche z.B. bei 80% Gleichheit immernoch ein nnnnnnjaOK liefert.
Wäre z.B. die FestplattenID noch drin und jemand tauscht/repariert/upgraded die Platte, dann wäre es nicht gleich sofort ein Fail, so Lange die restlichen Eigenschaften übereinstimmen.

[Klaus01]

.. über das wmic Programm kannst Du z.B. den Hersteller und den Plattentyp herausfinden.

Code:

wmic diskdrive get Caption
Caption
SAMSUNG MZALQ512HALU-000L2

OS Daten kannst Du so abfragen.

Code:

wmic OS get BuildNumber
BuildNumber
18363

wmic OS get serialNumber
SerialNumber
00913-92704-38983-CAOEM

Grüße
Klaus

[Andreas13]

Zitat:

Zitat von Klaus01 (Beitrag 1481730)

.. über das wmic Programm kannst Du z.B. den Hersteller und den Plattentyp herausfinden.

Code:

wmic diskdrive get Caption
Caption
SAMSUNG MZALQ512HALU-000L2

Ja, aber das ist ein externes Programm und keine Delphi-Routine...

Zitat:

Zitat von himitsu (Beitrag 1481724)

Tipp, ich würde nicht den Hash über alles bilden,
sondern in der ID die Teile trennen...

Gute Idee Himitsu!
Man könnte noch weiter gehen und den HASH-Wert mehrerer Kennzahlen (z. B. CPUID, CPUModel, CPUSpeed, Biosdate, HDDSerialNo, HDDVSerialno, Tempdir, MemTotalPhisical, Wintype, WinUserName etc.) separat ablegen und jeder Eigenschaft eine gewisse Anzahl von Werte-Punkten („Scores“) zuordnen. Zum erfolgreichen Bestehen der Tests kann man eine untere Grenze festlegen, bei welcher derselbe PC noch mit Sicherheit identifiziert werden kann.
Darüber hinaus könnte man eine Option „Software-Upgrade“ oder „Software reparieren“ etc. ins Anwendungsprogramm einbauen, welches den Fingerprint bei einer vorgegebenen Anzahl von Änderungen der PC-Umgebung (z. B. neue Festplatte, neue CPU, neues BIOS etc.) aktualisiert. Dies kann entweder automatisiert ablaufen oder per Vorschlag an den User.
Gruß, Andreas