Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - brew

#1
Starcraft / The Lost Packets
August 06, 2010, 07:52:23 PM
I know of 5 completely undocumented (that is, not widely known and not on BnetDocs) packets that I'd like to share with everyone. It isn't until recently that I've aggregated enough information about their structure, function, and usage until now. While it is true that none of these have been seen, nevertheless they provide some historical background of Battle.net and may be interesting to a few people and undoubtedly deserve documented status.
I found these a while ago while researching Warden, but didn't really think much of them. Hdx recently made a thread about them on Valhalla Legends, and I believe iago posted about them at one point, too. Neither are anywhere near complete descriptions nor are they of documentation quality, however.
Without further adieu:

---------------------------------------------------------------------

0x17 - SID_READMEMORY

Structure:

(S -> C)
    (DWORD) Request ID
    (DWORD) Address
    (DWORD) Length

(C -> S)
    (DWORD) Request ID
    (VOID) Memory


Purpose:
Rudimentary hack detection system. Was never used probably due to terrible implementation with little security. Yes, it is possible for a PvPGN server to read _EVERYTHING_ that is in the process' memory, including sensitive information such as your CDKey.

Found at:
battle!1901D470h (as of 1.16.1)

---------------------------------------------------------------------

0x20 SID_ANNOUNCEMENT

Structure:

(S -> C)
    (STRING) Text


Purpose:
Very simply prints out text with the string at 1903B9FBh (the default string, used anyway if the username field is NULL in the chat event struct -- currently a single 0x7F char) as the username. Used to send announcements and arbitrary messages to the user, but this was soon superseded by SID_CHAT subcommands such as EID_INFO, EID_ERROR, and EID_BROADCAST. Printed out with the same color and style as an EID_BROADCAST.

Found at:
battle!1901DDA0h (as of 1.16.1)

---------------------------------------------------------------------

0x23 SID_WRITECOOKIE

Structure:

(S -> C)
    (DWORD) unknown/unparsed -- Flags, Request ID?
    (DWORD) unknown/unparsed -- Timestamp?
    (STRING) Registry key name
    (STRING) Registry key value



0x24 SID_READCOOKIE

(S -> C)
    (DWORD) Echoed back, Request ID?
    (DWORD) Echoed back, Timestamp?
    (STRING) Registry key name

(C -> S)
    (DWORD) First DWORD from S -> C
    (DWORD) Second DWORD from S -> C
    (STRING) Registry key name
    (STRING) Registry key value


Purposes:
Much like a website cookie, simply stores some arbitrary string to a 'cookie jar' to save preferences et al. which can be retrieved later by the server. Not used because it was quickly discovered that storing preferences produces less problems and were faster by storing them server-side, associating them with the account. It is somewhat curious that these packet IDs are close to SID_PROFILE/SID_WRITEPROFILE (0x26 & 0x27).

Found at: battle!190216FBh and battle!1901D660h, respectively.

---------------------------------------------------------------------

0x43 SID_WARCRAFTSOMETHING

(S -> C)
    (DWORD) Unknown (0)


Purpose:
Unknown. I am unable to disassemble Warcraft 3's game.dll without a lot of trouble, and therefore I have limited knowledge of it. It has been seen once, after SID_LOGONPROOF (0x54) in the NLS logon sequence.

Found at: game.dll

---------------------------------------------------------------------


It would be nice if somebody updated BnetDocs with this information.
#2
Starcraft / The truth behind SID_PING
August 06, 2010, 02:52:06 AM
SID_PING, better known as "the 0x25 packet", does more than just a ping.

Pinging is sent in 20-second intervals, provided the initial ping packet was responded to correctly (not spoofed to be -1 or 0) AND SID_NULL packets are sent on a regular interval.
If the regular interval of null packets is broken, battle.net detects it as a connection that's "almost lost", and sends a ping packet once every 5 seconds until they have been responded to and the interval of null packets is reestablished.
In order to get an accurate ping, both the client and server temporarily disable the Nagle algorithm since a packet could be held up as long as 5 seconds with a rather idle connection (do note that the constant value of 1 is in fact TCP_NODELAY with level == IPPROTO_TCP, whereas 1 is SO_DEBUG with the level SOL_SOCKET):

.text:1901D4F0 Send0x25        proc near               ; CODE XREF: ServerThreadProc+2F8p
.text:1901D4F0
.text:1901D4F0 optval          = byte ptr -4
.text:1901D4F0
.text:1901D4F0                 push    ebp
.text:1901D4F1                 mov     ebp, esp
.text:1901D4F3                 push    ecx
.text:1901D4F4                 test    edi, edi
.text:1901D4F6                 jz      short loc_1901D53B
.text:1901D4F8                 mov     ecx, sck
.text:1901D4FE                 push    esi
.text:1901D4FF                 mov     esi, ds:setsockopt
.text:1901D505                 push    4               ; optlen
.text:1901D507                 lea     eax, [ebp+optval]
.text:1901D50A                 push    eax             ; optval
.text:1901D50B                 push    1               ; optname == TCP_NODELAY
.text:1901D50D                 push    6               ; level == IPPROTO_TCP
.text:1901D50F                 push    ecx             ; s
.text:1901D510                 mov     dword ptr [ebp+optval], 1
.text:1901D517                 call    esi ; setsockopt
.text:1901D519                 push    edi
.text:1901D51A                 push    25h
.text:1901D51C                 call    SendPacket
.text:1901D521                 mov     eax, sck
.text:1901D526                 push    4               ; optlen
.text:1901D528                 lea     edx, [ebp+optval]
.text:1901D52B                 push    edx             ; optval
.text:1901D52C                 push    1               ; optname
.text:1901D52E                 push    6               ; level
.text:1901D530                 push    eax             ; s
.text:1901D531                 mov     dword ptr [ebp+optval], 0
.text:1901D538                 call    esi ; setsockopt
.text:1901D53A                 pop     esi
.text:1901D53B
.text:1901D53B loc_1901D53B:                           ; CODE XREF: Send0x25+6j
.text:1901D53B                 mov     esp, ebp
.text:1901D53D                 pop     ebp
.text:1901D53E                 retn
.text:1901D53E Send0x25        endp


This creates the 'other' purpose I was talking about before, to synchronize the buffer used by recv in ServerThreadProc:


          case 0x21:
            Send0x25(packetid_minus_4, pktdata, pktlen - 4);
            pkg_align_variance = *(_DWORD *)lpTmp;
            ws_buf = ws_buf_base;
            break;

Code like this suggests that battle.snp knows the server's send buffer is flushed after an 0x25 send. SID_PING is not the only packet to have this buffer reset, though. Others are 0x28 SID_LOGONCHALLENGE, and 0x68 SID_FRIENDSREMOVE.
This means that you are guaranteed to never have a packet clumped after an 0x25, 0x28, or 0x68. Cool stuff.

Muchos kudos to Hdx, he pointed out the massive screwup I made earlier of thinking that 1 was SO_DEBUG here. Things make a lot more sense now.
#3
Starcraft / The *real* way to determine latency tiers
August 06, 2010, 02:00:10 AM
A lot of people wonder how exactly the 'lag bars' in Starcraft are determined - there are arguments of the precise range, in particular (i.e., is it 300-400, or is it 300-399, is it 299-399, etc). As a result, people would typically code a function to get the lag bar icon like this:

int GetPingIcon(uint32_t ping, uint32_t flags) {
    if (flags & 0x10)
        return ICON_LAG_PLUG;
    else if (ping == 0xFFFFFFFF)
        return ICON_LAG_NEG1;
    else if (ping == 0)
        return ICON_LAG_0;
    else if (ping <= 200)
        return ICON_LAG_1G;
    else if (ping <= 300)
        return ICON_LAG_2G;
    else if (ping <= 400)
        return ICON_LAG_3Y;
    else if (ping <= 500)
        return ICON_LAG_4Y;
    else if (ping <= 600)
        return ICON_LAG_5R;
    else
        return ICON_LAG_6R;
}


At the behest of Myst, I dug this up from Starcraft's battle.snp:


...
    v4 = GetDlgItem(dword_19045640, 1003);
    lpResult = sub_1902E200(v3, v5, *(_DWORD *)v2);
    if ( lpResult == -1 ) {
      v6 = *(_DWORD *)v2;
      if ( sub_1902E0B0(v3, *(_DWORD *)v2) )
        *(_DWORD *)(v2 + 8) |= 0x20u;
      ping = *(_DWORD *)(v2 + 12);
      if ( ping >= 10 ) {
        pingstep = ping / 100;
        if ( ping / 100 < 6 ) {
          if ( !pingstep )
            pingstep = 1;
        } else {
          pingstep = 6;
        }
      } else {
        pingstep = 0;
      }
      sprintf(&lParam, "%s\t%d %d\t%s", v6, *(_DWORD *)(v2 + 8), pingstep, *(_DWORD *)(v2 + 4));
      SendMessageA(v4, ((*(_DWORD *)(v2 + 8) & 0xF) != 0) + 384, 0, (LPARAM)&lParam);
...

(1.16.1, battle!19030420)

So as you can see, Starcraft doesn't assign any icon to latencies that are below 10, and for anything else, takes the quotient of the ping value after integer division by 100.

Knowing this, a better and more correct way to code the same GetPingIcon function above would be like so (this is, of course, assuming that the ping icons are consecutive in nature):

int GetPingIcon(uint32_t ping, uint32_t flags) {
    if (flags & 0x10)
        return ICON_LAG_PLUG;
    if (ping < 10)
        return ICON_LAG_0;
    return ICON_LAG_1G + ((ping < 600) ? (ping / 100) : 6);
}


That is all.
#4
Starcraft / Starcraft Game Lobby stuff
January 16, 2010, 04:43:08 PM
For the upcoming Starcraft© Guardian™ banlist (1.16.21), I intend to (in addition to entering text) have a convenient option to blacklist a player by the menu underneath the associated game slot. There's a quick dirty way to do this, of course. Hooking 0041AF10, then adding a reference to your string at (*(dword)(ecx + 3Ah) + *(byte *)(ecx + 46h)).
But this requires hooking, which is ugly, and even worse, would cause StarCraft to fail CheckRevision.

I refuse to use this 'solution' as it lowers my standards of quality software.
Instead, I am currently trying to figure out how to add a menu item by calling 0041B760h but it requires the construction of that struct i mentioned (Since it's passed via ecx like a thiscall, it's probably a reference to 'this').
Interestingly, this is the same function that inserts a line of text into the game lobby chatbox.

So far I've documented a bit of it:

word 0h   = unknown, maybe reference ID?
word 2h   = x
word 4h   = cx
word 6h   = y
word 8h   = cy
word Ah   = unknown, variable val, maybe this has something to do with the y?
word Ch   = unknown, constant 0xA000 though
word Eh   = unknown, constant 0x10 though
dword 10h = unknown, 0
dword 14h = unknown, 0
dword 18h = Flags, currently A0020411h
dword 1Ch = unknown, 0
word 20h  = unknown, variable, smallish value (35 - 63)
word 22h  = unknown, constant 13
word 24h  = unknown, constant 1
word 26h  = unknown, variable, higher order byte seems > than lower order (are these bytes?)
word 28h  =
dword 3Ah = Pointer to the string table of the current menu
byte 46h = current menu slot being referenced
byte 47h = upper bound of slots #s?
byte 4Ch = direction of menu drawing (always 0, for backwards draw)


I'm hesitant on calling it because I _don't_ know what the majority of these members actually are.
Anyone else feel like looking into it and contributing?
#5
The Playhouse / Proxier v1.0
January 14, 2010, 11:57:25 PM
This is just a small injectable library I slapped up to proxize a TCP winsock connection under Microsoft Windows 9x and NT. It was made at a friend's request specifically for the game Diablo II, but it should work for absolutely any Windows application. Maybe some of you might find it useful...

The source code is available in a ZIP format compressed directory at:
http://darkblizz.org/brew/proxier_src.zip.

The source code for the injector is in a ZIP file at:
http://darkblizz.org/brew/injector_src.zip.

A ZIP file containing the
- precompiled binary executable library
- configuration file, and
- the precompiled injector application
is available at:
http://darkblizz.org/brew/proxier.zip.


The precompiled binary alone is available at:
http://darkblizz.org/brew/proxier.dll.

The injector binary alone is available at:
http://darkblizz.org/brew/injector.exe.


Please take note that proxier.ini must be in the same current working directory as proxier.dll to work.
These programs are released under no warranty, especially the proxier itself. It hasn't been tested at all, however, if somebody does and finds a bug I'll be happy to fix it.
Also, run injector -? or injector -h for help on how to use the injector.
#6
Starcraft / IX86Archimonde.dll
June 12, 2009, 11:43:38 PM
I was pretty bored this morning, so I reversed the wc3 required work dll IX86Archimonde.dll so people can see for themselves exactly what it does. If you're interested (probably not) you can check out the full package at http://darkblizz.org/brew/IX86Archimonde.zip, or just the source at http://darkblizz.org/brew/IX86Archimonde.c.
#7
Open Source WinBot / Winbot
June 02, 2009, 07:33:34 PM
http://darkblizz.org/brew/winbot.zip

Just some crappy STAR/SEXP only 1v1 melee winbot i made a while ago, i figured it'd be okay to release it since keeping warden private hit the fan. Don't expect much, and don't expect everything to work. I made it in about a day for personal use.

Posting this suddenly got me in the mood for some bgh race wars....
#8
Development / new chat bot
May 10, 2008, 08:43:32 AM
thief's revelation bot has inspired me to develop a battle.net chat bot that will triumph over all.. here's my idea:
•MDI document interface, with tabs. Kind of like IDA :)
•Tabbed bot config (because my current method of making all the controls and frame x not visible and then having another one appear is shit.. not really, just so much work and messy)
•Custom anti-flood algorithm (compile it on your own into raw executable code, will include a default module)
•Will have an option to use bncsutil for hashing, cdkey decoding, srp, etc
•BNLS support for checkrevision (all three, 0x09, 0x18 and 0x1a, you can choose)
•Advanced flood filtering options
•Mutli profile (duh) with option of asynchronous or synchronous sockets
•SC game support (not full, will exit when game starts), hosting and joining
•Winamp support
•Downloads checkrevision modules
•Automatic hash file updates from patch

pretty much like brewbot except mutliprofile and a few other things removed.
if all goes well i'll then clean it up and release it as my first public bot.