PDA

View Full Version : A question about Ollydbg lugins


Hero
March 31st, 2007, 06:59
Hi all
In plugin api help of ollydbg,it says that ODBG_Pluginmainloop is called in each cycle of debuuging.
But I notice it will only call if you go step by step, and don't use run.
How I can analyse code step by step when somebody runs code?

Regards

blabberer
March 31st, 2007, 11:06
odbg_pluginmain loop is called on every DEBUG_EVENT when you are running it there is no DEBUG_EVENT it is simply running

Quote:

How I can analyse code step by step when somebody runs code?


could you be more specific (doesnt run trace , hit trace etc suit your needs ?)

if you use hit trace and/or runtrace your plugin uses odbg_pluginmainloop
your plugin will be getting called on each single step thats being executed

Hero
March 31st, 2007, 11:24
Here is what I want to do:
I writing an call logger(For API,...),then I should somehow detect all execution of calls.
When it is happening step by step when somebody presses F8 or F7 there is no problem and I can check it completely,but when somebody presses F9 program run and there is no ODBG_Pluginmainloop calling,then I can't log calls.
I don't know what I should to do when somebody presses F9.
Any idea?

Regards

blabberer
April 2nd, 2007, 02:09
you are logging thats fine
so if you want to log then your logger should get called

so this implicitly means you have to hook something

there are several methods and all of them at some point require the foreign code to signal an event

you can enumerate all and every functions that could be called and insert trampoline on its entry point to call your logger and let your logger resume the original

if you want to follow this method take a look at microsofts Detour
or iirc madshi has a delphi implementation of detour

the above method has a flexibility of being stand alone (no need for debugging the target

you can inject your logging code into all the process with many techniques
the most easist that come to my mind is Appinit key in registry

if you want to utilise debugger then you have to make sure that when ever an event of your choice happens you trigger a DEBUG_EVENT

to actualize this you can as in the above detour logic enumerate all the calls
but instead of trampolining you can insert a breakpoint on all the calls
so when ever they get hit

your handler (in your present case ODBG_PLUGINMAINLOOP() gets called)

you can log what you wish decide to keep this breakpoint or not etc etc
when you finished return control back to where it stopped with a DBG_CONTINUE or may be even with a GO( STEP_SAME) api from ollydbg plugin apis

simply wanting to log something without any associated event is not feasible or practically possible

Hero
April 3rd, 2007, 00:21
Hi
Quote:
if you want to follow this method take a look at microsofts Detour
or iirc madshi has a delphi implementation of detour

I were known about detour but I never test it yet and I don't know if it can be usefull when you don't know which API will be called.

Quote:
if you want to utilise debugger then you have to make sure that when ever an event of your choice happens you trigger a DEBUG_EVENT

I think this one has a same problem like previous one,for example:
Code:
myDLL db "kernel32.dll",0
myAPI db "GetCurrentProcessId",0
...
push myDLL
call LoadLibrary
push myAPI
push eax
call GetProcAddr
call eax
...

now how we can log this calling of GetCurrentProcess?you see that call eax is this call,but I don't know how I can log it,and i think this problem is a common one between both of those solutions.what do you think for this one?

Quote:
you can inject your logging code into all the process with many techniques
the most easist that come to my mind is Appinit key in registry

I should say that I don't know this key and what it doing,I will google it for now...

Regards

blabberer
April 3rd, 2007, 01:57
Quote:

now how we can log this calling of GetCurrentProcess?you see that call eax is this call,but I don't know how I can log it,and i think this problem is a common one between both of those solutions.what do you think for this one?


if you are using detours and or break points you are not supposed to deal with any code in the exe at all you are supposed to deal with sytem dll
for example in the above process you are supposed to trampoline the exact procedure in kernel32.dll so that you get control of it when it is called by any methods

Code:

004AFFE6 E8 6A0A3B7C CALL 7C860A55 ; kernel32.GetProcessId
004AFFEB 68 550A867C PUSH 7C860A55
004AFFF0 C3 RETN
004AFFF1 B8 550A867C MOV EAX,7C860A55
004AFFF6 FFD0 CALL EAX
004AFFF8 -E9 580A3B7C JMP 7C860A55 ; kernel32.GetProcessId



if you pursue logging from the actual exe then you haveto enumerate all calls
either vial GetAllCommands
call R32
Code:

Found commands
Address Disassembly Comment
00401000 JMP SHORT 00401012 (Initial CPU selection)
004353E7 CALL EBX
004353FA CALL ESI
0043543B CALL EDI
00435615 CALL EBP
0043C7D8 CALL EAX
00454CBF CALL EBX
00454CCC CALL ESI
0045FB11 CALL EAX
004751AA CALL EDI
00475B97 CALL EAX
0049110E CALL EAX
00491164 CALL EAX
0049121A CALL ESI
00491320 CALL EBX
00491556 CALL EAX
00491600 CALL EBX
00491772 CALL EAX
004961DD CALL ECX
00496649 CALL EAX
00496853 CALL EBX
004969C7 CALL EDI
00496C93 CALL EBX
00496CD6 CALL EAX
004A252D CALL EDI
004A43D8 CALL EAX
004A442D CALL EAX
004A5FA0 CALL ESI
004A5FAD CALL ESI
004AC280 CALL EAX
004ACF8F CALL ESI
004ACFAC CALL ESI
004AD0A5 CALL EAX
004AEE9C CALL EDI
004AFFF6 CALL EAX

JMP DWORD PTR DS:[CONST] ETC

OR PARSE e8 e9 ff25 byte sequence and put a bp on there
etc


Found commands, item 0
Address=004AA228
Disassembly=JMP DWORD PTR DS:[4CC468]
Comment=OLLYDBG.004AA240


Hero
April 3rd, 2007, 03:48
Hi blabberer
Thanks for quick reply.
It seems using using detour will be better than other choices.
But for the last question:
Some protections like armadillo's AntiBP algorithm checks API function to detect tampering.
If I use detour,it will be detected using armadillo's AntiBP,isn't it?if yes,is there any way to prevent it?

Regards

blabberer
April 3rd, 2007, 10:22
let alone protectors
many of the latest aggressive antivirus will not let you tamper in first place

they tamper themselves and keep other rogue tamperers out of the door

well no methods availble if you are talking about simple solutions

but some laws called newtons third or fifteenth law still hold sway

every action has its equal and opposite reaction

so every detection has an equal and opposite antidetection is a derivative of that law