SYS2x6 technical details discussion

[doccaz]

So, after quite some time I finally got all the pieces together: COH dongles, the Sony USB reader, and the software.
I did compile ps3mca-tool and got it talking to the COH dongles (so I guess I got the correct keys).

So, just for kicks I formatted one my spare COH dongles, copied the files from another dongle dump with mymc+ and... it doesn't boot. Tried signing the boot.bin file with --sign-kelf, same result. I read somewhere that one would need to patch a few bytes on boot.bin first. Anyone?

BTW, mymc+ is available here: https://git.sr.ht/~thestr4ng3r/mymcplus -- no sense in using the old python 2.x-based mymc anymore (it's on PyPi as well, so you should be able to just use PIP to install it).

 

[doccaz]

https://github.com/resekf/2x6donglemerge
https://github.com/XyLe-GBP/mca-coh-gui
I think these 2 should also work。

I took a look at those two...
The first one is a tool to merge ECC data into dongle images taken from MAME. Not the case here.

The second one is interesting. It requires a copy of ps3mca-tool.exe with the proper keys (of course), and libusbK drivers for the PS3 MCA USB adapter (which I found here: http://onorisoft.free.fr/psx/psx.htm#Tools -- yes, it's a PS1 memory card manager, but the drivers work on Win10)

Basically, it's a shell for calling ps3mca with the proper parameters. It does have a feature to dump/rewrite the key area for boot.bin to/from 32-byte key files. It also automates some stuff like downloading/uploading files to the card (dump all, write all). But it doesn't have options for signing at all.

 

[doccaz]

About AnthonyPS2: it contains all the ps3mca code (with the wrong keys) and requires the WinUSB drivers (it needs to load the "WinUsb Device" built-in to Win10).
It only does 4 things: read from card, read from file, write to card, write to file. No single file manipulation, only full card read/write. It *does* implement ECC page reading AND writing, which the original ps3mca-tool did not have.

It's not too intuitive (and a bit slow), but basically it's like this:

• if you click "Read->from Card", it'll read all blocks and keep it *in memory*. Same thing with "Read->from File", but it reads from a .ps2 memory card file.
• If you remove the current memory card, insert a new one and hit "Write->to Card", it'll do as it says on the tin, and create a 1:1 clone.
• If you hit "Write->to File", it'll ask for a filename and save a normal .ps2 image (which can be read and manipulated by other tools).

So, what would happen if you compile it with the proper keys and try to duplicate from one COH dongle to another? Well... the copied dongle is readable, but not bootable.

 

[extraweb1]

More to come soon , here is a sneak peek

More to come as I learn what makes this asic tick.

 

[extraweb1]

So, after quite some time I finally got all the pieces together: COH dongles, the Sony USB reader, and the software.
I did compile ps3mca-tool and got it talking to the COH dongles (so I guess I got the correct keys).

So, just for kicks I formatted one my spare COH dongles, copied the files from another dongle dump with mymc+ and... it doesn't boot. Tried signing the boot.bin file with --sign-kelf, same result. I read somewhere that one would need to patch a few bytes on boot.bin first. Anyone?

BTW, mymc+ is available here: https://git.sr.ht/~thestr4ng3r/mymcplus -- no sense in using the old python 2.x-based mymc anymore (it's on PyPi as well, so you should be able to just use PIP to install it).

Remember before formatting any dongle to backup the original boot.bin because it has the dongle's key

 

[doccaz]

Remember before formatting any dongle to backup the original boot.bin because it has the dongle's key

I did save mine, and if I put back the boot.bin from the backup, it boots as expected I still want to get the re-signing thing done correctly though.

 

[extraweb1]

Since I have this working, I need one of brizzo's Dongles for my collection . I just bought 5 more games because I just have to have them after playing them so my collection is still growing. Some of these games have costed me a lot. But I just had to have them

 

[extraweb1]

More to come soon , here is a sneak peek

I have tried changing the chips code and it's a no go but I bought some blank ones and wrote a sysid:0x03 and a mcid: custom but didn't mess with anything else and wrote one successfully and it operates but these are 15 a piece and the hours of work and payin for a 300 dollar uncapping and code exploration mean this was a expensive dongle.

It was fun though.

 

[l_oliveira]

So, after quite some time I finally got all the pieces together: COH dongles, the Sony USB reader, and the software.
I did compile ps3mca-tool and got it talking to the COH dongles (so I guess I got the correct keys).

So, just for kicks I formatted one my spare COH dongles, copied the files from another dongle dump with mymc+ and... it doesn't boot. Tried signing the boot.bin file with --sign-kelf, same result. I read somewhere that one would need to patch a few bytes on boot.bin first. Anyone?

BTW, mymc+ is available here: https://git.sr.ht/~thestr4ng3r/mymcplus -- no sense in using the old python 2.x-based mymc anymore (it's on PyPi as well, so you should be able to just use PIP to install it).

Do it again, but before binding the file to the card open it at a hex editor and paste this hexadecimal string at offset 0x28:

41A9A25013C81C6F3FE0A6E9DCF7CB039DFFF1F2E6D19D2CB83323F47DDB0BF1

What this does is restore the original state of the file before it was bound to the memory card. Binding decrypts the keys using the **mechacon algorithm**, then re-encrypt them using the **card algorithm**. If you try to bind an file that was already bound the keys retrieved by the tool during the bind process will be wrong and the final file will not decrypt at all. This is why you need the disc file as basis for binding.

Because they used the same 0x16 bytes at the start of all files (user header) and the same content key(KC) / bit table key (kbit) the encrypted digest is identical on all files.

The algorithm has two types, "disc" which is intended to be decrypted by the mechanics controller mcu on the PS2 (this string I pasted here returns the file into being disc type) and "card".
Card files have those 32 bytes encrypted by the card they're bound to which is why you need to move the data from file to file, sony defeated themselves by using the same user header and decrypted file keys, this make the digest identical for all boot.bin files and that's why moving the encrypted data around (keep it with the same card it came with) works.

So again, take a boot.bin file you want to bind to your card, paste that hex string at offset 0x28 and then run the -k option to bind. The resulting value should be the exact same you had on the original file you got off the card when you first read it out.

On the modded ps3mca I made in 2021 I added a function where the program asks nicely the card to decrypt the file keys in the header then it re-encrypts it to the file using the mechacon algorithm, effectively unbinds the file and make it so it can be bound again later on to a different card.

Adding to Defor's information, the COH and DEVKIT key sets you can see at the PS DEV WIKI were obtained from the SCPH-5000x mechacon firmware which were attacked with a firmware patch injection attack, completely software based by the folks of the "mechapwn" project.

 

[l_oliveira]

Oh and at the time I did three versions of it, one for retail, (it let you unbind and copy over things like DVD player, osd update files, freemcboot installs). one for DEV which lets you play around with the SCPH-10020 TDB Startup card or create special FMCB files that can work with TEST Debuggingstation PS2 consoles and finally this one which works on COH dongles.

 

[l_oliveira]

More to come soon , here is a sneak peek

This is something that is interesting but since most of the secrets were already extracted from something else, the interest on this is mostly about understanding how SONY manufactured the cards. More of a curiosity. So the chips came blank and were "initialized" into a state which defined which type of memory card they would operate as?

 

[doccaz]

Do it again, but before binding the file to the card open it at a hex editor and paste this hexadecimal string at offset 0x28:

41A9A25013C81C6F3FE0A6E9DCF7CB039DFFF1F2E6D19D2CB83323F47DDB0BF1

What this does is restore the original state of the file before it was bound to the memory card. Binding decrypts the keys using the **mechacon algorithm**, then re-encrypt them using the **card algorithm**. If you try to bind an file that was already bound the keys retrieved by the tool during the bind process will be wrong and the final file will not decrypt at all. This is why you need the disc file as basis for binding.

So, the "unsign" operation is just pasting those 32 bytes to 0x28? Or would you need to decrypt something using those bytes?

Because they used the same 0x16 bytes at the start of all files (user header) and the same content key(KC) / bit table key (kbit) the encrypted digest is identical on all files.

The algorithm has two types, "disc" which is intended to be decrypted by the mechanics controller mcu on the PS2 (this string I pasted here returns the file into being disc type) and "card".
Card files have those 32 bytes encrypted by the card they're bound to which is why you need to move the data from file to file, sony defeated themselves by using the same user header and decrypted file keys, this make the digest identical for all boot.bin files and that's why moving the encrypted data around (keep it with the same card it came with) works.

Ahh, now that makes sense on why just moving those 32 bytes from the original boot.bin to the new one works. Thanks for the explanation.

So again, take a boot.bin file you want to bind to your card, paste that hex string at offset 0x28 and then run the -k option to bind. The resulting value should be the exact same you had on the original file you got off the card when you first read it out.

Weird, I'm getting different bytes than the original ones from the original boot.bin after using -k on the file after adding the "unbound" bytes. Also, on your example you pasted the 41a9... to test2.bin... but you signed the original test.bin instead?

 

[l_oliveira]

So, the "unsign" operation is just pasting those 32 bytes to 0x28? Or would you need to decrypt something using those bytes?

-U takes the original file I read off the card with the data 179CA01FF244CADA355788AD323A23ED1F19BE9057B88DAED1C99FC3DE5FA143 and after decrypting with the card then re-encrypting with mechacon algorithm/key it became 41A9A25013C81C6F3FE0A6E9DCF7CB039DFFF1F2E6D19D2CB83323F47DDB0BF1.

I then take the new file and use -K with it and it became 179CA01FF244CADA355788AD323A23ED1F19BE9057B88DAED1C99FC3DE5FA143 again, which matches that specific card. It is a original untampered ZDX1 dongle.

Ahh, now that makes sense on why just moving those 32 bytes from the original boot.bin to the new one works. Thanks for the explanation.

The decrypted keys are the exact same keys used by SONY on the SCPH-10000 DVD Player 1.00 (the one which had the region detection bug).

Weird, I'm getting different bytes than the original ones from the original boot.bin after using -k on the file after adding the "unbound" bytes. Also, on your example you pasted the 41a9... to test2.bin... but you signed the original test.bin instead?

mca-coh -x ./boot.bin ./test.bin <- reads boot.bin off dongle
mca-coh -u test.bin test2.bin <- reads boot.bin, unbinds and saves the result as test2.bin
mca-coh -k test2.bin test3.bin <- reads test2.bin, binds to card and saves result as test3.bin.

I now noticed I wrote the third command wrong:

C:\MCA>mca-coh -k test2.bin test3.bin
PS3MCA-TOOL v1.4 (COH)
PS2 Memory Card Content Key
target Kelf file: 'test3.bin'
Kbit: 17 9c a0 1f f2 44 ca da 35 57 88 ad 32 3a 23 ed
Kc : 1f 19 be 90 57 b8 8d ae d1 c9 9f c3 de 5f a1 43

C:\MCA>fc test.bin test3.bin
Comparing files test.bin and TEST3.BIN
FC: no differences encountered

And:

C:\MCA>fc test.bin test2.bin
Comparing files test.bin and TEST2.BIN
00000028: 17 41
00000029: 9C A9
0000002A: A0 A2
0000002B: 1F 50
0000002C: F2 13
0000002D: 44 C8
0000002E: CA 1C
0000002F: DA 6F
00000030: 35 3F
00000031: 57 E0
00000032: 88 A6
00000033: AD E9
00000034: 32 DC
00000035: 3A F7
00000036: 23 CB
00000037: ED 03
00000038: 1F 9D
00000039: 19 FF
0000003A: BE F1
0000003B: 90 F2
0000003C: 57 E6
0000003D: B8 D1
0000003E: 8D 9D
0000003F: AE 2C
00000040: D1 B8
00000041: C9 33
00000042: 9F 23
00000043: C3 F4
00000044: DE 7D
00000045: 5F DB
00000046: A1 0B
00000047: 43 F1

There you go.

 

[l_oliveira]

So, the "unsign" operation is just pasting those 32 bytes to 0x28? Or would you need to decrypt something using those bytes?

That only apply to the ARCADE boot.bin files because them all use the exact same per file keys and user header. On regular PS2 files they changed those values in a per file basis making it a lot more secure.

 

[extraweb1]

like doccaz i get different values ;

i extracted boot.bin from a virgin card :
18 01 69 25 39 25 CD FF B4 34 77 80 AA 94 1C 10 8D BD AA 16 F3 83 36 10 7D 24 74 53 72 95 4C 22
pasted what you said at offset x28
41A9A25013C81C6F3FE0A6E9DCF7CB039DFFF1F2E6D19D2CB83323F47DDB0BF1

then i tried to sign it with the -k option

PS3MCA-TOOL (COH KEYSET) v1.3
PS2 Memory Card Content Key
target Kelf file: 'boot.bin2'
Kbit: 48 af 6d e0 64 d5 3d 40 0a d1 fb b9 d9 4f e8 ab
Kc : 82 ef 49 eb ac 67 76 66 67 08 5c 65 3e 44 55 ca

i then opened it back up and it has the wrong key for the virgin dongle:

48 AF 6D E0 64 D5 3D 40 0A D1 FB B9 D9 4F E8 AB 82 EF 49 EB AC 67 76 66 67 08 5C 65 3E 44 55 CA

so clearly taking the source off the net and replacing the keys doesn't do any of the above binding and unbinding. but even doing it manually without those features it doesn't work.

this is why i lost a dongle when my kid formatted one that wasn't backed up.

 

[l_oliveira]

like doccaz i get different values ;

i extracted boot.bin from a virgin card :
18 01 69 25 39 25 CD FF B4 34 77 80 AA 94 1C 10 8D BD AA 16 F3 83 36 10 7D 24 74 53 72 95 4C 22
pasted what you said at offset x28
41A9A25013C81C6F3FE0A6E9DCF7CB039DFFF1F2E6D19D2CB83323F47DDB0BF1

then i tried to sign it with the -k option

PS3MCA-TOOL (COH KEYSET) v1.3
PS2 Memory Card Content Key
target Kelf file: 'boot.bin2'
Kbit: 48 af 6d e0 64 d5 3d 40 0a d1 fb b9 d9 4f e8 ab
Kc : 82 ef 49 eb ac 67 76 66 67 08 5c 65 3e 44 55 ca

i then opened it back up and it has the wrong key for the virgin dongle:

48 AF 6D E0 64 D5 3D 40 0A D1 FB B9 D9 4F E8 AB 82 EF 49 EB AC 67 76 66 67 08 5C 65 3E 44 55 CA

so clearly taking the source off the net and replacing the keys doesn't do any of the above binding and unbinding. but even doing it manually without those features it doesn't work.

this is why i lost a dongle when my kid formatted one that wasn't backed up.

That just mean you are using wrong keys still on the mechacon part and the bind function is not working properly because of that lol


The wiki has different names for some of the keys stuff:

MG_KBIT_IV -> MG_KBIT_MATERIAL
MG_KC_IV -> MG_KC_MATERIAL

MG_KBIT_MASTER_KEY (same name)
MG_KC_MASTER_KEY (same name)

Those keys are not needed to unlock the card, just to bind a file. Without the correct initial vectors (IV) the digest will be different and the resulting key will be wrong when decrypted.

 

[l_oliveira]

this is why i lost a dongle when my kid formatted one that wasn't backed up.

Don't worry, once you fix the keys on your tool and put the data I told you to on the boot.bin file, it will work correctly and you will be able to recover that card.

 

[extraweb1]

Don't worry, once you fix the keys on your tool and put the data I told you to on the boot.bin file, it will work correctly and you will be able to recover that card.

So the keys to sign boot.bin are different than the keys to read and write the cards?
edit: well i give up i used each keyset one at a time and it just doesn't work .

 

[l_oliveira]

So the keys to sign boot.bin are different than the keys to read and write the cards?

CARDKEYx_y, CARDIVx_y (two pairs) and MG_CHALLENGE_IV being correct are what is needed to unlock a card for reading.


This is the most help I can give you without getting me in trouble with legal crap like DMCA.

static const uint8_t MC_CARDKEY_MATERIAL_1[] = { 0x6A,
static const uint8_t MC_CARDKEY_HASHKEY_1[] = { 0xBA,
static const uint8_t MC_CARDKEY_MATERIAL_2[] = { 0x12,
static const uint8_t MC_CARDKEY_HASHKEY_2[] = { 0x38,
static const uint8_t MC_CHALLENGE_MATERIAL[] = { 0x2C,

static const uint8_t MG_KBIT_MATERIAL[8] = { 0x22,
static const uint8_t MG_KC_MATERIAL[8] = { 0xC3,
static const uint8_t MG_KBIT_MASTER_KEY[16] = { 0x93,
static const uint8_t MG_KC_MASTER_KEY[16] = { 0x05,

static const uint8_t MG_IV_NULL[8] = { 0 };

 

[extraweb1]

CARDKEYx_y, CARDIVx_y (two pairs) and MG_CHALLENGE_IV being correct are what is needed to unlock a card for reading.

i can read the cards fine for a while now
i can even write bootable cards, but i have to paste the key between boot files

This is the most help I can give you without getting me in trouble with legal crap like DMCA.

static const uint8_t MC_CARDKEY_MATERIAL_1[] = { 0x6A,
static const uint8_t MC_CARDKEY_HASHKEY_1[] = { 0xBA,
static const uint8_t MC_CARDKEY_MATERIAL_2[] = { 0x12,
static const uint8_t MC_CARDKEY_HASHKEY_2[] = { 0x38,
static const uint8_t MC_CHALLENGE_MATERIAL[] = { 0x2C,

static const uint8_t MG_KBIT_MATERIAL[8] = { 0x22,
static const uint8_t MG_KC_MATERIAL[8] = { 0xC3,
static const uint8_t MG_KBIT_MASTER_KEY[16] = { 0x93,
static const uint8_t MG_KC_MASTER_KEY[16] = { 0x05,

static const uint8_t MG_IV_NULL[8] = { 0 };

that is what i use for keys so i dont know what is going on,.
but when binding it just dont work .

edit: I think its my program maybe, i did message it to you a while back