you won't get anything on the screen from the syscon log dumper. You need to have a fat32 USB drive connected to the PS3, then run the dumper.
It should run and go to XMB, nothing on the screen. Next if you check the USB drive, you'll find the log file.
This post is not exactly on topic but it is somewhat related & I thought people interested in the ps3 advanced tools might also be interested by this development.
As esc0rtd3w lost a member of his family & he always takes care of all the testing, the work on the new HEN installer project has been put on hold temporarily.
I decided to use the time to work on the PS3 Toolset, as I still have the new file manager tool to finish & a handful of new features to add to existing tools.
For those interested in getting syscon error logs as well as all the data dumped by M4j0r's tool from OFW 4.8x, I am currently adding the feature to the Toolset.
Things may yet evolve but this is how it looks like at the moment.
Next I will try to add the active ROS detection, if it works as I hope, I will change the patching method ie patch CoreOS only in the active ROS, leave the other ROS untouched. And I might add a way to detect the firmware installed in each ros, at least for OFW/HFW 4.8x.
If any of you guys have a request for extra data you would like to be able to get with the System Manager (ex FMM), feel free to suggest while I am working on this tool.
If any of you guys have a request for extra data you would like to be able to get with the System Manager (ex FMM), feel free to suggest while I am working on this tool.
@bucanero@M4j0r
For the errors log, would you guys know why I seem to get UTC time based dates when using your syscon log dumper (which relies on ctime calls to convert time_t to string) while I get UTC+2 (ie local time) when making the same ctime calls through the libc vsh export from ROP in the browser?
What do you think is best anyway for users?
Keeping everything in UTC?
Or using local times?
Either way maybe I should add UTC/UTC+X for the sake of clarity?
@bucanero@M4j0r
For the errors log, would you guys know why I seem to get UTC time based dates when using your syscon log dumper (which relies on ctime calls to convert time_t to string) while I get UTC+2 (ie local time) when making the same ctime calls through the libc vsh export from ROP in the browser?
What do you think is best anyway for users?
Keeping everything in UTC?
Or using local times?
Either way maybe I should add UTC/UTC+X for the sake of clarity?
Syscon uses UTC only, well the weird variant without the offset. I guess it doesn't really matter much since the relative order is more important and that won't change.
Syscon uses UTC only, well the weird variant without the offset. I guess it doesn't really matter much since the relative order is more important and that won't change.
I see.
Using UTC might be more coherent then.
But I am guessing that won't work with the ctime vsh export, at least not without some extra fiddling on the original values, maybe through a tm conversion?
Unless I use js to get both current UTC & local times to work out the appropriate correction to apply to time_t values before they are passed to ctime?
Damn, more work... Lol
This post is not exactly on topic but it is somewhat related & I thought people interested in the ps3 advanced tools might also be interested by this development.
As esc0rtd3w lost a member of his family & he always takes care of all the testing, the work on the new HEN installer project has been put on hold temporarily.
I decided to use the time to work on the PS3 Toolset, as I still have the new file manager tool to finish & a handful of new features to add to existing tools.
For those interested in getting syscon error logs as well as all the data dumped by M4j0r's tool from OFW 4.8x, I am currently adding the feature to the Toolset.
Things may yet evolve but this is how it looks like at the moment.
Next I will try to add the active ROS detection, if it works as I hope, I will change the patching method ie patch CoreOS only in the active ROS, leave the other ROS untouched. And I might add a way to detect the firmware installed in each ros, at least for OFW/HFW 4.8x.
If any of you guys have a request for extra data you would like to be able to get with the System Manager (ex FMM), feel free to suggest while I am working on this tool.
By now is not posible to identify the name of superslims motherboards, we know the complete list of Platform IDs for them, but we are not sure which motherboard is the "owner" of each
As mentioned here the superslim Platform IDs depends of the flash type... so in the meantime i would suggest to add another line under "System Info" with the "Flash Type" (where the only posible values are NAND, NOR or eMMC)... just to make more obvious to newcomers that the "Flash Type" needs to be reported together with the "Platform ID" and the "Product Sub Code" to help us complete that tables in wiki
And... if at some point we complete the list with the superslim Platform IDs in wiki you could show another line under "System Info" with the "Motherboard Name" by a direct conversion of the Platform ID
As example... in your screenshot that is showing Platform ID = CokJ13 you could add another line with "Motherboard Name = JTP-001"... right now you could do it with fat and slims motherboards (platform IDs from Cok14 up to CokK10)... but we cant do it with superslim motherboards yet
By now is not posible to identify the name of superslims motherboards, we know the complete list of Platform IDs for them, but we are not sure which motherboard is the "owner" of each
As mentioned here the superslim Platform IDs depends of the flash type... so in the meantime i would suggest to add another line under "System Info" with the "Flash Type" (where the only posible values are NAND, NOR or eMMC)... just to make more obvious to newcomers that the "Flash Type" needs to be reported together with the "Platform ID" and the "Product Sub Code" to help us complete that tables in wiki
And... if at some point we complete the list with the superslim Platform IDs in wiki you could show another line under "System Info" with the "Motherboard Name" by a direct conversion of the Platform ID
As example... in your screenshot that is showing Platform ID = CokJ13 you could add another line with "Motherboard Name = JTP-001"... right now you could do it with fat and slims motherboards (platform IDs from Cok14 up to CokK10)... but we cant do it with superslim motherboards yet
I am good with that but maybe I should wait to add the motherboard type until that correspondance list between platform id & motherboard type is completed.
In the meantime, I suppose you can gather ss from superslim users along with the sku models, that should be enough to finish the list, shouldn't it?
How many correspondances are still unknown as far as you can make out?
I am currently looking at extracting more data from syscon, stuff like flags/tokens that can be retrieved from OFW userland, anything that may be useful.
I might also add a boot to recovery mode feature..
@bucanero
I added the "save info to file" feature with a dialog to select the fs destination as requested.
It saves all the system information data from tree + the sha256 hashes of the 2 ros regions.
Btw the errors log dates are now in UTC.
I solved the issue by removing the ctime export calls altogether & using the syscon returned time values (number of elapsed seconds since 2000), converting them to the number of milliseconds since 1970 in order to create javascript date objects, it is now js objects that output the error date strings through toUTCString().
I am currently looking at extracting more data from syscon, stuff like flags/tokens that can be retrieved from OFW userland, anything that may be useful.
The QA token is stored in a protected area as far i remember, not sure if it can be retrieved with syscalls
Btw, there is a way to unlock a higher level syscon access from gameOS, to achieve it is needed to aplpy a patch to unlock one of the non-retail services... i dont remember right now, but m4j0r and me was talking about it in the syscon thread some months ago, he mentioned the literal names
Is one of the steps required to overwrite the "thermal config" region from gameos (thats the reason why i was asking about it, heheh)
No, is a bit an egg-chicken problem, to complete the list of Platform ID we need the PS3 model name, the flash type (NOR or eMMC), and the motherboard name
The PS3 model name can be readed from the case sticker, and the flash type is easy to find, it can be seen in XMB and the PS3 owner should know about it, but the motherboard name needs to be checked visually... in other words, is needed to open the PS3 to read it from the texts "printed" in the motherboard
Lets say... incase someone reports an undocumented platform ID + flash type (but not the motherboard name) the only thing we can do is to try to deduce the motherboard name, but at this point we should not make much deductions like that, what sony did was weird and extremelly confusing, im still keeping open mind because they did it 3 times (CECH-40xx series, CECH-42xx series, and CECH-43xx series), in CECH-43xx series it looks more striaghtforward but in CECH-42xx and CECH-40xx im not so sure
There are 16 Platform ID reserved for superslims (take a look at the list while reading this)
2 very rare (CokN20, CokN40)
1 rare (CokM40)
7 common, confirmed (CokM20, CokM30, CokN10, CokP40, CokP10, CokR30, cokR40)
6 common, unconfirmed (CokM10, CokN30, CokP20, CokP30, CokR10, CokR20)
The CokN20, CokN40 doesnt seems to be used in retail production, so most probably we will never find them
The CokM40 is doubtful, personally i think it was used in retail production but they only produced few units
The 6 unconfirmed was used in retail production (we are sure about it, so are common)
I am good with that but maybe I should wait to add the motherboard type until that correspondance list between platform id & motherboard type is completed.
We have been waiting years to complete the list of platform IDs, i been talking about it latelly but by now we are still stucked at the same point we was some months ago, and im a bit pesimistic about it, i dont expect much progress unless we do something to promote people in completing that damn list for once
Right now i dont have anything more to do in wiki related with this (i dont see any way to improve the info we have) and i dont want to add more speculation, because the current speculation have a big probability to be right... lets say... following the scientifical procedures... we have a theory and needs to be either confirmed or debunked
If the next reports confirms some of the details we mentioned then nice... otherway we are going to need to step back and return to the brainstormings, lol
---------
Anyway... from a practical point of view (other than completionism, thats another factor, lol), there are 2 main reasons why im so interested in completing that list with the Platform IDs
In wiki there are tenths (probably hundreds) of pages where we need to show a list of things (hardware components, and sometimes software too), and we do it using a table, where the 2 columns most at left are "PS3 Model name" and "Motherboard Name"
In superslims we dont know which "PS3 model" is the owner of each "motherboard name", and as a consequence there are many tables in wiki that have the columns "PS3 Model name" and "Motherboard Name" filled with question marks... is mostly because we dont want to risk in making any assumption, we need a good proof before udating all that tables
The other reason is because traditionally the way to identify by software the "PS3 Model name" and "Motherboard Name" has been by checking the "Product Sub Code" (from IDPS), there are many homebrews that does it this way, but thats not enought
Is needed to check both, the "Product Sub Code" and the "Platform ID"
Just to show you some special cases...
By looking only at the Product Sub Code you are going to see the 2 posible motherboard models used in CECH-25xx (JTP-001 or JSD-001) are shaing the same Product Sub Code = 0x0B. To identify this motherboard models is needed to check the Platform ID
CECH-25xx/JTP-001 = CokJ13 (platform ID) = 0x0B (Product sub code)
CECH-25xx/JSD-001 = CokJ20 (platform ID) = 0x0B (Product sub code)
The same stuff happens in between DEB-001 motherboard (used by fat DECR-1400) and DYN-001 motherboard (used by slim CECH-20xx), both are sharing Product Sub Code = 0x09. But by looking at the Platform ID we can identify them:
CECH-20xx/DYN-001 = CokG11 (platform ID) = 0x09 (Product sub code)
DECR-1400/DEB-001 = Deb01 (platform ID) = 0x09 (Product sub code)
If you take a look only at the Platform ID of COK-001 motherboard you dont know if the PS3 model is CECHAxx or CECHBxx.... but you can find it by looking at the Product Sub Code
CECHAxx/COK-001 = Cok14 (platform ID) = 0x01 (product sub code)
CECHBxx/COK-001 = Cok14 (platform ID) = 0x02 (product sub code)
CECHCxx/COK-002 = CokB10 (platform ID) = 0x03 (product sub code)
CECHExx/COK-002 = CokB10 (platform ID) = 0x04 (product sub code)
Basically... the platform ID of cookie motherboards can be used as a unique identifyer of the motherboard model, so it needs to be checked first
The only exception to this rule is one of the COK-001 prototypes named DEH-H1000A-E that is sharing platform ID = Cok14 with the retail COK-001 but this is not really a problem, and it makes sense
And after that the "PS3 model" can be deduced directly... or... (if platform ID = Cok14 or CokB10) with the help of the "Product Sub Code"
The only exception are CECHJxx/CECHKxx... and... CECHLxx, CECHMxx, CECHPxx, CECHQxx,
I think you could add it to your tool, for PS3 fats and slims is very accurate, the only flaw is what i mentioned about PS3 fat models with suffix J/K ...and... L/M/P/Q (in other words... if Platform ID = CokE10 or CokF10) that are sharing this identifyers so we cant tell the exact "PS3 Model", but as far i know there is no way to difference them by software so there is not much hope to find a better identification method in the future
And for superslims... well by now you could display a text with
Motherboard: Unknown (please check it and report)
Motherboard: MMX-001 (needs confirmation)
Or... dont display that line at all by now... if you have the functions ready it will be easy to add the motherboard names later after we complete the list of Platform IDs
My previous post was like a recap about the best way (in my oppinion) to find the "PS3 model" and "Motherboard model". It works with fats and slims, and it will work fine with superslims too, but i forgot about one more detail, im going to mention it for the record
After checking the "Product sub code", you can check the "Product code" to add the last 2 digits of the "PS3 model"
Just to show an example checking the 3 IDs (a PS3 from brazil region) : Platform ID = CokB10, Product sub code = 0x04, Product code = 0x8F-------> PS3 Model = CECHE14, Motherboard = COK-002
*additionally, in the superslims with eMMC flash you can add the suffix "A" at the end of the "PS3 model" name (smallest storage capacity)
*sadly we cant difference the "B" from "C" at the end of the superslims "PS3 model" names (medium and large storage capacity... in other words... HDDs... and NOR flash), so you can display them as "B/C"
I have added above tool to be recognized by PS3AT. Didn't test, but should work if it is sufficient to just rename "EBOOT.BIN" into "tool.self". ;p Unpack archive into folder with the same name and put it under "/TOOLS" in $appdir or pendrive.
I compiled a self file of HDD Unlock for anyone wanting to add it to the toolset (made with default make_self from PSL1GHT instead of scetool). Haven't tested it, so it may not work.
I have been fiddling with the update manager syscall aiming to read/write to syscon this afternoon.
The wiki data organised in offset tables supposedly describes which offsets are accessible & which are not but the way the data is presented, it is unclear to me. I think it should be more explicit..
I decided to check the Rebug Toolbox source & found it makes 3 different update manager syscall calls fself flag, recover mode flag or product mode so I reused them to write equivalent code in ROP for testing purposes. I expected this to go smoothly but it didn't so I am seeking clarification.
I did all my tests from Rebug REX CFW 4.84 on slim 25xx.
I keep getting an error (0x80010509? something like that, I checked, that error means bad argument) when trying to read the OS bank indicator (active ROS).
I am getting no error when reading fself flag, recover mode flag or product mode.
However I keep getting 0 for the returned value in each case, not sure they should all 3 be 0 though?
So to be sure I used the syscall to write 0xFF to the recover mode flag, it returned no error, so far so good I thought but then I proceeded to read the value & it still returned 0. Hmmm...
So I rebooted & the console booted directly to a system software reinstallation screen which was not at all what I would have liked but which could imply that something was written by the update manager syscall?
So anyway, before I begin to reverse code to try to find answers & make a self to test this stuff more easily, I thought to ask you about it as you might just already have the answers I seek.
Do you know what syscon offsets are accessible from OFW?
Or help me understand the wiki tables?
I would assume there is a table of accessible offsets somewhere in the system. In lv1?
Do you know what syscon offsets are accessible from OFW?
Or help me understand the wiki tables?
I would assume there is a table of accessible offsets somewhere in the system. In lv1?
There's a whitelist both in update manager (update_manager::read_eprom) and sc manager (read_eprom). There're also different ones for write operations.
For the "full" access you need the dispatcher manager patch and the following sc manager/update manager patches:
Code:
// 4.84 REBUG D-REX Offset Original Value Patched Value
u64 patches[7][3] = {{0xFC4DC , 0x419D005438000001, 0x6000000038000001}, // UM allow all EEPROM offsets (read)
{0xFEA38 , 0x419D02B438000001, 0x6000000038000001}, // UM allow all EEPROM offsets (write)
{0xFEBDC , 0x409E00107FC3F378, 0x600000007FC3F378}, // UM allow non-secure product mode overwrite
{0xBA17C , 0x409D00743D2BFFFC, 0x4800003C3D2BFFFC}, // SCM allow all EEPROM offsets (write)
{0xBA458 , 0x409D00743D2BFFFC, 0x4800003C3D2BFFFC}}; // SCM allow all EEPROM offsets (read)
There's a whitelist both in update manager (update_manager::read_eprom) and sc manager (read_eprom). There're also different ones for write operations.
For the "full" access you need the dispatcher manager patch and the following sc manager/update manager patches:
Code:
// 4.84 REBUG D-REX Offset Original Value Patched Value
u64 patches[7][3] = {{0xFC4DC , 0x419D005438000001, 0x6000000038000001}, // UM allow all EEPROM offsets (read)
{0xFEA38 , 0x419D02B438000001, 0x6000000038000001}, // UM allow all EEPROM offsets (write)
{0xFEBDC , 0x409E00107FC3F378, 0x600000007FC3F378}, // UM allow non-secure product mode overwrite
{0xBA17C , 0x409D00743D2BFFFC, 0x4800003C3D2BFFFC}, // SCM allow all EEPROM offsets (write)
{0xBA458 , 0x409D00743D2BFFFC, 0x4800003C3D2BFFFC}}; // SCM allow all EEPROM offsets (read)
Thanks.
So without lv1 exploit, there is no hope of getting any data in range 0x48C00 - 0x48CFF at all?
I was under the impression that certain of those offsets could be read without patching UM while others could not...
But if it is not the case, it means I can definitely forget about identifying/changing the active ROS region on NOR in the PS3 Toolset.
syscall 863 can use update manager to read and write to syscon from gameos
if dispatch manager is not patched in lv1 the syscall will return error 80010505
syscall 863 can use update manager to read and write to syscon from gameos
if dispatch manager is not patched in lv1 the syscall will return error 80010505
Thanks.
So without lv1 exploit, there is no hope of getting any data in range 0x48C00 - 0x48CFF at all?
I was under the impression that certain of those offsets could be read without patching UM while others could not...
But if it is not the case, it means I can definitely forget about identifying/changing the active ROS region on NOR in the PS3 Toolset.
However there is no mention of the requirements to get each of those offsets.
Some should be accessible through the UM syscall without patches? others with UM patches? the rest with DM patches? The need for patches is mentioned elsewhere on that page but I found the whole thing very ambiguous, so much so that I ended up posting here to get clarifications from M4j0r.
Come to think of it, the UM 0x600C service (syscon write) description is also a little ambiguous.
0x600C - Write EEPROM[edit]
Writting to EEPROM of Update Manager is also possible through DM
Basically this text was written with the assumption that all necessary patches are applied & you can dump what you want, which is fair enough but somewhat misleading for devs looking to use UM to peek a specific syscon offset & seeking the necessary info from this wiki page.
@sandungas
You are more familiar than most with the wiki, what do you think?
If we don't have the offset/patch data to complete the tables, should we not at least clarify the situation?
