PS3 Release: PS3 Advanced Tools

sandungas · Mar 4, 2022

bguerville said:
I am adding this stuff to the PS3 Toolset too, it will be in the coming update roll out.

Here is a ss preview of what it will look like on one of my slims (25xx). As you suggested it would say "Board ID: unknown" if the "platform id" was not in our list of known ids.

Nice, this is going to help to complete the list

In the list in wiki there are 3 or 4 motherboards from PS3 superslims that are supposed to be common, i think is just a coincidence that we dont have a report of them yet

Btw, if at some point someone reports an unkown superslim board, ask about the flash type (NOR or eMMC), and the PS3 model from the sticker in the plastic shell, also in some cases it could be handy to know if the PS3 was bought used (just incase the previous owner build a PS3 with the shell and motherboard from different PS3 models)

bucanero · Mar 4, 2022

@sandungas thanks for sharing those improvement ideas

I don't have much time for homebrew stuff at all, perhaps @M4j0r wants to add these changes to the source, and then I can update the GitHub repo. In any case it's mostly cosmetic changes right?

bguerville · Mar 4, 2022

bucanero said:
@sandungas thanks for sharing those improvement ideas

I don't have much time for homebrew stuff at all, perhaps @M4j0r wants to add these changes to the source, and then I can update the GitHub repo. In any case it's mostly cosmetic changes right?

I don't think there are any changes to make for this last proposed code addition, if I am not mistaken, you could just insert the quoted code at line 131 of main.c in sm_error_log project & optionally repack the pkg to make a new release file even though it is not much for an update.

Alternatively sandy could make a pull request in your repo, you would only have to accept it once tested.

sandungas · Mar 4, 2022

Yes, just cosmetic, the timestamp format is a bit more simple, and the motherboard names is because when someone posts in the forum one of the log.txt created by this tool i use to check in wiki (in the platform id page) which motherboard is it, even if the person posting the log.txt mentions it, i use to check if some of the info from the log.txt was labeled as "unknown" in wiki, this is going to simplify it a bit too

An improvement would be to add a text description with the Syscon Error Codes
I noticed many people "edits" the log.txt before posting it in the forum to add the description at the right. That descrioptions are the page section names (added by me some weeks ago), im not fully confident with them but are "inspired" in the officials without respecting the original names much, but i guess are fine by now, if someone have alternative descriptions im fine in using different ones
Is just... in total we have 17 + 27 + 21 + 35 = 100 error codes
Im not sure if implementing this in the code using a switch with 100 cases is a bit overkill
Also, is needed to "split" the error code in bytes (so is needed to change his data type), the first 2 bytes are important, but the real error code are the last 2 bytes
So... dunno... if someone wants to suggest a code structure for it please post it here and me and other people will try to complete the text descriptions

By now we dont need to add the 100 btw... a lot of them are unnamed in wiki because we never found anyone reporting them

bguerville · Mar 4, 2022

sandungas said:
Nice, this is going to help to complete the list
In the list in wiki there are 3 or 4 motherboards from PS3 superslims that are supposed to be common, i think is just a coincidence that we dont have a report of them yet

Btw, if at some point someone reports an unkown superslim board, ask about the flash type (NOR or eMMC), and the PS3 model from the sticker in the plastic shell, also in some cases it could be handy to know if the PS3 was bought used (just incase the previous owner build a PS3 with the shell and motherboard from different PS3 models)

I am confident that we'll eventually complete that list ;-)

It's a bit off-topic here but somewhat related so here goes.
I think that the more system information I can display in the Toolset system manager the better, there ought to be more useful data about the system to be extracted without lv2 exploit required & displayed there. Maybe disk info/network info/attached devices (pad, BT, USB)/chips temperature/etc..
Maybe I could also add a "rebuild db on reboot" and/or a "go to recovery on reboot" feature, that kind of things.
All those things could be added to the advanced tools too if they aren't there already.

sandungas · Mar 4, 2022

bguerville said:
I am confident that we'll eventually complete that list ;-)

I think that the more system information I can display in the Toolset system manager the better, there ought to be more useful data about the system to be extracted without lv2 exploit required & displayed there. Maybe disk info/network info/attached devices (pad, BT, USB)/chips temperature/etc..

From the PS3 model it can be derivated a lot of hardware components, lets say... around 80% of the components that appears in this tables
https://www.psdevwiki.com/ps3/Talk:SKU_Models
Are not fully accurate though, in some of them it would be better to identify them by his software ID just incase the motherboard was repaired/refurbished and some components was replaced
Right now im not sure if there is something failproof that could be retrieved with syscalls

----------
The next natural thing after identifying the motherboard name would be to deduce the PS3 model name
You know... there are many apps that does it since years ago, and as far i know it was always made by reading the https://www.psdevwiki.com/ps3/Product_Sub_Code
The good thing of it is the product subcode allows to difference a CECHAxx from a CECHBxx (both using the same COK-001 motherboard with the same platfom id = Cok14)
And CECHCxx from a CECHExx (both using the same COK-002 motherboard with the same platfom id = CokB10)
But in the CECH-25xx is needed to check the platform ID to difference motherboard JTP-001 from JSD-001 (both are using product subcode = 0x0B)
So... is needed to check both things, im not sure whats the best logic to follow
When we move on to the superslims this becomes a bit more confusing, personally if it was me who had to write this logic i would not make any assumption because t could be conunterproductive, i would add a lot of "unknowns" for the superslims and wait for user reports to confirm the speculations from wiki

Also, by reading the https://www.psdevwiki.com/ps3/Product_Code you can find the region of the PS3 (to add the digit suffix of the PS3 model name)
Lets say... in your screenshot

Board ID = JSD-001 = Slim (so the PS3 model name follows the format CECH-YYxx instead of CECHYxx)
Product subcode = B = CECH-25xx
Product code = 82 = CECH-2500 (damn, you converted it to debug to ruin this example, lol so the 00 at the end means "worldwide" region, in this case we dont know the real region printed in the shell sticker)
So.. after checking all this:
PS3 model: DECH-2500

EDIT:
Btw, how are you finding if the firmware is CEX or DEX ?, there is some easy way with syscalls or whatever ?, right now im thinking in this screen https://www.psdevwiki.com/ps3/More_System_Information
At top there is a line that tells the firmware type and regions, and is taken from
https://www.psdevwiki.com/ps3/Index.dat
I guess this is a failproof way because is not even telling the region and the firmware type, but also the special PS3 models that appears grouped together in the product code page (like DEX-ww, dtcpipdevdex, and qabdp that shares the same product code 0x82 but have a different PS3 model name)... the final PS3 model name depends of them (the "AV tool" PS3 models adds an "S" in the PS3 model name)
I guess the PS3 model identification should start this way... just to be sure

The problem in the example i wrote above with your PS3 bgerville is i "jumped" from CECH-25xx to DECH-25xx just because i saw in your screenshot that is mentioned DEX in top-right corner... but in some way thats cheating because im not sure how you are identifying the firmware type

The point is... there is a conflict in the way i suggested to identify the PS3 model because in this case the PS3 model name CECH-2500 is completly valid and used in retails (in retails the 00 suffix just means japan region)

bguerville · Mar 4, 2022

sandungas said:
The problem in the example i wrote above with your PS3 bgerville is i "jumped" from CECH-25xx to DECH-25xx just because i saw in your screenshot that is mentioned DEX in top-right corner... but in some way thats cheating because im not sure how you are identifying the firmware type
The point is... there is a conflict in the way i suggested to identify the PS3 model because in this case the PS3 model name CECH-2500 is completly valid and used in retails (in retails the 00 suffix just means japan region)

The Toolset uses syscall 985 which takes a uint64_t* pointer as argument to return the kernel type (CEX, DEX, DECR for sure, never managed to test other types & didn't check the kernel code disassembly either though). The Toolset priority is CEX, the rest is bonus but if someone was willing to test I could easily make it DECR compatible provided that the Toolset firmware version requirements (4.80+) are respected, not sure what it would bring to the table of DECR users though.
As to the VSH type, it is inferred from the VSH TOC in other words, it might be feasible to infer the console model's SKU like you said using the various pieces of data & putting them together.

sandungas · Mar 7, 2022

bguerville said:
it might be feasible to infer the console model's SKU like you said using the various pieces of data & putting them together.

I was not completly sure how far we could go with this PS3 model identification procedures and the logic we should use, but after playing around with it (and checking a bunch of wiki pages as reference) i think this code chunk should work :encouragement:

As you can see im relying a lot on the platform_id because is directly readed from inside syscon EEPROM, and it can be used as a failproof identifyer of the motherboard name, after that im deducing the console_series directly for all them (except for COK-001 and COK-002 that requires to check the "product sub code" from IDPS)

The point is... the IDPS is stored 2 times in EID0 and EID5, the CEX2DEX conversions like yours is changing it in EID0 (but not in EID5), there are also the IDPS spoofers that are disturbing a bit this PS3 model identification procedures
Actually, the "product code" and "product sub code" (taken from the IDPS) are something a bit unrelliable. and for curiosity sake... the fact is we can do this procedure 2 times with the IDPS from EID0 and EID5

I added support for the "debug" (DECH) and "reference tool" (DECR) PS3 models because are just a few more code lines
I added lot of comments, included the code required for the unkown identifyers of the superslims, this way when someone reports them you just need to uncomment it. there are 7 unknown superslims but i found photos of 6 them in google so im completly sure that combinations exists... the way how are assigned is still a bit speculative

Please @bgerville try it in your toolset, as far i understood your code related with this is inspired in the PS3 advanced tools in @bucanero git, i used the same variable names and all, is intended to be directly pasted in it, in your PS3 it should print:

Code:

PS3 Model Name: DECH-2500A/B (Worldwide)

Im not declaring the syscall functions btw... in your toolset you already have sys_dbg_get_console_type but it neeeds to be added into the PS3 advanced toold for this to work

New version in this post:
https://www.psx-place.com/threads/release-ps3-advanced-tools.34104/page-6#post-327852

Code:

char board[8]; char console_type[8]; char console_series[4]; char console_region_code[4]; char console_storage[4]; char console_region_name[32]; // platform_id is the output of syscall 387. sys_sm_get_system_info // pscode[3] is the output of syscall 867. sys_ss_appliance_info_manager -> get_ps_code. Also known as "Product Code", 6th byte of IDPS // pscode[5] is the output of syscall 867. sys_ss_appliance_info_manager -> get_ps_code. Also known as "Product Sub Code", 8th byte of IDPS switch (hwinfo.platform_id) { case 'Cyt2.2': // DEH-R1000, DEH-R1010, DEH-R1020 board = 'TMU-510'; break; case 'Cyt3.1': // DEH-R1030 board = 'TMU-520'; break; case 'Cyt3.2': // DEH-R1040, DECR-1000 board = 'TMU-520'; console_series = '-10'; break; case 'Deb01': // DECR-1400 board = 'DEB-001'; console_series = '-14'; break; case 'Cok14': board = 'COK-001'; switch (pscode[5]) { case '1': // CECHAxx console_series = 'A'; break; case '2': // CECHBxx console_series = 'B'; break; } break; case 'CokB10': board = 'COK-002'; if (pscode[3] == 0xA0) { console_series = '-11'; // GECR-1100 break; } switch (pscode[5]) { case '3': // CECHCxx console_series = 'C'; break; case '4': // CECHExx console_series = 'E'; break; } break; case 'CokC12': // CECHGxx board = 'SEM-001'; console_series = 'G'; break; case 'CokD10': // CECHHxx board = 'DIA-001'; console_series = 'H'; break; case 'CokE10': // CECHJxx or CECHKxx board = 'DIA-002'; break; case 'CokF10': // CECHLxx or CECHMxx or CECHPxx or CECHQxx board = 'VER-001'; if (pscode[3] == 0xA0) { console_series = '-15'; // GECR-1500 break; } break; case 'CokG11': // CECH-20xxA/B board = 'DYN-001'; console_series = '-20'; console_storage = 'A/B'; break; case 'CokH11': // CECH-21xxA/B board = 'SUR-001'; console_series = '-21'; console_storage = 'A/B'; break; case 'CokJ13': // CECH-25xxA/B board = 'JTP-001'; console_series = '-25'; console_storage = 'A/B'; break; case 'CokJ20': // CECH-25xxA/B board = 'JSD-001'; console_series = '-25'; console_storage = 'A/B'; break; case 'CokK10': // CECH-30xxA/B board = 'KTE-001'; console_series = '-30'; console_storage = 'A/B'; break; /* case 'CokM10': // CECH-40xxB/C ? board = 'MPX-001'; console_series = '-40'; console_storage = 'B/C'; break; */ case 'CokM20': // CECH-40xxB/C board = 'MSX-001'; console_series = '-40'; console_storage = 'B/C'; break; case 'CokM30': // CECH-40xxA board = 'MPX-001'; console_series = '-40'; console_storage = 'A'; break; /* case 'CokM40': // CECH-40xxA ? board = 'MSX-001'; console_series = '-40'; console_storage = 'A'; break; */ case 'CokN10': // CECH-40xxB/C board = 'NPX-001'; console_series = '-40'; console_storage = 'B/C'; break; /* case 'CokN30': // CECH-40xxA ? board = 'NPX-001'; console_series = '-40'; console_storage = 'A'; break; */ case 'CokP10': // CECH-42xxB/C board = 'PQX-001'; console_series = '-42'; console_storage = 'B/C'; break; /* case 'cokP20': // CECH-42xxB/C ? board = 'PPX-001'; console_series = '-42'; console_storage = 'B/C'; break; */ case 'CokP30': // CECH-42xxA board = 'PQX-001'; console_series = '-42'; console_storage = 'A'; break; case 'CokP40': // CECH-42xxA board = 'PPX-001'; console_series = '-42'; console_storage = 'A'; break; /* case 'cokR10': // CECH-43xxB/C ? board = 'RTX-001'; console_series = '-43'; console_storage = 'B/C'; break; case 'cokR20': // CECH-43xxB/C ? board = 'REX-001'; console_series = '-43'; console_storage = 'B/C'; break; case 'cokR30': // CECH-43xxA ? board = 'RTX-001'; console_series = '-43'; console_storage = 'A'; break; */ case 'cokR40': // CECH-43xxA board = 'REX-001'; console_series = '-43'; console_storage = 'A'; break; default: board = 'Unknown !!!'; console_series = '-xx'; console_storage = ' '; } switch (pscode[3]) { case '81': console_type = 'DECR'; console_region_code = '00'; console_region_name = 'Worldwide'; break; case '82': console_type = 'DECH'; console_region_code = '00'; console_region_name = 'Worldwide'; console_storage = ' '; break; case '83': console_type = 'CECH'; console_region_code = '00'; console_region_name = 'Japan'; break; case '84': console_type = 'CECH'; console_region_code = '01'; console_region_name = 'United States'; break; case '85': console_type = 'CECH'; console_region_code = '04'; console_region_name = 'Europe'; break; case '86': console_type = 'CECH'; console_region_code = '05'; console_region_name = 'Korea'; break; case '87': console_type = 'CECH'; console_region_code = '03'; console_region_name = 'United Kingdom'; break; case '88': console_type = 'CECH'; console_region_code = '11'; console_region_name = 'Mexico'; break; case '89': console_type = 'CECH'; console_region_code = '02'; console_region_name = 'Australia'; break; case '8A': console_type = 'CECH'; console_region_code = '06'; console_region_name = 'South Asia'; break; case '8B': console_type = 'CECH'; console_region_code = '07'; console_region_name = 'Taiwan'; break; case '8C': console_type = 'CECH'; console_region_code = '08'; console_region_name = 'Russia'; break; /* case '8D': // PS3 never released in China console_type = 'CECH'; console_region_code = '09'; console_region_name = 'China'; break; */ case '8E': console_type = 'CECH'; console_region_code = '12'; console_region_name = 'Hong Kong'; break; case '8F': console_type = 'CECH'; console_region_code = '14'; console_region_name = 'Brazil'; break; case 'A0': console_type = 'GECR'; console_region_code = '00'; console_region_name = 'Worldwide'; console_storage = ' '; break; default: console_type = 'UNKN'; console_region_code = 'xx'; console_region_name = 'Unknown'; } if (strcmp(hwinfo.platform_id, 'Cyt2.2') == 0) { fprintf(fp, "PS3 Model Name: DEH-R1000, or DEH-R1010, or DEH-R1020 (Worldwide)"); } else if (strcmp(hwinfo.platform_id, 'Cyt3.1') == 0) { fprintf(fp, "PS3 Model Name: DEH-R1030 (Worldwide)"); } else if (strcmp(hwinfo.platform_id, 'Cyt3.2') == 0) { fprintf(fp, "PS3 Model Name: DEH-R1040, or DECR-1000 (Worldwide)"); } else if (strcmp(hwinfo.platform_id, 'CokE10') == 0) { // print PS3 model 2 times, with the console_series hardcoded to J and K fprintf(fp, "PS3 Model Name: "); fprintf(fp, "%sJ%s", console_type, console_region_code); fprintf(fp, ", or "); fprintf(fp, "%sK%s", console_type, console_region_code); fprintf(fp, " (%s)\n", console_region_name); } else if (strcmp(hwinfo.platform_id, 'CokF10') == 0 && pscode[3] != 0xA0) { // print PS3 model 4 times, with the console_series hardcoded to L, M, P, Q fprintf(fp, "PS3 Model Name: "); fprintf(fp, "%sL%s", console_type, console_region_code); fprintf(fp, ", or "); fprintf(fp, "%sM%s", console_type, console_region_code); fprintf(fp, ", or "); fprintf(fp, "%sP%s", console_type, console_region_code); fprintf(fp, ", or "); fprintf(fp, "%sQ%s", console_type, console_region_code); fprintf(fp, " (%s)\n", console_region_name); } else { // print PS3 model 1 time fprintf(fp, "PS3 Model Name: %s%s%s%s (%s)\n", console_type, console_series, console_region_code, console_storage, console_region_name); } fprintf(fp, "Motherboard Name: %s\n", board);

And please @M4j0r take a look at the logic im following, you are a lot more used than me to non-retail PS3 models and knows well the related wiki pages, i know there is an small flaw in the identification of the DEH-R1040 model, this code prints DECR-1000 for it
There are also a couple of switch cases related with the PS3 models using the prefix "DEH-R", but is commented out because i dont know any way to identify them

sandungas · Mar 7, 2022

sandungas said:
And please @M4j0r take a look at the logic im following, you are a lot more used than me to non-retail PS3 models and knows well the related wiki pages, i know there is an small flaw in the identification of the DEH-R1040 model, this code prints DECR-1000 for it
There are also a couple of switch cases related with the PS3 models using the prefix "DEH-R", but is commented out because i dont know any way to identify them

Ohh, well, i just realized there is an easy way to identify them, not much elegant but is accurate enought

Code:

else if (strcmp(hwinfo.platform_id, 'Cyt2.2') == 0) {
    fprintf(fp, "PS3 Model Name: DEH-R1000, or DEH-R1010, or DEH-R1020 (Worldwide)");
}
else if (strcmp(hwinfo.platform_id, 'Cyt3.1') == 0) {
    fprintf(fp, "PS3 Model Name: DEH-R1030 (Worldwide)");
}
else if (strcmp(hwinfo.platform_id, 'Cyt3.2') == 0) {
    fprintf(fp, "PS3 Model Name: DEH-R1040, or DECR-1000 (Worldwide)");
}

EDIT:
I updated the code with this changes, now is able to identify the Reference Tool prototypes "DEH-Rxxxx" PS3 models

M4j0r · Mar 7, 2022

@sandungas
sys_dbg_get_console_type only returns 1/2/3.
To get the full target type you'd also need to get the VSH Target, it's probably available from a VSH Export or it's possible to read it from the Syscon EEPROM: https://www.psdevwiki.com/ps3/Promo_flags.txt . I don't know how the EEPROM value gets mapped to the VSH Value though, it might be +2 (somewhere hidden in the VSH code).

sandungas · Mar 7, 2022

And i figured another easy way to identify the arcade PS3 models used by namco (GECR-1100, GECR-1500, GECR-2500)
I like this last changes im doing because it works in the same way than the initial version, by checking 4 things: console_type, platform_id, product_code, and product_sub_code... and the initial version already had some code (partially disabled) because i was trying to identify the DEH-R (reference tool prototypes) and GECR (arcade)
So this last changes completes the support for that incomplete code
For the arcades im setting the console_type to "GECR" in the same switch where i was searching for regions by reading the "Product Code", this way:

Code:

    case 'A0':
        console_region_code = '00';
        console_region_name = 'Worldwide';
        console_type = 'GECR';

The console_series for some PS3 arcade models (values -11 and -15) requires an additional check in motherboards: COK-002 and VER-001 this way:

Code:

    case 'CokB10':
        board = 'COK-002';
        if (pscode[3] == 0xA0) {
            console_series = '-11'; // GECR-1100
            break;
        }
        switch (pscode[5]) {
            case '3': // CECHCxx
                console_series = 'C';
                break;
            case '4': // CECHExx
                console_series = 'E';
                break;
        }
        break;

Code:

    case 'CokF10': // CECHLxx or CECHMxx or CECHPxx or CECHQxx
        board = 'VER-001';
        if (pscode[3] == 0xA0) {
            console_series = '-15'; // GECR-1500
            break;
        }
        break;

And finally, that damned PS3 names that belongs to VER-001 motherboard and needs to be printed 4 times (for L,M, P, Q), im bypassing that "if" statement at the bottom this way:

Code:

else if (strcmp(hwinfo.platform_id, 'CokF10') == 0 && pscode[3] != 0xA0)
    // print PS3 model 4 times, with the console_series hardcoded to L, M, P, Q

And i added an specific "if" statement for them, this way the arcade PS3 model names are printed only 1 time, and without the console_storage (without the suffixes A/B/C)

Code:

else if (pscode[3] == 0xA0) {
    // print arcade PS3 models, without the console_storage suffix
    fprintf(fp, "PS3 Model Name: %s%s%s (%s)\n", console_type, console_series, console_region_code, console_region_name);
}

EDIT:
I updated the code with this changes, now is able to identify the Arcade "GECR-xx00" PS3 models

sandungas · Mar 7, 2022

I figured a way to simplify the code, im regreting of posting the previous versions so soon, but well, at least you can see how it evolved

The point is... i can use this same method for all the other console_types:

sandungas said:
For the arcades im setting the console_type to "GECR" in the same switch where i was searching for regions by reading the "Product Code", this way:

Code:

case 'A0': console_region_code = '00'; console_region_name = 'Worldwide'; console_type = 'GECR';

In previous versions i was doing this to identify the console_type, but im going to delete it:

Code:

switch (type) {
    case '1': // Retail
        console_type = 'CECH';
        break;
    case '2': // Debug
        console_type = 'DECH';
        break;
    case '3': // Tool
        console_type = 'DECR';
        break;
    default:
        console_type = 'UNKN';
}

And now im doing it this way in the checks to the "product code" (al the others are given the prefix "CECH"):

Code:

    case '81':
        console_type = 'DECR';
        console_region_code = '00';
        console_region_name = 'Worldwide';
        break;
    case '82':
        console_type = 'DECH';
        console_region_code = '00';
        console_region_name = 'Worldwide';
        break;
    case 'A0':
        console_type = 'GECR';
        console_region_code = '00';
        console_region_name = 'Worldwide';
        break;

So... the result is the same, only 4 posible values for console_type (CECH, DECR, DECH, GECR), but by deleting the switch (type) im removing the requirement of syscall 985. sys_dbg_get_console_type
The previous versions required 3 syscalls, used 3 switches and was checking 4 things (type, platform_id, product_code, and product_sub_code)
After this changes requires 2 syscalls, uses 2 switches, and checks 3 things (platform_id, product_code, and product_sub_code). I prefer it this way, more simple and more open to be reviewed by some of you

EDIT:
I updated the code sample with all the changes mentioned in my previous posts

sandungas · Mar 8, 2022

M4j0r said:
@sandungas
sys_dbg_get_console_type only returns 1/2/3.
To get the full target type you'd also need to get the VSH Target, it's probably available from a VSH Export or it's possible to read it from the Syscon EEPROM: https://www.psdevwiki.com/ps3/Promo_flags.txt . I don't know how the EEPROM value gets mapped to the VSH Value though, it might be +2 (somewhere hidden in the VSH code).

I was thinking in how to identify the DECH-Sxx00 (AV tool PS3 models) just because i consider them the next ones in the list of "most popular PS3 models"
Using the list in this page https://www.psdevwiki.com/ps3/Product_Code
The last revision of the code already supports CECH, DECH, DECR, DEH-R, GECR, thats a lot more than what i thought when i started writing it, i was not sure how much we could expand this PS3 model identification while keeping the code simple and following a simple logic
Overal im happy with the current state, is like the code base, intended to be accurate, but open to improvements

What you are suggesting would allow to identify the DECH-Sxx00 (AV tool PS3 models)
And additionally the dtcpipdevdex, but the PS3 model name is same than debug, right?, in this case it would be needed to display a new string somewhere (just to indicate that is labeled as an standard debug, but with dtcip features enabled)
Dunno... right now i dont have a clear view of how to find and display all this, i feel like the code is in a dont touch me state for me
It needs a more calmy review to see if there is some room for improvement or some mistake/flaw... either by some of you or eventually i will return to it, but by now i dont feel confident into increasing the complexity of it

EDIT:
Btw, when i was doing this i was keeping an eye at many wiki pages, im going to copy the list here incase someone is interested and as a self reminder
https://www.psdevwiki.com/ps3/Talk:SKU_Models
https://www.psdevwiki.com/ps3/SKU_Models_Nonretail#Prototype_model_names
https://www.psdevwiki.com/ps3/Chassis_ID
https://www.psdevwiki.com/ps3/IDPS
https://www.psdevwiki.com/ps3/Flash:Encrypted_Individual_Data_-_eEID
https://www.psdevwiki.com/ps3/LV2_Functions_and_Syscalls
https://www.psdevwiki.com/ps3/AIM_Manager#0x19004_-_Get_PS_Code
https://www.psdevwiki.com/ps3/Promo_flags.txt
https://www.psdevwiki.com/ps3/Platform_ID
https://www.psdevwiki.com/ps3/Product_Code
https://www.psdevwiki.com/ps3/Template:Minimum_Firmware_Version

sandungas · Mar 8, 2022

Ehhhmm, i figured a way to simplify the code a bit more, in the previous version i was using a "if else" statement at bottom specific to print the PS3 arcade models without the console_storage (the suffixes A/B/C) this way, but i just realized i can delete it

Code:

else if (pscode[3] == 0xA0) {
    // print arcade PS3 models, without the console_storage suffix
    fprintf(fp, "PS3 Model Name: %s%s%s (%s)\n", console_type, console_series, console_region_code, console_region_name);
}

And clean the console_storage for the arcade PS3 models this way:

Code:

    case 'A0':
        console_type = 'GECR';
        console_region_code = '00';
        console_region_name = 'Worldwide';
        console_storage = ' ';
        break;

And additionally im doing it here too for the debugs and the CEX2DEX conversions

Code:

    case '82':
        console_type = 'DECH';
        console_region_code = '00';
        console_region_name = 'Worldwide';
        console_storage = ' ';
        break;

EDIT:
I updated the code sample with this changes

bguerville · Mar 8, 2022

sandungas said:
Ehhhmm, i figured a way to simplify the code a bit more, in the previous version i was using a "if else" statement at bottom specific to print the PS3 arcade models without the console_storage (the suffixes A/B/C) this way, but i just realized i can delete it

Code:

else if (pscode[3] == 0xA0) { // print arcade PS3 models, without the console_storage suffix fprintf(fp, "PS3 Model Name: %s%s%s (%s)\n", console_type, console_series, console_region_code, console_region_name); }

And clean the console_storage for the arcade PS3 models this way:

Code:

case 'A0': console_type = 'GECR'; console_region_code = '00'; console_region_name = 'Worldwide'; console_storage = ' '; break;

And additionally im doing it here too for the debugs and the CEX2DEX conversions

Code:

case '82': console_type = 'DECH'; console_region_code = '00'; console_region_name = 'Worldwide'; console_storage = ' '; break;

EDIT:
I updated the code sample with this changes

So what's the status now sandy?
Would this cover all models correctly?
Can I add this algo to the Toolset "as is?

Keeping in mind that to support platforms other than CEX, I need a number of vsh offsets on versions 4.8x & iirc the 4.75 pup must be the latest DECR publicly available?
For DEX already we are missing some, we only have 4.80, 4.81, 4.82 & 4.84 as you know.
In the Toolset, the vsh offsets are only needed for multithreading ROP I could potentially make a number of modifications to restrict the Toolset features when VSH is unknown so that users could still get some info about their console but couldn't use any feature that requires multithreading. It would be a fair amount of work & I am not sure the practical outcome would outweigh the time investment.

Support for earlier firmwares like 4.7x isn't possible without buying a custom ssl certificate due to the limited selection of supported ssl certificates with each fw version. Currently free let's encrypt ssl certs are only supported from 4.80 up which is in fact an improvement because until a change of certificate authority in the free certs issuer was made last year, support originally began at 4.82.

sandungas · Mar 8, 2022

bguerville said:
So what's the status now sandy?
Would this cover all models correctly?
Can I add this algo to the Toolset "as is?

Keeping in mind that to support platforms other than CEX, I need a number of vsh offsets on versions 4.8x & iirc the 4.75 pup must be the latest DECR publicly available?
For DEX already we are missing some, we only have 4.80, 4.81, 4.82 & 4.84 as you know.
In the Toolset, the vsh offsets are only needed for multithreading ROP I could potentially make a number of modifications to restrict the Toolset features when VSH is unknown so that users could still get some info about their console but couldn't use any feature that requires multithreading. It would be a fair amount of work & I am not sure the practical outcome would outweigh the time investment.

Support for earlier firmwares like 4.7x isn't possible without buying a custom ssl certificate due to the limited selection of supported ssl certificates with each fw version. Currently free let's encrypt ssl certs are only supported from 4.80 up which is in fact an improvement because until a change of certificate authority in the free certs issuer was made last year, support originally began at 4.82.

Yes, i think is ready to use it "as is", maybe i did some syntax error and the compiler is going to complain about my noob coding skiils but other than that is able to identify all combinations of CECH (retail), DECH (debug), GECR (arcade), DECR (reference tool), and DEH-R (reference tool prototypes)

Im not doing any restriction by firmware versions or blacklisting combinations never used by sony, as example, it can identify a GECR-4300 (an arcade using the last superslim motherboard), or a DECH-4300 (debug with the last superslim motherboard, or an unnofficial CEX2DEX conversion), sony never did that but the code supports it because that theoretical PS3 models follows the same naming convention than the others that exists
So you decide how many to include, to remove the "reference tools" you need to delete the mentions to "Cyt" and "Deb01" from inside the switch (hwinfo.platform_id) and also the "if else" statements at bottom for "Cyt", and the case '81' from inside the switch (pscode[3])
The support for DECH (debug) is mostly because the CEX2DEX conversions, are not so rare, your screenshot made me realize about it, lol and i think is not worthy to remove it, are just a few lines
If you decide to do it and minimize it only to retail CECH you could delete also all the mentions to A0 and 0xA0 (specific for arcade PS3 models)

bguerville · Mar 9, 2022

sandungas said:
Yes, i think is ready to use it "as is", maybe i did some syntax error and the compiler is going to complain about my noob coding skiils but other than that is able to identify all combinations of CECH (retail), DECH (debug), GECR (arcade), DECR (reference tool), and DEH-R (reference tool prototypes)

Im not doing any restriction by firmware versions or blacklisting combinations never used by sony, as example, it can identify a GECR-4300 (an arcade using the last superslim motherboard), or a DECH-4300 (debug with the last superslim motherboard, or an unnofficial CEX2DEX conversion), sony never did that but the code supports it because that theoretical PS3 models follows the same naming convention than the others that exists
So you decide how many to include, to remove the "reference tools" you need to delete the mentions to "Cyt" and "Deb01" from inside the switch (hwinfo.platform_id) and also the "if else" statements at bottom for "Cyt", and the case '81' from inside the switch (pscode[3])
The support for DECH (debug) is mostly because the CEX2DEX conversions, are not so rare, your screenshot made me realize about it, lol and i think is not worthy to remove it, are just a few lines
If you decide to do it and minimize it only to retail CECH you could delete also all the mentions to A0 and 0xA0 (specific for arcade PS3 models)

OK then.
I might just add the whole thing.

bguerville · Mar 11, 2022

sandungas said:
Yes, i think is ready to use it "as is", maybe i did some syntax error and the compiler is going to complain about my noob coding skiils but other than that is able to identify all combinations of CECH (retail), DECH (debug), GECR (arcade), DECR (reference tool), and DEH-R (reference tool prototypes)

I just ported the whole code to js, overall it seems to work fine but I believe there is a mistake in the detection of converted CEX models.
I tested on a slim CECH-2504A (CokJ13) converted to DEX on Rebug.
The product code is 82 (instead of 85) & the sub code is B so of course the output of your algorithm is:

Code:

PS3 Model Name: DECH-2500 (Worldwide)

I think we need to add more data processing in the part of the code:

Code:

...
case '82':
  console_type = 'DECH';
  console_region_code = '00';
  console_region_name = 'Worldwide';
  console_storage = ' ';
  break;
...

But adding a check in here to ensure that the console is not a converted model would not even be sufficient, in your algo, the console_region_code variable cannot be set if the product code is not the original so I don't think pscode[3] will do for this.
If we cannot get the original product code from the ss_aim_manager syscall using service 0x19002, we may need to extract it from eid5 or something like that..????

sandungas · Mar 11, 2022

bguerville said:
I just ported the whole code to js, overall it seems to work fine but I believe there is a mistake in the detection of converted CEX models.
I tested on a slim CECH-2504A (CokJ13) converted to DEX on Rebug.
The product code is 82 (instead of 85) & the sub code is B so of course the output of your algorithm is:

Code:

PS3 Model Name: DECH-2500 (Worldwide)

I think we need to add more data processing in the part of the code:

Code:

... case '82': console_type = 'DECH'; console_region_code = '00'; console_region_name = 'Worldwide'; console_storage = ' '; break; ...

But adding a check in here to ensure that the console is not a converted model would not even be sufficient, in your algo, the console_region_code variable cannot be set if the product code is not the original so I don't think pscode[3] will do for this.
If we cannot get the original product code from the ss_aim_manager syscall using service 0x19002, we may need to extract it from eid5 or something like that..????

Hehe, you are getting hooked into improving it, nice

Yes, in the algorithm there is no room to indicate if is a CEX2DEX conversion, i guess it could be made by displaying 2 info lines:

Code:

PS3 Model Name (EID0): DECH-2500 (Worldwide)
PS3 Model Name (EID5): CECH-2504A/B (Europe)

And it would be needed to add a check to the EID5 inside the switches, i dont know how to do it

But there is another flaw related with the DECH and DECR PS3 models, check in this table, there are a bunch of PS3 model names
https://www.psdevwiki.com/ps3/Template:Console_Information
And eventually to this lists too to see how are labeled other "rare" PS3 models
https://www.psdevwiki.com/ps3/SKU_Models_Nonretail#Prototype_model_names

The problem is... the DECR and DECH PS3 models doesnt uses the suffix i named "console_storage"... i mean... they have 2 posible suffixes "A" or "J" but doesnt represents the storage capacity, the posible combinations should be displayed like this:

Code:

PS3 Model Name: DECR-1000A (America)
or...
PS3 Model Name: DECR-1000J (Japan)
or...
PS3 Model Name: DECR-1400A (America)
or...
PS3 Model Name: DECR-1400J (Japan)
or...
PS3 Model Name: DECHA00A (America)
or...
PS3 Model Name: DECHA00J (Japan)
or...
PS3 Model Name: DECH-2500A (America) <---yours, i guess, or the CEX2DEX conversions should be considered japan ?, dunno
or...
PS3 Model Name: DECH-2500J (Japan)

As you can see, in the wiki template with all the PS3 model names we are labeling them in a generic way, as example "DECH-2500A/B"... this means the sticker have either an A or a J (but not both) at the end of the PS3 model name
I was thinking to fix this just by doing this (same stuff for DECR), but you know... it looks dirty in the code because in this fix im repurposing a variable named "console_storage" to indicate the region

Code:

...
case '82':
  console_type = 'DECH';
  console_region_code = '00';
  console_region_name = 'America/Japan';
  console_storage = 'A/J';
  break;
...

But to be honest, i would like to do it better to indicate if is one or the other instead of displaying both A/J
In the retail PS3 slims happens something a bit similar, because the suffix indicates the hdd capacity (either A=small storage capacity or B=big storage capacity), this way your PS3 should be displayed like this (assuming you bought the PS3 bundle with the B=big hdd capacity)

Code:

PS3 Model Name (EID0): CECH-2504B (Europe)
PS3 Model Name (EID5): DECH-2500 (Worldwide)

Instead of this, where is not indicated the exact hdd storage capacity:

Code:

PS3 Model Name (EID0): CECH-2504A/B (Europe)
PS3 Model Name (EID5): DECH-2500 (Worldwide)

Yesterday i was taking a look at some syscon dumps trying to see if there is something in them that could indicate the hdd storage capcity of the PS3 slims and superslims but i could not find anything :/

Dunno, i need to take another look at the algorithm to see if there is some way to add more improvements without creating much chaos

bguerville · Mar 11, 2022

Ultimately the problem for me is not cex/dex conversion, I can tweak the code, get the product code from eid5 & use that instead of pscode[3] as the Toolset already extracts stuff from Flash Memory anyway.

What bothers me more at this stage is the inability to differentiate between cex phat models, using something like "it could be this model or it could be that model or... " is not ideal to display in the tree the "System Manager" tool uses, and no matter how you change the wording of it, it remains somewhat annoying. I was looking for a foolproof way to get the exact model for all CEX consoles at least.

Also I think we have to assume that some idps spoofing methods will mess with the entire algorithm & make model identification using product code & sub code unreliable.
Ideally we would need to integrate that possibility in the algo & detect those use cases where some extracted info might contradict other extracted info..

We may be able to overcome those complications however I cannot help but wonder whether it is pertinent to invest more time in this just to get a string written at the back of the console.

PS3 Release: PS3 Advanced Tools

Similar threads