User talk:Zer0Tolerance

From PS3 Developer wiki
Revision as of 23:53, 29 December 2022 by Zecoxao (talk | contribs) (→‎Mike's WriteUp)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

thanks :) Euss

User:Zer0Tolerance under observation because of posting strong SEXual content ;) - (User:Roxanne 17th December 2015 / 16:19 GMT+1)

Good joke, thanks. (User:Zer0Tolerance 17th December 2015 / 18:51 GMT+1)

About eid2 des iv[edit source]

just a quick heads up. both eid2 des ivs (the zeroed one and the other one) are valid to use. in a way, both glevand (zero iv) and naehrwert (fixed iv) are correct. make sure you consult with naehrwert for more info.


@zecoxao Just use openssl des-cbc -d -in pblock.desenc -out pblock.dec -nosalt -K 6CCAB35405FA562C -iv 989A955EFDE7A748 -p -nopad and openssl des-cbc -d -in pblock.desenc -out pblock.dec -nosalt -K 6CCAB35405FA562C -iv 0 -p -nopad Only the second one vector is valid. Thank You.


it's very rare to see naehrwert wrong. maybe the algorithm is handled differently in libeeid(polarssl) than in openssl? i'll talk to him when i have a chance ;) either way, thanks :)


Im sorry, but iv must be zero. :(


I'm almost sure i was able to decrypt default.spp

please check all 3.15 key combinations possible.

Thanks :)


Im checked it and could not decrypt metainfo into default spp, please provide me the decrypted metainfo as proof.


Unfortunately i don't have it anymore. but i'll try to decrypt it anyways :)


Please recheck (retry) it if possible. Im sure that we needed another key(set) to decrypt default.spp for ceb.


yes, you're correct. just tested other combinations and none of them work.

About EID0_0_UNK1[edit source]


Pretty sure it's z1 and z2 (2 hashes). looks like it's a metadata of sorts :)


Maybe, maybe not. hash algorithm is unknown yet.


Have you tried checking if it's a pub from another curve?


Pub is a point with X and Y. One Pub for one Priv. These "hashes" are not constants. So this is not a Pub. It can be two hmac-sha1 or something. IDK what is this.

EEPROM Syscon Probing[edit source]

  • some useful links: (bus pirate) (logic analyzer)

  • Analyzer settings:

  • Bus pirate settings:

  • More info:

  • Write Unlock command:

0xA3 0x00 0x00

  • Write command:

0xA4 0xXX 0xXX (XX XX is block id)

  • Read command:

0xA8 0xXX 0xXX (XX XX is block id)

  • Check Status command:

0xA9 0x00 0x00 0x00

  • Some proof!hssQHZhI!bNMS3MgWx21iUrfLGBSoB2bA3Mfe3DVL23y_SENzDUw!wl8wSCKK!ZZkgeKd8hdRCMRpA2oWrrV5lirjupF_4k9boJkBpBfM

you need

dump of eeprom with above data

Thank you for puppies[edit source]

Mike's WriteUp[edit source]

when you have time come talk with me on discord about

thanks, zecoxao

Also, you're needed on telegram. thanks

Help with VSH exports related with RCO[edit source]

Not sure if you took a look at this table Talk:RCOXML_Objects#WidgetType, i made it thanks to your research with VSH_Exports#paf, but im having a problem, by looking at RCO stuff i think there are a couple of vsh exports missing in your list, not sure how you are getting them (reversing the hash from nids i guess), i know the codenames of some rco stuff so i can imagine the vsh export names that should have, please take a look if this ones exists

  • paf::PhPlaneDiv::WidgetType(void)
  • paf::PhPrim::WidgetType(void)

I am using a FNID_Validator, this tool just calculates a hash from function name, i guessing function name and verifying hash. I also using fnid_bruteforcer to bruteforce a few chars at the tail of function name.
You found correct function name, just mangled it and validated:
_ZN3paf10PhPlaneDiv10WidgetTypeEv FNID is 0xE36C18F5
I also tryed to find second one, but no luck.
Thanks a lot.

Nice, and this one ? (i think im missing one or two more, is mostly a blind shoot trying to imagine the names)

  • paf::PhLabelButton::WidgetType(void)

paf::PhLabelButton::WidgetType(void) not found on vsh exports :(

Ok, one last question, im wondering if there is some typo here, at bottom of VSH_Exports#paf table... this is normal ? (2 different NIDs returning the same object name)

Export NID Notes Usage
0xCA9160F6 returns "PhNumSpin" const char* paf_CA9160F6()
0x59A11C82 returns "PhNumSpin" const char* paf_59A11C82()

Why not? Asm code is same for both functions, so there are 2 same functions with different names.

Ok, it was another blind shoot, just because at bottom of paf table you have a group of NIDs that returns 24 object names, and in my table i have only 23, the difference of 1 is because the "PhNumSpin" is repeated in the paf table... i was wondering if it could be a typo and it was "hiding" a new unknown object name (to ask you later to search for paf::PhUnknown::WidgetType(void)), but i guess that was too much speculation, heheh, if at some point i imagine better names for the ones im missing (not sure if im missing some of how much though) i will tell, but by now thats all, thx

There is a table of "widgets"
1) paf::PhWidget::WidgetType(void)
2) "PhCamera" there is a function without export/import, so I can not validate func name by hash
3) paf::PhScene::WidgetType(void)
4) paf::PhPlane::WidgetType(void)
5) paf::PhPlaneDiv::WidgetType(void)
6) paf::PhButton::WidgetType(void)
7) "PhOskButton" simillar to case 2 - function without export/import
8) paf::PhText::WidgetType(void)
9) paf::PhScroll::WidgetType(void)
10) paf::PhLabelPrim::WidgetType(void)
11) paf::PhLevelMeter::WidgetType(void)
12) paf::PhProgress::WidgetType(void)
13) paf::PhCheckBox::WidgetType(void)
14) paf::PhXmBar::WidgetType(void)
15) paf::PhXmList::WidgetType(void)
16) paf::PhXmItem::WidgetType(void)
17) "PhSpin" simillar to case 2 - function without export/import
18) paf::PhItemSpin::WidgetType(void)
19) paf::PhNumSpin::WidgetType(void)
20) paf::PhList::WidgetType(void)
21) paf::PhInfoList::WidgetType(void)
22) paf::PhMenuList::WidgetType(void)
23) paf::PhCheckBoxList::WidgetType(void)
24) paf::PhLabelText::WidgetType(void)
25) "PhLabelPrimDiv" simillar to case 2 - function without export/import
26) paf::PhClock::WidgetType(void)
27) paf::PhIPAddr::WidgetType(void)

Nice, with 4 more the numbers starts matching, by RCO format specificatios there are up to 0x1F Template:RCO_TOC_entry_types, i did not expect for all them to have exports so is nice you got this new 4 names (rcomage and me in wikipages has been named them "objects" but im starting having doubts about that naming convention). I noticed a group that doesnt have exports is all the objects named "items" by rcomage. By looking at that template it can be seen the chronologicall order where was implemented by sony programmers, the first ones are the constructors for the main "xrossmediabar", and every time where appears a "list" it comes an "item" inmediatly after. Other than this "items" there could be more without exports but are not going to be much (maybe 1 or 2)

Well, instead of brainstorming here im going to update that table at Talk:RCOXML_Objects#WidgetType. initially was just some dirty notes to help me in the research but is becoming something important and i guess eventually could be moved from talk to frontpage


Not found :(

  • And this ones ?... seems to be used as counters and indicates how many "items" childrens there are under the "lists" (this ones are to "Set", i guess there could be others more to "Get"):
    • paf::PhXmBar::SetItemNum(int)
    • paf::PhMenuList::SetItemNum(int)
    • paf::PhCheckBoxList::SetItemNum(int)
    • paf::PhLabelPrim::SetItemNum(int)

Not found

Thanks, good to know anyway, now i "just" need to imagine why some "list" has vsh exports to "SetItemNum" but others doesnt. I guess there must be a good reason for it but right now i cant imagine why, i was not expecting to unlock the triple "not found" combo, but it seems im in a strike :'(