You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry to bother you. I know it's been a while since you've been working on this project. But by any chance, do you know how to extract the image from 3989?
It's the loading screen file; the image itself is in file 3988, but apparently the game loads in file 3989, which is in .bin format.
From what I understand, file 3989 is encrypted, but in a generic way with some PSP key, not with something from Capcom.
I don't know if there's any way to decrypt it and then re-encrypt it.
Found an old email from 10+ years ago about 3989.bin when someone else was asking about that file and did some analysis about it:
"About 3989.bin, the file seems different from 3988.tmh. Since is close to the adhoc mib files then i assume that is encrypted because it gets sent via adhoc to the other player.
It has a encrypted header (or maybe is just padding) of 176 bytes, something that looks like the encrypted block size at the offset 0xB0 (0x47C80 bytes), something that looks like a relative offset to the start of the encrypted block at 0xB4 (0x80 bytes). Since this offset is relative then the encrypted block starts at the offset 300 or 304.
The data at 0xC0 looks like a sha1 checksum of the block to me (length of 20 bytes) and the rest of 0x0 bytes are just padding. You could try to extract the blocks (at offset 300 or 304) and try to decrypt it using one of the methods in mhtools (data.bin, mib or savedata decryption mode). If none of these work then it probably uses another decryption algorithm (or uses the same as the mib decryption but with different seed values)."
This was a conversation with a member of Team Maverick One. I don't have a followup email from him so i assume that he either solved it or gave up. Try to decrypt the block with some algorithms from the email above or try to locate the team and asking them directly.
Thank you so much for your reply, So we've been doing tests, and this is the part of the code that uses it: it copies that file into memory, then passes it through zz_scePauth_98883B5D, and then copies it back to the original location.
Thanks again, I'll look into the information you provided.
Do you happen to have any ideas on how to encrypt it once it's been edited?
Activity
Ancer282 commentedon Mar 13, 2026
From what I understand, file 3989 is encrypted, but in a generic way with some PSP key, not with something from Capcom.
I don't know if there's any way to decrypt it and then re-encrypt it.
codestation commentedon Mar 14, 2026
Found an old email from 10+ years ago about 3989.bin when someone else was asking about that file and did some analysis about it:
"About 3989.bin, the file seems different from 3988.tmh. Since is close to the adhoc mib files then i assume that is encrypted because it gets sent via adhoc to the other player.
It has a encrypted header (or maybe is just padding) of 176 bytes, something that looks like the encrypted block size at the offset 0xB0 (0x47C80 bytes), something that looks like a relative offset to the start of the encrypted block at 0xB4 (0x80 bytes). Since this offset is relative then the encrypted block starts at the offset 300 or 304.
The data at 0xC0 looks like a sha1 checksum of the block to me (length of 20 bytes) and the rest of 0x0 bytes are just padding. You could try to extract the blocks (at offset 300 or 304) and try to decrypt it using one of the methods in mhtools (data.bin, mib or savedata decryption mode). If none of these work then it probably uses another decryption algorithm (or uses the same as the mib decryption but with different seed values)."
This was a conversation with a member of Team Maverick One. I don't have a followup email from him so i assume that he either solved it or gave up. Try to decrypt the block with some algorithms from the email above or try to locate the team and asking them directly.
Ancer282 commentedon Mar 14, 2026
Thank you so much for your reply, So we've been doing tests, and this is the part of the code that uses it: it copies that file into memory, then passes it through zz_scePauth_98883B5D, and then copies it back to the original location.
Thanks again, I'll look into the information you provided.
Do you happen to have any ideas on how to encrypt it once it's been edited?