Dreamarena Authentication

Dreamarena was an online service used by PAL Dreamcast games. One key element of Dreamarena was its authentication system which some games (Quake 3, Toy Racer) used to get online when using dial-up internet.

Authentication The Dreamarena authentication protocol was added fairly late on in the Dreamcast life cycle, and the library in the SDK which provided the functionality (authent.lib) only appears in the final KATANA SDK revision. A server emulator was unfortunately not available in any releases of the SDK leaked online. However, patching binaries to overcome Dreamarena is possible.

Protocol In order to understand how the protocol works, it was necessary to take a look at the sh4 assembly code. Here is a brief breakdown over how the server and client communicates. This will show from connect to authentication successful.

Server (First packet to client after TCP handshake):

<!KADBICHBIOPETERPAN=><ONLINEGAME> <!KADBICHBIOPETERPAN=> Client (Sends back a default console id and the real console id):

<!KADBICHBIOPETERPAN=><ONLINESTRT> <!KADBICHBIOPETERPAN=>0000000001 <!KADBICHBIOPETERPAN=>REAL_CONSOLE_ID <!KADBICHBIOPETERPAN=> Server: Should use the console id to lookup the user identifiers (3 digits) and the usernames associated with the console. For example:

console id user id username 0000000001 111 foo 0000000001 222 bar

Then if the server gets the <ONLINESTRT> 0000000001 it should return 111 foo and 222 bar. Note: Because we don't have this kind of data, which is taken from dream-key registration, just send back empty user list. <!KADBICHBIOPETERPAN=><USERLISTSP> <!KADBICHBIOPETERPAN=> Client: Will response with it's username, password and name of the game. Because we send a empty userlist, the user can choose between 0000000001 and REAL_CONSOLE_ID. The USERNAME will be the picked console id in the response packet.

<!KADBICHBIOPETERPAN=><USERNAMESL> <!KADBICHBIOPETERPAN=>USERNAME <!KADBICHBIOPETERPAN=>ENTERED_PASSWORD <!KADBICHBIOPETERPAN=>NAME_OF_GAME <!KADBICHBIOPETERPAN=> Server: The below response is bascially saying You've not registered a gamer name with us before. Please select a name you would like to use whilst playing.

<!KADBICHBIOPETERPAN=><GAMENAMNON> <!KADBICHBIOPETERPAN=>

Otherwise use the below response to set the game name, this was taken from the console id -> gamer name mapping back in the days. If the REGISTERED_GAME_NAME is not accepted by the server, it should send suggested gamer name (not implemented). <!KADBICHBIOPETERPAN=><GAMENAMREG>REGISTERED_GAME_NAME <!KADBICHBIOPETERPAN=> Client (Response with the entered game name):

<!KADBICHBIOPETERPAN=><GAMENAMESL> <!KADBICHBIOPETERPAN=>ENTERED_GAME_NAME <!KADBICHBIOPETERPAN=> Server:

<!KADBICHBIOPETERPAN=><OKSERVAUTH> <!KADBICHBIOPETERPAN=> Client:

<!KADBICHBIOPETERPAN=><OKAUTHORIS> <!KADBICHBIOPETERPAN=> Server (Send registration data):

<!KADBICHBIOPETERPAN=><USERINFOPK> <!KADBICHBIOPETERPAN=>001<!KADBICHBIOPETERPAN=> <!KADBICHBIOPETERPAN=>foo<!KADBICHBIOPETERPAN=> <!KADBICHBIOPETERPAN=>uk<!KADBICHBIOPETERPAN=> <!KADBICHBIOPETERPAN=>uk<!KADBICHBIOPETERPAN=> <!KADBICHBIOPETERPAN=>18<!KADBICHBIOPETERPAN=> <!KADBICHBIOPETERPAN=>foo_chat_name<!KADBICHBIOPETERPAN=> <!KADBICHBIOPETERPAN=>foo_gamer_name<!KADBICHBIOPETERPAN=> <!KADBICHBIOPETERPAN=>foo@bar.com<!KADBICHBIOPETERPAN=> The data format of each of these parameters is:

   char        shortname[16];
   char        userid[10];
   char        preferredlanguage[3];
   char        countryid[2];
   char        age[3];
   char        chatname[20];
   char        gamername[20];
   char        emailaddress[65];

Client (Sends the service type the games operates over: gmsv,lobb,chat,gmsp):

<!KADBICHBIOPETERPAN=><SERVICECOD> <!KADBICHBIOPETERPAN=>SERVICE_TYPE<!KADBICHBIOPETERPAN=> <!KADBICHBIOPETERPAN=> Server (The amount of instances of the requested service type, that is if you have two lobbies then the value should be 0002):

<!KADBICHBIOPETERPAN=><SERVICEDET> <!KADBICHBIOPETERPAN=>0001<!KADBICHBIOPETERPAN=> Client (Asks for the first service, will send 0001 x (amount of service instances sent above) ):

<!KADBICHBIOPETERPAN=><SERVICELST> <!KADBICHBIOPETERPAN=>0001<!KADBICHBIOPETERPAN=> Server (Sends the connection data for the service type):

<!KADBICHBIOPETERPAN=><SERVICESAV> <!KADBICHBIOPETERPAN=><SERVICESTR>0001 <!KADBICHBIOPETERPAN=>SERVICE_TYPE <!KADBICHBIOPETERPAN=>Service description <!KADBICHBIOPETERPAN=>IP <!KADBICHBIOPETERPAN=>PORT <!KADBICHBIOPETERPAN=><SERVICEEND><!KADBICHBIOPETERPAN=> Client (Done):

<!KADBICHBIOPETERPAN=><AUTHSUCCES><!KADBICHBIOPETERPAN=> That was it, a proof-of-concept has been done with Q3 and Toyracer PAL and both works fine after the authentication.

Notes: 1. The above auth. conversation is the fastest way of getting a AUTHSUCCESS, there is more in the protocol regarding fetching registration data and mapping, but for now those are not necessary to get the games to work. 2. No newline in the packages from the server.

A production-ready server is being worked on.

Games Known to use Authentication Toy Racer Quake 3 (PAL)