Re: [SBOL]Server development
I've been working on this and will focus mainly on the server side for the moment. But will post up my findings here in case they are of any interest to anyone.
Servers
Patch:
This appears to be quite simple. Looks to be powered by MPS. But I was able to work out simple packet headers at least to get failure responses from the client. Also found the packet to sent the client to inform that all is up to date.
Packets:
Code:
Structure: SS SS TT TT DD DD ..
S = Packet size minus 2 in big endian
T = Packet type in big endian
D = Packet data
Client -> Server : Initialize connection with server
00 02 68 10
Server -> Client : Inform client of update error
00 02 68 12
Server -> Client : Unknown packet but client reports unknown short
00 02 68 XX - any unhandled type for example 68 13
Client -> Server : Upon being sent an unhandled packet the client responds with this
00 06 68 20 06 05 23 40
Server -> Client : Client is up to date.
00 02 68 22
Server -> Client : Update info appears to be update data but structure is currently unknown
00 02 68 31 ... Unknown structure
Server -> Client : Client produces an error "Unknown 32 bit value"
00 02 68 32
Server -> Client : Client produces an error "Unknown 16 bit value"
00 02 68 33
Client -> Server : Client closed connection
00 00
I didn't bother looking further into the launcher and patch. Purely because the game can be launched without the launcher and I'll probably design my own launcher and patch server/code, But the above may be of interest to others.
Login server
Code:
Structure: SS SS TT TT ST ST DD DD ..
S = Packet size minus 2 in big endian
T = Packet type in big endian
ST = Packet sub type? in big endian
D = Packet data
The client appears to use the packet type and subtype to look up against a function table. But some sort of decoding is done to do this. however if the Subtype is 0 the packet is processed differently.
Client -> Server : Initialize connection and send username null terminated 15 characters max (password appears to be sent later. No encryption appears to be taking place at the moment)
00 16 01 00 53 42 6F 00 UU UU UU UU UU UU UU UU ....SBo.USERNAME
UU UU UU UU UU UU UU 00
Client -> Server : Send password null terminated 15 characters max (This appears to be an abandoned packet and replaced with the encrypted method using packet 0x0102)
00 16 01 00 53 42 6F 01 PP PP PP PP PP PP PP PP ....SBo.PASSWORD
PP PP PP PP PP PP PP 00
Server -> Client : Authentication process
Packet 0x180: Start authentication
00 04 01 00 01 80 : Client calls AuthDataCrypt function in csp_crypt.dll. client then responds with encrypted password
Client -> Server
Example response (password starts at offset 0x04 and is encrypted with "authgenki" using the AuthDataCrypt function in the DLL, decrypting can be done by passing the buffer to AuthDataDecrypt using "authgenki"):
00 22 01 02 4D 6D 69 34 2D 56 64 48 4D 64 56 41 ."..Mmi4-VdHMdVA
49 74 69 33 00 00 00 00 00 00 00 00 00 00 00 00 Iti3............
00 00 00 00 ....
Packet 0x181: Connection Failed (ie invalid username/password. Server administratively down).
SS SS 01 00 01 81 NN : NN = subcommand. All except 0x02 jump to the same function. The below packet causes the client to disconnect with a dialog box displaying the text from the packet at offset 0x07 (ASCII)
SS SS 01 00 01 81 02 [STRING]
Any other value at offset 0x06 causes the client to reconnect to another server that is specified in server.ini. I suspect its used when servers are administratively down it allows the client to connect to another server).
Packet 0x182: Login success send account details
00 90 01 00 01 82 XX : I'm currently unsure of the complete structure but any packet smaller than 146 bytes crashes the client. Currently just sending 0'd data. The client then fades to black and send 2 packets:Client -> Server : After login (WIP)
00 02 00 0A
Client -> Server : Sent after the 0x000A Packet (WIP)
00 02 0E 02
Client -> Server : Ping occurs every 10 - 15 seconds (client is unresponsive to pings sent from the server. Actually if the packet isn't at least 6 bytes it'll crash so appears that the packet type and sub type are required for all packets sent from the server)
00 02 00 02
Client
Models
There has been some success I've seen of people use models from this game so suspect its similar to other TXR games? The file have a mmdl extension. 3d modelling isn't my strong point. I've been able to extract models from Dreamcast TXR's in the past but those were NJ files which have their formats documented and have enough tools to open them. This files have "LDMM" in the file header. I've not found any documentation on these. But I can clearly see float values in the files so don't appear to be compressed in anyway which makes things easier.
textures
Textures have a MIA file extension. There doesn't appear to be any header information to dictate their format. but again doesn't appear to be compressed or protected.
sound effects
Sound affects have a DLS file extension. The file header has RIFF. DLS widely documented format with editors publicly available. I've been able to open these and play the samples from them. The files contain sound effects of cars at certain points at RPM. They sound nasty so may be able to replace these at some point.
BGM
Music files are WAV's. I don't really need to say much more about that. I could edit the client to play a better format such as OGG though at some point. Each file has a corresponding SGT file (DirectMusic Segment) which like the sound effects is a RIFF file that contains details about the music file. May even be able to use the current system to play other formats anyway...
Interface
The interface uses 3 files. ASF.SSS, KFD.SSS and KFD2.SSS. The ASF.SSS file has a BMP header and is essentially 5 BMP's concatenated. These BMP's are just the font images used by the text blitter in the game. The KFD.SSS appears to be the Main menu interface including the company logos that appear as you launch the game. There are mentions to FSCommands in this file so suspect it uses ActionScript and may actually be some sort of flash/shockwave app. The KFD2.SSS appears to be the interface used while in game as there are mentions of Time and max speed. Again this has FSCommands so may be actionscript.
Game Client
The game client I'm working with is from what I can tell the latest (2.00.03) If anyone wants the client I can upload it somewhere (but its easy enough to get just use archive.org to view an old page of
http://sb-online.genki.co.jp/). It only supports 640x480 resolutions and by default runs in full screen. It also has code that prevents running more than one instance of the client.
Resolution is hard coded into the client there are no references to other resolutions. However it is easily edited so I could integrate multi resolution and aspect ratio support. I've found a majority of these but would need to edit the interface SSS files as these do not scale when I tested 1280x720. This also requires repositioning interface items elsewhere there the SSS files aren't used. I've done this in other games and in my experience can get into the hundreds/thousands to values to update.
Switches
- -w : Windowed mode
- -port : server port number (only used if server.ini is missing)
- -ip : server IP address (only used if server.ini is missing)
- -skipwarning : Skips trademarks and driving warning straight to login screen
- -course : Not 100% sure but probably sets the course to goto after logging in
- -enter : Not 100% sure but probably an auto login switch.
Removing the code that prevents multi clienting was easy.
The client and update program use server.ini and update.ini to specify server addresses and ports. So its easy to redirect to another server. within the server.ini. I'm unable to see any difference that the option "side" has. But "type" appears to disable the server if set to anything other than 0.
Although at the moment I've not seen any packets being encrypted it is common for the authentication packets to be unencrypted as they may contain generated client keys that the client uses to send further packets encrypted. There is a DLL that comes with the client called csp_crypt.dll. Disassembling this I can see that there are 6 functions: csp_encrypt, csp_decrypt, AuthDataCrypt, AuthDataDecrypt, AuthDataCryptDecrypt and AuthDataDestroy. The client only seems to call the Auth functions so the others are likely called within the auth functions. However being a DLL it makes things simple. I've written a DLL that doesn't encrypt any data this should disable any encryption for the moment. But as I said the client isn't calling any of these functions as yet so suspect its once the user is logged in. I also plan to place any inline patches that are made to the client such as translations, resolution support and my own encryption maybe.
The game is mostly in japanese. It uses a single byte UTP-8. So easily translated. I've translated the mainmenu and options for the moment (as thats all I can get too at the moment). But plan on getting it fully translated.
Thanks.