Forums Bug Reports Allow DCC reception with exploit blocking (ver. 2)

You can allow DCC reception with exploit blocking by using /debug -i filterfunction, if you know what you're doing. You simply make the filterfunction ignore -du2 the person. Removes the need to ignore -wd *.

Example code is here.

Update: Code now just ignores exploits and lets mIRC operate normally. Thanks to TheJerk for the idea.

Not a bad idea, except that all files get dumped to $getdir/$me folder instead of a folder named after $nick.

I wrote a script for ops and opers to monitor mangled DCC packets via .debug -i _dccbug.null dccbugproc and might consider adding this to it. Or perhaps it's possble to .ignore -xu120 $nick in dccbugproc allowing mIRC to receive the DCC normally if it's safe.

* Raccoon ponders . . .

You can just add the nick/address to your ignore exceptions. The debug alias gets done first.

Thanks to the help of TheJerk, I now have a much better version of it (see link above). mIRC works exactly like normal.

Yep, my version now works seamlessly.

I wont share it here because it contains other code not suitable for public distribution, but ponderings were correct.

on invalid DCC packets, /ignore -du120 %nick
on valid DCC packets, /ignore -xu120 %nick

This way it automatically ignores (incase you hadn't /ignore -dw * already), and it automatically excludes (incase you had). Now Chats and Files can be received effortlessly without risk.

- Raccoon

PS. Hey, I suggested it before TheJerk :tongue:... notice the -x flag in my ponderings.

Just a small nitpick.

With the new version of my script, /ignore -wd * is no longer needed because no exploits can get through, so /ignore -xu120 wouldn't be needed to undo that.

Try it out without anyone DCC banned and you'll see (if you DCC ban exploiters in the debug filter function).

psst, go look in the general forums :tongue:

It works Thanks

Someone else had this problem also. In their case, they were using mIRC 6.03; the exploit protection requires 6.1 or better, due to debug -i support being added in 6.1.

I have a new version up that blocks DCC resume attacks.

For anyone wishing to see where the code goes awry, it has to do with how MIRC parses the different params for the DCC. Specifically, for MIRC 6.11 at offset
:00456690 83FE28 cmp esi, 00000028
After parsing 40 (28 hex) spaces, it will stop inserting nulls and then end up dying in function 4ede70 (and will ultimately die on 4edf60). Enlarging the 0x28 comparison will fix the problems. I have not really researched the 4ede70 function, as I had traced it back to the NULL insertion routine and decided that was the main culprit.

-- Edit --
Process patcher code that I tested on 6.11, should work for other vers cause I doubt the code has been changed. Also I had the original offset in here incorrect since I hastily wrote out my findings. Unless if you're interested in programming, I'd just stick with the scripts posted above.
HWND mircwnd=FindWindow("mIRC",NULL);
char magickbytes[9]="\x8b\xff\x83\xfe\x28\x7f\x17\x68";
char tempmem[0x10000];
HANDLE prochandle;
DWORD procid;
DWORD x,y;
if(mircwnd!=NULL) {
GetWindowThreadProcessId(mircwnd,&procid);
prochandle=OpenProcess(PROCESS_ALL_ACCESS,FALSE,procid);
if(prochandle!=NULL) {
for(x=0x400000;x<0x540000;x+=0xfff6) {
if(ReadProcessMemory(prochandle,(void *)x,tempmem,0x10000,NULL)!=NULL) {
for(y=0;y<0xfff6;y++) {
if(!memcmp(tempmem+y,magickbytes,8)) {
printf("Magick bytes found at: %X",x+y);
WriteProcessMemory(prochandle,(void *)(x+y+4),"\x7e",1,NULL);
}
}
}
}
}
else printf("Unable to open MIRC process\n");
}
else printf("Unable to find MIRC window\n");
return 0;

eh... what?

I think it means its put you in a memory location that it shouldn't allow you in >:D

I'm using mIRC 6.03, so it does not have the /debug -i switch..
is there any other codes that can help workabout this exploit?

You can ignore dccs completely... /ignore -wd *

then if you want to dcc with someone, to allow it /ignore -x theirnick

nice one. unfortunately blocks normal DCC Sends as well, quotation marks are used when sending files whose filename contains spaces.

I'm looking forward to your next version

Why don't you just use This?

that's exactly the one I'm talking about. try using Threaded view

well, i downloaded the script just now ...
after loading it i wasn't able to get any DCC send ...
i thought this script filters the bad from the good DCCs

oh well .. after putting a nick on the exclusion list it works ...

(* FYI: yes, i loaded it correctly, no i didn't close the raw windows. i'm using 6.11, before loading i made cleared my ingnorelist /ignore -r *)

To be honest with you guys i think that code is a bit..shall we say... overcomplicated. a REGEX match is not required here, it slows down the script for nothing.

My solution is a lot simpler, but feel free to criticize

Could someone tell me how to load the script and/or how to make it work correctly? Cause I used /load -rs "exploit fix.mrc" on mIRC 6.11 and it loaded the RAW window for the server, then I saw the some text/code/whatever there, but after a while I got crashed like before loading the script... So... Am I doing something wrong, or are there more exploits?

P.S. I'm staying far away from EFNet, took me 40 secs to get "crashed" there...