VBA-Code nicht knacken

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

Hallo mumpel,
ich beschäftige mich mit diesem Thema seit Office 4.2 (1994). Leider legt M$ auf Office-Kennwörter keinen besonderen Sicherheitswert. Die letzte strategische Entscheidung erfolgte mit Office 2000 SP2. Damals wurde Outlook erwähnt, daß SP2 erforderlich sei (MyLove-Virus). Tatsächlich wurde aber auch beim Vba-Kennwort eine neue Verschlüsselungs-Routine eingebaut. Selbst mit Office 2007 hat sich hier nichts geändert.
Inzwischen dürfte wohl jeder, der es wissen will, den Tipp von 'Schmitti' kennen.
Der Hintergrund dieser M$-Änderung ist noch viel banaler. Egal wie lang das eingetippte Vba-Kennwort ist, durch die implizite Shift-Verschiebung ist in der xls-Datei die Verschlüsselungslänge immer zwischen 72 und 78 Byte (nur gerade Werte!) lang. Sollte noch der erwähnte Trick dazukommen, dann sind nochmals 16 Byte (&H0) dazuzurechnen.
In VB6 gibt es den Datentyp Byte-Array. Damit kann man Dateien Byte für Byte einlesen (1 Befehlszeile).
Ich suche dann die 1. Stellen des Vba-Kennwortbeginns, ermittle die verschlüsselte Kennwortlänge und tausche in einem 2. Byte-Array das unbekannte Kennwort gegen ein mir bekanntes verschlüsseltes Kennwort aus. Zum Schluß erstelle ich aus dem 2. Byte-Array eine neue Datei.
Damit ist für mich die Kennwortgeschichte gegessen.
Sicher werden sich jetzt Einige (oder doch Viele) fragen, warum hier aus dem Nähkästchen plaudert wird. Mich 'kotzt' es einfach an, daß M$ auf ihren Internetseiten Office2007 preist, als ob hier das NonPlusUltra von Office entstanden ist. Tatsächlich ist die Sicherheit total auf den Hund gekommen (und eben nicht nur in Excel). Mußte man früher noch eine kleine Vba-Routine laufen lassen, um den Blattschutz auszuhebeln, kann man jetzt in den xml-Dateien der Tabellen die verschlüsselte Kennwortzeile einfach löschen, alles wieder zu einer Zip-Datei (xlsm) umwandeln und Mr. Brot von KiKa hat mit seinem Spruch: "Alles wird gut" wiedermal genau ins Schwarze getroffen.
Ich bin mal gespannt, wenn M$ von Firmen verklagt wird, weil hochbrisante Office-Daten durch einfache Taschenspielertricks an die Öffentlichkeit gelangen.
Naja, habe eben mal ein bischen Luft rauslassen müssen; aber wenn heute Abend im Fußball alles seinen Gang geht (3:1 für Irland), dann ist die Welt doch schon wieder ein bischen besser geworden.
Gruß von Luschi
aus klein-Paris

Hallo D.,
ich habe das kürzlich auch mit Verwunderung in einer der von Dir genannten Zeitschriften gelesen....
Der Trick mit dem HEX-Editor ist Insidern zwar schon lange bekannt, aber ich finde es dennoch nicht OK, diese Methode so zu veröffentlichen....
Den Code in einer XLA/XLS/XLT kann man nicht "effektiv" schützen, es steckt (Excel 2000 - Excel2003) jeweils der gleiche Algorithmus dahinter, erst ab Excel 2007 hat sich das gesamte Dateiformat (und damit auch der implementierte VBA-Schutz) ja grundlegend verändert ! Ich vermute mal, Du meinst mit "Trick ausschalten" etwas anderes : z.B. eine per Visual Basic (nicht VBA !) erstellt spezielle Excel-Library (*.XLL) bzw. "normale" Library (*.DLL). Diese kannst Du mit Excel selbst jedoch NICHT erstellen !
Ein Beispiel für eine XLL findest Du auf Deinem PC (Bestandteil des AddIns "Analyse Funktionen") :
ANALYS32.XLL im Ordner C:\Program Files\Microsoft Office\OFFICE11\Makro\Analyse
Und ein Beispiel für eine DLL findes Du im Verzeichnis des SOLVER-AddIns :
SOLVER32.DLL im Ordner C:\Program Files\Microsoft Office\OFFICE11\Makro\SOLVER
(Die Verzeichnisse beziehen sich auf Excel 2003 unter Windows XP englisch !)
Beide Librarys sind nicht (bzw. nicht so trivial) zu "knacken" - allerdings benötigt man zu deren Erstellung z.B. Visual Basic (oder auch Visual C++) !
Gruß, NoNet

Beliebteste Forumthreads (12 Monate)

11 Beiträge zum Forumthread Beiträge zu diesem Forumthread

VBA Beispiele zu verwandten Themen

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

11
Beiträge zum Forumthread

Beiträge zu diesem Forumthread