And where would mirc store its key? The rol.vbs method of infection you mentioned can be used to launch any payload of any type, as an .exe the trojan would have access to the same information the mirc.exe does. Maybe mIRC could use an obscure encryption of some sort, but the point of encryption is to keep data safe even when the decryption method is known, how long would it take for someone to figure it out?
I think the first 'stop' shouldn't be restricting commands/identifiers, but simply stopping mirc from loading the files in the first place. With a 'safe' .ini, we could hopefully assume that the remote files in the list are legit. mIRC could also monitor the .ini and remove remote files that 'appear' in its rfiles section while it's running. Keeping its own version of the .ini in memory and flushing it to disk on close/at set durations would make modifying the .ini rather pointless (nearly). A mutex on the file could prevent read/write access, but would kinda stuff up multiple instances.
To LocutusofBorg: my mIRC should be more insecure than it has to be because of 'ignorant people'?..... Righhhht.
