I've done my best to understand and trace through this application using breakpoints on WM messages.. but I just do not know how to find out where/when the message is being sent to disable this button.

I know that it is not disabled by default because I've examined it using "Resource Hacker". I also know that I can use programs like "windows enabler" to enable it real-time, but I want change it in the application itself so I don't have to use the enabler.

Any help, or even just advice would be greatly appreciated.

btw. I've been using ollydbg.

You would avoid a "comment" by JMI if you just try to meet the requirements of the FAQ to tell us what research YOU, YOURSELF have done to attempt to solve your problem. This includes searching for answers both here and on the net for a solution to your problem!

For example, you say the button is not disabled by "default," but you "just do not know how to find out where/when the message is being sent to disable this button."

What effort have YOU made to determine how, as with what code, your button might be disabled and/or enabled? If you have researched this issue, how would we know?

Have you considered the possibility that the "protection" of your "target" is determining that your "target" is not appropriately "registered" and then goes off to some code which disables this particular button?

Have you considered that this particular piece of code might be (gasp) encrypted, preventing you from seeing it?

Have you considered that (gasp) the program might be detecting your debugger (double gasp) and therefor doing something it wouldn't do, if YOU weren't watching it with Olly??

How about you do some research on activating buttons and how buttons might be "deactivated" as a form of preventing "unauthorized" use of the "full" capacity of the program. When you've done some of that, and told us what you have already done, besides ask your question here, I'm sure someone can give you some further hints.

Regards,

responses in blue

Messages are not the only way buttons and menu items get grayed/disabled. Kayaker wrote an excellent tutorial about them, but I cannot seem to find it right now.
Search in the tuts repository for "gray out targets", and you will find a more extensive collection of strategies.

Good response and you could have avoided my questions all together if you has explained some of these points in your intitial post. One of the problems with people posting is that have many things in their heads which do not appear in their posts and, generally, we have no way of knowing what anyone may have done, unless they provide such information.

So, you say you are not working on bypassing a protection system.

You say I should know the button is disabled sometime during the running of the application because you said you used Resource Hacker to check it, but MY question was not whether or not the button was disabled by the running of the program, but whether or not YOU had done research on "what code" would disable a button. If you don't know what code is capable of "deactivating" a button, it seems logical to conclude you might have difficulty finding the proper code on which to set a breakpoint.

NOW you say you spent the night doing research on WM and how to breakpoint them, but, obviously, this information is not in your original message. That was the point of the statement: "If you have researched this issue, how would we know?"

Now, since you say you are not trying to "crack" anything, and you start with a button which "was activated" and now it is "deactivated," have you asked yourself WHY they might have done this? Is this a demo version of the software? If so, the code which might make the "button" function might not actually even be in the code you have to play with. Again, I am only speculating, in the absence of information.

But your problem remains the same. You say you have a button which was initially activated and now it is deactivated and you want a breakpoint to set to see if you can catch, and impliedly, prevent this from happening.

Seems that before you can "start setting breakpoints" you need to better understand how the "control" (e.g. the "button" can be activated and/or deactivated. Do you know what those commands are? And if you do, are those the commands you have already attempted to set breakpoints on?

Regards,

Thanks. I didn't know there were other ways to grey out a standard form button. I'll look for that tutorial also. I hadn't thought of wording my search as "gray out targets". I'll do that, thanks.

Sorry, Kayaker wrote the intro. The tut is by clandestiny.

http://71.6.196.237/fravia/Clandestinity_MixVibes.html

Thanks so much. I will read thru this tomorrow (I've been up all night here in japan and need a little shut-eye). I notice it is about enabling menu items and not buttons.. but if anything I am sure it will help me more to figure out my own situation. Thanks again. -b

I did it! Thank you so much. Like I said, the tutorial was about menu items and not form controls.. but I was able to figure it out based on the concept of menu item disabling.

For anyone else interested, here's what I did.

1) Using W32Dasm, I found the button's control ID. (This is the same ID that is listed in Resource Hacker, but in Hex format).

2) Then I put a breakpoint on all called API's that are similiar to the ones used to disable menu items. (EnableMenuItem, GetMenu, GetMenuItemCount, GetMenuItemID, GetMenuState, GetMenuString A, GetSubMenu, InsertMenu, LoadMenuA, & ModifyMenuA). This ended up being alot of api's. I pretty much put a breakpoint on anything that said enable, dlg, control, & window.

3) I was able to determine which breakpointed api was interacting with the button based on the parameter that specifies the control ID. As it turns out, the actual api responsible for setting a button to disabled is EnableWindow. The first parameter (2nd line above the call to the api) is what specifies its state, the second is the control ID. 0 is disabled, and 1 is enabled.

thanks guys.

well for future referances perhaps look at ollydbgs windows Window it sure lists menu items and their control ids and you can possibly follow their class procs or WndProcs As Well
setting up message breakpoints

or simply go deep into system and set bps on TranslateMessage,DispatchMessage Apis

which is where every message is handled
in fact instead of EnableWindow
the app in Question Might use SendMessage ??WM??_DISABLE or as your resource hacker did or does Send PostMessage(??WM??_ENABLE) or use DDE apis to enable and disable if they are using Property Style Sheets

there or lots of ways to skin the cat

Actually.. I spent quite a bit of time in the windows section.. as well as even more time bp'ing sendmessages, dispatchmessages etc.. The WM messages were the route I took to try to figure this out at first. Finding the api which initiated those messages was where I found my solution.

Glad you hung in there and got it figured out. It may take longer, but the more personal effort one puts in, the greater the personal sence of satisfaction when the hoped for outcome is achieved.

Regards,

If I may interject:

Messages are the heart beat of Windows, what gives this OS and environment the illusion of multi-tasking and parallel processing, as well as an event driven format.
If you know messages, you know windows. The down side of message tracking is that there are hundreds of them, simultaneously flying in all directions, to all sort of windoses, threads, and processes, driving the background noise to a rather high level. Catching the right message at the right time is the key to effectively using messages for RCE. That is when conditional breakpoints, used as a noise filter, are priceless in this sort of endeavor.

I just felt I had to give a sort of deep sounding political speech

Well, its a good one. That is the best way to describe what I've been realizing thru my 'messing around'. In fact, the skill of breaking at the right moment is what I was hoping to get a better grasp on. Aside from bp'ing in such a way that I'd see EVERY one of those messages that make up the noise... the only way I knew to try to find that one exact message was:

-to find a way to break in at a moment when the button had been created, but before it had been disabled.

-Then go to the windows section and select "message breakpoint on classproc" for that control

-then specify which message to look for.

My problems were that I didn't know how to figure out how to break after the button was created, but not disabled. Then I didn't know which message to look for. I know learning conditional breakpointing is the key to mastering the use of ollydbg.. but olly's help file is lacking, and the searches I did mostly turned up examples instead of guides. So I guess I just need to find lots of examples and study them until I get enough info to start creating my own conditional bp's. Nonetheless, thanks for the replies guys. -b

There is an app called spyxx that comes with a microsoft compiler. It's very handy for identifying what messages are activated when a button is pressed. It will also tell you the hwnd (handle) of an active window (button) etc., and which window receives those messages. You can set it to tell you every message generated by a control, even custom messages. You can also set it on a range of messages and it will trip when one is generated.

It works very well with softice (errr, em...only kidding blabberer ).

Wow, that sounds perfect for me to learn this stuff (I learn more thru experimentation than documentation). Thanks man, I'll check that out right now,

You may also want to look at other alternatives to Spy++, in the same tool category:

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

since you said you got your message handled at EnableWindow i assume you button is a window then it would have been Created By a CreateWindow and before that there would be
RegisterClass which will have as its parameter a ClassProc
which is were the relevent messages are handled if the app in question is straight window
thats neither subclassed or superclassed
and if they are either subclassed or superclassed the GetWindowLong(GWL_WNDPROC) is where the subclassed or superclassed messages are dealt with

Added another tool to the library

http://www.woodmann.com/collaborative/tools/Window_Hack ("http://www.woodmann.com/collaborative/tools/Window_Hack")

Looks nice. I added it to the possibly more suitable category "Window Manipulation Tools" too.

wow there are so many categories
i thought "Window_Monitoring_Tools" would incorporate all such appz
Its nice to see that the library has become quite exhaustive already
credits to you dELTA

I just checked back and saw all the new replies. Thanks for the information! I'll check out these tools. I've actually got a new question now that I just posted here:

http://www.woodmann.com/forum/showthread.php?p=73230#post73230

thanks guys