Inclusion of SBI files in the dat?

[Haldrie]

Hm...ok now that I think about it a little more I guess it wouldn't hurt. I'm just seeing way too much stuff around here with people wanting to make this more "emulator friendly" when that was never what this started out to be in the first place but yes I guess a CRC of the sbi file is possible since the site generates the checksums for the cue files as well. I just wish Dremora (or someone here that can program) would make something that can inject the SBI data in to a generated CloneCD sub file for people like me who want to burn the images and run them on the real system.

[SoulReever]

I only asked this question out of curiousity (since I'm new and all). Ideally I just wanted the SBI's available with the dump in the archive when I run it through Clrmame - only so I have them locally if needed for emulation and because they relate to the modified subchannel data of the original disc.

[topkat]

Hm...ok now that I think about it a little more I guess it wouldn't hurt. I'm just seeing way too much stuff around here with people wanting to make this more "emulator friendly" when that was never what this started out to be in the first place but yes I guess a CRC of the sbi file is possible since the site generates the checksums for the cue files as well. I just wish Dremora (or someone here that can program) would make something that can inject the SBI data in to a generated CloneCD sub file for people like me who want to burn the images and run them on the real system.

Indeed,  directly onthefly injection of  the subchannel-data when mounting/burning a dump would be the best solution, but until someone comes up with way to use them, we are stuck to the sbi-files and therefor should be referenced in the dats.

Just like some MAME versions ago, where you need to use some special files (xor tables) to break protection of CPS3 games. Ofcourse MAME had references to those files in it's internal database. Now that MAME can emulate the protection itself without the need to 'crack' it, the xor-tables arn't needed anymore and has been removed from the rom-db.

[BadSector]

I believe SBI info should not be in the Dat file if it can't be verified, as that was not what i remember this site purpose was.

for me having info about packiso images CRC or SBI info in a dat is not right, and it should be the responsibilities of the uploaders to download those SBI files and share them with the dumps. also if someone have some packiso images generating a new dat file for those take just few clicks, having that info and regularly update it when ever there is a change related to that image in redump.org DB will only make maintaining the DB hard.

PS: i would rather like the dat file to be updated so that the naming scheme of the files can be updated to reflect more proper game name then having these info.

[Sotho Tal Ker]

SBI files should always be the same, else the libcrypt protection would fail.

SBI files are needed to actually preserve the digital data, so it should be included when replicating data. (Though it is bad that it is done in a binary format which is poorly documented)

[themabus]

One thing I can suggest though is that we do need something added to the site to give us a list of the games that do have sbi files on them so that we can quickly know what games have been proven to have LibCrypt protection on them without having to look at each game separately.

https://redump.info/discs/system/psx/libcrypt/2/


btw, do those SBIs even work?

there appears to be no CRC stored within them,
so it's supposed to be recreated i guess
but since there are multiple patterns,
how would you tell whether to XOR with 0x0080 or with 0x8001?
if it's byte right after MSF, something's wrong then - it's never different from 0x01

for example:

Code: Select all

same changes on CDs with different patterns:

                      C/A TNO IND M   S   F   Zro aM  aS  aF  CRC      Unmd   LC1    CRC      Real   LC2
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05  ffb8 xor b838 = 4780 | ffb8 xor ff38 = 0080
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05  3839 xor b838 = 8001 | 3839 xor ff38 = c701

in SBI CRC is lost:

                      C/A TNO IND M   S   F   Zro aM  aS  aF  CRC      Unmd   LC1    CRC      Real   LC2
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05  ???? xor b838 = 4780 | ???? xor ff38 = 0080
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05  ???? xor b838 = 8001 | ???? xor ff38 = c701

so to recalculate CRC it could be either one of those algorithms:
a) Real XOR 0080
b) Unmd XOR 8001
but only one of them is valid for each CD

i.e.
this is as far as SBI goes:
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05
those bytes are the same for both CDs
https://redump.info/disc/592/
https://redump.info/disc/798/
but each has different pattern in DB

it can't be right...

edit:
from what i can tell from cdr sources
0x01 following MSF indicate both time values being modified
and that's as much as SBI can hold
other options are 0x02 and 0x03 - for storing only relative or absolute MSFs
so i'd say ther's no way for SBI to hold CRCs - it's an unfortunate limitation of format

so what are those SBIs then good for at all?

[F1ReB4LL]

CRCs are unneeded for ingame libcrypt validation, only MSFs and AMSFs are important.

[themabus]

but CRCs are modified as well -
it's either (CRC from clean block or CRC from modified block) XORed with one of predefined values:
0x0080 or 0x8001
so what is this all about? why would Sony bother XORing then?
to tell people where LC is, so it could be copied with ease?
maybe emulators cheat? have you tested on console?

i don't think SBI author did really understand how LibCrypt works,
since ther's that possiblility to include only one of MSFs (saving 7 bytes?) -
on LibCrypt this seems to never happen - it's always both or none, afaict
so CRC can even be sole value modified:
https://redump.info/disc/1128/
those sectors are known to be LC,
with them pattern looks complete: 32 total sectors divided in groups of 16
3rd entry is @offset 0x20 in SBI, containing only valid bytes
how can modified data be recreated from unmodified values?
btw such blocks would be skipped with original plugin - it only stores ones with modified MSFs

so this complexity of format - it appears completely irrational and quite useless,
it could have been just MSF+entire Q
overcomplication often is a result of lack of understanding

[themabus]

well ok,
i've made a program that would convert .sbi -> .sub taking magic value as an input parameter
sbi2sub

processed following images with it:
Crash Bash
Speed Freaks

and tested with ePSXE 1.70

plugins that do not appear to read subcode at all (they crashed @LC):
SaPu's CD-ROM
Xeven's Cdr
plugins that would have to work but didn't (both games hanged prior LC with those):
P.E.Op.S. CDR
Pete's CDR
plugins that did worked:
ePSXe CDR <- only one that passed and would run actual CDs instead of images
Moby2 cd disk image driver
and additionaly ePSXe's Run ISO command

without subcode:
Crash Bash would crash on loading screen after character select & intro, before stage select
Speed Freaks hangs while Neon City stage is loading

with subcode those parts passed on both XOR patterns ($8001 & $0080)
i didn't test further though:
maybe there are later checks that wouldn't
maybe there is certain threshold, so for example:
byte from each MSF + 2 CRC bytes = 4  - maybe half of them passing is sufficient
but CD-R recorded this way would degrade much faster
maybe hardware or even other emulators act different
so i didn't test all those things - i'll take a closer look later with debugger - it's quite interesting

but consider this:
if those CRCs are there for the kicks only - completely unneeded to pass LibCrypt
it's a huge flaw in protection then, imho - this pattern gives away those special blocks
so what if Sony removed it later?
what if there are LC versions without modified CRCs or at least without constant (maybe even for USA or Japan)?
we wouldn't pick those currently, right?
the only way would be to clear subchannel a lot - with multiple rereads
and compare it later on with the ones from different CD, made in a similar way
psxt001z is capable of doing this, afaik, but nobody would - it takes forever
it's such a drag, not everyone would even test CDs with fast option

[Jackal]

lol, Dremora can't manage to write such a tool in 3 years time and you do it in 1 day (and you both live in Latvia? )

So the sbi format is missing relevant data that cannot be generated again? How about a tool which loads the libcrypt sectors from the database instead of using the sbi file?