PS3 PS1 libcrypt support on PS3 official emus - research thread

Code: 
static uint16_t q_crc_lut[256] = 

{

0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7, 0x8108,

0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF, 0x1231, 0x0210,

0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6, 0x9339, 0x8318, 0xB37B,

0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE, 0x2462, 0x3443, 0x0420, 0x1401,

0x64E6, 0x74C7, 0x44A4, 0x5485, 0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE,

0xF5CF, 0xC5AC, 0xD58D, 0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6,

0x5695, 0x46B4, 0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D,

0xC7BC, 0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,

0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, [emoji767]0A, 0xB92B, 0x5AF5,

0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12, 0xDBFD, 0xCBDC,

0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A, 0x6CA6, 0x7C87, 0x4CE4,

0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41, 0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD,

0xAD2A, 0xBD0B, 0x8D68, 0x9D49, 0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13,

0x2E32, 0x1E51, 0x0E70, 0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A,

0x9F59, 0x8F78, 0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E,

0xE16F, 0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,

0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E, 0x02B1,

0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256, 0xB5EA, 0xA5CB,

0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D, 0x34E2, 0x24C3, 0x14A0,

0x0481, 0x7466, 0x6447, 0x5424, 0x4405, 0xA7DB, 0xB7FA, 0x8799, 0x97B8,

0xE75F, 0xF77E, 0xC71D, 0xD73C, 0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657,

0x7676, 0x4615, 0x5634, 0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9,

0xB98A, [emoji767]AB, 0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882,

0x28A3, 0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,

0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92, 0xFD2E,

0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9, 0x7C26, 0x6C07,

0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1, 0xEF1F, 0xFF3E, 0xCF5D,

0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8, 0x6E17, 0x7E36, 0x4E55, 0x5E74,

0x2E93, 0x3EB2, 0x0ED1, 0x1EF0

};

 

static INLINE uint16_t calculate_subq_crc(uint8_t *data) 

{

uint16_t crc = 0;

int i;

 

for (i = 0; i < 10; i++) 

crc = q_crc_lut[(crc >> 8) ^ data[i]] ^ (crc << 8); 

 

return ~crc;

}
That's the code called to calculate subQ crc for each lba when subQ is specified in the read cd scsi command.
calculate_subq_crc takes as only argument a pointer to the subQ struct filled by the code I attached in previous post.
Code: 
typedef struct _SubChannelQ

{

	uint8_t control_adr;

	uint8_t track_number;

	uint8_t index_number;

	uint8_t min;

	uint8_t sec;

	uint8_t frame;

	uint8_t zero;

	uint8_t amin;

	uint8_t asec;

	uint8_t aframe;

	uint16_t crc;

	uint8_t pad[3];

	uint8_t p;

} __attribute__((packed)) SubChannelQ;
The for loop in the above calculate_subq_crc function processes the first 10 bytes of a 16 byte SubChannelQ struct from uint8_t control_adr to uint8_t aframe & the 2 bytes returned by the crc calculation are stored in the uint16_t crc member of the struct.
As far as I can make out, if we added code to fill the first 10 bytes of a SubChannelQ struct using sbi provided data, we should be able to call calculate_subq_crc to fill the struct crc member.

And if you look at the sub.c code in the cdrpeops plugin, notice the px->subq data getting filled, that is what we need to reproduce in Cobra to fill the 10 bytes of subq data per lba pass when appropriate.
Code: 
...
while(fread(buffer, 4, 1, subfile)==1)              // -> read record header
    {
     iSUBNum++;                                        // -> one more sub cache block
     px=(SUB_DATA *)malloc(sizeof(SUB_DATA));          // -> get cache buff
                                                       // -> and fill it...
     px->addr=time2addrB(buffer);

     px->pNext=NULL;

     px->subq[0]=0x41;
     px->subq[1]=0x01;
     px->subq[2]=0x01;
     p=&px->subq[3];
     addr2timeB(px->addr,p);
     px->subq[6]=0x00;
     p=&px->subq[7];
     addr2timeB(px->addr+150,p);

     if(buffer[3]==1)
      {
       fread(px->subq,10, 1, subfile);
      }
     else if(buffer[3]==2)
      {
       fread(&px->subq[3],3, 1, subfile);
      }
     else if(buffer[3]==3)
      {
       fread(&px->subq[7],3, 1, subfile);
      }
...
The cdrpeops plugin processes the sbi file on mounting the CD, it builds a collection of SUB_DATA structs to store the 10 bytes of data per lba & a collection of SUB_CACHE structs to cache addresses for faster on the fly search access.
Here are the structs in play
Code: 
typedef struct { 
long addr; 
void * pNext; 
unsigned char subq[10];
 } SUB_DATA;

typedef struct { 
long addr; 
void * pNext; 
} SUB_CACHE;
I cannot say if it is really worth doing but the more I look at this idea of adding sbi support to Cobra, the more I think it's feasible without that much fuss.
I think we would only need to port the sub.c code to storage_ext.c.
1. to build on disc mount a subcQ cache from the sbi data like the sub.c code does, we could lift much of the code for that & keep the readily implemented fast search system.
2. to modify the scsi read cd handler so that whenever a subcQ cache exists, its data gets added on the fly.
3. to destroy the subcQ cache on disc unmount.
 
Last edited:
Devildwarf said:
OK just tested the magic Branch and its working great with FF8, it found the magic word, only problem i had was the PKG was non-existant still (same thing happened before), so i made the PKG myself but other then that its working great on my PS3 (it spends AGES making the PKG then it cleans up and im left with nothing so im not sure if its deleting the PKG or it just never gets made properly), i checked all 4 discs (using reset and change disc) and all 4 load fine to the main menu and i played the opening scene and upto the first battle on CD1 and its all working great, this is really nice work
EDIT:- i also tested this method on my Vita's PSP emulator and it didn't work so im guessing the PSP handles it differently.
Click to expand...

Try the magic-word branch again. It has support to download and apply PPF patches now. See gamedb.py/libcrypt.
So far only VagrantStories UK and FF8 UK have the links to the PPF. I have tested VagrantStory, can you test FF8 on your Vita again?

Then we just need to add links to ppf files for all other disks. But that is just time-consuming but not difficult.
 
Agrippa said:
To be honest I do not really know what the last three patches are precisely doing. I do not like the guessing games, so I think the reverse engineering the emulator is needed to understand it properly. Either way, the protection is not triggered at all it seems on these cases.

The first three games with Magic Words are present even in the old ps1_emu. Maybe some emulation issues interfered with the protection.

The MediEvil has got less sectors with the LC, because no paired sectors were used. Probably a second paired sector was added to avoid a tracking problems, as the seeking may not be accurate. In general LibCrypt works the same way like the old SecuROM (no surprise, as the same company was responsible for it).
Click to expand...
I been checking the internal structure of the tables used to store this "pseudo configs" inside ps1_netemu.elf and im confident what i wrote in my previous post is right, are offsets, the first data chunk have size 0x1A8, second 0x100, and third 0x160
The emulator knows where the area starts but doesnt knows where it ends, all the values in this areas are 4 bytes lenght, so the emulator reads values of 4 bytes consecutivelly until it finds 4 bytes filled with zeroes (the 4 bytes with zeroes represents the end of the area, is like a terminator)

To find the data in ps1_netemu.elf 4.88 we need to substract 0x1ABF0 from the values that appears in wiki and read up to the terminator:
The value im suggesting to substract looks so weird because by now in this talk we are using the offsets in wiki as reference, but are not valid for 4.88
Sadly there are many other values in wiki that doesnt matches, it seems the info in wiki was taken from an old emu version, probably 3.55
- Crash Team Racing (000000020017d3d4)
- MediEvil (000000020017d57c)
- Vagrant Story (000000020017d67c)

Crash Team Racing SCES_021.05 (located at absolute offset 0x17d3d4 - 0x1ABF0 = 0x1627E4)
Code: 
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

001627E0              00 00 06 A3 00 00 0E 21 00 00 17 79      ...£...!...y
001627F0  00 00 29 CB 00 00 2B 21 00 00 2E 22 00 00 31 31  ..)Ë..+!..."..11
00162800  00 00 37 19 00 00 37 1E 00 00 38 35 00 00 38 95  ..7...7...85..8•
00162810  00 00 38 9A 00 00 3A D0 00 00 3A D5 00 00 3B 1A  ..8š..:Ð..:Õ..;.
00162820  00 00 3B 1F 00 00 3B D0 00 00 3B D5 00 00 3C 12  ..;...;Ð..;Õ..<.
00162830  00 00 3C 17 00 00 3D 0C 00 00 3D 11 00 00 3F 27  ..<...=...=...?'
00162840  00 00 3F 2C 00 00 48 91 00 00 55 35 00 00 57 A1  ..?,..H'..U5..W¡
00162850  00 00 58 38 00 00 59 38 00 00 5B 67 00 00 62 A9  ..X8..Y8..[g..b©
00162860  00 00 62 C5 00 00 78 4F 00 00 78 CA 00 00 7E 94  ..bÅ..xO..xÊ..~"
00162870  00 00 90 30 00 00 9A D5 00 00 9E 05 00 00 A4 3D  ...0..šÕ..ž...¤=
00162880  00 00 A4 42 00 00 A5 C0 00 00 A5 C5 00 00 A8 04  ..¤B..¥À..¥Å..¨.
00162890  00 00 A8 09 00 00 A8 A9 00 00 A8 AE 00 00 A9 5A  ..¨...¨©..¨®..©Z
001628A0  00 00 A9 5F 00 00 A9 90 00 00 A9 95 00 00 AA 72  ..©_..©...©•..ªr
001628B0  00 00 AA 77 00 00 AD 18 00 00 AD 1D 00 00 C5 5C  ..ªw........Å\
001628C0  00 00 EC 56 00 00 FB CA 00 01 04 52 00 01 04 7C  ..ìV..ûÊ...R...|
001628D0  00 01 08 F4 00 01 22 A3 00 01 26 79 00 01 2F 8B  ...ô.."£..&y../‹
001628E0  00 01 2F A6 00 01 2F CE 00 01 53 A8 00 01 79 10  ../¦../Î..S¨..y.
001628F0  00 01 86 0D 00 01 C3 96 00 01 CD 83 00 01 EA 08  ..†...Ö..̓..ê.
00162900  00 01 F6 92 00 02 02 57 00 02 1C 08 00 02 53 85  ..ö'...W......S…
00162910  00 02 91 5D 00 02 93 8F 00 02 93 A6 00 02 AB 93  ..'].."..."¦..«"
00162920  00 02 AB FB 00 02 BC 8C 00 02 CA 39 00 02 D2 17  ..«û..¼Œ..Ê9..Ò.
00162930  00 02 F1 35 00 03 16 06 00 03 4A 45 00 03 4C B6  ..ñ5......JE..L¶
00162940  00 03 68 26 00 03 6B 1D 00 03 92 B8 00 03 92 F2  ..h&..k...'¸..'ò
00162950  00 03 9B 5D 00 03 A7 76 00 03 BA 90 00 03 C5 1A  ..›]..§v..º...Å.
00162960  00 03 C5 41 00 03 C5 A3 00 03 FC F1 00 03 FD DA  ..ÅA..Å£..üñ..ýÚ
00162970  00 04 14 C2 00 04 1F 49 00 04 26 57 00 04 87 5F  ...Â...I..&W..‡_
00162980  00 04 8E 65 00 04 C0 DA 00 00 00 00              ..Že..ÀÚ....

MediEvil SCES_003.11 (located at absolute offset 0x17d57c - 0x1ABF0 = 0x16298C)
Code: 
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00162980                                      00 00 06 15              ....
00162990  00 00 2A 75 00 00 37 19 00 00 3A 33 00 00 3A D0  ..*u..7...:3..:Ð
001629A0  00 00 3B 1A 00 00 3B 8A 00 00 3C 12 00 00 3E 2F  ..;...;Š..<...>/
001629B0  00 00 3E E5 00 00 5D FC 00 00 71 8E 00 00 7C 17  ..>å..]ü..qŽ..|.
001629C0  00 00 80 35 00 00 A4 3D 00 00 A7 3D 00 00 A8 04  ..€5..¤=..§=..¨.
001629D0  00 00 A8 A9 00 00 A9 19 00 00 A9 90 00 00 AB BB  ..¨©..©...©...«»
001629E0  00 00 AC 7F 00 00 BA B2 00 00 BE E3 00 00 C0 AF  ..¬...º²..¾ã..À¯
001629F0  00 00 C1 93 00 00 C1 C4 00 00 C3 A1 00 00 DA DE  ..Á"..ÁÄ..á..ÚÞ
00162A00  00 00 E7 C1 00 00 FD 3A 00 01 1A 1C 00 01 1D 6A  ..çÁ..ý:.......j
00162A10  00 01 1D CF 00 01 29 EF 00 01 45 E2 00 01 6A 98  ...Ï..)ï..Eâ..j˜
00162A20  00 01 7F BB 00 01 B7 A0 00 01 BB 05 00 01 BF 12  ...»..· ..»...¿.
00162A30  00 01 EE 64 00 02 02 6E 00 02 0B CA 00 02 10 19  ..îd...n...Ê....
00162A40  00 02 37 24 00 02 45 EC 00 02 54 06 00 02 55 A1  ..7$..Eì..T...U¡
00162A50  00 02 5D 48 00 02 62 C8 00 02 81 12 00 02 9B 2D  ..]H..bÈ......›-
00162A60  00 02 BD 04 00 02 C2 AF 00 02 D9 2A 00 02 DC 90  ..½...¯..Ù*..Ü.
00162A70  00 02 E1 3A 00 02 F2 18 00 02 FC C8 00 03 51 CF  ..á:..ò...üÈ..QÏ
00162A80  00 03 52 AA 00 03 72 3F 00 00 00 00              ..Rª..r?....

Vagrant Story SLES_027.54 (located at absolute offset 0x17d67c - 0x1ABF0 = 0x162A8C)
Code: 
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00162A80                                      00 00 14 B5              ...µ
00162A90  00 00 38 F3 00 00 38 F8 00 00 39 39 00 00 39 3E  ..8ó..8ø..99..9>
00162AA0  00 00 3A 33 00 00 3A 38 00 00 3A D0 00 00 3A D5  ..:3..:8..:Ð..:Õ
00162AB0  00 00 3B 1A 00 00 3B 1F 00 00 3B 8A 00 00 3B 8F  ..;...;...;Š..;.
00162AC0  00 00 3B D0 00 00 3B D5 00 00 3F 27 00 00 3F 2C  ..;Ð..;Õ..?'..?,
00162AD0  00 00 3F AA 00 00 90 84 00 00 A6 54 00 00 A6 59  ..?ª..."..¦T..¦Y
00162AE0  00 00 A6 AF 00 00 A6 B4 00 00 A7 3D 00 00 A7 42  ..¦¯..¦´..§=..§B
00162AF0  00 00 A8 04 00 00 A8 09 00 00 A8 A9 00 00 A8 AE  ..¨...¨...¨©..¨®
00162B00  00 00 A9 19 00 00 A9 1E 00 00 A9 5A 00 00 A9 5F  ..©...©...©Z..©_
00162B10  00 00 AD 18 00 00 AD 1D 00 00 BD D6 00 00 BE B1  ........½Ö..¾±
00162B20  00 00 BF AC 00 00 C9 BC 00 00 E5 11 00 01 07 06  ..¿¬..ɼ..å.....
00162B30  00 01 0C 80 00 01 18 E0 00 01 1E 36 00 01 41 46  ...€...à...6..AF
00162B40  00 01 55 E7 00 01 71 BF 00 01 D2 F5 00 01 D8 B5  ..Uç..q¿..Òõ..ص
00162B50  00 01 E4 5A 00 01 E6 29 00 01 F1 FD 00 01 FE B9  ..äZ..æ)..ñý..þ¹
00162B60  00 02 40 5D 00 02 59 9A 00 02 59 ED 00 02 5A 2F  ...]..Yš..Yí..Z/
00162B70  00 02 8B F6 00 02 8C A0 00 02 8C C2 00 02 A0 62  ..‹ö..Œ ..ŒÂ.. b
00162B80  00 02 DD 59 00 02 FD F1 00 03 0B FC 00 03 0C 26  ..ÝY..ýñ...ü...&
00162B90  00 03 9A B1 00 03 A9 E1 00 03 BC 7F 00 03 E1 B9  ..š±..©á..¼...á¹
00162BA0  00 03 E2 08 00 03 F8 8F 00 04 01 72 00 04 05 91  ..â...ø....r...'
00162BB0  00 04 13 8F 00 04 3E D8 00 04 40 DC 00 04 48 94  ......>Ø...Ü..H"
00162BC0  00 04 67 FB 00 04 78 2C 00 04 8A CE 00 04 B4 A0  ..gû..x,..ŠÎ..´ 
00162BD0  00 04 B9 60 00 04 BE 93 00 04 C3 0C 00 04 CB 0E  ..¹`..¾"..Ã...Ë.
00162BE0  00 04 CB C9 00 04 D5 C8 00 00 00 00              ..ËÉ..ÕÈ....

Now the question is if this is related with subchannel data ?
I been looking at the SBI file structure trying to imagine alternative ways to store the same info but no luck, the structure of the SBI files is commented in this code sample http://www.pbernert.com/cdr_interface.zip (scroll to bottom of the .cpp file)
// UCHAR ControlAndADR; (eg 0x41)
// UCHAR TrackNumber; (eg 0x01)
// UCHAR IndexNumber; (eg 0x01)
// UCHAR TrackRelativeAddress[3]; (bcd)
// UCHAR Filler; (always 0)
// UCHAR AbsoluteAddress[3]; (bcd)
Click to expand...
Basically... for the purpose of confirming if is the same data in 2 different formats... we can ignore the first 3 bytes of each entry in the SBI files, and the "filler" byte too... this only leaves 2 values that represents 2 adresses
 
Last edited:
I have updated the master branch for pop-fe with two pathes, one to automagically create the magic-word when building ps3 pkgs, which should make libcrypted games work for them, but also automatically install libcrypt PPFs when building PSP EBOOTs.
Right now only ~1/3 of the libcrypt disks are supported (krHACKen's archive a few pages back plus a handful of other games).

This should take care of the libcrypt issue for EBOOT based emulators on PS3.
 
krHACKen said:
Cheers !
As for those in my archive, I've no idea when I could start making new patches. Made a todolist of discs that aren't in my archive, counted 168 discs oof:dejection:.
Click to expand...

I think none of the patches had a .DIZ section where most of the other ones I see have credits.
I feel a little bad not showing credits where credits are due. Let me know and I can easily make
a "kindly contributed by xyz" or whatever you want to be printed to stdout anytime a patch of yours are applied.

EDIT: Compose a message and I will add it to pop-fe and print to the screen anytime someone usesyour patch
 
Yeah, an stdout'ed "Contributed by krHACKen" (or any message you want) will be fine:encouragement:, thank you.
And if you would like to modify my patches to add a description or a .diz section, feel free to do so.
 
Kracken, what did you use to rebuild ecc codes on disks. i used ecc regen from STARWIN guy and i can down only to 30 different bytes from pff comparing with your patches from more than 95 bytes of an untouched ecc code - same source, internet abandonware, same namefiles. do you use proprietary tool ?
 
Last edited:
I'm not sure, but I believe that I simply used CDmage to inject patched files into the disc images (CDmage rebuilds ECCs on the fly).
Otherwise when I hexpatch mode 2 disc images directly, I fix the ECCs with the good old ECCRegen 1.41. It works no problem on Windows 10.
 
krHACKen said:
Yeah, an stdout'ed "Contributed by krHACKen" (or any message you want) will be fine:encouragement:, thank you.
And if you would like to modify my patches to add a description or a .diz section, feel free to do so.
Click to expand...

Done. I have added a credits field to the libcrypt dictionary in https://github.com/sahlberg/pop-fe/blob/master/gamedb.py
It is printed to the screen everytime one of these games are processed by pop-fe.
Thank you!

I have also updated the installation instructions. @Devildwarf very kindly figured out how to build pkgcrypt under windows and provided updated windows instructions. This means that building PS3 packages for these games can now also be done on windows. Wooohooo.
 
Last edited:
@krHACKen what is your process when you create these patches?
I looked at https://red-j.github.io/Libcrypt-PS1-Protection-bible/index.htm
and did a quick test to just search for 25308600
and replacing with the 4 bytes containing the magic word, but the resulting pkg did not work on my ps3.

Is it because I did not update the checksums(reed-solomon?) codes and the ps3 emulator actually looks at this even for
binary packages that still has the per sector sha1 checksums and if the emulator detects corrupted data it can just tell the user to re-download the game? ( i am developer by trade and in this kind of situation I would never try to correct the data. just throw up a screen telling the user the game is corrupted and you need to re-download a good version. because that is the easy solution and I am lazy)


Or did I mess something up? Is it supposed to work by just replacing all occurences of 25308600 for ps3 packages or is it a lot more complex?

If that is all it takes it would be trivial for me to do that kind of bianry search and replace before I (psp: compress the sectors and) write them to the eboot.
 
Last edited:
Ronnie Sahlberg said:
@krHACKen what is your process when you create these patches?
I looked at https://red-j.github.io/Libcrypt-PS1-Protection-bible/index.htm
and did a quick test to just search for 25308600
and replacing with the 4 bytes containing the magic word, but the resulting pkg did not work on my ps3.
Click to expand...
If I had to make some patches, I would disassemble the games files; to locate the routines and to see which GPRs are involved, so I could write my opcodes accordingly.
To make things easier, I'd build a comprehensive list of false-positive-free hex search patterns, or a tool to find the routines using all the GPRs.

0x00863025 compiles to or a2, a0, a2 which is a common instruction. Searching for this might lead to kilometric truckloads of occurences that are totally unrelated to the LC routine. There's a hint though : this or instruction is preceded by three branch instructions that you have to NOP (screen shot @ red-j.github.io).

I'm sure that the "LibCrypt fix" codes in my codelist were generated by a tool of mine. But for the life of me I couldn't find its src, not even a build:confusion:. What a pity. It'd be time consuming to redo everything from scratch then a write up:frown new::frown new::frown new:.
 
Ronnie Sahlberg said:
and did a quick test to just search for 25308600
and replacing with the 4 bytes containing the magic word, but the resulting pkg did not work on my ps3.
Click to expand...

have you replaced 86 00 by c6 34 ? the full replacement is XX XX C6 34.
i've seen a kracken patch with c6 37 loading on parasite eve 2 disk 2, pretty sure is an error since it is the only disk like this.

there is only single valid call and it is few bytes only after long one :
08 00 20 14 02 00 e7 30
06 00 e0 10 ad ff 84 20
04 00 80 14 00 00 00 00 .

exemple on picture of any "standard" LC2 scheme :
 

Attachments

  • Annotation 2021-12-18 142715.jpg
    Annotation 2021-12-18 142715.jpg
    270.4 KB · Views: 36
Last edited:
imagine what i can do if i learn how to code. :bitsbubba:

:very drunk:


no need to fix anything dude, open the ppf and mod the 37 to 34, you not gonna remake all this shit 25 years later for a damn caracter everybody can change with an hex editor.

let sandungas mod the file prior upload and baam, done. 5seconds.
 
solomonbyte said:
have you replaced 86 00 by c6 34 ? the full replacement is XX XX C6 34.
i've seen a kracken patch with c6 37 loading on parasite eve 2 disk 2, pretty sure is an error since it is the only disk like this.

there is only single valid call and it is few bytes only after long one :
08 00 20 14 02 00 e7 30
06 00 e0 10 ad ff 84 20
04 00 80 14 00 00 00 00 .

exemple on picture of any "standard" LC2 scheme :
Click to expand...

I must have messed up. I trired it again an this time it worked, so I added it to pop-fe but behind a new argument --auto-libcrypt
 
You must log in or register to reply here.

Similar threads

Back
Top