Hi
I want to post here a little assay I was experimenting a time ago. It is an object that has the capability to dis/en-able the access to hardware ports. As some of us can remember, this was possible on older OSs to access the CMOS values or other hardware components. In my case I experimenting with the parallel communication ports to play in user mode with an application Iím writing like the well known LapLink.

The object can perform the switching due a driver that is installed from within the object data and finally removed when no longer needed. The driver code per se is based on a driver written by Four-F I adapted a little bit.

Regards,

Biterider

Attachments:
Posted on 2006-04-17 12:10:37 by Biterider
Iirc you don't need a driver to do port access, if you're willing to use an undocumented NT call... you might want to check out this post :)
Posted on 2006-04-18 08:19:59 by f0dder
Hum, interesting. The DirectIO.exe doesn't work on my system but I will translate it to see if I can use the code. Thanks for the hint.

Biterider
Posted on 2006-04-18 09:50:14 by Biterider

Hum, interesting. The DirectIO.exe doesn't work on my system but I will translate it to see if I can use the code. Thanks for the hint.

Biterider

Hm, okay - might be interesting single-stepping it to see which call fails and with which error code. It *is* undocumented, I just thought it would work from NT4 up.
Posted on 2006-04-18 11:18:54 by f0dder
Hi
The code is OK. My mistake.
To adjust the IOPL, you have to reboot the box after the first run. That and the fact that the code must be executed under administrative right make it a little annoying. For the moment I prefer the gost-driver approach.

Btw, reading some text about the undocumented api, I discovered that the DEP protection can be easily deactivated by software, which makes the whole strategy completely ineffective. Sometimes I was surprised what the big heads of MS are doing...  :shock:

Biterider
Posted on 2006-04-18 12:19:35 by Biterider
Well, driver approach requires administrative rights as well - and I bet that turning off DEP also does. Is IOPL stuff per-user or systemwide? If it's systemwide, driver approach is probably better...
Posted on 2006-04-18 12:24:00 by f0dder
Hi
The driver method seems not to require special rights to run, at least my tests on a non administrative account show this. The current downside is that the code is not prepared for multiple instances but I think I can correct the situation with a counter on the driver side and tons of fault tolerant code.

Biterider
Posted on 2006-04-18 14:44:00 by Biterider
Hm, wtf? You can load a driver with a limited user account? That shouldn't be possible!
Posted on 2006-04-18 14:46:36 by f0dder
I closer look into the accounts I checked the app shows that they are all admin accounts. I opened a new limited user account and the SCManager failed as expected (as usual you are right  ;)).

Biterider
Posted on 2006-04-19 07:56:30 by Biterider
*phew* - I was just about to get afraid :)
Posted on 2006-04-19 08:02:19 by f0dder