So much effort, only to realize something :P

Index > Windows > So much effort, only to realize something :P

Author

Thread

StakFallT

Joined: 19 Jan 2006
Posts: 50

StakFallT 26 May 2006, 06:41

<Original sections cut out to reduce post size. This was due as per the next post which shows this section was no longer needed.>

Question 1: A question of implementation.. Ok so right now, here's how it's utilized.. This guy's vb program (which his source comes with the zip file) contains a simple form with 2 buttons with the caption hook and unhook. The both call a function within the testpatch.dll... More specifically this code (It's in MASM syntax so I appologize, but as I said I'm not sure if fASM can do DLLs, and if it can I'm not sure how)

Declaratives just so you guys have them if you need em
NOTE: Some are left out to avoid a really lengthy post!

Code:

sFunctionHook struct 
        hFuncName DWORD ?
        hHookFunc DWORD ?
        ordinal DWORD ?
        OrignalFunc DWORD ?
        iDefault BOOL ?
sFunctionHook ends
sDllHook struct
        DllName DWORD ?
        sHook sFunctionHook <>
sDllHook ends


PointerToPEHeader proto :DWORD
HookAPICall proto :ptr sDllHook
RedirectIAT proto :ptr sDllHook,:DWORD,:DWORD

;Our replacement function
MyMessageBoxA proto :DWORD,:DWORD,:DWORD,:DWORD
MyCryptProc1 proto :DWORD,:DWORD,:DWORD,:DWORD,:DWORD

.data
NoDosSig        db      "Dos signature not found! Invalid PE File.",0
InvalidPE       db      "Unable to determine location of PE Header!",0
NoImportAddr db "No imports in this module.",0
MsgError        db      "Gerneral Error",0 ;

;the DllName that has the function when want to redirect
DllStr  db "USER32.dll",0
DllStr2     db "ADVAPI32.DLL",0

;function name that we want to redirect
FuncStr db "MessageBoxA",0
CryptFuncStr1 db "MyCryptProc1",0

TestTitle db "MessageBoxA Hooked",0
TestMessage db "testing 1234",0
ImIn db "Dll attached!",0

MemWriteError db "Unable to change access attributes on memory.",0

ModLoaded db "Module Loaded",0

.data?
patchBool DWORD ?
szDllName db 256 dup(?)
szFuncName db 256 dup(?)
TestHook sDllHook <>
TestHook2 sDllHook <>
CryptHook1 sDllHook <>

hModule DWORD ?
pNTHeader DWORD ?
tempstr db 512 dup (?)
hDll DWORD ?
hHook DWORD ?
thismodule db 1024 dup (?)

InstallHook Proc

Code:

InstallHook proc
        invoke SetWindowsHookEx,WH_CBT,HookProc,hDll,0
        mov hHook,eax
        ret
InstallHook endp

HookProc Proc

Code:

HookProc proc nCode:DWORD,wParam:DWORD,lParam:DWORD
        
        invoke CallNextHookEx,hHook,nCode,wParam,lParam
        ret

HookProc endp

LibMain Proc

Code:

LibMain proc hInstDLL:DWORD, reason:DWORD, unused:DWORD
        .if reason == DLL_PROCESS_ATTACH
                ;save Instance, we are going to need it later
                push hInstDLL
                pop hDll
                ;get module hanlde of process were in
                
                
                        invoke GetModuleHandle,NULL
                        mov hModule,eax
                        
                        
                        lea edx,DllStr
                        mov TestHook.DllName,edx
                                         
                        lea edx,FuncStr
                        mov TestHook.sHook.hFuncName,edx
                
                        ;this is not implemented yet
                        ;mov TestHook.sHook.ordinal,32
                
                        ;set idefault to false,because we are going to use our own, ill change this later
                        mov TestHook.sHook.iDefault,FALSE
                        ;move our replacement function into hHookFunc
                        mov TestHook.sHook.hHookFunc,MyMessageBoxA
                        ;Hook the API call 
                        ;invoke MessageBox,NULL,addr ImIn,addr MsgError,MB_ICONERROR
                        invoke HookAPICall,addr TestHook


                  ;Hook all the coded in Crypt Functions
                  lea edx,DllStr2
                  mov CryptHook1.DllName,edx
                  lea edx,CryptFuncStr1
                  mov CryptHook1.sHook.hFuncName,edx
                  mov CryptHook1.sHook.iDefault,FALSE
                  mov CryptHook1.sHook.hHookFunc,MyCryptProc1
                  invoke HookAPICall,addr CryptHook1

                  invoke GetModuleFileName,NULL,addr thismodule,1024
        
                  ret
           
        .elseif reason == DLL_PROCESS_DETACH
                ;were going to set the API back to normal
                mov TestHook.sHook.iDefault,TRUE
                mov CryptHook1.sHook.iDefault,TRUE

                ;UnHook the API
                invoke HookAPICall,addr TestHook
                invoke HookAPICall,addr CryptHook1

;<blah blah insert routines that locate the area of memory to patch...>

MyMessageBoxA proc p1:DWORD,p2:DWORD,p3:DWORD,p4:DWORD
        ;show a message to let us know we succeeded
        invoke MessageBox,NULL,addr TestMessage,addr TestTitle,MB_OK
        
        ;push all the info back on the stack
        push p4
        push p3
        push p2
        push p1
        ;call the original function
        call TestHook.sHook.OrignalFunc         
        
        ret

MyMessageBoxA endp


MyCryptProc1 proc p1:DWORD,p2:DWORD,p3:DWORD,p4:DWORD,p5:DWORD
    invoke CryptAcquireContext,p1,p2,p3,p4,p5
    ret
MyCryptProc1 endp

Ok at this point the problem probably isn't very obvious.. So basically in crude ascii flowline it goes like this

App intiates API patch by using the called InstallHook proc -> This calls HookProc (via a SetWindowsHookEx param) -> which calls CallNextHookEx

Now..

App calls MessageBoxA-> MyMessageBoxA routine is ran -> return control back to user

So let's say I load up my vb program (app2) with a few listboxes, the first lists the api, and each listbox after that is the parameters passed to it, and the last listbox is the return value.. App2 issues the InstallHook function and the API is now patched.. Then I run app1...

App1 issues a cryptographic api.. The routine we patched into memory is now fired. Control returns back to App1

Even though App1 called the API my goal is to have the routine we patched into memory return back a value to the vb program before returning control back to App1.. almost like a SomeVariable = SomeFunction() but like in the form of
addr SomeFunctionInMemory() stores values into SomeVariableInApp2 before returning to App1 with value

And even if we come up with an idea on how to pass a value back to some outside app, how does calling the API (like the messagebox bit above) not cause some kind of recursive loop..
like api A is patched with B
A is called B runs instead.. but B calls A... == recursive loop?? Doesn't seem that way though in the above bit with the messagebox

(Btw, I read the replies to the original thread, and yeah all of it helped, thanks guys!! I think I'm super close to getting this at least functional, if it turns out better than my demoscene demo, which is completely broken and needs a total rewrite, I'll upload it)

-- StakFallT

Last edited by StakFallT on 28 May 2006, 22:50; edited 1 time in total

26 May 2006, 06:41

StakFallT

Joined: 19 Jan 2006
Posts: 50

StakFallT 28 May 2006, 22:43

Ok I'm apparently blind, because I did a search on yahoo and found there is an example that comes with fASM that tells how to make a DLL..

So ok now that I have that answered I still need some kind of way for the routine that I patch into memory to tell an outside program the api and parameters that was just called before returning back control to the program that did the calling.. One thought I had was maybe like sendkeys or sendmessage or something to the process id of this "outside program"..

How does calling the api that was patched from the routine that was in patched in, not cause a recursive loop?? It doesn't seem to as I've ran the hook and triggered the messagebox hook, so it's working ok, just I'd like to know how come it doesn't loop overr and over for the sake of knowledge..

-- StakFallT

On a side note, maybe this has been done before but I kinda a theory on something, curious if it plausible.. Were writting on r3 inside whatever asm compiler for windows it is that were writting in (weither it be masm or fasm, etc), there exists a -large- amount of native api calls.. Almost all of these start with Rtl<rest of name here> (Not sure what rtl stands for..).The theory I had is: would it be possible to path a -native- api call to get to r0 allowing you to work on r0 without having to write a vxd? Like some sort of developer interpreter that allows you to pass asm calls to the routine you patched in as parameters and the routine issues them?

28 May 2006, 22:43

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20337
Location: In your JS exploiting you and your system

revolution 29 May 2006, 01:05

Using native API's won't help you get to ring0. They are not magic, they simply offer a standard interface to perform the OS functions. RTL* and ZW* function are not documented so input parameters and constants change between OS versions and sometimes between OS builds of the same version, you are best to stick with the normal documented functions, they give you the same functionality and better portability to other versions/builds.

29 May 2006, 01:05

okasvi

Joined: 18 Aug 2005
Posts: 382
Location: Finland

okasvi 29 May 2006, 06:12

Rtl=RunTimeLibrary, Zw*'s are exported by ntoskrnl.exe and used in driver developement. Four-F has converted most(all?) of DDK(driver developement kit) for masm.

There is complete code posted to get r0(xp sp2 atleast) here in board.

29 May 2006, 06:12

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum