search

kakaroto / ps3xport

PS3 Backup Manipulation Tool
GNU General Public License v3.0
108 stars 34 forks source link

Artificial backups with modified encrypted archives are impossible to restore; Read-Write Permissions of artificial backups are incorrect #9

Open christorrella opened 9 years ago

christorrella commented 9 years ago

When the PS3 creates a backup, certain files are given certain permissions to define which usergroups(?) on the system can edit the files. When ps3xport dumps the same backup and re-compiles it in an "artifical" backup, the usergroups are all changed so that only the first one has read-write access. Also, I do believe there is something wrong with the encryption of files added back into the backup. This is the root problem in restoring any backup dumped and re-compiled in ps3xport; every time, you will receive an error at 99% restoration on the PS3 (80010037). This will result in a forced format of the hard drive (yikes!) I think that decrypting an archive_XX without actually DUMPING it into the computer's filesystem is the best way to go right now, because this (hopefully) will not change the file permissions that the PS3 has set for specific files. I will check up on this soon. Edit: I don't think there's an "encrypt archive_XX.dat" command, but I could be wrong. Edit 2: I tried simply adding a file to the original archive without dumping the filesystem of the backup and still got an error. Had to reformat the PS3. Something is still wrong somewhere else in the PS3' reading of the artificial backup, and ot looks like it's regardless of the file permissions, although the file permissions changing could still be an issue.

My suggestions for a fix, any of you devs out there?

christorrella commented 9 years ago

Something really strange is that after adding a protected directory/file, trying to extract the file right after results in a bundle of jumbled data. MY guess is that when you add an encrypted file to archive_2, the encryption of the file isn't correct. However, delecting the file from the encrypted archive (if it exists) and adding it to the unprotected archive is just fine. I successfully edited a file from archive2, deleting it, and reinstalled it into the unencrypted archive.Dat proved successful. I am able to to this and restore the backup on the PS3 with no errors.

DieKatzchen commented 9 years ago

Are you saying that extracting, say, /home from the backup, deleting it from the encrypted portion and adding it to the unencrypted portion results in proper file permissions and a working backup? Or is it just possible to restore it but the permissions are wrong?

christorrella commented 9 years ago

I believe that it works for files that have r/w permission by default. On Jan 12, 2015 12:14 AM, "DieKatzchen" notifications@github.com wrote:

Are you saying that extracting, say, /home from the backup, deleting it from the encrypted portion and adding it to the unencrypted portion results in proper file permissions and a working backup? Or is it just possible to restore it but the permissions are wrong?

Reply to this email directly or view it on GitHub https://github.com/kakaroto/ps3xport/issues/9#issuecomment-69530699.

DieKatzchen commented 9 years ago

I can confirm that extracting /home , deleting it from the archive, and then adding it to the unencrypted backup allows you to restore copy protected save files to a different ps3, which is what I care about. How would I check if the permissions are messed up?

christorrella commented 9 years ago

Check the original partition information from the original index with the newly ps3xport-modified index to see if the first colum (rw, etc) has changed On Jan 14, 2015 1:40 PM, "DieKatzchen" notifications@github.com wrote:

I can confirm that extracting /home , deleting it from the archive, and then adding it to the unencrypted backup allows you to restore copy protected save files to a different ps3, which is what I care about. How would I check if the permissions are messed up?

Reply to this email directly or view it on GitHub https://github.com/kakaroto/ps3xport/issues/9#issuecomment-69967283.

DieKatzchen commented 9 years ago

So I checked the permissions and everything is 600 despite being originally a mix of 600, 604, and 666. It's hard to say who it's assigning as owner of any of the files either. I'm going to try in Linux as soon as my fiancee relinquishes the computer with Ubuntu on it. Maybe it's just Windows mucking up the permissions.

DieKatzchen commented 9 years ago

In Linux everything extracted has permissions 664. I created a test file with permission 654, created a new archive, and then read the archive.dat and it had been given permission 600. So it seems it gives all extracted files 664, and any files added to an archive it gives 600. It seems to give ownership of all extracted files to whoever ran ps3xport, and I don't know how it assigns ownership to archived files since ReadIndex says nothing about ownership. I'm not sure how to appropriately deal with ownership either, since if it preserved ownership you would need to elevate yourself to root to do anything with the data. I think the virtual filesystem reader would be best. Beyond my skill, though.

christorrella commented 9 years ago

Yeah half of the things you just said are waaay over my head. But it's good to see that more than one person is having issues with this ownership dealything. Can't wait until somebody steps up to that plate... I'd honestly live to see an Aldostool GUI to do this sort of thing. Heck, afaik, he's probably working on one right now! Hopefully he sees this issue :) On Jan 15, 2015 9:20 PM, "DieKatzchen" notifications@github.com wrote:

In Linux everything extracted has permissions 664. I created a test file with permission 654, created a new archive, and then read the archive.dat and it had been given permission 600. So it seems it gives all extracted files 664, and any files added to an archive it gives 600. It seems to give ownership of all extracted files to whoever ran ps3xport, and I don't know how it assigns ownership to archived files since ReadIndex says nothing about ownership. I'm not sure how to appropriately deal with ownership either, since if it preserved ownership you would need to elevate yourself to root to do anything with the data. I think the virtual filesystem reader would be best. Beyond my skill, though.

Reply to this email directly or view it on GitHub https://github.com/kakaroto/ps3xport/issues/9#issuecomment-70199027.

kakaroto commented 9 years ago

Maybe you can look at these patches here : https://github.com/kakaroto/ps3xport/pull/1 I remember setting those permissions because that's what I saw the backup sets files to, but I guess it's not always true. It should be doable to set them to better values (according to the linux filesystem or hardcoded to different values, depending on the path/filetype/etc..)

DieKatzchen commented 9 years ago

I think it would be easiest to just set it to the linux filesystem, and then set everything the way you want it in your folder. It would require manipulating the data as root, though, since you wouldn't be the owner.