Just a note, the buffer for Patch Path is not properly cleared and trimmed by the server, resulting in this packet responding with a lot of random extra data. This is just random data and should be ignored. Extracting a NT string from the packet will work fine as it is ALWAYS properly terminated before the extra data.

Example:

0000:  FF 07 08 01 02 00 00 00 00 00 45 1A 00 00 00 00   ÿ
.....E....
0010:  E0 C9 95 15 A0 D7 E0 01 26 BA 54 00 50 83 4D AB   àÉ• ×à
&ºT.PƒM«
0020:  44 BE 33 03 88 A4 7A 6B 12 35 CE D3 76 BB 90 C1   D¾3ˆ¤zk5ÎÓv»?Á
0030:  FC 2D 6C 48 7E F4 A7 1F 25 06 1B A0 E3 B8 3D 6E   ü-lH~ô§% ã¸=n
0040:  A3 30 9D 3B E6 B3 62 B4 4C E5 E1 C7 B0 0B 0D 23   £0?;æ³b´LåáÇ°.#
0050:  5B 2B D2 02 CD 8E F6 D7 68 2F 51 9E 8B 42 52 3A   [+ÒÍŽö×h/Qž‹BR:
0060:  B9 FE 19 DA 94 11 92 05 0A 7D 43 D9 6D 72 58 31   ¹þÚ”’.}CÙmrX1
0070:  96 DF 85 79 13 F8 BF 54 0C 2C 57 17 10 18 DD A6   –ß…yø¿T,Wݦ
0080:  1E D0 00 ED 40 53 F3 EA C0 08 99 71 37 D8 C4 BA   Ð.í@SóêÀ™q7Øĺ
0090:  81 E2 34 65 CF 1A 36 6F AC 56 14 75 82 2E 04 B5   ?â4eÏ6o¬Vu‚.µ
00A0:  4F 8D 3F 87 B7 EB 1D AD E9 5E EE 0E D6 86 EF FF   O??‡·ë é^îÖ†ïÿ
00B0:  E8 63 DB 1C 47 84 C6 F1 4A C5 3E 22 E4 32 2A A9   ècÛG„ÆñJÅ>"ä2*©
00C0:  FD 3C 26 98 7C B6 78 5A 6A 8A 66 D5 64 9F 27 CA   ý<&˜|¶xZjŠfÕdŸ'Ê
00D0:  46 F2 69 D4 F7 F5 16 FB B1 AA 8C 38 DC 29 89 01   FòiÔ÷õû±ªŒ8Ü)‰

00E0:  39 45 BC AF FA 41 0F 80 28 C3 9C 97 95 60 9B A2   9E¼¯úA€(Ãœ—•`›¢
00F0:  20 24 E0 67 CC B2 61 E7 59 A5 4E 09 BD C2 8F F0    $àg̲açY¥N.½Â?ð
0100:  F9 7B 9A 07 74 CB EC 91                           ù{štËì‘........

If you'll notice, the packet length is 0x0108, minus the header and result dword = 0x0100, looks logical size of a buffer to me!

Also note, that when you FAIL checkrevison, and there is actually something in this buffer, there is no random data.
Exa:

0000:  FF 07 1E 00 01 00 00 00 57 32 42 4E 5F 49 58 38    ÿ
.....W2BN_IX8
0010:  36 5F 32 30 30 5F 32 30 32 2E 6D 70 71 00          6_200_202.mpq.

If anyone's curious as to why this happens, it is most likely because the programmer who was responsible for programming the packet forgot to initialize the buffer correctly.

So if they do not use the buffer (i.e. set the buffer to X value), then you'll receive whatever is in that buffer (at that spot in memory); however, had they initialized it properly, you would of received normal data (a null-terminator and nothing after it).

On a side-note, I believe PvPGN does this properly, someone correct me if I'm wrong. In other words, if you connect to an unofficial server, there is a good chance that the programmer who made that server (the most popular server software being PvPGN) initialized their buffer correctly and therefore you will not receive the extra data.

To further add to Hdx's comment: it would be nearly impossible for you to gain anything by reading the extra data; any data you may receive from it is always random (since it's from memory already being used). And is it also impossible to construct anything useful from it because of the data being random. So while it may look interesting or you may recognize some data that appears, there's no point to actually use the extra data you receive.

It appears the public Battle.net servers no longer send the uninitialized buffers. There's an extra 00 byte compared to what I expect though, so perhaps the format is DWORD, STRING, String, for some reason?

Yes, I requested a Blizzard developer to fix the buffer overflow last month and they did.

Ribose, do you have a packet dump you can share to confirm that there's still an extra null byte? I'm seeing the proper syntax: FF 07 09 00 02 00 00 00 00

Perhaps the documentation here could be clarified such that the STRING is always present irrespective of the result code.

00000000  01 ff 1e 27 00 01 00 00  00 00 00 00 00 00 00 00   ...'.... ........
00000010  00 00 00 00 00 00 00 00  00 45 50 53 49 4c 4f 4e   ........ .EPSILON
00000020  2d 35 00 4e 61 74 65 00  ff 12 3c 00 b0 ff 01 be   -5.Nate. ..<.....
00000030  6e a2 d2 01 b0 5f f0 36  4d a2 d2 01 f0 00 00 00   n...._.6 M.......
00000040  11 04 00 00 09 04 00 00  09 04 00 00 45 4e 55 00   ........ ....ENU.
00000050  31 00 55 53 41 00 55 6e  69 74 65 64 20 53 74 61   1.USA.Un ited Sta
00000060  74 65 73 00 ff 06 14 00  36 38 58 49 4c 54 52 44   tes..... 68XILTRD
00000070  2a 00 00 00 00 00 00 00                            *....... 
    00000000  ff 05 14 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000010  00 00 00 00                                        ....
    00000014  ff 1d 0c 00 f9 93 03 00  9d ea 54 56 ff 25 08 00   ........ ..TV.%..
    00000024  bd 5d 24 09 ff 06 32 00  00 5e 20 02 70 5f c7 01   .]$...2. .^ .p_..
    00000034  6c 6f 63 6b 64 6f 77 6e  2d 49 58 38 36 2d 30 33   lockdown -IX86-03
    00000044  2e 6d 70 71 00 6d b2 0d  08 3c 1a dc a9 11 39 bc   .mpq.m.. .<....9.
    00000054  72 ba aa 77 55 00                                  r..wU.
    0000005A  ff 00 04 00                                        ....
    0000005E  ff 00 04 00                                        ....
    00000062  ff 00 04 00                                        ....
00000078  ff 25 08 00 bd 5d 24 09  ff 07 29 00 36 38 58 49   .%...]$. ..).68XI
00000088  4c 54 52 44 2a 00 00 00  01 09 00 01 f3 c3 de ce   LTRD*... ........
00000098  8a 8a ff 79 f4 4b df 41  89 73 0b 5a 45 d9 a3 73   ...y.K.A .s.ZE..s
000000A8  00                                                 .
    00000066  ff 07 0a 00 02 00 00 00  00 00                     ........ ..

Mysterious possible second empty string?

I can confirm there's an extra null byte at the end of the packet.

ff 07 0a 00 02 00 00 00 00 00