Search results

My copy is English, it has a second sticker telling it may loss data if connected to a ps2.

Copying it is a non issue, the copies of the data ONLY work on the original card they came from due to cryptography on the card itself. The cards are not married to the dongle.

I own one, it IS a standard retail memory card with a HUGE STICKER on the back saying to not insert it on a normal PS2 to not cause loss of data.

SCII campaign card is a regular PS2 memory card. It is encrypted using the card itself to encrypt, we don't know how to enable that feature and that is what keeps the data from working on different cards. We would need to read, decrypt then encrypt again to put it on a new card.

Yet nobody can make copies of the campaign memory card. lol

5V Neo Geos (regardless of chipset type) do not have enough power to supply the multi due to a protection circuit it has on the input.

There is no need to hack anything, we can modify the files already. What is the problem is that a lot more research is necessary to be able to do that much. There is no longer any need to make hardware modifications, now everything boils down to analyze the software and the encryption...

There is nothing in common between System 246 and Python2. Python2 use a retail PS2, the hdd is protected with HDD-DNAS, a DRM protection SONY developed for consumer products and is completely unrelated to MAGIC GATE... http://www.system16.com/hardware.php?id=976 Python1 is related to System...

Conquest card is not paired to the dongle but it cannot be copied to a different card and cannot be tampered with (modified) until we understand how the PS2 writes to it. Per card encryption is used and the data format is non standard.

What we know to this point is: - It uses a different ECC data format than normal cards - Encrypted sectors are encrypted using the per card seed/key so copying the NAND to a different card won't work even if ECC is correct.

Seriously you don't need to make ASICs, and those are likely SoCs, a tiny mcu with security enclave and a firmware. We have the keys, it should be simple make a dongle out of a raspberry pico.

I don't know, maybe decompress it then analyze it on IDA or other disassembler (yes it is compressed, with a self decompress asm stub).

Get pre compiled or build kelf-tool.exe and then put this file named "PS2KEYS.dat" at the root directory of your user profile. Then you can use it to decrypt the boot.bin file I posted. This file has correct keys to decrypt coh boot.bin but it will only work if it is of the disc type. Edit: To...

I'd like to call your attention to this: ARCADE_KBIT=69A1EF2E577FAEE758529AD846558E05 ARCADE_KC=DA66A5D4311C3B5A39423C7BB956D35F From: https://www.psdevwiki.com/ps2/Talk:Keys#Etc_keys Which mean the content keys decrypted successfully and the rest of the file should decrypt properly as well...

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

Don't use full dumps that way because the NAND chip has error correction data that will change over time. ONLY WORK ON LOOSE FILES.

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.

Don't use plain MinGW, use Msys because that actually works. Native Linux also work well. I think it might be related to autoconf.

I took the src from 2011 without any changes and put the correct coh keys in it, binding worked properly.

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.