I'm going to have to read up on the aftermath. Glad things have worked out but, to me, it was never a huge issue. (Well, not until waiting 24hrs didn't work.)
Critical PS3 internal clock error and its aftermath
- Thread starter patsu
- Start date
I'm going to have to read up on the aftermath. Glad things have worked out but, to me, it was never a huge issue. (Well, not until waiting 24hrs didn't work.)
If that's the case, why did people setting their PS3's to the correct (OS) time not let them play their games - including disc-based games?
I think this issue is being glossed over. I know all DRM requires a timestamp - my concern is that Sony's DRM seems to require the CMOS timestamp, which implies when the battery dies altogether none of your DLC or PSN content will work, and none of your trophy-based games on disc will work. I'm not comfortable with that, and I hope they fix their system to make it work, because it's a shoddy thing to do and it's easily avoidable.
If consoles can connect to PSN without a battery, it implies that the DLC and stuff will work as well.
P.S. And why was my premium theme working after the bug when the system clock had changed the OS clock to 29.4.2020 ?
Last edited by a moderator:
Many people who removed and replaced their battery during the day of the dead reported that it fixed their system. Why it fixed their systems is yet another interesting story, I'm sure, but the end result is if the CMOS battery dies and you replace it, you'll be fine. Might even be okay if it just dies and you don't replace it, I don't think anyone tried that.
Maybe the older phats that worked did so because the battery was dead?
http://www.youtube.com/watch?v=MXfAzQv6yvA&feature=related
This guy pulls out the battery, boots the console, the date selection pops up, he just leaves it at 1/1/2000 and logs into PSN.
This guy pulls out the battery, boots the console, the date selection pops up, he just leaves it at 1/1/2000 and logs into PSN.
Why not crack open your PS3 and test it?
Did your premium theme work during the "day of the dead"? (lol @ androvsky)
Many people who removed and replaced their battery during the day of the dead reported that it fixed their system. Why it fixed their systems is yet another interesting story, I'm sure, but the end result is if the CMOS battery dies and you replace it, you'll be fine. Might even be okay if it just dies and you don't replace it, I don't think anyone tried that.
Maybe the older phats that worked did so because the battery was dead?
That's the cause of concern for me - the CMOS battery being replaced fixed the issue. What I'm hearing is that once the PS3's CMOS battery dies, content (including disc-based content) will not work. Sure, I can open up my PS3 to the motherboard and replace the battery... but is that the best option? Why not just let DRM use the system date, or even the internet date when it's available? Telling me I need to crack open my PS3 and replace a battery to play disc based games is a very poor solution, if that's what the situation is.
If the CMOS battery life is, say, five years, and Sony is pushing a "10 year life cycle", do they honestly expect the 30-50million owners from, what, 2012 onwards to open their machine to replace a battery? Surely fixing their DRM system via a firmware update is much more preferred for everyone. I don't understand why anyone would choose to defend this.
My clock read 1/3/10 yesterday, so I had to update it.
I think it is more likely that the PS3 OS is hitting a error with an "unrecognized time", which was the main problem.
This is pure speculation, but works logically for me.
It's not that the CMOS time stamp is required or something, it just needs to have a "recognizable" CMOS time stamp for the PS3 OS DRM to work properly.
If this wasn't the case, the removal of the CMOS battery would wreak havoc on the DRM of the PS3s that did have their batteries removed and this apparently did not happen.
This would make sense since an unrecognized time is not within the system's design so the developers didn't anticipate a workaround for the DRMs to just look at the system time, it simply wasn't thought about.
Taking out the battery will reset the CMOS time to some pre-determined date, and then the OS will recognize that pre-determined date again, and therefore DRM will work as usual again as resetting the CMOS time moves the CMOS time away from the unrecognizable 2010/02/29.
The battery being dead would probably not be a problem. In the case of the battery being dead, every time you turn on your PS3 would probably require you to enter that day's date and time to calibrate the OS date as the PS3 has no means to keep time while it is turned off. But while the PS3 is on, the CMOS time stamp should be available.
Furthermore, since the CMOS time would be that recognizable pre-determined date, DRM should be able to work properly.
For a test, someone could remove the CMOS battery and try to log on. If I'm right, then the battery being dead or not should not affect DRM.
Why not crack open your PS3 and test it?
Did your premium theme work during the "day of the dead"? (lol @ androvsky)
PARANOiA much ?
I don`t need to test it. I`m sure that it will work. Premium themes showed up as corrupt files during the bug period.
I didn`t even have to re-download,re-install it, it was just there again,ready to be applied.
And now everything works fine though the clock thinks we have the year 2020.
I think that it's along these lines. Maybe GameOS only checks the RTC through the hypervisor on boot and when you try to set the time - maybe it works on a offset from that? As my machine remained running, everything carried on working and the OS date passed to 1st March 2010 without a problem. Maybe the PSN sync and the DRM works off the OS clock which in my case remained running, who knows?
The user readable time and the system time may be used differently. e.g., We have Daylight Saving (+/- 1 hour) but the rest of the system doesn't really care. From security perspective, they are more interested in for example "time" differences between server and client, or the validity of a time value (e.g., what the hell is 2/29/2010 ?). When you change the user readable time, you are just tweaking the clock's presentation (e.g., changing timezone). You won't change how other systems use the real clock value.
All DRM implementations and authentication rely on some sort of timestamp; like for public key based systems, it's used to detect the validity of your certificates. To get a trophy, they will need to authenticate you to PSN first. Same for playing protected content. There are fully offline security systems, but this kind of systems has a whole slew of (IMHO more confusing) problems to solve. [size=-2]Be careful what you wish for ![/size]
I'd think CMOS clock is a pretty standard component. A lot of media devices (e.g., Zune, RIMM) and laptops (e.g., MacBook Air) have it.
I used Internet time server. Didn't have to do a thing for both PS3s.
It's a simple and easy to make change anyway, compared to waiting for download and patch.
EDIT: I disconnected my PS3 and played PJ Shooter. It's doable, so the DRM implementation already allows off-line authentication and authorization. If you want an offline trophy award system (or no trophy if offline), then it may be an enhancement request to the trophy system rather than the security or DRM system. Also, the clock bug may have affected the PS3 before these systems are in-play.
I used it too, but there's no automatic sync option from what I can see so I had to find and select to update. I'm just being picky about your point there was no user action required for correct recovery.
My theory, setting the time is not actually setting the time in the hardware, but an offset from the time in the hardware.
In otherwords, the time/date the hardware thinks it is, is not changed. But how much the OS adds to the hardware time, to get the correct time.
Daylight Savings time is handled the same way, so I'd imagine I'm right
Cause it reset the hardware time.