FreeTDS Development Group

["James Harper" <james.harper AT bendigoit.com.au>]

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                                      `...

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.

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.

The next few packets appear random in content.

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