# Windows-Maschine eindeutig identifizieren



## tuxedo (19. Mrz 2009)

Hallo zusammen,

ich bin auf der Suche nach Merkmalen einer Windows (Vista) Installation die man dann kombiniert als "Windows-Identifikation" benutzen kann. 

Sprich: Ich hab einen Java-Client der dem Java-Server eine ID mitteilt die die Windows-Maschine recht zuverlässig eindeutig identifiziert.

Ich weiß, eindeutig ist so ne Sache, erst recht wenn es um sowas wie eine Hardware-ID geht.

Die ID am Server generieren, dem Client übermitteln und der speicher sie sich dann fällt erstmal flach. Da kommt man doch zu schnell dahinter.

Was ich bisher habe:

Volumenseriennummer der Windows-Platte
kombiniert mit
Datum des Windows-Verzeichnisses.

Das hat bisher auch gut geklappt, nur tauchen jetzt die ersten mit Rechnern auf die vom selben Hersteller und Typ sind, und die geclonte Festplattenimages drauf haben. 

Fällt hier noch jemandem etwas ein was man zurate ziehen könnte um die ID etwas eindeutiger zu machen? Wenn alle Stränge reissen muss ich die ID halt doch am Server generieren und der Client muss sie sich irgendwo versteckt merken.

Würde mich aber freuen wenn jmd. noch ne tolle Idee hat.

- Alex


----------



## maki (19. Mrz 2009)

>> Das hat bisher auch gut geklappt, nur tauchen jetzt die ersten mit Rechnern auf die vom selben Hersteller und Typ sind, und die geclonte Festplattenimages drauf haben.

Wenn du erst auf Virtualisierte Clients triffst wird das ganze noch besser 

Glaube wirklich das es mittlerweile keine 100% Möglichkeit mehr gibt Maschinen immer und jederzeit an der HW oder SW zu identifizieren.


----------



## tuxedo (19. Mrz 2009)

maki hat gesagt.:


> >> Das hat bisher auch gut geklappt, nur tauchen jetzt die ersten mit Rechnern auf die vom selben Hersteller und Typ sind, und die geclonte Festplattenimages drauf haben.
> 
> Wenn du erst auf Virtualisierte Clients triffst wird das ganze noch besser
> 
> Glaube wirklich das es mittlerweile keine 100% Möglichkeit mehr gibt Maschinen immer und jederzeit an der HW oder SW zu identifizieren.



Naja, ne 100,0%ige Möglichkeit gibts sicher nicht. Aber 99% würden mir erstmal reichen. Bisher lieg ich geschätzt bei 70%.

Ne andere Idee kam mir gerade:

Ich nehm ein Merkmal vom lokalen PC und kombinier das mit einer zufälligen, eindeutigen ID vom Server. Das muss der Client dann halt versteckt speichern.

Da der Client-Login am Server noch zusätzlich mit Benutzername und PW läuft, kann ich ja dann steuern welchen/wieviele Rechner der User benutzen darf.

Gegenvorschläge? Bessere Ideen?

- Alex


----------



## fjord (19. Mrz 2009)

Wie wäre es noch mit sowas wie Pfad zu deinem Programm, Username, PROCESSOR_IDENTIFIER, Computername und so weiter? Und das ganze dann natürlich durch eine Hashfunktion jagen.


----------



## KSG9|sebastian (19. Mrz 2009)

MAC-Adresse mit aufnehmen


----------



## tuxedo (19. Mrz 2009)

>> Pfad zu deinem Programm

Bei Webstart ist das glaub etwas "schwierig"

>> Username

Loggt er sich mit nem anderen Namen ins Windows ein hat das dann eine andere ID zur Folge -> nicht brauchbar

Client-Server-Anwendungsbenutzername: Naja. Sehe da noch nicht den "Effekt" dahinter.

>> PROCESSOR_IDENTIFIER

Prozessor-ID? Gibts doch AFAIK nicht mehr und gabs nur ne Zeit lang bei Intel.
Und wenn damit die Prozessorbezeichnung gemeint ist: Zei OEM Systeme hätten da wohl die gleiche CPU ... Geht also auch recht schlecht

>> Computername

Ja, das wäre ein weiteres Beispiel. Allerdings können sich Computernamen bei Anwender-PCs doch hin und wieder mal ändern, was dann auch eine neue ID zur Folge hätte.

>> so weiter

Ja, ich höre ?! 

Über solche Dinge hab ich mir schon den Kopf zerbrochen. Es müssen halt Merkmale sein die die allerwenigsten während der Lebensdauer einer Windows-Installation ändern. 

Hab auch schon über die Windows-Seriennummer nachgedacht. Aber da sind ja trotz WGA noch ziemlich viele geklaute Nummern unterwegs, so dass man wohl schnell auf doppelte trifft. Wobei da die Frage ist wie verheerend das werden könnte. OEM Systeme haben i.d.R. ja alle eine echte Seriennummer für Windows...

Denke ich nehm die Variante aus Servergenerierter ID und lokalem Merkmal. Dann wirds zu 100,0% eindeutig. Muss nur die ID versteckt genug speichern.

- Alex


----------



## maki (19. Mrz 2009)

> Gegenvorschläge? Bessere Ideen?


kA ob das besser/umsetzbar wäre, aber warum gibt der Server den Clients nicht ein eindeutiges Token mit?



KSG9|sebastian hat gesagt.:


> MAC-Adresse mit aufnehmen


Kann bei Virtuellen Machinen sinnfrei sein.


----------



## tuxedo (20. Mrz 2009)

maki hat gesagt.:


> kA ob das besser/umsetzbar wäre, aber warum gibt der Server den Clients nicht ein eindeutiges Token mit?



Öhm :bahnhof:. Ist das nicht das was ich zuletzt als :idea: hatte? --> 



			
				tuxedo hat gesagt.:
			
		

> Denke ich nehm die Variante aus Servergenerierter ID und lokalem Merkmal. Dann wirds zu 100,0% eindeutig. Muss nur die ID versteckt genug speichern.



??

Oder hast du was anderes gemeint?

Vielleicht noch etwas mehr Hintergrund:

Wie gesagt: Ich hab eine Client-Server-Anwendung. Jeder User hat einen Benutzernamen und Passwort. Um Account-Missbrauch und andere Dinge zu verhindern, möchte ich möglichst zuverlässig und "sicher" einschränken, dass der User seinen Account auf maximal x Computern benutzten kann (nicht einfach nur das "gleichzeitige" sondern das "überhaupt" verhindern). Und das ein Computer nur mit einem Account benutzt werden kann. 

- Alex


----------



## maki (20. Mrz 2009)

> Oder hast du was anderes gemeint?
> 
> Vielleicht noch etwas mehr Hintergrund:
> 
> Wie gesagt: Ich hab eine Client-Server-Anwendung. Jeder User hat einen Benutzernamen und Passwort. Um Account-Missbrauch und andere Dinge zu verhindern, möchte ich möglichst zuverlässig und "sicher" einschränken, dass der User seinen Account auf maximal x Computern benutzten kann (nicht einfach nur das "gleichzeitige" sondern das "überhaupt" verhindern). Und das ein Computer nur mit einem Account benutzt werden kann.


So in der Art, aber verzichte noch auf das "lokale" Merkmal 
Lass die Ids/Token nur vom Server generieren, vom Client brauchst du nicht wirklich etwas dafür.


----------



## tuxedo (20. Mrz 2009)

maki hat gesagt.:


> So in der Art, aber verzichte noch auf das "lokale" Merkmal
> Lass die Ids/Token nur vom Server generieren, vom Client brauchst du nicht wirklich etwas dafür.



Naja, das "lokale" Merkmal wäre nur dazu da damit nicht einer auf die Idee kommt die ID von Rechner A auf Rechner B zu benutzen ...(falls er rausfindet wo die ID steht und wie man sie ändern kann). Gültig wäre somit nur beides in Kombination.

- Alex


----------



## Geeeee (20. Mrz 2009)

KSG9|sebastian hat gesagt.:


> MAC-Adresse mit aufnehmen


Du bist dadrauf noch nicht eingegangen. Ich finde das recht gut.
Natürlich kann man die per Hand ändern, aber dennoch wird man es nicht so oft, wie man ggf. mal den Computernamen ändern muss. Außerdem ist doch eigentlich in jedem Rechner heutzutage ne Karte drin (z.b. onboard)


----------



## tuxedo (20. Mrz 2009)

Sorry, hatte ich vergessen.

MAC Adressen sind toll. Problem ist nur: Es gibt unter den Anwendern auch Laptop-User. Und darunter gibts offensichtlich nicht wenige, die je nach Location ihre LAN-Karte an und die WLAN-Karte ausschalten (oder umgekehrt). Aus der Sicht von Java sind dann auf einmal MAC Adressen "weg" oder plötzlich "wieder da". 
Sprich: Daheim hab ich nur die LAN-Karte an. Also hab ich eine MAC-Adresse sichtbar. Unterwegs benutz ich dann vllt. WLAN und schalte die LAN-Karte ab (bzgl. das Tool zum wechseln der Netzwerkeinstellungen macht das für mich). Die LAn-Mac ist dann "weg", dafür aber die WLAN-Mac da. 
Andere wiederum benutzen einen UMT-Stick, den sie nur bei Bedarf anstecken. Dessen Mac ist dann auch nicht immer präsent.
"Zuverlässig" ist das also nicht wenn Laptop-User im Spiel sind. Leider...

- Alex


----------



## Geeeee (20. Mrz 2009)

Verständlich. Hatte nur den einfachen Heimrechnerbenutzer im Blickfeld.


----------



## ice-breaker (20. Mrz 2009)

Wie wäre es mit Motherboard-Id usw?
Da stehen ja Fertigungsdatum drinne, ne Seriennummer usw


----------



## Geeeee (20. Mrz 2009)

ice-breaker hat gesagt.:


> Wie wäre es mit Motherboard-Id usw?
> Da stehen ja Fertigungsdatum drinne, ne Seriennummer usw


Da kommste aber nur noch mit JNI weiter.
Wenn wir über die Definition von Rechner sprechen, dann ist das MB wohl eines der Teile wo man sagen kann: DAS ist der Rechner.


----------



## ice-breaker (20. Mrz 2009)

Mac Adresse würde auch JNI benötigen.
Und ich bezweifel einfach mal ganz frech, dass man mit den Platformunabhängigen wirklich ne gute Id basteln kann, denn an die Dinge, die Computer wirklich unterscheiden (Hardware) kommt man nicht ran.


----------



## tuxedo (20. Mrz 2009)

>>  	 Mac Adresse würde auch JNI benötigen.

Definitiv nein. Das ist was was Java von Haus aus kann.

>> Wie wäre es mit Motherboard-Id usw?

Hmm, gibts denn da einen herstellerweiten Standard? Also eine "genormte" Stelle an der sowas steht? Wenn eine Windows-Standard-DLL da dran kommt, wäre das recht geschickt.

Auf der anderen Seite: AFAIK macht vllt. jeder Hersteller seine eigene Seriennummer, aber "weltweit unique" ist die wohl auch nicht. Ist ja nicht gesagt dass die ID von Hersteller A nicht zufällig auch bei Hersteller B auftaucht?!

>> Und ich bezweifel einfach mal ganz frech, dass man mit den Platformunabhängigen wirklich ne gute Id basteln kann, denn an die Dinge, die Computer wirklich unterscheiden (Hardware) kommt man nicht ran.

Naja, die MAC Adresse ist da schon das beste was man kriegen kann, ohne sich zu sehr mit JNI/JNA zu beschäftigen und alle anderen Komponenten wie Grafikkarte, RAM, Festplatte, BIOS und Co. hinzuzuziehen. Aus all diesen Merkmalen ließe sich wohl eine 99,9%ige ID erzeugen, aber auf der anderen Seite: Verreckt einem nur mal die Grafikkarte oder ein RAM-Riegel, so ist man gleich wieder aufgeschmissen und muss dem User eine neue ID geben und die alte löschen.

Bei Linux und MacOS ist das alles kein Problem. Zumindest nicht so ein Problem wie in Windows. Mac's haben ne Apple-Seriennummer. Die kann man ganz einfach auslesen. 
Linux: Nun, da gibts zahlreiche Möglichkeiten. Eine davon ist die Herstellerbezeichnung und Seriennummer der Festplatte. Wenn das nicht reicht, kann mans noch mit anderen Merkmalen kombinieren.

Gruß
Alex


----------



## Spacerat (22. Mrz 2009)

MD5 THIS: "System.getProperties()" ...naja... ist vllt. übertrieben, aber immerhin ein oder mehrere Anhaltspunkte.


----------



## tuxedo (22. Mrz 2009)

Darin sind doch auch wieder benutzerspezifische Dinge enthalten, so dass jeder Systembenutzer seine eigene ID bekäme ... :-(


----------



## Spacerat (22. Mrz 2009)

Ja... Genau das meinte ich mit "übertrieben". Andererseits könnte trozt der benutzerspezifischen Angaben ein Hash darauf von Maschine zu Maschine anders sein. Wenn's nicht reicht, nimmt man halt noch "getEnv()" dazu. Der Hash muss allerdings auch Clientseitig gespeichert werden, da sich Pfade usw. auch auf ein und der selben Maschine recht häufig ändern können. Eine Idee wäre es, wenn man beim 1. Connect (z.B. Registration) diese Informationen sammelt, hashed, auf dem Server speichert, eine Klasse oder ein Paket der Anwendung damit verschlüsselt und diese(s) dann dem Benutzer zukommen lässt. Soweit so gut. Der Benutzer könnte immer noch die gesammte Anwendung, sammt verschlüsselter Klasse / Paket auf einen anderen Rechner kopieren. Aber wir haben ja, wie du sagst, noch die MAC-Adresse (haben wir? k.A.) welche wir noch in den Hash mit einbeziehen können.


----------



## Gast2 (22. Mrz 2009)

Moin,

soweit ich weis versucht Windows jedem System eine eigene GUID zuzuweisen ... ich weis nicht wie das mit geclonten Pladden aussieht - also wann die GUID für das System erzeugt wird (Installation oder erstmaliger Start) ... jeder Benutzer bekommt ebenfalls eine eigene GUID basierend auf der vom System

am besten solltest Du mal bei einem Forum nachfragen die sich mehr mit Windows beschäftigen 

hand, mogel


----------



## DellCapone (22. Mrz 2009)

Ich bin mir grad nicht sicher wie es auf anderen Systemen aussieht. Aber z.B. auf Dell-Geräten hättest du die Servicetag die deinen 99% entsprechen könnte. Diese lässt sich auch unter Windows und Linux auslesen. Ich glaube so ein EINDEUTIGES Merkmal wird man nicht finden.


----------



## tuxedo (23. Mrz 2009)

Warum wird eigentlich immer nur das letzte drittel des Threads gelesen?! Thread abhaken geht ja nun hier im neuen Forum auch nciht mehr *schade*

Wurde doch bereits geklärt dass es am sichersten ist die ID vom Server generieren zu lassen. Dann gibts keine Duplikate. Bzgl. der Sicherheit dieser Technik: Die ID muss beim Client gespeichert werden. In meinem Fall am besten so, dass der User sie

a) nicht findet
b) kein Plan hat was das sein soll
c) die ID, selbst wenn er sie gefunden hat, auf einem anderen System nicht einfach so benutzen kann.

Dazu einfach ein lokales Merkmal mit der servergenerierten ID kombinieren und fertig 

Deshalb an dieser Stelle nochmal: Danke für all die Überlegungen und Tipps. 

---->>>> PROBLEM GELÖST <<<<----

Gruß
Alex


----------



## tuxedo (25. Mrz 2009)

*RE-OPEN*

Problem doch nicht gelöst. Grund:

Ich kann zwar via Server eine ID generieren: Aber wo speicher ich die Benutzerübergreifend OHNE Admin-Rechte?
Der Java Preference Store gilt pro Systembenutzer. D.h. jeder Systembenutzer würde eine eigene ID erhalten --> deckt sich nicht mit meinen Anforderungen.

Bin jetzt dann doch wieder n Stück zurück gegangen und hab wieder über ein Windows-Merkmal nachgedacht. Unter anderem auch über den Windows CD-Key den man bei der Installation eingeben muss. Wenn es sich nicht gerade um Firmenrechner dreht, die evtl. geklonte Images im Einsatz haben, so dürfte der CD-Key, in Verbindung mit meinen bisherigen Merkmalen (Volume-Serial + Zeitstempel von C:\Windows) ziemlich eindeutig werden. Zur Not noch den Hostnamen mit rein nehmen.

Problem ist nur: 

a) Wie komm ich an diesen CD-Key?
b) Komm ich da überhaupt ohne Admin-Rechte ran?

Zu a): Steht in der Registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion im Key "DigitalProductId". Mit The_29's Pure Java Registry Lib komm ich da nicht ohne Runtime-Exec-Regedit erweiterung dran da es sich um ein REG_BINARY handelt, welches von der java.dll nicht gehandhabt werden kann. Einsatz Regedit fällt erstmal flach.

Zu b): Werd gleich mal nen nieder privilegierten User anlegen und das testen. Aber wie's da bei Vista aussieht weiß ich auch noch nicht. Denke das könnte eine massive Hürde werden wenn ich da Admin-Rechte brauche (deckt sich nicht mit meinen Anforderungen).

- Alex


----------



## Ebenius (25. Mrz 2009)

Preferences bietet einen User- und einen System-Tree. Letzterer ist natürlich nur von Administratoren (oder anderen Super-Benutzern, keine Ahnung) schreibbar. Das heißt: Als Admin installieren und Key erzeugen. Auslesen sollten dann eigentlich alle Benutzer können; mutmaße ich aber nur.

Ebenius


----------



## thE_29 (25. Mrz 2009)

Irgendwie kann man (wenn ich ein paar Aussagen glauben schenken darf) das Runtime.exec oder den ProcessBuilder dazu bringen, dass diese Admin Abfrage kommt! Dadurch würde es funktionieren...

Wie das aber geht, weiß ich auch nicht..
Desweiteren man kann die registry auch so sperren, dass da kein Admin User lesen darf. Dann hättest du sowieso ein Problem..

Und warum speicherst du das nicht Online wo ab? Oder sollte die App auch ohne Netz gehen?


----------



## tuxedo (25. Mrz 2009)

Online speichern.. hmm. das wäre auch noch so ne idee. könnte man anhand des useraccounts in der eh schon exsitierenden DB speichern....

Aber quatsch... Macht doch keinen Sinn:

Ich generiere via Server für den Client eine ID. Und die speichere ich dann auf dem Server? Wie soll sich denn dann der Client damit am Server identifizieren? Geht dann ja gar nicht. 

Aber was anderes:

Hab eben nen "User" in Windows XP erstellt. Mit dem konnte ich ohne schwierigkeiten und ohne "run as" folgendes ausführen:

```
regedit /e myfile.reg "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
```

Dann bin ich noch auf das hier gestoßen:


```
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v DigitalProductId
```

Letzteres liefert ein ebenso brauchbares Ergebnis. Ob das nun auch mit dem normalo-User geht hab ich nicht getestet. Aber da prinzipiell der lesende Zugriff auf die Registry auf diesen Schlüssel geht, denke ich wird der zweite Befehl auch funktionieren. 

Jetzt ist nur noch die Frage bzgl. Vista... 

Hat hier jmd. Vista und kann beide Befehle mal mit einem nicht-Admin User testen?
Was mich im Vista-Fall vor allem interessiert ist ob das UAC-Ding da im Weg steht. 

Von Paranoia-Admins für gesperrte Registrys ("kein nicht-Admin darf lesen") fallen durch die Anforderungen durch. Sprich: Die können die Anwendung dann halt nicht benutzen. Denke nicht dass ich mir da viele "Feinde" machen werde. Mir persönlich ist in meiner Laufbahn sowas auch noch nicht unter gekommen (was nicht heisst dass es sowas nicht gibt), und ich war schon in ner handvoll Firmen mit sehr restriktiver IT.
Nebenbei ist die Anwendung auf eine spezielle Heimanwender-gruppe ausgerichtet. 

Gruß
Alex


----------



## tuxedo (25. Mrz 2009)

Ebenius hat gesagt.:


> Preferences bietet einen User- und einen System-Tree. Letzterer ist natürlich nur von Administratoren (oder anderen Super-Benutzern, keine Ahnung) schreibbar. Das heißt: Als Admin installieren und Key erzeugen. Auslesen sollten dann eigentlich alle Benutzer können; mutmaße ich aber nur.
> 
> Ebenius




Das hab ich auch schon feststellen müssen. Anwendung aber erst als Admin laufen lassen geht aber nicht. Deshalb fällt die Option leider weg.

Was auch noch funktioniert hätte, jedoch mehr Aufmerksamkeit erregt hätte:

Eine Datei in C:\Documents and Settings\All Users\Documents anlegen. Die kann dann zwar nur vom ersteller nochmals geschrieben werden, aber es hätte ja gereicht wennsie überhaupt mal einer erstellt und die anderen sie nur noch lesen. 

Allerdings: Wenn dann einer seine Platte aufräumt und dann diese Datei abhanden kommt, wäre die servergenerierte ID auch wieder hinüber.


----------



## Ebenius (25. Mrz 2009)

Hast Du das mit nem XP Professional probiert? Bei vernünftigen Policies wird regedit mit 0815-Benutzer nix.

Ebenius


----------



## thE_29 (25. Mrz 2009)

Was ist beim Online speichern so schlimm?
Du "generiest" jedesmal den Key neu und guckst ob der in der DB vorhanden ist. Wenn nicht ist nicht erlaubt zu starten..
Ich habe daheim Vista, weiß aber nicht ob ich heute zum Testen kommen. Wenn es den ohne Admin funktionieren würde (was ich mir nicht so vorstellen kann), dann kann ich das ja im RegistryWrapper einbauen 
Vorallem kann ich mir dann das Puffern sparen, da ich ja bei regedit /e ziemlich viel rauskam..

Version 3.5 steht an


----------



## tuxedo (25. Mrz 2009)

Ebenius hat gesagt.:


> Hast Du das mit nem XP Professional probiert? Bei vernünftigen Policies wird regedit mit 0815-Benutzer nix.
> 
> Ebenius



Jepp, war XP Prof SP3 auf einem Coorporate PC. Haben zwar DOmänenrichtlinien, aber die greifen ja bei einem nur lokalen User nicht. 

Hab ergo ein Standard XP System ohne spezielle Richtlinien mit einem Normalo-User (kein Admin, kein Poweruser) getestet. Lief ohne Probleme.

@the_29

Weiß nicht ob du alles gelesen hast:

Ich will die ID um den Computer weitgehend eindeutig identifizieren zu können. Den Benutzeraccount soll man nur auf max. 2 Computern nutzen können.

Entweder ich schaffs dass ich eine sehr zuverlässige Merkmal im Windows-System finde und sich der Rechner damit jedesmal selbst am Server identifiziren kann (zusammen mit den Accountdaten),

ODER

ich generiere eine ID am Server und schick sie dem Client. Dieser speichert sie sich für alle Zukunft und nutzt diese bei jedem Login.

Wenn ich die ID jetzt am Server generiere und am Server speichere: Wie soll dann die Identifikation des Computers noch funktionieren? Verstehst du was ich meine?

Mac-Adresse und Co. fallen ebenfalls raus (wieso kann man weiter vorne nachlesen).


----------



## Gast2 (25. Mrz 2009)

Moin,

HKLM ist für jeden Deppen lesbar - aber nicht schreibbar ... da packe ich auch immer Rechner-Konfigurationen rein die Uswer nur lesen dürfen (unter HKLM/Software/<Firma>/<...>)

HKCU ist nur für den aktuellen Benutzer ... wenn sich ein anderer Nutzer anmeldet, stehen AFAIK andere Werte drinnen ... habe ich aber noch nie benutzt

hand, mogel


----------



## tuxedo (25. Mrz 2009)

Das klingt prima und bestätigt meinen Test.
Danke für den Hinweis.

- Alex


----------



## Gast2 (25. Mrz 2009)

Moin,

HKCU ist übrigens nur ein Link nach HKU und ist tatsächlich der angemeldete User (vgl. Wikipedia)

so ... ich weise Dich nochmal darauf hin das jedes Windows-System eine eigene GUID bekommt ... ein Bug in Windows 2000 hilft Dir sogar die GUID zu finden ... ich weis aber nicht ob der Registry-Pfad noch für XP und Vista stimmt

hand, mogel


----------



## tuxedo (26. Mrz 2009)

Das mit der GUID ist mir glaube ich bekannt. Bin mir aber nicht 100%ig sicher. Wenn es das ist wofür ich es halte, dann hätte man bei teilgeklonten Windows-Installationen ein Problem...

Deshalb stellt sich mir die Frage: WANN wird diese GUID generiert? Was ist mit OEM Systemen? Viele Hersteller klonen die Windows-Installation um ihre Rechner vorinstalliert ausliefern zu können. Ist es sicher dass die GUID da definitiv Unique ist?


----------



## Gast2 (26. Mrz 2009)

Moin,

ich tippe hier auf Ja ... sonst würde die Volkszählung von Microsoft nicht funktionieren

hand, mogel


----------



## tuxedo (26. Mrz 2009)

Das wäre prima.

Hab eben n kleines diagnose-Script gebastelt das mir die notwendigen Infos sammelt und zipped. Das geb ich mal meinen "OEM Problemkandidaten". Dann hab ich klarheit...


----------



## tuxedo (26. Mrz 2009)

Hmm, letzter Post in diesem Thread behauptet dass Images ein Problem darstellen:

wer-weiss-was | "MachineGUID" | aus Forum Windows 2000 & XP

Naja, im schlimmsten Fall kombiniere ich 

MachineGuid
CD-Key
Timestamp von C:\Windows
Volume-Serial der C-Platte

Das zusammen sollte ausreichend einzigartig sein.


----------



## thE_29 (26. Mrz 2009)

Wenn ich heute am Abend nicht vergesse, boote ich mal wieder Vista aufn meinem Macbook und teste ob reg.exe ohne Admin Rechte auskommt!
Dann baue ich die pur Registry eventuell um! Ich wusste halt nicht, dass der Befehl überhaupt existiert


----------



## tuxedo (26. Mrz 2009)

thE_29 hat gesagt.:


> Wenn ich heute am Abend nicht vergesse, boote ich mal wieder Vista aufn meinem Macbook und teste ob reg.exe ohne Admin Rechte auskommt!
> Dann baue ich die pur Registry eventuell um! Ich wusste halt nicht, dass der Befehl überhaupt existiert



Auch RegEdit kommt da ohne Admin-Rechte aus. Habs ja selbst getestet.

Was ich aber auf Wikipedia gelesen hab ist, dass man einzelnen Programmen wie "regedit" die Nutzungsrechte entziehen kann. Und das wird auch ab und an von Admins gemacht. Das bezieht sich aber nur auf Schreibrechte. Lesen geht, wenn ich das richtig verstanden/gelesen hab IMMER. 

- Alex


----------



## Ebenius (26. Mrz 2009)

tuxedo hat gesagt.:


> Lesen geht, wenn ich das richtig verstanden/gelesen hab IMMER.


Kann ich so nicht bestätigen. Das hängt sehr davon ab, wie paranoid die IT-Abteilung in der jeweiligen Firma ist. Man kann sich teilweise nicht mal drauf verlassen, dass regedit überhaupt auf dem System vorhanden ist.

Ebenius


----------



## thE_29 (26. Mrz 2009)

Naja, wenn ich regedit.exe in ausführen eingebe, kommt immer diese Admin Abfrage!

Bei Runtime.exec() kommt halt ne Exception, dass er das nicht darf..


----------



## tuxedo (26. Mrz 2009)

Ebenius hat gesagt.:


> Kann ich so nicht bestätigen. Das hängt sehr davon ab, wie paranoid die IT-Abteilung in der jeweiligen Firma ist. Man kann sich teilweise nicht mal drauf verlassen, dass regedit überhaupt auf dem System vorhanden ist.
> 
> Ebenius



Wer sagt dass du RegEdit brauchst? 

Und wenn Wikipedia recht behält ist alles in Butter:



			
				http://de.wikipedia.org/wiki/Windows-Registrierungsdatenbank#Sicherheit hat gesagt.:
			
		

> *Sicherheit*
> 
> Da mit der Registry auch Optionen wie das Ausblenden des Taskmanagers oder Komponenten der Systemsteuerung vorgenommen werden können, ist es nützlich, die Registry z. B. in großen Netzwerken _vor ungewollten _*Änderungen *durch normale Benutzer zu schützen. Dies kann durch die Funktion „Berechtigungen” vorgenommen werden.
> 
> ...


----------



## Ebenius (26. Mrz 2009)

tuxedo hat gesagt.:


> Wer sagt dass du RegEdit brauchst?


Dann hab ich oben was falsch gelesen, sorry. 

Ebenius


----------



## Gast2 (26. Mrz 2009)

tuxedo hat gesagt.:


> Hmm, letzter Post in diesem Thread behauptet dass Images ein Problem darstellen:


ja klar ... wenn die Maschine bereits lief wird auch die GUID im Image mit gespeichert ... ich vermute aber das bei OEM-Installationen das nicht der Fall ist und die GUID beim ersten System-Start erzeugt wird - sonst würde die Volkszählung noch weniger funktionieren 

hand, mogel


----------



## thE_29 (26. Mrz 2009)

Ich brauche aber regedit.exe um alle Einträge außer dword aus der registry zu kriegen 
Und da regt sich das UAC auf.

Die Frage ist, ob man eine Java App mit UAC starten kann..


----------



## tuxedo (26. Mrz 2009)

was ist mit "reg"? Damit kann man doch auch die registry lesen. Okay, schreiben kann sein dass man dafür dann Admin-Rechte braucht. Aber zumindest lesen geht. Der CD-Key ist auch kein dword und kann damit gelesen werden...

@mogel

Klingt einleuchtend. Den Beweis hab ich wenn meine Problemkandidaten mein Diagnose-Script ausgeführt haben. Dauert nur noch etwas bis ich alle Daten hab.

- Alex


----------



## thE_29 (26. Mrz 2009)

Wie gesagt, ich fahre heute mal Vista hoch und schau mal wie sich reg.exe verhält! Wenn das beim Lesen (da ja Befehl query) keinen Adminzugang benötigt, muss ich meine Lib wohl ändern


----------



## thE_29 (26. Mrz 2009)

Jupidu!

reg.exe query geht ohne admin Rechte 
Konnte sogar HKLocalMachine und HKClassesRoot extrahieren
Najo, dh, ich muss meine Lib Updaten


----------



## tuxedo (29. Mrz 2009)

Für alle die die Sache mit dem Zeitstempel von c:Windows auch bei sich einsetzen wollen:

Dank "Superweich" keine so gut Idee: Winterzeitdateien ändern in der Sommerzeit ihren Zeitstempel um eine Stunde. Gleiches gilt für Sommerzeitdateien in der Winterzeit.

Nachzulesen hier:

CodeProject: Beating the Daylight Savings Time bug and getting correct file modification times. Free source code and programming help

Gruß
Alex


----------

