Re: Daytona USA Progress
Posted: Wed Jan 11, 2023 4:39 pm
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:
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.
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)"
In the mean time I'll play with the POST data and confirm if my research on the responses all work.