What's new
By:

SYS2x6 technical details discussion

Try bind this file. This one should work. Apparently the disc key I pasted here had a wrong digit somewhere. This one I tested and it works.
 

Attachments

i get

PS2 Memory Card Content Key
target Kelf file: 'boot.bin2'
Kbit: 8f 0d 90 b3 f5 c6 26 58 73 91 c3 a2 3b 50 3a f9
Kc : 50 a8 23 47 a4 3e 14 3e df 61 43 73 b7 76 0e 3d

correct key for the dongle:
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

it must be the software im using
 
Last edited:
I took the src from 2011 without any changes and put the correct coh keys in it, binding worked properly.
 
l_oliveira said:
I took the src from 2011 without any changes and put the correct coh keys in it, binding worked properly.
Click to expand...
Like I said I don't know why but it don't work for me, maybe it my version of libusb or auto tools.

But I know if you use a newer sdk and auto tools and libusb it won't compile the src without modifications. ( Doccaz did this and his don't work for me either 😭)

I know if you use a older sdk you get the problems I have. So I will look at my versions and see if making changes works.
 
Last edited:
l_oliveira said:
-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.



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).
...

And:

C:\MCA>fc test.bin test2.bin
Comparing files test.bin and TEST2.BIN
00000028: 17 41
00000029: 9C A9
...

There you go.
Click to expand...
Thanks for this. I now have something to compare against :)
 
l_oliveira said:
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.
Click to expand...

Mine matches these. I also added all the keysets and made them selectable. I think I matched these hex values with the wiki a few dozen times now, but we never know... 8|
 
l_oliveira said:
Don't use plain MinGW, use Msys because that actually works.
Native Linux also work well. I think it might be related to autoconf.
Click to expand...
I'm doing it with native Linux and mingw64, patched a couple of things to make it not complain about autotools and some newer GCC complaints. I also compared the resulting binary behavior after compiling it with a (very old) distro to cross-check I didn't make any boo-boos. So far it works fine for all operations except this one.
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 MG_IV_NULL[8] = { 0 };
Click to expand...

These do match as well. I'll try on the original code and an older toolchain/distro to see if I didn't break anything unintentionally.
 
I used ps2 sdk from 2014
Autotools 1.5 (it complained about autoconf needing to be 1.6 so I updated it)
Libusb 1.2.2.0
 
Can someone is able to explain how are 18 bytes calculated from provided key? I compared vanilla rom to donor and to converted one, and found out that converted rom have 18 bytes different from donor and vanilla dump scattered over the rom. My conclusion is that they are somehow calculated using 32 key bytes. If that could be figured out it would be possible to make a conversion using just HxD editor, I made a experiment and took virgin rom put changes with HxD editor and rom booted with no problem.
 

Attachments

  • Changes.png
    Changes.png
    45.7 KB · Views: 153
BilonFullHDemon said:
Can someone is able to explain how are 18 bytes calculated from provided key? I compared vanilla rom to donor and to converted one, and found out that converted rom have 18 bytes different from donor and vanilla dump scattered over the rom. My conclusion is that they are somehow calculated using 32 key bytes. If that could be figured out it would be possible to make a conversion using just HxD editor, I made a experiment and took virgin rom put changes with HxD editor and rom booted with no problem.
Click to expand...
How things are calculated is already posted by l_oliveira.
 
l_oliveira said:
I took the src from 2011 without any changes and put the correct coh keys in it, binding worked properly.
Click to expand...
Try taking the one from archive.org and compile it.
Don't compile src you have laying around, because the few trying to compile this are not using a version off your computer we are using the only version found online.
 
Last edited:
can someone throw me a bone here like send me a list of prerequisites or a grep of installed software.

im no stranger to code ( https://web.archive.org/web/20080731051032/https://forums.ps2dev.org/viewtopic.php?t=10688 ) and have been doinging this a while however this just makes no sense to me why i get a different result .

i tried after getting mcboot compiled way back when https://web.archive.org/web/20080801035341/http://gshi.org/vb/showthread.php?t=3097
once i got help with that i tried to compile ps3mca-tool and couldn't get it to work so this nice guy name jimmy gave me a copy of the ps2 version pre compiled and i lost it. now i guess im a stranger to the community but i still would like to compile this one day.
 
Last edited:
BilonFullHDemon said:
Can someone is able to explain how are 18 bytes calculated from provided key? I compared vanilla rom to donor and to converted one, and found out that converted rom have 18 bytes different from donor and vanilla dump scattered over the rom. My conclusion is that they are somehow calculated using 32 key bytes. If that could be figured out it would be possible to make a conversion using just HxD editor, I made a experiment and took virgin rom put changes with HxD editor and rom booted with no problem.
Click to expand...

There is no 18 bytes, the stuff on the 0x28 offset of boot.bin file is two 16 byte KEYS. Due to the purpose of their use/context, they can't be treated as separate because both need to be correct for the file to decrypt therefore you copy both together.
 
l_oliveira said:
Don't use plain MinGW, use Msys because that actually works.
Native Linux also work well. I think it might be related to autoconf.
Click to expand...
i have msys and mingw installed and i use the msys.bat in the msys folder.

native linux i still recieve the same thing , why is that?

wsl i get the same also, why?

can you make a docker of your development environment and pm me or doccaz it ?
 
Last edited:
I call bs it don't work.gif


I call bs, im using msys even with the warning which is only the unformat function
 
You should only run bootstrap once, to have it create a makefile that is correct for your platform. I once tried to edit the makefile by hand to insert ifdefs and I ended with a file that failed at cryptography, just like yours. I suggest you start over from the original source tree, only run bootstrap once then use make/clean to recompile after modifying. You can keep the current files on a different place and move over the mods once it builds a exe that works properly. I suggest you first try to build a file that works properly with PS2 memory cards.
 
l_oliveira said:
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?
Click to expand...
No I thought they were blank but they are ps2. I paid for a uncapping but waiting on full code exploration to come back
 
i started with fresh code and only ran bootstrap once and tried signing the boot.bin and the signature changes based on directory that im "cd"ed to


Code: 
Microsoft Windows [Version 10.0.19045.3803]
(c) Microsoft Corporation. All rights reserved.


C:\Users\DJ>C:\mca-coh\src\ps3mca-tool.exe -ck boot.bin


C:\Users\DJ>C:\mca-coh\src\ps3mca-tool.exe


C:\Users\DJ>C:\mca-coh\src\ps3mca-tool.exe
PS3MCA-TOOL v1.3
Copyright (C) 2011 - jimmikaelkael & 'someone who wants to stay anonymous'


Usage:
C:\mca-coh\src\ps3mca-tool.exe <command> [<arguments>]


Available commands:
         --mc-info, -i
         --mc-free, -f
         --mc-image, -img <output filepath>
         --mc-unformat
         --mc-format
         --list, -ls <mc path>
         --extract-file, -x <mc filepath> <output filepath>
         --inject-file, -in <input filepath> <mc filepath>
         --make-directory, -mkdir <mc path>
         --remove-directory, -rmdir <mc path>
         --remove, -rm <mc filepath>
         --file-crosslink, -cl <real mc filepath> <dummy mc filepath>
         --content-key, -ck <disk kelf filepath>
         --sign-kelf, -k <disk kelf filepath> <card kelf filepath>




C:\Users\DJ>C:\mca-coh\src\ps3mca-tool.exe -ck boot.bin
PS3MCA-TOOL v1.3
PS2 Memory Card Content Key
target Kelf file: 'boot.bin'
Kbit: 70 da f4 c3 95 a4 be 36 0b 20 35 c8 79 af 45 ca
Kc  : 1b 8a ae 63 28 3f 3b 0c ea 28 e9 c1 9c 8a e8 e0


C:\Users\DJ>C:\mca-coh\src\ps3mca-tool.exe -k boot.bin boot2.bin
PS3MCA-TOOL v1.3
PS2 Memory Card Content Key
target Kelf file: 'boot2.bin'
Kbit: 70 da f4 c3 95 a4 be 36 0b 20 35 c8 79 af 45 ca
Kc  : 1b 8a ae 63 28 3f 3b 0c ea 28 e9 c1 9c 8a e8 e0


C:\Users\DJ>cd C:\mca-coh\src


C:\mca-coh\src>C:\mca-coh\src\ps3mca-tool.exe -k boot.bin boot2.bin
PS3MCA-TOOL v1.3
PS2 Memory Card Content Key
target Kelf file: 'boot2.bin'
Kbit: 8f 0d 90 b3 f5 c6 26 58 73 91 c3 a2 3b 50 3a f9
Kc  : 50 a8 23 47 a4 3e 14 3e df 61 43 73 b7 76 0e 3d


C:\mca-coh\src>
C:\mca-coh\src>ps3mca-tool.exe -k boot.bin boot2.bin
PS3MCA-TOOL v1.3
PS2 Memory Card Content Key
target Kelf file: 'boot2.bin'
Kbit: 8f 0d 90 b3 f5 c6 26 58 73 91 c3 a2 3b 50 3a f9
Kc  : 50 a8 23 47 a4 3e 14 3e df 61 43 73 b7 76 0e 3d


C:\mca-coh\src>cd c:
C:\mca-coh\src


C:\mca-coh\src>cd ..


C:\mca-coh>cd ..


C:\>C:\mca-coh\src\ps3mca-tool.exe -k boot.bin boot2.bin
PS3MCA-TOOL v1.3
PS2 Memory Card Content Key
target Kelf file: 'boot2.bin'
Kbit: 97 16 24 69 bb ae dd 1e 03 f8 99 a6 15 59 7b 81
Kc  : 98 dc 44 e1 66 28 e3 fa 0d 4a 9b 31 fb 92 2a 30


C:\>
 
Last edited:
You must log in or register to reply here.
Back
Top