Check out this:

http://alegu.blogspot.com/

Ich habe zwar bei den bisherigen Blogposts kein Wort verstanden, aber das kommt sicherlich noch :-)

Link: http://dotnetmasters.com/HistoryOfCFamily.htm

Dieser Link ist mir heute von Alex geschickt worden:

History of the C family of languages

Klingt alles durchaus plausibel.

Nach den beiden Laserschwertern hat Mission Control neuerdings ein ultrasmartes neues Gadget (naja, solange halt, bisses der DEI schafft, es kaputtzumachen): Eine echte Luftgitarre! Und natürlich muss jeder Besucher von Mission Control, der keinen Eintritt zahlt, eine Frage hat oder nicht von selbst zugreift, neuerdings erstmal einen Luftgitarren-Riff zu den "Klängen" (sorry ABO!) von Eddie van Halen spielen. Klaro daß man diesen Anblick der Nachwelt erhalten muß. So spielt etwa mein treuer, braver Depp-uty sehr authentisch die Luftgitarre:

Was macht der Softwareentwickler von Welt, wenn ihm langweilig ist? Klaro, er findet Lösungen zu Problemen, die es noch gar nicht gibt. So auch bei mir dieses Jahr: Seit etwa 10. Dezember 2005 und vor allem zwischen den Jahren und in der ersten Januarwoche habe ich mich mit der MMC und Snap-Ins für die MMC beschäftigt. Der Grund dafür lag auf der Hand: Das war wieder mal eine Technologie mit der ich mich noch nicht beschäftigt habe, wohl aber der DEI, und das wurmt. Außerdem wollte ich mal wissen, wie lange sowas dauert, wenn man ein richtig amtliches Snap-In entwickeln will, das dem "Services" und "Event Log" Snap-In von W2K oder XP in punkto Aussehen und Funktionalität in nichts nachsteht.

Die Wahl des Frameworks

Für MMC Snap-Ins gibt es eine Reihe von Frameworks, die aber alle ihre Vor- und Nachteile haben. Man kann zum einen VB nehmen, da gibt es sogar einen Wizard dazu, der einem eine Menge abnimmt. Aber nein, sowas mach' ich nicht, man hat ja schließlich noch einen Funken Selbstachtung im Leib. Dann gibt es ATL und einen Wizard, der einem auch wieder viel abnimmt. Aber einige Postings in der Newsgroup microsoft.public.management.mmc haben mich dann doch aufhorchen lassen, weil einige Sachen dann doch ziemlich Broken sind, wenn man ATL verwendet. Die Samples zur MMC im PlatSDK hingegen verwenden ein selbergestricktes Framework und führen einen in mehreren Schritten von einem bare-bones Snap-In, das wirklich nur die allernötigsten COM-Interfaces implementiert, hin zu etwas aufwendigeren Snap-Ins mit einem richtigen Baum in der Scope-Pane und mit Property Pages für einzelne Knoten in der Result View usw. Und nachdem ich von der MMC bis dato noch überhaupt keinen Blassen hatte, dachte ich mir, es ist vielleicht sinnvoll, erstmals durch die Samples aus dem PlatSDK durchzudebuggen, um die Abläufe zu verstehen und hinterher vielleicht eine "more educated decision" zu treffen, was das Framwework der Wahl sein sollte. Und dabei bin ich dann auch geblieben, denn das Framework aus dem PlatSDK hat einen sehr großen Vorteil: Es versteht sich nicht als in Stein gemeißelte Klassenstruktur, das auf den immergleichen virtuellen Methoden und Klassen besteht, sondern es "erfindet sich quasi für jedes einzelne Sample neu". Die Samples untereinander teilen sich also nicht tonnenweise Framework Code als Common Code, sondern benutzen für jedes Sample gleichnamige Klassen mit denselben Dateinamen und Aufgaben, die aber für jedes Sample leicht unterschiedlich aussehen. Was zählt ist die Idee, die hinter jeder Klasse steckt, nicht aber die codemäßige Wiederverwendung. Sowas gefällt mir, denn es ist superflexibel und man kann sich aus den Samples, wo jedes einen bestimmten Bereich abdeckt, ganz frei bedienen. Wenn man also wissen will, wie man eine Toolbar implementiert, macht man einfach einen Diff zwischen dem nodes Sample und dem Toolbars Sample und weiss dann, wie man sein Snap-In erweitern muss, um die Toolbar zu kriegen.

Und so schaugt's aus

So sieht in etwa mein Snap-In aus, wenn man es frisch startet:

Wie man sieht, gibt's eine Toolbar, über die man die Result View Items steuern kann. Über ein Kontextmenü (Hey dafür muß man wie für die Toolbar extra ein neues COM-Interface implementieren, kein Witz!) kann man natürlich die einzelnen Result View Items auch a bissal bedienen:

Was dann passiert, wenn man das tut, habe ich mir vom "Services" MMC-Snap-in abgeschaut:

Das coolste aber ist dér Aufbau zu einem Remote-Computer. Was noch ausschaut wie beim Eventlog-Snap-In oder dem Services-Snap-In....

Sieht plötzlich voll aus wie Max im Wizard97-Look:

Wenn man dann beim Max weiterklickt, kommt einem wieder alles verdächtig bekannt vor:

...bis man dann auf diese Seite stößt, die einem gestattet, sich als anderer User als dem eingeloggten zu verbinden:

Am Schluß gratuliert Max dann natürlich artig, daß man das so toll hingekriegt hat:

Uuuunnd wen man JJJEEEEETTTTZZZZTTT den "Finish"-Button drückt, dann kommt es einem...

Oooochh, wie? Auf SAAVIK läuft das RPC-Interface nicht? Macht nichts, dann zeigen wir eben kein List Control im Report Mode an sondern das MMC OCX für Messages, so wie im obigen Bild.

Au weia. Das hat mich Tage gekostet, daß das in allen Use Cases lief. Und als mich dann der Wahnsinn gepackt hat und ich dachte, jetzt ist das Biest "Ready for Prime Time", da wollte ich wissen ob das Ganze auch unter NT4 funktioniert. Also, NT4SP6 VMWare genommen, das NT4 Redistributable für die MMC 1.1 installiert. Setup verweigert die Ausführung: "Hey ohne IE 4.01 geht hier nix!". Also im CD-Gruschtelregal nach alten IE4-CDs gesucht, gefunden und installiert. Und dann geht erstmal gar nix in meinem Snap-In: Der schöne Wizard sieht total komisch aus (weil IE4 die Wizard97-Spezifikation nur so halbe eingeführt hat), er kommt nie zum Abschluß (weil ich lauter Makros für Comctl32 Version 5.80 verwendet habe, wo doch IE4 nur comctl32 Version 4.72 mitbringt) und die schöne Message View wie im letzten Bild gibt's schon mal gar nicht, weil es dieses COM-Interface erst mit MMC Version 1.2 gibt (die für NT4 ist 1.1).
Also folgendes getan

• Code geschrieben für die Erkennung der unterschiedlichen MMC-Versionen (uuh, ist das convoluted! - das IComponent und das IComponentData-Interface müssen da Hand in Hand arbeiten um das rauszukriegen...)
• Extra Templates für Old-Style Wizards mit MMC1.1 erzeugt
• Alle 5.80er Common Control Makros ersetzt und höllenviel Code geschreiben, der auch unter comctl32 Version 4.7x funktioniert
• Die MessageView ersetzt durch ein Pseudo-Result-View-Item, das halt denselben Text in einer Report View anzeigt.

Aber es gibt auch echt was für's Auge, z.B. die Property Pages für die einzelnen Result View Items:

Herzig, sieht doch aus wie bei Muttern, dem Services MMC Snap-in, oder? Die zweite Seite macht bei ihrem großen Vorbild natürlich auch phatte Anleihen:

Nicht zu vergessen Seite 3, die sehr geschwätzig das Service Control Manager API bemüht:

Und wie lange braucht man dafür?
Wollte man so vermessen, sein, mich als "erfahrenen Entwickler" zu bezeichnen, dann könnte man sagen, daß ein erfahrener Entwickler dafür 3 Wochen braucht, und beim zweiten Mal dann zwei Wochen. Davon sind etwa 3 Tage allein anzusetzen für ausschließliches Debuggen der Samples und das Nachvollziehen der Abläufe, unterstützt von den UML-Sequenzdiagrammen (!) aus der PlatSDK Doku. Für den NT4-Backport habe ich einen ganzen Tag gebraucht. Für die korrekte und flickerfreie Implementation eines Refresh (also "F5 Drücken"), etwa 3 Tage. Für die Property Sheets auch etwa 2 Tage (Hey, da steckt Logik dahinter!).

Alles in allem hat's Spaß gemacht und es gibt wieder eine Technologie mehr, wo ich dem DEI wieder hoffentlich auf mehr als Augenhöhe ;-) entgegentrete. Und nein, auch wenn DEI behauptet, das PlatSDK-Framework für MMC-Snap-Ins sei uncool: Ich finde es ganz brauchbar. Wer's verwendet, und wissen will, wo da die Speicherlecks drin sind, darf sich dann vertrauensvoll an den Mission Control Supreme Commander wenden.

Aber das allerbeste ist der Umstand, daß da keine einzelne Zeile MFC-Code drin ist, weil das ganze Mal wieder 'mal eine Technologie ist, wo MFC mehr behindert als nützt. Und wenn ein Projektleiter mich dereinst vielleicht fragt, wieviel davon denn wiederverwendbar sei, dann lautet die freudige Antwort: "Null!" und ich habe nicht ein bißchen ein schlechtes Gewissen dabei.

Halt, halt, ... , nein, das Allerallerbeste ist: Es gibt in dem ganzen Projekt keine einzige globale Variable. Braucht man da einfach nicht, sorry. Naja, es geht auch mit, aber wir wissen ja, wozu sowas führt...

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.