0

I am having trouble entering the extended function mode of the Nuvoton NCT6793D. The datasheet says to write 87h twice to to the regsiter 2Eh but on trying to do so I get an exception thrown by Visual Studio that the 3rd line is a 'privileged instruction'.

On looking it up online it is my understanding that this instruction can only be carried out in the kernel mode, but I cannot find any way to run my assembly code in kernel mode.

  .386
  .stack 4096
.
.
.
  main PROC
        mov DX,2EH
        mov AL,87H
        out DX,AL    <----
        out DX,AL
.
.
.

Is my only option writing a kernel mode driver?

Thank you in advance for your kind responses.

Rahul
  • 177
  • 3
  • 9

1 Answers1

2

Yes, out is a privileged instruction. It must be executed at Ring 0 (kernel mode).
The only way around this is making a driver, Windows has the Windows Driver Kit for developing drivers (it has all the tools and many examples).

There is an instruction to jump into privileged mode (more than one, actually) but of course you jump to an entry point in the kernel.
All these instructions are fundamentally a call to a specific routine, you cannot elevate your code or the OS would be totally broken.

I assume Windows is involved somehow, since you are using Visual Studio and x86 code, despite the title refers to an embedded machine.

Windows doesn't exposes a function to read/write the IO ports to user mode applications (for very good reasons).

Untested (or maybe tested but I don't remember)

I've found an old driver I wrote for reading IO ports, it exposes the "file" \Device\iomem_io which can be open, read and written as usual (CreateFile, ReadFile, WriteFile).
Reads and writes at offset X (see SetFilePointer) will read/write from/to port X, the size of the operation must be either 1, 2 or 4 bytes.

RWEverything comes with a driver that allows to read/write ports (and much more). It's commonly used by malwares that requires HW access, it is not documented and it is controller with IOCTLs (DeviceIoControl) codes that must be gathered from reverse engineering.

Note If you switch to Linux, you can use iopl to allow a user mode program to access the IO ports. That's great for debugging.

Community
  • 1
  • 1
Margaret Bloom
  • 41,768
  • 5
  • 78
  • 124
  • I know that Windows NT 4.x (maybe also Windows 2000) had a user-mode API that worked exactly (or at least similar to) `iopl()` in Linux. Maybe more modern Windows versions still provide that API. – Martin Rosenau Jun 26 '19 at 17:51
  • @MartinRosenau Interesting! do you happen to remember the name of the API? – Margaret Bloom Jun 26 '19 at 18:04
  • @MartinRosenau : In theory you can raise the IOPL to 3 to allow direct IO access with NtSetInformationProcess as long as you have Act as Operating system mode privileges (SE_TCB_PRIVILEGE). – Michael Petch Jun 26 '19 at 20:39
  • I forgot to mention, but as @MargaretBloom mentioned kindly, this is so easily achievable on Linux using the function `ioperm()` to set permission from `` followed by calls to `inb()` and `outb()` from ` to read and write from/to the ports. I just wish it was as simple on windows. – Rahul Jun 27 '19 at 02:36
  • @MichaelPetch I think that this is the API that I was using back then. – Martin Rosenau Jun 27 '19 at 04:32
  • @MartinRosenau In Windows 7, after allowing users access to SE_TCB_PRIVILEGE, NtSetInformationProcess with ProcessUserModeIOPL returns STATUS_NOT_IMPLEMENTED (0xc0000002). So it's not possible to set the IOPL anymore in Windows. I don't know the latest version supporting it. – Margaret Bloom Jun 27 '19 at 09:39
  • @MargaretBloom I was using **SHA Toolkit** (Sybera HW Access) to control my home-made equipment connected to LPT port: https://www.sybera.de/download/manual_can_e.pdf Having switched to 64bit Windows I had to give up that approach, however :-( – vitsoft Jun 27 '19 at 14:57
  • @vitsoft It's actually hard enough to find a computer that still has an LPT :) Anyway, the serial/parallel interface should be accessible in user mode IIRC. – Margaret Bloom Jun 27 '19 at 15:11