Ist Codesignierung Geldverschwendung?

Hallo Leute,

ich habe da ein Verständnisproblem mit Codesignierung. Der Vorteil von Codesignierung unter Windows ist ja das der User sieht das das Programm von einem bestimmten Herausgeber ist.

Andererseits kann man damit auch die Integrität eines Programmes oder eines Programmmodules überprüfen. Dieses Szenario finde ich ganz interessant insbesondere, wenn man Code-Injektion via Proxy DLL Dateien verhindern will.

Der einfachste Schutz wäre es die Integrität der Signierung zu überprüfen. Nur was ist wenn der Cracker jetzt seine Proxy DLL selber signiert? Unter der Bedingung, dass das Zertifikat gültig ist würde mein Schutz so ausgehebelt werden. Mein nächster Gedanke ist: Das ich das Zertifikat weiter untersuche und überprüfen ob das CA-Zertifikat einen bestimmten Hash hat.

Also habe ich jetzt ein Programm, das überprüft ob ein Modul via Codesignierung gültig signiert ist und ob der Herausgeber einen bestimmten Hash verfügt. Nur wenn jetzt der Cracker noch meinen Hash verändert (z.B. mit einem Hex-Editor) und mein Programm neu signiert bin ich wieder am Anfang: Ich weiß noch immer nicht ob mein Programm manipuliert wurde.

Habe ich einen großen Denkfehler oder ist Codesignierung wirklich Geldverschwendung?

Hallo

Wenn man mit einer signierten Assembly arbeitet, verhindert diese ja genau, dass andere DLLs geladen werden, der PublicKeyToken wird imo aus einem Keyfile und einer Art Hash der Assembly generiert. Eine fremde Assembly hat also sicher einen anderen Hash und bestimmt nicht dasselbe Keyfile mit dem es signiert wurde. Das Hauptprogramm erwartet ja nicht irgendeine Signierung sondern genau DEINE Signierung.

[edit]
Ob es grundsätzlich Geldverschwendung ist, muss von Fall zu Fall beurteilt werden. Sicherheit ist natürlich ein wichtiger Punkt. Bei privaten oder internen Anwendungen sehe ich selten Bedarf.

Gruss

Hallo edsplash,

der PublicKeyToken wird imo aus einem Keyfile und einer Art Hash der Assembly generiert.

Der PublicKeyToken hängt nur vom öffentlichen Schlüssel des Keys zur Signierung ab.

Hallo C# Fritze,

zu berücksichtigen ist auch dass durch Signierung erst ein "installieren" in den GAC möglich ist und so auch mehrere Versionen "side by side" existieren können.
Aber das ist ein anderer Punkt auf den du ja nicht aus bist.

mfG Gü

Hallo gfoidl

Ja, natürlich ^^ Sagt ja der Name auch aus, jedoch meinte ich, dass über diesen eine signierte Assembly "identifiziert" wird. Wodurch es wohl praktisch unmöglich ist eine Assembly zu fälschen.

Gruss

folgendes szenario ist in .Net ohne weiteres umzusetzten:

1. Signierung der kompletten anwendung entfernen (6 byte per Hexeditor je assembly ändern)
2. komplett decompilieren
3. alles neu signieren

"Mein nächster Gedanke ist: Das ich das Zertifikat weiter untersuche und überprüfen ob das CA-Zertifikat einen bestimmten Hash hat."
-->> 3.a überprüfung ausbauen

4. neu compilieren
5. fertig

Du kannst natürlich auch mit einem selbsterstellten Zertifilat signieren. Das kostet dich nichts, aber ein paar Vorteile kannst du auch so nutzen.

Hallo C# Fritze,

Nur was ist wenn der Cracker jetzt seine Proxy DLL selber signiert?

dann ist sie zwar unterschieben, aber die Unterschrift ist eine andere. Es reicht also in der Tat nicht, dass du einfach allem vertraust, was unterschrieben ist, sondern wenn ein besserer Schutz erreicht werden soll, dann musst du prüfen, ob du dem konkreten "Unterschreiber" traust.

Du würdest ja dem Betrüger an deiner Wohnungstür auch nicht nur deshalb vertrauen, weil er dir seine Unterschrift darauf gibt, dass er dich nicht bescheißen will.

Natürlich darfst du nicht blind allen Angaben vertrauen. Der Cracker kann sich das Zertifikat ja selbst ausgestellt haben. Aber da kommt eben die CA ins Spiel. Die ist ja dafür da zu bestätigen, ob jemand, der vorgibt jemand bestimmtes zu sein, auch wirklich dieser Jemand ist.

Bleibt letztlich nur die Gefahr, dass Zertifikate gestohlen werden. Also dass es einem Cracker irgendwie gelingt, an den privaten/vertraulichen Teil des Zertifikat eines bekannten Herstellers zu kommen, und damit dann seine eigene DLL unterschreibt. Das wäre der Worst Case.

Allerdings sollte das dann dazu führen, dass das konkrete Zertifikat von der CA für ungültig erklärt wird. Zwar mit heftigen Auswirkungen auf die im Umlauf befindliche echte Software des Herstellers, aber zumindest ist der Schutz vor falscher Software wiederhergestellt.

herbivore

folgendes szenario ist in .Net ohne weiteres umzusetzten:

1. Signierung der kompletten anwendung entfernen (6 byte per Hexeditor je assembly ändern)

Könntest Du das bitte etwas näher erläutern?

Ich arbeite gerade für meine eigene Applikation an einem Lizenzierungsmechanismus via XML-Datei und war mir ziemlich sicher, dass meine Implementierung relativ "safe" ist.

Ich würde jetzt gerne versuchen, mit der von Dir vorgeschlagenen Methode meine eigene Applikation "zu hacken"....

Ich vermute es gibt eine Art Header der EXE/DLL in dem spezifiziert ist, dass die Assembly signiert ist - und diesen Header kann man (wenn ich Dein Posting richtig interpretiere) einfach modifizieren, ohne dass es dem .NET Laufzeitsystem auffällt ?!?!?!?!?!

Schonmal vielen Dank!

Bye,
Knick

Hi m.knigge,

vielleicht hilft CodeProject: Removing Strong-Signing from assemblies at file level (byte patching).

beste Grüße
zommi

Hallo m.knigge,

so wie ich das verstehe, ist damit das PE-Format gemeint. Hier findest du einen guten Einstieg.

zero_x

@zero_x
@zommi

Schönen Dank Euch beiden! Ich werde das mal die Tage ausprobieren und gucken, ob sich der Assembly-Loader von .NET und Mono in der Tat so einfach austricksen lassen...

Bye,
Michael

Ich vermute es gibt eine Art Header der EXE/DLL in dem spezifiziert ist, dass die Assembly signiert ist - und diesen Header kann man (wenn ich Dein Posting richtig interpretiere) einfach modifizieren, ohne dass es dem .NET Laufzeitsystem auffällt ?!?!?!?!?!

mit dem ändern des Headers ist die Datei eben nichtmehr signiert.