Tim Leonard's Website

Reverse Engineering Dark Souls 3 Networking (#7 - Realtime Mechanics)

2022-06-20T00:00:00+00:00

Recap

In the previous entry we went over asynchronous gameplay mechanics. No we are going to move onto the more interesting real-time gameplay mechanics, these are mechanics were you are directly interacting with other players - namely summoning or invading them!

This should be quite an interesting post!

Summoning

The main functionality of Dark Souls 3’s cooperative online comes from summoning. Unlike a lot of traditional games, there are no lobbies and no invites - instead players can place signs anywhere in the world, which can be seen by other players, and can be interacted with to bring the player who placed the sign into the other users world.

Initially this works very similarly to the async mechanics. To create a remove a sign the player uses some familiar types of requests.

message RequestCreateSign {
    required uint32 map_id = 1;
    required uint32 online_area_id = 2;
    required MatchingParameter matching_parameter = 3;
    required bool is_red_sign = 4;
    required bytes player_struct = 5;
}

is_red_sign determines if the sign is for summoning for PvP rather than the normal PvE usage of signs.
player_struct contains a serialized representation of the player character, which is shown as a ghost in other players worlds when they examine the sign.
matching_parameter I’ll explain how this one works below as it’s fairly critical to a lot of gameplay elements.

message RequestCreateSignResponse {
    required uint32 sign_id = 1;
}

sign_id is a unique, sequentially incrementing identifier for the sign and used by all future requests that reference the placed sign.

Removal is again, very familiar, just providing the sign id and its area.

message RequestRemoveSign {
    required uint32 map_id = 1;
    required uint32 online_area_id = 2;
    required uint32 sign_id = 3;
}

message RequestRemoveSignResponse {
    // Empty response.
}

Viewing signs in an area is fairly straightforward, every couple of minutes or so request is made to get a list of signs in the area the player is in.

message SignInfo {
    required uint32 player_id = 1;                      
    required uint32 sign_id = 2;                        
}

message SignDomainGetInfo {
    required uint32 online_area_id = 1;                    
    required uint32 max_signs = 2;                         
    repeated SignInfo already_have_signs = 3;
}

message RequestGetSignList {
    required uint32 unknown_id_1 = 1;                       
    repeated SignDomainGetInfo search_areas = 2;
    required uint32 max_signs = 3;                          
    required MatchingParameter matching_parameter = 4;
    required SignGetFlags sign_get_flags = 5;
}

message SignData {
    required SignInfo sign_info = 1;                    
    required uint32 online_area_id = 2;                 
    required MatchingParameter matching_parameter = 3;  
    required bytes player_struct = 4;                   
    required string steam_id = 5;                       
    required uint32 is_red_sign = 6;                    
}

message GetSignResult {
    repeated SignInfo sign_info_without_data = 1; 
    repeated SignData sign_data = 2;
}

message RequestGetSignListResponse {
    required GetSignResult get_sign_result = 1;
}

While this is made up of a lot of different structures, the actual concept is fairly straightforward. The game sends a list of areas we want signs from (SignDomainGetInfo), and the server sends back any signs in those areas. A bit of optimization is done here by providing a list of signs the game already knows about in the already_have_signs list, the server will not send back the full data for these signs, just a confirmation they still exist in sign_info_without_data.

Where things become interesting is in the MatchingParameter structure. The server doesn’t send back all signs that exist in an area, only the ones the player can actually summon, the rules that dictate who they can summon are adjusted such that the player is matched with someone of similar skill and gets a fair gameplay experience. This structure is also used in a lot of other mechanics that require matchmaking, you will see it more below.

message MatchingParameter {
    required uint32 regulation_version = 1;         
    required uint32 unknown_id_2 = 2;                        
    required uint32 allow_cross_region = 3;               
    required uint32 nat_type = 4;                     
    required uint32 region = 5;                     
    required uint32 soul_level = 6;                                             
    required uint32 soul_memory = 7;                                           
    optional string unknown_string = 8;                   
    required uint32 clear_count = 9;                     
    required string password = 10;                                              
    required Covenant covenant = 11;                                            
    required uint32 weapon_level = 14;                                              
    optional string unknown_id_15 = 15;                   
}

So what are the actual rules that dictate who can play together? Essentially the server goes through every sign thats been created, and compares the MatchingParameter, provided when the sign was created, against the MatchingParameter provided with the RequestGetSignList request. The following rules are applied:

Can match only if regulation_version, which represents the version of the game, is equal.
Can match only if region is the same, or allow_cross_region is true for both players.
Can match only if nat_type, which represents the ability for different games to connect together, is compatible.
Can match only if password is the same for both players.
Can match only if soul_level and weapon_level are within limits (described below), except where a password is supplied, or both players have a soul_level over 351.

The big one here is how we determine if a player has a soul level and weapon level within limits. The limits depend upon what type of gameplay we are trying to summon for - PvE has more relaxed limits that PvP for example.

For cooperative summoning the equation used is:

Minimum = (Level * 0.9) - 10
Maximum = (Level * 1.1) + 10

Where Level is the soul level of the player requesting a list of signs.

For example, a player with a soul level of 125 can summon:

Minimum = ((125 * 0.9) - 10) = 102
Maximum = ((125 * 1.1) + 10) = 147

Weapon level matching is slightly more complicated, an array of the maximum weapon level a player can match is checked against both the summoner and the owner of the sign (called the host).

MaxLevels = [ 1, 2, 3, 4, 6, 7, 8, 9, 10, 10, 10 ]
CanMatch = (WeaponLevel <= WeaponLevelUpperLimit[HostWeaponLevel] && HostWeaponLevel <= WeaponLevelUpperLimit[WeaponLevel]);

Once the player has been provided a list of signs by the server, they will be spawned into the world, when the player activates them and attempts to summon them, they will send the following request to the server:

message RequestSummonSign {
    required uint32 map_id = 1;
    required uint32 online_area_id = 2;
    required SignInfo sign_info = 3;
    required bytes player_struct = 4;
}

player_struct is a similar structure to the one we provided when we created a sign, except this time it represents the person summoning the sign.

message RequestSummonSignResponse {
    // Empty response.
}

Once the server receives this request it will send a push message to the original creator of the sign,

message SummonSignMessage {
    required uint32 player_id = 1;
    required string steam_id = 2;
    required SignInfo sign_info = 3;
    required bytes player_struct = 4;
}

message PushRequestSummonSign {
    required PushMessageId push_message_id = 1;     
    required SummonSignMessage message = 2;
}

This push message supplies the steam_id and player_struct of the player who summoned the sign.

At this point the game will determine if the sign is still valid, and if the original creator is still in a location they can be summoned from (e.g. they haven’t walked into a boss battle or been invaded). If everything goes as expected, then both players establish a peer-to-peer connection via steams network API, this connection is then used for exchanging all real-time gameplay network state, the main server is no longer used.

If however something prevents the summoning from taking place, the game will send the following request to the server.

message RequestRejectSign {
    required uint32 player_id = 1;              
    required uint32 unknown_2 = 2;              
    required uint32 sign_id = 3;
    required bool unknown_4 = 4;                
    required bool unknown_5 = 5;                
}

^{Most of the values in this structure appear to be constant, so can mostly be ignored.}

message RequestRejectSignResponse {
    // Empty response.
}

This will cause the server to send a push message back to the player that attempted to summon the sign.

message RejectSignMessage {
    required uint32 sign_id = 1;
    required uint32 player_id = 2;      
}

message PushRequestRejectSign {
    required PushMessageId push_message_id = 1;
    required RejectSignMessage message = 2;
}

At this point the game will show a “Summoning failed” message to the player and will refresh the signs again.

One interesting bit of trivia - When a sign is used or removed by the player who created it, the server sometimes sends a push message to all players’s it has sent the sign info to in the past.

message RemoveSignMessage {
    required uint32 player_id = 1;
    required uint32 sign_id = 2;
}

message PushRequestRemoveSign {
    required PushMessageId push_message_id = 1;     
    required RemoveSignMessage message = 2;
}

You would expect that to remove the sign from the world so the player’s cannot accidentally summon it right? Well actually the game seems to entirely ignore it. This might go some way to explaining the common problem of people trying and failing to summon signs during busy activity, because even if they’ve been used they stick around until the next refresh!

Invasions

So we’ve explained how the cooperative PvE aspect of the game works, but what about the PvP aspect? This mainly comes from a feature that people either love or loath - Invasions. Invasions allow other players to invade your game without request and come and kill you, often at the least opportune times!

So how do the invasions work? Well when a user uses one of the multiplayer items that allow them to invade another game - such as the Red Eye Orb - The game is placed into a state where it is constantly looking for other players they can invade.

This searching is accomplished by sending a request every few minutes to the main server.

message RequestGetBreakInTargetList { 
    required uint32 map_id = 1;
    required uint32 online_area_id = 2;
    required uint32 max_targets = 3;                       
    required MatchingParameter matching_parameter = 4;
    required uint32 unknown_5 = 5;                          
}

message BreakInTargetData {
    required uint32 player_id = 1;
    required string steam_id = 2;
}

message RequestGetBreakInTargetListResponse {
    optional uint32 map_id = 1;
    optional uint32 online_area_id = 2;
    repeated BreakInTargetData target_data = 3;
}

As you can guess this works the same as all the other request-list-of-things type requests. We provide an area we want to look at, and our matching parameters and the server sends us back any other players that match the rules.

The matching parameters are almost the same as PvE except for a couple of additional rules:

Cannot match with players that have been invaded in the last 20 minutes, unless a Dried Finger is in use.
Cannot match with players that have a full game (There are a total of 6 players slots for pvp and pve, the number of slots allocated to each depends on the area).
Cannot match with players who are not currently in an “embered” form.
Games with more than one PvE summon in it are prioritized for invasion.

In addition to these rules the soul level range is adjusted to;

Minimum = (Level * 0.9)
Maximum = (Level * 1.1) + 20

Or if you are in the mound maker covenant, you can invade slightly higher players:

Minimum = (Level * 0.9)
Maximum = (Level * 1.15) + 20

For the targets of invasion the server uses the information supplied by the call to RequestUpdatePlayerStatus to do the matching.

Once the invader has a target player they send the server a request to invade:

message RequestBreakInTarget {
    required uint32 map_id = 1;
    required uint32 online_area_id = 2;
    required uint32 player_id = 3;
    required uint32 unknown_4 = 4;                   
}

message RequestBreakInTargetResponse {
    // Empty response.
}

At which point the server sends a push request to the player being invaded.

message PushRequestBreakInTarget { 
    required PushMessageId push_message_id = 1;
    required uint32 player_id = 2;                        
    required string steam_id = 3;       
    required uint32 unknown_4 = 4;                          
    required uint32 map_id = 5;
    required uint32 online_area_id = 6;
}

If the targeted player is no longer in a state where they can be invaded they send a rejection to the server.

message RequestRejectBreakInTarget {
    required uint32 player_id = 1;                         
    required uint32 unknown_2 = 2;                          
    required uint32 map_id = 3;
    required uint32 online_area_id = 4;
    required uint32 unknown_5 = 5;                          
}

Which results in the server sending a push message back to the invader telling them they have been rejected, and causing a “Failed to invade” message to be shown to the player and for the game to try a different target.

message PushRequestRejectBreakInTarget {
    required PushMessageId push_message_id = 1;            
    required uint32 player_id = 2;
    required uint32 unknown_3 = 3;                         
    required string steam_id = 4;                           
    required uint32 unknown_5 = 5;                         
}

Remote Code Execution, Oh No!

Small segway, bare with me!

Now we get onto something very worrying. If the player is able to be invaded then a request is made to the server to provide them with the invader’s information so a peer-to-peer connection can be established and gameplay can begin.

message RequestSendMessageToPlayers { 
    repeated uint32 player_ids = 1; 
    required bytes message = 2;
}

Ok, that’s a weird function, it doesn’t match any of the unambiguous requests the server normally takes? Why they chose to use this rather than a specific request I will never know. What this absolutely awful request does is it will send a serialized message directly to any player_id’s provided - without any serialization or limitation on which players it can be sent to. Normally it’s used to send the following message to the invader.

message PushRequestAllowBreakInTarget { 
    required PushMessageId push_message_id = 1;
    required uint32 player_id = 2;                         
    required bytes  player_struct = 3;
    required uint32 unknown_4 = 4;                         
}

However it can actually be sent at any time when connected to the server, and can be used to send absolutely any protobuf message type in the game.

Does that sound really dodgy? Well it sure is! It’s actually the vector used by the Remote Code Execution vulnerability that got the servers taken offline for the last 6 months. It can be used to send the exploit to -everyone- currently connected to the server, they don’t need to be active in multiplayer, they just need to be connected. Very worrying! The actual exploit was due to the game not sanitizing any of the data blobs the server exchanges with players (such as the player_struct above), allowing for buffer overruns and RCE. This function takes a nasty RCE and turbo-charges it to be capable of exploiting tens of thousands of people at once.

A nice rewrite up of the exploit by the original author is available on GitHub Here if you are interested.

Covenant Visits

There is one final piece of the puzzle of the invasion and summoning mechanics. This is what the game calls “Visits”, these are situations where players can be automatically summoned for coop or invasion automatically without requesting it. This function is tied to different covenants in the game, and mostly revolve around either protecting an area from anyone who enters it, or protecting players who have been invaded.

Unlike invasions or summoning, no network requests are sent by the player who will be visiting another world. Instead they mark themselves as able to visit when they send a RequestUpdatePlayerStatus. Players who are in a situation where they can be visited then search for potential visitors.

There are 5 different covenants whos members can be potential visitors. They all have slightly different criteria and level ranges.

Covenant	Criteria	Lower Range	Upper Range
Blue Sentinels	Player must be being invaded, friendly to player.	`(Level * 0.9) - 15`	`(Level * 1.1) + 15`
Blades of the Darkmoon	Player must be being invaded, friendly to player.	`(Level * 0.9) - 15`	`(Level * 1.1) + 15`
Watchdog of Farron	Player must be embered and inside the Farron Swamp area. Hostile to player.	`(Level * 0.8) - 20`	`(Level * 1.1) + 0`
Aldrich Faithful	Player must be embered and inside the Anor Londo area. Hostile to player.	`(Level * 0.8) - 20`	`(Level * 1.1) + 0`
Spears of the Church	Summoned as part of Halflight boss fight. Hostile to player.	`(Level * 0.8) - 20`	`(Level * 1.1) + 0`

When a player meets the criteria for a given covenant they will send out the following request every 10 minutes or so.

message RequestGetVisitorList {
    required uint32 map_id = 1;   
    required uint32 online_area_id = 2;   
    required uint32 max_visitors = 3;
    required MatchingParameter matching_parameter = 4;
    required VisitorPool visitor_pool = 5;                      
    required uint32 unknown_6 = 6;                             
}

visitor_pool Identifies the pool of potential visitors we pull from. Some covenants (such as Blue Sentinels and Blades of the Darkmoon) use the same pool.

message VisitorData {
    required uint32 player_id = 1;
    required string player_steam_id = 2;
}

message RequestGetVisitorListResponse {
    required uint32 map_id = 1;   
    required uint32 online_area_id = 2;  
    repeated VisitorData visitors = 3;
}

Once a candidate is found, the game will send a request to ask the visitor to join:

message RequestVisit {
    required uint32 map_id = 1;   
    required uint32 online_area_id = 2;   
    required VisitorPool visitor_pool = 3;        
    required uint32 player_id = 4;              
    required bytes  player_struct = 5;
}

player_struct has the same kind of serialized data as you have seen for invasions and summons, the summoning players state.

message RequestVisitResponse {
    // Empty response.
}

The server then sends a push message to the player being summoned.

message PushRequestVisit {
    required PushMessageId push_message_id = 1;       
    required uint32 player_id = 2; 
    required string player_steam_id = 3;
    required bytes  player_struct = 4;                           
    required VisitorPool visitor_pool = 5;       
    required uint32 map_id = 6;
    required uint32 online_area_id = 7;
}

The player being summoned will then either establish a connection with the summoner and enter their world, otherwise they will send back a request to the server asking to reject the request.

message RequestRejectVisit {
    required uint32 player_id = 1;                                        
    required VisitorPool visitor_pool = 2;              
    required uint32 map_id = 3;
    required uint32 online_area_id = 4;
    required uint32 unknown_5 = 5;                      
}

message RequestRejectVisitResponse {
    // Empty response.
}

In this case the server will send a push request notifying the summoner of the rejection. That player will then go back to scanning for other potential candidates.

message PushRequestRejectVisit {
    required PushMessageId push_message_id = 1;    
    required uint32 player_id = 2;
    optional VisitorPool visitor_pool = 3;              
    required string steam_id = 4;                           
    required uint32 unknown_5 = 5;                         
}

All super easy right? It’s almost the exact flow that’s used for summoning and invasions, just with some slightly different data in the requests.

Undead Matches

The final real-time multiplayer feature is the “Undead Arena”. Unlike the other mechanics this one isn’t diegetic, it is controlled via a pretty standard matchmaking menu. This menu allows the user to match up with a number of other players to compete in various PvP game modes.

As with the other game modes the level matching has its own values, matching close to those used by summon-signs.

Minimum = (Level * 0.9)
Maximum = (Level * 1.1) + 20

These limits can be removed by setting a matchmaking password in the undead match menu.

Network wise the undead matches have probably the most complex request flow in the game. It all starts when the user searches for a match, at which point the following request is made:

enum QuickMatchGameMode {
    Duel = 0;
    TwoPlayerBrawl = 1;
    FourPlayerBrawl = 2;
    SixPlayerBrawl = 3;
    TwoVersusTwo = 4;
    ThreeVersusThree = 5;
    TwoVersusTwo_Team = 6;
    ThreeVersusThree_Team = 7;
}

message RequestSearchQuickMatch {
    required QuickMatchGameMode mode = 1;
    repeated group Map_id_list = 2 {
        required uint32 map_id = 1;
        required uint32 online_area_id = 2;
    }
    required uint32 max_results = 3;                      
    required MatchingParameter matching_parameter = 4;
}

Map_id_list contains a list of maps the user wants to play in. These are unique to undead matches, they are not part of the normal game world.
mode is the pool of matches the player wants to search for results in. This doesn’t perfectly match up with the game modes in the UI - for example the *_Team pools are used instead of the equivalent standard pool if the player sends a password that applies only to one team in a game mode.

message QuickMatchData {
    required uint32 host_player_id = 1;      
    required string host_player_steam_id = 2; 
    required uint32 online_area_id = 3;             
}

message QuickMatchSearchResult {
    optional QuickMatchData data = 2;
    required uint32 unknown_3 = 3;                
    required uint32 unknown_4 = 4;                  
}

message RequestSearchQuickMatchResponse {
    repeated QuickMatchSearchResult matches = 1;
}

If no matches are found the player sends a request to create a new match:

message RequestRegisterQuickMatch {
    required QuickMatchGameMode mode = 1;
    required uint32 map_id = 2;
    required uint32 online_area_id = 3; 
    required MatchingParameter matching_parameter = 4;
    required uint32 unknown_5 = 5;                      
}

message RequestRegisterQuickMatchResponse {
    // Empty response.
}

If the player ever cancels matchmaking they will dispose of their match using the following request.

message RequestUnregisterQuickMatch {
    required QuickMatchGameMode mode = 1;
    required uint32 map_id = 2;
    required uint32 online_area_id = 3; 
    required uint32 unknown_4 = 4;                      
}

message RequestUnregisterQuickMatchResponse {
    // Empty response.
}

Matches are uniquely identified by the player who is hosting them. A player can only host a single match at a time.

If a match was found during the initial search the joining flow begins, which starts by a request asking the server to let us join the match.

message RequestJoinQuickMatch {
    required QuickMatchGameMode mode = 1;
    required uint32 character_id = 2;
    required uint32 host_player_id = 4;              
    required uint32 map_id = 5;                  
    required uint32 online_area_id = 6;             
    required uint32 unknown_7 = 7;                  
    required string password = 8;                  
}

message RequestJoinQuickMatchResponse {
    // Empty response.
}

The server then sends the host of the match a push message notifying them of the pending join.

message JoinQuickMatchMessage {
    required uint32 join_player_id = 1;                                        
    required string join_player_steam_id = 2;                                  
    required uint32 join_character_id = 3;                                     
    required uint32 online_area_id = 4;                                        
    required uint32 unknown_5 = 5;                                             
    required string password = 6;                                              
}

message PushRequestJoinQuickMatch {
    required PushMessageId push_message_id = 1;                  
    required JoinQuickMatchMessage message = 2;
}

The host can then either respond by accepting the join request.

message RequestAcceptQuickMatch {
    required QuickMatchGameMode mode = 1;
    required uint32 join_player_id = 4;                           
    required bytes  data = 5;                  
}

message RequestAcceptQuickMatchResponse {
    // Empty response.
}

Or by rejecting the join request.

message RequestRejectQuickMatch {
    required QuickMatchGameMode mode = 1;
    required uint32 map_id = 2;  
    required uint32 online_area_id = 3;
    required uint32 join_player_id = 4; 
    required uint32 unknown_5 = 5;              
}

message RequestRejectQuickMatchResponse {
    // Empty response.
}

While results in an appropriate push message being send to the joining player.

message AcceptQuickMatchMessage {
    required uint32 host_player_id = 1;  
    required string host_player_steam_id = 2;
    required bytes  metadata = 3;   
}

message PushRequestAcceptQuickMatch {
    required PushMessageId push_message_id = 1;                  
    required AcceptQuickMatchMessage message = 2;
}

message RejectQuickMatchMessage {
    required uint32 host_player_id = 1;                         
    required uint32 unknown_2 = 2;                              
}

message PushRequestRejectQuickMatch {
    required PushMessageId push_message_id = 1;                     
    required RejectQuickMatchMessage message = 2;
}

If the player is accepted into the game, the games establish a peer to peer connection and await for enough other players to join for the game to begin.

Once the game begins the host will first unregister the match using the RequestUnregisterQuickMatch shown above, followed by telling the server the game is starting and who is in it.

message RequestSendQuickMatchStart {
    required uint32 unknown_1 = 1;                 

    repeated group  Session_member_list = 2 {
        required uint32 player_id = 1;
        required uint32 character_id = 2;           
    }
}

message RequestSendQuickMatchStartResponse {
    // Empty response.
}

Once the game is complete, each player in the game will then send the result of the match to the server so their new ranks can be calculated.

enum QuickMatchResult{
    QuickMatchResult_Win = 0;
    QuickMatchResult_Lose = 1;
    QuickMatchResult_Draw = 2;
    QuickMatchResult_Disconnect = 3;                    
}

message QuickMatchRank {
    optional uint32 rank = 1;       
    optional uint32 xp = 2;         
}

message RequestSendQuickMatchResult {
    required QuickMatchGameMode mode = 1;
    required uint32 unknown_2 = 2;                      
    required QuickMatchResult result = 3;               
    required bool local_won = 4;                        
    required QuickMatchRank remote_rank = 5;            
    required QuickMatchRank local_rank = 6;             
    optional string unknown_7 = 7;                      
}

The server then responds with the players new rank.

message RequestSendQuickMatchResultResponse {
    required uint32 unknown_1 = 1;             
    required QuickMatchRank new_local_rank = 2;
}

Interestingly the rank just seems to be incremented from the local_rank sent in the initial request. You can likely just “cheat” your way to the highest rank by fiddling with the initial local_rank value, not that I recommend you do that.

Final Words

Well I hope you found this series interesting, I’m sorry the last couple of posts were basically over-complicated flow charts. Unless I can think of some other interesting tid-bits of information, this is the conclusion. We’ve gone all the way from finding out how to get the game to connect to a different server, to mapping out how all the game features work at a request level.

There are a handful of other features the main server is capable of, but most are either restricted administration functions, or things that are just plain uninteresting. Feel free to check out the current reversed protobuf file if you want to see the other requests that are floating around.

Dark Souls 3 is certainly a technically interesting game, and its network services definitely have some bizarre quirks, not to mention alarming security vulnerabilities. If you haven’t already though, you should pick up a copy of it, it’s without a doubt one of best games of all time, and From Software deserve your support to continue producing these types of games (I need my fix!).

Hopefully they can resolve the security vulnerabilities and get the official servers back online soon, and we can all enjoy some jolly cooperation on much more populated servers!

Reverse Engineering Dark Souls 3 Networking (#6 - Async Mechanics)

2022-06-18T00:00:00+00:00

Recap

In the previous entry we went over the initial message exchanges that happen with the server, and how character data is managed and updated.

In this post we’re going to start looking into asynchronous gameplay mechanics. For those not familiar with the term, asynchronous gameplay is a term used to mean gameplay where you are no directly interacting with another player in real-time. In Dark Souls I use this to refer to mechanics such as blood stains, messages, ghosts and other similar things.

Blood Messages

So lets dive in with the most well known, and meme’d, gameplay feature of From Software games - Messages. Or as known in the code “Blood Messages”. These are messages people can place anywhere in the game-world, with the restriction that the message can only use fixed phrase-structures and a fixed vocabulary of insertable words.

How blood messages work is super straight forward.

Each time the player places a message, its stored locally in the users save data, there are slots for a maximum of 10 messages.

At the same time the message is stored the follow exchange is sent to the server:

message RequestCreateBloodMessage {
    required uint32 online_area_id = 1;
    required uint32 character_id = 2;                      
    required bytes  message_data = 3;
}

online_area_id is a unique numeric id for the area that the user is, it is used for filtering which blood messages are relevant at a given time.
message_data is a buffer of serialized data that represents the text, associated animation and location of the message that was placed.

message RequestCreateBloodMessageResponse {
    required uint32 message_id = 1;
}

The message_id that is returned is a unique identifier on the server, every message has a unique id. The id is sequential and goes up each time a message has been placed in the game. When this is returned the game stores this information in the save data as well - we shall see why in a moment.

There is also an equivalent remove request if the user deletes one of their messages.

message RequestRemoveBloodMessage {
    required uint32 online_area_id = 1;
    required uint32 message_id = 2;
}

To actually view messages from other players the game will every few minutes send out the following request

message BloodMessageDomainLimitData {
    required uint32 online_area_id = 1;
    required uint32 max_type_1 = 2;                     
    required uint32 max_type_2 = 3;         // Maximum returned is the sum of both of these values.
}

message RequestGetBloodMessageList {
    required uint32 max_messages = 1;                   
    repeated BloodMessageDomainLimitData search_areas = 2;
}

The search_areas field dictates which online areas we want to get messages from, and how many we want to get from that area. Typically this only includes the area the player is currently in.

message BloodMessageData {
    required uint32 player_id = 1;
    required uint32 character_id = 2;   
    required uint32 message_id = 3; 
    required uint32 good = 4;         
    required bytes  message_data = 5;
    required string player_steam_id = 6;
    required uint32 online_area_id = 7;
    required uint32 poor = 8;                   
}

message RequestGetBloodMessageListResponse {
    repeated BloodMessageData messages = 1;
}

The result here is a list of all messages that were found in the given area, including information about who made the message and how many times it’s been rated as good or poor by other players.

To limit the amount of data that the server needs to store at a given time, the server does not actually store any of the bulky message_data. Instead it appears to be held in a “hot cache” in memory, after a given amount of time and once the user is offline the message is evicted from the cache. Only messages in this cache will ever be returned from the RequestGetBloodMessageList.

This is why when you go offline and come back after a week or so, your messages will have only gone up by a few points, as they will normally have been evicted shortly after you went offline. The cache seems to have some heuristics involved to keep messages active which are highly popular, judged by being frequently evaluated.

You might ask then how the game gives the illusion that your messages are persistent and always in the game world? Well what happens is when you log back in with a character the following request is exchanged:

message LocatedBloodMessage {
    required uint32 online_area_id = 1;
    required uint32 message_id = 2;
}

message RequestReentryBloodMessage {
    repeated LocatedBloodMessage messages = 1;
    required uint32 character_id = 2;                   
}

The messages field is a list of all the messages the player has in their save data.

message RequestReentryBloodMessageResponse {
    repeated uint32 recreate_message_ids = 1;       
}

The recreate_message_ids field is a list of all the messages requested which are no longer in the cache, and need to be resent to the server.

If this request returns any message ids, the game initiates another request:

message RequestReCreateBloodMessageList {
    required uint32 character_id = 2;                     

    repeated group Blood_message_info_list = 3 {
        required uint32 online_area_id = 1;
        required bytes  message_data = 2;
        required uint32 unknown_1 = 3;
        required uint32 unknown_2 = 4;
    }
}

Blood_message_info_list is a list of data for all the messages that the server asked us to recreated.

message RequestReCreateBloodMessageListResponse {
    repeated uint32 message_ids = 1;
}

message_ids are the unique id’s for all the messages that have been recreated. I’ve never seen these ids actually change from what the messages were created with, but in theory they may do if the server ever clears its database.

So far, so simple. The only element of the blood messages we haven’t looked at so far is how evaluations are performed. Each message can be rated either good or poor once by a user. When the player rates a message the following request is sent:

message RequestEvaluateBloodMessage {
    required uint32 online_area_id = 1;
    required uint32 message_id = 2;
    required bool was_poor = 3;
}

message RequestEvaluateBloodMessageResponse {
    // Empty response.
}

Simple enough, this request updates the good or bad counter on the server. The server also does one additional thing at this point - it sends a push request to the client who wrote the original message if they are online.

message PushRequestEvaluateBloodMessage {
    required PushMessageId push_message_id = 1;
    required uint32 player_id = 2; 
    required uint32 message_id = 3;
    required string player_steam_id = 4; 
    required bool was_poor = 5; 
}

This tells the original author who evaluated the message and if they evaluated as good or poor. This is used by the game to grant the player a health refill - which occurs regardless of it was a good or poor rating.

Ritual Marks

Ritual Mark’s aren’t something you will ever see in game, they are a feature that was cut during development. I’m mentioning them now more as trivia than anything, the game contains a complete protobuf set that is structurally setup almost the same as the blood messages. It looks like this was likely something to do with the cut feature that allow you to create bonfires anywhere in the world using enemy corpses.

The below video is worth watching, it both explains and recreates this functionality.

Blood Stains

So on to the next feature - blood stains! These are puddles of blood that are shown wherever players in the world have died. Going up to them allows the user to interact with them and view a ghostly replay of the original players death.

So how do these work? Simple, when the user dies the following request is sent.

message RequestCreateBloodstain {
    required uint32 online_area_id = 1;
    required bytes  data = 2;                       
    required bytes  replay_data = 3;         
}

message EmptyResponse {
}

Weirdly this is one of the few requests that doesn’t have a dedicated response type, it just uses a generic EmptyResponse protobuf.

Like the blood messages the creation request is simple, it specifies the online area where the bloodstain was made and then includes a block of serialized data that describes the bloodstain. The only interesting thing here is the data is split into two parts, the general data, including things like the location, and the chonky replay_data that includes everything required to show a replay of the player’s death - serialized animations.

To actually view blood stains from other players the game will every few minutes send out the following request

message DomainLimitData {
    required uint32 online_area_id = 1;
    required uint32 max_items = 2;
}

message RequestGetBloodstainList {
    required uint32 max_stains = 1;               
    repeated DomainLimitData search_areas = 2;
}

message BloodstainInfo { 
    required uint32 online_area_id = 1;
    required uint32 bloodstain_id = 2;
    required bytes data = 3;    
}

message RequestGetBloodstainListResponse {
    repeated BloodstainInfo bloodstains = 1;
}

Again, this works similar to the blood messages. We say what areas we are interested in, and how many bloodstains we want, and the server replies with a list of the available bloodstains and the data that goes along with them.

When the user interacts with a bloodstain, an additional request is made for the data required to show the ghost. This avoids the server having to send the data to players who may never interact with the bloodstain.

message RequestGetDeadingGhost {
    required uint32 online_area_id = 1;    
    required uint32 bloodstain_id = 2;
}

message RequestGetDeadingGhostResponse {
    required uint32 online_area_id = 1;    
    required uint32 bloodstain_id = 2;
    required bytes replay_data = 3;
}

Ghosts

Blood stains aren’t the only place you can see ghosts of other players in the game. The game also actions that occur near bonfires and displays these in other players worlds, giving the illusion of a populated world.

This is probably one of the simplest features in the game. The game will randomly record actions several seconds of action near the bonfire, and based on unknown heuristics, when it decides one of these replays is “interesting” enough it will send a request to the server:

message RequestCreateGhostData {
    required uint32 online_area_id = 1;
    required bytes replay_data = 2;
}

message RequestCreateGhostDataResponse {
    // Empty response.
}

The replay data is structured almost identically to the blood stain ghosts.

When the player is sitting at, or near a bonfire, the game will very infrequently send the following request to the server:

message DomainLimitData {
    required uint32 online_area_id = 1;
    required uint32 max_items = 2;
}

message RequestGetGhostDataList {
    required uint32 max_ghosts = 1;               
    repeated DomainLimitData search_areas = 2;
}

message GhostData {
    required uint32 unknown_1 = 1;         
    required uint32 ghost_id = 2;
    required bytes  replay_data = 3;
}

message RequestGetGhostDataListResponse {
    repeated GhostData ghosts = 1;
}

Interestingly there is no additional request for the ghost data like you see in the bloodstains, it just sends it straight in the reply. I’m guessing the assumption is we are always going to use it when requested. The maximum number of ghosts requested is also low - normally 3, so they probably didn’t think the additional request was worth it.

As soon as the response is received, one of the ghosts is selected and the ghost replay is run.

The Great Bell

One small and easily missed feature is the great bell in Archdragon Peak.

When you ring it and change the world state ready for the boss, a request is sent to the server.

message RequestNotifyRingBell {
    required uint32 online_area_id = 1;    
    required bytes  data = 2;
}

data contains a very small block of information, seems to just be a single value, possibly the new-game level the player is on.

message RequestNotifyRingBellResponse {
    // Empty response.
}

The server then finds all the other players in the same area specified by online_area_id and sends the following push message to all of them.

message PushRequestNotifyRingBell {
    required PushMessageId push_message_id = 1;
    required uint32 player_id = 2;    
    required uint32 online_area_id = 3;    
    required bytes  data = 4;
}

What does all this network activity result in? If you listen carefully, you can hear other players ringing the bell in the background!

Leaderboards

The Darkmoon Knights covenant maintains a leaderboard of how many contributions each player has made. A special multiplayer item known as the Roster Of Knights allows the player to browse all the players in the covenant and see their current rank.

Implementation of this feature works as a pretty standard leaderboard setup, the system is generic and can be used with any number of leaderboard’s, though the game only uses a single one (board_id for all the messages below is always set to 0).

Each time the user contributes to the covenant their contribution is updated and stored locally in their save data. At the same time, a request is made to the server:

message RequestRegisterRankingData {
    required uint32 board_id = 1;     
    required uint32 character_id = 2;     
    required uint32 score = 3;         
    required bytes  data = 4;
}

score contains the number of contributions the user has made.
data contains a small block of serialized data that contains some misc information such as the users steam-id, used for displaying the user’s name in the leaderboard.

message RequestRegisterRankingDataResponse {
    // Empty Response.
}

When the user opens the leaderboard the first request that occurs is:

message RequestCountRankingData {
    required uint32 board_id = 1;       
}

message RequestCountRankingDataResponse {
    required uint32 count = 1;
}

This tells the game how many entries are in the leaderboard, and thus how many pages of results it needs to show to the player.

As the player pages through each page a request is made to get the data for that particular page of results.

message RequestGetRankingData {
    required uint32 board_id = 1;     
    required uint32 offset = 2;       // 1-indexed.
    required uint32 count = 3;         
}

message RankingData {
    required uint32 player_id = 1;  
    required uint32 character_id = 2;   
    required uint32 serial_rank = 3;
    required uint32 rank = 4;
    required uint32 score = 5;          
    required bytes  data = 6;
}

message RequestGetRankingDataResponse {
    repeated RankingData data = 1;
}

There are two ranks for each entry serial_rank and rank. serial_rank is the order of entries, it always goes from 1 to the number of entries in the board. rank is almost the same except that if two entries have the same value they both share the same rank - this is what’s actually displayed to the player in the UI.

If the player presses X to show their own ranking, a request is first made to find their currently rank, and then the UI switches to the relevant page. If the user has no rank, it just switches to the last page of rankings.

message RequestGetCharacterRankingData {
    required uint32 board_id = 1;       
    required uint32 character_id = 2; 
}

message RequestGetCharacterRankingDataResponse {
    optional RankingData data = 1;
}

If the user selects a player to view their info, the profile overview screen is shown and populated with a request to RequestGetPlayerCharacter to retrieve the player’s character from the last time they uploaded it with the periodic call to RequestUpdatePlayerCharacter

message RequestGetPlayerCharacter {
    required uint32 player_id = 1;
    required uint32 character_id = 2;            
}

message RequestGetPlayerCharacterResponse {
    required uint32 player_id = 1;
    required uint32 character_id = 2;           
    required bytes  character_data = 3;  
}

Coming Up

We’re almost at the part I’m sure everyone is interested in! The next post is going to go over the real-time mechanics, namely invasions, summoning and quick matches. Exciting!

Continue to the next entry

Reverse Engineering Dark Souls 3 Networking (#5 - Character Management)

2022-06-18T00:00:00+00:00

Recap

In the previous posts we’ve looked over the full protocol used by game to communicate with its online services. At this point we are capable of producing a server that can fully communicate with the client.

The last part that remains, is what actually messages are sent between the client and the server to facilitate the game-play mechanics in the game. As with previous posts, I won’t go into detail on how these were disambiguated, as it’s mostly fairly boring pattern matching and browsing of disassembly.

When the user has fully established a connection to the server, the first request that is sent to the server is a nice straightforward one called RequestWaitForUserLogin, the protobuf for which looks as follows;

message RequestWaitForUserLogin {
    required string steam_id = 1;
    required uint32 unknown_1 = 2;
    required uint32 unknown_2 = 3;
    required uint32 unknown_3 = 4;
    required uint32 unknown_4 = 5;
}

And has a response message that looks like this:

message RequestWaitForUserLoginResponse {
    required string steam_id = 1;
    required uint32 player_id = 2; 
}

This exchange as you might guess from the names is to allow the server to do any setup it requires before the client starts making other requests. In DS3OS, and likely on the retail server, this involved grabbing the users account details from the storage database.

You will notice that in the response a player_id value is sent back. This is a unique number that identifies a player on the server, and persists forever, the users steam_id is permanently linked to it. These player ids are what will be used to identify players throughout any future exchanges with the server, steam_ids are never used as identities, they are only passed around in situations where it’s required to facilitate the use of steam functionality.

Once the user has been logged in the server also sends once of its rare push-requests:

message PlayerInfoUploadConfigPushMessage { 
    required PushMessageId push_message_id = 1;                 
    required PlayerStatusUploadConfig config = 2;               
    required uint32 player_character_update_send_delay = 3;     
    required uint32 player_status_send_delay = 4;               
}

This configures how often, and what type, of large messages the client sends to the server. The server may also send this push message at any time while playing. The server uses this to load balance the traffic being sent to the server in real-time. The messages this affects are primarily about reporting of the player’s status and character information.

Announcements

As soon as the player is logged in the first user visible action occurs! This is a simple exchange that uses the following request and response:

message RequestGetAnnounceMessageList {
    required uint32 max_entries = 1;
}

message AnnounceMessageData {
    required uint32 unknown_1 = 1;  
    required uint32 index = 2;
    required uint32 unknown_2 = 3;  
    required string header = 4;
    required string message = 5;
    required Frpg2PlayerData.DateTime datetime = 6;
}

message AnnounceMessageDataList {
    repeated AnnounceMessageData items = 1;
}

message RequestGetAnnounceMessageListResponse {
    required AnnounceMessageDataList changes = 1;
    required AnnounceMessageDataList notices = 2;
}

This request is used to get a list of announcements that are shown to the user on the main menu. On the official server these are filled with patch notes and server status information. Interestingly there is a huge amount of redundant data in this exchange, many of the fields make no difference to how the information is displayed - the split between “change” and “notice” announcements for example, which all get displayed concatenated into a single list when displayed. I suspect some of this may be a left over from development, when they were perhaps displayed differently.

Implementing this allows us to make the first user-visible changes to the server-connection:

Character Registration

At this point if you stay on the main menu, no more exchanges will occur. Messages start being sent as soon as the player selects a character and loads into the game.

The first exchange that’s sent on selecting the character involves these messages:

message RequestUpdateLoginPlayerCharacter {
    required uint32 character_id = 1;                               
    repeated uint32 unknown_2 = 2;
}

message QuickMatchRank {
    optional uint32 rank = 1;       
    optional uint32 xp = 2;         
}

message RequestUpdateLoginPlayerCharacterResponse {
    required uint32 character_id = 1;                              
    required QuickMatchRank quickmatch_brawl_rank = 2;   
    required QuickMatchRank quickmatch_dual_rank = 3;   
}

These messages essentially tell the server what character the player is going to use while playing. The character_id is assigned by the game when you created a new character, it increments sequentially for each character created on the same save file.

As each character has its own entries in most of the online mechanics - leaderboards, messages, etc. You will see that most references to a particular player in-game will uniquely identify them using both a character_id and player_id.

The response to this message also includes the players current ranks for the brawl and duel in the undead matches game mode. It’s a bit of an odd place to put this information, but I figure From Software probably did it to save setting up additional more-specific messages.

Once the player has identified which character they are going to use, they will periodically send the following message exchange, the frequency its sent is determined by the values in the PlayerInfoUploadConfigPushMessage message we saw earlier.

message RequestUpdatePlayerCharacter {
    required uint32 character_id = 1;          
    required bytes character_data = 2;      
}

message RequestUpdatePlayerCharacterResponse {
    // Empty Response
}

^{Note: You will see a lot of these “Empty Response” protobufs, they exist purely to tell the game that their request was received. Failure to send these empty responses back will result in the game deadlocking.}

This message essentially updates a serialized block of save-data describing the character’s equipment/appearance/items/etc, which the server stores persistently even when the player is offline. This block of data can be retrieved for any character using the below message.

In-game this is only used by the Roster of Knights leaderboard item to show another players profile. It’s also likely that from uses this on the backend for cheat-detection and similar purposes.

message RequestGetPlayerCharacter {
    required uint32 player_id = 1;
    required uint32 character_id = 2;            
}

message RequestGetPlayerCharacterResponse {
    required uint32 player_id = 1;
    required uint32 character_id = 2;           
    required bytes  character_data = 3;
}

Player Telemetry

While playing, the game sends back a whole wreath of telemetry data to the server. A lot of this information is fairly uninteresting information - what the player killed, what items they bought, etc. Mostly useful for From Software’s design team. You can look at all this telemetry data by browsing the FpdLogMessage.proto file, these protobuf’s are wrapped in the following message the client sends when the relevant actions occur (there are also a few other message types as well all begin with RequestNotify*):

enum LogType
{
    UseMagicLog = 2020;
    ActGestureLog = 2021;
    UseItemLog = 3000;
    PurchaseItemLog = 3001;
    GetItemLog = 3002;
    DropItemLog = 3003;
    LeaveItemLog = 3004;
    SaleItemLog = 3005;
    StrengthenWeaponLog = 3010;
    GlobalEventLog = 5001;
    SystemOptionLog = 8001;
    VisitResultLog = 7040;
    QuickMatchResultLog = 7050;
    QuickMatchEndLog = 7060;
}

message RequestNotifyProtoBufLog {
    required LogType type = 1; 
    required bytes common = 2;
    required bytes data = 3;
}

However there is one bit of telemetry data that is -very- important, as it’s used to provide functionality to a lot of the game mechanics.

This telemetry data is sent using these messages:

message RequestUpdatePlayerStatus {
    required bytes status = 1;
}

message RequestUpdatePlayerStatusResponse {
    // Empty Response
}

This message is sent very frequently, dictated by values in the PlayerInfoUploadConfigPushMessage message we saw earlier.

So what exactly does the mysterious status field contain? Well it contains a serialized protobuf. This protobuf is massive and contains a dump of everything from what item the player is currently using, to if they are in another users world, even down to how many NPC’s they’ve killed.

How ever due to the frequency that this protobuf is sent, the game only sends it in its entirety once, all future messages contain only the fields that have changed which the server merges with its current value to get the latest status.

I’m not going to paste the entire protobuf here as its about 300 lines long, however if you can view it Here, the AllStatus protobuf is the one used. But just to give you a basic idea, here’s a snippet:

message PlayerStatus {

    optional uint32 regulation_version = 1;                
    optional uint32 unknown_2 = 2;                           // 2

    optional bool cross_region_matchmaking_disabled = 3;
    optional int32 soul_level = 4; 

    optional uint32 sinner_points = 5;
    optional uint32 unknown_6 = 6;                           
    optional uint32 is_invadable = 7;                        
    optional uint32 can_summon_for_way_of_blue = 8;     
    optional uint32 unknown_9 = 9;                           
    optional uint32 can_summon_for_watchdog_of_farron = 10;   
    optional uint32 can_summon_for_aldritch_faithful = 11;    
    optional uint32 can_summon_for_spear_of_church = 12;      
    optional uint32 unknown_13 = 13;                         
    optional uint32 unknown_14 = 14;                         
    optional WorldType world_type = 15;                      
    optional uint32 covenant = 16;                           

    repeated uint32 played_areas = 17;

    repeated uint32 unknown_18 = 18;                         
    optional uint32 embered = 19;                         
    optional uint32 souls = 20;                              
    optional uint32 soul_memory = 21;                        
    optional uint32 archetype = 22;                        

    optional int32 hp = 23;
    optional int32 max_hp = 24;
    optional int32 base_max_hp = 25;
    optional int32 fp = 26;
    optional int32 max_fp = 27;
    optional int32 base_max_fp = 28;
    optional int32 stamina = 29;
    optional int32 max_stamina = 30;
    optional int32 base_max_stamina = 31;

    optional uint32 unknown_32 = 32;                         
    optional uint32 unknown_33 = 33;                         
    optional NetMode net_mode = 34;                         
    optional uint32 dried_fingers_active = 35;              
    optional InvasionType invasion_type = 36;                       
    optional uint32 character_id = 37;                       

    optional string name = 38;
    optional bool is_male = 39;

    .... it goes on for many lines ....

};

You can see from some of the fields that this is how a lot of the game mechanic information is exchanged. For example field’s like can_summon_for_aldritch_faithful directly dictate if the player is using the Aldritch Faithful covenant can be summoned by other player’s games for covenants invasion.

Interesting as this is user controlled, a game can cut themselves fully off from invasions or other game-mechanics they don’t like simply by setting the relevant fields to false.

Also just because I find it interesting, the protobuf also contains the following field:

    repeated int32 anticheat_data = 62;

Which is hilariously obfuscated. It’s an array of seemingly random values that are shuffled around to look like it’s some kind of state being changed. How ever if the game thinks you’ve tampered with any executable code, it will silently slip in a value of 0x1770. When the server receives this value it will mark the players account as cheating and will ban them on the next ban-wave (which occur once a week).

Coming Up

At this point we know about all the messages required for the user to register a character and get into the game. What remains is to go over the game mechanics.

I’m going to split the mechanics into two final posts, one going over asynchronous ones (ghosts, bloodstains, messages) and one going over all the real-time ones (invasions, summoning, quick matches).

Continue to the next entry

Reverse Engineering Dark Souls 3 Networking (#4 - Reliable UDP)

2022-06-09T00:00:00+00:00

Recap

In the previous posts we’ve seen how the game connects to an initial introduction server, which then forwards game onto a second key-exchange/authentication server, before finally forwarding the game onto a third and final server.

This last server is going to be the most interesting, as it’s the main “game server” which handles everything needed to support the online game features in Dark Souls 3. We’re going to look at how this third server now. This is going to be a dense post, so prepare yourself!

Protocol Confusion

So lets dive in and see what we’re looking at here. Your first assumption may be to try treating this server like the others, and assuming it uses the same TCP-based protocol. However if we start listening to that TCP port the game was forwarded to by the last server, you will be disappointed to see that the game never attempts to connect on this port.

So what exactly is going on here? If we break out Wireshark again we can see what, and more importantly where, the client is sending its packets.

It appears the client has switched over from TCP to UDP for communicating with the game server. And even more problematic, if we try parsing the packets in the same way as those we received via TCP we will fail.

If we have a look at the first packets data we can see why:

The protocol has entirely changed!

Well back to square one, if take a capture of several packets we can start to breakdown the contents once again.

We can see that the first 8 bytes are always identical, followed by what we can assume is a ciphered payload.

So what is the first 8 bytes? Well it changes every time we go through the connection process, but remains the same for each connection. And if we examine the data sent by the authentication server in the previous post, we can find the same 8 bytes in the first field of Frpg2GameServerInfo struct.

What these bytes work as is essentially a token created by the previous server to say that we have authenticated ourselves correctly, and are allowed to access the game server.

If the server receives packets without an authentication token it recognizes, it will ignore the packet.

Now how about that ciphered data after the authentication token? Fortunately we have one giant hint about how to decrypt this - Remember the second key exchange we performed on the previous server? Well it turns out that was to generate the key that is used for all communications with this server. If we try to decrypt this packet using the same CWC cipher we used on the previous server, we will suddenly get something a bit more meaningful!

^{Parts redacted to obscure my steam id.}

Excellent! We have something we can work with here.

A Logical Jump

So I’m going to have to apologies a little bit here, and make a logical jump. Deciphering how these packets work is unfortunately a long, and fairly dull, exercise in reading through disassembly, which will fill up several blogs posts. So instead I’m going to explain directly how they work.

I leave it as an exercise for the reader if they wish to investigate further. A good starting point is reading through the code associated with the Nauru::Communication::UDPConnection class.

Reliable UDP

So the protocol for these packets is one that anyone who has done networking code in game development will be familiar with. It’s an implementation of reliable UDP.

A little background information here for those unfamiliar with network protocols - if you know what reliable UDP is, feel free to skip this section.

The two most commonly used protocols are known as TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Each have their positives and negatives.

TCP is stream-orientated protocol. By that we mean that at the application layer each side of the connection just seems a continual stream of bytes sent from the other side, there is no segmentation into “packets”. In additional to that, TCP is also reliable and ordered. Meaning that each byte of data sent will be reliably delivered to the other end of the connection, and will be received in the same order it is sent.

UDP is the polar opposite of TCP. UDP is stateless, meaning that no connection or stream exists concept on the application layer. Instead the application will just receive any packets (known as datagrams in UDP terminology) that are received by the host for the UDP port the application is listening on. All sends and receives occur as individual packets, these packets have a maximum size dictated by the minimum MTU (Maximum Transmission Unit) setting on the network devices between the sender and the receiver, typically around 1024 bytes, data sent beyond this size may be fragmented during transmission. Importantly UDP is unordered and unreliable - Meaning packets are not guaranteed to get to their destination, and if they do, they are not guaranteed to come in the same order they were sent.

^{Source unknown, this meme has been going around for years.}

You might ask why would a game server choose to use UDP rather than TCP? It seems that TCP would be the preferred choice right? Well that’s not always the case, especially in video games. TCP excels for things like sending a web-page to a web-browser, something where reliability and ordering is important. However with this functionality comes a lot of additional overhead to manage the stream, along with complex algorithms for flow and congestion control, which may result in high latency or sluggish transmissions.

Video games on the other hand, generally don’t need the guarantees that TCP provides. For example if a game server is sending the positions of other players/enemies/etc to a client every frame, with TCP if one of those updates was lost, the recipient’s game would not receive any data until retransmission occurs, which can take several hundred millisecond - dozens of frames. By the time the recipient actually receives that retransmission the data isn’t relevant anymore.

Using UDP in this situation allows us ignore the dropped update packet and just carry on when we get the next update. We might get some questionable position extrapolation, or rubber banding, but at least we can continue without waiting dozens of frames.

In additional, UDP has one very useful feature that TCP doesn’t. With UDP we can reliably implement NAT traversal by using a technique called Hole Punching. This allows us to make direct connections to different devices on different networks. Allowing users to host games without worrying about things like port-forwarding.

However you might guess that there are some things that games normally want to send with the reliability and ordering of TCP. The naïve approach to supporting this might be to use both TCP and UDP in tandem. But this adds a lot of complexity and we loose some of the benefits of using UDP.

Instead what we can do is implement a reliability layer on top of UDP, that behaves similarly to how TCP does, that we can selectively use for the packets we want to be reliable and ordered. This is precisely what Dark Souls 3 does.

Exactly why the game uses this protocol though, I’m a little unsure of. Nothing the game server does is latency sensitive, everything has to be both ordered and reliable, and none of the other benefits like nat traversal are helpful to it. TCP would have suited just fine for the usage. I’m guessing the reason is either something related to scalability (maximum tcp connections a server can handle?) or perhaps the protocol is just reuse of some existing code? Either way, this is what the game uses, so what we will have to replicate.

Packet Structure

So back to those packets! How exactly are they structured? Well like the TCP protocols they have a short header followed by an optional data payload.

There is one small quirk here. The first packet that’s sent by the client is always prefixed with a small struct containing two copies of the players steam id.

struct initial_packet_prefix
{
    char steam_id[17];
    char null = 0;
    char steam_id_copy[17];
};

struct packet_header
{
    uint16_t magic = 0x02F5;
    uint8_t  sequence[3];
    uint32_t type;
    uint8_t  congestion = 0xFF;
};

The magic field remains the same for all packets.
The congestion field changes depending on network state, and can be used to adjust the frequency of data sent - ds3os ignores it for simplicity.
The sequence field contains 2x 12-bit values (3 nibbles each). We call the first one the local ack and the second one the remote ack. There usage depends on the type of packet.
The type of packet can be any of the following values. There are other types that the game can process, but none of them are used in practice, so we only handle this subset. You can view the full set in the DS3OS codebase.

enum class packet_types
{
    SYN         = 0x02,
    DAT         = 0x04,
    HBT         = 0x05,
    FIN         = 0x06,
    RST         = 0x07,

    // These are combination types, they are the type above
    // bitwise OR'd with 0x30.
    ACK         = 0x31,
    SYN_ACK     = 0x32,
    DAT_ACK     = 0x34,
    FIN_ACK     = 0x36,
};

Establishing Connections

Each side of the connection maintains a sequence-number, this sequence number is sent in the sequence field of the header. When a packet is recieved an acknowledgement (ACK) packet is sent back to the sender containing the sequence number contained in the recieved packets header. If one side of the connection doesn’t receive an acknowledgement of a packet it sent, then after a certain amount of time it will attempt to resend it. After a certain amount of re-sends fail the connection is considered broken.

Each side of the connection also keeps track of the next sequence number it expects to receive from the other side, if it receives a packet with an older sequence number than expected it assumes its ACK of that sequence number got lost and re-sends it, if it gets a sequence number greater than what it expects then it assumes its missed a packet and waits for the older packet to be resent.

This allows us to maintain both a reliable stream of packets, as well as keeping them ordered.

However before any of this will work we need to synchronize sequence numbers so that both sides of the connection know what the other sides sequence number is.

This is done by a sequence of packets known as a handshake. If you’ve ever read about the TCP three way handshake, then this will look very familiar.

Sequence numbers traditionally start out as randomized, though its not strictly necessary, in this example the clients sequence numbers start at 1 and the servers at 1000.

The client first sends a SYN (Synchronize) packet to the server with their sequence number in it.
The server then sends back an SYN_ACK (Synchronize Acknowledge) packet with their sequence number in it and the sequence number the client sent.
The client then sends back an ACK (Acknowledge) packet with the SYN_ACK’s sequence number in it.

At this point both sides of the connection know what the others sequence number is and have acknowledge that they know it. At this point the connection can start exchanging data, each side will expect the next packet from the other side to always have a sequence number of sequence+1.

If communications fails at any point, due to issues such as dropped packets, a RST (Reset) packet will sent, triggering re-randomizing sequence numbers, and then the handshake will be re-started from the beginning.

Termination of connections behaves in almost the same way as establishing them, with a three-way-handshake. The only difference is FIN and FIN_ACK are used rather than SYN and SYN_ACK.

Data Exchange

Ok now we have a connection established!

So how do we actually exchange data? Well its yet another three way process.

First one end of the connection sends a DAT (data) type packet, with a payload containing the data we want to send.
The receiving end then sends a DAT_ACK (Data Acknowledge) packet back, with it’s remote sequence number set to the sequence number of the initial DAT packet. If this is a reply with additional data (eg. data requested by the DAT packet), then the payload contains that additional data.
The initial side sends a ACK (Acknowledge) packet with the remote sequence number of the DAT_ACK packet.

It’s very important that DAT_ACK packets are sent, even if no reply is required. Not doing so will cause the game to timeout and consider the connection broken.

As the game tends to send data as infrequently as it can, if there is a long period with no data exchanged each side will send a HBT (Heartbeat) type packet to let the other side know they are still there. If no data or heartbeat is seen for a while the connection is considered broken.

Packet Payloads

Ok, so we’re now able to send and receive data packets, all done, we can start looking at the what the game packets do right?

Unfortunately not …

Like the TCP protocol used in the previous servers the data we want is actually wrapped in two different protocol layers. So we need to know how to parse these before we get to the game-data we are actually interested in.

Fortunately these ones are quite straightforward, much simpler than the the reliable udp protocol!

Fragmentation

As I mentioned earlier, the maximum amount of data you can send in a UDP packet is limited to the MTU of all the network devices along the route between the sender and receiver. Typically the safest amount of data you can send in a UDP packet is about 1024 bytes.

What happens if we want to send more than that? If we just send a packet larger than that, it will be fragmented by one or more of the network devices along the route between the sender and receiver. And given any of those fragments may be any size, come in any order, and may even be lost, we have no way to reassemble these fragments when we receive them, even with our reliable udp implementation.

So what Dark Souls 3 does instead is to pre-fragment the data and sending it in multiple packets, such that no individual packet length is over the safe limit of 1024 bytes.

To allow us to reassemble the data a small header is included at the start of each fragment received.

struct fragment_header
{    
    uint16_t packet_counter;
    uint8_t  compress_flag;               
    uint8_t  unknown_1;
    uint8_t  unknown_2;               
    uint8_t  unknown_3;
    uint16_t total_payload_length;
    uint8_t  unknown_4;
    uint8_t  fragment_index;
    uint16_t fragment_length;
};

The packet_counter field increments for every un-fragmented block of data thats sent.
The fragment_index field increments for each fragment of data that makes up the full payload, the first fragment being 0, the next being 1, etc.
The fragment_length field contains how many bytes of data are included in this fragment.
The fragment_payload_length field contains how many bytes of data are included in the complete un-fragmented data.

To receive the data we just keep reading fragments (which will already be in order thanks to our reliable-udp implementation) and appending their data together until the sum is greater than total_payload_length.

To further squeeze as much data as they can into individual packets, if the compress_flag field is set then the completed un-fragmented data was encoded using DEFLATE Compression before being fragmented up and sent.

Game Messages

The last layer you might remember from the TCP protocol, its almost exactly the same. It’s a small wrapper that tells us what type of message is contained in the remaining data, which like the TCP protocol is encoded as protobuf!

To do so each block of data contains the following small header:

struct message_header
{    
    uint32_t header_size = 0x0C;
    uint32_t message_type;
    uint32_t message_index;
};

The header_size field is constant, and presumably is there for potential variable length headers, though they aren’t used by the game.
The message_index field is a constantly incrementing sequence number, which is used to identify individual messages and the replies to them.
The message_type field contains a unique identifier that matches one of the protobufs we can deserialize.

The game messages are quite easy to handle, we just read the message_type and deserialize the data with the appropriate protobuf. But how do we know what protobuf matches each value? Well surprisingly this is actually super easy.

If we break out Ghidra and try simply searching for the names of different protobufs (which we know already from the RTTI information), we will find a function like this for each of them. It is essentially registering the protobuf as a valid message, and the function that that is invoked, which I’ve called “RegisterMessageType”, contains the id of the message as its second parameter (in this case RequestCreateBloodMessageResponse has an id of 0x0397).

Dark Souls 3’s game server protocol is setup in a Request->Response architecture, the game asks for something and then the server responds to it. You can see this in the names of all the protobufs, which almost all come in pairs, eg. RequestCreateSign and RequestCreateSignResponse.

To know which message a response is for, every response message has a message_type of 0 and a message_index set to the same message_index of the original request message. A little book-keeping is necessary so we know what Response protobuf we need to decode based on the Request protobuf we originally sent.

The game server protocol also has a small handful of push messages that the server can send without a request from the client. These all have a message_type value of 0x0320. To identify the protobuf for these push messages, the type of the protobuf is stored in the first field of the protobuf - meaning you need to deserialize twice, once with a protobuf containing a single id field, and once with the actual full protobuf. For example this is the protobuf for one of the push messages:

message PushRequestNotifyRingBell {
    required PushMessageId push_message_id = 1;
    required uint32 player_id = 2;    
    required uint32 online_area_id = 3;    
    required bytes  data = 4;
}

To get the Id of the protobuf to use we would first deserialize it with this cutdown protobuf:

message PushRequestHeader {
    required PushMessageId push_message_id = 1;
}

Why exactly they choose to do it this way I have no idea, its obtuse and unnecessary seeing as they already had a message_type field. I’m guessing it might have just ended up cobbled together like that over time.

Coming Up

Phew, that was a long post. But at least we now know how the game communicates with the server. And we can decipher all the messages it sends. We’re now in a position to start looking at high level logic that contains the game features, which is what’s coming up in the next post!

Continue to the next entry

Reverse Engineering Dark Souls 3 Networking (#3 - Key Exchange)

2022-06-03T00:00:00+00:00

Recap

In the last post I described knowledge how the basic messaging protocol works, and we left off with the server redirecting the client to another server. In this post we will be looking at what function this second server performs.

From this point forward we’re going to be passing a lot of different message types around, so I’m not going to discuss how each of them were reverse-engineered in detail, as it’s the same process of logical deductions and investigation described in the previous post.

Firm Handshakes All Around

So lets dive in and have a look at this new server. Fortunately this server uses the same tcp protocol as the previous one, so we can already use our previous knowledge to decipher it.

As soon as the game connects it sends a message (with a type value of 6), containing a protobuf called RequestHandshake.

message RequestHandshake {
    required bytes unknown_1 = 1;
}

Once the client sends this to the server, something unusual happens. The server replies with a response message, with a 27 byte payload, which is both un-encrypted and isn’t parsable as a protobuf. As soon as the game receives this all messages that follow are not longer decryptable!

So what exactly is going on here? If we have a look at the unknown field in the RequestHandshake message as well as the response, we can get get an idea.

Looking at the header in more detail we can start to break down what it actually contains:

^Request

^Response

If we run the process multiple times we can also see that the values are never consistent, and appear totally random.

Got an inkling of whats going on here yet?

It’s a key-exchange! By the time we get into the game we will be sending a lot of messages often, and RSA just isn’t suitable for doing. It’s encryption and decryption costs are infeasible for realtime usage. So the server and game exchange key material from which to derive a symmetric key for a more lightweight encryption algorithm.

Normally what happens in this situation is both game and server send each other a few bytes of random data and combine them together in a deterministic way to come to a shared conclusion on the key they should use for future communications.

However Dark Souls 3 appears to be broken in this regard (a phrase you might want to get used to …). The key material the server sends back is entirely unused. The key used for all future communications is the raw 16 bytes that the game initially sends.

So what cipher does the game use for all future communications if not RSA? It uses a very obscure ones, that as far as I’m aware only has a single implementation public on the internet - in the original authors GitHub. The cipher is AES-CWC-128, as hinted to by the CWCObject we found when looking through the RTTI types in the previous post.

Also if you wanted to use the reference implementation, you might be disappointed! FromSoftware for whatever reason decided to flip the endian of some calculations in the middle of the implementation (at line 498 of cwc.c if your curious). Good job to the guys on the ?ServerName? discord who managed to figure out that nightmare.

Authentication Flow

So now that we have swapped encryption to a new cipher, what else does this server actually do?

Well this server can process and respond to the following 3 different types of messages. These messages are always sent in the same order from the game. Additional flows might exist in development scenarios.

Service Status

The next thing the game does is send a message (type 2) containing the following protobuf.

message GetServiceStatus {
    required int64 id = 1;
    required string steam_id = 2;
    optional string unknown_1 = 3;
    required int64 app_version = 4;
}

This essentially is asking the server if a given service is available to us with the version and steam-id we are using. The game currently only queries a service with an id of 2, which appears to just refer to the standard online game features.

The response sent to the client is almost identical to the request, with the exception of the steam-id being blank.

message GetServiceStatusResponse {
    optional int64 id = 1;
    optional string steam_id = 2;
    optional int64 unknown_1 = 3;
    optional int64 app_version = 4;
}

If the user is using an out of date version of the game, the server will send back an empty response with no fields set. If the game receives a response like this it will show a message telling the user to update their game.

Key Exchange Redux

Surprise! You thought we had already exchanged encryption keys earlier. Well guess what, we’re going to do it again!

This begins with a message (of type 1) with a payload containing 8 bytes, which are not parsable as a protobuf.

The response send is a message containing a payload of 16 bytes. Lets have a look at the request and response:

^Request

^Response

Looks like the server just tacks on 8 random bytes to the 8 the client send and then sends the 16 byte result back.

And guess what? This works correctly, the derived bytes are what is actually used as a key this time.

But what is this key even for? We shall find out soon!

Ticket Authentication

Now we’re getting to the meat of things. The next message that’s sent (of type 3) contains a variable length, non-protobuf payload. Lets have a look at it shall we?

^{Partially redacted to avoid any potential spoofing of my steam account.}

Looks like a lot of random data? Not quite.

If we look at the first 16 bytes we can see these are the key we generated in the previous step, oddly this is the actual key that ends up getting used in future - I’m not sure what the point of the key exchange was previously if the client can just generate its own key and send the key to the server here, a mystery.

The rest of the bytes are interesting though. They differ each run, and can differ in length -drastically- between different players. We can use a bit of logical deduction here to guess what this is - the game needs some way to verify that the user actually owns the game, and the game uses steam. Could this be a steam ticket? Its roughly the right size and shares the same characteristics?

Well we can easily verify this. Steam has a developer mode, one function of which is to write out all API calls and responses that a game performs. You can find lots of documentation about it Here.

Yup, that looks like it matches - the client requests an encrypted ticket just before it communicates with the server, and it looks to be the same length!

At this point, the server authenticates the ticket with the steamworks backend. If the ticket fails to validate the player is abruptly disconnected. If the ticket is validated the server sends a response with an non-protobuf 184 byte payload.

Game Server Info

And oh boy is this payload interesting. Its structured roughly like this:

struct Frpg2GameServerInfo
{
    uint64_t auth_token;
    char     game_server_ip[16];
    uint8_t  unknown_horror[112];    
    uint16_t game_port;
    uint8_t  padding[2];

    uint32_t unknown_1  = 0x00008000;
    uint32_t unknown_2  = 0x00008000;
    uint32_t unknown_3  = 0x0000A000;
    uint32_t unknown_4  = 0x0000A000;
    uint32_t unknown_5  = 0x00000080;
    uint32_t unknown_6  = 0x00008000;
    uint32_t unknown_7  = 0x0000A000;
    uint32_t unknown_8  = 0x000493E0;
    uint32_t unknown_9  = 0x000061A8;
    uint32_t unknown_10 = 0x0000000C;
    uint32_t unknown_11 = 0;    
};

Its main purpose is to provide the client with the ip address and port of the next server it needs to connect to. This server is the final and most important server - the game server which handles all our requests for in-game features, and the topic of the next blog entry.

In the retail environment there are actually two different servers you can be directed to here. If the server has flagged you in the past for cheating, which it does en-mass every week, you will be redirected to a “banned server”. Otherwise you will be redirected to the normal game server. It’s impossible to play with people on other servers, banned players will only be able to play with other banned players, and the same for unbanned players. Banned players are essentially quarantined while still allow them to play online.

This “banned server” is also where anyone playing mods online will end up, which is a massive shame. It means some of the massive overhaul mods like Cinders can only play online on servers filled with people cheating. This was one of the main reasons for writing DS3OS, it gives somewhere safe for people with modded games to play.

Before we start looking at the next server, there are some entries in this structure that are quite interesting.

auth_token its a randomly generated number we will be using on the game server to tell it we have been authenticated by this server and to let us connect. We will go more into detail about how this fits into things in the future.

unknown_1 through unknown_11 haven’t been investigated much yet. They must be set to the values shown above though or the game will crash. I speculate from the behavior I’ve seen that that these are potentially configuration values for memory allocation, they have very suspicious power-of-two-ey numbers which definitely makes me believe they were defined by a programmer.

unknown_horror however is where the real fun is. It’s uninitialized data, which appears to be leaking parts of the stack on the game server. Uh-oh. Given the security problems the Dark Soul’s games have recently been notorious for (Info here for those out of the loop), it really does feel like FromSoftware should probably hire some pen-testers and audit their network code.

But anyhow, we have our destination, so onwards to the game server!

Coming Up

This was a fairly short post as the “authentication” server doesn’t do a whole lot, but is an important piece of the network architecture. In the next blog post we are going to start looking into the game-server, and it’s going to get -chonky- as there are a lot of things to go over for it. But we’re almost to the point where we can start looking at game-visible mechanics!

Continue to the next entry

Reverse Engineering Dark Souls 3 Networking (#2 - Packets)

2022-06-02T00:00:00+00:00

Recap

In the previous part of this series I went over how we can make the game connect to our own server.

This part starts to look into the structure of the protocol the client uses to communicate with the server.

The Packet Structure

So lets dive right in and see what data the client sends to the server when it first connects, including the encrypted data.

Thats quite the block of seemingly unintelligible bytes.

However if you look careful at the first few bytes you will notice the data has fairly low entropy - lots of repeating zeros for example. Following this block the remainder of the bytes look to be exactly the opposite - very high entropy.

We can take a reasoned guess that the low-entry bytes at the start are a header of some description, describing the block of encrypted bytes that follow. You will see similarly structured data in a lot of protocols that use TCP, as they make it simpler to break up the stream of data into individually processed packets, this is typically known as message framing.

Looking at the header in more detail we can start to break down what it actually contains:

In total we have 26 bytes we need to decipher the format of.

The first 2 bytes are easy to figure out - to deliminate a stream of data into individual packets we need to know the amount of data to recieve before processing it. The first 2 bytes are 01 18 (decimal 280) which is exactly equal to the length of remaining data after it.

struct message_header
{
    uint16_t payload_size;
    uint8_t unknown[24];
};

We can guess, from the repeated runs of zeros, that the remainder of the header is likely made up of multiple big-endian multi-byte fields which contain small values. If we break the buffer up assuming the non-zero values are in the most-significant bytes, we can get a rough idea of the structure.

struct message_header
{
    uint16_t payload_size;
    uint16_t unknown_1;
    uint8_t unknown_2;
    uint8_t unknown_3;
    uint32_t unknown_4;
    uint32_t unknown_5;
    uint32_t unknown_6;
    uint32_t unknown_7;
    uint8_t unknown_8;
    uint8_t unknown_9;
    uint8_t unknown_10;
    uint8_t unknown_11;
};

We can use a simple trick to start breaking down these values. By trying to connect multiple times in a row, we can see what changes in the packet each time, this allows us to seperate out any dynamic data from static data.

We can see that the the first value and last value seem to increase each time we try to connect. These are likely sequence-numbers of some description, possibly for matching up request packets and responses.

If we do this enough times to overflow the last value we will also discover that it is stored in little-endian, the opposite of the other fields.

struct packet_header
{
    uint16_t payload_size;
    uint16_t sequence_number_1;
    uint8_t unknown_2;
    uint8_t unknown_3;
    uint32_t unknown_4;
    uint32_t unknown_5;
    uint32_t unknown_6;
    uint32_t unknown_7;
    uint32_t sequence_number_2_little_endian;
};

If we look at the values in each of these fields we will see 2 with the repeated value 01 0C (decimal 268), which is the number of bytes that follow the after these specific fields.

What we are looking at here is nested-protocols. We have a packet, who’s payload contains a message, whos payload contains the actual encrypted data. Both the message and the packet have a header, they are adjacent in memory causing us to currently assume they are a single header. If we break this into multiple structures and annotate the lengths we can start to make more sense of this.

struct packet_prefix
{
    uint16_t packet_size;
};

struct packet_header
{
    uint16_t sequence_number_1;
    uint8_t unknown_2;
    uint8_t unknown_3;
    uint32_t payload_length;
    uint32_t payload_length_2;
};

struct message_header
{
    uint32_t unknown_6;
    uint32_t unknown_7;
    uint32_t sequence_number_2_little_endian;
};

^{Trivia: I have no idea why the protocol duplicates the payload_length field, its a bit of an oddity. Perhaps a left over from previous iterations?}

Now that we have disambiguated the message header from the packet header, some of our values become easier to determine.

We can now determine that unknown_2 and unknown_3, which are always 0, are almost certainly compiler-added padding to ensure that payload_length has correct alignment.

We can also determine the 2 sequence numbers are part of different frames of data - one is for packets, one is for messages.

struct packet_prefix
{
    uint16_t packet_size;
};

struct packet_header
{
    uint16_t sequence;
    uint8_t padding[2];
    uint32_t payload_length;
    uint32_t payload_length_2;
};

struct message_header
{
    uint32_t unknown_6;
    uint32_t unknown_7;
    uint32_t sequence;
};

unknown_6 looks to always be 0C (decimal 12), which is the same size as message_header, and we can assume is likely just a prefix-size in case of variable-length headers.

unknown_7 is a little more tricky, but we can make some educated assumptions that allow us to fill it in. The game needs some way to known what type of message is contained in the payload, so it knows how it should parse it. We can further reinforce this assumption, by tracing through all the packets send during the games connection to the server, and seeing that this value is always sent in the same sequence.

struct packet_prefix
{
    uint16_t packet_size;
};

struct packet_header
{
    uint16_t sequence;
    uint8_t padding[2];
    uint32_t payload_length;
    uint32_t payload_length_2;
};

enum class message_type
{
    initial_message = 5,
};

struct message_header
{
    uint32_t header_size;
    message_type type;
    uint32_t sequence;
};

One thing remains to be deciphered before we known enough to send and recieve a stream of packets, and its a bit of an oddity.

If we look at replies recieved from the server, there are a few things we might notice.

The first and most obvious thing to notice is the header is longer.

Any responses to a clients request messages have 16 additional bytes added to the end of the message_header. The value of these 16 bytes is always static, and never changes. The values are 4 uint32_t’s with the second having a value of 1 and the rest a value of 0.

Along with that its also worth noting that replies always have a message type of 0, and a sequence number that matches the initial message that prompted the reply, which confirms our assumption earlier.

struct packet_prefix
{
    uint16_t packet_size;
};

struct packet_header
{
    uint16_t sequence;
    uint8_t padding[2];
    uint32_t payload_length;
    uint32_t payload_length_2;
};

enum class message_type
{
    reply = 0,
    initial_message = 5,
};

struct message_header
{
    uint32_t header_size;
    message_type type;
    uint32_t sequence;
};

struct message_response_header
{
    uint32_t unknown_1 = 0;
    uint32_t unknown_2 = 1;
    uint32_t unknown_3 = 0;
    uint32_t unknown_4 = 0;
};

I’ve never been able to determine the point of these values, they don’t do anything, and the game doesn’t appear to use them in any way. I’m guessing they are perhaps left overs from previous iterations of the protocol.

The Message Payload

At this point we have enough information to emulate the sending and receiving of messages from the game server. However we do not yet know how the payload of the message is structured.

The first step is to get it decrypted. With the keypair we made in the previous part of this guide, we can now decrypt it using the private key. Using OpenSSL we just need to make a call to RSA_private_encrypt.

The padding mode depends on which side of the connection we are on, the client encrypts using RSA_PKCS1_OAEP_PADDING, while the server encrypts using RSA_X931_PADDING, this can be confirmed by breakpointing the RSA encryption and decryption functions in a debugger.

As our encryption is asymmetric, you may be asking how the client decrypts messages send by the server if it only has a public key. To do this the game exploits an interesting quirk of RSA cryptography, its possible to encrypt with the private key and decrypt with the public key. This is exactly what happens when the server sends the client message. For anyone contemplating doing this though, don’t, it’s terrible for a number of reasons. You can read some of these reasons here, written by someone far more knowledgeable about cryptography than myself.

So anyway, once we’ve decrypted the first message payload, what exactly do we get?

^{Note: I’ve censored part of this to hide personal information.}

So what is this exactly? Well just looking at the text representation you can see at least one string of characters - the uint64 representation of my steam-id infact. But how exactly do we decipher this, there aren’t any obvious patterns we can abuse like the repeating zeros in the packet headers.

Well this one requires a bit more investigation of the exe in ghidra.

If we look around at the code the Nauru namespace references, you will see a lot of RTTI references to types such as “MessageLite”. A quick google search will show us that these types are part of Protocol Buffers (typically shortened to Protobuf), google’s structured data serialization format. And if we look even further we will a couple of namespaces (Frpg2RequestMessage and Frpg2PlayerData) that contain a whole lot of types with MessageLite related functions in their virtual function table.

Protobuf works by having its own compiler that generates compilable code for a specific language, this code is then capable of serializing protobuf data structures. These data structures are defined in a language-neutral .proto files that look something like this:

message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;
}

^{Note: For people unfamiliar with .proto syntax, the equals value is assigning each field an index used for matching up serialized values to the fields, its not setting a field’s value!}

The RTTI types we’ve found are for the classes that were generated by the protobuf compiler. One of which exists for each message that is sent across the connection!

Unfortunately the source .proto files are not shipped with the game. So now all we need to do is create our own .proto file that matches the data and we can deserialize and manipulate it easily!

Reverse-Engineering Protobufs

Unfortunately its not that easy :(

The data format on the wire is tightly packed, and has no references to the original field names only their numeric indices. So if we need to reverse-engineer the contents of the original .proto file (which is not packed with the game) so we can have protobuf generate valid serialization code for the data.

This was probably the most time-consuming part of making DS3OS. Especially as the game makes use of the “MessageLite” format of protobufs, which strips out a lot of the useful metadata from the executable and serialized data, that would make them easier to decipher.

There are two useful tools we can use to make this process easier.

If we log each protobuf received we can use the –decode option in Protobuf compiler (protoc). This will show us the field number, value and data type of each field in the provided protobuf. However while useful, this is very problematic when optional fields are defined, or for messages we cannot get captures of easily.

A much more robust way we can do this is to read the parsing code in Ghidra, and reconstruct the fields from there. Index 7 in the vtable of each type is the deserialization function.

Take for example the following Protobuf deserialization function (this is for the message called RequestQueryLoginServerInfo).

This might seem indecipherable, but if we know one single thing about the protobuf wire format (lots of info about the format here) it becomes much easier to understand.

Prefixed before each field in the protobuf wire format is a uint16_t whose first 3 bits are the format of the field, and the remaining bits are the fields index. This leads to a very common pattern in the disassembled code:

uVar8 = uVar4 >> 3;
if (uVar8 == 1) {
    if (((byte)uVar4 & 7) == 2) {

We can see uVar8 is shifting off the first 3 bits of uVar4. So we can assume here its trying to get the field index. We can also see further below that we are bitwise-and’ing uVar4 with 7, which in effect retrieves the field data type. You can rewrite the above code like this:

field_index = field_prefix >> 3;
if (field_index == 1) {
    field_data_type = ((byte)field_prefix & 7)
    if (field_data_type == 2) {

Because the protobuf code is generated, its consistent and follows the same pattern everywhere, checking for field index and then checking is the correct data type, before parsing the value. We can examine all the classes to build up a .protobuf file that matches the original one that we don’t have access to.

After this point its just a matter of figuring out what each of the fields actually does, which is just a matter of looking at which messages are sent in which situations and applying some deduction.

So assuming we have reverse engineered all the protobufs, what exactly is the initial packet thats sent on connection.

It turns out the protobuf that the received data matches up to is RequestQueryLoginServerInfo, which has the following protobuf representation:

message RequestQueryLoginServerInfo {
    required string steam_id = 1;
    optional string unknown_2 = 2;
    // app version without the period and -1. eg. app ver 1.13 = 112
    required uint64 app_version = 3;                
}

The server always responds to this with a RequestQueryLoginServerInfoResponse protobuf message:

message RequestQueryLoginServerInfoResponse {
    required int64 port = 1;
    required string server_ip = 2;
}

As you might have guessed from the names. The original server the client communicates with acts as an introduction server, taking some basic details and telling them which server they should communicate with next.

In general the retail server will always direct the user to the same server & port, I imagine this might direct users to different servers in pre-release/press/development scenarios.

Coming up

In the next post I’ll be going over what the next server in the chain is responsible for (Oh by the way, its a chain, we get forwarded to other exciting servers after the next one!).

Continue to the next entry

Reverse Engineering Dark Souls 3 Networking (#1 - Connection)

2022-05-29T00:00:00+00:00

The Backstory

FromSoftware’s SoulsBorne series are some of my most cherished games. I’ve got a lot of fond memories in these games, mainly participating in jolly cooperations with friends.

Being a programmer, I’ve also had somewhat more interest than is probably healthy in how they’ve but together these masterpieces. To that end I spend a lot of time browsing social media related to modding and data-mining these games.

It was around a year ago that I was reading the ?ServerName? discord, probably the largest modding community for these games. Some of the members were discussing the prospect of private servers for games so that modded games had somewhere to play that wasn’t the official banned-server, which by its nature was populated with all the worst kinds of cheaters.

This discussion peaked my interest as it just the kind of challenge I have the skill set to help with.

From what I saw several members had attempted to make private servers for the latest game, Dark Souls III, but hadn’t got much past just getting the game to try to establish connections to an third-party server, the information they had acquired gave me the starting point to eventually produce: Dark Souls 3 Open Server (GitHub).

This blog series is mostly a discussion about how DS3OS was produced, and contains a technical dive into how the games network architecture is setup. I may skip over some things here and there to avoid anyone having to read about hours of experimentation in a disassembler / debugger, so apologies for any logical jumps.

What does the server actually do?

So if we’re looking at how to emulate the retail game server in Dark Souls 3, you might be asking - what does that server actually do?

Well you might be forgiven for thinking about the server in terms of it being a dedicated server for the purpose of realtime multiplayer - as that is obviously the main apparent online feature in the game.

However all multiplayer traffic in FromSoftware’s games is actually sent entirely peer-to-peer. What the game server actually does is handle a variety of game services, most importantly;

Matchmaking players for coop, invasions and covenant auto-summons.
The funny messages players leave around the world.
Bloodstains left by players deaths.
Ghosts used to show players glimpses into other peoples games.
Leaderboards for various covenants.
Cheat detection and banning.
And various other miscellaneous services.

Establishing connections to a different server

Getting the game to connect to a different server is surprisingly more involved than you might expect.

The initial connection made is a TCP connection, specifically to fdp-steam-ope-login.fromsoftware-game.net, this can be seen by taking a Wireshark capture of the game booting up.

^{Note: 54.148.23.40 is the resolved ip of fdp-steam-ope-login.fromsoftware-game.net. Imagine a complete connection here, FromSoftware’s servers are down at the time of writing.}

My initial thoughts at this point would probably be to add a host file entry, or detour the dns resolution functions in the game to have that domain return the IP of my shiny new server. Then we could get down to figuring out the traffic protocol!

However if we look at the actual data being sent during this initial connection, you might notice a stumbling block:

That looks suspiciously like its encrypted or ciphered in some way! Not a problem you might say? Just find the encryption key?

Well if we load the game’s exe up in my favorite decompiler, Ghidra, we could have a look for clues! The game makes use of RTTI (Runtime Type Information), so there is a wealth of type names that can give us a general idea of how the game structures things.

Aha, that is promising, lots of class names that look very much like they handle network communications. And if we look even closer we can see two very interesting types - CWCObject and RSAObject, both of which contain names of encryption ciphers. In fact the Nauru namespace is actually where the game stores all the logic for handling connections to the game server.

To determine if these are used we can search in Ghidra for the places these types are referenced. Doing so will turn up a handful of functions that look like constructors.

If we run the game with a debugger attached, and place breakpoints in these functions, we can determine the only type used at the same time the initial connection takes place is RSAObject.

This is bad news for us RSA is a form of public-key cryptography, which means traffic encrypted with a recipients public-key can only be decrypted by their secret private-key. So while we can get the game to connect to our new server, we have no way to decrypt the data the game sends it, as the private key to decrypt it is safely hidden away out of our reach on FromSoftware’s servers.

So the question then becomes, can we trick the game into using a key we supply, that we have the matching private key for, as well as trick it into connecting to our new server?

So lets start with the easy steps first, and search the exe for reference to the server hostname or anything that look like public keys (which are normally stored in some very obvious, easily searchable, formats like PEM). If we find these, we should just be able to patch them.

Bad luck, none of our string search’s show anything useful, just some parts of the OpenSSL library.

Interestingly if we look at the previous entries in the Dark Souls series we can see the keys and hostname ARE hard-coded in the exe in a visible format.

So unless Dark Souls 3 has fundamentally changed how it handles online connections, which seems unlikely as most of the RTTI in the area matches up, then the key is probably obfuscated or stored in a different location.

We know that the key has to be available in memory at the point its passed to the OpenSSL library to do the packet encryption, so what we can do is find the relevant openssl functions, put breakpoints in and trace backwards up the callstack to where the key comes from? Fortunately openssl has a lot of RTTI information and it’s functions tend to compile to the same machine code, so its easy to pattern match from known compiled code and find the functions we want.

Doing so (and spending several hours staring at a debugger) will eventually lead us to this function, which is what produces the public key (and hostname!).

You can ignore the disassembly for this one, Ghidra does a poor job of it generating it in this case.

So what is this function? It takes in a block of data and 4 ints, then does ~something~ to it and spits out a block of data with our encryption key and hostname in it?

Well it turns out its actually an implementation of the Tiny Encryption Algorithm. FromSoftware is being extra sneaky by encrypting the encryption keys. The 4 ints are the TEA key and the block of data is what contains our public key and hostname.

The data being decrypted is static and stored at offset 0x144F4A5B1 (on the current patch at time of writing). Its hidden interleaved in a block of unrelated code (very sneaky!).

Its encrypted with the following static key:

0x4B694CD6, 0x96ADA235, 0xEC91D9D4, 0x23F562E5

So now the offset is known, connecting to a different game server is as simple as writing our own data blob, encrypting it with the known key, then launching the game and patching the offset it with a simple call to WriteProcessMemory.

The format of the data blob is also nice and straightforward, so its easy for us to build:

struct server_info_blob
{
    uint8_t public_key[0x1B0]; // UTF-8 PEM encoded public key.
    uint8_t hostname[0x58];    // UTF-16 encoded hostname of server. 
};

Coming up

In the next post I’ll be discussing how the initial connection protocol was reverse engineered.

Continue to the next entry

Tim Leonard's Website

Reverse Engineering Dark Souls 3 Networking (#7 - Realtime Mechanics)

Recap

Summoning

Invasions

Remote Code Execution, Oh No!

Covenant Visits

Undead Matches

Final Words

Reverse Engineering Dark Souls 3 Networking (#6 - Async Mechanics)

Recap

Blood Messages

Ritual Marks

Blood Stains

Ghosts

The Great Bell

Leaderboards

Coming Up

Reverse Engineering Dark Souls 3 Networking (#5 - Character Management)

Recap

Login Awaits

Announcements

Character Registration

Player Telemetry

Coming Up

Reverse Engineering Dark Souls 3 Networking (#4 - Reliable UDP)

Recap

Protocol Confusion

A Logical Jump

Reliable UDP

Packet Structure

Establishing Connections

Data Exchange

Packet Payloads

Fragmentation

Game Messages

Coming Up

Reverse Engineering Dark Souls 3 Networking (#3 - Key Exchange)

Recap

Firm Handshakes All Around

Authentication Flow

Service Status

Key Exchange Redux

Ticket Authentication

Game Server Info

Coming Up

Reverse Engineering Dark Souls 3 Networking (#2 - Packets)

Recap

The Packet Structure

The Message Payload

Reverse-Engineering Protobufs

The Login Flow

Coming up

Reverse Engineering Dark Souls 3 Networking (#1 - Connection)

The Backstory

What does the server actually do?

Establishing connections to a different server

Coming up