Is there a program that will give me the RVA of events such as a button click for any exe simular to this screen shot taken from DeDe looking into a crackme.

Im not looking for where to dl it, I can find that on my own. I just need to know what to look for

First, in windows, the type of events you are refering to are known as messages.

I don't know if there exists program to identify specifically where to set a breakpoint, for each event... but it's not very hard to figure it out yourself.

- You can set breakpoint on messages in softice.
- You can find the message loop / WindowProc and 95% of the time, it's just a bunch switch/case.

maby i didnt make my question clear enough. I am looking for a program that will give me the rva of where the code for the event(message) is located in the exe. That screen shot was taken from a c++ app.

There is no program to do this for a generic .exe.

You mean Delphi

Is there any reason why not, other than no-one has bothered to write it? I don't see it as a particularly hard thing to code for a basic level, although some of the more esoteric ways of creating controls might cause a few headaches...

I guess because the message loop code could be anything (i.e. not just a simple switch/case, but crypted/packed/obfuscated/whatever), and the only way to see where a certain message is processed is to do intelligent generic analysis of the code? Or am I missing something?

He's not only talking about locating the message loop I think, but rather locating the exact code location for the processing of certain events (messages), like "ButtonPressed"/"MouseMoving"/"MouseClick"/whatever...

Exactly what I was talking about, If there is no such program there should be http://www.woodmann.com/forum/smilies_Kayaker/thumbsup.gif. Mainly I was refering to when the button ie: "Register" was clicked, What was the start or RVA of the code that it calls. For those of you who have used DeDe, I think you know what I'm refering to.

Well, due to the reasons I listed above, that is not possible in a generic way.

http://www.woodmann.com/forum/smilies/confused.gif I wonder if the people who wrote the packers/crypters thought the same thing at first http://www.woodmann.com/forum/smilies_Kayaker/undecided.gif.
All things should be possible just who can figure it out first http://www.woodmann.com/forum/smilies_Kayaker/thumbsup.gif. Thats the true question.

"Generic" is the keyword here. The reason that there does not exist any programs for this is the exact same reason that there does not exist any generic unpackers.

Once you have analyzed one particular version of one particular packer (or in this case obfuscated message loop), there is usually no problems writing an unpacker/analyzer, no, but since the discussed issue here was to create a program that could perform exactly this analysis (i.e. the generic nature is implicated) that would defeat its own purpose. For this you would have to implement an AI equivalent of a human reverse engineer. Sure, there are no theoretical limitations preventing this, but this is way ahead even the state of the art in artificial intelligence today, not to mention the resources of someone wanting to write a cracker tool.

And venom925:

If you want to bemoan the absence of such a tool and contradict good advise explaining why it is not possible, why don't YOU start studying and acquire the necessary skill set and code your own damn tool and stop complaining that no one else has one to gift you with.

Regards,

If no tool exist, it's probably because the benefit of writing such tool VS the time & complexity to build it is simply not worth it.

Figuring out where the exact location inside your message loop really isn't that hard when you have a resource tool, a debugger and a disassembler.

You can try to implement one; but for every build of it you produce, I can assure you that someone in here would be able to make a message loop that breaks your tool.

side note: there are unsolvable problems in computer science.

JMI: I was mearly stating that there were probably people who thought that things like the packers/crypters were impossible. Not complaining that no one has a "gift" for me

Delta: Thanks for the explanation of why this could not be made

doug: Thanks for the info on how to find the calls im looking for with SI

Thanks to everybody who responded. None of these post were meant to piss anybody off, I didn't find the info i was looking for so i asked. Is that not what this board is for?

venom925,

I think your approach - looking for a GENERAL tool - is not correct.
Try to limit the field of investigation...

For Delphi, and Visual Basic, and VisualC with MFC classes, for example, the tool you are talking about is possible. Why? Because all those high level languages store in some internal structures the addresses of the snippets which will handle the individual events.

For other languages, such as ASM and C, those structures are not necessarily present, so the only address exported to the underlying GUI is the entry point of the Window/DialogBox procedure.

Regards, bilbo

Actually, it can be done in a generic way, but it's messy:

GetWindowLong(<target button's HWND (can be found with Spy++, etc.)>, GWL_WNDPROC) will give you the handle to the button's window procedure. This call will fail if the caller is not the process that the button exists in, so we have to do the CreateRemoteThread(...) trick to inject the GetWindowLong(...) call into the target process containing the target button.

The messy part is converting the window procedure handle to the window procedure address. It's doable, but again, quite messy and very undocumented

disavowed,
your hint is nice, but I am afraid that from a practical point of view we are not interested to a button window procedure which in the most cases will be always the same (USER32!ButtonWndProcA)... We are interested to the parent window procedure, but - again - we know just the entrypoint of it.

Regards, bilbo