IBM(jetzt ja nicht mehr) verbaut in seinen Thinkad-Laptops Vibrationssensoren. Darüber kann die räumliche Lage des Laptops als auch der Grad der Erschütterung gemessen werden. Diese Funktion wird genutzt um die Festplatten bei zu großer Erschütterung abzuschalten und damit vor der Zerstörung zu schützen. Prinzipiell dokumentiert IBM das System als solches in folgendem Dokument: http://pusa.uv.es/~ulisses/thinkpad/aps2mst.pdf . Meine erste Vermutung das es sich um einen Kernel-Mode-Treiber handeln muss der über einer User-Mode-Schnittstelle verwaltet wird, bestätigte sich. Leider gibt es von IBM keiner Header-Informationen um die Schnittstelle in Form der sensor.dll selbst zu verwenden. Will man also an die Vibrationsinformationen auf seinem Thinkpad kommen und in der eigenen Software verwenden, muss man sich was anderes überlegen. Es ist jedoch möglich mit geringem Wissen über das WDM-Device-Driver-Konzept und Assembler heraus zu bekommen wie die Kommunikation mit dem Treiber funktioniert
DeviceIoControl:
Microsoft stellt zur Kommunikation mit bestimmten Device-Treibern das API-DeviceIoControl zur Verfügung. Diesem API übergibt man einen IOControlCode sowie einen Input und Output buffer zur Kommunikation mit dem Treiber-Device. Das Handling des Buffers wird durch das Treiber-System übernommen. Nach erfolgreicher Abfrage steht uns ein Stück Speicher mit Informationen zu Verfügung die nur noch Inteprertiert werden mussen. Um festzulegen welches Gerät man abfragen will, wird ein FileHandle verwendet das mit der API CreateFile erzeugt werden muss. Zur Erzeugung eines File-Handles muss auch entsprechende Datei in Form eines Devices zur Verfügung stehen. Diese Geräte müssen sich in einem besonderen Kernel-Object-Name-Space befinden. Um einen Überblick über die Objekt-Struktur zu bekommen, hilft das Tool WinObj weiter.
Mit diesem Wissen kann man nun an die sensor.dll gehen, die ja von IBM als Benutzerschnittstellen ausgewiesen wird. Erste Überlegungen legen nahe das diese DLL nur ein schmaler Wrapper um die jeweiligen DeviceIoControl-Aufrufe ist. Wie bekommt man jetzt die benötigten Parameter heraus ?
Win32DAsm
Ich benutze das Tool Win32Dasm von URsoft um die Sensor.dll in ihrer vollen Assembler-Schönheit zu sehen. Es hat den Vorteil die Entrypoints der exportierten Funktionen mit Namen zu versehen und auch die bekannten Einsprungspunkte in die Win32-API in einem lesbaren Format darzustellen, so ist leichtes Navigieren möglich.
Entwurf des Prototypen
Nachdem das Funktionsprinzip der Software klar ist, kann man sich jetzt der Definition des Prototyps zuwenden und der Technik um alle benötigten Details zu finden. Dieser Prototyp soll sehr einfach gehalten werden und nicht die Original-APIs aus der sensor.dll aufrufen, sonder nur die DeviceIoControl-Calls ausführen. Ziel ist es ein Programm zu entwerfen, was die aktuelle Lage des Laptops ausgibt, nichts anderes macht die Control-Panel-Erweiterung mit etwas OpenGl verschönert.
Auswahl der Funktionen
Zur Auswahl der benötigten APIs kann man die sensor-DLL mit dem Dependency-Walker anschauen. Zum Glück sind auch alle Funktionen mit sprechenden Namen exportiert und so kann deren Bedeutung leicht erahnt werden. Ist das nicht möglich hilft manchmal auche die einfache Anwendung des in den Dependency Walker integrierten Profilers. So kann man z.B. erkennen das die Sensor.dll erst nach dem Programm-Start über LoadLibrary und GetProcAddress verwendet wird. Auch der WinObj hilft weiter und macht viele Synchronisations-Objekte sichtbar.
Um die Lage des Laptops heraus zu bekommen scheint die Funktione mit dem Namen GetAccelerometerData sehr vielversprechend. Also schauen wir uns den Assembler-Code an, der hinter dieser Funktion steckt. Jeder der jetzt den DASM aufmacht, wird sehen das eigentlich nur unwesentlich wichtiger Code vor dem eigentlichen Einsprung in die DeviceIOControl-Routine steht, somit sind für uns nur die genutzten Parameter wichtig. Die MSDN verrät das DeviceIOControl 8 Parameter benötigt. Diese werden in umgekehrter Reihenfolge auf den Stack gelegt. Dazu wird die push-Anweisung verwendet. Und siehe da, direkt vor dem Sprung finden sich 8 Push-Anweisungen mit den Parametern. Bis auf die Frage wo kommt das File-Handle her ist alles sehr durchsichtig und statisch. Es wird ein 36 Byte langer Output-Buffer übergeben und ein 0 Byte langer Input-Buffer. Das File-Handle kommt aus einem während der DLL-Initialisierung stattfindenden Aufruf von CreateFile. Daraus ergibt sich folgender Code für unseren Prototypen um den Lage des Laptops auszelesen:
HANDLE hShockMgr = CreateFile( "\\\\.\\ShockMgr", 0, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL );
DWORD dwOutLen = 0x24;
LPBYTE lpOutput = (LPBYTE)LocalAlloc(LPTR, dwOutLen );
DWORD dwIOCode = 0x733FC;
DeviceIoControl( hSchockMgr, dwIOCode, NULL, 0, lpOutput, dwOutLen, &dwReturnedBytes , NULL );
Den entsprechenden Aufruf sollte man jetzt immer aufrufen wenn die neue Lage des Laptops abgefragt werden soll, natürlich sind alle Resourcen wie das geöffnete File-Handle wieder frei zu geben. Zusätzlich kommt noch einiges an Probier-Aufwand hinzu um die richtige Belegung der einzelnen Bytes im Rückgabewert zu verstehen. Hier hilft es seinen Laptop während des Auslesens in die entsprechenden Richtungen zu drehen und die Veränderungen zu notieren. Besonders Augenmerkt sollte auch noch auf die Funktion GetAccelerometerMutex gelegt werden, wenn dieser Code irgend parallel zu anderen Clients verwendet wird (und davon ist auszugehen). So lässt sich sehr leicht ein Tool entwerfen, das den Mouspointer über die Bewegung des Laptop steuert oder ähnliches.
Ich hoffe das dieser Artikel ein nützlicher Anfang für jeden ist, der den Vibrationssensor des Thinkpads für eigene Zwecke nutzen will. Als Autor kann ich weder für die Korrektheit aller Angaben garantieren noch irgendeine Form der Verantwortung an Beschädigungen des eigenen Gerätes übernehmen.
Links:
Intel x86 Function-call Conventions - Assembly View
http://www.online.ee/~andre/i80386/Opcodes/
http://pusa.uv.es/~ulisses/thinkpad/aps2mst.pdf