Resource icon

PS1 Lib Enigma - A PlayStation 1/2 CD Image C Library For Patching And Identification v1.0.4

Go to download
Overview Extra info Updates (2) History Discussion
Ronnie Sahlberg said:
Ok, I redid it and added to the database a tag IF psx.exe / PSX.EXE is referenced.It is probably not 100% accurate
but likely accurate enough.
190 entries for SCPL/SLPS, has PSX.EXE and also a known volume creation timestamp/

a.txt is the python program to extract it, out.txt is the 190 entries found.
Click to expand...
This is all great. Sony sent out a memo in early 1995 saying "DO NOT DO PSX.EXE MAKE A PROPER SYSTEM.CNF AND NAME THE BOOTFILE AS THE SERIAL". There was some lag though, some people didn't get the memo, and Sony kept approving games into late 1995 making masters with no system.cnf and PSX.EXE. I think it's only Japanese games officially though, never seen a USA one (launch for those was September 1995. Sounds like the right amount of games too, I'm still going through it but tysm
 
Here is a better one.
In the previous one I just checked if the file psx.exe or PSX.EXE existed.Turns out is is somewhat common that there is a PSX.EXE for many disks that then have a copy of it under the proper name and system.cnf pointing to the proper filename.

This means a bunch of false positives.
I have redone the list now by also verifyig that system.cnf actually points to a file with a proper name.
And now there are only 101 entrues.

Attached below
 

Attachments

Ronnie Sahlberg said:
Here is a better one.
In the previous one I just checked if the file psx.exe or PSX.EXE existed.Turns out is is somewhat common that there is a PSX.EXE for many disks that then have a copy of it under the proper name and system.cnf pointing to the proper filename.

This means a bunch of false positives.
I have redone the list now by also verifyig that system.cnf actually points to a file with a proper name.
And now there are only 101 entrues.

Attached below
Click to expand...
Yes exactly! Just because there is a SYSTEM.CNF doesn't mean that it doesn't just point to a PSX.EXE! And Sony's loose approval policy didn't make the situation any easier,
 
@Ronnie Sahlberg the reason for SYSTEM.CNF pointing to PSX.EXE is get this: custom Event/Stack/TCB args. They ignored the sony memo, but wanted the custom features. If your game is just named PSX.EXE the bios is bugged to the point where it ignores the Event/Stack/TCB headers in the EXE IF your just having a PSX.EXE file and no SYSTEM.CNF. The ONLY way to have it have custom ones are with a SYSTEM.CNF, even though the PSX.EXE format literally has fields for these that are intended to be used, they are just ignored due to buggy Sony BIOS when booting no-system.cnf game. This was actually a problem I helped socram8888 (og tonyhax non-international dev) solve: https://github.com/socram8888/tonyhax/issues/153.

The opposite is also true... King's Field (Japan) has absolute garbage values in the PSX.EXE header, and there is no SYSTEM.CNF. So if you don't design your soft-mod to ignore them when no SYSTEM.CNF exists then you get bad values and crashes :)
 
Last edited:
Enigma: a person or thing that is mysterious, puzzling, or difficult to understand.
Paradox: a seemingly absurd or self-contradictory statement or proposition that when investigated or explained may prove to be well founded or true.

This is a C library that can be used in your program to:

* Ensure validity of a PlayStation 1 or 2 CD disc image in MODE2/2352 format.

* Get the boot file name (i.e. SLUS_XXX.XX) of the disc image. PSX.EXE games are supported (some still need to be identified by the library but many already are). When a PSX.EXE game is identified, the serial/product code on the original CD case of the game is returned in the same manner as a proper boot file game. See example 1 and example 2.

* Identify different disc images that share the same boot file name by checking revision differences. See example 2.

* Identify if a bin file will fit on a 71 minute, 74 minute, or 80 minute CD-R.

* Apply PARADOX PPF v1, PPF v2, and PPF v3 patches from unsigned char arrays. You can convert your PPF patch file into an unsigned char array, use the library to apply the patch, and create a standalone single executable patcher for your project/tool that requires no external files (see example 2).

* Find and replace method for byte patterns, with advanced options. Traditional find and replace with i.e. a hex editor DO NOT WORK for BIN/CUE PSX CD images because of how raw sectors are laid out:

Full Sector (0x930/2532 bytes) layout:
Sync header - 0x18 bytes - tells the psx what sector/where in the CD the laser is reading.
User data - 0x800 bytes - actual data for the game or software.
EDC - 0x04 bytes - a checksum used to check if a data read by the CD drive was successful.
ECC - 0x114 bytes - repair data, if the EDC checksum mismatches with what is read, this data can be used to 'fix' what was read, unless it's really off.

So keep in mind sectors are chained together. So you could have a byte pattern that starts at the very end of the user data on say sector 40. The data will be cut off at offset 0x818 in the sector (a total of 0x800 bytes are in the user sector, then the header itself was 0x18 bytes). So then you have your 0x04 bytes of EDC, 0x114 bytes of ECC, ANOTHER header of 0x18 bytes for sector 41, then finally you arrive at the user data of sector 41. This is where the REST of the byte pattern ends in this example. Because half of the byte pattern was cut off 0x136 bytes before the rest of it started, simple hex editor find n replace will FAIL if you encounter something like this. **Lib-enigma's** find n replace method is sector aware and works across sector boundaries**.

Another thing about this feature, is you can specify offsets that you want to ignore in your byte pattern. So for example if you are looking for a byte pattern of 08, 0F, 16, 24, and after 24 you know there is going to be 6 bytes you don't care about, but then there is 1C, 37, 4A that is supported! You can tell the library to ignore certain offsets of your pattern, and it will do so! This increases the strength of finding your unique pattern, and enables more advanced find and replace. See example 3.


3 examples are available, compiled for multiple operating systems w/source code:

Example 1: Prints out boot file of psx game bin file, with support for early PSX.EXE games.

Example 2: Single executable that uses no external files, applies english translation patch w/save fix for the game King's Field (Japan).

Example 3: Patches LibCrypt v1 if it detects the game MediEvil (Europe) using 'lossy' patching without hardcoded offsets. If any other game is given as input it will patch APv2 protection if it is detected. This patch for APv2 protection allows the game to work with a soft-mod correctly, if their is not a non-stealth mod-chip in the console.
 
@GuilloteTesla when I submitted this as a resource and it autogenerated another discussion thread. Any chance that the resource can be modified to point to this thread instead? No need for two threads.
 
So I'm working on this again. I have alot of plans for it eventually. I have written half a dozen psx based patchers and refuse to update them until I can use one unified code library of my own that makes sense (lib-enigma, here).

If you give a man a fish, he eats for one day. If you teach a man to fish, he eats for many years... or something like that.

My goal with lib-enigma is to release an open source library that stops people writing code for technical things unrelated to their goal. I get I'm pretty much the scene for this at this point. But everyone benefits from biaries using consistant updates to functionality, bug fixes,etc. If I can just release a library update called by all my patcher programs this benefits greatly me enough.

So... my next feature to add is a sector read function. Not just one, but 3... sector_user_data_read, sector_edc_read, sector_ecc_read...

For those unfamiliar. a standard PSX disc track 1 is a data bin file, comprised of:
0x18 sync bytes. This tells the CDROM wth it is (for the most part).
0x800 bytes of data. This is your actual game.
0x04 EDC bytes. This is a 4 digit checksum for what the EDC should return.
0x118 ECC bytes. This is repair data based off EDC, that tries to repair raw read data.

That's an awful lot of noise repeated each sector.The new functions will further abstract this so if you just want a bunch of user data sectors that is what you will get. Lib-Enigma already solves this in it's find n replace functionality for general lossy non-offset patching, it takes every sector and chains it's user data together until the end. But much more can be done to abstact the noise (comparing true sector user data differences, etc... even tho I have sort of done this with aprip this will be done in a more library way).

The best way I can explain this, is say you are looking for 1A, 3B, 5C, 6F pattern in a PSX CD ISO. Well there is chance because every 0x800 bytes your are cut off by bs you don't care about you'll never find this where you want to with a traditional hex editor. And lets be honest, hex editors our not the same on the year of linux 2026 anyways... But by abstracting the 0x18 sync header, 0x04 EDC, and 0x114 EDC and only chaining together real data for your find n replace this is much more useful then a hex editor :) I even plan on porting the user sector compare feature, so you can ignore the EDC/ECC change from the sector on the patched disc image and just see the binrary differenes. Again this all exists right now in i.e. aprip but not in a more sophisticated way for use in your own programs. Hope this makes sense to someone messing about with this stuff or who has in the past.
 
Last edited:
Have to love C99 and K&R syntax. Not just because it works on Windows 95 and essentially everything newer, but because its all I know and all I want to know ;). Imagine rewriting this in rust and loosing the ability to read it and or target older operating systems. Hint, if your targeting windows 95 right you can easily target win 11 x86_64 as well with no changes! And ancient Mac OS X 10.4 Intel from 2006, or Linux 3.2.0... Don't believe me? Check out the build system I use for every program for lib-enigma as well as every lib-enigma example: https://github.com/alex-free/ezre you just fill in some vars, program in C99, and boom.

Site butchers syntax, but can always find proper 4 space tabbed code here: https://github.com/alex-free/lib-enigma/blob/master/lib-enigma.c
int read_sector_user_data(FILE *bin, unsigned int sector_number, unsigned char * sector_buf)
{
unsigned int sector_sum = total_number_of_sectors(bin);
if(sector_sum < sector_number)
{
return 2;
}
unsigned int sector_offset = (SECTOR_RAW_LEN * sector_number) + SECTOR_SYNC_HEADER_LEN;
fseek(bin, 0, SEEK_SET);
fseek(bin, sector_offset, SEEK_SET);
unsigned int ret = fread(sector_buf, 1, SECTOR_USER_DATA_LEN, bin); // Not big endian safe.
fseek(bin, 0, SEEK_SET); // Always seek to initial fpos as per policy of this library.
if(ret == SECTOR_USER_DATA_LEN)
{
return 1;
} else {
return 0;
}
}
 
Last edited:
alexfree updated Lib-Enigma: Portable C Library For Disc Identification & Patching with a new update entry:

Lib Enigma v1.0.4

PSX-Place.com has been down, but I've still been working on this. The best PSX modification library ever, and open surce at that. I'll give yall an update on what has been implemented since the site has been down...

v1.0.4 (5/4/2026)

Changes:

  • Better build system and documentation.

v1.0.3 (5/4/2026)
Changes:

  • Completely rewritten the advanced find n replace sector boundary aware function. Instead of giving it a file, you give it a sector. This allows you to run...
Click to expand...

Read the rest of this update entry...
 
Nice.
Are you also planning to host a collection of (all available) PPF patches for games?
I don't think there is a central repository for patches and as old sites go offline PPF patches are I think lost forever.
 
Ronnie Sahlberg said:
Nice.
Are you also planning to host a collection of (all available) PPF patches for games?
I don't think there is a central repository for patches and as old sites go offline PPF patches are I think lost forever.
Click to expand...
Hmm, yea. I think it would be a different program but still using lib-enigma. I've wanted to do one for i.e. english translations, etc.. As for modchip stuff (USA/Japan, non LibCrypt) I have something in the works, but really just using the Tonyhax International Boot CD already sollves that issue.. None the less, I am working on an APRIP update that will cover almost every protected game with advanced lossy patching (kinda the whole reason for these recent updates).
 
alexfree said:
Hmm, yea. I think it would be a different program but still using lib-enigma. I've wanted to do one for i.e. english translations, etc.. As for modchip stuff (USA/Japan, non LibCrypt) I have something in the works, but really just using the Tonyhax International Boot CD already sollves that issue.. None the less, I am working on an APRIP update that will cover almost every protected game with advanced lossy patching (kinda the whole reason for these recent updates).
Click to expand...
As soon as you have something ready, let me know and I will import it into pop-fe.

Other consumers I could see where this would 100% be a value-add would be emulators and ODEs like X-Station.
Having them automatically patch games on the fly.
That would be really cool and useful.

You load the Disk images of Aconcagua and the emulator/X-Station/Mister/... asks you
"There is an english translation of this game, do you want to apply it on the fly? Y/n"
 
Ronnie Sahlberg said:
As soon as you have something ready, let me know and I will import it into pop-fe.

Other consumers I could see where this would 100% be a value-add would be emulators and ODEs like X-Station.
Having them automatically patch games on the fly.
That would be really cool and useful.

You load the Disk images of Aconcagua and the emulator/X-Station/Mister/... asks you
"There is an english translation of this game, do you want to apply it on the fly? Y/n"
Click to expand...
Do standard mod-chip/soft-mod checks mess up the emulators POP-FE covers (non-libcrypt protected games like Japanese and USA, I.e. Dino Crisis USA).

Also emu authors and ODEs, my code is portable C99 and 3-BSD licensed, it will run on a toaster (not shading the PS1 as a toaster but it does run some of the library in Tonyhax internatinal) and you don't get more freedom then that really in licensing…. Just credit my name as who wrote it and don't use my name to endorse your product, you didn't even need to release source code;)
 
You must log in or register to reply here.

Similar threads

Back
Top