VBA-Projektkennwort
Schnelle visuelle Sperre gegen versehentliches Öffnen. Viele kostenlose Tools können es entfernen. Nur bei ehrlichen Anwendern nützlich.
VBA-Codeschutz
Vier Schichten rund um Ihren VBA-Code.
Stapeln Sie, was Ihr Bedrohungsmodell erfordert.
VBA-Schutz ist nicht binär. XLS Padlock liefert vier unabhängige Schichten: Projektkennwort, Verbergen und Sperren, Bytecode-Kompilierung und Sperre des VBE-Zugriffs. Stapeln Sie eine oder stapeln Sie alle vier. Die richtige Wahl hängt davon ab, an wen Sie ausliefern und wie aggressiv Sie ein Reverse Engineering erwarten.
Vom lesbaren Quellcode zum kompilierten Bytecode.
Schicht 3 ist am schwersten zu überwinden. Sie verschieben die von Ihnen ausgewählten Prozeduren in den VBA-Editor von XLS Padlock, der sie zu Bytecode kompiliert und in der Anwendung speichert. Die ursprüngliche Logik verlässt die Arbeitsmappe: Wo das Makro früher ausgeführt wurde, bleibt nur ein Aufruf der Hilfsfunktion CallXLSPadlockVBA.
Jede Schicht schlägt eine andere Klasse von Angriffen.
VBA verbergen und sperren
Der XLS Padlock Manager sperrt das VBA-Projekt, sodass es nicht angezeigt, geöffnet oder geändert werden kann. Wer es öffnet, sieht die Meldung Project is unviewable, und da die Arbeitsmappe innerhalb der EXE verschlüsselt ist, können Tools zur Kennwortentfernung den Quellcode nicht erreichen.
VBA Compiler
Sie verschieben die kritischen Teile Ihrer Makros in den VBA-Editor von XLS Padlock und kompilieren sie zu Bytecode. Anschließend ersetzen Sie den ursprünglichen Code durch einen Aufruf der Hilfsfunktion CallXLSPadlockVBA, sodass die Quelllogik die Arbeitsmappe verlässt und nur innerhalb der sicheren Anwendung ausgeführt wird.
VBE-Zugriff verweigert
Die kompilierte Anwendung kann das Öffnen des Visual Basic Editor (Alt+F11) untersagen, sodass Endanwender die VBE nicht öffnen können, um das Projekt zu untersuchen.
Drei Bedrohungsmodelle, drei Schutztiefen.
Den Quellcode nur vor ehrlichen Anwendern verbergen
Verwenden Sie das VBA-Projektkennwort zusammen mit dem Verbergen und Sperren. Schnellste Einrichtung, kein Refactoring des Codes. Ausreichend, wenn Ihre Kunden kein aktives Reverse Engineering betreiben.
Das geistige Eigentum kompilieren, die Verdrahtung behalten
Verschieben Sie Ihre sensiblen Prozeduren in den VBA-Editor von XLS Padlock und kompilieren Sie sie, während Sie Ereignishandler und UserForm-Code in einfachem VBA belassen. Bestes Gleichgewicht zwischen Sicherheit und Entwicklerkomfort.
Aggressiv kompilieren, bei Bedarf umstrukturieren
Verschieben Sie so viel Geschäftslogik wie möglich in den VBA-Editor und kompilieren Sie sie: mathematische Bibliotheken, Berechnungs-Engines, Exportfunktionen, alles, was nicht von Ereignissen der Excel-Oberfläche abhängt. Rechnen Sie damit, einen Teil des Codes anzupassen (explizites Application-Objekt, nur unterstützte Objekte), aber Sie maximieren die geschützte Oberfläche.
Sperren Sie das Projekt, kompilieren Sie das geistige Eigentum, verweigern Sie den Editor.
Für die meisten kommerziellen Arbeitsmappen ist die richtige Grundlage die Kombination der Schichten 2, 3 und 4: Verbergen Sie das Projekt vor der Excel-Oberfläche, verschieben Sie sensiblen Code zum Kompilieren in den VBA-Editor von XLS Padlock, verweigern Sie den VBE-Zugriff zur Laufzeit. Lassen Sie Schicht 1 (das Projektkennwort) weg, da sie nichts beiträgt, sobald die EXE ohnehin das Öffnen des Editors verweigert.