mIRC Home    About    Download    Register    News    Help

Print Thread
CTCP Version reply internal timer (7beta) #220166 06/04/10 04:05 PM
Joined: Jun 2009
Posts: 6
D
dev0 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
D
Joined: Jun 2009
Posts: 6
Until now, mirc has had an internal timer on version replies.

so it wont reply to a version request from the same nick more than once every 10 sec.

in mirc7 that timer is gone.

I know of many networks that rely on that delay to catch bad bots that pretend to be mirc clients but are in fact bottlers/catchers and other malicious bots..

in my opinion the 10sec delay should be re-added to avoid mass akills on various networks of people using the new mirc client, and to help keep irc clean from malicious bots

Last edited by dev0; 06/04/10 04:05 PM.
Re: CTCP Version reply internal timer (7beta) [Re: dev0] #220169 06/04/10 06:32 PM
Joined: May 2008
Posts: 16
V
Vilius Offline
Pikka bird
Offline
Pikka bird
V
Joined: May 2008
Posts: 16
Are your mIRC Options -> IRC -> Flood -> Limit CTCP replies checked?

Re: CTCP Version reply internal timer (7beta) [Re: Vilius] #220170 06/04/10 07:48 PM
Joined: Jun 2009
Posts: 6
D
dev0 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
D
Joined: Jun 2009
Posts: 6
Not the same thing..
It was not an option you could turn on/off it was a hardcoded limit. And i hope it will be put back.

Re: CTCP Version reply internal timer (7beta) [Re: Vilius] #220171 06/04/10 07:51 PM
Joined: Feb 2006
Posts: 32
Daveoh Offline
Ameglian cow
Offline
Ameglian cow
Joined: Feb 2006
Posts: 32
I have the same outcome (7.0 has no delay between version CTCPs) using the same settings as 6.35 (Limit CTCP replies).

I don't have a problem with this however.

Re: CTCP Version reply internal timer (7beta) [Re: dev0] #220195 07/04/10 07:28 AM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I would be pretty surprised if any networks actually use this kind of a heuristic to ban clients. Certainly there are many legitimate clients out there with no such a timer, are they being banned? If this check is specifically targeted for a version reply containing mIRC, I see no problem in having these network admins modify their rules-- they would have to, and I'm sure they would.

That said, there is a good reason to re-enable the hardcoded flood check: the version reply cannot be halted via scripts, and /ignoring all CTCPs is not always warranted. Also I'm sure some users prefer to use their own scripts to manage an ignore list or flood control, so having mIRC at least have a sane default would help.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: CTCP Version reply internal timer (7beta) [Re: dev0] #220197 07/04/10 10:56 AM
Joined: Dec 2002
Posts: 4,895
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,895
All flood protection has now been integrated into one routine and this item is now available as "Limit CTCP replies" in the Flood dialog. The heuristics have changed slightly as well, allowing only a certain number of CTCP replies within a fixed time period, which offers much better protection.

I am not sure it would be possible to keep mIRC behaving in one way or another based on how each IRC network bases its bot-detection. The way mIRC behaves changes with almost every version, as features are tweaked, bugs are fixed, etc. It would be difficult even if I knew the specific heuristics that each network used.

Re: CTCP Version reply internal timer (7beta) [Re: argv0] #220205 07/04/10 03:43 PM
Joined: Jun 2009
Posts: 6
D
dev0 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
D
Joined: Jun 2009
Posts: 6
"I would be pretty surprised if any networks actually use this kind of a heuristic to ban clients. Certainly there are many legitimate clients out there with no such a timer, are they being banned? "

I know for a fact that many networks use it as a part of their protection, small and large, they do not get banned solely based on that result of course.But until now, all legitimate versions of mirc would never reply to 2 version replies from the security bots within 10 sec, with the standard mirc version reply.

There is a lot of bad bots that pretend to be mirc clients, that will reply with "mIRC vX.XX Khaled Mardam-Bey" but they do not have the hardcoded limit, so its an easy way to spot them, and do more checks.

This include ddos bots, hacked xdcc boxes and other malicious clients that shouldn't be allowed on irc. And such an easy way of spotting suspicious clients and watch them closer shouldn't be removed.

In my opinion, the limit to the version reply should be put back.
Why "fix" something that wasn't broken and something that people has started to rely on.

Anyways, keep up the good work.

Re: CTCP Version reply internal timer (7beta) [Re: dev0] #220213 07/04/10 06:02 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
It seems like those networks will simply have to modify that heuristic. Given that a bot maker could easily emulate mIRC's delay regardless of what mIRC does or does not do (and this server check is now documented on the official forums for all to see), I really don't see how effective or "reliable" such a check really is, but I guess I don't have the data to look at.

As Khaled pointed out, the internal hardcoded limit is no longer necessary thanks to improved flood control handling. Since the feature was primarily meant to users don't get flooded off an IRC server and not so it would bypass a bot-check, this change makes the interface more consistent.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"