mIRC Downloads - scripts, addons, dlls, themes, code

Please Disable Ad-Block To View This Website.

If you block ads, this site can not survive!

Ads are very minimal for registered users. If you don't have an account please register now!


Home	Search	Site Map	About Us

DOWNLOAD

Addons

DLLs

Misc.

INTERACT

Challenge

Forums

Site Search

FRIENDS

Link to us!

Home | Comments:

mIRC On The Fly Version Changer v3.05 by danielson

Download

Description:

This is a nifty little addon that will change your version reply using a dll. No hexing, using debug.logs, or sockets.

Update:
A few changes regarding optimizations. Also fixed two memory leaks which can drain your machine of usable RAM.

Submitted Review Author's Updates

There is no review for this file yet.

February 24th, 2002:
mIRC On The Fly Version Changer, version 3.

Updated for mIRC 6.0+ only.

It's finally here, mOTFv3 which supports multiple servers, and the ability to halt version requests entirely. It's more flexible and also much smalller (7.5 KB dll)

Enjoy.

March 23rd, 2002:
-Fixed GPF resultant from two copies of mOTFv being loaded (Thanks Deke)

-Backwards compatibility (Now supports all dll-enhanced versions)

Screenshot:

No
Screenshot
Available

Comments:

Qc	Jul 3, 2006 1:47PM

I'd say it has problems with SSL connections, i never had problems before and since i'm connecting using SSL to certain servers, it returns errors on those alone, and the mirc default reply is sent.
OK Synchronized w/9 servers
20060703-181104 [RizonMon VERSION]
20060703-181104 -Global- [Logon News - Apr 26 2006] Did you know? Rizon now offers SSL IRC connections! All servers support SSL on ports 6697 and 9999. Questions on SSL? Need help setting it up? Join #SSL
!mOtFv3! Unknown command
20060703-181105 Local host: ***
!mOtFv3! Unknown command
!mOtFv3! Unknown command
!mOtFv3! Unknown command

Sometimes a dozen in a short time.

Text edited by author on Jul 3, 2006 @ 2:36PM

danielson

Sep 12, 2006 1:05AM

Qc, you are correct. mOTFv3 is not compatible with SSL sockets. It's probobaly doable but I wrote it before SSL was even an option w/IRC servers let alone a release of mIRC. I do not plan on upgrading it either.

Who needs SSL for IRC anyways? It's not like your bank records or at stake, or that SSL is going to protect you...everything you do on IRC involves talking to other people which no form of crypto can secure...

Just seems paranoid to me, but whatever floats your boat man.

Regards, "danielson"

scar	Oct 2, 2006 1:41AM

i for one would be grateful if you added support for SSL sockets. together with mircryption, IRC can be totally secure. it is yet another secure medium we can use to protect our privacy, which even the least paranoid should be concerned with. ;) please do not assume no one needs anything (SSL) for anything (IRC). we are all un-alike ;) instead, try to cater to every possible scenario within your software. if it is probably doable then it would make your software that much better.

Qc	Mar 24, 2007 2:48PM

Well, the scripted versions rely on the reservation of /debug and ignore all ctcps, leaving your dll as only remaining choice besides altering mirc.exe, which is not really acceptable since it isnt legal and forces users to update mirc the same bogus way.
Regarding who needs SSL, I dont need it personally, but if I see alot people use it, and more and more servers support it, IRCd's providing channel modes that allow only SSL using users, and Mr. Khaled supported it too in mIRC, it's obvious quite some people consider it worthwhile, so making provisions for it in my script is a logic choice if I want as many users as possible happy.

Basically, the "SSL or not" question is the same as the "hide or not hide which irc client you use" question.
Anyways, it is your work, your time, and your choice. I can only ask. I found and find this dll useful. SSL support would just make it even more useful.

danielson

Jul 5, 2007 5:35PM

I don't have the source to 3.05, I have a slightly-modified version of it ( I was debugging it for some potential changes, then stopped working on it)...

I would be happy to give somebody the source that I do have (full of extra debugging-related crap)....if they wanted to attempt an SSL upgrade...

All I ask is credit for the source and version-stability (like mOTFv 4)....

However....this will not be an easy task to implement which is why I refuse to attempt it....

The reason? SSL is designed to prevent this kind of thing...

mOTFv3 works by hijacking the sockets mIRC uses to connect to IRC...

the !mOTFv3! Unknown Command error you guys have been noticing when connecting to SSL is a behind-the-things thing mOTFv3 does to determine
which socket goes to which server...

Basically it works like this....

When you load mOTFv3 (I think it's the Load command)...

It looks up some details it will need to hook.
It opens up a callback file-map with mIRC (so it can send commands or get information from mIRC)
(This only works for callback-enabled versions of mIRC, which pretty much everyone uses these days)...

It checks the version of mIRC you're using...

Dependent on the version of mIRC you're using, the method of syncing (sync command) differs.
Basically, if you're using a version of mIRC that doesn't support multiple-servers it queries mIRC using $server
otherwise it uses $scon...

Once it has a list of all the servers you're currently connected to, it "hooks" into mIRC, a programming-term that basically
describes the action of intercepting a function or event without the host's knowledge, kind-of like a parasite...

Once it's hooked, it has FULL access to everything mIRC sends or receives over the internet and can modify/block as it wishes..

Then, it tells mIRC (through its callback, to execute the following)

/scon (server #) raw -q !mOtFv3! followed by (the server number):(mIRC's process Id)
(Note, for single-server versions of mIRC, it just uses the basic /raw command, same info sent)

This extra bit of info is included to prevent scripts or (the unlikely) mistake of sending out the !mOtFv3! command to the server
yourself... If mOTFv3 gets it it will stop it (assuming all the information is correct)...

This may seem confusing, but here's what it's actually doing...
mOTFv3 gets access to all data received/sent from mIRC (before anything useful has been done with that information).

This means when someone sends a NOTICE to you on IRC, mOTFv3 gets it first, then sends it to onto mIRC...
When you send a NOTICE to someone else, mOTFv3 gets it and then passes it onto Winsock and finally out to the internet.

The problem is, mOTFv3 doesn't immediately know which socket is connected to IRC servers, that's why it tells mIRC to send
!mOTFv3! to its connected IRC server... mOTFv3 waits for mIRC to send this packet, and when it detects it...it knows which socket is associated with which server.... And that's really all the sync command does, it hooks mIRC and tells mOTFv3 which sockets to pay attention to..

After that, it listens for VERSION requests and modifies them to MOTFV requests so that a scripter can do whatever they want...

P.S. As you should see now, this is why you have to resync whenever you connect to a new IRC server...

So then, why does SSL break mOTFv3? Because mIRC is sending and receiving encrypted packets, that only it and the IRC server has the keys to..

Therefore, when mOTFv3 tells mIRC to send "!mOTfv3! blah", it first encrypts this information, then sends it...
Therefore, mOTFv3 doesn't see the command and it goes to the IRC server, is decrypted, and finally comes back as "!mOTFv3 Unknown Command" on your screen.

I don't doubt that SSL could be broken for this purpose, but I'm not sure it's worth the trouble... Unless mIRC provides a scriptable way to get the keys, it's a shot in the dark.. You could read the SSL keys straight from mIRC's "Image" (RAM)...but this location would likely change from version to version of mIRC and is not practical...

P.S. I don't know much about SSL, so you may have some objections to what I've said, just my two cents...

ch1zra

Feb 25, 2005 10:47PM

I like it... I probably won't use it, but I still like it..

There are two ways of looking @ this :

1. nothing is sacred, there's no point in making any new software cause some1 will ripp it in a few days...

2. people try to "change the unchangeable", and they are doing it. this just means that proggraming community has some realy briliiant minds, and this is good (or am I maybe wrong ??)

all in all, great work :]

PS (I know that my english sux0rz :P)

danielson

Apr 13, 2005 7:49PM

Hey....I dig compliments.
Thanks.

Imrahil

Feb 22, 2005 1:58PM

Could you give us the source code, or a good example of how to change standard replys?
Im Interested if this method will work on other replys too, so join the OS Community ;)
Imrahil

myggan

Nov 12, 2004 9:24PM

What's the fking point of changing the version reply? I don't get this, the version reply should contain:
1. the name of the CLIENT, not the name of your script-collection aka full script
2. credits to the author of the CLIENT, again not your stuff.
I don't see anything wrong with adding a cutsom reply as long as you leave the default one intact.
but I guess I can't blame you all, it is kinda fun to be all elite and changing the "unchangeable" version reply. oh God.

seec77

Jan 19, 2005 3:57PM

Lots of people change the version reply to include mIRC, and credits for the full script.

myggan

Jan 19, 2005 4:35PM

I can only speak for myself when I say that I don't give a rats ass about what full scripts people use, I only want to know the client name when I version people.
I guess it's ok as long as you leave the default version reply and append your information at the end.

But then there are those who just don't care about the credits and replaces it w/ their filthy piece of crap,
I for one absolutely hate people who takes other persons work and claiming it their own (which you probably can tell).

Alan	Jan 21, 2005 2:15PM

Just because you think its lame to change it doesnt mean everyone else does...

myggan

Jan 21, 2005 5:30PM

I'm well aware of that, I'm merely stating my opinion, which I'm entitled to do.

wshs	Dec 19, 2004 4:22AM

With the implementation of SSL support in mIRC, this DLL becomes obsolete. Is it even possible to hijack version requests on SSL connections?

tcairns

Nov 12, 2004 6:19PM

I'd just like to say that this script is brilliant, I found out about it yesterday, and I now use it all over the place, I thank danielson for actually making it!

Jinx	Aug 29, 2004 8:32PM

why would you want to use a dll when you can easily use debug ?

Andy	Aug 29, 2004 11:34PM

1. This DLL was out way before the debugging method was used
2. Easily? I'm sure you couldn't do it as easily as this DLL

seec77

Jun 9, 2004 3:54PM

Why don't you release the source to your DLL?
You should... the OpenSource community is great!
Plus, others can benefit from looking at your code!
It's not like you were going to make money from your code anyways...
Just a thought!

Thanks,
seec.

gabrielevans10

Jun 28, 2004 6:46PM

quote:
seec77 said:

Why don't you release the source to your DLL?
You should... the OpenSource community is great!
Plus, others can benefit from looking at your code!
It's not like you were going to make money from your code anyways...
Just a thought!

Thanks,
seec.

I agree with you.

seahorse-br

Feb 18, 2003 11:15PM

lalalala :)

Text edited by author on Feb 18, 2003 @ 11:15PM

Create New Post

You must be logged in to post messages.