The author (I'm just a customer, no financial stake etc. sent with permission) says: "I've run the program, and it does indeed kill Serv-U on Win95 on a fast link. From the looks of it sofar it seems the Win95 socket stack is to blame. It never even goes into actual Serv-U code when it crashes, but stays in system drivers." -- Alan Thew alan.thewat_private Computing Services,University of Liverpool Fax: +44 151 794-4442 On Thu, 5 Feb 1998, tl wrote: > This program doesn't do anything to my Serv-U program. I can see the > garbage flooding, however when I break out of serv-who.c, serv-u continues > to run normally without any crash or system slowdown. I'm running win95 > osr2 on a PPro 150, and ServU version 2.0c 32bit. This is an older version > so perhaps that's the reason .. > > -----Original Message----- > > > >Hello, > >After reading an earlier message, Windows 95/NT War FTPD 1.65 Buffer > >Overflow, I thought I might play around with some other Windows ftp > >servers. One problem I found was in Serv-U FTP by Cat-Soft > ><http://www.cat-soft.com>. After you connect instead of sending the normal > >USER then PASS, you can send garbage. And if you send alot of garbage at a > >high speed Serv-U will stop responding to mouse clicks and after a short > >amount of time will crash and give you this: > > > >SERV-U32 caused a stack fault in module KERNEL32.DLL at 014f:bff9a08c. > >Registers: > >EAX=005e2084 CS=014f EIP=bff9a08c EFLGS=00000246 > >EBX=17bf0514 SS=0157 ESP=005e2080 EBP=005e20d4 > >ECX=005e2098 DS=0157 ESI=81628c70 FS=2347 > >EDX=ffffffff ES=0157 EDI=0000ffff GS=0000 > >Bytes at CS:EIP: > >5e 8b e5 5d c2 10 00 64 a1 00 00 00 00 55 8b ec > >Stack dump: > >00000001 c00000fd 00000000 00000000 bff9a08c 00000000 01570157 01870028 > >17bf0b6a c10fabe8 16c70001 80dc0014 16e73a45 00040000 02000000 bff97fdc > > > >Why it does this I have no idea. It only acts this way in the windows 95 > >version. Under NT the cpu usage goes up to 100%, but no crash. Alot of > >times even after the crashed Serv-U has closed, Windows is still slow to > >non responsive. > > > >And here is the program I used, not pretty but it works: > > >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:41:49 PDT