mIRC Home    About    Download    Register    News    Help

Active Threads | Unanswered Past 24 hours | Past 48 hours | Past Week | Past Month | Past Year
Scripts & Popups
12/06/19 06:29 AM
Apologies in advance I've only been playing around with scripting for less than a day.

I've made a bot that randomly says a quote anytime some says the trigger word by itself example

if someone says


The bot would trigger and say a random quote from a list.

Is there anyway to add a line in the script so the bot would pick up "Bananas" said in a full sentence.
Eg. "I'm going to buy some bananas today" and have the bot trigger?
0 59 Read More
Feature Suggestions
16/05/19 05:49 AM
Please allow users to be able to choose a server specific nickname in settings otherwise its a pain. This way you can create a server connection with a different nick than one in main easily. Thanks
0 80 Read More
Feature Suggestions
27/04/19 06:45 PM
Would love to see OOP features in mirc in the future like in other programming languages like C++, Python etc.

Would save on requiring tedious coding lines.

Also would love to have for loops in mirc also in the future! Thanks!
0 145 Read More
Feature Suggestions
20/04/19 07:24 AM
I would like to see extended floating point accuracy for outputs of smaller numbers that don't even 52 bit values. When working mostly less-than-zero values such as ratios and percentages, we are limited to only 6 digits of precision unless we arbitrarily multiply all of our values by 1 million or 1 billion in order to achieve a greater (useful) precision of the final product.

It would be nice to automatically have access to 12 digits of precision when working with smaller values, especially when they have to be multiplied with a previous product many hundreds or thousands of times. The errors do add up significantly, and it's rather painstaking to avoid.

Otherwise, if there's a library out there (in C++) that supports "big math" with huge numbers and infinite precision, I think many of us would really enjoy using that. $bigcalc() or something.
0 128 Read More
Feature Suggestions
27/03/19 11:19 PM
You can specify Favorite channels for given networks, but there's no way to navigate them by network. All channels are mashed together without a dropdown menu or folderization.

I would also recommend making this dialog twice or 3 times as wide to display longer channel names and descriptions. I could add the network name to the description if nothing else.

I am willing to help curate your default Favorites list, if you're interested in free work.
0 189 Read More
mIRC Help
27/03/19 08:17 PM
I have been using VPowerget to great success, but recently, it just started stalling and will only do one request at a time, if I manually right click at 'request now'. Any help you can provide would be greatly appreciated.

Kindest regards,
0 159 Read More
Feature Suggestions
26/03/19 07:18 AM
As a convenience to scripters and to speed up reads and writes to files, I would recommend that mIRC keep file handles open until a script alias, event or thread completes. This would in effect give scripts that use $read() and /write all the benefits of /fopen without the tedious nature of /fseek, $fread, and /fwrite.

It would not be unusual for mIRC to keep a file handle open until a script thread completes its task (or errors out).
0 262 Read More
Feature Suggestions
21/03/19 09:59 PM
Updated $encode Blowfish improvements wishlist.

1. New padding method 0-7 zeroes
2. New $encode format Base85
3. Restore no-limit hash(key length) for non-literal keys
4. A new switch to recognize key and iv|salt parameters as both being hex strings
5. New $encode format Hex.
6. New switch to defend against CBC bit-flipping of IV

(1) New padding method 0-7 zeroes
(2) New $encode format Base85

Since a likely use for the encryption is for channel messages, these would allow longer encoded messages within the limited length of a PRIVMSG. Comparing the 5:4 ratio of a base85 message to the 4:3 ratio for mime/base64, a 360 byte channel message would have a mime length of 360*4/3=480, while base85 would encoded it to only 360*5/4=450. To support the N chunk parameter, it could be the 60-character encoding of 48 bytes, though as you pointed out in an older post, UTF8 means encoding bytes can be split across 2 chunks, making the chunk parameter somewhat obsolete except for some variant of Uuencode which can have a variable chunk length preceded by a variable length-byte.

Also of consideration for shorter length is that Base85 doesn't need the padding which many version of mime expect.

The main reason for the new padding method is to allow 1/8th of all messages to be 8 bytes shorter, which means their mime encoding would be 10-11 bytes shorter. By appending 0-7 bytes, this padding method would differ from 'z' padding where it does not need to append 8 0x00's to a message that's already a multiple of 8 bytes. Since the 0x00 cannot exist in a UTF8 encoded text message, there would be no risk of incorrectly stripping the 0x00 byte belonging to the original message. This new padding method would be compatible with the existing 'z' when the message is a text string which can't contain 0x00's, or even a binary string with a format that can never end with 0x00.

The Wikipedia page for Base85 lists several kinds of 85-character alphabets. Unless there are considerations where it's helpful to exclude $ %, the RFC1924 variant is supposed to be compatible with JSON, and hopefully would be regex friendly.

(3) Restore no-limit hash(key length) for non-literal keys, as described here

(4) A new switch to recognize both strings in the 'key' and 'iv|salt' parameters as hex strings. Shouldn't need to have separate switches to have only one of the pair being hex.

As the examples here show, OpenSSL and the Crypt::CBC which $encoded has compatibility with both support allowing the passphrase|Salt|IV to all be hex.

Trying to force the literal key to always be a UTF8 text string greatly limits the number of possible valid encryption keys, and using UTF8 text can easily cause portions of the key to be silently ignored due to being pushed past the 56th byte. As mentioned here, the Salt|IV are avoiding the UTF8-encoding of codepoints 128-255 into 2 bytes each, but are silently replacing all codepoints 256+ with codepoint 63 "?".

The user may be unaware that, with and without the 'l' switch, the random characters have no effect on changing the encryption because the changing byte of the key is beyond position 56, and the random salt character is always replaced by "?", resulting in this command always having identical encryption.

//echo -a $encode(message,mcil,$str(a,55) $+ $chr($rand(192,255)),$chr($rand(256,10004)))

Hex strings would enable setting the secret key to all 2^448 values, and enable setting the Salt|IV to all 2^64 values.

(5) New $encode format 'Hex' to define the encoding format for the $1 parameter. This can be used in a way unrelated to Blowfish. If it needed to support N chunks, 30 bytes as a chunk of 60 encoding characters.

(6) New switch to defend against CBC bit-flipping of IV

The switch defends the first block of the plaintext message from being bit-flipped by manipulating the IV, without altering or garbling the rest of the message. This alias shows how an attacker can manipulate the contents within an encrypted message's 1st block if it uses CBC feedback. For this to work, the attacker needs to know only:

A. The exact not-encrypted plaintext bytes among the 1st 8 bytes of the message, which they want to change into something else.
B. The value of the corresponding byte positions in the IV used as feedback against block#1
C. The 'something else' they want to change those bytes into

They do not need to know the password.
They do not need access to the encrypted portion of the message or know the ciphertext.

This has nothing to do with Blowfish itself, it would affect any cipher in CBC mode having a public IV without an authentication string. AES would've had this same issue, where its 128 bit block size exposes double the number of bytes at the beginning of the message.

The new switch would be invalid in combination with 'e' ECB mode. The ECB mode is not vulnerable to this issue, because there is no feedback.

The syntax using the 's' switch is not vulnerable to this, because the salt hash generates the secret56:IV8 using a method which shields the resulting IV from someone who doesn't know the key.

Sufficient behavior for the new switch would be to continue storing the user-defined or RandomIV the way it currently does, but prior to being used by the encryption or decryption, there would be an ECB mode encryption of the public IV before the CBC feedback begins. The original unaltered IV would continue being stored in the encrypted message as part of the RandomIV header. This would shield the IV used by block#1 from someone who did not know the key parameter. The only compatibility issue with this switch is that decrypting without also using the new switch garbles the 1st 8 bytes of the decrypted message, but the remainder decrypts fine.

When the public IV is known, and the plaintext byte is known, each byte of the new IV becomes (old-public-IV-byte XOR existing-plaintext-byte XOR new-faked-byte).

As a test vector, the following command and output are:

//echo -a $encode(20190101 this can't be backdated,mcirl,foobar,text_iv8)
result: UmFuZG9tSVZ0ZXh0X2l2ODz3ktZrCBsKkBN1bgqwfXpp6x+aAa+5tRy95xUUyfdoSD/PXrNNWgo=

Note that the (Item#1) padding method would have shorter output due to not needing to append 8 bytes padding to a text string (or a string which would never end with 0x00) whose length was already a multiple of 8.

new pad result: UmFuZG9tSVZ0ZXh0X2l2ODz3ktZrCBsKkBN1bgqwfXpp6x+aAa+5tRy95xUUyfdo

When the IV is bitflipped, the stored IV changes, but the encrypted message is not altered:

//echo -a $decode(UmFuZG9tSVZ0ZXh1Xmp1ODz3ktZrCBsKkBN1bgqwfXpp6x+aAa+5tRy95xUUyfdoSD/PXrNNWgo=,mcirl,foobar,text_iv8)

output: 20181231 this can't be backdated

When using the new switch, where the public IV is ECB encrypted before being used to begin the CBC feedback, the encryption output changes to:


Both the attempt to bit-flip the output, or decrypting without using the new switch - would both result in the date stamp in the 1st 8 bytes being pseudo-randomly garbled, but the remainder of the message decrypts ok.

alias blowfish_CBC_bitflip_demo {
  ; next line should be one of the following choices: mcirl mcir mcr mcrl
  var %switches mcr

  var -s %key $input(Input any encryption key (encode uses only the 1st 56 bytes),e)
  if (%key == $null) goto enter_key

  var -s %original_message $input(Enter any Original Message 16+ characters (longer the better),e)
  if ($len(%original_message) < 16) goto enter_message

  var %fake_message $input(Enter 8 characters to change the beginning of the message into,e)
  noop $regsubex(junk,%fake_message,,,&fake_msg) | if ($bvar(&fake_msg,0) < 8) goto fake_message
  echo -a encode( %original_message ,%switches, %key )

  if (i isincs %switches) {
    var -s %iv $input(Enter any text string used as IV,e) | if ($len(%iv) < 8) goto enter_IV
    var    -s %old_mime $encode(%original_message,%switches,%key, %iv)
  else var -s %old_mime $encode(%original_message,%switches,%key)

  bset -t &encrypted 1 %old_mime | noop $decode(&encrypted,bm)
  bset -t &guessed_original_msg 1 %original_message | bcopy -c &guessed_original_msg 1 &guessed_original_msg 1 8
  bcopy -c &old_iv 1 &encrypted 9 8
  echo 3 -a at this point the attack begins, using ONLY the following info which does NOT include knowing the key:
  echo 4 -a assumes the first 8 bytes of the not-encrypted original message guessed as: $bvar(&guessed_original_msg,1-) $qt($bvar(&guessed_original_msg,1-).text)
  echo 4 -a knows the 8 bytes of the public IV are: $bvar(&old_iv,1-)
  echo 4 -a does not know the key, but wants to change the assumed 1st 8 bytes to: $bvar(&fake_msg,1-8) $qt($bvar(&fake_msg,1-8).text)

  ; now replace IV_byte with: old_iv_byte XOR old_plaintext_byte XOR faked_plaintext_byte
  var %i 1, %new_iv | while (%i isnum 1-8) {
    var %j $xor($bvar(&fake_msg,%i),$bvar(&guessed_original_msg,%i))
    var %j $xor(%j,$bvar(&old_iv,%i)) | var %new_iv %new_iv %j | inc %i

  echo -a now the attacker replaces the old iv $qt($bvar(&old_iv,1-)) with $qt(%new_iv) then lets the intended receiver decrypt the message
  bset &encrypted 9 %new_iv | echo -a noop $encode(&encrypted,bm)
  var -s %faked_mime $bvar(&encrypted,1-).text
  echo 3 -a this is the 1st usage of the KEY since the message was encrypted,
  echo 3 -a yet the attacker can change the 1st 8 bytes of the message, without knowing the key,
  echo 3 -a just by knowing the original not-encrypted bytes, without even needing to know how those 8 bytes were encrypted
  var %a %old_mime vs %faked_mime
  if (i isincs %switches) {
    echo 4 -a decrypt original: $decode(%old_mime  ,%switches,%key,%iv)
    echo 4 -a decrypt hacked::: $decode(%faked_mime,%switches,%key,%iv)
  else {
    echo 4 -a decrypt original: $decode(%old_mime  ,%switches,%key)
    echo 4 -a decrypt hacked::: $decode(%faked_mime,%switches,%key)
0 457 Read More
Feature Suggestions
18/03/19 01:53 AM
Dear Khaled, could you add this .htaccess file to your forums.mirc.com root?

RedirectMatch ^/?(\d+)$ /ubbthreads.php/topics/$1/#Post$1

I think I have that code right.
The idea is that links to:


get redirected to:


This would be rather handy on IRC channels.
0 203 Read More
Feature Suggestions
11/03/19 06:00 PM
/dll <filename> <procname> [data]
$dll(filename, procname, data)

Since /dll allows [data] to be optional, it seems reasonable that $dll() should also allow the 3rd parameter to not be present. This would allow procnames to receive a $null data without forcing a blank or dummy 3rd parameter. $dll(dllname,getdllversion,)

edit: looks like $dllcall is also requiring the data parameter be present.
0 151 Read More
Feature Suggestions
02/03/19 08:28 AM
1) Could mirc have a box which you could enter words so that the message would not be sent if it contained the censored word?

#schizophrenia on ircstorm.net is currently having a problem with a bot logging in every second with a new name and repeating the same line.

2) This feature would also be useful to prevent certain repetitive lines from being read out by the voicereader/ Speech.

Julian P
0 302 Read More
26/02/19 02:53 AM
This thread attempts to document the unique behaviors that mIRC will exhibit in response to server and network specific supported features. Features are often expressed via ISUPPORT 005 numeric (type /raw VERSION), or via CAP LS, REQ, LIST handshake (type /raw CAP LS). There are other signals that mIRC picks up during an IRC session that modifies its behaviors in how it handles network specific features or idiosyncrasies.

The goal is to document all the various deviations of expected behaviors in order to anticipate and understand them better.



If CPRIVMSG or CNOTICE appears in the 005 ISUPPORT list, then any time you are an op or voice in a channel that you share with another user that you wish to send a query (/msg, /query, ctcp) or notice (/notice, /ctcpreply) to, the IRC command CPRIVMSG will be used instead of PRIVMSG, and CNOTICE will be used instead of NOTICE. These commands enable you, as an opped or voiced user, to bypass certain server restrictions for the number of users you can message in a short period of time, or how much text you can send to them in a short period of time, or whether you need to gain the user's permission first before you are allowed to send them a message... depending on server implementation.

mIRC v7.53 29-Nov-2018
21.Added support for CPRIVMSG and CNOTICE. If listed in numeric 005,
   PRIVMSG and NOTICE will be automatically upgraded for most
   outgoing messages if you are an op/voice on a channel and message
   a user on the same channel.


If NAMESX appears in the 005 ISUPPORT list, then mIRC will immediately issue the command 'PROTOCTL NAMESX' to request NAMESX support. This will enable multi-prefix support by telling the server to display multiple prefix in NAMES responses, ie, when joining a channel. Though mIRC doesn't display the multiple prefixes on the user interface, they will be tracked internally and be known to scripts using 'isvoice' and '$nick(#,%i,v)' etc when a user is both an op and a voice.

mIRC v6.17 17-Feb-2006
18.Added support for numeric 005 NAMESX token, indicating that
   mIRC supports multiple mode prefixes for a nickname in a NAMES
   list, eg. @+nickname.

I'm going to continue this document on Wikichip for now.
You're welcome to help.

0 397 Read More
Scripts & Popups
25/02/19 06:03 PM
I have maded this:
Say GoodBye to Channel and Exit: {
  if (%GBMessage == $null) {
    /set %GBMessage $$?="Input GoodBay Message...."
  /msg $chan %GBMessage
  /timer1 3 1 echo <<- It's not works.. need help here.
  /msg $chan Ciao mamma guarda come mi diverto
  ; /leave

Instead the timer it's my idea to add a pause... like somethigs wait about 5 seconds after post the %GBMessage to channel and only after left from this channel using the /left commands.

How i can do it ?


Found myself solution apparently it's works:

  /msg $chan %GBMessage
  .timermsg 1 5 /leave
  ; /msg $chan Ciao mamma guarda come mi diverto
  ; /leave

Look also my comments TEST smile
If it's exist a better or alternative solution.. write it smile
Thanks in advance.
0 144 Read More
mIRC Help
24/02/19 01:59 AM
When i tried to update mirc i downloaded a new one and a prompt came up on the old version and asked if i would like to reload the scripts it and i clicked no because i didnt read it all the way. When i went back to msldev all of my scripts were gone. PLS HELP

UPDATE: I found them in appdata, sorry for the confusion
0 245 Read More
mIRC Help
19/02/19 12:06 PM
As with most software, new versions of mIRC are released every so often that add new features, fix bugs, and address security issues.

We generally recommend using the latest version of mIRC because it can include changes that address important issues.

Until recently, the mIRC website provided a download link for an older version of mIRC, mIRC v6.35, and recommended it as the only safe version for users wanting to use an older version of mIRC. All versions older than mIRC v6.35 are open to exploits. An exploit allows someone to gain access to your computer without you realizing it.

However, recent security fixes mean that mIRC v6.35 is now also not safe. Due to the number of bug and, especially, security fixes, we can no longer recommend using any older versions of mIRC.

The only version we can recommend using is the latest version available from the official mIRC download page.
0 737 Read More
Scripts & Popups
17/02/19 04:58 AM
Was wondering if someone could help with identifying how to capture text after a certain point and repeat it in a channel.

<jimmy> !quote johnny Something, something stupid & inane

i'd like to listen for !quote johnny
and then capture and repeat everything after that and issue a msg to channel-

<johnny> !unquote johnny Something, something stupid & inane

0 183 Read More
Feature Suggestions
16/02/19 06:21 PM
We currently count with a goto error, $error, and reseterror for handling errors, but we got no way of reporting errors directly. Therefore I suggest an /error command with the following format:

/error <error message>

which just as the built-in commands do, this will try to jump to the :error line and echo the error message and halt the script if there was no /reseterror.


alias test {
  if ($1) return success
  error $!test: insufficient parameters
alias testing {

  echo -s Testing received error message: $error



should output:

Testing received error message: $test: insufficient parameters (line 6, test.mrc)

and calling from an edit box:

//noop $test

should output:

* $test: insufficient parameters

0 204 Read More
Feature Suggestions
15/02/19 03:25 PM
mIRC has a feature to automatically trim lines from a window after it reaches 5000 lines or so. I would like to request to have this feature extended in a unique way.

Allow for the trimming of select Event messages after they bubble up above N lines from the bottom and the lines are at least N minutes old. For instance:

Trim Channel Event Messages:
[x] Older than [ 5 ] minutes
[x] Older than [ 20 ] lines
(o) If Both  ( ) If Either
For the following Events:
[x] Join  [x] Part  [x] Quit
[x] Nick  [ ] Kick  [ ] Mode
[ ] CTCP  [ ] Topic [ ] Notice

This way, channels don't become so cluttered and conversations are easier to follow.
0 187 Read More
Feature Suggestions
14/02/19 10:40 AM
I wish to request extending the $server() identifier to support a numeric value for the optional 'group' parameter, to reference the N'th group, to allow for iterating through each of the server groups (ie, networks) without having to know them by name beforehand.

$server(0,0) == number of server groups
$server(0,1).group == name of the first server group
$server(1,1).group == name of the first server group*
$server(0,1) == number of servers in the first server group
$server(1,1) == first server in the first group

$server(0,1).group and $server(1,1).group might return two different values, if that server address happens to belong to two different groups. This is why $server(0,1).group or $server(,1).group should definitely return the group name and not just the server count.
0 157 Read More
Scripts & Popups
08/02/19 11:17 PM
So I'm trying to figure out how my bot can count emotes on twitch. For example: if user types in more than 15 emotes the bot will trigger a timeout for the user. Any help on this?
0 182 Read More
mIRC Help
08/02/19 09:34 PM
I'm trying to set up my bot to work for subs but the issue I have is getting the room id. I used this thread for help: https://forums.mirc.com/ubbthreads.php/topics/258923/Re:_(twitch_bot)_CANNEL_ID_OR_

I did everything it said but I still get no number after typing in chat. http://prntscr.com/mikka9

Not sure what I'm doing wrong but any help would be appreciated.
0 241 Read More
Latest News
08/02/19 10:41 AM
Dear mIRC User,

mIRC v7.55 has been released today.

This version of mIRC is primarily a security release. mIRC users are advised to upgrade due to a security issue that may allow someone to trigger a remote code execution vulnerability in some situations. This issue affects all versions of mIRC. This update also includes changes and fixes to a number of features:

Fixed /onotice and related commands not working correctly in some contexts.
Fixed Clear History log files option not deleting empty nested folders in logs folder.
Fixed $sha1()/$hmac() bug that caused &binvar data to be overwritten.
Added $zip() identifier that adds support for AES encrypted ZIP files.
Extended $rand() to allow negative number values and changed RNG algorithm.
Added $rands() identifier that returns a cryptographically secure random number.
Fixed $hfind() not reporting an error when the called alias returns an error.
Fixed $asctime() 'z' bug to work with non-standard offset timezones.
Extended IRCv3 support for CAP NEW to request supported tokens automatically.
Fixed RCE vulnerability affecting all versions of mIRC (CVE-2019-6453).
Added $notify().sound2 property to return offline sound.
Updated CA root certificates cacert.pem file.
Fixed "Show nicks on join" option not working correctly.

How to upgrade?
mIRC is distributed in an installer that installs mIRC on your computer for you. Simply download and run the installer from the download page on the mIRC website. Follow the instructions the installer gives to you. When upgrading all your old settings and scripts will stay as they were, if you want that. Read the questions the installer asks with care and nothing can go wrong. You will be chatting with the new mIRC in no time. If you get stuck or if you want to find out more about a certain feature, just click on a Help button or browse the Help file and you should find lots of hints to help you out.

Where to download?
As always, the latest version of mIRC can be downloaded from the download page on the mIRC website.

Registering mIRC
As you know, mIRC can be downloaded freely and evaluated for 30 days. If you find that you enjoy using mIRC, it would be great and much appreciated if you registered your copy. This licenses you to keep your copy of mIRC and helps to support our continued work on mIRC. You can find out how to register here.

Full list of Fixes, Changes and Additions.
For a more detailed list of recent changes, please see the whatsnew.txt file. You will need to read through the help file to learn more about these changes and their impact. Some changes are obvious, some need getting used to - please take your time to play with them and see how they work. May we invite you to use these forums for all questions you might have? The forums offer great help with everything related to mIRC!

Thanks for using mIRC, have fun on IRC!
0 6,698 Read More
mIRC Help
01/02/19 03:37 AM
Jump to new posts JTV [by TroyL]
So in mIRC for Twitch jtv sets modes to moderators. But jtv is only setting modes in some channels that im connected too instead of all of them. Any help?
0 219 Read More
mIRC Help
31/01/19 03:17 PM

How can I contact, for adding an Dutch server, toe the server list?
0 207 Read More
Feature Suggestions
24/01/19 09:48 AM
Can we have a more customizable line spacing between the lines? Some clients are personalizable through theme scripting and some others have it fixed, I only see three options in mIRC but I'd really like to see a wider range.

0 3,072 Read More
Page 1 of 3 1 2 3