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

[christorrella]

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?

• Create a virtual filesystem reader. That is to say, you have a GUI that displays the contents of the backup, and allows for deletion, copying, moving, and creating of more files in the backup. This could be achieved without changing the file permissions of the file system by keeping record in the RAM (or a temp folder) of the original file permissions. Or...
• make ps3xport maintain file permissions by saving a copy of the original index, and then reading from it when it's time to recompile. This would ensure the permissions are not skewed.

[christorrella]

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]

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]

I believe that it works for files that have r/w permission by default. On Jan 12, 2015 12:14 AM, "DieKatzchen" [email protected] 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]

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]

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" [email protected] 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]

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]

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]

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" [email protected] 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]

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]

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.