PS3 PSN Error 80710A06 - Spoofed CFW's unable to go online

Some bad news for PS3 CFW user's who have a "spoofed firmware" as it seems Sony has made a move to block spoofs from accessing the PlayStation Network (PSN), however CFW user on 4.66 are unaffected at this time. When logging into the network you will be presented with a Error Code of "80710A06" and be signed out of the network, which reports have pointed to only spoofed CFW user's getting this error. The good news [break]ss[/break] recently there was a release of about 8 popular services that no longer have the PSN login attached to them thanks to scene developers who were able to lift this intrusive requirement the official Netflix / YouTube and other applications . You can see these "NO PSN Apps" via this link


Be sure to stay tuned at PSX-Place.com as more develops on this latest news surrounding the PlayStation Network and CFW user's


playstation-network-down.jpg


Sources: PSX-Scene / Nextgenupdate


 
Now I hope there is a Rebug 4.66 as until now I saw no reason for it. Here is hoping the team can help.

Me too :'( this news made me deeply angry and sad, I hope the team Rebug make another Rebug CFW COBRA 4.66 (equal to 4.65.2, but updated and without Spoof)
 
jump on habib 4.66 buy your games then back to rebug :p

I don't know man... I really need Rebug's CFW. If they can't upgrade, maybe i jump to Habib 4.66 COBRA, but this is the last thing I want to do, although the Habib's CFWs is excelente (only CEX, not DEX). :crybaby:
 
They can be simply changed the pass phrase which blocks the spoof.
We must start the job not that.
 
CELL_HTTPS_ERROR_HANDSHAKE 0x80710a06
SSL Connect Handshake error, or SSL certificate verification failed

Error Codes - PS3 Developer wiki

atd3qt5s8isw0aizg.jpg


It's very very weird... All the certificates are the same for both 4.65/4.66 and SONY also added an extra psn pass phrase since 4.60 but spoofed 4.46 also worked fine till yesterday [even 4.21]

Server exchanges certificates and handshake fails due to its encrypted data mismatches.

I wonder what they added to check this spoof.
 
Observing the traffic it is seen that the spoof is detected very quickly.

Maybe you have to block certain request but I do not find that :(
 
Word on the street is it was a server change and version spoofing will need a slight update.
 
Word on the street is it was a server change and version spoofing will need a slight update.

If that is the case hopefully team REBUG is working on it and will offer an update. I really hope they don't make you use another method until they decide to release a new firmware like in 4.65.2.
 
If that is the case hopefully team REBUG is working on it and will offer an update. I really hope they don't make you use another method until they decide to release a new firmware like in 4.65.2.

I know, I dont want to update out of rebug ether.
 
They disabled SSLv3 on the server.

An easy way to confirm this is using the OpenSSL binary:

Code:
C:\OpenSSL-Win32\bin>openssl.exe s_client -connect 198.107.130.100:443 -ssl3
Loading 'screen' into random state - done
CONNECTED(000000AC)
15264:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:
.\ssl\s3_pkt.c:1292:SSL alert number 40
15264:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:.\ssl\s3_pkt.c:615:

If you do the same command without the -ssl3 flag it connects fine using TLSv1.

If someone can figure out a way to make Rebug 4.65 use TLS, then it should be able to connect again.
 
They disabled SSLv3 on the server.

An easy way to confirm this is using the OpenSSL binary:

Code:
C:\OpenSSL-Win32\bin>openssl.exe s_client -connect 198.107.130.100:443 -ssl3
Loading 'screen' into random state - done
CONNECTED(000000AC)
15264:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:
.\ssl\s3_pkt.c:1292:SSL alert number 40
15264:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:.\ssl\s3_pkt.c:615:

If you do the same command without the -ssl3 flag it connects fine using TLSv1.

If someone can figure out a way to make Rebug 4.65 use TLS, then it should be able to connect again.

Most likely went from SSL3, to TLS1 as suffering from serious security problems. Many platforms are migrating to TLS. So, once logged into the system you have a self-signed certificate.
 
Most likely went from SSL3, to TLS1 as suffering from serious security problems. Many platforms are migrating to TLS. So, once logged into the system you have a self-signed certificate.

The answer is in VSH, it seems like 4.66 vsh works on 4.65, even lv2kernels are the same, that's how people were able to port cobra 4.65 to 4.66 in less than 30mins :)
 
The answer is in VSH, it seems like 4.66 vsh works on 4.65, even lv2kernels are the same, that's how people were able to port cobra 4.65 to 4.66 in less than 30mins :)
Should we expect any "official" spoofer from the rebug team, or should we mess with vsh ourselves? :p
 

Featured content

Trending content

Back
Top