Trying to change version string in mIRC.
 

This is probably very simple for you guys, and may seem trivial or stupid. But it is just for experience like the last thing I did :)

The string it uses to reply as a version is "mIRC v6.17 Khaled Mardam-Bey", I couldn't see that in hex or when I viewed all referenced strings in olly. I could however find v6.17 in hex and when I searched for strings in memory in olly. Which makes me think that he is using something like.

"%s%s%s", programname, programversion, myname

At the place in memory where I found v6.17 I tried changing the 7 to an 8, then versioned myself. It replied with v6.18 so that must be the correct place. I was thinking he might be using programname/programversion in other parts of the program aswell so I was hoping I could find a solution without editing them. I had a thought that maybe I could edit the ""%s%s%s" (if I can find it) to a string literal instead, or perhaps point it to a different place in the file where there are some spare bytes and that I could write my own version string.

I think the problem I am faced with at the moment is that I don't know how to find %s%s%s, I searched for all referenced strings, and then searched those strings for %s%s%s there were quite a few of these. And I didn't really want to look at each one of them. Plus I think checking each one isn't really an effective method. 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?

Thanks in advance guys.

Try searching with an hex editor for the string:
"mIRC %s Khaled"
Anyway, watch out for CRC check, and file rename check!

Thanks. Did you have a special way of finding that or were you just searching things like mIRC and Khaled Mardam-Bey?

here something useful for you :D

nice utility, a little dll that intercept and modify on the fly the version reply when someone "CTCP VERSION" you:D

no, simple searching like you said

there is special command on the mIRC scripting language of changing the CTCP VERSION reply. At least it has one, dont know if the latest versions removed that option.

Thanks for this, I appreciate it but it is mainly about the learning side of things, not so much just having my version changed ;)

Yes this is possible and from what the readme says that comes with the DLL posted above, this is how it works. Something like this below.

However the readme in that DLL says copyright 2000 - 2002, which implies it was created in 2002. Also it says in the readme that the version of mIRC is v6.01
The current version of mIRC is v6.17 it has either been changed on purpose to stop version spoofing or there is a bug. Because the first time you version someone using a script like this it says.

If you do it again quite quickly it seems it sends only the "Whatever IRC Client." reply, but if you wait a short while and do it again. It will send the real version reply and fake version reply.

-----------------------------------
Well I'm a little closer thanks to 0KRam, I guess this might be a bit more difficult than I thought though.

take here a functional script with source that change the version reply (functional with 6.17 of course) it is all well explained in the zip with the source.

I think before I go any futher into reversing I should definitely work on my programming more. As an example, understanding that code hehe.

Thank you conan981.

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.

FYI there is a small essay of Sub-niggurath on something similar to Olly memory bpm, but for other uses... I think it is on the arteam site.
It is handy sometime to place a bunch of invisible breakpoijnts -especially when you log...
Give it a look ;)

Regards,
Maximus

Indeed. Anything which raises an exception *could* be used as a breakpoint. INT3 and DBx registers are only one way to skin the cat. They raise explicit debug exceptions, but a debugger that can't catch other kinds of errors would be a pretty lousy debugger. For that matter, don't just limit your thinking to exceptions; various system APIs can also be used to invoke the debugger. It's easy to think of "breakpoints" with an overly narrow mindset. Get creative :D

How about changing version reply in HydraIRC client (www.hydrairc.com) ? I believe it is encrypted in the file so perhaps no possibility?

No, it's not encrypted, as you can see with PeID.
All the strings reported in CTCP version are located at the following offsets:

#HydraIRC on EFNet 0x9C44C
Dominic Clifton aka Hydra 0xC4318
v0.3.151 (19/November/2005) 0xC4334
HydraIRC 0xC9438