[jcifs] Re: Win2K: Primary Domain Fld of Ssn Setup Not Proper ly Zero Term'd

Allen, Michael B (RSCH) Michael_B_Allen at ml.com
Mon Aug 26 14:24:04 GMT 2002


> -----Original Message-----
> From:	Richard Sharpe [SMTP:rsharpe at ns.aus.com]
> Sent:	Monday, August 26, 2002 8:25 PM
> To:	Allen, Michael B (RSCH)
> Cc:	Luke Kenneth Casson Leighton; CIFS at DISCUSS.MICROSOFT.COM; jcifs at samba.org; samba-technical at samba.org
> Subject:	RE: [jcifs] Re: Win2K: Primary Domain Fld of Ssn Setup Not Proper ly Zero Term'd
> 
> On Mon, 26 Aug 2002, Allen, Michael B (RSCH) wrote:
> 
> > 
> > 
> > > -----Original Message-----
> > > From:	Richard Sharpe [SMTP:rsharpe at ns.aus.com]
> > > Sent:	Monday, August 26, 2002 4:28 PM
> > > To:	Michael B. Allen
> > > Cc:	Luke Kenneth Casson Leighton; CIFS at DISCUSS.MICROSOFT.COM; jcifs at samba.org; samba-technical at samba.org
> > > Subject:	[jcifs] Re: Win2K: Primary Domain Fld of Ssn Setup Not Properly Zero Term'd
> > > 
> > > On Mon, 26 Aug 2002, Michael B. Allen wrote:
> > > 
> > > > On Mon, 26 Aug 2002 10:24:09 +0000
> > > > Luke Kenneth Casson Leighton <lkcl at samba-tng.org> wrote:
> > > > 
> > > > > On Sun, Aug 25, 2002 at 10:02:49PM -0400, Allen, Michael B (RSCH) wrote:
> > > > > 
> > > > > > Clients should not check for *two* zero bytes after the Primary Domain field Unicode string
> > > > > > in SMB_COM_SESSION_SETUP_ANDX. You may only get *one* 0x00 byte. I'm almost
> > > > > > glad this is a bug in Win2K, I thought this was a bug in jCIFS. At least I have two articles of
> > > > > > evidence suggesting the bug is with Win2K. One is inlined here and the other is a PNG of a
> > > > > > pcap.
> > > > > >
> > > > > > Aug 21 06:58:52.472 - bad string
> > > > > > 00000: FF 53 4D 42 73 00 00 00 00 98 01 80 00 00 00 00  |?SMBs...........|
> > > > > > 00010: 00 00 00 00 00 00 00 00 05 88 56 34 01 F8 04 00  |..........V4.?..|
> > > > > > 00020: 03 75 00 81 00 00 00 58 00 7C                    |.u.....X.|
> > > > >  len1 = 0x58; len2=0x7c    ^^^^^ ^^^^^
> > > > > >                                      57 00 69 00 6E 00             W.i.n.|
> > > > > > 00030: 64 00 6F 00 77 00 73 00 20 00 35 00 2E 00 30 00  |d.o.w.s. .5...0.|
> > > > > > 00040: 00 00 57 00 69 00 6E 00 64 00 6F 00 77 00 73 00  |..W.i.n.d.o.w.s.|
> > > > > > 00050: 20 00 32 00 30 00 30 00 30 00 20 00 4C 00 41 00  | .2.0.0.0. .L.A.|
> > > > > > 00060: 4E 00 20 00 4D 00 61 00 6E 00 61 00 67 00 65 00  |N. .M.a.n.a.g.e.|
> > > > > > 00070: 72 00 00 00 44 00 49 00 56 00 49 00 4E 00 45 00  |r...D.I.V.I.N.E.|
> > > > > > 00080: 00 30                                            |.0
> > > > > 
> > > > >  0x58 length ends here.
> > > > > 
> > > > >  well, whoopidedoo, that happens to be absolutely spot-on.
> > > 
> > > Ummm, since SMBs are little endian, 00 58 is a large BCC. Much larger that 
> > > 0x58.
> > > 
> > > As well, ISTM, 00 7C is the first part of the Native OS: It looks like |.
> > > 
> > 	His little pointers were just wrong. It's really 58 00 and 7C although I'm not sure
> > 	what len2 means. He's right in that the byte count cuts off the pd field. Still a
> > 	stepchild of a packet if I ever saw one.
> 
> At the risk of getting into a pissing contest, the SMB shown looks like a 
> session setup and X response with a chained command.
> 
	Yes, read the note below the hexdump in my original message.

> The 00 57 are in the correct place for the BCC, they just look like they 
> are in big endian format.
> 
	Nope. Look at the PNG of Ethereal in my OP. The packet may be messed up
	but it's definately not suffering from endian-inversion.

> The next two bytes actually look like padding. 
> 
> At least that is what it looks like when comparing it to NT4 and W2K 
> traces I have.
> 
> Of course, I could be wrong. Where did the packet come from?
> 
	I captured jCIFS doing a NetServerEnum. I'll send you the pcap. Please don't
	crack my password :~)

> Regards
> -----
> Richard Sharpe, rsharpe at ns.aus.com, rsharpe at samba.org, 
> sharpe at ethereal.com
> 




More information about the samba-technical mailing list