IOPLto3

[Ficko]

Hi guys!  :bg

I need some expert advise if any. ::)

I used to set the IOPL to 3 with the following subroutine.

It works great on 32-bit systems however it breaks on 64-bit system.

Any idea what could be changed to get it work eventually?

Code Select Expand


.nolist
.686p
include \masm32\include\masm32rt.inc
include \masm32\include\advapi32.inc
include \masm32\include\ntdll.inc
include \masm32\macros\ucmacros.asm
; ---------------------------------------------------------------------------
extern ProcHeap:DWORD
; ---------------------------------------------------------------------------
TOKEN_ADJUST_PRIVILEGES equ 20h
TOKEN_QUERY equ 08h
SE_PRIVILEGE_ENABLED equ 02h
POLICY_CREATE_ACCOUNT    equ 10h
POLICY_LOOKUP_NAMES      equ 800h
ANYSIZE_ARRAY            equ 1
STATUS_SUCCESS equ 0
TokenUser equ 1
GPTR equ 40h
; ---------------------------------------------------------------------------
LSA_OBJECT_ATTRIBUTES STRUC
Lengt dd ?
RootDirectory dd ?
ObjectName dd ?
Attributes dd ?
SecurityDescriptor  dd ?
SecurityQualityOfService dd ?
LSA_OBJECT_ATTRIBUTES ENDs
LSA_UNICODE_STRING STRUC
Lengt dw ?
  MaximumLength dw ?
Buffer dd ?
LSA_UNICODE_STRING ENDs
; ---------------------------------------------------------------------------
.const
SeTcbPrivilege db  "SeTcbPrivilege", 0
WSTR SeTcbPrivilegeW ,"SeTcbPrivilege"
.code
;$command SetIOPLto3(),UINT
; =============== S U B R O U T I N E =======================================
SetIOPLto3 proc near public
LOCAL _TOKEN_PRIVILEGES :TOKEN_PRIVILEGES
LOCAL _LSA_OBJECT_ATTRIBUTES:LSA_OBJECT_ATTRIBUTES
LOCAL _LSA_UNICODE_STRING :LSA_UNICODE_STRING
LOCAL PHandle :DWORD
LOCAL hToken :DWORD
LOCAL Cproc :DWORD
LOCAL PSid :DWORD
LOCAL Lenge :DWORD
LOCAL Error :DWORD
LOCAL IOPL :DWORD
invoke RtlZeroMemory, ADDR IOPL, sizeof TOKEN_PRIVILEGES + sizeof LSA_OBJECT_ATTRIBUTES + sizeof LSA_UNICODE_STRING + 28
mov byte ptr IOPL, 3
mov _LSA_UNICODE_STRING.Buffer , offset SeTcbPrivilegeW
mov _LSA_UNICODE_STRING.Lengt , sizeof SeTcbPrivilegeW - 2
mov _LSA_UNICODE_STRING.MaximumLength , sizeof SeTcbPrivilegeW
invoke LsaOpenPolicy,0,ADDR _LSA_OBJECT_ATTRIBUTES,POLICY_CREATE_ACCOUNT or POLICY_LOOKUP_NAMES,ADDR PHandle
.if (eax == STATUS_SUCCESS)
invoke GetCurrentProcess
mov Cproc, eax
invoke OpenProcessToken,Cproc,TOKEN_ADJUST_PRIVILEGES or TOKEN_QUERY,ADDR hToken
.if (eax != 0)
invoke GetTokenInformation,hToken,TokenUser,0,0,ADDR Lenge
.if (eax == 0)
invoke HeapAlloc, ProcHeap,GPTR,Lenge
mov PSid, eax
invoke GetTokenInformation,hToken,TokenUser,PSid,Lenge,ADDR Lenge
.if (eax != 0)
mov ecx, PSid
invoke LsaAddAccountRights,PHandle,[ecx],ADDR _LSA_UNICODE_STRING,1
.if (eax == STATUS_SUCCESS)
invoke LookupPrivilegeValueA,0,ADDR SeTcbPrivilege,ADDR _TOKEN_PRIVILEGES.Privileges.Luid
.if (eax != 0)
mov _TOKEN_PRIVILEGES.PrivilegeCount, 1
mov _TOKEN_PRIVILEGES.Privileges.Attributes, SE_PRIVILEGE_ENABLED
invoke AdjustTokenPrivileges, hToken,FALSE,ADDR _TOKEN_PRIVILEGES,0,NULL,0
.if (eax != 0)
invoke ZwSetInformationProcess,Cproc,16,ADDR IOPL,SIZEOF IOPL
mov Error, eax
.endif
.endif
.endif
.endif
invoke HeapFree,ProcHeap,0,PSid
.endif
invoke CloseHandle, hToken
.endif
.endif
invoke GetLastError
push eax
invoke LsaClose, PHandle
pop eax
or eax, Error
ret
SetIOPLto3 endp
end


P.S.

ProcessUserModeIOPL setting requires "SeTcbPrivilege"!!
Granting it to current account (admin rights required) takes effect after next login!

Description: Go into Administrative Tools\Local Security Policy\Local Policies\User Rights Assignment
and there select the "Act as part of the operating system" policy and add your local account.

[dedndave]

first, that is some dangerous code - lol
second, you probably need to make a manifest to run it on newer OS's

[Ficko]

first, that is some dangerous code - lol
second, you probably need to make a manifest to run it on newer OS's

Anything can be dangerous in wrong hands. :bg

I like to play with hardware before - or at all - developing a driver.
And this MS signature nightmare for drivers is just no go.

It runs on newer OS but it breaks somewhere propable because of  "Act as part of the operating system" on VISTA is hidden somewhere for a "super admin" or something. :dazzled:

[akane]

Hi Ficko, try with impersonation (see in Ebasic section) because iopl change may require more privileges than on XP.
By the way you don't need to enable TCB, you need only to have it (at least on XP).

[Ficko]

Thanks akane! :thumbu

"try with impersonation"

I will try it but I do not have too much hope since that one of the new protection mechanism by Vista that you can't just "impersonation" an admin.
VISTA has above Admin a "Super Admin" called something like the "Installer" that's the reason you can't easily modify system files etc. you have to take over the ownership first.

[Astro]

Hi,

Check you have security permissions to modify permissions!! Sounds crazy I know but some permissions can only be obtained at SYSTEM (seems SYSTEM is higher than Administrator).

There are also some permissions you can't obtain without having them already (yes, more craziness!).

Which permission do you require exactly?

Best regards,
Astro.

[Astro]

Is this correct?

LsaAddAccountRights

http://msdn.microsoft.com/en-us/library/aa374731(VS.85).aspx

I can't find it listed.

Which OS? XP or Vista?

Hmm... http://msdn.microsoft.com/en-us/library/ms721786(VS.85).aspx

The handle must have the POLICY_LOOKUP_NAMES access right.

...does it?

If the account identified by the AccountSid parameter does not exist, the handle must have the POLICY_CREATE_ACCOUNT access right.

What error code are you getting back from the function?

Example code using LsaAddAccountRights: http://msdn.microsoft.com/en-us/library/ms721863(VS.85).aspx

Best regards,
Astro.

[Ficko]

Is this correct?
LsaAddAccountRights
http://msdn.microsoft.com/en-us/library/aa374731(VS.85).aspx
I can't find it listed.

Yes it is:
http://msdn.microsoft.com/en-us/library/ms721786(VS.85).aspx

Code Select Expand


Which OS? XP or Vista?

The code above runs on XP & Win2000.
- I mean I never tryed the exact code above I usually use my own headers for such prgs since some MASM headers are incomplete or incorrect in kernel and security area.
I just added the MASM headers checked if it is compiles before posting it but didn't try.
It should work if I didn't make a typo or didn't have a buggy structure in one of the headers.-

I am trying to get it work on "Vista 64".
I do not have a "Vista 32" at hand but would be great if somebody could test it on it to further close in on the problem being an OS or CPU hardship.

Code Select Expand


What error code are you getting back from the function?

Thats a legitimate question. :P

STATUS_NOT_IMPLEMENTED   =>  0C0000002h
from "ZwSetInformationProcess"

See debugscreen attached.

This makes me wonder not trying to do something physically impossible.?! ::)
I am not a "CPU major" but if I am understanding "WOW64" the CPU is running 64-bit in Level 0 and 32-bit mode in Level 3 and "WOW" translates the API calls.
Maybe that's the reason you can not lower IOPL (increase the number) from a 32-bit application.

May it would work from a 64-bit application?! ::)

[dedndave]

besides virtualizing code - the registry is also virtualized
look at the regsitry for a hive named wow64 or something like that
i think it is meant to add a layer of protection from viruses etc

[Astro]

Is UAC enabled? If so, try disabling it. Maybe it is intercepting the call somewhere?  ::)

I've got Vista 64 bit here. If you tell me how I need to configure it and what I'm looking for, I'll try the code here.

The fact it is 64-bit shouldn't make any difference. If it is a Win32 function, it will be supported in the 64-bit version as well (otherwise 64-bit OS would break all 32-bit apps).

Best regards,
Astro.

[Ficko]

Thanks Astro!

Code Select Expand


If you tell me how I need to configure it and what I'm looking for, I'll try the code here.


As you can see on the debug screen - attached above - the code runs fine till the last call to "ZwSetInformationProcess", which should set the IOPL and return 0.
That's what you have to look for.
If it returns 0 your IOPL level is set to 3 that mains you can excecute privilaged level instructions like "out, in, cli,sti" in the calling process.

I use "HeapAlloc" to reserve some place above you can change it to "GlobalAlloc" if you don't have a process heap.

You have to set up your computer security rights like I wrote it above.

Go into Administrative Tools\Local Security Policy\Local Policies\User Rights Assignment
and there select the "Act as part of the operating system" policy and add your local account.

Even if there is "Administrator" allready present you should add it again. - and restart the computer -

Code Select Expand


The fact it is 64-bit shouldn't make any difference. If it is a Win32 function, it will be supported in the 64-bit version as well...


I am not sure about that one. :naughty:
See for example the api call "Beep".
It is not supported on 64-bit OS.

And the fact that I get "STATUS_NOT_IMPLEMENTED" suggest that MS left this status implementation from the call out for 32-bit enviroment
maybe because it is not possible to set IOPL level to the same as the IOPL level of priv.level 0 since priv.level 0 runs in 64-bit mode
but this is a question of the CPU architecture and I am not that good on that one. :red

Let me know how it goes. :wink
Ficko

[Astro]

Beep:

Windows Vista x64 and Windows XP 64-Bit Edition:  This function is not supported.

OK...  :red

but this is a question of the CPU architecture and I am not that good on that one.

Hmmm... *thinks*

A 32-bit program can't access 64-bit code and vice-versa (e.g. 32-bit EXE can't use a 64-bit DLL). If the level you are attempting to access requires to be 64-bit, then this could be the case.

Best regards,
Astro.

[dedndave]

64-bit OS's are VERY different from 32-bit, especially windows

[Ficko]

64-bit OS's are VERY different from 32-bit, especially windows

No question about that dedndave. :P

I think I have a conclusive evidence that this has nothing to do with the CPU.

It works on a 32-bit virtual machine hosted on a 64-bit OS!

From the viewpoint of the CPU a virtual machine is just an other 32-bit application isn't it? ::)

[Astro]

I just searched MSDN for ZwSetInformationProcess and got....one result that was to a blog.

Googling the issue further ("ZwSetInformationProcess vista")

http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.kernel/2006-06/msg00194.html

http://www.scribd.com/doc/3247626/Windows-2000-Native-API-Reference

^^ Go to page 138/139. There is no mention of the return code STATUS_NOT_IMPLEMENTED, so I can only presume this call is not supported in Vista.

I also can't find it in MSDN which suggests it has been *DELETED* as a function!!  :eek

How you are then supposed to write for a older OS when even the references are being REMOVED for apparently older API calls is interesting to say the least.

"ZwSetInformationProcess STATUS_NOT_IMPLEMENTED" yeilded few results.

Best regards,
Astro.