Ich weiss es jetzt ziemlich genau: Ziemlich genau 30 €, dazu braucht man zwei bis drei Tage Zeit und eine handvoll Rechner.

Einer meiner "Schwager from Hell" hatte nämlich dummerweise irgendeine Tantiemenabrechnung, die er irgendwann mal mit dem Beamer vor versammelter Mannschaft an die Wand geworfen hatte, mit einem Passwort geschützt und ebendieses vergessen ("Tja siehste, das Passwort war so geheim, daß ich es vergessen habe" würde jetzt der DEI sagen). Dumm, wenn man aufgrund dieser Angaben dann irgendwann diesen Monat noch irgendwelche Zahlungen leisten muß. Nachdem alle Versuche, die Datei wieder lesbar zu machen, gescheitert waren, mußte ein Passwort-Cracker her. Seit Office 97 werden die Exceldateien mit einem RC40 Streamcipher verschlüsselt, also hilft da nur eine Brute-Force Attacke (die einschlägigen Tools kennen offenbar keine Wörterbuchattacken). Die Wahl fiel auf ein Tool von irgendeinem russischen Entwickler das man für etwa 30 € kaufen konnte. Es teilt den Keyspace (von 2^40 Schlüsseln) in 16384 äquidistante Teilbereiche auf und man kann durch Angabe einer Start- und Endzahl (zwischen 0 und 16383) festlegen, welchen Bereich des Keyspace die jeweilige Instanz untersuchen soll.

Häh, "RC40 Streamcipher"? "Brute-Force Attacke"? "Wörterbuchattacke"? "Keyspace"?

Also jetzt ganz einfach für die kryptographisch Minderbemittelten unter uns: Wenn eine solche Datei verschlüsselt wird, dann wird aus dem Eingabestring (dem "Passwort") schlicht und einfach eine Zahl erzeugt. Im Fall von Excel ist das eine Zahl die einen Wert zwischen 0 und 2^40-1 (der "Keyspace") hat, also eine Dualzahl mit 40 Stellen. Die Verschlüsselung muß man sich nun mathematisch vorstellen als Funktion, die als Ergebnis den Ciphertext hat (also die verschlüsselte Datei, die keiner außer demjenigen anschauen können soll, der das Passwort weiß) und zwei Eingabeparameter, nämlich besagte Zahl, die aus dem Passwort gebildet wurde (der "Key") und dem Klartext (der unverschlüsselten Exceldatei).

Wie klappt nun die Entschlüsselung? Ganz einfach: Der Benutzer gibt in Excel das Passwort ein, von dem er glaubt, es sei das richtige. Mit demselben Algorithmus wie bei der Verschlüsselung wird nun wieder eine 40-stellige Dualzahl ermittelt und der Verschlüsselungsalgorithmus in umgekehrter Richtung durchlaufen: Das Ergebnis ist also eine Funktion, die als Rückgabewert den (erwarteten) Klartext ergibt und als Eingabeparameter besagte Zahl sowie den Ciphertext (die verschlüsselte Exceldatei) hat. Diese Entschlüsselung erzeugt dann ein Ergebnis, das entweder totaler Kauderwelsch ist (wenn der Key und damit das Passwort nicht dasselbe war wie bei der Verschlüselung) oder eben etwas Vernünftiges, wenn der Key und damit das Passwort gestimmt haben.

Wegen dieser Eigenschaft, daß derselbe Key zum Ver- und Entschlüsseln verwendet wird, werden derartige Algorithmen übrigens "Symmetrische Verschlüsselungsverfahren" genannt. Beispiele für solche Verfahren sind etwa Blowfish, Twofish, DES, Rijndael/AES, IDEA. Im Gegensatz dazu gibt es auch asymmetrische Verfahren, wo also zwei unterschiedliche Schlüssel zum Ver- und Entschlüsseln verwendet werden. Asymmetrische Verfahren finden aber häufig Anwendung in Public-Private-Key-Infrastrukturen "but that's a whole different kettle of fish" (denn für asymmetrische Verfahren ist meist noch wichtig, daß der eine Key vom anderen nicht trivial abgeleitet werden kann).

Und wie klappt nun das Knacken von solch einem Excelfile? Auch wieder ganz einfach: Ein Programm erzeugt der Reihe nach alle Zahlen zwischen 0 und 2^40-1 (also dem "Keyspace"). Diese füttert es dann dem Entschlüsselungsalgorithmus ein, zusammen mit dem Ciphertext. Dann schaut es jedesmal das Ergebnis an und wenn das Ergebnis nicht irgendein Kauderwelsch ist sondern ausschaut wie ein Excelfile, dann war das mit an Sicherheit grenzender Wahrscheinlichkeit der richtige Schlüssel. Man hat dann zwar das Passwort nicht, aber immerhin die Datei wieder lesbar gemacht. Wenn stattdessen ein Kauderwelsch rauskommt, wird das Ganze mit der nächsten Zahl probiert, usw...

Hört sich easy an, aber genau dieses Testen des kompletten Keyspace ist das Problem, denn es erfordert Rechenpower, die sich bis vor wenigen Jahren nur die NASA, Exxon, die NSA und die Mafia leisten konnte. Heute kann es aber jeder Depp, eingeschlossen meiner bescheidenen Wenigkeit. Also: Alle verfügbaren Rechner zusammengesammelt und jeden auf einen Bereich des Keyspace losgelassen. Beteiligt waren dabei SULU, SAAVIK und PICARD bei mir daheim und die alte ES-ES128, das SCHMALZFLEISCH und NEPTUNE in Mission Control, wo jetzt in der ersten Januarwoche eh' keiner arbeitet. Wohl dem, der auf seinem Rechner zwei Kerne knacken lassen kann. Alle diese Rechner waren von letzten Sonntagabend bis Mittwoch früh mit 100% CPU-Last damit beschäftigt, diese Exceldatei zu knacken. Nach etwa zweieinhalb Tagen, in der Nacht auf den Mittwoch, hat das SCHMALZFLEISCH den Key dann gefunden.

Jetzt könnten dem kryptographisch Unbedarften natürlich ein paar Fragen gekommen sein:

• "Ja, ist das denn nun schlecht verschlüsselt, wenn man das in zwei Tagen mit Commodity-Hardware knacken kann?"
• Wieso ist denn überhaupt das Verschlüsselungsverfahren bekannt, sollte man da nicht diesen Algorithmus einfach geheimhalten?

Die Antworten lauten:

• Kann man so nicht fragen. Vor 10 Jahren wäre das Geheimnis in der Excel-Datei eines gewesen, das eine ganze Weile nicht hätte geknackt werden können. Daß man ein Geheimnis nur durch Brute-Force herausbekommen kann, zeichnet den Algorithmus aus. Nebenbei bemerkt: Ein Verschlüsselungsalgorithmus, auf den diese Eigenschaft nicht zutrifft, hat eh keinen Bestand auf dem Markt.
• Ein Verschlüsselungsverfahren, dessen Algorithmus nicht bekannt ist, wird im Allgemeinen belächelt. Die Zunft der Kryptanalysten macht derartigen Verfahren durch Reverse-Engineering den Garaus. Die einzigen Verfahren, die den Test der Zeitläufte bestehen und bestanden haben, sind diejenigen, die von Anfang an offengelegt wurden und von den Kryptanalysten auseinandergenommen wurden. Nur wenn sich dabei herausstellt, dass ein derartiger Algorithmus nur durch Brute-Force zu knacken ist, ist er sicher. Denn dann kann man an der Schraube mit der Schlüssellänge drehen und den Aufwand für den Angreifer exorbitant erhöhen. Deswegen ist grundsätzlich Mißtrauen angesagt, wenn jemand von einem Verschlüsselungsalgorithmus spricht, der besser ist als alles andere, ihn aber nicht offenlegen will. Und im übrigen: Die Anzahl Personen auf diesem Planeten, die brauchbare symmetrische Verschlüsselungsalgorithmen entwerfen können, ist mit an Sicherheit grenzender Wahrscheinlichkeit kleiner als 100.

Tadaaaa, bei mir war heute schon der Weihnachtsmann, mein höchsteigenes VS2005 ist da, zusammen mit einer Systembuilder-Version von XP x64 Edition:

Das hier ist mein treuer, braver Depp-uty beim Erklären eines Rhythmus' für Kopfschüttlermusik. Kein Wunder swingt das nicht. Und hier haben wir SBryant nachdem ich ihn die Wunder von weak external linking nähergebracht habe. Keine Ahnung was "U rawk" bedeutet. Und schlußendlich wissen wir jetzt, dass VRB auch mal "Nein" sagen kann.

Heute war es sehr anstrengend auf Arbeit und deswegen hat Mission Control sich und seine stetig wachsende Anzahl an Sympathisanten mit einer kleinen spontanen Glühwein-After-Work-Party belohnt. Und hier sind die Bilder aus dem festlich-vorweihnachtlich geschmückten Mission Control:

Hier sieht man sehr schön wie weihnachtlich-stimmungsvoll Mission Control derzeit dekoriert ist:

Der Herr mit Bart vor der Säule im nächsten Bild ist übrigens Teil der Deko und wurde uns von einer Weihnachtsmannagentur billig zur Verfügung gestellt. Zu billig, wie sich herausstellte, denn er hatte sein Weihnachtsmannkostüm vergessen... Well, you get what you pay for!

Und wie man sieht, hat sich unser Ex-Azubi iRene auch noch dazugetraut, und sogar unsere Unit-Test-Sorceress hat sich die Unit-Test-Krone auf's Haupt setzen lassen.

Um auf die Antwort auf diese Frage zu kommen, muß man historisch schon etwas bewandert sein. So muß man wissen, daß die ersten Versionen der MFC natürlich nicht für Win32 geschrieben waren sondern für Win16, also für dasjenige Programmiermodell, das die Ausführung von kooperativen Anwendungen unter Windows 3.1++ gestattete. Solcherlei Binaries hatten denselben Aufbau wie die Ende der Achtziger und Anfang bis Mitte der Neunziger stark verbreiteten MS-DOS Binaries. MS-DOS war ein OS, das den Intel 8086/80286 benötigte und in dessen "Real Mode" lief, weshalb der Speicher in sogenannten Segmenten verwaltet wurde, von denen ein jedes 64 kByte groß war. Geringer Speicherbedarf war Trumpf, denn wenn eine Anwendung wenig Speicher benötigte, konnte sie selber mehr Daten verwalten und ließ auch zu, daß so Goodies wie TSR-Programme oder Netzwerkstacks (gasp!) nebenherliefen. Eine andere Eigenheit des Real Mode war, daß Adressen entweder 16 bit breit (NEAR Pointer) sein konnten oder 32 bit breit (FAR Pointer), und die Adressarithmetik, die für FAR Pointer notwendig war, etwas Performance kostete. Also wollte a jeda seine Programme so schreiben, daß möglichst NEAR Pointer verwendet wurden und daß die logischen Segmente für Code, Daten und Stack möglichst klein sein konnten und am Besten in ein- und daselbe physikalische Segment passten.

Durch die damals vorherrschenden Entwicklungswerkzeuge Microsoft C, Microsoft Quick C, Borland Turbo Pascal und Borland Turbo C, später dann MS Visual C 1.0/1.5/1.51/1.52 und Borland C in verschiedenen Versionen, wurde diese segmentierte Architektur durch sogenannte Speichermodelle unterstützt. Durch die Wahl des Speichermodells legte man fest, wie die logischen Segmente auf die physikalischen Segmente verteilt wurden und wie deswegen für die einzelnen Zugriffe die Pointer aussahen, NEAR oder FAR. Dabei gab es folgende Auswahl:

• Tiny: Code und Daten werden über NEAR Pointer adddressiert und sind in einem einzigen physikalischen Segment kombiniert. Mit dem exe2bin-Programm kann man eine .com Datei aus der exe erstellen, das Binary ist kleiner als 64kByte und läuft nur unter DOS, nicht unter Windows.
• Small: Code und Daten werden über NEAR Pointer adddressiert und sind in je einem physikalischen Segment. Das Binary läuft unter DOS und Windows.
• Medium: Code wird über FAR Pointer und Daten werden über NEAR Pointer adddressiert. Das Binary läuft unter DOS und Windows.
• Compact: Code wird über NEAR Pointer und Daten werden über FAR Pointer adddressiert. Das Binary läuft unter DOS und Windows.
• Large: Code und Daten werden über FAR Pointer adddressiert. Das Binary läuft unter DOS und Windows.
• Huge: Code und Daten werden über FAR Pointer adddressiert. Zusätzlich können Large Pointer verwendet werden, die auf einen zusammenhängenden Speicherbereich > 64kByte zeigen, aber sehr teure Zeigerarithmetik bedingen. Das Binary läuft unter DOS und Windows.

Und was hat das jetzt mit den virtuellen Methoden von MFCs CWnd-Klasse zu tun? Ganz einfach: Jede Klasse, die virtuelle Methoden definiert oder redefiniert, impliziert damit eine Tabelle von Funktionszeigern, die sogenannte vtable, die irgendwo im Adressraum des Prozesses zugänglich sein muß. Wenn nun die Basisklasse aller Fenster Hunderte von virtuellen Methoden hätte, hätte das für alle abgeleitete Klassen natürlich auch riesenhafte vtables zur Folge, wenn diese eine virtuelle Methode definieren oder redefinieren. In letzter Konsequenz bedeutet das dann, daß man mit der Wahl des Speichermodells auf Large beschränkt ist, und das wollte man bei MS offensichtlich nicht, weshalb man die platzsparenderen Message Maps statt virtueller Methoden für Messagehandler einführte. Und so kam es, daß eine vom damaligen "App Wizard" erzeugte Standardapplikation mit full-blown Document View-Model die Speichermodelle Medium und Large verwenden konnte. Frameworks, die Message-Handler mit virtuellen Methoden abbildeten, waren auf Large beschränkt.

So, und nun braucht es auch nimmer viel, um die Frage nach den virtuellen Methoden für Property Sheets und Property Pages zu beantworten: Sie wurden eigentlich erst so richtig in Win32 etabliert und kamen erst mit der letzten Version der MFC, der Version 2.52b, als Backport in die Win16-Version der MFC. Und viele virtuellen Methoden sind außerdem ohnehin nur für den Wizard-Mode von Property Sheets erforderlich, der für die Win16-Version nie angeboten oder portiert wurde.