Warum ist es notwendig, hier mit Signaturen zu
arbeiten? Die Antwort liefert das Henne-Ei-Phänomen. Wenn die exe die dll prüfen soll, dann
müsste die exe die Prüfsumme der dll kennen.
Also trägt man diese in der exe ein. Wenn die
dll aber auch die exe prüfen soll, dann muss die
dll die Prüfsumme der exe kennen. Dazu müsste
man diese eintragen, was aber die dll verändert und damit die in der exe eingebundene
Prüfsumme ungültig macht.
Verwendet man Signaturen, wird in allen
Modulen (exe und alle dlls) lediglich der
öffentliche Schlüssel versteckt eingebettet.
Mit dem privaten Schlüssel wird jedes Modul
unterschrieben und die Signatur an das Modul
selber angehängt. Damit kann jeder jeden
prüfen. Und einzelne Teile können später
unabhängig von den anderen Teilen aktualisiert werden.
ExProtector – Embedded Devices
Der AxProtector erzeugt eine geschützte
Anwendung oder Bibliothek, welche sich
selber entschlüsselt. Beim ExProtector ist
dies anders: Der ExProtector schützt Anwendungen, Bibliotheken oder das komplette
Betriebssystemimage auf einem Embedded
Device. Zum Laden und Ausführen der
geschützten Teile wird zusätzlich ein Modul,
die ExEngine, in den aufrufenden Teil integriert. Ist das komplette Betriebssystemimage
(z.B. ein VIP unter VxWorks) verschlüsselt, wird
die ExEngine in den Bootloader integriert. Sind
Anwendungen und Bibliotheken (z.B. RTPs
und DKMs unter VxWorks) verschlüsselt, wird
die ExEngine in das Betriebssystem integriert.
Header
Code Section
Data Section
Header
Definition
von Lizenzen und
Modulen
Encrypted
Code Section
AxProtector
Encrypted
Data Section
Encrypted
Resource Section
Resource Section
AxEngine
(Security Engine)
Geschützte .exe/.dll
■■ Ein Hacker erzeugt eine veränderte Kopie
einer Ihrer dlls. Zum Bespiel ersetzt er die
dll, welche den Kopierschutz überprüft
durch eine dll, die immer „Ok“ antwortet.
Die Integritätsprüfung des AxProtectors
verhindert, dass diese dl ]\