Hi,

I would like to disable a button on a toolbar.

I have done some reading and discovered Yoda's Window Manager (YWM) ("http://y0da.cjb.net/"), which sounds like a great tool for newbies, but alas it seems to good to be true as I don't seem to be able to make it do anything. Does anyone have any experience with this tool, because there doesn't seem to be much doco with it, if I could use the Window Manager to configure the app that would be ideal

Assuming though that I cannot use YWM, I would appreciate some general direction on how I might go about achieving this.

When you hit the button (that I want to disable - which is on a toolbar) you get a window (which looks like a messagebox - but isn't). When I trace the app I can break on that window, and trace back to where the call comes from. The "problem" is that the loop where the call to the window comes from appears to handle all the buttons, so I can't just NOP out logic in the loop because it affects more than just the offending button.

I have considered looking at how the toolbar is created, and then modifying the setup of the toolbar so that the button doesn't appear at all. At the moment that approach looks reasonably involved, and while I may yet examine that path in greater detail I wonder if there is an easier approach.

I have also tried capturing the button push, so far without success, but I haven't spent a lot of time on this.

I guess there are a few options, and perhaps some that I haven't considered at all, and I'd like to have a clearer plan before I go any further.

Thanks

VW

If you are not yet got anything.

how about try TRIAL APPs you can push "TRIAL" or "EVALUATE" or so.

after 30days, button disabled so you can not push

I dont remeber but you can disable button or menus.

Sendmessage or certain function? i dont remember sorry

Get an API reference. Look up EnableWindow.

The app uses ShowWindow to display the window, but I think it's too late at that point. You're already in the loop that handles all the messages. The call to ShowWindow is used to display various windows, depending on which buttons are pressed - so I don't want to try and modify this call - it's too central to the app's input handling.

Out of interest I modified the ShowState value to hidden, which did hide the window, but because the program was expecting input from the window (e.g. OK or Cancel) by hiding the window I effectively locked up the app as I was no longer able to supply any input.

Ideally I need to disable the button that sends the message to display the window in the first place.

Alternatively it may be possible to prevent the creation of the window in the first place. Although if I am successful in modifying the CreateWindow (assuming that's how it is done) - what happens when the ShowWindow is later called would be interesting to see.

It seems like you're approaching this the wrong way, IMO. You have 2 points of attack - either the code that responds to a WM_COMMAND on the button, or the code that creates and displays the resulting window. Perhaps you can clarify this:



You seem to be saying, you've found the parent code that calls the window creation/display code. But if you've found that I'm not sure why you're having trouble defeating it - even though the same loop you refer to handles all the buttons it must have specific logic for this button, which would be your target.

One other thing, what was this target app written using - straight C/C++, MFC, Delphi, asm, VB etc?

EnableWindow is not used to display windows, it's used to enable/disable controls/windows (everything is really a "window" inside MS Windows, also controls located on another window, or a menu etc).

So, again: Look up EnableWindow.

I agree with Delta

Enablewindow is the way to go. Instead of trying to patch the function of the button or the actual button why not just patch the generation of the toolbar. This is where the enablewindow/enablemenuitem etc come into their own. If you can find the routine that paints/refreshs the toolbar then its only a matter of setting the parameter for that specific buton (Which will have an id) to hide the option.

my 2 cents worth (yes i type quickly)

OK, I'm with you guys now.

I did run a trace breaking on calls to EnableWindow, but the details of the window that I am trying to block never appeared. So I couldn't see how to proceed.

However one of the calls to EnableWindow related to the Toolbar. So this is where I should focus my efforts.

Thanks guys.

VW

Hi

You might have a look at
Reversing 'Adware' by Modifying Window Display Properties
http://woodmann.net/fravia/kayaker_adware.htm

It may give you some feeling on how windows are created, how some of the relevant API's used to create and show the window controls can be "nested" calls, and how to use an API monitor to sort out what and where things are occurring.

Note that EnableWindow may not necessarily be used and ShowWindow can indeed be used to set the display state of a window. You'll have to figure out how your toolbar is being created, and again an API monitor may be very helpful in this regard.

Cheers,
Kayaker

A useful essay, much easier to follow than many. Frazzle is a straight-forward implementation where each of the buttons has a separate control. This makes the button (relatively speaking) easy to manipulate.


You're quite right. With my target the Toolbar appears to be a single control, when you view it with a "Window Info" viewer.

At the moment I am still to understand how the Toolbar is being created, and that's the key - if I can get to grips with that, then I ought to be able to modify the attributes of the individual buttons.

From what I can see the toolbar is a single control. Which means that the toolbar has a single id, rather than one for each button. How the individual buttons are managed remains a mystery to me at this point. Enablemenuitem is not used at all.

I have found the code that displays the Window after the button is pushed. This code is used to display different windows depending on which button is pushed. So I can't change the 'display window' code without breaking the app.

If I was going to change the app's behaviour once the button was pushed, I think I would need to locate the specific logic for the button (i.e. button pushed -> do all the prepatory stuff to display the window), which I have not yet been able to do. I guess in theory this is another approach that could be taken, in practice I don't feel that I have the knowledge to work out the required changes to make this viable.

I think it will probably be easier to disable or hide the button, because if I can locate the appropriate code, it's likely that I will only need to change 1 byte.

But to answer your question, what I have located is the final action once the button has been pressed, which is to display the window. I hope this explanation makes sense


As an aside, I would like to be able to use run trace. I tried to use run trace, but run trace does not seem to be effective when you're attempting to trace windows message handling. I think the tight loops mean that you end up with a virtually empty trace file (because when the loop repeats the trace overwrites). Which is a bugger, because run trace is one tool that I have found to be very useful in figuring out what an app is doing.

Also I haven't been able to step through the message loop code by hand (F7), because the app's program execution is different when it's running to when you're stepping through in debug mode.

So as a consequence so far I have not been able to follow the app's execution from the point immediately after the button has been pressed.


According to PEiD the app is written in Visual C++ 6.0

What about approaching the problem using a resource editor?

Exactly, using a resource editor you may be able to find the individual button graphic, usually there is an enabled function associated with it, simply change the state, or if you are working on a VB app, and you could very well be, (does it invoke msvbmXX? - get your hands on a copy of VBReformer version 3.7, (the last free one that allowed you to modify and save), disabling the button is child's play then, unless it's P-code. I'm assuming in your toolbar code there aren't a bunch of pushes - if so than changing the value usually from a 1 to a 0 might do the trick - you'd have to experiment.

SiGiNT