REGISTER
desert eagle
main menu

home

forums
    Show me new threads!

bookmarks

post article

view blogs

vault

you must be level 2 to upload files to your vault

downloads

you must be logged to access downloads

Rootkit Collection

File Contributer Link
Hacker Def... hfn/a
HE4Hook adminn/a
BASIC CLAS... hoglundn/a
Vanquish xshadown/a
NT Rootkit hoglundn/a
FU fuzen_opn/a
WinlogonHi... JeFFOsZn/a
klister joannan/a
Patchfinde... joannan/a
MyNetwork hoglundn/a
MTDWin hoglundn/a
NTFSHider hoglundn/a
VideoCardK... hoglundn/a
VICE fuzen_opn/a
Klog Clandestin...n/a
NtIllusion Kdmn/a
AFX Rootki... TheRealAph...n/a
SInAR vulndevn/a
Shadow Wal... Clandestin...n/a
BootRootki... dereksoede...n/a
CHAZ - Nim... neocrackrn/a
Clandestin... merlvingia...n/a
FUTo petersilbe...n/a
Windows Me... alcapone66...n/a
RAIDE petersilbe...n/a
BOOT KIT vipinkumarn/a
BluePill Joanna and...n/a
DEFRAG blume1975n/a
Keyboard H... chpien/a
CheatEngin... DarkByten/a

search the site

backends
A news back-end to implement RootKit news into your website is here or more advanced version here.

An XML/RSS feed that includes both NEWS and BLOGS for RootKit is here: XML/RSS.

[Valid RSS]

Beta feed for replied posts here. feedback to admins not forums, we know about times being off...

Shield from DLL-Injection
Jan 07 2007, 14:02 (UTC+0)
Opcode0x90 writes: Okay, actually this blog should entitled "Shield from code-injection". If you want to know why, read on.

This method was discovered when I was doing some random debugging. Sudden idea came to my mind when I inject some DLL into olly-debugged process. Olly log traced that one thread was created and terminated. Then I thought since the DLL loading takes place in user-mode, why cant I prevent it from loading by hooking some function ?

So I put a bp on kernel32.LoadLibraryA() and inject DLL again. ollydbg halted. I traced the stack frame to one function in kernel32.dll. I inject some DLL again, and yet I traced to the same function.

My sense tell me that is the function I'm looking for. So I began coding and hook that function. Voila, now Winject reports DLL-injection failed. But wait, our job is not done yet.

After more debugging I found that my hook was preventing the our own thread from creating too. So I need a method to distinguish rogue thread from our own thread.

Finally, I found a method used by Piotr Bania to prevent shellcode execution. He used VirtualProtect() to determine whether a code is rouge or not. Usually shellcode is injected as a result of stack-overflow or any other memory-based leak. These memory should be writable. If any pointer is pointing to a writable memory section, we can conclude that it is altered by the shellcode.

Yet, this method has a flaw. Most packer and protector modifies PE and mark the image as writable (to decompress or decrypt the content) and doesn't bother to restore them. It would raise false alarm when we use VirtualProtect() to check the protection. So I thought of a better solution.

I used VirtualQuery() to check for memory type. Usually when we create a thread, it should point to code within the image. (marked by loader as MEM_IMAGE) Any VirtualAllocEx() allocated memory would not have that flag set.

End of story, here goes the real stuff:



; ======================================================================= ;

.386
.model flat,stdcall
option casemap:none

include windows.inc

include kernel32.inc
includelib kernel32.lib

include user32.inc
includelib user32.lib

.data
; code signature for kernel32.BaseThreadStartThunk()
Signature BYTE 033h, 0EDh, 053h, 050h, 06Ah, 000h, 0E9h
;
; 7C810659 > 33ED XOR EBP, EBP
; 7C81065B 53 PUSH EBX
; 7C81065C 50 PUSH EAX
; 7C81065D 6A 00 PUSH 0
; 7C81065F ^ E9 E8AFFFFF JMP 7C80B64C ; kernel32.BaseThreadStart
;

; strings
szBusted BYTE "Busted", 0
szkernel32 BYTE "kernel32.dll", 0
szLoadLibraryA BYTE "LoadLibraryA", 0
szFreeLibrary BYTE "FreeLibrary", 0
szExitProcess BYTE "ExitProcess", 0

.data?
; address
Addr_LoadLibraryA DWORD ?
Addr_FreeLibrary DWORD ?
Addr_ExitProcess DWORD ?

Addr_BaseThreadStart DWORD ?
Addr_BaseThreadStartThunk DWORD ?

; you know
hModule DWORD ?
lpflOldProtect DWORD ?
.code

SigSeek_FindCode proc uses ebx ecx edx esi edi dwStart:DWORD, dwEnd:DWORD, lpSig:DWORD, dwSize:DWORD

;
; EBX = dwSize
; EDX = dwEnd - dwSize
;

; load the arguments into register
mov ebx, dwSize
mov edx, dwEnd
sub edx, ebx

; scan for specified signature
mov ecx, ebx
mov esi, dwStart
mov edi, lpSig
.repeat
; compare the string
repe cmpsb

.if zero?
; found the signature, return the address
mov eax, ebx
sub eax, ecx
sub esi, eax
mov eax, esi
jmp @f
.endif

; restore ECX, ESI, EDI registers
mov eax, ebx
sub eax, ecx
sub esi, eax
sub edi, eax
mov ecx, ebx

; move to next byte
add esi, 1

.until (esi == edx)

; return FALSE
xor eax, eax

@@:
ret

SigSeek_FindCode endp

Does_Something_Smell_Fishy proc lpStartAddress:DWORD

LOCAL lpMemInfo : MEMORY_BASIC_INFORMATION

; is the start address pointing to some fishy address ?
mov eax, lpStartAddress
.if (eax == Addr_LoadLibraryA) || (eax == Addr_FreeLibrary) || (eax == Addr_ExitProcess)
; obviously suspicious
mov eax, TRUE
jmp @f
.endif

; do a check on memory allocation type
invoke VirtualQuery, lpStartAddress, addr lpMemInfo, sizeof lpMemInfo

.if !(lpMemInfo.lType & MEM_IMAGE)
; hey, this thread isn't pointing to any loaded image, hmmmm
mov eax, TRUE
jmp @f
.endif

; no fish is found here
xor eax, eax

@@:
ret

Does_Something_Smell_Fishy endp

Hook_BaseThreadStartThunk proc

LOCAL lParam
LOCAL lpStartAddress

;
; EAX = lpStartAddress
; EBX = lParam
;

; save the parameters
mov lpStartAddress, eax
mov lParam, ebx

; does something smell fishy ?
invoke Does_Something_Smell_Fishy, lpStartAddress

.if (eax != FALSE)
; yeah, it smells
invoke MessageBox, NULL, addr szBusted, NULL, MB_OK

; kill this rogue thread
invoke ExitThread, NULL
.else
; jump to kernel32.BaseThreadStart()
xor ebp, ebp
push lParam
push lpStartAddress
push NULL
jmp Addr_BaseThreadStart
.endif

Hook_BaseThreadStartThunk endp

start:

; this wouldn't need any comments, eh?
invoke GetModuleHandle, addr szkernel32
mov hModule, eax

;
; scan for kernel32.BaseThreadStartThunk() signature from [base address] to [base address + 20000h] because it is not exported
;
; TODO: retrieve image size from PE, instead of using fixed image size value
;
mov ebx, eax
invoke SigSeek_FindCode, ebx, addr [ebx+20000h], addr Signature, sizeof Signature
mov Addr_BaseThreadStartThunk, eax

; extract the address of kernel32.BaseThreadStart() from jmp instruction
; destination = code location + jump offset + 5
mov ebx, [eax+7]
add ebx, eax ; / code location
add ebx, 6 ;
add ebx, 5
mov Addr_BaseThreadStart, ebx

; hook kernel32.BaseThreadStartThunk() function
invoke VirtualProtect, Addr_BaseThreadStartThunk, 5, PAGE_EXECUTE_READWRITE, addr lpflOldProtect

.if (eax != NULL)
invoke GetCurrentProcess
invoke FlushInstructionCache, eax, Addr_BaseThreadStartThunk, 5

mov edi, Addr_BaseThreadStartThunk
mov eax, offset Hook_BaseThreadStartThunk
sub eax, edi
sub eax, 5
mov byte ptr [edi+0], 0E9h ; jmp short
mov dword ptr [edi+1], eax

invoke VirtualProtect, Addr_BaseThreadStartThunk, 5, lpflOldProtect, addr lpflOldProtect
.endif

; get some function address
invoke GetProcAddress, hModule, addr szLoadLibraryA
mov Addr_LoadLibraryA, eax
invoke GetProcAddress, hModule, addr szFreeLibrary
mov Addr_FreeLibrary, eax
invoke GetProcAddress, hModule, addr szExitProcess
mov Addr_ExitProcess, eax

; we will see
invoke Sleep, INFINITE

ret

end start

; ======================================================================= ;
</pre>


Yet, this method only blocks out 80% of DLL-injecting tools that uses CreateRemoteThread(). Other method such as SetWindowsHookEx(), SetThreadContext() or code caving will work. That will take different approach to deal with.

No kernel is hurt during creation of this code. :)

Special Thanks to
- Piotr Bania,
- TiMBuS (I never knew that function has a name)

read comments (5) / write comment

recent comments:
shim engineautarky08.Jan:07:26
How about execute file?egeroo08.Jan:02:05
code formatting lostOpcode0x9007.Jan:14:06

printer-friendly version

login:
password:

ROOTKITS, Subverting the Windows Kernel
By: Greg Hoglund and Jamie Butler

Rootkits are powerful tools to compromise computer systems without detection. Get the original and best book on the subject here.


logged users

active for last 5 minutes

registered users:79912

There are currently 0 registered users and 22 guests browsing the website.

Welcome our latest registered user: Pris

recent board posts
subject author date
Hiding Tcp... _MAX_ Jul / 27
unload dri... dubteam2000 Jul / 26
APC Delive... aall87 Jul / 21
x64 SSDT h... lolwurst Jul / 21
password r... markedu9 Jul / 19
How to hid... Hack4freedom Jul / 15
UNC PATH A... pain_abator Jul / 15
CALL in na... _MAX_ Jul / 13
Conflict b... _MAX_ Jul / 08
Making dev... blackd0t Jul / 06
Hide proce... l0ngshot Jul / 01
Process Ha... krzys Jul / 01
Rooting VP... simplicityx Jun / 24
Rootkits: ... chimai Jun / 24
NDIS Inter... lclee_vx Jun / 17

recently replied posts
subject author date
x64 SSDT h... vrtulex Jul/27
unload dri... EreTIk Jul/27
Hiding Tcp... _MAX_ Jul/27
BIOS Rootk... rossettoecioccolato Jul/25
about this... DiabloNova Jul/22
APC Delive... aall87 Jul/21
password r... markedu9 Jul/19
UNC PATH A... pain_abator Jul/19
How to hid... vrtulex Jul/16
CALL in na... _MAX_ Jul/16
Hide proce... vrtulex Jul/10
Conflict b... _MAX_ Jul/08
Making dev... blackd0t Jul/07

recent blog entries
DiabloNova Jul 31, 12:06
ghost1369 May 09, 04:30
DiabloNova May 08, 15:33
_4epen May 04, 15:42
DiabloNova May 02, 03:59
Best Screenshots / Analog
May 14, 2010

dep.png /

click on the picture to enlarge and see description

!

read comments (0)
write comment

view archive(90) :

Analog(53) / Best Screenshots(37)

submit a picture to gallery

the most active news users
based on the number of news posts for last 30 days

user nr. of posted news

select skin



"I can't believe it!", says Luke.
"That is why you fail", responds Yoda.