mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
DCC Related GPF Bug (6.0 - 6.16) #89618 08/07/04 03:41 PM
Joined: Jul 2004
Posts: 17
S
SpeedFire Offline OP
Pikka bird
OP Offline
Pikka bird
S
Joined: Jul 2004
Posts: 17
I use the chat dccserver feature extensively... and I noticed random crashes of mIRC when people disconnect from this server (ie, when the dcc chat window is closed).
It's difficult to reproduce it, as it appears to be random, but it always happen when closing the dcc window.
I've written a script which crashes mIRC with a GPF, tested under all versions from 6.0 to 6.16, which is not exactly with the chat dccserver, but I think this is the same bug, still.

Code:
ALIAS testcrash {
  var %i = 1
  while (%i <= 20) { dcc chat $+(127.,$rand(0,255),.,$rand(0,255),.,$rand(0,255),:,$rand(1,65535)) | inc %i }
}
ON *:CLOSE:=:window -c = $+ $target


This basically opens 20 dcc chat windows (with a loopback IP... it won't connect of course, but it doesn't mind), and then closes all dcc windows. mIRC will crash before all windows are closed.

Of course this test is a bit "brutal", but this is the only way I've found to reproduce the random crash. (which can happen if there are only 2 dcc open !).

mIRC 6.0 => 6.16 / Windows 2000 Pro

Re: DCC Related GPF Bug (6.0 - 6.16) #89619 08/07/04 04:00 PM
Joined: Dec 2002
Posts: 788
C
Coolkill Offline
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 788
Might be worth adding This crash doesnt seem to occur when your not connected to a network, well, i cant get it to anycase..

However, it does occur, check your memory usage while running your above loop, on Win2k, here, it jumps to 19000 and the error produced is..

Application exception occurred:
App: (pid=1304)
When: 7/8/2004 @ 16:59:08.953
Exception number: c0000005 (access violation)

Eamonn.

Re: DCC Related GPF Bug (6.0 - 6.16) #89620 08/07/04 04:13 PM
Joined: Jun 2003
Posts: 5,024
M
Mentality Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Jun 2003
Posts: 5,024
Sidenote: It happens here when not connected to a server, both 6.16 and 6.15. It does not occur on 5.91 (32 bit). XP pro.

Regards,


Mentality/Chris
Re: DCC Related GPF Bug (6.0 - 6.16) #89621 08/07/04 04:25 PM
Joined: Jul 2004
Posts: 17
S
SpeedFire Offline OP
Pikka bird
OP Offline
Pikka bird
S
Joined: Jul 2004
Posts: 17
Here it happens whenever I'm connected or not. The error is :
The instruction at "0x0042cc27" referenced memory at "0x01830120". The memory could not be "read".

I've gathered some other debug info when mIRC crashed randomly (ie without using the above script, so the "real" and "hard to catch" bug), always just after somebody disconnects from the dcc chat server, and the instruction EIP were either 0x0042c827 or 0x0042c82f. If it can help... (this is not very far from 0x0042cc27, so probably this is actually the same bug).

I've noticed that the random crashes happen with 6.15 and 6.16, where the script above crashes everything starting from 6.0 (note : you have to higher a bit the 20 limit to make 6.0 => 6.14 crash)

Re: DCC Related GPF Bug (6.0 - 6.16) #89622 08/07/04 04:45 PM
Joined: Jul 2004
Posts: 17
S
SpeedFire Offline OP
Pikka bird
OP Offline
Pikka bird
S
Joined: Jul 2004
Posts: 17
I just noticed that, in fact, the "magic number" (20 in the example) seems to depend on the speed of the CPU, and the CPU usage. On my desktop computer (1.4 GHz), it crashes around 9-10, and on my laptop (2.6 GHz), it crashes around 12-13.
The memory usage doesn't jump here... Just 2 Mb increase.

Re: DCC Related GPF Bug (6.0 - 6.16) #89623 08/07/04 04:55 PM
Joined: Jun 2003
Posts: 5,024
M
Mentality Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Jun 2003
Posts: 5,024
The given example crashes on my computer which is 3Ghz.

Regards,


Mentality/Chris
Re: DCC Related GPF Bug (6.0 - 6.16) #89624 09/07/04 09:28 AM
Joined: Dec 2002
Posts: 122
S
STING Offline
Vogon poet
Offline
Vogon poet
S
Joined: Dec 2002
Posts: 122
Same happens here, under NT4.0 SP6.
Looks like a buffer overflow, causing the crash.

--edit--
It also seems "20" is not the magic number.
I just tried 100 and it went through all the way.
(Pentium III 730 mhz)

Code:
33970 405 412 NtFreeVirtualMemory (-1, (0x1ed0000), 1060864, 32768, ... (0x1ed0000), 1060864, ) == 0x0
33971 405 412 NtUnlockFile (528, {0, 0}, {-1, -1}, 412, ... ) == STATUS_RANGE_NOT_LOCKED
33972 405 412 NtClose (528, ... ) == 0x0
33973 405 412 NtFsControlFile (20, 0, 0x0, 0x0, 0x90028, 0x0, 0, 0, ... {status=0x0, info=0}, 0x0, ) == 0x0
33974 405 412 NtFsControlFile (20, 0, 0x0, 0x0, 0x90028, 0x0, 0, 0, ... {status=0x0, info=0}, 0x0, ) == 0x0
33975 405 412 NtCreateFile (0xc0110000, {24, 0, 0x40, 0, 0, "\??\C:\BorgIRC\BorgIRC 2.56\mirc.ini"}, 0x0, 128, 7, 3, 96, 0, 0, ... 532, {status=0x0, info=1}, ) == 0x0
33976 405 412 NtLockFile (532, 0, 0, 0, {0, 0}, {-1, -1}, 1, 0, 117505, ... {status=0x0, info=582}, ) == 0x0
33977 405 412 NtQueryInformationFile (532, 1373208, 24, Standard, ... {status=0x0, info=24}, ) == 0x0
33978 405 412 NtAllocateVirtualMemory (-1, 0, 0, 1056992, 8192, 4, ... 32309248, 1060864, ) == 0x0
33979 405 412 NtAllocateVirtualMemory (-1, 32309248, 0, 8416, 4096, 4, ... 32309248, 12288, ) == 0x0
33980 405 412 NtReadFile (532, 0, 0, 0, 8412, 0x0, 2012500072, ... {status=0x0, info=8412}, "[about]\15\12version=6.16\15\12show=Deckard\15\12\15\12[windows]\15\12main=14,1012,12,730,2,0,0\15\12status=1,534,1,303,2,1,0\15\12scripts=179,796,33,608,0,0,0\15\12wchannel=42,800,42,240,0,1,0\15\12wserv=105,853,105,486,2,1,0\15\12wlist=-1,800,-1,480,0,1,0\15\12wquery=63,652,63,240,1,1,0\15\12wwwwlist=-1,666,-1,360,0,1,0\15\12wdccg=-1,269,-1,261,0,1,0\15\12wdccs=-1,269,-1,261,0,1,0\15\12wchat=231,666,231,360,0,1,0\15\12wlinks=-1,851,-1,484,0,1,0\15\12\15\12[dde]\15\12ServerStatus=off\15\12ServiceName=borgirc\15\12CheckName=off\15\12\15\12[wizard]\15\12warning=6\15\12\15\12[dccserver]\15\12n0=0,59,1,1", ) == 0x0
33981 405 412 NtWriteFile (532, 0, 0, 0, "252,666,252,360,0,1,0", 21, {337, 0}, 2012500072, ... {status=0x0, info=21}, ) == 0x0
33982 405 412 NtSetInformationFile (532, 1218444, 8, EndOfFile, ... {status=0x0, info=0}, ) == 0x0
33983 405 412 NtFreeVirtualMemory (-1, (0x1ed0000), 1060864, 32768, ... (0x1ed0000), 1060864, ) == 0x0
33984 405 412 NtUnlockFile (532, {0, 0}, {-1, -1}, 412, ... ) == STATUS_RANGE_NOT_LOCKED
33985 405 412 NtClose (532, ... ) == 0x0
33986 405 412 NtFreeVirtualMemory (-1, (0x1281000), 53248, 16384, ... (0x1281000), 53248, ) == 0x0
33987 405 412 NtRequestWaitReplyPort (292, {48, 72, new_msg, 0, 405, 412, 103084, 0} "\14A\1\0\5\0\312\0\4\0\0\0zq\312\0\0\0\0\0\200\35\24\0\30\7f\1V\24\0\0\1\0\0\0\202\272\37.\271&\0\0\27\273\37." ... {188, 212, reply, 0, 405, 412, 103085, 0} "\2\1\312\0qq\312\0\4\0\0\0zq\312\0\0\0\0\0\200\35\24\0\0\0\0\0\0\0\0\0\221&\0\0\202\272\37.\270&\0\0\27\273\37.\15\0\0\0\225\1\0\0\234\1\0\0\15\0\0\0\234\1\0\0\225\1\0\0\1\0\0\0\5\0\4\0\0\0\0\0\225\1\0\0\234\1\0\0\0\0\0\0\200$\26\0\23\0\0\0\23\0\21\0n\0c\0a\0l\0r\0p\0c\0:\0[\0O\0L\0E\0e\02\0]\0\0\0\0\0\0\0\0\0\372w\0\0\0\0\0\0\0\0\6\0\0\0\350g\25\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" ) == 0x0
33988 405 412 NtDeleteAtom (49183, ... ) == 0x0
33989 405 412 NtQueryInformationProcess (-1, DebugPort, 4, ... {process info, class 7, size 4}, 0x0, ) == 0x0
33990 405 412 NtQueryInformationProcess (-1, DefaultHardErrorMode, 4, ... {process info, class 12, size 4}, 0x0, ) == 0x0
33991 405 412 NtClose (336, ... ) == 0x0
33992 405 412 NtOpenKey (0x80000000, {24, 0, 0xc0, 0, 0, "\Registry\Machine\Software\Microsoft\Windows NT\CurrentVersion\AeDebug"}, ... 364, ) == 0x0
33993 405 412 NtQueryValueKey (364, "Debugger", Partial, 16, ... ) == STATUS_BUFFER_OVERFLOW
33994 405 412 NtQueryValueKey (364, "Debugger", Partial, 64, ... TitleIdx=0, Type=1, Data="d\0r\0w\0t\0s\0n\03\02\0 \0-\0p\0 \0%\0l\0d\0 \0-\0e\0 \0%\0l\0d\0 \0-\0g\0\0\0"}, 64, ) == 0x0
33995 405 412 NtQueryKey (364, Basic, 24, ... ) == STATUS_BUFFER_OVERFLOW
33996 405 412 NtQueryValueKey (364, "Auto", Partial, 16, ... TitleIdx=0, Type=1, Data="1\0\0\0"}, 16, ) == 0x0
33997 405 412 NtCreateEvent (0x1f0003, {24, 0, 0x2, 0, 0, 0x0}, 0, 0, ... 372, ) == 0x0
33998 405 412 NtRequestWaitReplyPort (32, {24, 48, new_msg, 0, 0, 10, 0, 0} "\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\225\1\0\0\234\1\0\0" ... {24, 48, reply, 0, 405, 412, 103086, 0} "\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\225\1\0\0\234\1\0\0" ) == 0x0
33999 405 412 NtFsControlFile (20, 0, 0x0, 0x0, 0x90028, 0x0, 0, 0, ... {status=0x0, info=0}, 0x0, ) == 0x0
34000 405 412 NtQueryAttributesFile ({24, 0, 0x40, 0, 0, "\??\C:\BorgIRC\BorgIRC 2.56\drwtsn32.exe"}, 1237516, ... ) == STATUS_OBJECT_NAME_NOT_FOUND

Last edited by STING; 09/07/04 09:35 AM.
Re: DCC Related GPF Bug (6.0 - 6.16) #89625 09/07/04 09:39 AM
Joined: Dec 2002
Posts: 122
S
STING Offline
Vogon poet
Offline
Vogon poet
S
Joined: Dec 2002
Posts: 122
The magic number seems to be however 12.
When opening only 11 windows, mIRC doesn't crash.

I hope this bug isn't exploitable :|
I am trying to let it crash remotely now.

Re: DCC Related GPF Bug (6.0 - 6.16) #89626 09/07/04 01:22 PM
Joined: Dec 2002
Posts: 1,922
O
Online Offline
Hoopy frood
Offline
Hoopy frood
O
Joined: Dec 2002
Posts: 1,922
This code is enough to crash mIRC (v6.16, 98se)

alias testcrash dcc chat 127.0.0.1:1 | dcc chat 127.0.0.1:1
On *:close:=: window -c =$nick

Re: DCC Related GPF Bug (6.0 - 6.16) #89627 09/07/04 01:47 PM
Joined: Dec 2002
Posts: 122
S
STING Offline
Vogon poet
Offline
Vogon poet
S
Joined: Dec 2002
Posts: 122
Doesn't crash here.. on Windows NT 4.

Re: DCC Related GPF Bug (6.0 - 6.16) #89628 09/07/04 02:51 PM
Joined: Jul 2004
Posts: 17
S
SpeedFire Offline OP
Pikka bird
OP Offline
Pikka bird
S
Joined: Jul 2004
Posts: 17
I've run 1500 times (with a timer of 2 seconds) the Online's script, mIRC never crashed on my computer.

When mIRC crashes, it refers to the instruction at 0x0042c757.
I've used a debugger to trace in mIRC's code :
0x0042c757 is executed when the DCC Chat windows are closed, this is a compare instruction : CMP [EBP+528], EBX.
The crash occurs when EBP+528 is actually out of bounds regarding the memory allocated for mIRC.
I've ran the test with the magic number 20 :

Code:
01st window closed : EBP+528 = 0x00E4BA78, data in memory at this address : 00000000 00000000 00000000 01000000
02nd window closed : EBP+528 = 0x00E4D598, data in memory at this address : 00000000 00000000 00000000 01000000
03rd window closed : EBP+528 = 0x00E4F0D8, data in memory at this address : 00000000 00000000 00000000 01000000
04th window closed : EBP+528 = 0x01CF1310, data in memory at this address : 00000000 00000000 00000000 01000000
05th window closed : EBP+528 = 0x01CF2948, data in memory at this address : 00000000 00000000 00000000 01000000
06th window closed : EBP+528 = 0x01CF42E0, data in memory at this address : 00000000 00000000 00000000 01000000
07th window closed : EBP+528 = 0x01CF5E88, data in memory at this address : 00000000 00000000 00000000 01000000
08th window closed : EBP+528 = 0x01CFB228, data in memory at this address : 00000000 00000000 00000000 01000000
09th window closed : EBP+528 = 0x01CF7A40, data in memory at this address : 00000000 00000000 00000000 01000000
10th window closed : EBP+528 = 0x01CF9620, data in memory at this address : 00000000 00000000 00000000 01000000
11th window closed : EBP+528 = 0x01CFCE58, data in memory at this address : 00000000 00000000 00000000 01000000
13th window closed : EBP+528 = 0x01CFEAB0, data in memory at this address : 00000000 00000000 00000000 01000000
14th window closed : EBP+528 = 0x01D00730, data in memory at this address : 00000000 00000000 00000000 01000000
15th window closed : EBP+528 = 0x01C023D8, data in memory at this address : ???????? ???????? ???????? ???????? => not allocated !
=> The instruction at "0x0042c757" referenced memory at "0x01C023D8". The memory could not be "read".
=> Application terminated.


This explains why the magic numbers are different between computers, and we could even say it'll be different for
every instance of mIRC launched, because it depends on how the memory is allocated when mIRC requests it.
So it depends on how many RAM you have, which OS you use, how many applications are launched at the time you run
mIRC, how fragmented is your RAM (in my example we can see a "jump" of memory location), etc...
That's also why it happens for some people when they are not connected only, that's because some more memory is used
when they are connected, and the memory used for DCC chats will not be exactly at the same place...
This is also why it happens to me randomly without using any "crash script" as given in this thread : I run a bot
which is connected 24/24, and a lot of memory is allocated/deallocated by mIRC in this given time... So it can
crash with only 2 DCC's ! (That's also what happened to Online).

I think it can be remotely exploitable if you know that you just have to open/close DCC Chats with somebody that
automatically accepts it, or which is running a chat dccserver !

Re: DCC Related GPF Bug (6.0 - 6.16) #89629 09/07/04 06:06 PM
Joined: Nov 2003
Posts: 157
RuFy Offline
Vogon poet
Offline
Vogon poet
Joined: Nov 2003
Posts: 157
Confirm the bug here on WinME

alias testcrash dcc chat 127.0.0.1:1 | dcc chat 127.0.0.1:1
On *:close:=: window -c =$nick

Re: DCC Related GPF Bug (6.0 - 6.16) #89630 09/07/04 06:52 PM
Joined: Jul 2004
Posts: 150
D
Debug Offline
Vogon poet
Offline
Vogon poet
D
Joined: Jul 2004
Posts: 150
Confirmed, crash here too.

P.IV 3 with 1GB RAM using Win XP. (mIRC 6.16)

Regards.

Re: DCC Related GPF Bug (6.0 - 6.16) #89631 09/07/04 10:02 PM
Joined: Jul 2004
Posts: 8
M
mIRC_Scripter Offline
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
M
Joined: Jul 2004
Posts: 8
Online

confirm crash mIRC_6.16 98se 128mb ram 500mhz celery


alias testcrash dcc chat 127.0.0.1:1 | dcc chat 127.0.0.1:1
On *:close:=: window -c =$nick

Re: DCC Related GPF Bug (6.0 - 6.16) #89632 09/07/04 11:02 PM
Joined: Jan 2003
Posts: 3,012
KingTomato Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
I didn't crash with:

alias testcrash dcc chat 127.0.0.1:1 | dcc chat 127.0.0.1:1
On *:close:=: window -c =$nick

XP Home, AMD XP 2400+, 1Gig ram, mIRC v6.16 & v6.15


--

Sounds to me like Khaled is deleting the array stack prematurly. Gotta love allocating dynamic arrays ;d


-KingTomato
Re: DCC Related GPF Bug (6.0 - 6.16) #89633 10/07/04 03:32 AM
Joined: Dec 2002
Posts: 1,530
L
landonsandor Offline
Hoopy frood
Offline
Hoopy frood
L
Joined: Dec 2002
Posts: 1,530
Did NOT crash

alias testcrash dcc chat 127.0.0.1:1 | dcc chat 127.0.0.1:1
On *:close:=: window -c =$nick


2kpro SP3
AMD XP3000+
1 gig of ram
mirc 6.16
The above being my ONLY script loaded


Those who fail history are doomed to repeat it
Re: DCC Related GPF Bug (6.0 - 6.16) #89634 10/07/04 08:57 AM
Joined: Jul 2003
Posts: 11
Z
ZeroCarontE Offline
Pikka bird
Offline
Pikka bird
Z
Joined: Jul 2003
Posts: 11
With Online's script, confirmed.

EAX=00000000 CS=017f EIP=0042bee7 EFLGS=00010246
EBX=00000000 SS=0187 ESP=0082eb08 EBP=00f6e0ac
ECX=e0789eb0 DS=0187 ESI=00000002 FS=4727
EDX=00024144 ES=0187 EDI=0082fb80 GS=0000

CS:EIP:
39 9d 28 05 00 00 0f 85 be 00 00 00 8b 15 f4 24

Pentium4 1.5 256MB Win98se mIRC 6.14

Re: DCC Related GPF Bug (6.0 - 6.16) #89635 10/07/04 01:05 PM
Joined: Jan 2003
Posts: 3,012
KingTomato Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
Code In Question:

Code:
alias testcrash dcc chat 127.0.0.1:1 | dcc chat 127.0.0.1:1
On *:close:=: window -c =$nick


Thus far, the tally is as follows:

Code:
Crashes:
  mIRC v6.16 - Unknown;                Unknown;  Windows 98SE
  Unknown    - Unknown;                Unknown;  Windows ME
  mIRC v6.16 - Pentium 3;              1g RAM;   Windows XP
  mIRC v6.16 - Pentium Celeron 500Mhz; 128m RAM; Windows 98SE;
  mIRC v6.14 - Pentium 4 1.5Ghz;       256m RAM; Windows 98SE

No Crash:
  Unknown    - Unknown;                Unknwon;  Windows NT 4.0
  mIRC v6.15 - AMD XP 2400+;           1g RAM;   Windows XP Home
  mIRC v6.16 - AMD XP 2400+;           1g RAM;   Windows XP Home
  mIRC v6.16 - AMD XP 3000+;           1g RAM;   Windows 2k Pro


So far as I can tell, only pentiums crash--not amd. The RAM doesn't seem to influence as we have an instance of 1g of RAM in both scenerios. Also, I'm not trying to make this into a bash Pentium thread, just trying to maybe narrow down that maybe AMD and Pentium handle this differently.


-KingTomato
Re: DCC Related GPF Bug (6.0 - 6.16) #89636 10/07/04 01:41 PM
Joined: Jul 2004
Posts: 17
S
SpeedFire Offline OP
Pikka bird
OP Offline
Pikka bird
S
Joined: Jul 2004
Posts: 17
Code:
alias testcrash dcc chat 127.0.0.1:1 | dcc chat 127.0.0.1:1
On *:close:=: window -c =$nick

Above script tested approximately thousand times on two PCs :

mIRC v6.16 - Pentium 4 "Northwood" 2.66GHz; 512m RAM; Windows 2K Pro => no crash
mIRC v6.16 - AMD Athlon "Thunderbird" 1.40GHz; 640m RAM; Windows 2K Pro => no crash

Re: DCC Related GPF Bug (6.0 - 6.16) #89637 10/07/04 01:43 PM
Joined: Jun 2003
Posts: 5,024
M
Mentality Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Jun 2003
Posts: 5,024
Indeed, as I was rather uninformative earlier on in this thread, as it crashes on my computer I'll just say I can backup that Pentium-only theory:

Pentium 4, 3Ghz, 510MB RAM, XP Home SP1, mIRC 6.16 crashes with the original code. I haven't tested with Online's example.

Regards,


Mentality/Chris
Page 1 of 2 1 2