1. Enter the "task" command in Soft-Ice. There you get a list with all the running tasks on the system, with the Task-names at the start. Look there for the task-name of your target-program, for example PSP (for PaintShop)
2. Enter "hwnd (taskname)" where (taskname) is the name from the task you got through step 1. This will list you all hwnds for every window belonging to this task. Of course the first window listed will be the Parent-window - the MAIN window for your task.
Now when you take a look at the list, you will see DOZENS
of windows listed here, and you might (even justified) yell at me: "How
do i find the right window i want here ???" Okay, thats something
you must THINK for - in the list you will
find a column with the title "ClassName".
This tells you (obviously) the class of the window. Classes are more or
less some kind of templates for the windows that you create. The most common
classes are already defined, for example edit-fields, dialog-buttons (like
the OK-Button) etc.. If you want to create a window/element for which no
predefined templates/classes exists, you just create the new class (with
RegisterClass or something...) first and then tell the OS to use the new
class for your window. There is one case in which you ALWAYS have to create
a new class, and that is for creating your Parent-window. There are no
predefined classes for parent-windows (they are somehow unique,
or thats what Billy tells one in his books), this is why you find at the
top of the hwnd-list for the parent-window of the task a number
beneath "ClassName". You ONLY get numbers for the "ClassName" for the ones
who are not predefined, this includes ALL Parent-windows and all other
new classes the task has registered for child-windows. For standard (this
means already existing) classes like dialog boxes, common buttons etc.
you will find the correct "ClassName" listed, and since most nagscreens
etc. are made with these standard classes, you can skip all user-defined
classes with numbers as a class name. The next thing for finding the correct
window (and its hwnd) is to take a look at the window itself... Has it
any OK buttons, edit fields, etc. in it ? Then you should find a similar
structure in the list, and as the list is hierarchical as well, sub-windows
of one window are shifted to the right (coz you can have child-windows
for a child-window as well). I guess you wont have any problems with this
tree-like structure, you should be used to it by now from many other related
topics.
Window Handle hQueue QOwner Class Name Window Procedure Level 1 0EB4(0) 11D7 PSP #32769 04A7:9E6B ; parent-window Level 2 25B8(1) 11D7 PSP Histogram 1197:07E8 ; child-window without any sub-windows 2090(1) 11D7 PSP #32770 1D07:120E ; child-window with sub-window Level 3 20F0(2) 11D7 PSP Static 1D07:38A6 2138(2) 11D7 PSP Static 1D07:38A6 2180(2) 11D7 PSP Static 1D07:38A6 21D8(2) 11D7 PSP Static 1D07:38A6 2230(2) 11D7 PSP Static 1D07:38A6 2298(2) 11D7 PSP Static 1D07:38A6 22F0(2) 11D7 PSP Button 1D07:2876 ; this is for example an OK button 2344(2) 11D7 PSP Button 1D07:2876 ; this should be a CANCEL button 2398(2) 11D7 PSP Static 1D07:38A6 23F0(2) 11D7 PSP Static 1D07:38A6 2448(2) 11D7 PSP Static 1D07:38A6 24A0(2) 11D7 PSP Static 1D07:38A6(to give credits where credit is more than overdue --> this example was taken from the +ORC tutorial 9.2 on PSP cracking) etc...
For more information about the existing classes etc. i suggest that you should get yourself a good Win32-API Reference which you need sooner or later anyway. I have one with an intro about the organization of classes and other interesting things about the OS, as well with a complete description of every API function and a lot more... You will really need a book like this, coz very often you have to deal with new situations and getting as much information as you can is your only chance to deal with it. Now that you basically know how to get the right hwnd, you still need to know something about the windows-messages that you can break on with soft-ice. So here i go again ;-) The event-handling in Windows is managed via windows-messages. These messages tell your application when specific events occur that your program might or should act on. For example, when the user enters some text in a text field of a window it would be kinda useful to let the program know that this just happened. So the OS sends a message to the related programm code for this window like "That damn bloody user just happened to type some crappy text in this field, so DO something about it !!!". In real life, or in real Windows, these messages are of course not so well phrased... ist more something like wm_gettext. Yea, i know, the other message was more fun, but Billy has the humour of a piece of rotten bread... So deal with it ! There are of course many other useful events noted with these kind of messages, like button-clicks etc... Look them up in a Windows-API reference book, this is valuable information. Well, this enables us for example to break on the wm_gettext message for the text field of the registration number. You will get right down in the code which handles this event, and you might save yourself a lot of tracing through useless code-garbage. You can also take some advantage of the other information provided with the "hwnd" list under soft-ice, for example the column Window-Procedure, where you can see the adress-location of the corresponding code-part for handling events for this window. Most times the code for protection-routines are in a different location than the other code, this is due to obvious reasons: the protection part can be easily stripped away for the FULL, unprotected versions. This spares the programmers lots of work, and like +ORC already told us a dozen times, they are very lazy and commercially oriented (more money for less work). So you can easily see there is something wrong with a windows procedure for an element/window when it dwells in an other location than the rest... (at least it's a good guess :)))