Checksum einer Jar-File

[Bizarrus]

Huhu.

Ist es möglich die "eigene MD-5 Checksum" einer Jar-Datei, die gerade ausgefürht wird zu ermitteln?

Sinn hierfür ist eine überprüfung ob an einem Socket-Chat der Client verändert wurde.
Ich würde gerne eine überprüfung einbauen die folgendermaßen ablaufen würde:

1. Chatclient wird gestartet und initalisiert
2. Chatclient ermittelt die MD5-Checksum von sich "selber" (Jar-File)
3. Chatclient sendet die Checksum zum Chatserver
4. Chatserver überprüft, ob die angekommene Checksum mit der in einer Variable gespeicherte Checksum übereinstimmt
5. Chatserver erlaubt die weitere Verbindung oder lehnt diese ab

Ist derartiges möglich?

Edit:
Naja, es muss ja auch nicht unbedingt die MD5-Checksum sein, überlege ich gerade.
Die Größe der Jar wäre ja auch eig ein anfang.

 

[Simon_Flagg]

vllt. ist in der Klasse JarFile etwas.... --> Manifest ja/nein, alles richtig im manifest --> hashCode?
in der Klasse ZipFile gäbe es die methode size() --> Anzahl der Einträge

vllt. in File: compareTo, hashCode?

lg

 

[madboy]

java - How to get the path of a running jar file? - Stack Overflow und http://www.java-forum.org/java-basics-anfaenger-themen/114500-messagedigest.html#post736437 sollten dir helfen

 

[mvitz]

Die Frage ist aber, wenn man den Client ändert, wieso sollte man dann diese Überprüfung nicht auch einfach ändern und die vormals gültigen Werte zurückschicken?

 

[kay73]

Die Frage ist aber, wenn man den Client ändert, wieso sollte man dann diese Überprüfung nicht auch einfach ändern und die vormals gültigen Werte zurückschicken?

Volle Zustimmung.

In letzter Konsequent kannst Du nicht sicherstellen, dass der Traffic der an Deinem Chatserver ankommt, von einem "integren" Stück Code erzeugt wurde. Ein Angreifer wird das Applet/JAR dekompilieren, analysieren und ein eigenes Script mit Angriffscode schreiben. Konzentriere Dich lieber vorrangig darauf, den Server wasserdicht zu machen.

Du könntest natürlich was ganz Verrücktes machen und vom Server unvorhersehbar Code zum Prüfen und Rückmelden nachträglich in den Client schicken. Der könnte z. B. bestimmte digitale Signaturen des Client-JARs prüfen... :smoke:

 

[Dit_]

Die Frage ist aber, wenn man den Client ändert, wieso sollte man dann diese Überprüfung nicht auch einfach ändern und die vormals gültigen Werte zurückschicken?

nicht aber, wenn ich definiere, welche werte gültig sind und welche nicht, muss nicht MD5 sein, man kann auch eigene ID-Verfahren entwickeln. Wenn man sehr viele Klassen hat, kann man auch paar Sachen verstecken, paar andere mit Absicht, zur Ablenkung zur Schau stellen und mit Java Web Start kann man das noch zusätzlich zu jeder Zeit manipulieren.



Man kann schon so einiges machen, schöne spaßige Aufgabe. 🙂