StarCraft II Battle.net Wire Protocol Reference

1. Names and protocol layers

StarCraft II's online path is a stack, not one protocol. This document uses the following names consistently:

With these names established, the next chapter follows one session from the first Front connection through the Sunken service stream.

Back to contents

2. High-level architecture and flow

SC2 signs in on Battle.net's shared BGS service, then moves the authorized session to SC2's native service. The first connection establishes who you are and which game account may log in; the second proves that it received that authorization and carries the live SC2 services. The protocol calls that continuation Resume.

The next chapter begins with the outer BGS control plane: its framing, dispatch rules, account logon, and the GameUtilities request that creates the handoff.

Back to contents

3. BGS protobuf RPC

BGS is the generic Battle.net Game Service control plane used before SC2 enters its native service stream. SC2 embeds a standard protobuf descriptor set for connection, authentication, challenge, session, GameUtilities, account, channel, presence, and related services.

3.1 WebSocket transport and RPC frame

The Base97563 client first establishes TLS to the regional Front endpoint, then performs an RFC 6455 upgrade with subprotocol v1.rpc.battle.net. Each binary WebSocket message contains exactly one BGS RPC frame. WebSocket therefore supplies the outer message and body boundary; the two-byte BGS prefix below measures only the protobuf header.

offset  size                 description
------  -------------------  ----------------------------------------------
0       2                    header length, unsigned big-endian
2       header_length        protobuf bgs.protocol.Header
...     remainder of message protobuf request/response body

uint16_be header_length
bytes     header[header_length]
bytes     body[websocket_message_end - current_offset]

Header.size is a body-length assertion when present, not the outer message delimiter on this path. The two-byte prefix measures only the encoded protobuf header, not the complete RPC frame or WebSocket message.

Client-to-server WebSocket messages set the RFC 6455 mask bit. The current macOS client uses an all-zero four-byte mask, so the payload bytes remain visibly unchanged even though the frame is formally masked. Server messages are unmasked.

3.2 Dispatch and callbacks

A BGS header answers two separate questions: which operation should receive this body? and which earlier call does this reply belong to? Service and method fields perform dispatch; the token performs correlation.

After the special first Connect, client requests identify a service with the 32-bit FNV-1a hash of its full protobuf name:

h = 0x811c9dc5
for each UTF-8 byte b in full_service_name:
    h = h XOR b
    h = (h * 0x01000193) AND 0xffffffff

Relevant names include:

• bnet.protocol.connection.ConnectionService
• bnet.protocol.authentication.AuthenticationServer
• bnet.protocol.authentication.AuthenticationClient
• bnet.protocol.challenge.ChallengeNotify
• bnet.protocol.game_utilities.GameUtilities
• bnet.protocol.account.AccountService
• bnet.protocol.session.SessionService and SessionListener

Server-to-client calls use listener services. If the descriptor declares an ordinary response, answer with a header whose service_id is 0xfe, whose token is the callback token, and whose status is zero. If the declared return type is NO_RESPONSE, send nothing. An empty response is not equivalent to no response.

Connection-control calls and listener callbacks can arrive while another token remains pending. Decode and dispatch each message by its own header, acknowledge it when its declared result requires one, and continue waiting for unrelated tokens.

3.3 Logon sequence

For Base97563, LogonRequest.version is the embedded SDK identity Battle.net Game Service SDK v1.48.2 "cf68e241e0"/104, while protobuf field 6 application_version is zero. These fields must not be inferred from the installation build number.

Authentication listener traffic can be interleaved with the ordinary RPC responses: method 10 reports a logon update, method 14 reports game-account selection, and methods 11–13 are declared NO_RESPONSE. Dispatch them as callbacks rather than mistaking them for whichever request token is pending.

The browser or embedded web view handles only the account challenge. The BGS connection remains the protocol client: after the web flow returns its short-lived credential, the client submits that value with AuthenticationServer method 7.

The cached credential is distinct from the one-time credential returned by the web challenge. It is opaque, can suppress the next browser challenge, and should be replaced after a successful use. Rejection simply returns the flow to the ordinary web challenge.

3.4 GameUtilities Front request

Front sends GameUtilities.ProcessClientRequest method 1 with a deliberately sparse ClientRequest. Top-level field 1 repeats typed attributes; top-level field 4 is the selected SC2 game-account entity. Fields for host process, Battle.net account, program, and client info are absent on this path.

An Attribute is protobuf field 1 name plus field 2 Variant. Known Variant arms are field 2 bool, 3 signed integer, 4 double, 5 string, 6 blob, 7 embedded message, 8 FourCC string, 9 unsigned integer, and 10 entity ID.

A successful response is another attribute bag. The handoff requires:

• address: native endpoint string;
• session_key: exactly 64 private bytes;
• account_region: unsigned integer in 0..255;
• game_account_name and account_mail: private identity strings;
• logon_response: a bit-packed native LogonResponse3.

These response attributes are the boundary between the generic BGS control plane and SC2's native protocol. The next chapter explains how they are used to open the Sunken connection.

Back to contents

4. Front-to-Sunken handoff

The SC2 client names the generic BGS side “Front” and the native endpoint “Sunken.” Front authenticates the Battle.net account, selects an SC2 game account, and returns the values needed to open and authenticate the second connection.

The logon_response attribute is not an opaque ticket. It decodes as Battlenet::Client::Authentication::LogonResponse3, including response status, final authentication-module requests, ping timeout, regulator rules, account and game-account region, game-account name, failure count, and optional RAF state. The enclosing protobuf blob carries no native bit count; unused bits in the last byte must be zero.

The native TCP connection may be established before Front finishes closing, but the first native Auth/1 ResumeRequest is written after the Front shutdown. The sockets remain independent even when their lifetimes briefly overlap.

An ordered Front shutdown uses ConnectionService.RequestDisconnect (method 7, declared NO_RESPONSE). The server answers with the one-way ConnectionService.ForceDisconnect notification (method 4) and then closes TLS. This notification is a protocol event, not the response frame that NO_RESPONSE explicitly forbids.

From this point onward, the transport and payload format are native BSN. The next chapter introduces its bit cursor, record header, and schema-delimited boundaries before any authentication payloads are decoded.

Back to contents

5. Native BSN record stream

“BSN” is used here for the native bit-packed service protocol generated by Blizzard's embedded bsnc toolchain. Unlike the preceding BGS connection, native records are schema-delimited bitstreams rather than protobuf messages inside WebSocket boundaries.

5.1 The bitstream from first principles

A BSN record is not a list of byte-sized packet fields. It is a sequence of fields packed back-to-back into an array of bytes. Each field declares exactly how many bits it consumes, and the next field begins wherever the previous one stopped—even if that position is halfway through a byte.

How a number is split when it crosses a byte

Cursor movement explains where a field is stored. Integer chunking is a second rule that explains which part of the value goes into each region. If an integer does not fit before the next byte boundary, its most-significant chunk goes into the remaining space and its lower bits continue in the next byte. The boundary splits the value; it does not reverse it.

The decoder below expresses the same rule. The important operation is value = (value << take) | chunk: each earlier wire chunk becomes the more-significant part of the reconstructed integer.

read(width):
    value = 0
    while width remains:
        take = min(width, bits_left_in_current_byte)
        chunk = (current_byte >> current_bit_offset) & ((1 << take) - 1)
        value = (value << take) | chunk
        advance(take)

Consequently, a field cannot be cut out of the byte stream and decoded as an ordinary standalone integer. Its interpretation depends on the bit position at which the field began. Keep one cursor for the complete record, including its routing header.

5.2 Routing header

command_id       6 bits   0..63
service_present  1 bit    0 = no service slot follows
service_slot     4 bits   present only when service_present = 1

total: 7 bits without a slot, 11 bits with a slot

With a service slot, the payload begins three bits into the second byte; the upper five bits of that byte already belong to the payload. Without a service slot, the payload begins at bit 7 of the first byte.

for a route with a service slot
byte0 = (command & 0x3f) | 0x40 | (((slot >> 3) & 1) << 7)
byte1 bits 0..2 = slot & 0x07

worked arithmetic only: command 11, slot 5
byte0 = 0x4b
byte1 bits 0..2 = 0x05

The worked slot is arbitrary. Service slots are assigned for a connection; only the service FourCC and command meaning are stable.

5.3 How record length is determined

BSN records are schema-delimited. There is no universal field saying “this record is N bytes long.” Instead, the route identifies a payload decoder, and that decoder advances the shared bit cursor until its top-level value is complete. The cursor position at that moment is the logical end of the record.

Local counts are not record lengths. An array count describes one array; a string length describes one string; an optional flag and choice selector control only their nested values. The enclosing schema combines all of those decisions recursively to determine the payload’s total extent.

Counts use the same bounded-integer machinery as other ranged values. For a declared range [minimum..maximum], the metadata supplies the encoded bit width and the wire stores value - minimum. Thus an array declared [1..64] can store count - 1 in six bits. A fixed range, where minimum equals maximum, consumes no count bits at all.

The general calculation is:

logical_bits = routing_header_bits + payload_bits_consumed_by_schema
padding_bits = (-logical_bits) & 7
record_bytes = (logical_bits + padding_bits) / 8

An incremental socket decoder therefore does not wait for a declared record size. It tries to execute the selected schema against the bytes currently buffered. If a field is incomplete, it reads more TCP data and resumes. Once the schema finishes, it validates the final zero padding, removes exactly that many bytes, and starts the next routing header at the next byte.

Parser procedure

1. Read the 7- or 11-bit routing header.
2. Resolve (direction, service slot, command) to a payload type and generated order.
3. Decode fields until that schema is complete.
4. Consume zero padding through the next byte boundary.
5. The next byte begins the next routing header.

Internal alignment is also relative to the complete record. Strings, byte strings, and blobs can align the cursor before their raw bytes, so encoding a payload at bit zero and prepending a separately encoded route header produces a different layout. The next chapter resolves the numeric service slot into a stable FourCC; Section 7 then explains how the selected payload type is described.

Back to contents

6. Runtime service registry

The routing header has room for a four-bit service slot, so one connection can address at most sixteen native services. The slot is an index into that connection's registry; the registry entry supplies a stable FourCC and its command-handler table.

The complete route identity is (direction, service FourCC, command). The numeric slot is session state, not protocol identity. A decoder should resolve the slot first and use the resulting FourCC for every later lookup.

6.1 Assignments used by the documented build

Base97563 traffic uses the assignments below. They make a captured route such as slot 5, command 11 readable as Chat/11. Keep the FourCC in decoded output: a slot number is only the compact address used by this build's native connection and should not be treated as a permanent service ID.

Resolving the service still does not reveal the payload fields. The next chapter explains the embedded type library that associates a routed endpoint with a recursive BSN schema.

Back to contents

7. Embedded BSN schema metadata

The previous chapter established that a BSN route selects the schema which determines where its payload ends. That raises the next question: where does that schema come from?

SC2 ships a compact, version-7 type library produced by Blizzard's bsnc toolchain. It is embedded in the client executable alongside the generated encoders and decoders. It is not transmitted in each record, and it is separate from the protobuf descriptors used by BGS.

7.1 From a route to a schema

Each metadata type has a build-specific numeric ID. Looking up that ID yields a structural record and, when reflection names were retained, a naming record. Structural records refer to other type IDs, so resolving one top-level payload produces a graph rather than a flat field list.

The payload structures in this document are a human-readable rendering of that decoded type graph. They are documentation notation, not a language carried on the wire. For example:

illustrative rendering of decoded metadata
Authentication::ProofRequest {
    request  ModuleInput[0..4]
}

ModuleInput {
    id    blob[40]
    data  blob[0..1023]
}

Here the array bound, blob bounds, nested type relationship, type name, and member names all come from metadata. The braces and formatting are ours.

7.2 Native type vocabulary

The low six bits of a structural record identify one of sixteen kinds. The kind determines what other information the record carries and what the value consumes from the BSN bitstream.

Most bounded values encode value - minimum using the recorded bit width. Fixed-size forms can omit the count entirely. For indexed choices, enums, and structs, bit 7 can mean that indices are the full contiguous range rather than an explicit list.

7.3 How the type library is stored

This binary layout matters when extracting the type library from an SC2 build. A packet decoder which has already loaded the parsed type graph does not encounter this header or these tables on the network.

Type ID n indexes element n in both offset tables. Its shape offset points to the structural record. Its name offset points to a small record of 32-bit offsets into the NUL-terminated UTF-8 string pool, or is zero when no names were retained. The header's type_count, dump_size, and string_size delimit the five regions.

MetadataHeader  # five unsigned big-endian u32 values
    version             # currently 7
    flags
    type_count
    dump_size
    string_size

followed by
    dump_offset[type_count]
    dump_data[dump_size]
    string_record_offset[type_count]
    string_data[string_size]

The first byte of each structural record begins with:

bits 0..5  kind tag (1..16)
bit  6     obfuscated flag
bit  7     kind-specific compact-form flag

Bit 7 is interpreted by the selected kind; for example, it can indicate an implicit contiguous index range instead of an explicit list.

The registry and type library now provide everything needed to parse native records. The next chapter applies them to the first Sunken exchange: Resume authentication and the transition to protected service traffic.

Back to contents

8. Native Resume authentication

The Resume path starts immediately after the Front handoff. The Sunken endpoint does not greet first; it waits for client Auth/1.

8.1 Where the name “Resume” comes from

Resume is Blizzard’s type name. SC2’s embedded BSN metadata contains the fully qualified types Battlenet::Client::Authentication::ResumeRequest and Battlenet::Client::Authentication::ResumeResponse. The runtime Auth route maps client-to-server Auth/1 to the request and server-to-client Auth/1 to the response. This chapter uses those embedded names throughout.

What is resumed is the authenticated session context. Front has already authenticated the Battle.net account, selected an SC2 game account, and obtained the native endpoint plus session material from GameUtilities. The new Sunken connection uses ResumeRequest and its proof exchange to demonstrate possession of that handed-off state and continue it on the native service plane. In other words, authorization crosses from one protocol connection to another.

8.2 Auth/1 ResumeRequest

Logical payload:

RequestCommon:
    m_program   = FourCC("S2")
    m_platform  = FourCC("Mc64")
    m_locale    = FourCC("enUS")
    m_versions  = five Version records (table below)
m_account            = private account-login bytes
m_gameAccountRegion  = u8 region from Front LogonResponse3
m_gameAccountName    = private game-account bytes

These are Base97563-specific values. The final native compatibility number is not the installation build number, and the outer BGS LogonRequest independently sends application_version=0. Omitting the NGD records, substituting 97563, or labeling the final record S2/Mc64 produces a different and invalid version set.

8.3 Configuration and proof

C -> S  Auth/1   ResumeRequest
S -> C  Auth/18  Configuration
S -> C  Auth/2   ProofRequest [two modules]
C -> S  Auth/2   ProofResponse [one session-proof output]
S -> C  Auth/1   ResumeResponse [phase-two server proof]

The Resume ProofRequest contains two 40-byte module IDs (eight-byte usage prefix plus a 32-byte module identity):

1. Thumbprint module. The server supplies a 4096-bit RSA PKCS#1 v1.5 SHA-512 signature. Hash the 16-byte connected peer address followed by the ASCII domain Thumbprint.IPv6. IPv4 peers use IPv4-mapped IPv6 form. Verify with exponent 65537 and the public modulus embedded in SC2. This is a one-way server-authentication check and contributes no ModuleOutput element.
2. Session-proof module. Server data is 00 || server_nonce[16]. Treat the 64-byte GameUtilities value as seed B, generate client_nonce[16], derive the per-challenge key C below, and return 01 || client_nonce || HMAC-SHA256(C, 00 || client_nonce || server_nonce). The successful ResumeResponse returns 02 || HMAC-SHA256(C, 01 || server_nonce || client_nonce), which must be verified.

For GameUtilities seed B, client nonce Nc, and server nonce Ns, the Resume ratchet and proofs are:

C = HMAC-SHA256(B, 0x00 || Nc || Ns)
 || HMAC-SHA256(B, 0x01 || Ns || Nc)

client_proof    = HMAC-SHA256(C, 0x00 || Nc || Ns)
server_proof    = HMAC-SHA256(C, 0x01 || Ns || Nc)
transport_secret = C

Resume first ratchets seed B into C; Auth/2 proofs use C, not B directly. The domain-two KDF belongs to the alternate full-logon handshake and is not part of Resume.

An optional plaintext Conn/11 RegulatorUpdate can appear before Auth/1 ResumeResponse.

8.4 Conn/5 and stream protection

After validating the server proof, the client sends an empty Conn/5 EnableEncryption BSN record in plaintext. Both directions then immediately use ordinary stateful RC4, with no initial keystream discard:

inbound_key  = HMAC-SHA256(transport_secret,
                68e0c72eddd6d2f31e5ab155b18b631e)
outbound_key = HMAC-SHA256(transport_secret,
                dea965ae543a1e939e690caa68de7839)

The two RC4 states are independent and persist across TCP reads, writes, and BSN record boundaries. TCP segmentation is irrelevant. If one receive call contains plaintext ResumeResponse followed by protected bytes, decrypt only the buffered suffix after enabling the inbound state, exactly once.

Once protection is active, the connection enters the service bootstrap covered by the endpoint reference in the next chapter.

Back to contents

9. Native service reference

Native BSN exposes service command endpoints, not BGS protobuf RPC methods. An endpoint is identified by (direction, service FourCC, command). Each entry below separates the stable route from the session-assigned numeric service slot and describes the payload in actual generated order where known.

• Auth authentication
• Conn connection
• Toon identity
• Pres presence
• Frnd friends
• Cach cache streams
• S2Ms master data
• S2Mp multiplayer
• Prfl profile
• Chat channels

The entries follow the Resume and post-login path. “Logical structure” means metadata member order; “generated order” means the serializer's actual bit order, including any reserved runs inserted for an obfuscated type. Entries with an incomplete structure state the missing portion directly.

RequestCommon {
    program    FourCC
    platform   FourCC
    locale     FourCC
    versions   Version[0..63] {
        programId  FourCC
        component  FourCC
        version    u32
    }
}
account            bytes[3..320]
gameAccountRegion  u8
gameAccountName    bytes[1..32]

useS3Depot  bool

requestCount  u3  valid values 0..4; 5..7 are invalid
repeat requestCount:
    alignToByte
    id             blob[40]  fixed size; no length prefix
    dataByteCount  u10 0..1023
    alignToByte
    data           bytes[dataByteCount]

id[0..7]    usage             61 75 74 68 00 00 00 00  ASCII "auth" + four NUL bytes
id[8..39]   module identity   opaque 32-byte value

Thumbprint module identity
d7 e6 62 40 80 c1 ab a6 6d ee 63 a6 f3 92 8d 8a
54 69 25 7f 58 20 b5 72 1f b8 c3 2b 6b 5b ef 5d

Session-proof module identity
89 50 05 34 0a 63 0a 64 65 a6 5f ec 96 32 3c 31
0b ca 8a 9f 66 ec ee b1 88 7a 9d 6c 0e 67 61 2e

responseCount  u3  valid values 0..4; Resume uses 1
repeat responseCount:
    dataByteCount  u10 0..1023
    alignToByte
    data           bytes[dataByteCount]

result  choice {
    success {
        finalRequestCount  u3 0..4
        finalRequest       ModuleInput[finalRequestCount]
        pingTimeout     Time::Delta
        regulatorRules  optional RegulatorRules
    }
    failure {
        strings  optional Cache::Handle[40]
        result   choice { update | failure { error, wait } | versionCheckDisconnect }
    }
}

error  u16 Error::Code

version  u32

EnableEncryption { }  zero payload bits

timeData  optional s64  Unix epoch microseconds

info  choice {
    none
    leakyBucket {
        threshold  u32
        rate       u32
    }
}

payload    blob[0..14336]
frameType  u8 enum CS_ROUTED, SS_ROUTED, SS_BROADCAST, SS_ERROR, SC_ERROR, SC_ROUTED, SC_BROADCAST
headers    Header[0..32]

Header = choice {
    content | route | target | correlation | client | service
    error | replicate | timestamp | stream | traceRoute
}

externalIp4Addr  IP4::AddressPort { address, port }
siteData            SiteDataForClient[0..64] {
    name         bytes[0..32]
    addressPort  optional IP4::AddressPort
}

toonDisplayCount  u6  valid values 0..50
repeat toonDisplayCount:
    Display {
        nameByteCountMinus2  u7
        alignToByte
        name        UTF-8 bytes[nameByteCountMinus2 + 2]
                    2..100 bytes; 2..25 characters
        lastOnline  s32
        reserved    bits[3]
        flags       u32
        profile     Profile::RecordAddress
        realm       u32
    }

nameByteCountMinus2  u7
alignToByte
toonName             UTF-8 bytes 2..100 bytes; 2..25 characters
generatedCheck       u10 rolling check seeded with 2
realm                u32

recordAddress  { label u32, id u64 }
toonHandle     { program FourCC, region u8, realm u32, id u64 }
realm          u32
lastLogon      s32
nameByteCountMinus2  u7
alignToByte
toonName       UTF-8 bytes

depotRegion                    FourCC
achievementHandles              AchievementHandle[0..15]
isPlayingFromIGR                 bool
defaultPortrait                  u32
reserved                         bits[31]
maxGameServerConnectTimeoutMS    u32
programName                     bytes[0..32]
programFlags                    bits[128]
realmMapList                    RealmMap[0..4]
unlockablesFiles                UnlockableDefinition[0..128]
reserved                         bits[3]
maxMapFavorites                 u16
intermediateNameRestriction     UTF-8[0..1024]
finalNameRestriction            UTF-8[0..1024]
currentTime                     s32

InitialNotifiesComplete { }  zero payload bits

definitionCount  u7 0..100 accepted by the current client
repeat definitionCount:
    clientOnly   bool
    writable     bool
    ephemeral    bool
    sizeKind     u1 0 = fixed, 1 = variable
    fixedSize?   u16
    serverOnly   bool
    identifier   u8
    handle       u32

reserved           bits[19]
online             bool
localPresenceId    u32
masterPresenceId   u32
fieldDataByteCount u11 0..1024
alignToByte
fieldData          bytes[fieldDataByteCount]
reserved           bits[11]
clearedHandles     u32[count:u4]
handles            u32[count:u4]
variableSizes      u16[count:u4]
levelZero?         { isLastPacket bool, target u32 }
serverOnly         u8

endOfInitial?  bool
updateCount    u7 0..64
repeat updateCount:
    operation  choice { add | remove | modify }
    subject    choice { character | account | presence }

endOfInitial?  bool
entryCount      u7 0..64
repeat entryCount:
    accountId  u32
    fullName?  optional value
    nickname?  UTF-8
    role       u32

entryCount      u7
endOfInitial?   bool

token          u32
generatedCheck u23 rolling check seeded with 7
maxItemsMinus1 u6 request range 1..50
streamKind     u1 1 = description
channel        FourCC
itemName       FourCC
locale         FourCC
referenceTime  s32
direction      u1 0 = before, 1 = after

itemCount  u6 0..49
repeat itemCount:
    reserved         bits[23]
    alignToByte
    contentHandle  blob[40]
    publicationTime s32
token       u32
totalItems  u16
offset      u16

result  choice {
    success {
        authorityState       bool
        rankedMatchmakers     RankedMatchmakerConfig[count:u7]
        leagues               League[count:u9]
        seasonInfo           SeasonInfo
        leagueConfigurations LeagueConfig[count:u9]
    }
    failure  u16
}

namePattern          UTF-8 u13 byte count; up to 4096 bytes
tagPattern           UTF-8 u13 byte count; up to 4096 bytes
informationCacheSize u32
memberCacheSize      u32
informationExpiry    s32
onlineStatusExpiry   s32
eventExpiry          s32

client → server
clientHash     u32
requestId      u32
recordAddress  Profile::RecordAddress
readFlags      bits[5]
pathLength     u8
path           bytes[pathLength]

server → client
result         choice { Start, Block, Failure, Cache }
requestId      u32

type     enum { 1=SETTING_ACCOUNT, 2=SETTING_GAME, 3=SETTING_TOON }
path     blob[0..32]
address  Profile::RecordAddress { label, id }

ChannelListRequest { }  zero payload bits

reserved    bits[37] 27 + 1 + 9 generated bits
entryCount  u6
repeat entryCount:
    kind        u8
    index       u16
    reserved    bits[24]
identifier  u16

EnumConferenceDescriptions { }  zero payload bits

isLast       bool
reserved     bits[27]
decoy?        s32
entryCount   u6
repeat entryCount:
    reserved   bits[23]
    identifier u32
    sortOrder  u16
    marker     bool

token  u32
key    Conference::LocatorKey choice {
    0 private  UTF-8[0..31 chars, 0..124 bytes]
    2 public   { locale FourCC, name u16 }
    3 club     { club u32 }
}

result  choice {
    0 success { memberHandle u32, channelIndex u3,
                voiceSessionId, channelType u4,
                name?, config?, inviter? }
    1 failure { reason u16, channelType? u4 }
}
token?  u32

endOfInitial  bool
channelIndex  u3 0..6
changes       MembershipChange[1..64]

MembershipChange = choice {
    leaving
    joining       member handle, presence ID, status values
    updateStatus  member handle, one status value
}

channelIndex  u3 0..6

bodyByteCount  u10 0..1020
alignToByte      zero bits
body             UTF-8 bytes
channelIndex     u3 0..6

memberHandle   u32
bodyByteCount  u10 0..1020
alignToByte      zero bits
body             UTF-8 bytes
channelIndex     u3 0..6

token  u32
index  u8
key    Conference::LocatorKey
type   u1 enum { 0=AUTO_JOIN, 1=RECENTLY_JOINED }

token   u32
result  choice {
    0 success  s32 time value
    1 failure  u16 error code
}

Back to contents

10. Unresolved portions

1. Frnd/33 is defined for an empty page; the generated order of a non-empty toon-block entry remains unknown.
2. Server echo of an outbound Chat/11 message still needs explicit verification. Automated validation remains passive and never sends chat.
3. Numeric public-channel identifiers still need a reliable source of localized display names.
4. Additional registry services and commands remain metadata-only until their command mappings and generated wire orders are established.

Back to contents

11. Glossary

Battle.net platform

The complete modern account and game-service system. It includes BGS, web authentication, GameUtilities, and game-native services.

BGS (Battle.net Game Services)

The protobuf RPC layer carried here as one RPC per WebSocket binary message inside TLS. BGS handles generic connection, authentication, challenge, account, and GameUtilities calls.

BGS WebSocket

The RFC 6455 transport selected with subprotocol v1.rpc.battle.net. Its binary-message boundary delimits the complete BGS RPC body when the protobuf header omits size.

Cached web credential

An opaque value returned by AuthenticationServer method 8 after successful authentication and offered in a later LogonRequest. It is distinct from the short-lived credential returned by the interactive web challenge.

BSN

This document's short name for SC2's native, bit-packed service protocol. It is schema-delimited and routed by service slot and command.

Front

The regional SC2 BGS connection used before the native handoff.

Sunken

The SC2-native endpoint that accepts Resume authentication and then carries protected BSN service traffic.

GameUtilities

A generic BGS service. Its ProcessClientRequest method performs the SC2-specific Front-to-Sunken handoff on this path.

Protobuf descriptor

Schema metadata for a BGS message or service. BGS service names and methods are recoverable from standard protobuf descriptors embedded in the client.

BSN metadata

SC2's separate version-7 native type library, embedded in the executable rather than sent in BSN records. A numeric type ID selects a structural record and an optional naming record; recursively resolving child IDs produces the logical payload schema. It is not a protobuf descriptor set.

Frame

A BGS header/body unit, or the explicitly named native Connection/13 MessageFrame. The term is not used as a synonym for every native BSN record.

Packet

A convenient but ambiguous informal term. This document prefers BGS frame, BSN record, and TCP segment because each has a different boundary.

Record

One native BSN route header plus its schema-delimited payload and final byte-boundary padding.

Schema-delimited

A record boundary determined by executing the route-selected payload schema, rather than by reading an outer record-length field. Local counts, selectors, and presence bits determine nested extents; completion of the top-level value determines the logical record end.

Route

The native tuple (direction, service FourCC, command). Direction matters because the same command number may name different request and notify types.

Service hash

A 32-bit FNV-1a hash of a full protobuf service name, used for BGS dispatch after the initial Connect.

BGS token

A protobuf-header correlation value joining an RPC response or callback acknowledgement to the corresponding call. It is unrelated to a Chat request's application-level m_token.

Authentication module ID

The 40-byte identifier in an Auth/2 ModuleInput: an eight-byte usage prefix followed by a 32-byte opaque module identity. It selects how that module's data is processed. A module may produce no response element: in Resume, the locally checked thumbprint produces none and the session-proof module produces the sole output. See the exact layout and known IDs.

Service slot

A session-local four-bit number selecting a native BSN service. It is not a chat channel.

Client channel index

A three-bit Chat payload field selecting one of up to seven locally tracked chat channels. It is independent of the native service slot.

LocatorKey

A native Chat choice identifying a private, public, or club conference. Public channels use a locale FourCC and a channel-name string ID.

Generated order

The actual field order emitted by SC2's generated native serializer. For an obfuscated type it may differ from reflection-member order and may include otherwise unnamed reserved bits.

Resume

Blizzard’s name for the native Auth exchange that continues Front-authorized account, game-account, and key context on a new Sunken connection. The exact names Authentication::ResumeRequest and Authentication::ResumeResponse occur in SC2’s embedded BSN metadata. It does not mean resuming the previous TCP socket or restoring an earlier chat or game session. See the nomenclature explanation.

NO_RESPONSE

A protobuf RPC declaration stating that a BGS callback has no reply frame. It is semantically different from a response whose protobuf body is empty.

FourCC

A four-byte symbolic identifier such as Chat, Auth, Mc64, or enUS.

Back to contents

12. Prior art and source material

The 6+1+4 bit header and unusual bit order were publicly described during the original Battle.net 2 era. The sources below also provide protobuf, replay-format, and GameUtilities context useful when interpreting the live SC2 protocols.

• BNETDocs: Battle.net v2 Information
• 2011 Battle.net v2 packet research referenced by BNETDocs
• Blizzard/s2protocol — official replay-protocol decoder, useful for comparison but not the live social protocol
• Blizzard build-97563 replay protocol JSON
• d4-bnet-mitm — public modern BGS protobuf decoding prior art
• Plasmawatch login-server — public BGS login-server implementation
• CypherCore GameUtilitiesService.cs — public GameUtilities and Command_* precedent for another Blizzard game

Back to top