mIRC Homepage

CTCP Version reply internal timer (7beta)

Posted By: dev0

CTCP Version reply internal timer (7beta) - 06/04/10 04:05 PM

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
Posted By: Vilius

Re: CTCP Version reply internal timer (7beta) - 06/04/10 06:32 PM

Are your mIRC Options -> IRC -> Flood -> Limit CTCP replies checked?
Posted By: dev0

Re: CTCP Version reply internal timer (7beta) - 06/04/10 07:48 PM

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.
Posted By: Daveoh

Re: CTCP Version reply internal timer (7beta) - 06/04/10 07:51 PM

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.
Posted By: argv0

Re: CTCP Version reply internal timer (7beta) - 07/04/10 07:28 AM

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.
Posted By: Khaled

Re: CTCP Version reply internal timer (7beta) - 07/04/10 10:56 AM

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.
Posted By: dev0

Re: CTCP Version reply internal timer (7beta) - 07/04/10 03:43 PM

"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.
Posted By: argv0

Re: CTCP Version reply internal timer (7beta) - 07/04/10 06:02 PM

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.
© 2021 mIRC Discussion Forums