PS3 DECH-2500A Testkit

Just found out something interesting while taking some pictures of my devkit. While looking for the manufacturing datecode, i noticed that unlike normal retail systems, DECH's don't have them, instead they're printed like they are on FAT PS3 retails, stating the month and year.

1.png


But what puzzled me was, it's manufactured in May of 2011. So technically it's datecode would be 1B, but 1B systems ususally have a minver of 3.56 to 3.60 and therefore unhackable, but this system has a minver of 3.40. And 3.40 was released around July of 2010, so howcome it has a lower minver of a firmware that was released a year before the manufacturing of this system? Just something that baffled me as all.

upload_2021-3-7_16-36-9.png
 
I was asking about this on discord a while back, as I saw an EA DECH2500 for sale here locally.

It turns out devkits are way behind compared to retails. @DoublesAdvocate was saying he has DECR1400 from 2011 with minver 2.60, and also DECHA from 2008 with minver v1.00. I guess security was not such a big concern with those units as they can run debug content anyway, and also they cost so much at the time.
 
DeViL303 said:
I guess security was not such a big concern with those units as they can run debug content anyway, and also they cost so much at the time.
Click to expand...
Ahh that does make sense, since they were only given to trusted developers. It does make me wonder how they get leaked from companies and into the hands of the public.
 
DeViL303 said:
It turns out devkits are way behind compared to retails
Click to expand...
hm funny, but talking about reference tools, looking at the coreos differences, it turns out the sources are compiled and made at last, from date and time strings. aren't these the first units that get supplied to developers?

edit
I don't think you are only paying high prices for the license, but also for better hardware. this is what I think at least
 
Last edited:
What they did to block the metldr exploit was to modify a previous step of the bootchain named lv0ldr
In other words... they modifyed the bootchain to "embed" one of the steps (insecure) in the previous step (secured)
Probably the mistake is still there... is just we cant take a look at it :D

Well... that low steps of the bootchain (lv0ldr, lv0, bootldr, metldr), are installed at factory in a process that is independent of the other firmware installation. A standard PUP installation is not able to modify that lower steps of the bootchain
We use to identify the "CFW compatible" PS3 models based in the minfirmwarever, or the datecode/manufacturing date... but thats just a coincidence
What happened is they "fixed" the mistake (new bootchain) at the time the last retail PS3 firmware version available was 3.56 but there is not a real dependency or relationship in between them

Probably they was in a hurry to update the bootchain for retail PS3 models... but they took it more calmly for debug PS3 models
This is the kind of process where is needed to advise all the directors of the factories producing the consoles that an important change in the software tools is going to happen in the next days, then the directory of the factory advises the personal on chargue of the machines, then sony sends them the new software and instructions of how to do it... etc...
Is a panic moment where there is lot of room for mistakes that could be a disaster in the production lines, as far i remember it took them a couple of months :D
 
sandungas said:
Probably they was in a hurry to update the bootchain for retail PS3 models... but they took it more calmly for debug PS3 models
Click to expand...
True. So basically at the time, they wanted to patch it out asap before more consoles were manufactured with the exploit? Whereas since debugging models were not available to the public, they could take their time with it hence why these models and other nonretail systems don't have matching minimum versions or metldr's compared to their retail counterparts.
 
dazzaXx said:
True. So basically at the time, they wanted to patch it out asap before more consoles were manufactured with the exploit? Whereas since debugging models were not available to the public, they could take their time with it hence why these models and other nonretail systems don't have matching minimum versions or metldr's compared to their retail counterparts.
Click to expand...
Yes, updating the software tools at factories could be a slow process but they tryed to do it fast, i remember well that days because i heard rumours about the exploit some weeks/months before it was released and i was collecting money to buy a new PS3... so i was ready to buy the last PS3 model compatible with CFW
Lets say... i was aware that the PS3 models that was in current production (CECH-25xx) was vulnerables to the exploit (so i could go to a shop and buy any) but i was waiting a bit more to see if they was going to release a new PS3 model vulerable to the exploit too, lol
But this never happened, one day someone reported in scene forums about a PS3 CECH-25xx where the metldr exploit was locked... and at the next day i bought a CECH-25xx (in the shop i bought it only available by buying the "move edition" bundle)

Later they started selling CECH-25xx without bundle (25$ cheaper or so), and also with smaller hdd capacity (the most cheapest option, but im not sure if this ones had the new bootchain)

--------------
At that time i had the feeling they was reorganizing the production, the CECH-25xx was a bit like the final evolution of the slims (CECH30xx is like a review, the first time they started reducing costs in slims), also they had 2 different motherboards for CECH-25xx (JTP and JSP), also the different hdd capacities was a bit mess too

I think they was focusing his attention in all that and delayed a bit the changes related with the debug PS3 models, also i guess the datecode/manufacturing date "printed" in the plastic case is the date when the whole console is "assembled"... but the motherboards for debug could be manufactured some months before, are the same than retail, but probably they are made in the same production line (maybe even in the same factory), with his specific software tools
 
So, a bit of an update. My DECH for some reason now decides once i've turned it off, to keep the fans running? Even when the LED is red and nothing is lit up they're still spinning and blowing out air. Anyone know as to why?

EDIT: Nevermind, turns out it was because "Wake On LAN" was enabled in the debug settings. Odd though because that's been on when i've had an ethernet cable plugged into it before and it hasn't done that until now.
 
Last edited:
dazzaXx said:
My DECH for some reason now decides once i've turned it off, to keep the fans running? Even when the LED is red and nothing is lit up they're still spinning and blowing out air. Anyone know as to why?
Click to expand...

̶I̶ ̶t̶h̶i̶n̶k̶ ̶i̶ ̶h̶a̶v̶e̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶i̶s̶s̶u̶e̶:


(CECH2504B)
 
Last edited:
DeViL303 said:
It's not an issue, its normal. If you have "Wake on LAN" or "Remote Start" for remote play enabled, the console is not fully off.
Click to expand...
Now i know lol, i hadn't even messed with the debug settings at all, they're all still set from when EA used it, so when i had an ethernet cable plugged in multiple times before, the fans never stayed on until now. :eek:

Also, i'm most certain the coin battery inside the system is dead, as when i unplug it from the socket, the date and time reset. Funny thing was, when i set the date and time manually and checked webman's time on / total time, it said it had been on for 3566 days, as well as the total time that skyrocketed up to a total of 3500+ days of total on time, although once i did a reset, the actual total time and time on were back to what they should be. I don't know if that's a bug with webman or the syscon or not, but i thought i'd mention it.
 
Right, so i've been thinking about this for a while and would like some other people's opinions on this. As i stated in my last post here, the coin battery in my DECH is dead and cannot hold the date and time when unplugged from the power. I would like to fix this as i do have some replacement Energizer brand lithium CR2032 coin batteries and a T8 torx security screwdriver so i don't have to bootleg removing the screws with a small flathead, but at the same time i also don't want to destroy it's original warranty sticker.

But, if i do open the system, i can do a little cleaning on the inside. Granted, i only plan to replace the coin battery and not go any further than that. While i would like to replace the thermal paste at some point, i don't think i'd be that comfortable fully dissasembling this yet.

What would you think? Personally now when i think about it, it would be more beneficial if i replaced the battery, even if it does mean sacrificing the warranty sticker. But, would still like to get some other opinions. Thanks!

P.S. Are Energizer coin batteries good for use in PS3's? I heard somewhere that you should only use Sony brand but i don't think that's correct.

EDIT: I also noticed something interesting where the hard drive cover is, usually there are logos on it but on this, while there are logos, there are fewer than on a retail? I can't see some of them however since there's a sticker covering them.
 
Last edited:
Sorry for the bump but I just ordered one of those.

So basically the process is:
1. Forget about bgtoolset
2. Just downgrade to DEX 3.55 because DECH are already QA flagged
3. Install Evilnat 4.90 DEX or D-PEX?

Am I correct?
 
NiQ said:
Sorry for the bump but I just ordered one of those.

So basically the process is:
1. Forget about bgtoolset
2. Just downgrade to DEX 3.55 because DECH are already QA flagged
3. Install Evilnat 4.90 DEX or D-PEX?

Am I correct?
Click to expand...
Just in case someone runs into this - I've tried and this is indeed the correct procedure.
DECH-2500 units apparently all have a minimum firmware version of 3.40 and should be CFW compatible. Obviously, I can't 100% verify this, but my unit is from 3/2011 and the lowest version was still 3.40.
No need to use any hacks since they allow downgrades out of the box, so the procedure is just downgrade to 3.55 then install any DEX CFW (e.g., Evilnat D-PEX, Rebug D-REX).
Regarding the 3.55 downgrade - the "official" 3.55 downgrade package that's often linked to did not work for me. The 3.55 PUP that did has an MD5 of 047671664D9241C04D44278944E153D9, so look for that one if you have any issues. I did not have to use recovery mode or target manager.
 
NiQ said:
Just in case someone runs into this - I've tried and this is indeed the correct procedure.
DECH-2500 units apparently all have a minimum firmware version of 3.40 and should be CFW compatible. Obviously, I can't 100% verify this, but my unit is from 3/2011 and the lowest version was still 3.40.
No need to use any hacks since they allow downgrades out of the box, so the procedure is just downgrade to 3.55 then install any DEX CFW (e.g., Evilnat D-PEX, Rebug D-REX).
Regarding the 3.55 downgrade - the "official" 3.55 downgrade package that's often linked to did not work for me. The 3.55 PUP that did has an MD5 of 047671664D9241C04D44278944E153D9, so look for that one if you have any issues. I did not have to use recovery mode or target manager.
Click to expand...
Apologies for not responding on this, I haven't been on here in months. Glad you figured it out tho!
 
You must log in or register to reply here.

Similar threads

Back
Top