Kann man das knacken?

Hey ho,

ich weiß meine Themenüberschrift ist ungünstig gewählt, aber mir ist keine bessere für mein Problem eingefallen.

Es geht um eine relativ komplexe Verschlüsselung:

- User speichert die Seriennummer seiner CPU online
- Programm liest Seriennummer aus und sendet eine Anfrage
- Website erkennt, dass die Seriennummer korrekt ist und gibt einen Wert
zurück, der das Programm freischaltet.

Ich kenne die Seriennummer, und ich habe schon ein paar Pakete abgefangen.

Beispiele:

GET auth.php?A=2A8561A5B9078CA9&B=44025C0EDC28FA369453&C=8EFF28107A0BF5B1F34F&D=75D55F16DBF50237C21EA4632D7F46DBE370F5FF509C9A2736F44551A0EC1828

sendet das Programm und es erhält:

9b020a3badeb3298e5286a97db2f82eb36

oder:
auth.php?A=7E7A5C63FF493CB8&B=4A7A4C90E4A26E529ACB&C=507F189282077159BBCF&D=79AD4F98E3F57653CCFEA4E335FBC2CFEB50F5FF50960E23386C4551A0E63040

und:
5b04d77b81e74496c52a6e97f34394eb14

Nun zu meiner eigentlichen Fragestellung:

Wie glaubt ihr / denkt ihr / wisst ihr, ist diese Verschlüsselung aufgebaut und was könnte man versuchen?

Ich bin blutiger Anfänger und weiß, dass ich die Verschlüsselung nich knacken werde, aber ich möchte mich bilden und verstehen. Das Beispiel habe ich gewählt, weil es eine Problemstellung ist mit der ich letztens konfrontiert und es mein Interesse geweckt hatte.

Paul.

Ich rate mal ins Blaue: es geht um eine mit "HWID" gesicherte Software, richtig?
I.R wird nicht (nur) die CPUID genommen, sondern auch andere Werte: beliebt ist Grafikkartenname, FestplattenID (oder eher VolumeID), Macadresse der Netzwerkkarte.

Ohne die Software zu debuggen wird es in der Praxis kaum möglich sein, mit vertretbarem Aufwand die benutzten Algorithmen herauszukriegen (gut, Ausnahmen gibt es immer )

Üblich sind Konstrukte mit MD5/SHA1 Hashing der ausgelesenen Hardwarewerte (die get-Parameter der von Dir geposteten URL sehen auch danach aus).
"Dummerweise" kann hier der Programmierer seiner Fantasie den freien Lauf lassen - es fängt damit an, was eigentlich gehascht wird (hardwareID als String, als Bytearray, in verschiedener Reihenfolge aneinander gehängt oder einzeln) geht über Spielereien mit dem Hashalgorithmus (sowas wie md5(sha1("hardwareid_als_string"))) bis hin zu komplett eigenen Hashverfahren.

Das heißt - hier kann man lange herumraten, welche Hardwarekomponenten nun genommen werden, wie diese "gehascht" und welche Hashteile nun geschickt werden. Oder man debuggt die Software.

Bei dem Server verläuft es ähnlich - ohne Quelltexteinsicht wird es sehr schwer herauszubekommen, was der Server mit den Eingaben macht (z.B nimmt er jeden 2 Buchstaben der übergebenen ID und bildet daraus einen String den er dann hasht - und ähnliche Spielchen).

In aller Regel wird solche Software auf 2 Wegen angegriffen:
1. ohne eine gültige Kommunikationsaufzeichnung zwischen Server/Programm debuggt man das Programm bis zur Prüfung und versucht zu rekonstruieren, was bei einer positiven Antwort passieren würde. Viele Programmierer handhaben es genauso wie bei "Offlineabfragen" - irgenwo steht quasi ein
"if Antwort == xyz then registered else: 'Keine Lizenz!!!'"
die man genauso umgehen kann, wie bei "Offline" Schutz

Hier wird es aber haarig, wenn mit dem Rückgabewert noch irgendwas anderes verfahren wird (z.B enthält dieser wichtige Initilisierungswerte oder gar Key zum entschlüsseln bestimmter Codeteile). Man braucht eine gültige Kommunikationsaufzeichnung (im Übrigen braucht man auch bei so einger "Offlinesoftware" eine gültige Lizenz - die "Onlineauthentification" wird imho so ziemlich überbewertet) um weiterzukommen.

2. Man hat eine gültige Aufzeichnung. Nun kann man hier in etwa 2 Wege gehen:
2.1. Man lässt die Serverabrage immer die (vorher mitprotokollierte) richtige Antwort zurückgeben. Dazu muss man allerdings i.R die Hardwareabfrage auch so umbiegen, dass sie auf jedem PC den gleichen Wert "ermittelt", wie auf dem PC, auf dem die Kommunikation aufgezeichnet wurde.
Der Aufwand dazu ist sehr unterschiedlich, da es auf die eingesetzten Netzwerkbibliotheken und Sprache ankommt. Eine solche Lösung ist aber i.R schöner, als die 2.2

2.2. Man lässt die Hardwareabfrage wiederum immer den gleichen Wert ermitteln (wie bei 2.1), emuliert allerdings den Server, z.B in dem man die Hosts dateien auf den lokalen Rechner umbiegt und lokal einen Server startet. Das ist zwar nicht so schön, ist aber in einigen Fällen deutlich einfacher, als den kompletten Netwerkzugriff wie bei 2.1 umzuschreiben.

Edit: gut. Das von GrafZahl beschriebene "Challenge-Response" Verfahren wäre nur noch mit recht hohem Debugaufwand angreifbar - allerdings wird es in der Praxis nicht soo oft eingesetzt (zumindest für Validierung "normaler" Software), weil es auch kompliziert umzusetzen/fehleranfällig sein dürfte.

scheint ein challange response verfahren zu sein ... was genau da abläuft ist ohne eingehende untersuchung kaum zu sagen ...

grundsätzlich sind solche verfahren mit digitalen singaturen vergleichbar ...

man erzeugt einen wert (zufall / datum+uhrzeit) und sendet diesen mit anderen parametern an eine authentifizierungsstelle ... diese stelle besitzt einen signaturschlüssel, mit dem die anfrage mit zugehöriger antwort (wie z.b. "login erlaubt" / "login verweigert") digital signiert ... zur erzeugung der signatur ist der geheime signaturschlüssel erforderlich, der nur der authentifizierungsstelle bekannt ist ... zum prüfen der signatur gibt es einen öffentlichen schlüssel, der quasi jedem bekannt sein darf, und in der regel dem programm beiliegt ... damit kann die echtheit der signatur überprüft werden ... zudem kann man auch davon ausgehen, dass die kommunikation allgemein nicht im klartext abläuft, sondern chiffrate ausgetauscht werden... so will man üblicherweise verhindern, dass ein mitgesendeter dechiffrierschlüssel für bestimmte teile der software einfach aus der kommunikation ausgelesen werden kann ...



angreifbar wreden solche verfahren dann, wenn man als angreifer in der lage ist den öffentlichen signaturschlüssel des programms auszutauschen, und ggf. mitgesendete dechiffrierschlüssel abfangen kann (man könnte dem programm zusehen wie es die kommunikation abwickelt, und die schlüssel für die antwort aus dem speicher auslesen, oder den dechiffrierschlüssel vom programm selbst entschlüsseln lassen ... das kommt auf den einzelfall an)

wenn du den signaturschlüssel (und den öffentlichen schlüssel des servers für den verschlüsselten datenaustausch) in dem programm auf deinem rechner austauschen kannst, und ggf den dechiffrierschlüssel hast, kannst du die antwort des servers auf die auth anfrage für das programm glaubhaft simulieren, und müsstest nur noch die anfrage abfangen ...


der weg bis dahin dürfte allerdings steinig sein ...

//da war CDW wohl schneller

Ich will mich gleich nochmal intensiver mit euren Antworten auseinander setzen..

nur eine Frage: die besagte Seriennummer (oder HWID) hat sich bei mir letztens verändert, als ich smart overclocking aktiviert habe (so bin ich darauf gekommen, dass es sich um eine CPU-Nummer handeln muss.)
Mit deaktiviertem Overclocking -> die alte Kombination.

kann man eine HWID auch beeinflussen bzw. verändern?

ANGEFÜGT:
=========

Also ich habe gerade mal etwas rumgespielt:
Wenn ich den Parameter C der im php-link auftaucht verändere, erhalte ich vom server immer die selbe antwort:

9bb40c3bc5e13192220a4b7700f09de17278c3046c8ee13d79b50a438acb324f

Sie sieht etwas länger aus.. ich spinn mir jetzt mal einfach zusammen, dass das daran liegt, dass false länger ist als true.

Ich gehe also mal davon aus, dass kein Key für Codeteile mitgesandt wird, sondern nur ein "Kannst du vergessen!" in verschlüsselter Form.

verändere ich nämlich die anderen Parameter bekomme ich ein "Error" in Klartext.

Aber wenn ich alles richtig verstanden habe, bring mich das unwesentlich weiter. Ich muss wohl am Programm ansetzen, womit ich dieses Unterforum verlasse. Wenn ich fragen haben sollte meld ich mich an anderer Stelle.

Vielen Dank für die netten Antworten!

Paul.