PS3 PS1 libcrypt support on PS3 official emus - research thread

[sandungas]

Small pack of untested LC patches for disc images...

edit1: swapped Wip3out (Europe) (En,Fr,De,Es,It).ppf

i wanted to upload the 18 i made and verified but i think i just gonna F%$# off for the moment

de fr à fr ( merci pour l'upload. faudra que tu m'expliques 2-3 trucs un jour pour que je devienne moins con sur la méthode pour les faire )

i'll check em with time. for now 1 is already bad, wipeout 3. size wise file is empty.

Great, this is exactly what i was talking about, an initial collection of "clean" ppf patches (intended to disable libcrypt only) and in tiny size, is perfect for the PS1 Custom Patches page because allows to display them as text, in the same way is made in PS2 Custom Configs and here in the forum when someone publishes a PS2 config like this:


Vagrant Story (SLES-02755) by krHACKen

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  50 50 46 33 30 02 20 20 20 20 20 20 20 20 20 20  PPF30.          
00000010  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000020  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000030  20 20 20 20 20 20 20 20 00 00 00 00 78 F4 00 00          ....xô..
00000040  00 00 00 00 01 00 7A F4 00 00 00 00 00 00 02 00  ......zô........
00000050  00 80 F4 00 00 00 00 00 00 01 00 82 F4 00 00 00  .€ô........'ô...
00000060  00 00 00 02 00 00 88 F4 00 00 00 00 00 00 01 00  ......ˆô........
00000070  8A F4 00 00 00 00 00 00 02 00 00 98 F4 00 00 00  Šô.........˜ô...
00000080  00 00 00 04 17 59 C6 34 F8 F6 00 00 00 00 00 00  .....YÆ4øö......
00000090  04 8B 00 B5 06 28 F7 00 00 00 00 00 00 01 F0 2A  .‹.µ.(÷.......ð*
000000A0  F7 00 00 00 00 00 00 02 30 C6 30 F7 00 00 00 00  ÷.......0Æ0÷....
000000B0  00 00 01 2D 32 F7 00 00 00 00 00 00 02 F5 91 38  ...-2÷.......õ'8
000000C0  F7 00 00 00 00 00 00 01 D5 3A F7 00 00 00 00 00  ÷.......Õ:÷.....
000000D0  00 02 63 82 48 F7 00 00 00 00 00 00 04 60 F3 D6  ..c'H÷.......`óÖ
000000E0  03 4E F7 00 00 00 00 00 00 04 0C 4C 30 FF 7E F7  .N÷........L0ÿ~÷
000000F0  00 00 00 00 00 00 01 75 80 F7 00 00 00 00 00 00  .......u€÷......
00000100  02 06 5A 86 F7 00 00 00 00 00 00 01 7D 88 F7 00  ..Z†÷.......}ˆ÷.
00000110  00 00 00 00 00 02 CC 21 8E F7 00 00 00 00 00 00  ......Ì!Ž÷......
00000120  01 95 90 F7 00 00 00 00 00 00 02 A2 EC 9E F7 00  .•.÷.......¢ìž÷.
00000130  00 00 00 00 00 04 12 4F 28 3A A4 F7 00 00 00 00  .......O(:¤÷....
00000140  00 00 04 71 AD EB 8F AA F7 00 00 00 00 00 00 08  ...që.ª÷.......
00000150  90 8A 27 BD B9 2E 3C 79 B6 F7 00 00 00 00 00 00  .Š'½¹.<y¶÷......
00000160  0E 49 81 05 E4 6C 07 16 1A 83 99 31 42 BE 8D C6  .I..äl...ƒ™1B¾.Æ
00000170  F7 00 00 00 00 00 00 03 3C 70 D6 CE F7 00 00 00  ÷.......<pÖÎ÷...
00000180  00 00 00 05 AC 9D AB E3 9C D6 F7 00 00 00 00 00  ....¬.«ãœÖ÷.....
00000190  00 05 13 C5 21 15 F5 DE F7 00 00 00 00 00 00 08  ...Å!.õÞ÷.......
000001A0  D4 C1 31 1A 55 C6 BE FC EA F7 00 00 00 00 00 00  ÔÁ1.Uƾüê÷......
000001B0  0E 73 75 DC C7 F0 61 8F E8 C1 E8 6C 1F D0 71 FA  .suÜÇða.èÁèl.Ðqú
000001C0  F7 00 00 00 00 00 00 03 1F 10 01 02 F8 00 00 00  ÷...........ø...
000001D0  00 00 00 05 CF B9 52 93 83 0A F8 00 00 00 00 00  ....ϹR"ƒ.ø.....
000001E0  00 05 CB 80 8F 74 E5                             ..Ë€.tå

Vagrant Story (SLES-02755) by solomonbyte

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  50 50 46 33 30 02 50 53 58 2D 50 6C 61 63 65 20  PPF30.PSX-Place 
00000010  63 6F 6D 6D 75 6E 69 74 79 20 2D 20 74 65 73 74  community - test
00000020  20 62 79 20 73 6F 6C 6F 6D 6F 6E 20 62 79 74 65   by solomon byte
00000030  73 20 20 20 20 20 20 20 00 00 00 00 C1 F1 00 00  s       ....Áñ..
00000040  00 00 00 00 03 00 00 00 78 F4 00 00 00 00 00 00  ........xô......
00000050  01 00 7A F4 00 00 00 00 00 00 02 00 00 80 F4 00  ..zô.........€ô.
00000060  00 00 00 00 00 01 00 82 F4 00 00 00 00 00 00 02  .......'ô.......
00000070  00 00 88 F4 00 00 00 00 00 00 01 00 8A F4 00 00  ..ˆô........Šô..
00000080  00 00 00 00 02 00 00 98 F4 00 00 00 00 00 00 04  .......˜ô.......
00000090  17 59 C6 34                                      .YÆ4

Is an alternative way to "host" the files as text, the reader can highlight the hexcode with the mouse as text, then in a hexeditor--->new file-->paste--->save as .ppf
Is also a nice way to talk about them while having a "hexeditor view" of it in the web browser to compare them, etc...

Btw, the 2 patches in this post has been copyed from both your collections, eventually i will start adding them in the list in wiki as a "hexeditor view", i was about to do it with vagrant story, but i realized you are providing 2 patches for the same game... and both are inteded to do the same... so... we need to decide which is "the good one" for SLES-02755
Incase of doubts i can add both to the list in wiki (waiting for feedback/review)
Incase both patches works then the smaller filesize is the winner... i guess at this point is very hard to be completly sure, for a full confirmation is needed to do a complete playthrough

Btw krHACKen if you rebuild/rename your files i suggest to add the title id either in the filename or in the ppf header/comment
I wold use something like what solomonbyte did:
Vagrant Story (SLES-02755) LC.ppf

And inside the ppf header same info, but extended (it seems ppf format reserves room for 0x32 bytes or so)
Vagrant Story (SLES-02755) LC patch by solomonbyte


----------
Edit:
What im going to say matters mostly for the page in wiki, but is better to organize the files using the name of the original game, i mean... in the same way are grouped the disc releases of "Hogs of War"
https://www.psdevwiki.com/ps3/PS1_Custom_Patches#Hogs_Of_War
The name of this game is completly different for every country, as a result we dont have the files organized alphabetically and thats a bit confusing
In other words... instead of using filenames as Les Cochons de Guerre (France).ppf what we can do is:
Hogs Of War (SLES-01041) LC.ppf <--- includes english language
Hogs Of War (SLES-02766) LC.ppf <--- includes french language, named "Les Cochons de Guerre"
Hogs Of War (SLES-02767) LC.ppf <--- includes german language, named "Frontschweine"
Hogs Of War (SLES-02768) LC.ppf <--- includes spanish language, named "Marranos en Guerra"
Hogs Of War (SLES-02769) LC.ppf <--- includes italian language, named "Nati per Soffritto"

In other words... in the filename there is no need to indicate the languages included neither the "translated" game names
This way when we take a look at the full collection of .ppf files with a file browser/manager they are going to be listed together, and is a lot easyer to organize them (like in the list of patches in wiki)

If for some reason you really want to include the language and the translated game name in the filename, the best way to do it is by adding it at the end, to dont break the alphabetical ordering, something like this:
Hogs Of War (SLES-01041 English) LC.ppf
Hogs Of War (SLES-02766 French. Les Cochons de Guerre) LC.ppf
Hogs Of War (SLES-02767 German. Frontschweine) LC.ppf
Hogs Of War (SLES-02768 Spanish. Marranos en Guerra) LC.ppf
Hogs Of War (SLES-02769 Italian. Nati per Soffritto) LC.ppf

 

[sandungas]

OK made a small discovery, after Berion mentioned CTR EU was also a clean image i decided to buy it and started testing on it, Official version works but if i extract the ISO with psxtract and make a custom one it still fails, so next step was to grab and drop the official eboot.pbp onto the "make_psone_classic_metadata.exe" to make a custom ps1 classic with the official eboot, and libcrypt still activates.

so what this probably means is its NOT in the eboot but in the ISO.BIN.EDAT since a custom version crashed on libcrypt but the official one doesn't, so now we have it narrowed down to 1 much smaller file, i compared the official ISO.BIN.EDAT to the one made by the
"make_psone_classic_metadata.exe" and there are not many changes so the answer is probably here, im attaching a picture of the changes, Official on the left, custom on the right. @bguerville @Berion or any other Dev, i don't know how to edit the ISO.BIN (i can unpack it but if i hex edit it, it fails to start so im guessing a checksum ?)
View attachment 35456

The first 4 bytes you highlighted is the size of the disc image, it matches with this structure but "translating" the offsets as relative (the table starts in 0x400 but you should consider 0x400 = 0x0 in your screenshot)
https://www.psdevwiki.com/ps3/Iso.bin.edat#iso.bin_Disc_map

There is another page in wiki related, but doesnt contains much info
https://www.psdevwiki.com/ps3/PSISOIMG0000

 

[Devildwarf]

The first 4 bytes you highlighted is the size of the disc image, it matches with this structure but "translating" the offsets as relative (the table starts in 0x400 but you should consider 0x400 = 0x0 in your screenshot)
https://www.psdevwiki.com/ps3/Iso.bin.edat#iso.bin_Disc_map

There is another page in wiki related, but doesnt contains much info
https://www.psdevwiki.com/ps3/PSISOIMG0000

yeah i looked at those already but that would mean 4400 would be the checksum and im pretty sure it isn't since both those values are the same in both the eboots i posted, so i think most of that only applies to either Unofficial or Multidisc EDAT's (if its the later then it would help with FF8 but if its the former then its useless for this)
But the fact that its kept in the ISO.BIN.EDAT means that it should be possible to patch it if we can figure out the format (someone more intelligent then me would be needed probably), but the fact that Libcrypt can be patched in the ISO.BIN.EDAT is good news in my opinion and if it can be patched there im sure it can also be patched in the PS1 .self files which reads the ISO.BIN.EDAT if anyone who knows how to do that can do it (well i think so, i hope more dev's can look at it and see whats going on)

EDIT: i also tried the patch
Patch for disabling the signature check in ps1_netemu

but it just seems to black screen my ps3 so im guessing its for a certain version but it doesn't specify

 

[Ronnie Sahlberg]

OK made a small discovery, after Berion mentioned CTR EU was also a clean image i decided to buy it and started testing on it, Official version works but if i extract the ISO with psxtract and make a custom one it still fails, so next step was to grab and drop the official eboot.pbp onto the "make_psone_classic_metadata.exe" to make a custom ps1 classic with the official eboot, and libcrypt still activates.

so what this probably means is its NOT in the eboot but in the ISO.BIN.EDAT since a custom version crashed on libcrypt but the official one doesn't, so now we have it narrowed down to 1 much smaller file, i compared the official ISO.BIN.EDAT to the one made by the
"make_psone_classic_metadata.exe" and there are not many changes so the answer is probably here, im attaching a picture of the changes, Official on the left, custom on the right. @bguerville @Berion or any other Dev, i don't know how to edit the ISO.BIN (i can unpack it but if i hex edit it, it fails to start so im guessing a checksum ?)
View attachment 35456

Interesting.
I assume you mean the decrypted ISO.BIN.DAT here and not the encrypted ISO.BIN.EDAT?

You can not directly edit the ISO.BIN.DAT because it is indeed signed. The signature is the last 40 bytes of ISO.BIN.DAT.
See popstation.py : create_iso_bin_dat(), this is where the ISO.BIN.DAT file is created, minus the signature.
It is basically a copy of the what goes into the EBOOT for the metadata for the disk image.
For single disk games this is usually just a single PSISOIMG section and for multidisk images it is usually a
PSTITLEIMG section followed by one PSISOIMG section for each disk.

The PSISOIMG is the same as in the eboot.pbp except that it does not contain the actual compressed disc sectors. It is truncated after all the indicies but before the actual disk sector data.



Anyway, back to ISO.BIN.DAT. This file is signed and the last 40 bytes of the file is the signature.
If you want to modify it you need to regenerate the signature which should be pretty straightforward.
1, strip off the last 40 bytes
2, edit the ISO.BIN.DAT
3, run sign3.py (part of pop-fe) to recompute a new signature

Then to encrypt it back into ISO.BIN.EDAT you can
use the pack() fucntion in make_isoedat.
See pop-fe.py for an example how it is used.
Once you have the new ISO.BIN.EDAT you can now just create the PKG file again.


The size of each PSISOIMG section is exactly 0x100000 bytes so the signature will start at this offset into ISO.BIN.DAT for a single disc game from PSN.

 

[Devildwarf]

Interesting.
I assume you mean the decrypted ISO.BIN.DAT here and not the encrypted ISO.BIN.EDAT?

You can not directly edit the ISO.BIN.DAT directly because it is indeed signed. The signature is the last 40 bytes of ISO.BIN.DAT.
See popstation.py : create_iso_bin_dat(), this is where the ISO.BIN.DAT file is created, minus the signature.
It is basically a copy of the what goes into the EBOOT for the metadata for the disk image.
For single disk games this is usually just a single PSISOIMG section and for multidisk images it is usually a
PSTITLEIMG section followed by one PSISOIMG section for each disk.

The PSISOIMG is the same as in the eboot.pbp except that it does not contain the actual compressed disc sectors. It is truncated after all the indicies but before the actual disk sector data.

Caveat, the EBOOTS that pop-fe creates are slightly different, to make the code easier I always use a PSTITLEIMG including for single disk games.


Anyway, back to ISO.BIN.DAT. This file is signed and the last 40 bytes of the file is the signature.
If you want to modify it you need to regenerate the signature which should be pretty straightforward.
1, strip off the last 40 bytes
2, edit the ISO.BIN.DAT
3, run sign3.py (part of pop-fe) to recompute a new signature

Nice thanks for the info thats a BIG help Ronnie, and yes i ment i decoded the ISO.BIN.EDAT first into ISO.BIN (using TrueAncestors decryptor), and the signature makes sense if we can manipulate that then it might be possible to edit it,
And i will try doing that later thanks, hopefully it will give us more insight into this, i just hope this can lead to where the libcrypt command is passed

 

[Ronnie Sahlberg]

Nice thanks for the info thats a BIG help Ronnie, and yes i ment i decoded the ISO.BIN.EDAT first into ISO.BIN (using TrueAncestors decryptor), and the signature makes sense if we can manipulate that then it might be possible to edit it,
And i will try doing that later thanks, hopefully it will give us more insight into this, i just hope this can lead to where the libcrypt command is passed

As for the diffs in the screenshots you posted, the first diff, the 4 bytes immediately after PSISOIMG0000 those are a length field.
It points to the offset where the next section in the eboot.pbp starts, for example if there is another PSISOIMG0000 following for the next disk or so. Sometimes these are 0 and it seems that the emulator in psp/ps3 sometimes don't care.
So these 4 bytes are not part of libcrypt.

The third diff, that is just the 40 byte signature, so that is not libcrypt either.

Meaning if there is anything there, then it would have to be in the second diff, but it is also mostly jut filled with 0 so ... I suspect the subchannel data is not in this file but somewhere else. Maybe in a different file in the PKG.

 

[Devildwarf]

As for the diffs in the screenshots you posted, the first diff, the 4 bytes immediately after PSISOIMG0000 those are a length field.
It points to the offset where the next section in the eboot.pbp starts, for example if there is another PSISOIMG0000 following for the next disk or so. Sometimes these are 0 and it seems that the emulator in psp/ps3 sometimes don't care.
So these 4 bytes are not part of libcrypt.

The third diff, that is just the 40 byte signature, so that is not libcrypt either.

Meaning if there is anything there, then it would have to be in the second diff, but it is also mostly jut filled with 0 so ... I suspect the subchannel data is not in this file but somewhere else. Maybe in a different file in the PKG.

Well some GOOD news i messed around with the bytes and found changing the ones circled in the attached picture fixed Libcrypt on CrashTeamRacing EU
I tested with the original Eboot.pbp first then made my own using the clean ISO produced from PSXTRACT then used pop-fe to make a new one and its working.
so i think this proves libcrypt is handled in the ISO.BIN.EDAT, i also checked FF8 and it also has bytes around that location but those on its own are not enough for FF8, it has a load of data at the end of the ISO.BIN.EDAT that needs to be included as well, but if you do its possible to make a custom eboot with ff8 working so now we know libcrypt is handled this way we just need to decode how it works in ISO.BIN.EDAT

 

[solomonbyte]

i had the feeling the handling had to be within the pkg and not from ps3 side since tou yold me the ff8 & 9 work on pcs3 by swapping emulators. could not be otherwise. Bravo.

for my part i am desperate to make any of those damn soft making working compare function of 2 bins decompiled files. ghidra do not perform half the job on 2nd file opened, ida displays only one on the 2 files, i dont see how to switch, hanger, hanger and frustration.

 

[Ronnie Sahlberg]

Well some GOOD news i messed around with the bytes and found changing the ones circled in the attached picture fixed Libcrypt on CrashTeamRacing EU
I tested with the original Eboot.pbp first then made my own using the clean ISO produced from PSXTRACT then used pop-fe to make a new one and its working.
so i think this proves libcrypt is handled in the ISO.BIN.EDAT, i also checked FF8 and it also has bytes around that location but those on its own are not enough for FF8, it has a load of data at the end of the ISO.BIN.EDAT that needs to be included as well, but if you do its possible to make a custom eboot with ff8 working so now we know libcrypt is handled this way we just need to decode how it works in ISO.BIN.EDAT

Well done! This is an amazing discovery.
So, once you used the numberss on the left then the game worked and libcrypt was disabled?
The numbers 0x71 0xA3 0x00 0x00. Amazing, all of libcrypt just ends up being two bytes of data.
Amazing.

Now, we should look if the same can be found for other single-disk games.

Also, since ISO.BIN.DAT is basically a "copy" of the first 0x100000 bytes of the PSISOIMG section inside the eboot,
when you install a game on psp, you just install the EBOOT.PBP and there is no ISO.BIN.DAT.
I wonder, if you change the corresponding 4 bytes in the EBOOT.PBP that pop-fe creates for a PSP, will that make it pass the
libcrypt checks for PSP too? Do you have a PSP to test with?

 

[Devildwarf]

sorry i dont own a PSP (i did have one but got rid of it years ago when Vita came out, then was disappointed in the Vita and its really small buttons made it insanely hard to play games so i kinda regret getting rid of it) but it would be interesting to see, if anyone does have a psp please try it.
And i have no idea if this will work with other games, it doesn't with FF8 but FF8 has its own code a bit further down and that leads to a bigger patch at the end of the ISO.BIN.EDAT (either one on its own is useless, i checked), so i still have no idea how this works just that it does for CTR, i now need to look into more PS1 single disc libcrypt games to see how they are handled, but we know roughly where in the official ones where this is kept so it should be possible even if its different for every game (also this byte has to be read by the .self's so someone with more experience might be able to work it out somehow to find the function)

 

[solomonbyte]

@ sandungas : my patchs are incomplete i am learning, discard all ppf i uploaded. Kraken is the professional, i'm just a copy paste boy actually.

 

[Agrippa]

The numbers 0x71 0xA3 0x00 0x00. Amazing, all of libcrypt just ends up being two bytes of data.
Amazing

0xA371 is the Magic Word for the CTR actually. @Devildwarf you did a great job for figuring this out!

 

[sandungas]

Nice finding @Devildwarf
Now the theory is the emulator reads that 4 bytes, then it does something specific for the game, either:
1) load the subchannel data that (in theory) could be hardcoded inside the emulator self
2) load the patches (same concept than ppf format, but official), that also (in theory) could be hardcoded inside the emulator self

One way or the other i guess the next thing that could be made is to search in IDA for the value 0x71A30000 you found (or 0xA371 endianess swapped) in the decrypted emulator .elf ... and see where it takes the rabbit hole

-----
Btw, im not so sure if this is fully good news, because it would mean that we are dependant of how many "fixes" sony added into the emu, the complete libcrypt list is 229 discs... if sony only cared about 29 it means we have another 200 that are not going to work with this method (because we cant increase the entries in that theoretical list hardcoded in the emu)

 

[Ronnie Sahlberg]

sorry i dont own a PSP (i did have one but got rid of it years ago when Vita came out, then was disappointed in the Vita and its really small buttons made it insanely hard to play games so i kinda regret getting rid of it) but it would be interesting to see, if anyone does have a psp please try it.
And i have no idea if this will work with other games, it doesn't with FF8 but FF8 has its own code a bit further down and that leads to a bigger patch at the end of the ISO.BIN.EDAT (either one on its own is useless, i checked), so i still have no idea how this works just that it does for CTR, i now need to look into more PS1 single disc libcrypt games to see how they are handled, but we know roughly where in the official ones where this is kept so it should be possible even if its different for every game (also this byte has to be read by the .self's so someone with more experience might be able to work it out somehow to find the function)

Vagrant story PS3 PKG has also additional data at the end of ISO.BIN.DAT
At offset 0x100000 it has a blob of 0x11a0 bytes of data before the 40 byte signature.
This is an interesting number because 0x11a0 == 0x0178 * 0x0c
0x0C / 12 is the number of bytes for the subchannel content
and 0x178is the number stored at offset 0x12d8

Does that match for your FF8 disks too? That the number stored at 0x12d8 times 0x0c is the same as the amount of bytes stored at offset 0x100000 ?

 

[krHACKen]

@krHACKen,

after the typical magic word, what is so big you have to replace after ? my curiosity is on fire.

First screenshot, looks like the patched LC routine with the highlighted instruction that loads a fixed magic word, which is then loaded into the COP0 breakpoint register.
Second screenshot, error correction code that was fixed.

The pack does include patches for the games known to be unfixed for a long time - Spyro 3 and Lucky Luke: Western Fever.

Spyro 3s protection is a b*tch. Someone would have to clear the game 100% and to reload the final game save, to tell us the patch is whether reliable or not I'm afraid.
I remember to have debugged and patched Lucky Luke: Western Fever in the early POPStarter r13 development days. Though, I cannot tell if the patch I put in this pack is the same.
In fact, all the ppfs of this archive were made by comparing clean Redump-matching dumps and dumps that I've patched years ago. With PPF Studio. No verification data, no undo data, no nfo, in order to produce smallest possible files.

I think the POPStarter does replace the COP0 register with the correct key on the fly. But I haven't seen any working patch for a disc image to apply.

That's right. Now it directly feeds the register. And only if the LibCrypt protection doesn't send a unique magic word to the register on purpose, a patch (similar to our PPFs) is written to the main memory instead.
I remember that I made a program that was called ToolBox or similar, for our POPS hackeries. It was bugged to death, but I think it had the ability to produce PPFs and TROJAN files for standard LibCrypt crapola, not sure tho.
Also, a clever person made this LC Magic Word Finder that parses Redump info : https://github.com/Red-J/LibcryptMagic-Word-Finder-PSX

Btw, the 2 patches in this post has been copyed from both your collections, eventually i will start adding them in the list in wiki as a "hexeditor view", i was about to do it with vagrant story, but i realized you are providing 2 patches for the same game... and both are inteded to do the same... so... we need to decide which is "the good one" for SLES-02755
Incase of doubts i can add both to the list in wiki (waiting for feedback/review)
Incase both patches works then the smaller filesize is the winner... i guess at this point is very hard to be completly sure, for a full confirmation is needed to do a complete playthrough

Mine are heavier because they contain fixed ECCs. Not hexview friendly sadly. I prefer to always provide them in the patches in order to avoid "my burnt disc doesn't appear to be cracked" and "y0 dude yuor patch causes bad sectors" complains. Sometimes the injection of extra subroutines were required too.
Also post #131 from solomonbyte.

Btw krHACKen if you rebuild/rename your files i suggest to add the title id either in the filename or in the ppf header/comment
I wold use something like what solomonbyte did:
Vagrant Story (SLES-02755) LC.ppf

And inside the ppf header same info, but extended (it seems ppf format reserves room for 0x32 bytes or so)
Vagrant Story (SLES-02755) LC patch by solomonbyte

Yeah, that's what I ought to do next time. I wanted to do that (ID in the header, like I usually do), but the whole process of [redacted] the disc images, checking the old patched files for erroneous data, renaming stuffs and finally producing PPFs was a long and tedious road.
So I opted for the Redump naming convention for the sake of simplicity (and accuracy as for disc version identification) and skipped the SKU in PPF header part.

For now I don't plan to rework the patches. Feel free to edit them and their names for the wiki.

 

[Devildwarf]

0xA371 is the Magic Word for the CTR actually. @Devildwarf you did a great job for figuring this out!

Good catch, well atleast we know how that works now then, i guess it will be very game dependant but we know how it works now for CTR and probably some of the other games.

Nice finding @Devildwarf
Now the theory is the emulator reads that 4 bytes, then it does something specific for the game, either:
1) load the subchannel data that (in theory) could be hardcoded inside the emulator self
2) load the patches (same concept than ppf format, but official), that also (in theory) could be hardcoded inside the emulator self

One way or the other i guess the next thing that could be made is to search in IDA for the value 0x71A30000 you found (or 0xA371 endianess swapped) in the decrypted emulator .elf ... and see where it takes the rabbit hole

-----
Btw, im not so sure if this is fully good news, because it would mean that we are dependant of how many "fixes" sony added into the emu, the complete libcrypt list is 229 discs... if sony only cared about 29 it means we have another 200 that are not going to work with this method (because we cant increase the entries in that theoretical list hardcoded in the emu)

Yeah i know its not great news but it does mean that the PS1 selfs do support patching so its still interesting (even if it leads to nowhere due to lack of interest)

Vagrant story PS3 PKG has also additional data at the end of ISO.BIN.DAT
At offset 0x100000 it has a blob of 0x11a0 bytes of data before the 40 byte signature.
This is an interesting number because 0x11a0 == 0x0178 * 0x0c
0x0C / 12 is the number of bytes for the subchannel content
and 0x178is the number stored at offset 0x12d8

Does that match for your FF8 disks too? That the number stored at 0x12d8 times 0x0c is the same as the amount of bytes stored at offset 0x100000 ?

on FF8 the Patch data is at
0x400400
Which would put it around 0x100000 if it was a single disc game (+0x400 for multidisc header then +0x100000 per disc)
And i noticed this is decided early on in the ISO.BIN.DAT at
0x16D4 (so it should be 12D4 for Vagrent story since its single disc)
which reads
00 04 40 00
which translated to where the patch is (00 04 40 00 = 400400)

So im guessing at
0x12D4 in Vagrent story you would have
00 00 10 00
which would be 0x100000

EDIT:-
FF8 also has 4 patches at the end of it (1 per disc) so im not sure about the calculations on it, each disc points to a different offset so disc2 at 0x1016D4 points to 0x403400 which is where the next one starts and so on for each disc

 

[Ronnie Sahlberg]

Good catch, well atleast we know how that works now then, i guess it will be very game dependant but we know how it works now for CTR and probably some of the other games.


Yeah i know its not great news but it does mean that the PS1 selfs do support patching so its still interesting (even if it leads to nowhere due to lack of interest)


on FF8 the Patch data is at
0x400400
Which would put it around 0x100000 if it was a single disc game (+0x400 for multidisc header then +0x100000 per disc)
And i noticed this is decided early on in the ISO.BIN.DAT at
0x16D4 (so it should be 12D4 for Vagrent story since its single disc)
which reads
00 04 40 00
which translated to where the patch is (00 04 40 00 = 400400)
View attachment 35470
So im guessing at
0x12D4 in Vagrent story you would have
00 00 10 00
which would be 0x100000

EDIT:-
FF8 also has 4 patches at the end of it (1 per disc) so im not sure about the calculations on it, each disc points to a different offset so disc2 at 0x1016D4 points to 0x403400 which is where the next one starts and so on for each disc

You are right. At 0x12d4 I have 00 00 10 00
and at 12d8 I have 78 01 00 00

So it seems that @0x12d4 we have the offset where the subchannel data starts
and at @12d8 we have the count for how many 12 byte subchannel items there are

 

[sandungas]

Mine are heavier because they contain fixed ECCs. Not hexview friendly sadly. I prefer to always provide them in the patches in order to avoid "my burnt disc doesn't appear to be cracked" and "y0 dude yuor patch causes bad sectors" complains. Sometimes the injection of extra subroutines were required too.
Also post #131 from solomonbyte.

Well, are hexview friendly for comparing purposes, also the tiny size was something totally required for the idea i had to post them as a hexview in wiki, you made posible to start the list with a partial collection that is relliable enought

Yeah, that's what I ought to do next time. I wanted to do that (ID in the header, like I usually do), but the whole process of [redacted] the disc images, checking the old patched files for erroneous data, renaming stuffs and finally producing PPFs was a long and tedious road.
So I opted for the Redump naming convention for the sake of simplicity (and accuracy as for disc version identification) and skipped the SKU in PPF header part.

For now I don't plan to rework the patches. Feel free to edit them and their names for the wiki.

For wiki are going to be displayed in a "floating hexview" window with a "title" at top, in it im going to use a name format similar than what i mentioned, is almost done in the list in wiki, so if at some point you decide to rebuild your collection you can check the list in wiki for reference

@ sandungas : my patchs are incomplete i am learning, discard all ppf i uploaded. Kraken is the professional, i'm just a copy paste boy actually.

Is fine, even if are incomplete are aceptable, the most important thing was to find a way to start collecting them and "web browser friedly" for easy comparisons
Also, in your case, you have 1 or 2 references, as example... the patches in your vagrant story ppf are exactly the same values tha in krHACKen ppf patch (except one more you added at first), thats a nice signal, it means both are right in the patches that matches
Additionally... you also have the patches from other teams as reference (paradox etc...) where maybe could happen the same (the "clean" patch should be included in the paradox patch)

Yeah i know its not great news but it does mean that the PS1 selfs do support patching so its still interesting (even if it leads to nowhere due to lack of interest)

After reading your last posts it really looks 100% great news
The point was... a theory agrippa has been insinuating some posts ago
Some official sony emulators (specially the PS2 ones) asigns a unique identifyer to every game made with a hash (a custom CRC algorythm) of the TITLE_ID
As example... SCES-12345 becomes 0x6523
The list with that identifyers (in hex) is hardcoded inside the emulator, and based on it the emulator can do "special magic tricks" specifics for every disc

Well... the doubt was if the PS1 emulator was doing this, and additionally it had another list with the libcrypt data (either patches to disable it, or the subchannel of a few selected discs) associated with every identifyer, in this case related with the 0x71A30000 you found for CTR - Crash Team Racing (SCES-02105)

But if the last posts from you and ronnie are right (and it really looks like is right) it means the emulator doesnt have any hardcoded data specific for each disc
In other words.. the emulator allows to include the subchannel data together with the game disc image... and as a consequence it means that this should work with the 229 discs

Only thing left is to figure what they did with the subchannel data, as reference we should go to redump.org, they have the SBI info for each game displayed in a hexeditor view web browser friendly, in theory is exactly the same data... but maybe sony did something a bit different with it...in the worst scenario is going to be just a matter to apply a math formula to "convert" the SBI files from redump into the official format, so im optimistic, someone will find it soon

The other requirement is that Ronnie needs to review the structure of ISO.BIN.EDAT in his tools, but he has been working in them latelly so most probably he already know what needs to be reviewed
This is another part of the structure not documented before, probably there are a few unknown values in that area at 0x1220 (or 0x1620 for multidiscs), right ?
Btw, the 4 bytes you highlighted in the crash game screenshot with the 0x71A30000 are located at relative offset 0x90, right ?

Btw, someone edited the ISO.BIN.EDAT page today (some of you, thx, heheh)... and when i saw it i felt a bit motivated and edited the page a bit more too to organize it a bit because that page has been always very confusing, i added a new section for this area and named it "Game Params Table" with a link to this forum thread

 

[Agrippa]

Good catch, well atleast we know how that works now then, i guess it will be very game dependant but we know how it works now for CTR and probably some of the other games.

The FFVIII UK Magic Word is 0x9DE0. You can search the ISO.BIN.DAT with the "E0 9D 00 00" string.

 

[Ronnie Sahlberg]

The FFVIII UK Magic Word is 0x9DE0. You can search the ISO.BIN.DAT with the "E0 9D 00 00" string.

Can you compute what the magic word would be for Vagrant Story: SLES02754
I want to do a very crazy test that is super unlikely to work but you never know ...