PS3 PS1 libcrypt support on PS3 official emus - research thread

Sorry, I didn't answer sooner, you wrote a lot I couldn't follow ;)

I don't think I'll work on it, it seems to be lot of work, at least for me.

From what I understood, the only solution is to work directly on the cobra/mamba because this is where subchannel Q are managed. So, it's only place we can avoid the libcrypt 'corrupting' it.
 
Zar said:
From what I understood, the only solution is to work directly on the cobra/mamba because this is where subchannel Q are managed. So, it's only place we can avoid the libcrypt 'corrupting' it.
Click to expand...
Yes that's where the scsi commands are executed & where the data can be manipulated on the fly so it seems the logical place to insert externally stored libcrypt data.

I don't know if it would be such a lot of work Zar, the C code to support sbi files is ready to be deployed, there is also generic C code that shows where/when/how the sbi data should get inserted in the scsi command output data & the current Cobra/Mamba code is subchannel Q ready, it already fills the subchannel data when the scsi command specifies it, which helps. Everything is relative of course but I think it would be more like porting than developing in many ways. And Aldo & I are both willing to help as we can if ever you decide to give it a try.
But it is up to you of course, nobody wishes to force your hand, I declined taking on this job myself as I am swamped already, we would all understand if you did too.

Maybe we would first need to confirm the level of native support of the 2 emus for the libcrypt subchannel data, there would be no point going any further if the emus didn't support or ignored the subchannel data we intend to feed it.
I don't own libcrypt protected ps1 game titles so I cannot help testing.
 
Last edited:
Hello vous tous.

Je possède quelques jeux PS1 originaux (CD noirs) avec lesquels je peux faire des tests de vos réalisations. Je possède une PS3 sous le "Rebug-4.84.2 REX", et une autre sous le HFW-4.88/HEN-3.0.3 (CECH-4204C). Si je peux vous être utile, contactez-moi. Indiquez-moi les conditions de tests aussi.

I have some original PS1 games (black CDs) with which I can test your achievements. I have a PS3 under the "Rebug-4.84.2 REX", and another under the HFW-4.88 / HEN-3.0.3 (CECH-4204C). If I can be of assistance to you, please contact me. Tell me the test conditions too.
 
i only have final fantasy VIII that has libcrypt, all my other games do not (FF7, DieHard Trilogy, RE1,Broken Sword, F1 97, Bust a Move 2) well when i got my ps3 slim 3k model it could read discs1-3 and not 4, but now years later (and now on ofw 4.88) it can read all 4 discs but now black screens on loading the discs (after the PS logo and region), i downgraded my other PS3 slim to 3.55 rebug (earliest i dare downgrade too) and it does the same thing so not sure what changed (my first thought was maybe the discs no longer worked but my PC drive can read them fine without errors) so not sure what happened.
I am also curious about how PS1 Classics handle this, using psxtract i extracted the data from the eboot.pbp (official ps1 classic) to take a look and it has the original game discs without any subchannel data, i originally assumed they patched the images but it appears not, so there must be something else the official PS1 classic can do that a homemade one cannot (maybe it has a patch included in the JUNK/Meta data ?)
 
Load the original verified image through the ps1_netemu to check whether the emulator does patch the game itself internally. I do not know if the PBP file could contain any patches inside, I have no knowledge about the console specific formats.
 
from the patching bin, i dont see the point of extracting the exe file and hex it then use cdmage to perform the update since direct editing in the main bin file is exactly the same., any reason to do so ?
 
Agrippa said:
Load the original verified image through the ps1_netemu to check whether the emulator does patch the game itself internally. I do not know if the PBP file could contain any patches inside, I have no knowledge about the console specific formats.
Click to expand...
i tried loading my image and the one produced by psxtract and both do the exact same under all 4 ps1 emulator settings in irisman which is a the Europe PS logo then black screen (not surprising), and my original discs do the same so im out of ideas, i think this might be a dead end, i guess the other avenues are either a ppf patch for each of the games that need it that can be applied (but god i hate some of those awful menus some groups added back then) or try and figure out how the ps1 classic does it
 
Yup, I have discovered that psxtract tool. But are you sure you used it with the -c switch? The properly rebuilded CUE/BIN files will be created in the CDROM folder.

If these dumps from the Classics are really intact (they have to be after all), there must be either a config with memory patches inside the package or inside the ps1_netemu internals (we know such patches exist there).

I like the cracktros personally. At least they aged better than the games themselves.
 
was training myself to manually patch the standard libcrypt 2 ( 3 routines, action replay, mod chip & subchannel ) and beginning to be confidant as long i do not encounter LC3 or LC4 ( crypted ) i patch my games couple at the same time, copy paste on my Hxd to go faster.

when came parasite eve 2. the emulator i use to validate the patch is psxfin 1.13.
the game stuck on " published by bla bla bla "

i try it on no$psx...game working.... i put the image on ftp ps3..i launch the game with irisman.... game works.... evilnat 88.2... with emu, netemu old emu et new emu.... 4/4.

funny.
 
Agrippa said:
Yup, I have discovered that psxtract tool. But are you sure you used it with the -c switch? The properly rebuilded CUE/BIN files will be created in the CDROM folder.

If these dumps from the Classics are really intact (they have to be after all), there must be either a config with memory patches inside the package or inside the ps1_netemu internals (we know such patches exist there).

I like the cracktros personally. At least they aged better than the games themselves.
Click to expand...
yes i ran it from commandline with the -c switch (if you don't it doesn't generate images, it only extracts the PBP into the raw files which are not readable at all)
with the -c switch it generated 4 CUE+BIN's all of which match the finished game apart from the ends are missing but byte for byte they are the same as the images i made with CloneCD, the things thats missing is the subchannel data so im guessing it either doesn't have that or its in a different format that psxtract doesn't read or convert (there are 3 JUNK files in the extracted data from the PBP and 1 of these could be it but i have no idea), So the images are clean which means there must be a patch in there OR its in the EDAT thats used to launch the game
 
solomonbyte said:
was training myself to manually patch the standard libcrypt 2 ( 3 routines, action replay, mod chip & subchannel ) and beginning to be confidant as long i do not encounter LC3 or LC4 ( crypted ) i patch my games couple at the same time, copy paste on my Hxd to go faster.

when came parasite eve 2. the emulator i use to validate the patch is psxfin 1.13.
the game stuck on " published by bla bla bla "

i try it on no$psx...game working.... i put the image on ftp ps3..i launch the game with irisman.... game works.... evilnat 88.2... with emu, netemu old emu et new emu.... 4/4.

funny.
Click to expand...
wow thats some great work, congratulations, you have come far very fast
 
well, i have not learned to read and understand assembler on r3000 cpu in 48h, i have took the existant knowledge about sectors, the overall basic patching is very simple. 3 common HEX replacement strings and 4 bytes as a checksum to calculate from individual disc.

for game like FF9, wipeout 3, this is veeeeery simple to do.

for a vast amount of games it is enough, it generically disables protection, but when you start to go into soul reaver that do crypted checks, the LC2 scheme is becoming hybrid, routine are plain visible on cd but extra wizardry is done by game and comes into play the ability to really master reverse engineering, and lets face itn forcing on psx daily will take over a decade to be amateur skill rank.

worst case are lucky luck, spyro 2 &3, FF8... it is LC3 type : you do not see a single hex value of the routine on the disc, all is encrypted.

it is conceptually simple, still. the lack of how a given cpu works and no experience of assembler language coupled with no experience in coding provoke a massive stop when you confront debugger, because you know what you are doing, you know what you are searching, you understand the concept, but you just do not know reading, and this is very fustrating.

.

i found " Everything You Have Always Wanted to Know about the Playstation But Were Afraid to Ask. " pdf on the web. psx bible.

it will fill some blanks to my own brain.

i should go down in bit and begin with 8 bit nes maybe.
 
If you have regular time to invest & you are interested/motivated in learning, you should not hesitate for a second imho.
And I suppose the ps1 is as good an arch as any to start acquiring skills.

Assembler languages always scare people away, it used to scare me away so I know, it used to make me feel like inaccessible knowledge without years of learning.
But the truth is that it's only perception, it is not easy but it's not all that complicated either, you can learn to read & write x86, ppc, arm.. snippets quite fluently in a matter of weeks, not years.

When you inspect existing code you quickly realise that like in human languages, the most commonly used instructions represent only a tiny subset of the full instructions set. With that small subset of instructions you can do maybe 90% of all tasks.
You don't even need to be a coder already to learn this either although the fundamental programming principles apply & it's of course easier for a C coder to relate immediately to those.
Why not learn C & an assembler language at the same time? If I had to turn the clock back & start from scratch, that's probably what I would do.

Deciphering disassembled code is not a problem in itself, anyone can learn to understand a series of instructions in a few days, the complexity resides in reverse engineering the algos that the instructions implement, that's the real challenge.
 
i agree with your words.

focusing in a spec and then going other is probably not what i want and how i see things.

going my own pace but doing SAME time how to code in C then how it is disassembled looks like a good path to equilibrium.

i found a text about a guy who explain his approach for FF8 crack. he did not only crack the boot sequence of the game, he took the constraint of space and to not perturb the console and memory behavior he rewrote the boot sequence of the game totally to manage the decrypting bytes, then put 1-2 GOTO as bypass then ff8code begin. that's why the ppf is 550~ bytes instead of usual 25ish.

ff8 is graal on libcrypt. i laugh yesterday cause i understood what i 've read. i just do not understand yet all methodology, crypting, etc, cause it is all coding related that i ignore.

for now i will take simple FF9 check routine that calculate checksum on COP register at very early booting stage and disassemble the sequence until i find the routine to familiarize with the debugger, how to navigate, how to follow, how to search, to get my hands on the tools.
 
FFIX does include a crack protection too. It is not a simple check routine at all, if I remember correctly.

But what is more interesting to me is how the Sony is handling the LC protected games in their Classics releases. Judging by the extracted data from DATA.PSARC, there is no full subchannel data there (assuming the unpacker is properly coded).
 
i don't use your technical vocabulary as intended, my bad.
To me, a routine, when i learn a copy protection, it is the whole thing. :D

open FF9 CD 1 bin.
replace 80 e1 02 3c 00 38 82 40 by 80 e1 02 3c 00 00 00 00
replace 08 00 20 14 02 00 e7 30 06 00 e0 10 ad ff 84 20 04 00 80 14 00 00 00 00 by 00 00 00 00 02 00 e7 30 00 00 00 00 ad ff 84 20 00 00 00 00 00 00 00 00

and few bytes farer replace the 25 30 86 00 by a1 ce c6 34. where is A1 CE is specific for the PQ code checks of the disc. then you have FF9 CD1 (fr), patched. :D just like majority of lc2 games.

good luck trying this with FF8, that's what i meant.
 
Last edited:
The cracks have been available for 20 years. The point of this thread is to figure out how to pass the data dumped from original disc through the optical disc emulator. Since the official Classics support the LC protected games, maybe there is a way to use the ps1_netemu to load them directly without any changes in payload. There is a need to figure out how do the digital versions work. While it's nice to see you learning the cracking and improving your skills, it does not help the thread to progress in any way.
 
Agrippa said:
The cracks have been available for 20 years. The point of this thread is to figure out how to pass the data dumped from original disc through the optical disc emulator. Since the official Classics support the LC protected games, maybe there is a way to use the ps1_netemu to load them directly without any changes in payload. There is a need to figure out how do the digital versions work. While it's nice to see you learning the cracking and improving your skills, it does not help the thread to progress in any way.
Click to expand...
oh I didn't know. So, official PS1 classic PKG with libcrypt are working ? If you get the ISO from the PKG and mount it with cobra/mamba, it doesn't work ?

Can you give me an example, please ?
 
You must log in or register to reply here.

Similar threads

Back
Top