Hey
I have managed to get to the function of a program which is displaying a messagebox that my input was incorrect. My problem is that I want to know where this code was called from. If I stand on top of the called function the call stack and the trace window is empty.

If I get out of the function the line above is not the one who called the "wrong input" function. Which means it's not returning to the "correct" place.

So I tought maybe this was just a function that got called by a simple jump. But I can't get any information about where that would be.

What can I do to get what line of code called (or jumped) to this function?

If I'm unclear and you don't understand what I mean please write so I can refrase it.
Forgot to say that I'm using ollydbg.
//Henrik

You should enable tracing before landing at the place you want to backtrack...

Also, this plugin might be useful, e.g. if the normal tracing is giving you problems:
http://www.woodmann.com/collaborative/tools/Conditional_Branch_Logger

Ctrl+F9 in OllyDbg

if you made your app in Visual studio (or any orther compiler most likely) you can find the retn value of the function by following the EBP register , as original stack is often stored there , to save it so VS stack protection doesent fuck it up. but ctrl+f9 should prolly work aswell

It's not clear to me what you mean by 'standing on top of the called function'. The closest I can come to your meaning is being located at the address where the call originates but that's hardly likely since you are in the call itself, or have just returned from it. If you have traced out of the called function, you are sitting below it, not on top of it. In that case, if the call stack is empty, you need to carry on tracing till an address appears in it again.

If you are sitting at the address immediatley after the call to the mbox function, there are a couple of things to consider. The code you are in is going to return to the address immediately after yet another call, and those calls may be in a library (dll) like mscvrt.dll. There's no way to tell at this point where the former call is but tracing will get you there one way or another. Therefore, you are looking for the RET instruction that will take you back to the address after the previous call. Along the way, keep an eye on the call stack to see if it reappears. It usually does.

There's no way to tell at this point how many previous calls there are unless the stack is clearly defined. It would be nice if you could look at the stack and see the calling address from your app., but it doesn't always come out that way. The stack works in frames and you wont be able to see your original call till that frame comes up with its base in EBP. Why the stack disappears in Olly/softice is not clear to me.

One way of proceeding is simply to trace while watching the code. In softice, you can scroll down to see if an obvious RET instruction is there. Other times it is nearby and you can get to it by tracing/jumping over calls. If it's far off, but visible, you can double-click a few lines before the RET in softice then jump to the highlighted line. I'm sure Olly is similar. When you get to the RET, trace into it and see where you are. Also, see if the stack has returned. It might take tracing through several such returns to get the stack back, and even then it could be full of many levels of nested calls that are meaningless to you..

I haven't used Olly, but one problem I see is the mbox code being reached through ring 0 code. If that's the case, I don't know how to deal with that, and the ring 0 code may interfere with you tracing back, depending on how Olly handles it.

Another way of proceeding is to use IDA in conjunction with Olly. If the mbox is in a library like msvcrt.dll, you can load that in IDA and try to get an idea where the mbox code is going. If the mbox code is in your app, all the better. Look it up using IDA and get an idea what is going on.

sumtimes i just wanna quit reversing...