Versteckte Funktionen in RunDLL und Registry optimieren

RunDLL im Griff: Selbst wer Windows gut zu kennen glaubt, findet in Bereichen abseits der grafischen Benutzeroberfläche verblüffende Möglichkeiten, um das Verhalten des Systems zu ändern oder es zu erweitern. Was sonst kein Dialog in der Oberfläche erreichen kann, ist beispielsweise mit der Änderung von Werten in der Registrierdatenbank realisierbar.

Gleiches gilt auch für zahlreiche Systemtools auf Kommandozeile. Das Hilfsprogramm Net bietet beispielsweise deutlich mehr Funktionalität, als von der Windows-Benutzersteuerung bekannt, obwohl sich Net noch um wesentlich mehr Aufgabengebiete kümmert. Neben diesen weithin gut dokumentierten Bereichen verbirgt Windows jedoch noch ein kleines Systemprogramm, das es aber in sich hat. Seine Aufgabe besteht darin, interne Funktionen von Windows oder von Anwendungsprogrammen aufzurufen, für die es häufig kein Pendant geben würde.

Wozu dienen DLLS?

Moderne Betriebssysteme bestehen aus mehreren zehntausend größeren Einzelfunktionen, damit die vielfältigen Aufgaben nicht immer aufs Neue programmiert werden müssen. Dieses Vorgehen bietet zahlreiche Vorteile:

Zum einen können viele Entwickler gleichzeitig an einer Aufgabe arbeiten, wobei die einen die Grundfunktionen umsetzen, die anderen wiederum die Programme, die darauf aufbauen. Solche Grundfunktionen können beispielsweise Umrechnungen zwischen Maßen sowie Zahlensystemene, die Wandlung von Speichersätzen oder Datumsberechnungen darstellen. Mit ihrer Hilfe wird Zeit und Speicherplatz eingespart.

Weiterhin lassen sich durch verschachtelte Funktionen immer komplexere Fragestellungen mit einem Programmaufruf und zugehörigen Parametern lösen. Nicht zuletzt ist es auch weit weniger fehleranfällig, Systemfunktionen einmalig umzusetzen. Sollte sich eine Funktion unter bestimmten Rahmenbedingungen als fehlerhaft herausstellen, reicht die Änderung eines Code-Teils, um alle darauf aufbauenden Anwendungsprogramme ebenfalls davon profitieren zu lassen.

Aufgrund der Vorzüge dieses Modells kommt die Verwendung von Funktionen nicht nur im fest verankerten Systemkern vor. Sogenannte dynamische Linkbibliotheken (DLLs) stellen Dateien dar, die einen Programmcode enthalten, der erst bei Bedarf geladen wird und nur für die Dauer der Verwendung im Speicher verbleibt. Unter Windows packen daher zahlreiche Software-Entwickler die häufig oder gar immer verwendeten Programmroutinen in diese zusätzlich ladbaren Bibliotheksdateien. In der Praxis nutzt man den Begriff DLL aber auch für Dateien, deren Endung nicht zwangsläufig .dll lautet, noch deren Inhalt wirklich immer nur dynamisch genutzt wird.

Unter diese Kategorie fallen dann unter anderem Bibliotheken im Exe-Format, die beispielsweise fester Bestandteil des Betriebssystems selbst sind (beispielsweise User.exe oder GDI.exe) und entsprechend dauerhaft im Speicher gehalten werden müssen. Der in die DLLs ausgelagerte Programmcode besteht aus Funktionen, die explizit für die Verwendung durch externe Programme reserviert sind. Man spricht dann von exportierten Funktionen.

Genauere Informationen zu diesem Thema finden sich insbesondere für C-Programmierer in der Microsoft-Knowledge Base unter der Artikel-ID 164787 ("The Windows 95 Rundll and Rundll32 Interface") sowie unter der Artikel-ID 140485 ("Exporting Pascal-Like Symbols in 32-bit DLLs"). Einen schnellen Zugriff auf die Microsoft-Knowledge Base erhalten Sie unter der URL. Dort können Sie dann im Suchfeld eine der oben aufgeführten Artikel-IDs eingeben.

Zugriff auf DLL-Funktionen

Um auf DLL-Funktionen aus dem Betriebssystem oder von Anwendungsprogrammen zugreifen zu können, sind einige Voraussetzungen erforderlich. So muss man beispielsweise wissen, welche Parameter in welcher Reihenfolge die einzelnen Funktionen erwarten und um welche Variablenart es sich dabei handelt. Dieses sogenannte Deklarieren von nicht selbst hergestellten DLL-Funktionen setzt in der Regel die Dokumentation des Herstellers oder beim Betriebssystem selbst API-Referenzen - also von Programmierschnittstellen für Anwendungsprogramme- voraus.

Aufgrund der zusätzlichen Einschränkung bei exportierten Funktionen lassen sich leider keine beliebigen DLL-Funktionen verwenden, beispielsweise zum generellen Zugriff auf interessante Hilfsroutinen der System-APIs (beispielsweise User und GDI), was das Einsatzgebiet von Rundll32 gewaltig ausgedehnt hätte. Da der Aufruf von bestimmten, aufgabenmäßig klar abgegrenzten Funktionen ursprünglich nur für Microsofteigene Zwecke (zum Beispiel der Installation sowie Deinstallation von Komponenten) vorgesehen war, wird ersichtlich, warum sich nur wenig Informationen zu diesem Thema finden.

Idealerweise sucht man einfach im System selbst, um auf entsprechende Hinweise zu stoßen. Dabei tritt zutage, dass zahlreiche für Rundll bzw. Rundll32 nutzbaren Funktionen auch gleich mit dem Namenszusatz _RunDLL oder RunDLL versehen sind (z.B. Control_RunDLL, InstallDevice_Rundll, PrintersGetCommand_RunDLL oder auch DiskCopyRunDll). Doch keine Regel ohne Ausnahmen, wie etwa InstallHinfSection oder auch NewLinkHere beweisen. Suchen, experimentieren und kombinieren ist hier also gefragt.

Die RunDLL-Syntax

Die ursprünglich für den Microsoft-internen Einsatz vorgesehenen Hilfsprogramme RunDLL (Windows 95/98) und Rundll32 (ab Windows 95/98 und NT 4.0, bei Windows 8 nur noch Rundll32) stellen einige formale Ansprüche an die Syntax des Aufrufs. Die grundsätzliche Form lautet dabei:

Ein Aufruf besitzt dann beispielsweise die folgenede Form:

Bei DLL-Aufrufen muss für den Funktionsnamen beziehungsweise die zusätzlichen Parameter generell auf Groß-/Kleinschrift geachtet werden, Rundll32 macht dabei keine Ausnahme. Sollte also ein Funktionsaufruf nicht das gewünschte Ergebnis erzielen, prüfen Sie bitte zuerst, ob die Groß-/Kleinschreibung stimmt. Rundll32 setzt zudem weiterhin voraus, dass sich zwischen dem DLL-Namen und dem Funktionsnamen zwingend ein Komma befinden muss und kein Leerzeichen auftreten darf.

Ist eine dieser Voraussetzungen nicht erfüllt, bricht Rundll32 seine Arbeit schon an dieser Stelle ohne Kommentar ab, ohne dass sich auf dem Bildschirm ein Ergebnis gezeigt hätte. Fehlermeldungen treten in der Regel nur dann auf, wenn versucht wird, eine nicht vorhandene DLL oder Funktion darin aufzurufen. Auch zusätzliche Parameter sind syntaktisch nicht unproblematisch, doch um ihre Auswertung kümmert sich die DLL selbst.

Aus diesem Grund beginnt bei einigen DLLs die Zählung bei Null, in anderen bei 1. Um also beispielsweise ein bestimmtes Register eines Systemsteuerungsdialogs ansprechen zu können, muss man experimentieren, da nicht sicher ist, ob @0,1 nun das erste Register im ersten Applet darstellt, oder schon das zweite (also @0,0 das erste). Auch andere Abweichungen beziehungsweise Ungereimtheiten beim Zugriff auf DLLFunktionen hängen damit zusammen, dass die DLL selbst dafür verantwortlich ist, die Parameter vollständig auszuwerten.

Wie aus Tabelle ersichtlich, bieten nicht alle Systemsteuerungsdialoge (Cpl-Dateien) die Möglichkeit, einzelne Register direkt anzuspringen. Werden Registernummern angesprochen, die nicht existieren (zum Beispiel appwiz.cpl,,8), so aktiviert die Funktion Control_RunDLL das jeweils erste Register des Systemsteuerungsdialogs. Während in früheren Windows-Versionen der gewünschte Dialog beziehungsweise eines seiner Register noch nicht aktiviert sein durfte, besteht diese Beschränkung bei Windows 8 nicht mehr. Bei älteren Windows-Systemen hätte ein DLL-Aufruf eines schon zuvor aufgerufenen Dialogs mit einem anderen Register dazu geführt, dass der Aufruf ohne weitere Reaktion verpufft wäre.

Direktaufruf von Systemsteuerungsdialogen

Um eines der Systemsteuerungsicons direkt zu aktivieren, verwendet man innerhalb eines Programmes den Aufruf einer Funktion in Shell32.dll. Diesen Aufruf macht sich auch Control.exe zunutze, um auf Systemsteuerungsdialoge wie beispielsweise per

auf die Eigenschaften von Datum und Uhrzeit zugreifen zu können. Nach gleichem Schema lassen sich auch alle übrigen .Cpl-Dateien (z.B. main.cpl, desk.cpl, sysdm.cpl usw.) verwenden (siehe Tabelle links). Zusätzliche Anwendungsprogramme oder Hardware-Treiber können weitere Cpl-Dateien in der Systemsteuerung platzieren. Welche Cpl-Dateien insgesamt zur Verfügung stehen, lässt sich unter DOS in der Eingabeaufforderung leicht feststellen.

Geben Sie dort

ein und Windows 8 liefert alle Cpl-Dateien aus allen Unterverzeichnissen des Systemlaufwerks, wie der Screenshot in Bild rechts zeigt. Jedem Rundll32- bzw. Control-Aufruf lassen sich durchaus auch noch Zusatzparameter übergeben, die dann ein bestimmtes Applet oder sogar gleich noch ein bestimmtes Register anwählen. Mit welchen Parametern Sie gezielt auf Systemsteuerungsdialoge zugreifen, haben wir in der erstem Tabelle für Rundll32-Aufrufe zusammengefasst.

In den meisten Fällen reicht es auch, statt

einfach nur den Aufruf:

zu verwenden, um auf zahlreiche Systemsteuerungsdialoge zugreifen zu können. Manche Control- oder Rundll32-Aufrufe funktionieren nicht bei allen Windows-Versionen, zudem spielen natürlich auch Home- oder Premium-Version sowie die Installation von Service-Packs sowie das Vorhandensein bestimmter Hardware eine Rolle.

Weitere RunDLL-Fundstellen

Die beiden interessantesten Bereiche für bestehende Rundll32-Aufrufe stellen Einträge in der Registrierdatenbank sowie Inf-Dateien im gleichnamigen Windows-Systemverzeichnis dar. Hier finden sich teils hochinteressante Rundll32-Aufrufe, die entweder Microsoft oder ein Dritthersteller verwendet haben. Was und wie viel Sie hier finden, hängt natürlich auch vom verwendeten Betriebssystem und den installierten Applikationen ab. Auf diese Informationen aufbauend lassen sich dann neue Konstruktionen schlussfolgern, die dann durch Tests bestätigt oder auch widerlegt werden.

Bei früheren Windows-Versionen spielte auch der Bereich der Definition registrierter Dateitypen eine große Rolle. Sie waren beispielsweise unter Windows XP unter Explorer/Ansicht/Optionen/Dateitypen zu finden. Windows 8 unterstützt dies nicht, zumindest nicht ohne den Umweg über die Registrierdatenbank. Der Aufruf von Regedit.exe ist deshalb bei Windows 8 damit doppelt lohnend. Mit etwas Geduld und Spaß am Tüfteln finden Sie so bestimmt zahlreiche interessante Rundll32-Aufrufe oder entdecken neue gültige Kombinationen.

In der ersten Tabelle sind exemplarisch einige der nützlichsten Vertreter aufgeführt. Ein weiterer Unterschied zwischen Windows 8 und früheren Windows-Systemen wie etwa Windows XP in Bezug auf Rundll32 betrifft den Einsatz der Funktion Senden an im Kontextmenü. So war es beispielsweise bei Windows XP möglich, eine Verknüpfung mit enthaltenem Rundll32-Aufruf in den Ordner Sendto des gewünschten Anwenders zu verschieben und diesen Aufruf im Kontextmenü zu verwenden. Bei Windows 8 gelangt man durch Suchen/Apps und der Eingabe von shell:sento auch in den Senden-an-Ordner.

Dort lassen sich durchaus auch Verknüpfungen mit dem Editor oder beispielsweise Wordpad anlegen, die klaglos arbeiten. Verknüpfungen mit Rundll32-Inhalt lassen sich per Kontextmenü/Senden an hingegen nicht aktivieren. Die gleiche Verknüpfung auf dem Desktop hingegen würde von Windows 8 wie gewünscht ausgeführt werden. Findet der Rundll32-Aufruf nicht per Startmenü oder Ausführen, sondern auf DOS-Ebene (beispielsweise in einer Batch-Datei) statt, können Sie Umgebungsvariablen, wie etwa windir verwenden:

Bei Ihren eigenen Versuchen ist allerdings bei DLLFunktionen Vorsicht geboten, in deren Namen "Init", FirstTime oder RunOnce vorkommt. Ansonsten wäre es möglich, dass ein Übertragungsprotokoll doppelt installiert wird oder ähnliche unerwünschte und schwer zu reparierende Effekte auftreten.