TGUID - einzigartige ID auf andere Computer Systeme ?

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

[Sinspin]

Ich habe nicht die geringste Ahnung was UID mit dem neu starten des Rechners zu tuen hat.
Die CLSID's in der Registry (falls es darum geht) sind Windows-weit eindeutige UID die Interfaces für alles mögliche identifizieren. Zum Beispiel, das Paint ein Bild in einem Format öffnen kann das noch nicht existiert hat als Paint veröffentlicht wurde.
Du unterstellst Windows da Verhalten was absolut unnütz ist und somit auch nie existiert hat. Das Neustarten des Rechners hat damit zu tuen dass Dll's nicht ersetzt werden können wärend sie irgendwo in Verwendung sind.
Somit gibt es zwei Optionen das zu tuen.
1. Die existierende Dll umbenennen (was Windwos mitbekommt) und dann die Datei ersetzen. NACH einem Neustart des Programmes wird dann die neue Dll verwendet.
2. Den Windows-eigenen Dienst beauftragen (PendingFileRenameOperations) das ersetzten zu übernehmen wenn der Rechner neu gestartet wird.

Irgendwie kommt es mir so vor als willst Du uns entlocken wie man gültige Keys für jede beliebige Software generiert. Das wäre total Banane. Selbst wenn die wie UID aussehen heißt das nicht dass es UID sein müssen. Und Keys haben eine ganz andere Funktion als UID's was es unnütz macht nach einem Zusammenhang zwischen beiden zu suchen.

[paule32.jk]

- ich will Euch nichts böses.
- ich will auch keinen Key oder einen Generator dafür
- ich will meinen Eigenen Terminal Server basteln (ich weiß, existiert bereits. Aber wie heißt es so schön, Respekt wers' selber macht...)
Ich habe das vor langer Zeit mal mit einen Windows, und Linux-Rechner hinbekommen, was aber nur eine reine Text-Anwendung zum testen war.
Dazu habe ich das RPC-Protokoll verwendet, das von Microsoft abgekupfert in ActiveX und COM als Nachfolger abgekupfert wurde, um dann ein Eigenes "kommerzielles" Ding zu Haben.

Es ist mir durchaus bewußt, das RPC veraltet ist, da es noch zusätzlich auf modernen Computern mit einen SSL-Layer vorgelagert werden muss - und das in beide Richtungen:
Client -> Server
Server -> Client

Es gab auch damals schon Generatoren für automatisierungen derart, das man ein Client Stub und ein Server Stub erhalten konnte, wo dann nur noch die Funktionen implementiert werden mussten (aber halt einmal für Server und einmal für Client).

Dort wurden dann auch UID's eingesetzt - manche wurden sogar für bestimmte Bereiche als "reserviert" deklariert, so dass man dann andere UID's verwenden musste (auch wieder auf beiden Seiten: C/S).

Moderne Ansätze gehen ja dann mit Microsoft über Interfaces, die, wenn man es auf Server ummünzen sollte, die die Microsoft Produktpalette verwenden, nur noch die entsprechenden Compiler zu benutzen.
Man hat dann eine IDE, in der Man per Generator die Interface UID erzeugen lassen kann, oder wie ich das von Delphi 7 her kenne, die ActiveX UID der Komponenten per GUI-Dialog setzen und verändern konnte/kann.

Und wegen meiner geplanten Eigen-Entwicklung, bin ich auf diese im Betreff stehende Thema gekommen.
Auch deshalb, weil ich versuchen wollte, auch Komponenten/Interfaces über DLL als "Einführung" in dieses Thema, zu schreiben - was mir ehrlich gesagt noch nicht so recht gefallen mag, oder ich es evtl. noch nicht verstanden habe - weil es mir halt Bedenken macht, wie denn Funktionen remote ausgeführt werden können (C/S).

Aber ich werde wohl nicht drumrum kommen mich da eher mit Java zu beschäftigen, weil das ja alles möglich machen soll - oder aber wenn man an Microsoft kleben bleiben will, mit C-Sharp (C# Dot.NEt) oder so...

Aber dann habe ich wieder das Problem, das eventuell nötig ist, riesige Packete zu installieren von denen man vielleicht nur die Hälfte braucht.

Weshalb ich dann wieder Eigene Ideen geschaffen habe, Eigene mini-Programme zu entwickeln, die zwar als Pascal-Skripte daher kommen, aber mini-EXE/DLL schreiben können.
Als Beispiel könnt Ihr ja mal in das Thema reinschauen, wo ich mir Infos von KasOB habe helfen lassen, mittels NASM Assembler kleine Programmchen zu schreiben.

Jetzt wird natürlich wieder der Eine und Andere sagen, das man viel Speicherplatz hat, bei den modernen Speichermedien. Aber ich bin noch einer von der alten Schule, bei denen es um jedes Bit und Byte geht.

Ich verlange nicht, das Ihr das versteht, was ich für ein Problem (vielleicht auch nur selbstgemacht) habe, und wo meine Gedanken sind...

Ich freue mich natürlich sehr, wenn hierzu noch einige Ideen und Texte kommen.

[TiGü]

Überlege dir doch einfach anhand deines Anwendungsfalls ein kleines Binärprotokoll und schick dir das per Sockets zwischen den Applikationen hin und her?!

[paule32.jk]

das muss ich sowieso machen.
ich hatte da mal was mit Delphi 7 begonnen, und die Indy Komponenten dazu genutzt.
Allerdings ist D7 nur auf 32-Bit ausgelegt und die Indies kennen kein SSL - es sei denn man wäre auf Overbyte umgestiegen - was natürlich auch mal einen Blick lohnen könnte...

Aber in Delphi 11 sehe ich auch schon die Möglichkeiten 32 und 64 Bit.

Da muss dann noch mehr von mir kommen, an Überlegungen - weil ja (noch) nicht jeder 64 Bit als Client hat.
Was dann der Server macht muss dann entschieden werden.

Ich wollte da nur nicht zweigleisig fahren und 2x Programmieren.

[Delphi.Narium]

Zitat von paule32.jk:

Allerdings ist D7 nur auf 32-Bit ausgelegt und die Indies kennen kein SSL - es sei denn man wäre auf Overbyte umgestiegen - was natürlich auch mal einen Blick lohnen könnte...

Mein Delphi 7 kann mit den Indys aber schon seit gefühlten Jahrzehnten mit SSL umgehen, problemlos.

Oder meinst Du "nur" das mitgelieferte?

Die Indys gibt es aktuell auch im Netz (auch für D7), habe aktuell Version 10.6.2 der Indys.

[paule32.jk]

ja. Die Versionen über 9.
Versionen ab 10 haben aber eine andere Programmierlogik.

[Delphi.Narium]

Zitat von paule32.jk:

ja. Die Versionen über 9.
Versionen ab 10 haben aber eine andere Programmierlogik.

Ist mit noch garnicht aufgefallen, nutze es halt einfach nur.

[paule32.jk]

hast Du diese mal mit im Kontext FPC (Free Pascal Compiler) verwendet ?