If you lock $decode in the Options Dialog, $utfdecode will also be locked.



I'd suggest this behavior should be removed since there's no real security risk in using $utfdecode.

Well, $decode in itself is also not a "security risk", but it can be used in combination with social engineering tactics that make it one.

But this is nevertheless a good point-- given that 7.x now has Unicode enabled all the time, there should be no scenario where $utf(de|en)code could create obfuscated text for the a client.

$utfdecode() can be used in the same malicious way as $decode() because some of the charsets that mIRC supports don't include the latin alphabet

I'm under the impression that mIRC 7.x only supports a single charset (unicode). Is this not accurate?

it's the $utf*code identifiers that support other charsets :P

$utfdecode(txt , C) can be used to convert text to Unicode as though it were a series of bytes in charset C. one or more of these charsets contain unreadable characters where the latin alphabet should be. just as $decode(unreadable text, m) can be used to hide readable text/code, so too can $utfdecode(unreadable, C) for certain Cs.

Then mIRC could lock only when C is specified. However, I'm a little dubious as to the statement:



I'm under the impression that all "charset" values of C are just ANSI codepages, but all ANSI codepages share the same ASCII range. So it would seem that there would be no value of C that would create an unreadable builtin command name (since all builtin commands are ASCII).