hello
is there any tool that can display the execution path a function (by function i mean a region of an program) makes? more exactly, to display the jumps and calls the function takes ? i have searched the internet for
something like this but i couldn`t find anything and really i don`t think that this is an original idea. i mean somebody must have had this idea before me. if not i`m planning to make one but i asked you because i don`t want to waste my time doing redundant work on something.

If you are looking for the FLOWCHART of a subroutine/code-region, IDA Pro can do what you ask.

If you are looking for something that dynamically traces executions, Fenris is your choice (LINUX only):

http://lcamtuf.coredump.cx/fenris/

If fenris matches your need and you are not running LINUX, you may want to adapt to your needs:

http://www.phenoelit.de/dumbug/

HTH

yes, i want an tool that can do that at runtime. i have been thinking and it won`t be that hard to write. it will be a small console tool that will display an output simmilar to this

[004ea44c] trace start
[004ea457] call to 4c822a
[004c823c] je to 4c834a taken
[004c825c] je to 4c834f not taken
...
[004c832c] return to 004ea461
[004ea47f] trace end

this is random data, but it will give you an ideea about what i want...

Well, then Fenris is what you need. But also have a look to ProcessStalker IDA Plugin here: http://pedram.redhive.com/code/process_stalker/

Hi,

I'm not sure, but maybe this program can help you.
http://woodmann.com/forum/showthread.php?t=5839

Btw, it is not only a kernel debugger.
Try to read the USRGUIDE.rtf file. It has all the information
to use it.

Regards,
Opc0de

It's fairly easy to write a script for Olly that does pretty much what you want, the part that is not so easy is trying to eliminate everything executed when the code calls an API. I use one to compare time trials prior to and after expiration, and also to trace the origin of nags. - Main drawback is the lack of info regarding arguments and register info.

SiGiNT

A tool like this would slow down the analysed program quite a bit since it would have to run the processor in single-step mode, unless the processor has attached an external hardware debugging device. I remember something called a PFA (program flow analyser) from the time of the 8086. It was basically a very specialised 8086-like processor (hardware emulator) with some extensions. It would log into a separate memory all instructions executed (2MB, if I remember correctly, a very large amount of memory at the time), and show loops without repeating the instructions and procedure calls in detail, complete with register dumps. The emulated "processor" ran at approximately 100KHz. Even at that speed, the entire logging memory would be full within a few seconds.

Considering the speed at which current processors execute (several giga-instructions per second), and the amount of logging memory available, it seems quite difficult. After all, nobody would want to, nor have enough time in her whole life to examine the several hundred megabytes of log generated in less than a second, only to find the critical jump.



That wouldn't be too difficult to write, but a processor emulator would be the best choice since certain protections like to mess with the debugger by clearing the single-step flag, using the debug registers for its own use, etc. One day you may want to debug a debugger too... Basically you let the program run on an emulated processor, logging its every instruction (best written in highly optimised Asm). However, the amount of output from the logging program would be hard to analyse manually. Get the computer to do it. The important point of emulation is that the speed becomes extremely slow - less than 1/100th the speed of a real processor. The equivalent of having a 3GHz Pentium 4 turned into a 30MHz one.

Program flow analysers are one of the most valuable tools for RCE. Especially for the extremely rapid cracking of simple jmp/jnz/jz protections.

You know, this board has a funny little feature (see bottom of this page) called "Similar Threads" which often finds, er, similar threads...

Down there
|
|
|
V

is a thread titled "tools that logs a program address CS:EIP execution?"
in which Aimless describes using Softice for this exact purpose. It may not be mentioned there, but the results can be output by saving the Softice Command History after implementing the trick.

Of course, one of the best methods is (was) using the Backtrace feature of Softice, though that only works with Win9x. If you can go that route, don't forget to use Tracedump ;-) Sigh, the good 'ol days...

Kayaker

Quite recently I was reading through the Intel manuals when I found the following very interesting section titled Last Branch Recording.


It seems they've integrated a flow analyser+hardware debugger into the processor itself!

A while ago I was writing the solution for this problem in my own debugger (Memory Hacking Software).


Basically I had a logging feature.
You would set the start point and end point (usually you would want to start just before a function call and end just after it returns) and it would just log each instruction processed between those two points (accounting for recursive functions) the specified number of times.
After it cycles between those two points the specified number of times, the log would end and you could view it in graphical form.
You could click on any instruction you wanted to view and refollow the code.
All registers were saved for each instruction, so when you went back and followed the code again, you could see what the registers were at the time it was originally executed.

My intent was that you could create multiple logs and compare them to see what changed between each. So, for example, if you were trying to find code related to firing your weapon in a shooter game, you could log one frame where there is no firing action, then log another where there is firing action, and the difference between the two logs would be the code related to firing your weapon.



Well, my complication was that my program is not a kernel-mode debugger and when the target process performed a SYSENTER, my debugger couldn’t log the code anymore.
When it came out, my log stack would not always be aligned, creating a graphical error (though nothing more).
I disabled the logging feature in all releases of the software, although it is still there and works except for the graphical alignment problem.



Would you like me to enable it again?
Should I finish it? Does this sound as if it will solve your problem?
Also, if anyone has an idea how I can keep logging after SYSENTER instructions without being in kernel mode, I would appreciate that.
I currently log via single-stepping.


L. Spiro

Sure. A run trace feature is always nice to have.
Do you think it'd be possible to show the graphical flowchart for traces that don't include a SYSENTER and a simple linear trace log for those that do?