Trying to change version string in mIRC.

Originally Posted by Fade

So I was wondering, if I know the place in memory where v6.17 is stored, is there a way I can find where it is referenced in the program?

It may not have been necessary this time, but for future reference, I think this is an important question to answer.

The short answer is to set a memory breakpoint (on access) on the first byte of the string, and wait for something to read or write to it. Since the program is probably manipulating strings through library calls (ex. wsprintf), there's a good chance that your debugger will break somewhere inside of a system dll or library runtime (msvcrt, vbrun60, etc.) instead of the main module. You'll have to examine the return addresses of each stack frame to work your way back up to the relevant code in the target application.

The long answer is that Ollydbg has two kinds of memory breakpoints for breaking on an individual address. The hardware breakpoint option is a conventional memory breakpoint, analoguous to using "bpm ..." in SoftICE, except that it sets them through the windows debugging API instead of directly modifying the debug registers (forbidden for ring-3 code). The other option ("memory, on access/write" in the context menu) is something else altogether. When you use this option, Olly prohibits the corresponding operation by changing the attributes of the entire page containing the address (4k page minimum on x86 systems). This raises an exception every time that any address in that page is accessed/written to, not just the one you set the breakpoint on. Olly basically ignores all the other exceptions for you, and only halts when the exception is raised while messing with the breakpoint'd address.

This approach is novel, and can be very useful, but I tend to avoid using it unless other approaches don't work. Two problems: one is that this approach can have major performance impact because of all the "false positives" that have be dealt with. Secondly, this approach can also trip up certain kinds of programs, causing crashes or triggering a protector. You're also limited to only a single breakpoint of this kind at any given time, although the interface doesn't make this clear. On the other hand, the fact that it isn't implemented through the normal mechanisms is sometimes exactly what you need to avoid detection. YMMV.