neopcm2

[aquasync]

Just thought I'd move this from the samsh5sp thread...

 

I've made a fair bit of progress on my neopcm2 work. My original program is much simpler now (the 354 * 3 byte table is gone now ), and it boiled down to what looked like 2 variables, a shift and a data xor.

 

Then I got the kof2002 prog (thanks iq_132 ). It was a bit harder to use (it crc checks the input, which needed to be patched away), but after fiddling for a while, I was able to fit it into my previous algorithm, by including an address xor.

 

At this point, it is possible to fully encrypt and decrypt both sets' sound roms (yay!).

The next step is to try and do some of the other neopcm2 games, so I wrote a program (http://up1.fastuploads.com/neopcm2_detect.zip) that can take an encrypted and decrypted set of sound roms, and (try to) detect the 3 parameters.

I tested it, and it works properly on the 2 full sets I have (the above 2).

So it would be good if someone who has the full v sets (with correct crcs!) for samsho5/mslug5 could run this, as it will show if the current method is missing anything.

 

This will let me write drivers for all the neopcm games, and I should be able to release complete drivers in a few days (and a encrypt/decrypt tool).

 

-------------------

 

the sets I believe to be correct are:

mslug5

268-v1.bin 33c6305c

268-v2.bin 1afb848e

268-v1d.bin 14848c5c

268-v2d.bin 696cce3b

 

run this: neopcm2_detect 268 2 2 > mslug5.txt

 

samsho5

270-v1.bin 7541763a

270-v2.bin 4e6e7d98

270-v1d.bin e5c71699

270-v2d.bin 70b7083d

 

run this: neopcm2_detect 270 2 2 > samsho5.txt

 

and then post the text file.

[iq_132]

I tried both of those sets and have gotten nothing.

The program loads, writes a 0 byte.txt and then just hangs.

Am I not waiting long enough?

 

I've heard that the decrypted Vs of these new sets are watermarked, so you may not get exactly the same decrypted Vs that you're looking for.

I'm guessing (odds are that I am wrong) that is the reason why the program doesn't work.

 

btw. I'm sure you know this, but there are two versions of the neo-pcm2. One is the 1999, SNK one (which is used by rotd, mslug4, and pnyaa) and the other is the 2002, Playmore one (which is used by kof2002, kof2003, svcchaos, mslug5, samsho5, and samsho5sp).

Edited November 28, 2004 by iq_132

[Xeon]

hmmm....i tried it too and i thought its just my slug PC.

[aquasync]

Thanks for giving it a go.

Can I just get you to verify it on either kof2002 / samsh5sp?

You should get a whole bunch of stuff, with this at the bottom:

-------------------------

neopcm guesses for 272-v?.bin:

data_xor 4ba46346f091ea62

addr_xor 2

shift 4bc0

-------------------------

neopcm guesses for 265-v?.bin:

data_xor f9e05df3ea92beef

addr_xor a5

shift 0

-------------------------

Could you also try running it without redirecting the output, and seeing how far it gets , and post the command line used too.

(This will let me see if its just a problem loading the files, or if the algo's stuffing up due to possible watermarks).

Are the crcs right too?

 

 

btw. I'm sure you know this, but there are two versions of the neo-pcm2. One is the 1999, SNK one (which is used by rotd, mslug4, and pnyaa) and the other is the 2002, Playmore one (which is used by kof2002, kof2003, svcchaos, mslug5, samsho5, and samsho5sp

Actually I did know that, but it was only because I read the info on your site a few days ago

Edited November 28, 2004 by aquasync

[Xeon]

hmmm.. it worked on kof2k2

 

command-line used - "265 4 2 > kof2002.txt"

 

4 decrypted V ROMs and 2 encrypted Vs. verified by KDev RC dat

 

ive first took mistake the cart-id (wrote 268 instead of 265) and it gave me an illegal operation. when i corrected it, it worked fine.

 

the output was the same without redirecting the result, it only printed the results on screen. used the same command-line without "> kof2002.txt"

 

detecting data xor:
decrypted:
 1  2  3  4  5  6  7  8
1 08 08 08 08 08 08 08 08 
 109800 109578 109848 109719 109648 109323 109623 109940 
2 80 80 80 80 80 80 80 80 
 104778 105755 106378 106211 106173 105531 106252 106337 

encrypted:
 1  2  3  4  5  6  7  8
1 f1 e8 55 fb e2 9a b6 e7 
 109800 109578 109848 109719 109648 109323 109623 109940 
2 79 60 dd 73 6a 12 3e 6f 
 104778 105755 106378 106211 106173 105531 106252 106337 

data xors:
 1  2  3  4  5  6  7  8
1 f9 e0 5d f3 ea 92 be ef 
2 f9 e0 5d f3 ea 92 be ef 

detecting shift (this may take a while):
piece guess = 4096. offset 0
piece guess = 4096. offset 0
piece guess = 4096. offset 0
piece guess = 4096. offset 0
searching.......................................................................
.................................................................................
.................................................................................
....................... done
0 (total dist) / 256 (num found) = 0
shift = 0*piece_size - offset = 0

detecting address xor:
0xa5 (675840)
0xa5 (675840)

-------------------------
neopcm guesses for 265-v?.bin:
data_xor f9e05df3ea92beef
addr_xor a5
shift    0

Edited November 28, 2004 by Xeon

[iq_132]

Here are the results for svcchaos's Vs. (It never finished the shift detection though I left it running for an hour!)

 

C:\Documents and Settings\xxxx\Desktop\New Folder>neopcm2_detect 269 2 2

detecting data xor:

decrypted:

  1  2  3  4  5  6  7  8

1 08 08 08 08 08 08 08 08

  152081 152533 152494 152180 152730 152710 152519 152730

2 80 80 80 80 80 80 80 80

  103511 103709 103831 103835 103641 104136 104147 104309

 

encrypted:

  1  2  3  4  5  6  7  8

1 cb f5 89 a4 65 ef b7 96

  106777 107008 107581 107507 112005 111942 110508 110736

2 43 7d 01 2c ed 67 3f 1e

  72561 72862 73516 73710 78155 78506 76631 76334

 

data xors:

  1  2  3  4  5  6  7  8

1 c3 fd 81 ac 6d e7 bf 9e

2 c3 fd 81 ac 6d e7 bf 9e

 

detecting shift (this may take a while):

searching

 

btw, here's a program that was made to convert svcchaos's V roms

Edited November 29, 2004 by iq_132

[aquasync]

Thanks for the svcchaos program. I'll have a look at that today.

Judging from where it stopped, I probably set too high a lower bound on the address xor...

Ok, so where does it stuff up for samsho5 / mslug5. At the very least it should get past the data xor. Also can you post the crcs/sizes and command lines for them.

 

Btw, where are these program coming from! You thought the samsh5sp one (vconv) was from EGCG, the kof2002 one had spanish/italian error text , and now another one... Its like the people that know how it works aren't telling anyone, just releasing programs (but why?)

[iq_132]

Well... I think some of them were written by Fataku (he's peruvian) and odds are that the others were written by people from EGCG or someone "in the know."

 

I'll edit this soon with the info you want

[aquasync]

Well it turns out that my svcchaos vs are bad, so I couldn't just run it, so once again I patched away the crcs and gave it some random input.

My program then gave exactly the same data xors as iq_132 got, and crashed. I then just changed some of the assumptions (I had assumed that shift % 16 == 0 for faster searching), and it worked:

 

-------------------------

neopcm guesses for 269-v?.bin:

data_xor c3fd81ac6de7bf9e

addr_xor c2

shift 53d8

 

But when I encrypted using those parameters, I got a different crc.

I took a closer look at what the program does, and it patches the first 2 bytes of the rom (to ec29).

 

As I said before, I don't have the good svcchaos v roms to check, but I'd say that the above values are correct, and that it simply patches those 2 bytes. As to whether the patch is valid, I don't know, but the important thing is that its just the same algorithm.

 

The equivalent patch, to the decrypted roms, is to change the byte at c73d8 to 0x2f, and d73d8 to 0xea.

I wrote an example, that will decrypt the encrypted svcchaos roms, but it doesn't restore the 2 bytes (I don't know what they are supposed to be), but if you compare the roms, you'll the v2d's are the same, and the only difference between the v1ds are those two bytes. (http://up1.fastuploads.com/svc_vdec.zip)

 

Long story short - good news (samsh5sp, kof2002 and svcchaos are all known)

 

In the hope that the above mistake is all that prevented mslug5 and samsho5 from working before, I have uploaded a new version that relaxes that assumption.

(http://up1.fastuploads.com/neopcm2_detect2.zip)

 

 

-------------------

 

As an aside, does anyone know of a patch that can fix my v roms. I think they are the bootleg ones.

I'm trying to get to:

269-v1d.bin a81da99a 8388608

269-v2d.bin a8dd6446 8388608

 

And I have

269-v1d.bin e7203930 4194304

269-v2d.bin 675159c3 4194304

269-v3d.bin f8810665 4194304

269-v4d.bin b57b4ea3 4194304

or stuck together

269-v1d.bin dab37bef 8388608

269-v2d.bin 7b3e9487 8388608

[iq_132]

Here's a patch from:

 

269-v1d.bin dab37bef 8388608

269-v2d.bin 7b3e9487 8388608

to

269-v1d.bin a81da99a 8388608

269-v2d.bin a8dd6446 8388608

 

Edit

I'm still having the same problem with mslug5 it gets to the same point and then goes and goes... How long should this take? (I have a p4, 2.4ghz)

Edited November 29, 2004 by iq_132

[aquasync]

Thanks for the svc patches.

As for what's going wrong, it gets past the data xor though right? It should also be able to get past the first part of the shift thing. Is it stuck at the bit where it says searching? You're using the new version?

Unless the roms don't actually come from each other, i think it should generate a shift value, even if its completetly bogus.