Skip to Content.
Sympa Menu

freetds - Re: [freetds] packet type 0x12

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] packet type 0x12
  • Date: Thu, 26 Jan 2006 08:56:08 +0100

>
> Has any work been done on deciphering the 0x12 packet types?
> It appears
> to be what the query analyser 2000 tries to initiate a login
> with to an
> sql server.
>
> src/server/login.c says it's a pre-login, but I think it's an actual
> login attempt, and the client only falls back to 0x10 if there's a
> failure (eg an older version of the server.
>
> Looking at the packet exchange, the first packet is 0x34 (52)
> bytes long
> and appears constant except for two bytes (offset 0x30 and 0x31) which
> differ each type, and I think are encryption keys.
>
> 00000000 12 01 00 34 00 00 00 00 00 00 15 00 06 01 00 1b ...4....
> ........
> 00000010 00 01 02 00 1c 00 0c 03 00 28 00 04 ff 08 00 01 ........
> .(......
> 00000020 55 00 00 00 4d 53 53 51 4c 53 65 72 76 65 72 00 U...MSSQ
> LServer.
> 00000030 60 09 00 00 `...
>

is not constant

> The server then responds with an 0x04 response packet which
> is 0x25 (37)
> bytes long and appears constant in all cases.
>
> 00000000 04 01 00 25 00 00 01 00 00 00 15 00 06 01 00 1b ...%....
> ........
> 00000010 00 01 02 00 1c 00 01 03 00 1d 00 00 ff 08 00 02 ........
> ........
> 00000020 fe 00 00 00 00 .....
>
> The client then sends another 0x12 packet, this time 0x4e
> (78) bytes in
> length, and contains a heap of bytes which differ, even with the same
> password, which leads me to think that the two encryption
> bytes earlier
> are used as a (cheap) encryption method.
>

This is TLS incapsulated in TDS packets

> 00000034 12 01 00 4e 00 00 00 00 16 03 01 00 41 01 00 00 ...N....
> ....A...
> 00000044 3d 03 01 43 d8 3b 3d 61 53 c6 36 3f 26 3a f2 ca =..C.;=a
> S.6?&:..
> 00000054 7e d8 9a 3f 6e 55 d2 f4 16 1f 54 0e ee b7 a6 eb ~..?nU..
> ..T.....
> 00000064 e6 8f ea 00 00 16 00 04 00 05 00 0a 00 09 00 64 ........
> .......d
> 00000074 00 62 00 03 00 06 00 13 00 12 00 63 01 00 .b......
> ...c..
>
> Then it loses me completely. The next response is 0x266 (614)
> bytes long
> and contains a few instances of the server hostname (single
> byte ascii),
> something that might be the serial number or product number of the sql
> server, and a whole lotta nonsense :). Most of it except for
> about 0x3f
> (63) bytes are the same for different login attempts though.
>

There should be that certificate here... try to post here (or directly
to me)

> The next few packets appear random in content.
>

Probably crypted.

> Maybe it's a cryptographic challenge issued to the client so that the
> password is never sent over the network... seems a bit large for that
> though...
>
> Thought?
>
> Thanks
>
> James
>

http://cvs.sourceforge.net/viewcvs.py/*checkout*/freetds/freetds/doc/tds
_ssl.html?rev=1.5
And we implemented this some months ago...

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page