PS3 DECR-1000a BDEmu HDD Data Recovery

[Undertaker]

New person here, hope this is an OK place to put this.
I have a DECR-1000a that I would like to attempt to run data recovery on the BDEmu HDD. However searching online there's barely any information on the console itself let alone the BDEmu specifically. I believe the BDEmu was wiped at some point since Target Manager won't mount anything from any of the partitions. I would like to try and open the drive up in probably Linux since that's probably the only thing that can really open UFS2 filesystems, however I'm not entirely sure how to go about doing that and also how to then run data recovery. I also don't know if this drive is encrypted by the eid_root_key or not. I did dump it just in case though. I also made a backup of the drive using HDDRawCopy so maybe I could just use the .img file instead of massacring the HDD. I did try a couple applications for Windows like ps3_hdd_reader but it kept throwing errors about the HDD not existing and hdd_decrypt was the same, kept saying could not find the .img file which makes zero sense but whatever. I imagine there wouldn't be NOTHING on the drive as that would be odd since it's literal only purpose in life is to be a development kit. Mainly I'd just like to get any and all possible data off of it in order to archive any development builds of any games. Any and all help would be appreciated!

 

[Berion]

Probably it is encrypted but I dunno, never put my fingers on it.

I hope your image is not *.imgc but *.img like you said. That custom compression adds extra difficult to deal of layer, making such dump nearly useless (because homebrew linux tool for decompression this custom LZO is not trustworthy in meaning of format supporting and cannot be used in pipe).

Also I have hope you didn't agree for Windows disk initialize. If you did, you overwritten partition table by MBR or GPT and data recovery from that becoming far way harder without knowing where partition(s) started. I did that for CEX/DEX models in PS3HDH but I know where they usually starting, in your case, it is terra incognita.

You can send me on PM yours ERK (how did you dump it BTW?) and sample of disk, lets say first 2MiB.

ERK not encrypting disk, but key(s) calculated from it. Just FYI.

 

[Undertaker]

Yeah I'm not entirely sure either. The image IS a .img though, and I did make sure not to do Windows's dumb initialization as I know that would wipe out the partition table. I was able to dump the ERK using the Rebug Toolbox, and ah ok, didn't know that it wasn't itself the encryption key, I'll be sure to remember that.

Edit: BTW I don't believe I can send you DM, I may be too new (or blind) as I can't seem to find any option to.

 

[Berion]

Ah yes, new users restrictions. I cannot send you PM either.

Well, that mini dump and key aren't contains any private info or copyright stuff, so you can share it here. Just cut the link from https/www to trick the bot. Mediafire recommended. Other way to catch me is Discord (eg PSX-Place, PS2Scene or PS2-Space).

PS: So the plan is usually that:

1. Making disk decrypted on the fly (if it is encrypted, and if we will be able to decrypt it in the first place).
2. Copying visible data from everywhere (visible means from mounted filesystems).
3. Making sector by sector copy of disk or partitions from decrypted mapper(s).
4. Feeding recovery software by image(s) from step 3 (there are some UFS recovery apps; for FAT family DMDE is very good, and less complex but still fine IsoBuster - all behind paywall of course).

But do not use PS3HDH on it yet anyway. I will make fully read only variants (actually I'm in the middle of reorganizing scripts but many PS2 stuff locked me in half baked state).

 

[Undertaker]

Got it, all good, I just post here. Hopefully the drive isn't just empty, that'd be a real let down haha. Although after I imaged it I did run R-Studio just to see if it would "see" anything and it said ~200GB of files found? But idk how much I trust that considering the drive is UFS2 file system plus the possibility of encryption. Anyway here's the files: mediafire.com/file/job7fo0ga7zfrqi/EID-HDD-DECR.zip/file

 

[Berion]

Thanks for the sample. Drive is not encrypted, at least not partition table if we can name that index kind we can see.
Probably it is format like: <partitions numbers> <start LBA of partitions>.

I found in my basement some tool, for windows, to deal with that disk (never tried, and I cannot guarantee is free from malware). But still I'm interested to add support in PS3HDH on Linux side. Could you check what you can found at that LBA (4304h = 17156d * 512d = sector 8783872)? Eventually larger sample like i.e 1GiB.

@aldostools Is that your application maybe? I remember you have add something like that in ps3tools. Do you have maybe source code?

Is that the same disk structure we talking about?
https://www.psdevwiki.com/ps3/BDemu_Drive_Format

 

[Undertaker]

I went to that offset you were talking about, nothing there really. I did open the full image file in HxD though to check it out, seems the whole image is practically empty except for nearly the very end where there's quite a bit of data. Also if I'm reading that site correctly that disk structure does seem to match. The SDK shows that you only get 4 partitions on the BDEmu HDD, (mount point 0-3) so there are 4 different spaces you can upload data to and then mount one at a time on the XMB. When I get some time later I'll try out that tool you linked.

 

[Berion]

Actually nothing matches to the dev wiki page. That's why I'm confused.

File offset is not the same as LBA. LBA is sector number (imagine slicing file to 512 byte chunks and numbering them). Also hexadecimal is not the same as decimal system. 8783872d = 860800h.

 

[Undertaker]

My fault, here's where you were talking about, still like nothing there though. Only place I found actual data is way far down near the end of the drive. Also guess I got confused based on file structure vs disc structure, was mainly looking at how to files are stored and it seemed like it matched how they're structured on the BD-ROM's. Not sure why it's so different though, I can promise you I touched nothing for disk management or anything else, just straight ripped the whole drive. Not sure if someone else messed with it before me before putting it back into the dev kit?

Edit: Tried the application you linked, doesn't show the HDD at all, maybe it's corrupt or someone before me messed it up somehow, if it'd be helpful I could do a quick format (not full) on the devkit and see what happens after

 

[Berion]

That's funny. 4304 points to place where there is 4304 (BigEndian). Maybe that's some control pattern used in factory formatting. But then, you should not see anything on disk but such kind of stuff from start to end. That's strange.

Of course, I don't assuming you lies/trolling or overwritten it in any way.

Also guess I got confused based on file structure vs disc structure, was mainly looking at how to files are stored and it seemed like it matched how they're structured on the BD-ROM's

What you have in mind exactly? Isn't drive is not recognizing as formatted by anything you tried (BDEmu/TargetManager, BdEmu Partitions Tool)?

Could you scan disk or image by IsoBuster? If any orphaned fs found, should be listed on left tree. Then we can see its LBA range occupying and even extract it. But I'm not sure if that functionality isn't behind paywall.

 

[Undertaker]

Started a scan for lost data with ISOBuster, since that's what it asked when I selected the drive, said it found no file system or anything else. To clear up confusion, I got some images of games other people had pulled off their drives and looked at the file structure. Seems they're all fully packaged Blu Ray ISO's that then get pushed onto the BDEmu in one of the partitions for mounting, not sure if it gives you an ISO back when you grab it back from the BDEmu but that's what I was basing it off of. Not sure if doing a quick format would be able to restore the filesystem for viewing then try using data recovery to get data back would work at all, would be interesting to try though. Ofc I could be way off base, I don't exactly have the best knowledge when it comes to HDD's and file structures, etc, only basic knowledge as I haven't super delved deep into it

 

[Berion]

If *.iso placed in fs or raw on any partition, even if not exist now, then still IsoBuster would found it as UDF. If not encrypted of course (disc image and/or disk, but as we know, disk is not encrypted).

Writing anything to disk, significantly lowering chance of data recovery. I don't understand from where that idea came from it, but would not help in anything. Never do that on any environment, not only PS3! In case of PS3 internal HDD, in use is custom partition table(s) and even UFS2 isn't the one used in FreeBSD nowadays; according to dev wiki also custom table for BDEmu. Sony loves obscure garbage since beginning (APA in PS2, MCFS in PS2, PSXMC etc.).

IMO, this disk is empty, at best contains some leftovers from deleted game.

Any insight on issue would be great. ^^ @aldostools @haxxxen

 

[Undertaker]

Oh no I didn't write to HDD, just looked at ISO's I grabbed from online but yeah you're right doesn't matter, just assumed for no reason. But yeah thinking the disk might just be empty. If you can use a normal 400GB drive for the BDEmu then I'll just save this drive for any data recovery if possible, otherwise if we can't get anything off of it then might as well just use it for development. I'll save the image I took ofc though, no reason to delete it