![]() |
Usermode böse - Kernelmode lieb! Treiber sinnvoll einsetzen.
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 ![]() 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 ... |
Re: Usermode böse - Kernelmode lieb!
Netter Artikel, auch wenn der Titel jedenfalls fuer den Laien (mich :stupid: ) strange erscheint; es scheint so als wuerdest du sagen dass der Kernelmode lieb, und der Usermode boese ist :lol:
Greetz alcaeus |
Re: Usermode böse - Kernelmode lieb!
Mal was interesanntes, wieder was gelernt.
|
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Gemeinerweise dokumentiert MS aber nicht welche MS-Treiber ihre Parameter testen und welche nicht.
Einige Treiber die nur zur Benutzung durch andere Treiber vorgesehen sind (namentlich HIDUSB.SYS) machen das naemlich nicht. |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Zitat:
... aber alles wird gut - mit Vista :mrgreen: |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Supi geschrieben. Immer wenn jetzt wieder so ein Thread auftaucht wo nach Treiberprogrammierung mit Delphi oder ähnliches gefragt wird kann man jetzt erstmal die URL dieses Artikels posten...
|
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
ä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. gruß richard |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
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. Generell gebe ich gerne meine Sourcen weiter. (will sie ja nicht nur umsonst für mich für ein kleines Testprogramm geschrieben haben) 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. Und wie auch alle wissen, darf man meinen Sourcecode eben nicht in komerziellen Anwendungen benutzen, weil hooking so wie ich es mache eben eigentlich total unsicher ist. Sei es im User wie auch im Kernelmode. Aber man kann immer so schöne Sachen damit machen, wenn man gerade dem ein oder anderen Programm wieder was vortäuschen muss :) |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Zitat:
// Ansonsten finde ich den Artikel super :thumb: |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Hallo zusammen.
Was soll ich noch großartig zu diesem Artikel sagen bis auf klasse geschrieben und meine Hochachtung dazu. Mfg |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Daher Finger weg von sowas ;) |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Liste der Anhänge anzeigen (Anzahl: 1)
ö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. |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Zitat:
|
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Zitat:
Zitat:
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. |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
ich hab mich damit schon zu lang beschäftigt... mir ist die lust vergangen, wieder an meine parallele schnittstelle ranzukommen
|
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
Zitat:
Zitat:
Zitat:
Zitat:
Der Glossar-Eintrag für "Standart" ist ja Spitze :thumb: :zwinker: :mrgreen: Nachtrag: Zitat:
Zitat:
Zitat:
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_* ... |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
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? |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
:D 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 |
Re: Usermode böse - Kernelmode lieb! Treiber sinnvoll einset
So, der LptAccess Treiber ist nunmehr fast fertig.
![]() Da ich die meisten Themen bzgl. Direktzugriff auf LPT gesehen habe, habe ich entschieden zuerst den Treiber für LPT-Zugriff anzufertigen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:59 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz