Open Client Project

[kion]

Now that we can export pretty much all of the assets from the game, and a lot of the asset documentation is complete. The next thing I want to get into is an Open Source PSO client. Originally I was tempted to export assets from PSU or PS-Zero, but I think that swapping assets out and customizing can come later.

For the Open Client project, the concept is exactly as the name implies, which is to create an open source client that can connect to a PSO server. To start off with I'm going to try testing with Teth to try and re-create the packets to connect to a local server, and then as the functionality gets more complete for that, we can look into the option later of breaking the server off into it's own thing, if that would allow for easier maintenance or for the server to be more authoritative. But that decision doesn't need to be made anytime soon as we get started with the auth and path server.

For the client, the tool i'm most familiar with is html/css/javascript/threejs. So I'm not sure if that would work very well for the final client, but I definitely think that there are some tools that could be used to sketch out functionality. Like being able to open a web browser to feed your mag, or shitpost in the lobby, or at least be able to walk around pioneer 2. I'm not sure how much of the actual gameplay will be viable that way, as it will probably depend on how much the assets can be optimized.

For the actual gameplay, the program that I'm tempted to use is Godot. I understand that Unity is probably the most common standard and has the most people using it. And I'm really not trying to talk anyone out of using Unity. If we have an open client project, then the program used to program the client might not matter all too much. Meaning that if we have an Open Client with specifications on how to interact with the server, then it shouldn't really matter too much. My main reason for Godot is that since it's completely open, it allows for binaries to run on the Raspberry Pi, which I think would be pretty awesome, and I would prefer to use something FOSS-y.

So right now I'm getting a test server set up. And I'll probably start posting notes about how to connect to the server, and how to set up a test server and things like that.

 

[kion]

I think I got a local server set up, I can write some notes on how I got it working. I would like to avoid using my local computer, as I'm kind of too lazy to start the server every time I turn on the computer, I decided to go with a Raspberry Pi.

The Raspberry Pi is just a Raspberry Pi 3, generally any variation should theoretically work. And I'm using Raspbian Lite. I used the teth server from here: https://gitlab.com/theodis3/tethealla. And it's missing a readme. First to be able to get the server to compile I used:

Cloning and Compiling

$ sudo apt-get install make git clang libpcap-dev libssl-dev libmariadb-dev-compat

To install the dependencies and then from the home directory, i went ahead and cloned the repository.

$ cd
$ git clone https://gitlab.com/theodis3/tethealla.git
$ cd tethealla
$ make

And then all of the various binaries will be in the bin folder. From here we need to set up the SQL server.

MySQL (MariaDB) Server

From here we need to set up the MySQL server in order for the login and ship servers to connect to. On the Raspberry Pi, MySQL has been replaced by MariaDB the open source drop in replacement.

$ sudo apt-get install mariadb-server

And then we need to set up the user and database

$ sudo mysql -u root
> CREATE DATABASE `pso_server`;
> CREATE USER `pso_user`@`localhost` IDENTIFIED BY `raspberry`;
> GRANT ALL PRIVILEGES ON pso_server.* TO `pso_user`@`localhost`;
> FLUSH PRIVILEGES
> EXIT

And then we need to create the tables

$ cd /tmp
$ wget https://pastebin.com/raw/nxJnH9Wq -O pso_server.sql
$ mysql -u pso_user -p pso_server < pso_server.sql
Enter password: [raspberry]

And this will set up the tables for the mysql server. Next we will need to set up the login, patch, and ship servers. Which I'm kind of tempted to skip over at the moment. After a decent amount of time I was able to get these working, mostly by throwing all of the files from Soda's Setup Instructions into the bin folder.

I'm not sure if I want to take the time to run the setup again. It might be a good idea to go ahead and create a repository with the files ready to go. Two issues that I ran into were programs not being able to read strings from the config files correctly, so I went in and set static values to make up for that. And in a few places I have to replace back-slashes with forward slashes.

After that I was able to get the servers running, and simply started a screen process and left the executable running. Maybe there are some nerd points to be gained from setting up a systemctl start up script, but the goal here isn't to create a server to play on, but to test on. So right now the solution is "good enough". Next step is we need to patch the client to connect to our local server.

 

[kion]

Next step will be testing with the client. Originally I was thinking that I might try to be lazy to try and use the game client with the normal teth, and then just send packets to the test server. But it's probably a better idea to have the game client to connect to the test server, and that should make it easier to intercept and test the packets.

Which means we need to patch the game client to connect to our test server. We open up the psobb.exe file in Hxd hex editor, and search for the text 'psobb'. And that should bring us to where the ip address is set in the client. Soly on discord informed me thatthe first two ip addresses are the login server, and the four ip addresses after that are for the ship server. So basically I just need to replace these with 192.168.4.16, which is where the Raspberry Pi is on the network. And that way we can test to make sure the server works at all.

 

[plamp]

Hi I saw this post and thought to make a few suggestions as this is also something I've thought about in the past.

If you really want to build an open source version of the client your best bet might actually be to use something like IDA or GHIDRA to reverse engineer the games code into a programming language of your choice. Unfortunately it's not an easy task unless there happened to be a symbol table for one of the clients floating around, but I'm doubtful of that. I've done a bit of work on reverse engineering parts of other games clients using a disassembler and real time debugger before, it takes a lot of time and know-how but it's possible.

If not fully reversing it through use of a disassembler and rtd, it'll at least help gain a better understanding of parts of the client.

 

[Soly]

Soly on discord informed me thatthe first two ip addresses are the login server, and the four ip addresses after that are for the ship server

Just want to point out, what I said was first 2 are patch, the other 4 are login. (and this is wrong, it is 2 login and 4 patch)

There are no "ship ip addresses" in the client, those are sent by the server when you choose a ship in the ship menu

 

[kion]

For the address on the client, I ended up overwriting the DNS for the address defined in the client. I tried hex editing the text to 192.168.4.16, first by just adding a null byte in between each string, and then by replacing the start position of each prior string and adding null bytes in between. But both of those approaches caused the client to crash, so I ended up going with the DNS option.

For connection it looks like the login server was able to connect, but then the patch server through an error. So it's probably some server-client miss match issue. At least I managed to catch a few packets, so I can start looking into the hand-shake process before getting into the ship select.

 

[Soly]

You can't add null bytes in-between, it's an IP address string

 

[kion]

You can't add null bytes in-between, it's an IP address string

As in adding a null byte inbetween the strings.
192.168.4.16\0192.168.4.16\0 for a single null byte in between the ip strings
or 192.168.4.16\0\0\0\0\0\0\0\0\0192.168.4.16\0\0\0\0\0\0\0\0\0\0 adding padding to try and match the offsets of the original strings.

It might be easier using the client already patched to 127.0.0.1 as it would take out some of the guess work for editing. Or I could give up on the Raspberry Pi thing and use the Windows server. So there are a few options open for improving my test environment. For right now I'm going to start with the packets for the auth to see if i can get pass the blowfish boss.

 

[Soly]

My bad, I actually read null bytes in between parts of a single string.

As you said, you have to match the start of each string, but looking at it as "adding bytes to pad and match the offsets" sounds more complicated than just replacing each string (as a different "entity").

So I'd say to look at it as: replace 6 different strings, making sure you have at least 1 null byte at the end of each string.

 

[kion]

A few notes. I managed to hex edit the IP address. Downloading and editing the pre-patched 127.0.0.1 version ended up being the easiest option as it makes it easier to see what needs to be edited.


Which means we can connect, but then we run into this issue, which probably means that our server isn't set up correctly.



I was thinking that even if I can't connect to the server and play, that i might look into the packets to see how far it went, but now i'm thinking that it might be a better idea to go ahead and use the server Soda provided on Windows. I have a Latte Panda sitting around, so I think that might be the easier option.

Edit:

Update, I was able to login and start playing with Soda's sever. So I think i'll set up my Latte Panda (that's been collecting dust in a drawer since i bought it), set up to start acting as a home server to make testing easier.