Daytona USA Progress

[ioncannon]

Alright, read more about how SSL works and hit an issue I didn't realize: While 99% of the time RSA uses the private key for decryption and public key for encryption (as used when verifying the pinned cert); it seems when a certificate signature is being verified; the paradigm flips: The private key is used to encrypt the hash and the public key decrypts it.

The program is using the public key in the pinned cert to decrypt the encrypted data we send (containing the hash of the cert). Obviously this prints out nonsense; and fails to decrypt... failing the verification process. Which, yeah makes sense, VeriSign has that private key and stops people from spoofing the cert.

I still wonder how the guy who built the DNAS servers got around this issue. It seems he has a VeriSign cert issuing his own custom one. Dropped a message to him, hoping he can give some insight on how it can be done. I have looked up other projects that clone a CA and somehow use that to sign the lower cert.

Hm wait, I could try copying encrypted data from the pinned cert and see if that passes. The hashes will be different though but let's see /shrug.

Edit: Heh, was able to copy the signature from the VeriSign cert and it actually decrypted (since it was encrypted with the correct public key). Obviously the next call is to check if the hashes are equal, which they are not and it returns -1 and fails the connection. Least I confirmed what that last function is doing.

Edit2: I know it doesn't solve the issue of getting GD-ROMs working again; but I patched out the strcmp result comparison to accept the -1 result. The rest of the SSL handshake and send/receive funcs went off with out a hitch and I am seeing this on my apache server:

Code: Select all

[12/Jan/2023:01:43:05 +0000] "POST /cgi-bin/auth.cgi HTTP/1.0" 404 214 "-" "Mozilla/3.0 (DreamPas
sport/2.0; SEGA/Auth)"

Meaning Apache was able to decrypt the SSL packet on it's end and grab the HTTP request. That's good, it means all we have to worry about is crafting a cert that can fool it. Hope the DNAS server guy can help. It does simplify patching to a single byte though; brt -> brf (branch true to branch false).

In the mean time I'll play with the POST data and confirm if my research on the responses all work.

[colgate]

Wow this is great progress!

[ioncannon]

Incoming POST data for dricas looks like:

Code: Select all

commodity_id=S00001S0000211190101&user_id=flycast1&login_password=password

Note: If a game's commodity_id is empty/null, the dricas auth system is skipped. Daytona USA does this. Username and Password is stored in flash memory and can be edited with a DreamPassport or the like disc under connection settings. I assume Phantasy Star auto-created an account for you? Or was there an area you entered your account info in? Response is just text that returns 3 possible values:

Code: Select all

Reject_cause:<Number> Limit_date:<string/bytes?> Illegal_user:<Number>

For a good authentication, pretty much you can return an empty body but

Code: Select all

Reject_cause:0 Illegal_user:0

will also work (does the same thing). Still figuring out what the delimiter is but I think it uses a firstIndexOf type function anyways so doesn't matter.

Here are the possible values:

Code: Select all

Reject Causes

0 - Auth OK
1 - Bad Password
2 - Unregistered User
3 - Locked Out (You entered a wrong pwd too many times)
4 - Temp Password Expired (Error msg talks about account creation. Probably you got a temp password when a Dricas account was made)
5 - Unauthorized User (Translates as "We are currently discontinuing customer use". Either banned or the game is deactivated?)
6 - Paused (Similar msg as above)
7 - Expired (Your license has expired, please buy a new one. Prob for monthly paid games.)
8 - Unpurchased Rights (License has not been purchased. Go buy one.)
9 - Under Maintenance

16 - Bad Protocol
17 - DB Failure
18 - Pref Error

Illegal User Types (Only used when reject cause == 0)

0 - Auth OK
1 - Attention User
2 - Warning User 
3 - Unauthorized User
else - Other Unknown Reasons

[mstar]

Hey @ioncannon - hows the reversing coming along?

[ioncannon]

Hey @ioncannon - hows the reversing coming along?

Not much further as trying to figure out the flow of the program w.o a debugger is frustrating. But you just made me think of something.... instead of trying to fix Flycast, why not patch Daytona to use a "free" port that Flycast understands? Will give it a try and see if I can debug in that case.

In the mean time I was actually reverse engineering the Onsen games. I got the whole protocol figured out (including the encryption and checksum), and got far enough into the login process that it connects into a "game" server. However a lot of the data is unknown and it never actually leaves the loading screen.

Code: Select all

If type & 0x1F != 0, encrypt it. Packet looks like:

[headerSize (always 0xC)][type][payloadSize][ip][crc32][data]

In the data it usually has a header like this but the counts can be used in other ways: 

[opcode][responseCode][count1][count2][maxCount]

My parse code:

Code: Select all

        private int ParsePacket(byte[] data, int offset, int maxLength, out byte outType, out byte[] outPayload)
        {
            outType = 0;
            outPayload = null;

            int bytesRemaining = maxLength - offset;

            // Is there a header?
            if (bytesRemaining < 0xC)
                return 0;

            // Get details
            byte type = data[offset + 1];
            ushort payloadSize = (ushort)((data[offset + 3] << 8) | data[offset + 2]);

            // Is the full packet here?
            if (bytesRemaining < payloadSize)
                return 0;

            // The rest of the packet
            uint ipAddr = BitConverter.ToUInt32(data, offset + 4);
            uint checksum = BitConverter.ToUInt32(data, offset + 8);

            byte[] payload = new byte[payloadSize];
            Array.Copy(data, offset + 0xc, payload, 0, payloadSize);

            // Check CRC32
            uint crc32 = Utils.CalcCRC32(payload);
            if (crc32 != checksum)
                return 0;

            // Decrypt if needed
            if ((type & 0x20) != 0)
                server.GetBlowfish().Decrypt(payload);

            // Done!
            outType = type;
            outPayload = payload;
            return payloadSize + 0xc;
        }

[OlivusPrime]

Not much further as trying to figure out the flow of the program w.o a debugger is frustrating. But you just made me think of something.... instead of trying to fix Flycast, why not patch Daytona to use a "free" port that Flycast understands? Will give it a try and see if I can debug in that case.

In the mean time I was actually reverse engineering the Onsen games. I got the whole protocol figured out (including the encryption and checksum), and got far enough into the login process that it connects into a "game" server. However a lot of the data is unknown and it never actually leaves the loading screen.

You're incredibly resourceful in how you keep making progress even when these walls are thrown at you, amazing work.

[ioncannon]

Was able to get a working Flycast copy with debugger and open ports. Hopefully it doesn't start crashing.

So found this issue:

The Daytona client was pulling the IP address that the PPP server assigned to the DC (on a DreamPi it's the... DreamPi, on Flycast it's a tiny PPP server called PicoPPP embedded in it). This is sent to the host and assigned into the player list as a key to pull up the player info whenever needed.

The problem is when an incoming UDP packet is received it reads where it came from; which ends up being the REAL IP address of the machine (not the PPP one). So the "getPlayerForSocket" function returns -1 as it can't find the player, and aborts packet parsing.

I was able to fix the problem partially by forcing the Flycast IP to match the machine IP. Well, only on my wife's PC; on mine Daytona says there was an issue setting up the connection. My guess is maybe because the server is on here too? Will try remotely hosting the server.

Anyway, after doing this fix, the guest client passed the first state; waitOthers. It then tries to send something to the host, but gets stuck due to the above bug because I can't match the IP on my PC.

Here are all the states:

Code: Select all

      if (state == 0) {
        ned_waitOthers(proceedResult);
      }
      else if (state == 2) {
        ned_waitStart();
      }
      else if (state == 3) {
        ned_syncStep1();
      }
      else if (state == 4) {
        ned_syncStep2();
      }
      else if (state == 5) {
        ned_receivedDataState();
      }
      else if (state == 6) {
        ned_gameplayState();
      }

(Functions are my naming convention. The first 4 states were found from debug text.)

These IP shenanigans are getting annoying. Is there any issue with assigning the PPP addr to the Machine Addr (IE: DreamPi's IP)? Once both sides can "see" each other from their player list + UDP endpoint, the rest should work automatically!

[ioncannon]

Update: https://www.youtube.com/shorts/2r8tF7dTpsw . Actually footage of me testing after fixing the IPs on the PPP servers. Think you can add Daytona as WIP .

[iron_chief]

Update: https://www.youtube.com/shorts/2r8tF7dTpsw . Actually footage of me testing after fixing the IPs on the PPP servers. Think you can add Daytona as WIP .

Ngl I got a bit teary there.

[ioncannon]

Update: https://www.youtube.com/shorts/2r8tF7dTpsw . Actually footage of me testing after fixing the IPs on the PPP servers. Think you can add Daytona as WIP .

Ngl I got a bit teary there.

Yeah, I shut off my camera right when the game went black and then a second later started up. Was a nice surprise.

Going to have to now bullet proof the gate/lobby servers as they are pretty unstable since I was more focused on researching the client. However during gameplay their was no lag (mind you I am on the same network) and it lasted 8 laps until VMWare crashed and took out my lobby server lol. The clients then gracefully exited.

Edit: Tried again, 8 laps and post game handled gracefully; returning me back to the lobby.