Forums Scripts & Popups CTCP VERSION Masking

Is there a way to mask the CTCP VERSION that mIRC returns?

No.

-genius_at_work

Well, that isn't no fun!

Yes there's a way.
.
.
..

..
.
.
..
.
.
.
Write your own IRC client

Yes.

LoL everytime I post a dll i get told off by other ops

Well the way I see it is, nowhere in the mIRC license agreement does it state that halting or changing the version reply is forbidden. The only mention of it is in the help file in the Ctcp events section where it states "Note: You can't prevent the standard version reply from being sent." meaning you are not able to prevent the standard version reply from being sent. Well that was written long before this dll was written so that is no longer true. Also, I think we should be able to choose to not send a version reply at all. That's what I use it for, not to change it.

I personally am proud to be using mIRC and want everyone to know it kind of in a way. So I don't care if they version me + doesn't get me banned off servers that need a version reply or your booted off

It's not that I'm ashamed to be using mIRC, if that were the case I would just change it to reply whatever client I wanted. I just don't want to reply at all because of 1) target change errors and 2) I just don't want to reply.

I'm not ashamed of using mIRC either, just that on this private server, I'd like it to reply like the java programs do, so the sop's don't kill.

Well you shouldn't use this for that purpose.

yes.. and without use of dlls... you can change version reply using /debug...

You can not legally hide or alter the default version reply from the mIRC executable. If you do, you are in violation of the EULA.

The license agreement doesn't say anything of the sort. Hacking the exe to remove or alter the version reply would be a different story, but not using a dll or scripted solution.

I'll double check the EULA

It may not technically be in the EULA but it's clearly not in the spirit of the license agreement. You can use a DLL to do any sort of modification of an executable (removing nag screens for instance) without having to actually touch the contents on disk, but that doesn mean it's "right".

I don't think changing the version reply is or should be supported here, frankly. If Khaled wanted people to change the reply he would not have put a fence up around the CTCP VERSION event. I think that settles the official sentiment on the issue, whether it's written in the EULA or not. Those who don't respect the authors wishes can feel free to write their own client free of all restrictions. Until then, the "version" of mIRC should always be "mIRC" and Khaled should get his credit where his credit is due.

Keep in mind that even in Open Source Software it's illegal to claim someone else's work as your own. It's called a copyright violation and needs no EULA to be enforced. Changing the version reply to say you're using "MY IRC SCRIPT" without mentioning mIRC would be doing just that.

Notice that I discouraged using the dll to replace the version reply with their own. Yes, that would be wrong, but I don't find anything wrong with stopping the reply altogether. This can already be done by ignoring CTCPs, but I don't want to ignore ALL CTCPs, only certain ones, one of which happens to be version requests. We should already have this option.


No thanks. I'll just continue to stop version replies altogether with the dll.


Says you, the authority?

Yes you can legally hide version replies. The eaiset way would be to ignore all ctcps. this can be done by doing /ignore -t @ this will ignore all ctcps not just version requests. /help /ignore check the -t parameter. so if you rely on ctcp's (i dont know anyone who does) it may be not be good otherwise its a great LEGAL work around

I have no idea why one cant change the version reply!! especially when FREE clients offer that option. It has been requested by users many times and i think its selfish of the mIRC team not even to acknowledge this popular request even in the slightest way.
I personally don't care about my version reply. But it annoys me that a popular request like this one has not even had a tiny hint of acknowledgment especially being people pay for this program.

Sorry but when I said "hide" I meant hide mIRC's reply and show something else. I was not referring to ignoring a version reply altogether.

The fact that something is popular doesn't necessarily mean it's right. Copyright theft is indeed very popular nowadays, but that doesn't mean people should be allowed to steal software and music. Do you really think there's any justification for somebody wanting to claim mIRC as their own software? That's what changing a version reply is.. I can't imagine any valid justification for that. Surely nobody deserves to claim authorship of mIRC but Khaled himself.. in that sense- you either show the correct version or you don't show any at all. Sounds fair to me. If you don't like it, use one of your "free" clients.

In the end, Khaled wrote mIRC, you did not. So why should you want to tell people otherwise?

This is true for all software. Changing the version information to make it appear to be something else is the same as claiming it's yours outright. People used to (and probably still do) do the same thing with Invision by changing the logo/version reply. It's rather rediculous to do so.

yes there is a way - but it is looked down on apparently from many folks. i myself just add in an extra ctcp reply along with the standard since i wrote my own script

Tbh, i don't see any problem with the last one, so why should people look down on it? lol
It still clearly acknowledges Khaled and mIRC.

However, i do not see any point in changing the whole version reply, to something else... thats just lame.

As some1 said earlier, if you want to be able to change it by using one of the free irc clients, go ahead, their creators obviously don't care. But seemingly Khaled does care, and you should respect his decision, after-all, if he didnt create mIRC, you wouldn't have ever used it, and you wouldn't be here now.

So why not have an option to switch off the version reply but not alter it. I think most users who are an favor of CTCP masking do not want to change it to make as if they wrote the client. That is just a ridiculous assumption. They just want to hide it.

Whether its logical to you or not it has been a very popular request in the past and it has been entirely ignored. My criticism really is not so much in the fact that there is no option to hide it, nut in the fact that this issue has not even been addressed in the slightest way by the mIRC team.

As paying users i think we do have the right to make suggestions to what we want in the client. The mIRC team also has the right to say no. But the fact that nothing has been said about it makes me wonder if they care about what we want.

I did not start this topic and at the moment do not care about the CTCP replies etc, but it has come up so many times that i honestly think that something should be said by the MIRC team to stop it once and for all.

If you want an answer from Khaled you should e-mail him directly. You can't ask a question in a random forum on the boards and expect him to be scouring every one to find anything that he might be expected to answer.

Why change the reply it doesn't hurt anything even if it's shown what? You want to be elite and not let your friends know your on windows using a win 32 app and pretend your on linux? Why else would you hide the reply, I see many people all over dalnet,efnet etc.. that pretend they are on linux but yet you pop a version reply and they using nothing but mIRC.

This is not a random forum it is the official mirc forum. Also it has been brought up a TON of times before and it has been completely ignored. It is not just an oversight why it has not been addressed. Having seen previous posts and snippets of yours i am genuinely surprised and taken aback that someone of your stature would give such a meek reply.

Additionally lpfix5 this is not about whether it is sad to hide a version reply. It is about taking a popular user request seriously. To discuss the IQ level of a user who wants to mask his reply will be changing the thread of the topic.

Yes but it's the scripting forum of the mIRC boards. I'm not sure I've seen Khaled respond to a post in here in 8 years (although to be fair I don't view every one so I can't be sure). Whether he reads any or not I don't know, but asking here means there's a good chance he's simply not going to see it. It has been posted in Feature Suggestions once or twice, at least once in the last year it seems - and typically enough it got out of hand/off-topic as clearly some people feel very strongly about it one way or the other. And frankly I think that's why you probably won't get a direct reply from Khaled on any forum of these boards - from what I've seen he generally tends to avoid confrontational threads (a wise move) which is why I suggested you're better off e-mailing him if you want an answer. Of course Khaled reads the Feature Suggestions forum, so I'm sure he's seen the suggestion before and the fact that he hasn't added the support might be his answer in itself. On the other hand it might be on a todo list.

Personally I've always assumed the reason it was unblockable was on account of the number of repackaged mIRC's you can find that are bundled with scripts that try and pass off the whole thing as their creation, however not so long ago mIRC added the .exe renaming restriction which is a less intrusive means of getting credit where it's due so who knows, maybe suggesting the feature again --either on the boards or via e-mail-- might see different results.

As far as the rest of this thread goes, there's no legal reason why you can't block the version response (EULA or copyright related) so the only reasoning someone might have for not doing it is moral. I don't see any moral reason why you shouldn't block it or even change it if you want, although on the flip-side I don't see any practical reason why you'd want to. To each their own I guess.

Is it wrong to change the version reply to report another name or version? Yes, of course it is. That would be very lame. I don't really think anytone here wants to do that. I don't want to change the reply to rIRC v7.19 RoCk, I just simply want to stop it from replying at all, and for no other reason than I don't want to reply. It is sending a message that I don't want sent. This can already be done by ignoring CTCPs, but I don't want to ignore all CTCPs, yes I do use them. We should already have this option. To each their own is exactly right. I suggested a long time ago that an ignore flag be added to ignore version requests, but it went ignored. It could be in the options dialog, select it to ignore version requests, deselect it to unignore.

~ Edit ~
This all also goes for all built-in ctcp replies... version time clientinfo finger ... whatever else there is.

The problem is that a lot of people do. In fact, (this may be an assumption) it seems to me that it's actually what the OP wants to do.

I have no problem with an ignore option as well, as my posts above state. Ignoring is fine- changing is not. If Khaled is to do anything about this issue, that's what it should be. Problem is, it's probably not the ignoring part that's the "popular" request.

You're probably right, I'm sure some do want to change it. The thing is, if it were done in a way to only just not reply, then someone could just script their own reply. So it would have to ignore/discard any incoming ctcp version requests. If the user wants block mIRC's version reply, then it's only fair that ALL version requests be ignored imo.

Update: An elegant method for stopping the version reply can be found here.

I just wanted to add that not everyone using mIRC is pretending to be on Linux
I am on Linux and am using mIRC (via Wine) with a license I purchased at a full price.

Heh. Way to necro a 9 year old thread Welcome to the forums!

I guess while we're here...


Alternately...


Alternately...

Hey humans. I'm updating this thread, because the 3rd one isn't working anymore, and I assume ditto for the others. The reason is that IRCv3 @tags are now being put at the front of the strings seen by ON PARSELINE, so they no longer match. These optional tags at the beginning of the string can be identified by being a token that begins with the '@' character. So the Regex pattern needs to change by allowing for the optional presence of this string. The 1st 2 patterns also search for 'not a colon', but that's a valid character in a @tag, so it's possible that the pattern could dump you out in the middle of a tag instead of where it should be.

In addition, I found this not working at one network where it turned out that the reply to the version check was going outbound as a CNOTICE instead using the normal NOTICE keyword. I don't know if this is still happening, so I allow for it just in case.

So if you use the first 2 methods, you should modify the first 2 by inserting the string...

(?:@[^ ]+ )?

... immediately following the ^ symbol at the beginning of these patterns.

For the 3rd outbound, that stopped working once mIRC started attaching a tag like @label=1234 in front of outbound messages. This forwards whatever tag, if any, precedes the outbound version-reply, and also works with CNOTICE


* *

The other common ctcp's that people like to use to snoop at you are with TIME and FINGER. With CTCP TIME, they find out the time your pc clock is set to, which often indicates which country you are in. With CTCP FINGER, the default reply tells them the 'name' and 'email' you've input into your alt+E window, and also gives your $idle value, which tells them how recently you've done something in your client to reset that, which can be using the editbox to send a message to to a channel or query window on that network, but it can also be executing a //command in an alias which doesn't even involve sending traffic to/from the network.

You can either halt these without sending the message first, or you can send back a fake reply first. Both of these examples let you see the incoming CTCP request and shows your reply.

This one sends back an obviously wrong time, as a random time of day sometime on the 1st day of epoch:


If you're an @op that doesn't want spammers to get an idea from your clock if you're going to be there to stop them, instead of returning a random time of day, you can just have it return the same time all the time, picking a time that makes it look like you're going to be there.

This one replaces the default finger reply


This one allows the default reply to go out without halting it, but first it sets the $idle value to a fake number. But it also users a timer to reset $idle back to where it 'should be'