PS3 Problem with hdd of ps3

Till Harpax said:
My ps3 is eMMC ,and I have not started with GTP, because I did not know what a sector was.
Click to expand...

If HDD is equal or larger than 1TiB, Windows will write GPT instead of MBR. ;)

3141card said:
And the long line of zeros in the second screenshot, into a encryptet sector from the new formated HDD?
Click to expand...

I have also zeroes in first sectors, even plain text left from NTFS (?) in my CECHL04 HDD. It looks like not all is encrypted (but Your application works except reading dev_flash).
 
HDD_3.png
apparently removing the GPT partition using the DISKPART command does not work to fix the ps3's HDD.
@sandungas
Simply because of my disinformation I thought I could access the saved games of my games, through the HDD and since I did not appear in the file explorer of Windows I saw a video in which they made it recognize the disk through the "initialization" and finish using the GPT partition style.
Exactly the same as that of this image appeared to me.
 
There is no tool or application that can compare matches? my idea is to search within 4096 offset to the final offset where to where I have to patch the file
 
Obviously... this not "fix" Your PS3 HDD because You DELETED (overwrited) ps3 partition table (by Windows "initialization"). It will not help You writing any other partition table with anything in it. You permanently lost it and in that state, PS3 always be asking for format. Find someone with the same model, and ask to dump first 4MiB, then You can try cure for known HDD fs logics. Did You even made sector by sector copy of this device before You trying modify it?

Byte comparing is in all hex editors. For such task I prefer Hex Workshop (trial is sufficient) as have very clear view and easy "jump searchs".

You will NOT read PS3 HDD, even completely untouched (not broken) WITHOUT keys.

There is no secret knowledge or youtube troll tutorial kids who know something which we don't know. This is a math, and partitions are encrypted by long as f*ck unique per console keys.

I don't want to be rude but You doing everything to not restore content from this HDD. In every unsafe operation, You are more and more far away from the goal. ;)
 
Last edited:
Byte comparing is not useful in this case because at beginning all bytes are going to be different :)

In a hex editor you can make byte comparisons, but it takes your "cursor" to the next difference (and highlights 1 byte each time), so you are going to need to press "show me next difference" loooooooooooooot of times (several thousands) until the hexeditor tells you "there are not more differences"

Well... you can do it like that, but is better to just open both files side by side and scroll down both... is not so hard to see where both starts matching

*And make a screencapture to post in the forum


-----------
Well... hmmm
I guess you can make a byte comparison but starting at end of file/hdd.... and do the comparison in inverse direction
This should take you (with a single action) to the position where is the different area. And that position is near the beginning of the hdd so is needed to read everything "from bottom to top"

*If the hdd is very big... i guess this could take several minutes though... is needed to read both hdds/files completly (lot of GB) and compare them
 
Last edited:
@sandungas Comparing beginning of two PS3 HDD from this model and with other (not for recovery matters of course but to clarify there is new table position).
 
Yes, I made a backup sector by sector before modifying, the solution of copying the first 4 Mib does not work for me because the first 4 Mibs are literally the same, comparing the initialized partition versus the clean partition
 
Last edited:
or tell me @Berion you know some other tool that can back up a hard drive sector by sector (other than HDD RAW Copy because both the initialized copy and the corrupt copy are presumably equal to 0 to 4096 offset)
 
@Till Harpax CECH-3xxx are not fully hacked, so we don't know how encryption/decryption works on them (for CECHxyy and CECH-2xxx using different algos), we don't understand fully the partitions logic on PS3 HDD, and probably no one research it on "new" models. That's why You said is... intriguing. :) Normally, partition table is located at the beginning of the device, but who knows, maybe it is not on CECH-3xxx/4xxx. Could be anywhere, even at the end or at the beginning with some pregap (but in that case, PS3 would not complain about needed format...). It is hard to tell without CFW or Linux.

Sector by sector copy means, it's a dump data as is, without interpreting it and without packaging/compressing/whatever. We can assume that You did it correctly and that application did it correctly. On Windows I'm using MHDD (but I'm not sure if this tool is for You ;]), on Linux I prefer simple DD.

I hope we talking about comparing few first MiB of dumps from "broken" PS3 HDD and PS3 HDD freshly formatted on the same console with the same HDD. ;)
 
Last edited:
@Till Harpax
You can also use WinHex for make a backup. Open the HDD:

Tools --> Open Disk (or press F9) and open the HDD as Physical Media(real HDD, block device starting with sector 0)

go to the end of your HDD and double-click the last byte to select it(it will now be light blue)
go to the first byte of your HDD and duoble-click it.
Now all data on HDD are selected(light blue).

Right-click into the selected data, choose Edit --> Copy Block --> Into New File

Choose a folder, make a name and press save. The result is not different from what you get with dd under linux.

But I say it again, Iam sure your HDD is currently not fixable. Best chance is, let the damaged backup how it is
and hope in future is a way to get the keys from your type of PS3. Yes, its frustrating, but you had only encrypted
data, imposible to work with, it is a blind flight. It is not so easy like for old NAND/NOR PS3s, with only a single sector killed by windows.
 
Last edited:
I still have doubts if is fixable, but mostly because i dont know how many sectors are used by GPT (someone knows for sure, by personal experience of because you did read somewhere ?). We know he "initialized" it with GPT, but how many sectors was overwritten ?

And how this overritten sectors overlaps with the original PS3 data ?. Keep in mind the PS3 sometimes does some "gaps" with unused sectors just to align the positions of what comes next
Im sure 3141card know this well, but i dont know accuratelly how the beginning of the hdd is mapped

And i think he is making some mistake, because this is weird
Till Harpax said:
Yes, I made a backup sector by sector before modifying, the solution of copying the first 4 Mib does not work for me because the first 4 Mibs are literally the same, comparing the initialized partition versus the clean partition
Click to expand...
Till Harpax said:
or tell me @Berion you know some other tool that can back up a hard drive sector by sector (other than HDD RAW Copy because both the initialized copy and the corrupt copy are presumably equal to 0 to 4096 offset)
Click to expand...
Doesnt makes sense to be the same... should be different, the old one is the "corrupted" and the new one is the "repaired"

Are you sure you are doing the procedure as explained before ?
First you need to make a backup of the damaged hdd contents and store it in other hdd as hdd_backup.bin (or any other name you want), it seems you made this well
Then you connect the damaged hdd to the PS3... and format it in the PS3 ! (from recovery menu, or with the option in XMB)
And then... you take this hdd out of PS3... and connect it to PC... and use "open device" in the hexeditor to see his content

In that last step is when you can see the fresh formatted hdd connected to the PC (by "open device") and the damaged hdd data (by "open file": hdd_backup.bin) inside the hexeditor, in a dual view


---------------------
I know, is a "rare" PS3 model with eMMC flash... but i dont think the firmware is doing anything special with the partition table of the hdd
Most probably the trick they used was to "virtualize" devices with the hypervisor, in the same way they did when they "migrated" from NAND to NOR, most of the firmware is "flash type agnostic" (the firmware at lv2 doesnt cares much about the flash type, the device names, access paths, etc is the same for all flash types). The only one who cares about the flash type is the hypervisor to make the virtualization

Is just a blind shoot... but i think with eMMC is going to happen something similar
The hypervisor uses a "virtual" hdd inside eMMC... and there must be a "switch" somewhere where it tells if hdd is located in eMMC... or in SATA connector
But the content of that hdd (real or virtual) should be the same exactly (or this is my guess)
 
sandungas said:
I still have doubts if is fixable, but mostly because i dont know how many sectors are used by GPT (someone knows for sure, by personal experience of because you did read somewhere ?). We know he "initialized" it with GPT, but how many sectors was overwritten ?
Click to expand...

1024 sectors(0 to 1023) from the device start, thats a half MiB of lost data!!!
And 33 sectors from the end of device.

Also, the kind of data is importend too. It makes a big difference, whether the data are "constant" or "variable".
A PS3 partition table is 8 sectors in size, however, regarding the less count of regions only the first sector
contains data. This data are created at formating time and are never changed. To get this data back, in case
the first sector is killed, is easy. But a UFS superblock, a FAT, the allocated data from a filesystem, whatever...
thats variable data, it is modified over the time, again and again, even if it were only a timestamp for the last access.
Where such data are lost, then it is impossible to reconstruct them.
 
Ok, now i see why you insist that it cant be fixed, thats a lot more than the 8 sectors that can be restored by this method
 
In fact this morning I solved that HDD problem ,
And I realized that the copies I made were not in RAW format instead of that it was "compressed image" that's why the first 4 sectors looked the same,
upon noting that, restore the backup copy and check it with the hexadecimal editor and then make it a RAW copy, and then compare it with a clean version of the system and note that the first 4 sectors were different, then the corrupt copy was blank in the sector 32 to 34 while the clean copy does not, then note that from sector 34 to sector 319 were equal. In the end I found that the signature of the initialization was only at the beginning and end of the HDD.
 
Till Harpax said:
I want to thank all of you who took the trouble to comment in this post, regardless of whether your comment was useful or not, most of them were obviously useful
Click to expand...
The talk was very interesting anyway, im still brainstorming about it :)

Now you get used to all this procedures... can you upload a sample of the first 16 sectors of your hdd formated in a PS3 ?

The reason why im asking this is because your PS3 uses eMMC flash and is a bit special, not sure if someone checked what im going to explain

In a PS3 with NOR flash (most), sector 1 is the partition table of hdd then comes 7 "unused" sectors (to align the data that comes next), then sector 9 is another partition table for VFLASH... and again 7 "unused" sectors (to align the data that comes next)

So... for the record, what i said here is not exactly correct, in a PS3 with NOR flash can be recovered 16 sectors
sandungas said:
Ok, now i see why you insist that it cant be fixed, thats a lot more than the 8 sectors that can be restored by this method
Click to expand...

After that in sector 17... lot of sectors for VFLASH

Then another few "padding" sectors, and the huge main partition dev_hdd0

---------------------
In a PS3 with eMMC it should not exist the VFLASH inside hdd (unless sony was extremelly redundant)

So in your hdd at sector 9 you "should" have the start of filesystem of dev_hdd0 (maybe preceded by "up to 10" unused sectors, like the PS3 models with NOR ?)

For curiosity sake... check this table:
http://www.psdevwiki.com/ps3/Talk:Harddrive#HDD_partitions
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top