Hi,
I would like to know if it's possible to log jumps or function calls with ollydbg? I've tried "Conditional Branch Logger" but cannot seem to find wingraph32.exe

It would assist me greatly if I could do this, as I will be able to compare success and fail scenarios to isolate the jump calls that determine the branching.

If not, what's the best way to approach this?

Thanks.

Hi,

OllyCallTrace shd help u with that.

http://www.harmonysecurity.com/OllyCallTrace.html

Doesn't log jumps though.

Thanks.

I tried the various plugins but didn't help me the way I wanted. I eventually settled on ollydbg 1.10 without any plugins, and used CTRL+K to show call stack.

It's not an ideal solution but it helped me quite a bit in showing the the layers of calls, so much so that after 2 hours, I managed to solve what I needed to get done.

Thanks again.

BK.

This is the exact intent of the "Conditional Branch Logger" that you mention above, so what was the problem with it, and what does wingraph32.exe have to do with it?

(btw, wingraph32.exe should be included with the free version of IDA Pro I think)

I tried "Conditional Branch Logger" but it was animating the run process (F9), as if animate-into was selected.

I eventually figured out where to find wingraph32.exe (included with the free IDA PRO download) . I was trying out another plugin that would visualise the call trace.

I'm looking for one myself aswell. The plugin I'm looking for needs to log jumps when I'm stepping through the code. Why do I need that? To make difference between same program under different conditions (7-days left, trial ended, registered version and so on).

You may also want to consider http://pedram.redhive.com/code/process_stalker (more info and screenshots at http://pedram.redhive.com/research/process_stalking)

First of all, this kind of "execution path diffing" was exactly why the Conditional Branch Logger plugin was created.

Remember that you can specify exactly which code areas that should be logged and not, and also when to start and stop the logging, so maybe you don't have to manually step through the code during this logging after all?

Otherwise, the following IDA plugin helps you keep track of where you single-stepped inside a program:

http://www.woodmann.com/collaborative/tools/CoverIt

It's also open source, and can easily be modified to log the coverage information in any format you like.

You should probably take a look at the tools in the following CRCETL category too:

http://www.woodmann.com/collaborative/tools/Category:Code_Coverage_Tools

Sorry to be stupid once again, but is there any good tutorial for Conditional Branch Logger since when I activate it and hit "Play", then it starts doing some weird stuff.

How would it be possible for me to run program normally with OllyDbg samewhile Conditional Branch Logger logs every jump taken or not?

If you want to interact with the program you must either activate the logging at the right spot, or be very patient, just like with any tracing-type analysis.

I just cannot understand. When I can write jumps taken or not on paper, then why isn't it possible to log it with program?

I might sound a little bit stupid, because I started assembling few weeks ago and following one tutorial. Just thought it would make my life easier, because I have "solved" many trials with installation logging (log files, register before installation and after, and after uninstall again, then compare).

If you want to logged any types of jumps, you must write a script. Script will be simulate pressing F7 or F8 and compare instruction eip and your condition of jumps. If compare good, it will be logged.
P.S.
Yet, speed trasing in this case will be slow. But all jumps will be logged. I'm think, this very good method. Learn olly script. It easy.

This is exactly what Conditional Branch Logger does, did you even read the posts above?

breakpoints are my favorite way to keep track of what i'm doing, or to go deeper and deeper into finding the right calls, but when i can't set breakpoints because the program is packed or im attaching to something, i use notepad.exe, simple but copying a line of code from the disassembler window could save you from redoing a number of steps or breakpoint setting

dELTA,

Much like this poster, I'm struggling quite a bit with CBL. I know it's a great tool, but I want to use it for essentially process stalking and I haven't figured out how to do it on a program that's in-process. It's great for if what I need to track is right up front but more comprehensive help or a tutorial would be very useful.

Sorry to bk_ for possibly hijacking, but let me explain: In a program like I'm working on now, one call block will call a bunch of other tiny ones. Which will each call a couple others. Which may each call more, some of which I don't even know because the calls are computed based on register manipulations before therm. This same program also has a "waiting for input" branch that it keeps going back to in the process of doing other things.

I want to use CBL to trace ALL of the jumps that arise following me hitting a menu button that leads down a specific, very long execution path. But I can't seem to do it - it traces EVERYTHING, and I don't know how to tell it to only trace the things that I need. Particularly since it seems I either have to allow huge blocks of code, or can only whitelist/blacklist certain routines because I don't know everything that's being called.

Let me take a look and I'll get back to you..

maybe you can post a snippet or a test program and explain what you are looking for more clearly so if i can squeeze out some time i can also try help with the requirement is the process u r looking at public domain or small enough to test by myself pm me if it is private domain but take note replies may take long enough time to come back

Hey look who came out of hibernation I'm glad you find the time to visit occasionally blabberer

What I was going to say was - I think the strategy to using CBL effectively would be similar to using the Olly Run Trace feature.

In the simplest situation, say you've got a Call with an unknown execution path below it. You set a BP on the Call, set a BP on the instruction after the Call (the return address), and execute the trace. With CBL you would click on Configuration and accept the default Included Range (the entire .text section).

As with Run Trace, it makes sense to limit yourself to smaller code blocks and "feel" your way through the execution path, rather than trying to digest reams of log data. With CBL you can select Excluded ranges within larger ones, for example if you find you get logs of conditional jumps in large loops or message queues which are of no interest. There are CBL context menus in each of the CPU, Executable and Memory map windows to assist with setting ranges.

For a menu item such as you're interested in tracing, I'd probably set an initial BP on the WM_COMMAND (0x111) handler in the messaging queue for the main window procedure (which will trigger when a menu item is selected). Then you can set up CBL (choosing to log the entire .text section if you wish). Then enable the stop BP, for example at the *start* of the messaging queue, and run the program.

This will get you one full "turn" through the messaging queue for a menu selection. You really don't need CBL or anything else for this, you can single step trace it. The important part is finding the message queue and recognizing the WM_COMMAND handler. Olly itself should help with that, I believe you can set a conditional BP with MSG==111, search for exact syntax.


You should be able to manually find the handling code for the menu item you want that is somewhat *outside* of the messaging queue. When you do, then you can use CBL more effectively from that execution point onwards, without having to worry about logging within the message queue (which can be added as an excluded range).

I hope that sort of helped, it sounded like you were hung up logging a message queue and that's why you were getting "everything" recorded.

Kayaker

@Kayaker -

THANK YOU. So essentially, CBL as a tool is kind of like using RunTrace, except that it only logs the jumps and thus you can find program deviation faster...which is what dELTA was trying to say? Given that, it IS the tool I would want to use outside of ProcessStalker.

The key here is that I was using the tool more like a sledgehammer than a scalpel, I guess. Without telling it where it needs to trace, it got lost in the menu loops. Breaking it down into smaller chunks to "digest" will hopefully create a clearer path.

Your short little tut helps a lot. I'll try breaking on the WM_Command but do note that this is a delphi program so some things are just weirdly assembled loops. I can give it a shot though - I think I understand what you're saying, so I'll give it a go.


@blabberer -

Thanks for the reply and the offer! I'm going to see if Kayaker's tips help me first before pulling you back out of hibernation (don't poke the bear!)...but if not, you'll get a PM.

In that case I'd probably want to try DeDe first and look for the OnClick events for the menu items, as well as ResHacker to see if the specific Menu item Id can be identified. That would be the sledgehammer before breaking out the scapel

Neither workie, sadly. Reshacker shows me only the generic window (the rest of the windows are delphi renders. DeDe croaks about 1/3 through the load process. Tried both tricks already.

I both love and hate delphi apps. When they're small, they're awesome. When they're large, they suck.