TGUID - einzigartige ID auf andere Computer Systeme ?

[paule32.jk]

ich mein, es gibt ja verschiedene Arten mit Unterknoten:

- Mobile Telefone Consumer (Samsung, Nokia, Huway, ...)
- Mobile Telefone Business (Telecom)

- Festnetz Consumer (ISDN, 56k, TelecomBTX, ...)
- Festnetz Business (ISDN)
wobei man hier sagen kann: "früher brauchte man Telefon, um Internet zu machen. Heute braucht man Internet, um Telefon zu machen."

- Server (IBM, Dell, Cytrix, ...)
- Business PC (Apple, Silicon, ...)
- Consumer PC (Gamer, Büro (Home Office), Laptop, ...)
- Workstation (Router(FritzBox'en))

für jeden Anwendungsfall gibt es entsprechende Programme...
Microsoft hat ja schwer daran gearbeitet, Ihre Produkte untereinander kompatibel zu halten - wodurch dann VBX, ActiveX, COM, und dann COM+ zu etablieren - hin zu Remote Desktop / Terminal Server.

Java wurde dann zu C-Sharp oder: Mono (*nix Leute wissen bescheid ?)
etc. pp. ...

Damit verbunden entstanden die tollsten Entwicklungen, wenn ich das so überblicke:
- für jedes Control wurden etliche GUID für die Übernahme in Interfaces verbraten
- und das für jede angestöpselte Anwendung mit Subknoten.

Dann hat man die Fraktion der PC-Bild Leser, die sich ja alle 14 Tage die Zeitschrift (wenn dann schon im Abo mit fetten Programmen drauf) besorgt haben, um dann zu sehen, wie toll doch die Programme sind, dann ein, zweimal probiert, dann lagen die auf der Festplatte (samt GUID und Registry Einträgen) ...
Und dann die nächste Ausgabe ...
jo das ist/war auch so nen tolles Kapitel ...

Aber wo ich denn hinaus wollte:
Es wurde ja schon halbwegs angesprochen, das Windows zufreuden der Mausschubser in vielen (Arzt)Praxen eingesetzt wurde/wird.
Und wenn dann so ein "gebrauchter" PC gekauft wurde (weil ja die Krankenkasse nicht gerade spendabel war) und dann hat der genervte bekannte des Arztes Überstunden am zurechtbiegen verbracht...

Für solche Fälle müsste es doch eine zentrale Anlaufstelle für die Praxen geben ?
Für das Finanzamt gibts ja auch ELSTER...

Heute würde man das mit Thin-Clients bewerkstelligen, bei denen beim anschalten ein Boot-Image geladen wird, und die Datenbanken dann über Server laufen.

ABER:
Delphi ist immer noch zu sehr auf Desktop ausgelegt.
Also schließe ich, das es für die Server-Anwendungen eine Datenbank gibt, die GUID sammeln.
So wie die Keys für Windows.
Es gibt zwar die Möglichkeit Windows so zu installieren, das diese nicht eingegeben werden muss.
Allerdings hat man dann noch den Login-Punkt, bei dem die E-Mail abgefragt wird.
Und genau an diesen Punkt, hat dann Microsoft die IP.
Und mit der IP, die MAC, und den möglichen Standort.

Da gibt es doch das Vector-Verfahren, bei denen Wohn-Blocks eine IP bekommen, die dann mehrere Bewohner nutzen, was dann "normales" Serving nicht möglich ist, weil dann eben durch NAT gesurft wird, und wie bei alten Zeiten bei AOL das Netz im Netz war/ist.

Von daher: wie verhaöt es sich denn, wenn jemand seine "gesaugte" Kopie von Windows + Key weitergibt ?
Gibt ja seit neuesten diese Reburbisch Shops ...

Dann wird die GUID doch auch wieder mit Hilfe der MAX erstellt, und damit die Möglichkeit besteht, das zwei Benutzer die gleiche haben - aber unterschiedliche Programme.
Also Benutzer A gibt ISO + Key weiter, ohne die alte Kopie zu löschen.

Hat da sich schon einer durch die EULA gelesen ?

[jaenicke]

Zitat von paule32.jk:

Dann wird die GUID doch auch wieder mit Hilfe der MAX erstellt, und damit die Möglichkeit besteht, das zwei Benutzer die gleiche haben - aber unterschiedliche Programme.
Also Benutzer A gibt ISO + Key weiter, ohne die alte Kopie zu löschen.

Was hat denn die Mac-Adresse der Netzwerkkarte mit dem verwendeten Lizenzschlüssel zu tun? Zur Generierung wird auch nur eine physische Mac Adresse verwendet. Sind nur virtuelle Netzwerkkarten vorhanden, wird ein anderer Algorithmus verwendet.

[paule32.jk]

nun... virtuelle MAC Adressen werden auf Grundlage von bestehenden MAC Adressen vergeben.
Man kann daher auch von Layer sprechen/schreiben, da man die V-MAC "auf" eine bestehende MAC aufschaltet.
Man könnte ja zum Beispiel die lokale Adresse 127.0.0.1 heran ziehen, die auf jeden Computer-System mit einer dazugehörigen MAC Adresse vorhanden ist (ob nun eine NIC installiert ist oder nicht) - das ist dann eine Software NIC.
Wie man das nun im Detail macht würde wohl sicher hier den Rahmen sprengen...
Dann gibt es ja auch noch die drivers/etc/hosts Datei, in der man lokales DNS emulieren kann, um so mittels dem IIS virtuelle Domains/Hosts zu einer IP zu binden (und zurück) kann, und so lokale Entwicklung von WebSeiten ermöglicht wird.

von daher nur als kleiner Wink: öffne doch mal die Eingabeaufforderung-Console und tippe da mal folgendes Kommando ein: C:\ipconfig
und schon kann man Informationen über IP und MAC bekommen.

[TiGü]

Zitat von paule32.jk:

von daher nur als kleiner Wink: öffne doch mal die Eingabeaufforderung-Console und tippe da mal folgendes Kommando ein: C:\ipconfig
und schon kann man Informationen über IP und MAC bekommen.

Ich hätte ja jetzt eher "ipconfig /all" genommen, aber du machst das schon!

Inzwischen hat dein vorletzter Beitrag auch irgendwie nichts mehr mit der Ursprungsfrage zu tun.
Hast du das Konzept eines globalen eindeutigen Bezeichners nun verstanden oder nicht?

[Sherlock]

Also geht es eigentlich um Product Key, die GUIDs zum verwechseln ähnlich sehen. Da bin ich gespannt, wie dieser Thread weiter geht.

[paule32.jk]

@sherlock:

- indirekt:
ein Teilnehmer hat ja gepostet, das andere Möglichkeiten neben das MAC noch in den GUID Key verwendet werden, um diesen zu produzieren.

- direkt:
Es gab mal eine Windows Version, bei der die Lizenz.Key's nicht mehr ausgereicht haben, und Microsoft sein Produkt neu kompilieren musste, um dann auf "neue"Consumer Key's zuzuführen.

Ich will jetzt nicht erwarten, das einer mit nen Windows Key-Generator kommt.
Aber ich wollte mal das Thema abwarten, wie andere auf den Titel dieses Beitrages Ideen hinzufügen.

Irgendwann wird wohl dann doch Einer kommen, und aus den jetzt schon gelieferten Ideen, Code usw. ... neue Ideen zu entwickeln.

Aber ja (betrifft ja auch Embercaerdo mit seinen Produkten).
Es ist halt der Trend, das immer weniger Desktops eingesetzt werden, hin zu mehr "Components".

Ich hatte ja schon angedeutet, dass die Remote Desktop Dingends ja aus der *nix Zeit stammt - dort wo man das RPC (Remote Procedure Call) finden kann - was dann zu ActiveX und COM+ wurde.

Das RPC Protokoll anfürsich nutzt ja für die Übergabe nur eine 32-Bit Nummer zu jeder Methode, die einmal auf den Server, und einmal am Client stimmen muss.
Selbst unter Windows haben die DLL Funktionen Nummern, die, wie ich mitbekommen habe unter einer 16 Bit Zahl aufgerufen werden können - neben dem Funktionsnamen.

Man kann ja auch das Tool dumpbin benutzen, um die RVA's der DLL anzuzeigen.
Neue Windows-Versionen nutzen nicht mehr diese Nummer (im Kernel kann ich mir das vorstellen, dort wo Information Hidding oder auch zusätzlich Obfuscatoring gemacht)

Ich weiß jetzt nicht, ob man das Tool kostenlos als Einzelpaket vom Internet saugen kann... aber es ist auf jedem Falle in den Tools der Visual Studio (Community) Version 19 (2022) mit bei.

Ich kann aber keine detailierten Angaben machen, was man so machen kann, nur mal ein paar Tipps.
Aber ich muss da neutral bleiben, damit keine Rechtsverletzungen auftretten, und dann gesagt wird: "Ja der hat doch das so gesagt, wie ich das machen muss...".

Nene, damit will ich nix zu tun haben.
Daher distanziere ich mich auf jeden Fall.

Deshalb auch nur am Rande:
"ALLE ANGABEN AUF EIGENE GEFAHR, UND AUSSCHLIEßLICH NUR FÜR TESTZWECKE, UND NUR FÜR DEN PRIVATEN, NICHT-KOMMERZIELLEN NUTZUNG".


@TiGü:
Ich versuche zu verstehen...
Ich fachsimple mal, das die interne Datenbank von Windows in den Registrierung oder einer versteckten Datei gespeichert werden, und bei jedem "neuen" Setup eines Programmes geändert bzw. neu verteilt werden.
Der Windows-Loader - egal jetzt ob DLL oder EXE, der setzt ja auch intern immer neue Offset's zusammen. Und wenn dann der Computer aus und ein-geschaltet wird, werden dann die neue Offset verwendet.

Somit leuchtet es mir auch ein, das nach (fast) jeden neuen Setup/Install einer Komponente der Computer neu gestartet werden muss...

[jaenicke]

Zitat von paule32.jk:

Es gab mal eine Windows Version, bei der die Lizenz.Key's nicht mehr ausgereicht haben, und Microsoft sein Produkt neu kompilieren musste, um dann auf "neue"Consumer Key's zuzuführen.

Das muss dann aber schon Ewigkeiten her sein.

Zitat von paule32.jk:

Das RPC Protokoll anfürsich nutzt ja für die Übergabe nur eine 32-Bit Nummer zu jeder Methode, die einmal auf den Server, und einmal am Client stimmen muss.

Es gibt viele RPC Protokolle und diese Form der Übermittlung ist eher unüblich. Meistens wird eher ein Name oder (z.B. bei REST) eine URL verwendet.

Zitat von paule32.jk:

Ich fachsimple mal, das die interne Datenbank von Windows in den Registrierung oder einer versteckten Datei gespeichert werden, und bei jedem "neuen" Setup eines Programmes geändert bzw. neu verteilt werden.
Der Windows-Loader - egal jetzt ob DLL oder EXE, der setzt ja auch intern immer neue Offset's zusammen. Und wenn dann der Computer aus und ein-geschaltet wird, werden dann die neue Offset verwendet.

Somit leuchtet es mir auch ein, das nach (fast) jeden neuen Setup/Install einer Komponente der Computer neu gestartet werden muss...

Du stellst dir das glaube ich falsch vor. Die Offsets kommen schlicht dadurch zustande, dass z.B. Objektreferenzen in Delphi an einer bestimmten Speicherstelle liegen. Von dort aus wird dann grob gesagt das Klassengerüst drübergestülpt um die echten Adressen zu ermitteln. Wenn z.B. ein Feld 50 Byte nach dem Beginn der Klasse liegt, werden diese 50 Byte zu der Adresse hinzugezählt, an der die Objektreferenz liegt.

Genauso werden DLLs in den Speicher geladen und liegen dann an einer bestimmten Stelle im Speicher. Genauso kann man von dort aus dann die relativen Speicheradressen der Funktionen über die Ladeadresse in absolute Adressen umwandeln.

Im Detail steckt da noch einiges mehr dahinter, z.B. die Virtual Method Table usw., aber als grob vereinfachte Datstellung sollte das reichen.

Es gibt keine interne Datenbank oder so, sondern in den DLLs sind Offsets zu den einzelnen Methoden gespeichert. In Kombination mit der Adresse der DLL im Speicher bekommt man dann die absolute Adresse. Die Offsets sind in den DLLs pro Version fest und ändern sich nur ggf. bei einer neuen Version der DLL. Die echte Speicheradresse wird jeweils dynamisch ermittelt.

Ich sehe allerdings nicht, was das mit dem Thema zu tun hat und worauf du eigentlich hinaus willst.