Index
> Windows > Port I/O and NtSetInformationProcess |
| Author |
|
|
System86 29 Jan 2008, 01:06
I've made a user mode program that directly accesses ports under Windows XP, without any IOPL drivers. It uses the undocumented internal function NtSetInformationProcess, which I found on the internet allows you to change the IOPL of the program. It sets the IOPL to 3, turns on the speaker using ports, waits for a keyhit using _getch, and turns off the speaker. The source code is here:
Code: format pe console entry start include 'win32axp.inc' start: .next: push 4 push iopl push 16 push -1 call [NtSetInformationProcess] ;NtSetInformationProcess(NtCurrentProcess(), 16, &Iopl, sizeof(Iopl)) cmp eax, 0x3FFFFFFF jb .noerror cmp eax, 0x40000000 jb .error cmp eax, 0x7FFFFFFF ja .error .noerror: cinvoke printf, <'Access Port!', 10, 13> mov ax, 500 call sound call [_getch] call nosound jmp .done .error: cinvoke printf, <'Fatal error %X!', 10, 13>, eax .done: invoke ExitProcess,0 ;turns the PC speaker on sound: push ax bx dx mov bx, ax mov ax, 34DCh mov dx, 12h div bx ;calculate frequency, result in ax mov dx, ax mov al, 0B6h ;channel 2, square wave out 43h, al ;set timer 2 countdown value mov al, dl out 42h, al mov al, dh out 42h, al in al, 61h or al, 3 ;turn on the speaker out 61h, al pop dx bx ax ret ;turns the speaker off nosound: push ax in al, 61h and al, not 3 out 61h, al pop ax ret align 4 iopl dd 3 section '.idata' import data readable library kernel32,'KERNEL32.DLL', msvcrt,'MSVCRT.DLL', ntdll, 'NTDLL.DLL' import msvcrt, system,'system', printf, 'printf', _getch, '_getch', _kbhit, '_kbhit' import ntdll, NtSetInformationProcess, 'NtSetInformationProcess' include 'api/kernel32.inc' include 'api/user32.inc' include 'api/gdi32.inc' include 'api/advapi32.inc' include 'api/comctl32.inc' include 'api/comdlg32.inc' include 'api/shell32.inc' include 'api/wsock32.inc' If you try to simply run the code, it won't work, though. You need the SE_TCB_PRIVILEGE, which only the NT AUTHORITY\SYSTEM account has, even administrator does not have it. As for how to get to this privilege level, I followed the instructions here. It works (I've tested it), but is there a simpler way to get SE_TCB_PRIVILEGE (ideally within the program)? I know there is the example here for port I/O, but it does not come with source (just exe and docs) so I don't know how it accomplishes it (BIEW disassembler didn't help). |
|||
29 Jan 2008, 01:06 |
|
|
revolution 29 Jan 2008, 05:01
There are already some posts on this board that show how to allow I/O. Search for KMD and/or UserPort.
|
|||
|
29 Jan 2008, 05:01 |
|
|
f0dder 29 Jan 2008, 09:45
AlexP: try reading what the poster wrote.
System86: if you want 64-bit support, you'll probably have to write a driver after all - at least the IOPL trick doesn't seem to work for me under XP64. |
|||
|
29 Jan 2008, 09:45 |
|
|
DJ Mauretto 29 Jan 2008, 11:49
Hi
Here there is a small example that i wrote some time ago 
Note: You must first of all 'Act as part of the operating system',thus START / RUN type gpedit.msc follow this tree Local Computer Policy Computer Configuration Windows Settings Security Settings Local Policies User Rights Management then to the right search the string 'Act as part of the operating system' and type your user account,restart your pc or logoff and logon, Have Fun !!! 
NB: This file is too big , i will delete within some days, note further that i coded it in MASM  |
|||
|
29 Jan 2008, 11:49 |
|
|
f0dder 29 Jan 2008, 12:33
Hm, why is "act as part of the operating system" required? Not really a good idea to enable that for your accounts.
|
|||
|
29 Jan 2008, 12:33 |
|
|
DJ Mauretto 29 Jan 2008, 12:46
Quote:
Better way to do all IN/OUT is a driver under NT system,further you can benefit of RING0 ,this is only a fast alternative way ,i use sometime to test hardware without write eveytime a boring driver. About if 'act as part of the operating system' is required ,i don't know mailing this question to Microsoft,maybe them know it better than me |
|||
|
29 Jan 2008, 12:46 |
|
|
System86 30 Jan 2008, 00:35
Quote:
But UserPort and KMD are drivers. Using NtSetInformationProcess, you don't need any driver, you can just set the IOPL and do all the port I/O you want. BTW, Linux has some int 80h system call as well that lets you set the IOPL. Setting the IOPL does not let you do everything related to I/O, though. True, you can access ports and cli/sti. However, you don't automatically gain access to memory-mapped I/O addresses or are able to create ISRs. |
|||
|
30 Jan 2008, 00:35 |
|
|
revolution 30 Jan 2008, 01:04
System86 wrote: ... the undocumented internal function NtSetInformationProcess ... I don't understand what you have against drivers. The interface is documented and easy to understand. |
|||
|
30 Jan 2008, 01:04 |
|
|
f0dder 30 Jan 2008, 10:06
revolution wrote:
NtSetInformationProcess is easier to use for quick tests, but I agree with you fully; it shouldn't be used for production code. _________________  - carpe noctem |
|||
|
30 Jan 2008, 10:06 |
|
|
calpol2004 30 Jan 2008, 11:42
I think he's just trying to build highly optimized code, and by going straight to the hardware he doesn't haven't to rely on the OS or drivers being 100% efficient or have the overhead of your message being passed like a baton from application to OS to drivers to hardware. I don't know what standards drivers are made to these days, probably built in C++ or maybe C if we're lucky so naturally even with the best high-level programmers in the land there's going to be some innefficiencies.
i found it interesting anyway, not having to use the windows API to access hardware may be quicker and easier in some cases, but by no means portable or even stable. But not everyone is building software for public use anyway. |
|||
|
30 Jan 2008, 11:42 |
|
|
f0dder 30 Jan 2008, 11:47
calpol2004: accessing hardware directly while running under an operating system is a pretty bad idea, and you don't really gain any speed from doing it. In fact, since you can't handle IRQs etc. from usermode, you'd end up with slower speed.
Doing it can be OK for initial tests, though, but nothing more than that. And driver overhead isn't that bad considering how slow the IN/OUT instructions are and how much time you will spend waiting for the device |
|||
|
30 Jan 2008, 11:47 |
|
< Last Thread | Next Thread > |
Forum Rules:
|