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

[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.