hi every one.
i want to protect my process (some virus try to injection a DLL to my process), is there any good way to protect my process from injection (CreateRemoteThread, Hooking ....) ?
thanks very much.
Posted on 2008-05-10 06:50:08 by secmask
This api only available to privileged user.
Reduce user privilege and api wont work.
Posted on 2008-05-10 09:17:12 by Homer
1. hum, but the virus is infected to system services and run as system user !!!
2. what about system wide hook ? can i prevent them ?

thanks.
Posted on 2008-05-10 20:38:18 by secmask
You should be able to make *suspiciousfunctions* fail by using a kernel mode driver which intercepts these *suspiciousfunctions*. AFAIK, these is no other clean way. Antivirus programs usually install processes that track process/thread creations, disk I/O, internet downloads, etc. and act if they find *suspiciousactivities* described in their databases. Additionally, antiviruses use sophisticated algorithms to detect malicious activities (Symantec calls it their "Bloodhound" system) - they can detect malicious codes based on many complicated things ;)

So, in short: I don't know any clean & easy way to prevent injections except asking the user to be logged in without any priviledges.
Posted on 2008-05-11 09:44:15 by ti_mo_n
there's plenty more methods to remote process code injection than just createremotethread...

what is it you're trying to do? more detail helps
Posted on 2008-05-11 17:32:04 by evlncrn8
You can remove the debug privilege from your process, even admin users won't be able to CreateRemoteThread then, once your process is running (of course that can be circumvented by a driver, or by using a loader to load your program). World Of Warcraft does this, for instance.

If you want to do this for software protection, though, give up already - crackers know how to circumvent this protection :)
Posted on 2008-05-11 18:05:23 by f0dder
hi f0dder, what do you mean "remove the debug privilege" ? , i see that we can only enable or disable privilege, and the default is disable for normal process, but they still be infected by CreateRemoteThread.
There some virus try to inject a DLL(or more) to many other process, so its difficult to remove them.
the DLL do something like:

 while(true){
        do purpose action ......
        ...............................
        ...............................
        check for new process, CreateRemoteThread if need.
        check if not in startup list, make new registry key to make this ....
}


one of them is Worm.Win32.Otwycal.q , i want to protect my process first, then will do some actions to clean the system.
Posted on 2008-05-12 10:36:27 by secmask
The debug privilege is a USER privilege which is inherited by your processes.
You need to edit the permission for the USER ACCOUNT.
That's what I originally meant when I said that the api only worked if the user account had sufficient privilege.
The problem really is that most user accounts are running with Administrator privilege, and by default, Administrator has debug privilege enabled.
Posted on 2008-05-12 23:43:58 by Homer
ok, seem to be that impossible to do my program on windows :P
thanks all.
Posted on 2008-05-13 05:11:32 by secmask
You give up too easily :)
Posted on 2008-05-13 06:17:12 by Homer

You give up too easily :)

:P , just the thing i think after the replies (to say don't let me give up  :D)

@Homer: you have a suggest ? , any google keyword ?
thanks.
Posted on 2008-05-13 07:17:25 by secmask
Homer, even if the user has DEBUG privilege (ie., administrator accounts), the DEBUG privilege can be removed per-process. I have some pretty ugly code lying around that does it, but I'm not sure it should be posted here - and it should definitely be cleaned up beforehand if it should.
Posted on 2008-05-13 08:26:14 by f0dder
Here's what you need,

AntiHookExec Algorithm

This code works as follows:
Manually read ntdll.dll and kernel32.dll into memory using CreateFile, ReadFile APIs. Make sure they are properly aligned to the specified memory alignment. Henceforth, these two manually loaded images shall be called the file images. The memory images of ntdll.dll and kernel32.dll as mapped in by the OS shall be called the memory images.

Iterate through all the APIs exported by ntdll.dll and kernel32.dll using the Export Table of the file images. For each API exported, perform Instruction Length Disassembly to get a rough estimate of the function length (N). Compare the first N bytes of each API using the file images and the memory images. Any discrepancies between them would indicate that the particular API have been hooked using the second technique described above.

Restore each hooked API by copying the relevant bytes from the file images to the memory images.

Iterate through the Import Address Table (IAT) of kernel32.dll. For each imported API address from ntdll.dll, check that it has not been modified. Any modified IAT entries of kernel32.dll will be restored using the disk images.

Obtain the API address of CreateProcessA using the disk image of kernel32.dll. This ensures that any modifications to our IAT won't affect us.

Execute the specified EXE using CreateProcessA.


Usage

AntiHookExec.exe <exe filename>

This program will attempt to rid itself of userspace API hooks and execute <exe filename>

The following steps will be taken.
API Restoration. This program will attempt to detect any changes to the memory image of ntdll.dll by comparing it against the disk image. If there are any changes, the memory image will be patch by referencing the disk image.

Import Table Restoration. This program will attempt to restore the import tables in the memory image of kernel32.dll by comparing it against the disk image.

Obtain the memory address of CreateProcessA using the disk image of kernel32.dll, and use this address to execute <exe filename>

Limitations

The following are some limitations of this proof-of-concept code.
The system-wide API hooking program has not hooked ReadFile API, and cause it to return a falsified disk image of kernel32.dll and ntdll.dll.
The system-wide API hook has not disabled VirtualQuery and VirtualProtect APIs.
This program will not work against kernel-space rootkits.
This program will also not work against API hooks that are installed using SetWindowsHookEx.

Not written by me, I found this in my code db.
I would post again when I will recode it overcoming the limitations listed above.

Attachments:
Posted on 2008-05-13 13:22:50 by shakuni
Interesting piece of code, but not something I would use in production - there's so many opportunities for it to break, or at least trigger malware protection software. Also, it doesn't help you against attaching later on and insert threads, read/writeprocessmemory etc.
Posted on 2008-05-13 17:45:51 by f0dder

Interesting piece of code, but not something I would use in production - there's so many opportunities for it to break, or at least trigger malware protection software. Also, it doesn't help you against attaching later on and insert threads, read/writeprocessmemory etc.



yes, i mean that include read/write process --> to protect process from modifying of others in the final.
Posted on 2008-05-13 21:06:01 by secmask
Interesting piece of code, but not something I would use in production - there's so many opportunities for it to break, or at least trigger malware protection software. Also, it doesn't help you against attaching later on and insert threads, read/writeprocessmemory etc.

I would keep these things in mind while I am working on a better variation of this.
Thanks.
Posted on 2008-05-14 00:44:07 by shakuni
"Any discrepancies between them would indicate that the particular API have been hooked using the second technique described above."

erm, what about hotfixes / other 'safe' programs that might hook etc.. like window blinds and so on.. basically you're creating a rule of thumb here and taking it as gospel.. where it may not be so...

i also think you're looking in the wrong direction.. protect your code from the inside out..... a well designed/protected program using anti*, obfuscation, self tracing and so on would be a better approach, the createremotethread, then can only realistically be used to hook / subvert api's, which can be done from ring 0 anyway (which your ring 3 program wont see)...

a truly determined cracker will find a way into your process, that much is pretty much guaranteed...

and using any api will be your weakness...

you meantion using createfile to access kernel32 / ntdll / whatever, then load them into memory..
what if i hooked createfile to give you my 'modified' kernel32 with the hooks in it which would match up in your checks...
therby making you checks useless...

any program using api's has its vunerabilities in the api's.. now there's no way you will manage to make an 'api less' method for loading a file... so i'd really forget the approach you're using (its a waste of time and effort)...

so nice idea sure.. totally flawed by the fact you use api's which the cracker could hook and use to make your method totally useless...
Posted on 2008-05-14 03:59:25 by evlncrn8
Hello, this is my first post, so bear with me.

  Would it be possible, by keeping a checksum, of the process, we could detect the CreateRemoteThread() technique?
  Acessing PEB, iterating through the linked list, of loaded dlls, would first of detect the CreateRemoteThread()&LoadLibrary(), at very least... now, to detect CreateRemoteThread() alone, would it be possible, to periodically check the process checksum?!
  I know this would be a cumbersome of a solution, but i cannot phatom other than, obviously, patch the CreateRemoteThread() ourselfs.... but, ain't this malware too ? lol
Posted on 2009-04-02 06:36:19 by taradinhu
Nevermind... as soon as I hit "Post" i remembered, that even patching CreateRemoteThread, there must be some Zw* function, that only on kernel mode... Driver mode only, no?
Posted on 2009-04-02 06:41:05 by taradinhu