Usermode böse - Kernelmode lieb! Treiber sinnvoll einsetzen.

[Olli]

Weil (mir) das Thema immer wieder hochkommt, wenn Leute fragen wie man dies oder jenes machen kann, wollte ich mal ein paar klarstellende Worte zum Sinn und Unsinn der Trennung von Kernel- und Usermode verlieren.


Vom Usermode in den Kernelmode

Zuallererst möchte ich natürlich Brechi und seinen Kollegen Respekt zollen. Natürlich kann man einen Treiber prinzipiell auch mithilfe des Delphi-Compilers und -Linkers zusammenbasteln; natürlich kann man über andere Wege (z.B. PhysicalMemory-Section) in den Kernelmode eindringen. Alles ganz doll und auch sehr imposant. Aber leider alles nur für Hackertools tauglich. Ja, richtig gelesen, Hackertools: diese Lösungen sind nichts für den Ottonormalprogrammierer, geschweige denn -anwender, der u.U. nichtmal genau weiß was Kernelmode und was Usermode sind. Und man möge mir verzeihen wenn es pedantisch klingt, aber die kleinen nützlichen, "nützlichen" und unnützen Code-Schnipsel, die irgendwann mal entstehen machen es leider noch zu häufig in eine später kommerzielle Lösung. Das ist dann fatal, wenn weder der Programmierer weiß was er tut, noch der Benutzer die Sicherheitslöcher erahnt, die durch die Installation einer solchen Software aufgetan werden.


Begrifflichkeiten und Befindlichkeiten

Die Begriffe Kernelmode (KM) und Usermode (UM) werden oft sehr abstrakt verwendet. Komischerweise haben sie aber einen Sinn. Dieser besteht hauptsächlich darin, daß eine Trennung von privilegiertem und unprivilegiertem Code erzeugt wird. Diese Trennung ist wichtig, weil man sonst auf der NT-Plattform noch immer diese wundervollen Bluescreens en masse wie unter Win9x bekäme.
Falls jetzt jemand meint, er hätte unter NT aber auch schonmal einen Bluescreen gesehen - erstmal Luft anhalten.

Diese Trennung der Modi wird dank des Prozessors direkt unterstützt und ermöglicht beispielsweise, daß die Prozesse auf der NT-Plattform strikt voneinander getrennt sind. Ansonsten könnte eben einer beim anderen im Adreßraum rumkritzeln. Nicht sonderlich prickelnd wenn das eigene Programm Opfer von sowas wird.

Jeder KM-Programmierer lernt so ziemlich als erstes, daß UM-Code böse ist. Dies hat einen gewissen Sinn; es schärft dem Programmierer ein, keinem UM-Code zu trauen. Wenn der UM-Code also einen Request an einen Treiber schickt und darin steht, daß Adresse XYZ "gut" ist, muß der Treiber dennoch, so paranoid es erscheinen mag, penibelst prüfen ob der UM-Code auch wirklich nicht "lügt". Alles andere kann, von einem BSOD (Bluescreen of death) über Hardwareschäden bis zu schlimmsten Sicherheitslücken, bittere Konsequenzen nach sich ziehen.

Interessanterweise ist der erste Schrei seitens der Anwender, wenn Windows mal wieder blaumacht, "Windows ist schuld!". Obwohl das natürlich der Fall sein kann, ist es keineswegs so wahrscheinlich wie daß es sich um einen Treiber eines Drittanbieters handelt. Natürlich kann es vorkommen, daß Microsoft "vergessen" hat bei einer Funktion auf ungültige Parameter zu prüfen. Dies ist aber sehr unwahrscheinlich und, wie ich hier (ab #28) nachgewiesen habe, zumeist auf Software von Drittanbietern zurückzuführen. Das ist eben der große Unterschied zwischen UM- und KM-Programmierung: wenn ich im UM scheiße programmiere, stürzt maximal mein Programm (oder im Fall von Hooking-DLLs alle gehookten Programme) ab, wenn ich im KM scheiße programmiere, stürzt im besten Fall nur der PC mit einem BSOD ab - im schlechtesten Fall beschädige ich gleich noch die Hardware.

Vielleicht lassen die obigen Ausführungen den einen oder anderen schon erschaudern, wenn sie daran denken was bei falscher Handhabung alles passieren kann, aber es kommt noch besser.

Generischer Portzugriff ist was Feines ...

... sagte der Virus und brannte lustige Muster auf dem CRT-Monitor ein. Zugegeben, dank TFTs ist dieses Risiko gemindert, aber das Umprogrammieren von Hardwarekomponenten ist nach wie vor möglich.

In allen diesen Fällen ist es natürlich so, daß die Hardware spezifisch angesprochen und zerstört werden muß. Aber auch wenn es nur 50% der Anwender trifft, dürfte das für ein Softwarehaus (jenes welches den Zugriff ermöglichte) einen beträchtlichen Imageschaden bedeuten.

"Lustig" wäre auch die Umprogrammierung von Dongles, denn da gibt es nicht so viele verschiedene Systeme, daß man sie nicht bequem in einem Trojaner unterbringen könnte. So wäre gleichzeitig die Firma welche die Dongles produziert, die Firma welche die Dongles benutzt um ihre Software zu schützen und nicht zuletzt der Kunde sprichwörtlich angeschissen.

Immer wieder werden, sei es aus Unwissenheit oder Ignoranz, Lösungen empfohlen, die generischen Portzugriff erlauben. Diese empfinden die CPU-Befehle IN und OUT nach. Die korrekte Alternative wäre allerdings ein Treiber, welcher nur auf spezifische Ports einen Zugriff erlaubt. Absichern kann man sich nämlich nicht gegen feindliche Übernahme. Deswegen kann der Treiber genau wie er vom eigenen Programm benutzt werden kann auch von einem fremden Programm (z.B. einem Virus) mißbraucht werden. Generisch bleibt generisch, und so ist dann auch die potentielle Schadenswirkung: breitmöglichst.


Fazit

Wer nach diesen Ausführungen noch nicht kapiert hat, wohin es führen kann - und mittelfristig wird - einem Usermode-Programm generischen Zugriff auf Ressourcen zu geben, die eigentlich dem Kernelmode vorbehalten bleiben sollten, der wird es sicher niemals begreifen, oder er tut es eben aus Spaß an der Hackerei. Allerdings ist Hackerei selten alltagstauglich, weshalb auch die Fragesteller sich nicht immer auf den erstbesten "Rat" zur Einschleusung von Code in den KM oder zur Benutzung von generischem Portzugriff einlassen sollten. Im Endeffekt hat die Trennung nämlich seinen Sinn gehabt und Microsoft/Cutler hat sich was dabei gedacht.

Beklagen müssen wir uns jedenfalls nicht darüber, daß Windows so instabil ist, sondern daß wir es so instabil machen indem wir solche Frickellösungen zulassen und vielleicht noch weiterempfehlen.


So das war's. Ich hoffe es hat meinen Lesern ein wenig Einsicht gebracht. Da solche Diskussionen seit Jahren immer wiederkehren, dachte ich mir es sei Zeit für eine kleine Abhandlung zum Thema ...

[Olli]

Zitat von richard_boderich:

äh du meinst jetzt aber nicht sowas wie z.b die portio.sys oder portio.dll treiber, den diese
ermoeglichen ja auch direkten zugriff auf speicheradressen ueber den smbus? ich frage naehmlich weil
ich diese komponenten in meiner mainboardueberwachungssaftware benutze.

Doch genau solche meine ich. Wenn du willst, helfe ich dir gern eine andere - maßgeschneiderte - Lösung zu basteln

Zitat von brechi:

Hab nichts gegen den Artikel auszusetzen.
Alles was ich so programmiere, ist halt rein proof of concept, womit ich zeige, was man alles so machen kann. z.b. werden aber Usermode hooks wirklich eingesetzt und komerziell verkauft, (madshi.net) wo ich mir ebenfalls super oft denken muss wie wenig Plan die Nutzer davon haben wenn sie meinen sie köntnen damit Antiviren-Programme schreiben.

Jupp, Usermode-Hooks sind ja soweit okay.

Zitat von brechi:

Generell gebe ich gerne meine Sourcen weiter. (will sie ja nicht nur umsonst für mich für ein kleines Testprogramm geschrieben haben)

Jupp, finde ich auch super. Aber man muß denen die "wenig Plan haben" auch sagen, daß sowas als POC sehr gut ist, aber nichts in Anwendungssoftware zu suchen hat.

Zitat von brechi:

Zumal es in letzter Zeit viele Leute (Skriptkiddies??) gibt die mal in deim ein oder anderen Programm etwas hooken wollen oder eben einen Trainer schreiben wollen. Dafür sind meine Sourcen halt schon nützlich, denn wer hat immer Bock sich damit selbst zu verfassen, weil es doch recht kompliziert ist.

Locker bleiben. Das mit dem Respekt war nicht nur dahingesagt! Das war auch so gemeint. Aber es gab da ja schon den ein oder anderen Thread wo der KM "in Angriff" genommen wurde

Zitat von brechi:

[...] weil hooking so wie ich es mache eben eigentlich total unsicher ist. Sei es im User wie auch im Kernelmode.

Deswegen obiger Artikel

Zitat von jfheins:

aber mir stellt sich jetzt die Frage, was denn "generischer" Zugriff ist, was man damit machten kann(, und wie man ihn erreicht) ...

Generischer Zugriff bedeutet, daß man mithilfe des jeweiligen Treibers wahllos auf alle I/O-Ports zugreifen kann. Also auch auf jene auf die die Anwendung welche den Treiber benutzt nie zugreifen müßte. Der installierte Treiber ermöglicht aber eben jeder anderen Software diese mißbräuchliche Nutzung ...

Daher Finger weg von sowas

[richard_boderich]

öhm jaa olli dann wuerd ich dein hilfe sehr gern in anspruch nehmen.
was bräuchst den von mir?

Richard

//edit olli guck dir das mal an, was ich hochgeladen habe. dort gibt es eine option
"I/O Permission Map Grid, die mir so aussieht als ob ich da zugriff auf nur bestimmte adressen zulassen kann. was haellst davon? das ist jetz gwioport. wie gesagt ich habs mit portio.sys
gemacht.

[Daniel G]

Zitat von richard_boderich:

öhm jaa olli dann wuerd ich dein hilfe sehr gern in anspruch nehmen.
was bräuchst den von mir?

Ginge das auch öffentlich? Also, nicht das du Richards Code hier auseinandernimmst, sondern dass du sagst, wie's prinzipiell ginge. Weil ich mich etwas schlau gemacht hab' im Web und eigentlich eine Funktion zum Anzeigen der Temperatur in meinem Programm "CPUiD" integrieren will (in nächster Zeit). Allerdings wird dafür auch GIVEIO.SYS verwendet...

[Metal_Snake2]

Zitat:

Aber leider alles nur für Hackertools tauglich. Ja, richtig gelesen, Hackertools: diese Lösungen sind nichts für den Ottonormalprogrammierer

Da stimme ich dir voll und ganz zu. Eigentlich ist das hier alles spielerei! Nur kann man Code schnippets auch für lernzwecke nutzen. Man erfährt alleine durch den blanken code (den man verstehen solte!) schon einiges. Ich persönlich finde das das Hooking idealerweise für lernzwecke geeignet ist. Egal ob im Benutzer- oder Treiberland. Leider sind Hooks durch das ausnutzen einiger user negative behaftet, obwohl Hooks dem programmierer viel macht verleiehen.

Zitat:

wenn ich im UM scheiße programmiere, stürzt maximal mein Programm (oder im Fall von Hooking-DLLs alle gehookten Programme) ab, wenn ich im KM scheiße programmiere, stürzt im besten Fall nur der PC mit einem BSOD ab - im schlechtesten Fall beschädige ich gleich noch die Hardware.

Stimme hiermit auch zu. Jedoch kann man dies weiter Differenzieren. Treiber sind mehr als Module die Beim booten als Dienst aus der Registry geladen werden und nur zur steuerung von Harware Ressourcen dienen. Es gibt Treiber die auf andere Treiber schichten(Layered Drivers), manche nennen sie auch Sandwich Trieber. Solche Treiber werden meistens für Filter zweck verwendet, z.B. benutzen viele Kommerzielle Firewalls einen NDIS IM Treiber welcher die NDIS API Hooken und zwichen der TDI und der NetCard schichten(daher auch Sandwich Treiber). Solche Treiber greifen also nicht direkt auf die Harware zu.



Generell sollte jeder einen Treiber(Kernel geschichten) in C mit der DDK schreiben. Microsoft hat sogar mit der WDM einen gewissen Standart für Treiber Programmierung herausgebracht.

Wer sich für Kernelprogrammierung interisiert soltte sich am besten enstprechende Bücher besorgen.




Finde ansonsten den Artikel gelungen für leute die noch nie was vom User- oder Kernelspace gehört haben.

[hboy]

ich hab mich damit schon zu lang beschäftigt... mir ist die lust vergangen, wieder an meine parallele schnittstelle ranzukommen

[Olli]

Zitat von Metal_Snake2:

Leider sind Hooks durch das ausnutzen einiger user negative behaftet, obwohl Hooks dem programmierer viel macht verleiehen.

Manchmal sind sie sogar unumgänglich, siehe Registryzugriff auf Windows 2000. Ab XP gibt es einen Callback-Mechanismus vom System.

Zitat von Metal_Snake2:

Jedoch kann man dies weiter Differenzieren. Treiber sind mehr als Module die Beim booten als Dienst aus der Registry geladen werden und nur zur steuerung von Harware Ressourcen dienen. Es gibt Treiber die auf andere Treiber schichten(Layered Drivers), manche nennen sie auch Sandwich Trieber. Solche Treiber werden meistens für Filter zweck verwendet, z.B. benutzen viele Kommerzielle Firewalls einen NDIS IM Treiber welcher die NDIS API Hooken und zwichen der TDI und der NetCard schichten(daher auch Sandwich Treiber). Solche Treiber greifen also nicht direkt auf die Harware zu.

Sandwich höre ich in dem Zusammenhang zum ersten Mal

Zitat von Metal_Snake2:

Generell sollte jeder einen Treiber(Kernel geschichten) in C mit der DDK schreiben. Microsoft hat sogar mit der WDM einen gewissen Standart für Treiber Programmierung herausgebracht.

... oder in C++ mit dem KMDF

Zitat von Metal_Snake2:

Wer sich für Kernelprogrammierung interisiert soltte sich am besten enstprechende Bücher besorgen.

... oder an den entsprechenden Seminaren teilnehmen (OSR, Oney und wie sie alle heißen ...).

Der Glossar-Eintrag für "Standart" ist ja Spitze

Nachtrag:

Zitat von richard_boderich:

dort gibt es eine option
"I/O Permission Map Grid, die mir so aussieht als ob ich da zugriff auf nur bestimmte adressen zulassen kann. was haellst davon? das ist jetz gwioport. wie gesagt ich habs mit portio.sys
gemacht.

Das ist eigentlich fast noch heftiger als "normaler" generischer Port-I/O, weil er damit komplett die Beschränkungen des Systems umgeht

Zitat von Graham Wideman:

Getting Permission From NT

Under NT, "user-mode" code (ie: applications written by mere mortals) is not allowed to access hardware directly, hence when your application attempts to execute an I/O instruction you get an exception. The idea is, of course, that hardware resources are things that no application should just take over at will, instead it should be up to the operating system (and its drivers) to arbitrate between different apps requests to use those resources.

That's the theory. Turns out that the NT kernel maintains a map of I/O port addresses that each process is allowed to access, and for your apps that's normally set to "none". But we can tell NT to use a different I/O Permissions Map (IOPM) for our process and thereby gain access to the ports. This approach is of course very naughty from a disciplined OS standpoint, so not recommended for widely distributed commercial apps. But for those times when you just need to hack on some hardware, who has time to write a proper NT device driver?

Zitat von Daniel G:

Ginge das auch öffentlich? Also, nicht das du Richards Code hier auseinandernimmst, sondern dass du sagst, wie's prinzipiell ginge. Weil ich mich etwas schlau gemacht hab' im Web und eigentlich eine Funktion zum Anzeigen der Temperatur in meinem Programm "CPUiD" integrieren will (in nächster Zeit). Allerdings wird dafür auch GIVEIO.SYS verwendet...

Der Code für einen Treiber wird wenn dann definitiv OpenSource, japp.

Noch'n Nachtrag:
Ich finde beide, giveio.sys und gwiopm.sys äußerst interessant vom technischen Standpunkt her, aber aus der im obigen Artikel beschriebenen Sicht bleibt mir fast der Atem weg.

Beispiel: dank gwiopm.sys kann man IN und OUT direkt aus seinem Delphi-Programm anwenden. Nichtmal NT-Treiber benutzen IN und OUT direkt, weil es dazu Wrapper in der HAL.DLL gibt. Diese Wrapper garantieren, daß sich das ganze auch dann noch sauber verhält, wenn es für ein anderes System kompiliert wird. Siehe READ_PORT_* und READ_REGISTER_* ...

[Olli]

Hallöle, da bin ich wieder.

Ich wollte nur mitteilen, daß ich für den Zugriff auf LPT gerade den entsprechenden Treiber und danach die Interface-Unit(s) und C/C++-Header/Module schreibe. Für speziellere Geschichten kann sich ja gern jeder an mich wenden.

Richard hatte sich schon einmal gemeldet, seitdem aber nicht mehr ... hoffentlich nix passiert?

[richard_boderich]

danke fuer deine sorge olli aber ich hab gewartet das du mal was schreibst. ich wollt dir auch nich auf den S... gehen mit zuviel pm generve. hab da schlechte erfahrungen mit gemacht.
schade das du keinen schnellen inet zugang hast, sonst koennten wir uns mal im inoffiziellen DP-Teamspeak treffen und das mal belabern. wie gesagt waere ich sehr an einer zusammenarbeit interessiert. ich bin mir nur nicht ganz sicher wie eine solche aussehen koennte. deswegen hatte ich ja angefragt was du von mir brauchst. hinzugefuegt sei noch. das ich von C nur rudimentaere allgemeine kenntnisse habe und von treiberprogrammierung gar keine. ich hoffe aber trotzdem das wir was auf die beine stellen koennen.

gruß richard

[Olli]

So, der LptAccess Treiber ist nunmehr fast fertig. Hier geht's zur Beta (und später auch zur Final ) ...

Da ich die meisten Themen bzgl. Direktzugriff auf LPT gesehen habe, habe ich entschieden zuerst den Treiber für LPT-Zugriff anzufertigen.