I'd like to be able to change a setting in an specific application without using the options dialog in which you'd normally change the setting. (I'd like to do it e.g. by sending a message to the application from my own program, or patching the code somehow or injecting a dll which calls the code or whatever)

How can I find the code that handles the processing of that setting/option (when it's set/changed through the options dialog)? And once I've found that code, how could I call and run that code? (wouldn't just simply want to change the eip would you? )

My observations so far: I've noticed that the option that I'm aiming at is read out by sending an WM_GETTEXT to the Editbox in the options dialog (no big surprise) But I couldn't find the processing routing by bpx'ing the WM_GETTEXT and then tracing through the code. (btw: who has sent that WM_GETTEXT message? was is the options dialog or the main window?)

Any tips for finding the code which retrieves the editbox contents and handles the further processing?

Thanks

Sunrise: Perhaps you are being a bit vague/obtuse to conceal your real purpose and perhaps you simply haven't described it clearly. One would wonder WHY you might want to change a 'specific setting in an option dialog" from another program and/or inject code into it from another program, UNLESS you did not have access to the "option dialog" while in the program itself, because, if you had access, you could simply change it there, right?
So maybe you are approaching the problem from the wrong direction, or not describing that approach.

Assuming my assumption may be accurate, call it a leap of faith, have you considered approaching the problem from the side of whatever is preventing you from accessing the "options dialog" in the first place? Have you considered the likelihood that if the "option dialog" is not available for changing that simply "turning on" one of the options in the box itself, may not have the desired effect of activating that portion of the code, because the program itself never reaches it because it didn't make the branch at the "is registered" or "activate those options" portion of the main code?

Just food for thought.

Regards,

Probably I have been vague. Since it it has nothing to do with registering an crippled program whatsoever. And I do have access to the options dialog. (In fact my first approach was find the application windowhandle (findwindow()), open the dialog (sendmessage), change the value in the editbox (settext) and press the OK button (wm_command). That worked, but I don't like it that way. The window popped up and I want to do it the 'hard and neat' way (read: lowlevel))

I just want to change that option (a text string) and have the program act as is normally would. What i'm trying to do may be considered as writing a plugin for a program. (program is free and not crippled) In fact, it IS a plugin! (it's only that the application doesn't support plugins, got it?) I try to take control over the application from the outside. Hope this makes it clear.

Well that is more clear.

I know it might not be elegant, but, have you considered a DOS .bat file? Your discussion suggests the program will be already running, so the bat file simply has to identify the proper program to effect, open the dialogue box and insert string and save. Or is that too "high tech" ?

Is your object simply to learn how to inject the code for general learning and future use or to simply get the change in this program in any way you can, with the least effort? Your responses will probably help some of our coders to help you accomplish your task because, on the surface, it doesn't sound too different from other code injection tasks.

That setting has to be stored in the program in some memory location and there has to be a routine for saving it in memory and for changing it and re-storing it. Have you search the code in memory to see if you can find your code in clear text? Have you searched for the strings from the dialog box in a disassembler to find the routines that operate the box? Seems that the approach would be similar to serial fishing efforts described in these forums. You want to catch the entry of new text in the input window and that should identify for you the where, in the code this is happening. So you run the debugger on the program whose option you want to change, set breakpoints on your text reading API's and make a change and see where the program breaks to get your text and where it puts it. That should help you figure out how to then replace that string in memory with your "new" information.
Then you can read up on injection of your own string into the memory space of the running program.

Hope this is helpful. It's all very generic at this point.

Regards,

Hi

I think you've got the right idea, you just need to follow it a bit further. You say you can trace WM_GETTEXT up to a point then get lost as to what it's doing? That's probably exactly what you need to explore further, you need to get into and through the message handling routine and see what changes are being made. If the program writes something to the registry say or to an internal variable, then once you've figured out the precise changes to make you may be able to do that directly, say from an injected dll.

If you set a 'BMSG <hwnd> wm_gettext' you should be able to find the main message handler you'll need to trace through. The hwnd you need should be the main dialog window, though you may need to experiment in case it's subclassed or something. In Win2K, BMSG should break in kernel code which may look something like this:
Call CF0F8
jmp 41B448 -> exact start of main message handling routine.

In Win98 it's similar, BMSG should break in KernelAlloc at a PUSH statement, the address PUSHed again should be the start of the main message handling routine you're interested in.

If the BMSG trick doesn't work, you may also be able to find the message handler in a static disassembly, look for the presence of 111h (wm_command) or 0Dh (wm_gettext), etc. (it may not be that obvious). Once you find the start of the message handler (remember, this is the whole point!), you can set a conditional breakpoint so you will ONLY break on wm_gettext with your hwnd. Then you can carefully trace to see what the program does exactly on that message, and hopefully figure out a way to do it directly yourself.

Heh, I always seem to preach in these cases to "Find the main message handler and trace your message!", but in the majority of cases it's the easiest and most direct route, the 'front door'. Until you're comfortable doing this it's easy to get lost, but almost always it's straightforward if you keep watch for your parameters of hWnd, wParam, lParam and msg being handled. You should be able to find a single statement which says essentially "if msg = wm_gettext jump here", and you can analyze what the program does then to your hearts extent.

If you need more help, say so.

Kayaker

EDIT: I see JMI alluded to an API monitor. That's my second favorite preach Chances are that may be even more direct than tracing through the message handler. Pause the monitor until you press OK with the new text in your dialog box. That should be enough to give an indication what the program is eventually doing, plus give a few addresses to break on.

Much like what JMI suggested, if the text is in plain view then probably the easiest way to modify it externally is using the WriteProcessMemory function.

It becomes almost trivial if the text is not encrypted and always in the same location.

Thanks for your replies. Using the BMSG WM_SETTEXT method and tracing back to the caller, and some more tracing I have finally found a call which does all the processing/handling for that setting. The call accepts 2 parameters, one of those is the text read from the editbox. (pretty cool huh?) (the call contains large portions of code, don't even think about rewriting it! (As what you might do for e.g. a keygen)

So, what I'm going to try is to inject a DLL to the process which calls the call I just mentioned (with the proper params obviousely). It might take some time, but I think I'll manage to do that (never done something like injecting a dll). Anyway, any hints or info on this subject is always welcome). (I haven't searched this board yet, but I will do that soon. I might find all the info I need).

Try elicz's apihooks. hxxp://www.anticracking.sk/EliCZ/ has functions that will hook api's, inject dlls into another process space, call functions of injected dlls, etc.. etc..

Yoda also has a similiar library called forcelib you can get it at hxxp://y0da.cjb.net/

Lastly real stuff *worth* understanding by Yates hxxp://www.woodmann.net/yates/import.html

There are other ways to do this as well, but EliCZ and Y0das libs does a fine job.

Regards, Sope.