Data Execution Prevention

[Jimg]

So you are saying it doesn't work on Vista????

[ecube]

apparently this code will disable dep for the current process, can someone please test this? i'm not on sp2, the masm code I wrote below should be any Windows verison safe,crash wise, however when I tested it, it fails at NtCurrentProcess, it doesn't find it.

ULONG ExecuteFlags = MEM_EXECUTE_OPTION_ENABLE;

NtSetInformationProcess(
    NtCurrentProcess(),    // (HANDLE)-1
    ProcessExecuteFlags,   // 0x22
    &ExecuteFlags,         // ptr to 0x2
    sizeof(ExecuteFlags)); // 0x4

Code Select Expand


.386
.model flat, stdcall
option casemap: none

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\masm32.inc
include \masm32\include\user32.inc

includelib \masm32\lib\masm32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib

ProcessExecuteFlags equ 22h

IsXpSP2 proto
DisableDEP  proto

.data
ExecuteFlags db 02h
sznNtdll   byte 'ntdll.dll',0
szNtCurrentProcess   byte 'NtCurrentProcess',0
szNtSetInformationProcess byte 'NtSetInformationProcess',0
szSuccess    byte 'DEP disabled!',0
szFail   byte 'DEP not disabled',0
.data?
ntdll dd ?
NtCurrentProcessx dd ?
NtSetInformationProcessx dd ?

.code
start:
invoke DisableDEP
.if eax==1
invoke MessageBox,0,addr szSuccess,addr szSuccess,MB_ICONINFORMATION
.else
invoke MessageBox,0,addr szFail,addr szFail,MB_ICONINFORMATION
.endif
invoke ExitProcess,0

DisableDEP proc
invoke LoadLibrary,addr sznNtdll
cmp eax,NULL
je @failed
mov ntdll,eax
invoke GetProcAddress,ntdll,addr szNtCurrentProcess
cmp eax,NULL
je @failed
mov NtCurrentProcessx,eax
invoke GetProcAddress,ntdll,addr szNtSetInformationProcess
cmp eax,NULL
je @failed
mov NtSetInformationProcessx,eax

call NtCurrentProcessx
mov ecx,eax

push sizeof ExecuteFlags
push offset ExecuteFlags
push ProcessExecuteFlags
push ecx
call NtSetInformationProcessx

mov eax,1
ret

@failed:
xor eax,eax
ret
DisableDEP endp

IsXpSP2 proc
LOCAL os:OSVERSIONINFOEX
invoke GetVersionEx,addr os
.if os.dwMinorVersion==SDWORD PTR 1
.if os.wServicePackMajor==SDWORD PTR 3
mov eax,1
ret
.endif
.else
xor eax,eax
.endif
xor eax,eax
ret
IsXpSP2 endp

end start


[MichaelW]

NtCurrentProcess appears to be a macro, defined as:

#define NtCurrentProcess() ( (HANDLE) -1 )

So it would appear to be the value -1 cast to a HANDLE, and I think it is interpreted as meaning the handle of the calling process.

[ic2]

E^cube

I'm not sure how nt works but I looked under ntdll.dll with Dependency Walker and there is no  NtCurrentProcess API.  There is a NtCurrentTab.

From your notes it looks like this is under a structure and your code  is calling it from the dll.

I looked in window.inc and there is no structure for it.  Instead of continuing I better send this information to you.

ULONG ExecuteFlags = MEM_EXECUTE_OPTION_ENABLE;

Code Select Expand


;  ...................................     
    PUSH  offset szNtCurrentProcess
    PUSH  ntdll
    CALL  GetProcAddress

            cmp eax, NULL
        je @failed
                        mov NtCurrentProcessx, eax


;    ULONG ExecuteFlags = MEM_EXECUTE_OPTION_ENABLE

; NtSetInformationProcess(
;    NtCurrentProcess(),    //  (HANDLE)-1
;    ProcessExecuteFlags,   //   0x22
;    &ExecuteFlags,         //   ptr to 0x2
;    sizeof(ExecuteFlags)); //   0x4


; NTSYSAPI
; NTSTATUS
; NTAPI

; NtSetInformationProcess(
;
;  IN HANDLE                      ProcessHandle,
;  IN PROCESS_INFORMATION_CLASS   ProcessInformationClass,
;  IN PVOID                       ProcessInformation,
;  IN ULONG                       ProcessInformationLength );

On my XP ServicePack 2 ... The code will assemble then I get DEP not disabled

Just a few links I found trying to get some ideas.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1034817&SiteID=1

http://www.nynaeve.net/?p=189

http://www.reactos.org/pipermail/ros-diffs/2006-July/013310.html

[donkey]

NtCurrentProcess appears to be a macro, defined as:

#define NtCurrentProcess() ( (HANDLE) -1 )

So it would appear to be the value -1 cast to a HANDLE, and I think it is interpreted as meaning the handle of the calling process.

That's right, the current process handle is always -1 since it is a pseudo handle...

A pseudo handle is a special constant, currently (HANDLE)-1, that is interpreted as the current process handle.

Donkey

[ecube]

yeah apparently the code I posted requires certain circumstances to be into play, so for general use it doesn't appear to be vallid.

[hutch--]

ic2,

You will tend to find that most of these methods will be shut down over time for security reasons as the trojan/virus brigade have abused them for too long. It does not mean that you cannot design security methods, it just means you must change them for later OS versions.

With a single exe file you don't have all that many options as a traditional binary virus can modify the MZ/PE header before you reach the entry point but if you are designing multifile packages you can perform cute tricks like keeping an encrypted copy of the exe or at least parts of it and if the exe fails on a crc test or any oter you like, you trigger another app that normally cannot be started and patch the original exe back to original code.

basically you can capitalise on cross patching binary files before or after they are started in much the same way as a modern trojan uses the registry, delete one of the keys that it uses and it simply writes another one back in its place. You can do the same thing with binary files.

[ic2]

I'll delete this too.  It was nothing more than a joke anyway.  I'll just say it is not fair.

[Jimg]

Or you can just use VirtualProtect to unprotect your code segment.

[Rockoon]

Or you can just use VirtualProtect to unprotect your code segment.

..or stop the bad coding practice

[ic2]

I thought this thread was dead and gone to the google world....

..or stop the bad coding practice

It's all about hiding API calls and I been very clever about it so ... A protection plan is a protection plan and the ideas  here may now be in use by others so I delete this comment...

[hutch--]

ic2,

If you need to hide most of your API calls try LoadLibrary/GetProcAddress/FreeLibrary. In terms of protection it definitely makes them work hard to find what your code is doing. Fiddling with your PE header is becoming more and more difficult for security reasons, do this type of stuff and you have no security limitations and it works just as well.

Also have a look at a DEP capable exe compressor, PEcompact comes to mind, it makes them work even harder to find code and its very easy to do.

[ic2]

My original is good and I will fix it.  Your idea looks great, I'll include some of that too to make it better.

Thanks hutch

[ic2]

Now that I read it again,  it sounds even better.  It sounds too good not to use.

Thanks hutch

I'll help save Vista latter... right now it's back to the drawing board

[Rockoon]

I may be wrong but this seem to prove that the OS is manipulating the register and this is not the job of any OS and this is not doing programmers a  favor, do you think.

The OS isnt manipulating your registers.

You have a hard time explaining yourself. Try saying exactly and precisely what you mean.

I am replying to a message that describes taking the default value of EAX when your process starts (if not the default value, then you failed to explain where it came from) and does something with it. That is most definately bad programming practice.

I dont think that that is what you intended to say, is it?

You intended to describe what this value is derived from to begin with, where exactly you are storing it, how exactly it is being used later, and so forth.. right?