aquasync

Its fairly trivial to move your gfx and sound roms between any of the different versions, so it doesn't matter too much. I have left mine in the pcb configuration, as it is the most encrypted, and presumably most legitimate.

Thanks for making those, the unfortunate problem is that I'm an idiot . The first patch is correct, but the second isn't, because the.bat should read like this "uips c v2_1.ips 268-v2.new 268-v2.bin", on the 3rd line. (It currently just creates the first patch again ).

Ok, I uploaded a fixed mslug5 encrypter (http://up1.fastuploads.com/ms5_venc2.zip). Included is a.bat file that will encrypt with 2 different methods, and make patches of the results against the real vs. (33c6305c & 1afb848e) Ideally, one of the sets of patches should be quite small, and that will mean it was the right method, and those patches are the fixes/watermarks. If anyone has those roms, can they post the crreated patches plz.

Ok, update on the matrimelee vs: The first two bytes of pim's encrypted v1 (86b6ef14), were c4c4, ie the first byte of the data xor, ie they probably came from encrypting 2 0s. This was the case with the svcchaos vs, where the first 2 (erroneous) bytes were c3c3. I first tried switching the 2 bytes of pim with ec29 (as per svcchaos), then with (perhaps more logically) eb23 (which is ec29 ^ c4 ^ c3). Still no luck. So I decided to go fishing . I had a program generate all 256 * 256 crcs for all 2 byte combinations, and lo and behold, for f018, I got a4f83690. (At this point I should probably note the typo of a4f83680 from iq_132's driver, that stressed me for a little while ). So, perfect pim v's for all . The differences in encrypted and decrypted form: --- 266-v1.bin 86b6ef14 800000 +++ 266-v1.bin a4f83690 800000 0 c4c4 f018 --- 266-v1d.bin 352b0a07 400000 +++ 266-v1d.bin 435f33cf 400000 21e0 00 34 +ffff 00 dc

Sorry I didn't see that, sure, I think the only one missing is mslug5 right? Which I've got here somewhere... http://up1.fastuploads.com/ms5_venc.zip Maybe it'll work for me now with these new patches (thanks xeon). That site has some useful info, I finally made the 2 encrypted svcchaos gfx roms, and its possible to go between all the sets now (svcboot/svcplus <-> svcchaosa <-> svchaosnd <-> svchaos). So, what we need now is for the m1 encryption to be figured out. Does anyone have any info on this, or have good pairs for a bunch of roms? -- Actually scrap that program. I just realised the one i posted expects 4 vds, and that I'd left the address xor as 0x4e000 instead of 0x4e001, which I was testing. I'll post a proper one later. I'm getting this at the moment: 268-v1d.bin: 14848c5c 268-v2d.bin: 696cce3b 268-v1.new: e4a934f9 268-v2.new: c40613ed or changing the address xor to 4e000 (it just seemed strange to be the only one with any bits set <12) 268-v1.new: 529d9191 268-v2.new: e4485fd5 So it doesn't look good. Perhaps when someone gets a chance they can post a patch between the encrypted decrypted roms, and the normal ones.

Well all the values look the same, and its the same algorithm (although using BITSWAP expects a whole lot of the compiler's optimizer if it is going to be as fast as just switching bits 16 and 1 directly). Whats interesting is that kof2003 is included, but then the values look to be placeholders. --------------- I was trying to figure out why I can't get the real mslug5 vs. Encrypting gives me this: 268-v1d.bin: c3540e0d 268-v2d.bin: 077bd2f4 268-v3d.bin: 39b14567 268-v4d.bin: 969ff3b2 268-v1.new: e66e4f61 268-v2.new: 94b46260 And I'm expecting these: 268-v1.bin 33c6305c 268-v2.bin 1afb848e I think the problem is my vs are bad. Sticking them together, they are 268-v1d.bin 0ab43275 8388608 268-v2d.bin 358b1419 8388608 When they should be, 268-v1d.bin 14848c5c 268-v2d.bin 696cce3b Does anyone have/can make a patch between between these v's?

Ok, I uploaded the program. I get this output with my vs: 266-v1d.bin: 352b0a07 266-v2d.bin: 945f8831 266-v3d.bin: e8362fcc 266-v4d.bin: 393c9a62 266-v1.new: 86b6ef14 266-v2.new: d0f69eda Which seem the same as yours. Are there newer ones than these then? oops, forgot to add : http://up1.fastuploads.com/pim_venc.zip. If your crcs are different / you get the right encrypted ones, can you post your decrypted crcs..

Well, yeah, soon as I got the values from that site iq_132 linked, I tried encrypting mslug5 and pim. Neither of them got crc matches though, probably because of some watermarks/patches again. Ie, i could post an encrypted, but you won't get the crcs you're probably looking for. If anyone has both encrypted and decrypted, we can get a patch of the difference between the encrypted decrypted roms, and the plain encrypted roms (if that makes sense). But isn't there no good dump of the matrimelee encrypted roms anyway? Well I could probably do it, but I haven't seen any crcs (let alone a dump) for the encrypted vs. (granted I hadn't been looking).

Interesting site, I should be able to properly encrypt my newer roms with some of that info. For what its worth, here are the drivers I was working on (much the same, just less verbose): //////////////////////////// // switch bits 16 and 1 #define swap_1_16(i) \ (i & ~0x10001) | \ (i & 1) << 16 | \ (i & 0x10000) >> 16 ) void neopcm2_decrypt(byte *data_xor, int addr_xor, int shift) { int i; int v_size = memory_region_length(REGION_SOUND1); UINT8 *sound = memory_region(REGION_SOUND1), *buf = malloc(v_size); for (i = 0; i < v_size; i++) buf[swap_1_16(i) ^ addr_xor] = sound[(i + v_size - shift) % v_size]; for (i = 0; i < v_size; i++) sound = buf ^ data_xor[i & 7]; free(buf); } /* known values: samsh5sp: data_xor 4ba46346f091ea62 addr_xor 2000 shift 4bc0 kof2002: data_xor f9e05df3ea92beef addr_xor a5000 shift 0 svcchaos: data_xor c3fd81ac6de7bf9e addr_xor c2000 shift 53d8 samsho5: data_xor cb297d43d23ac2b4 addr_xor a000 shift 14d40 pim: data_xor c483a85f212764af addr_xor 1000 shift 31e0 mslug: data_xor c3fd81ac6de7bc9e <= same as svcchaos addr_xor 4e001 shift 1d30a */ DRIVER_INIT( samsh5sp ) { ... UINT8 data_xor[] = { 0x4b, 0xa4, 0x63, 0x46, 0xf0, 0x91, 0xea, 0x62 }; neopcm2_decrypt(data_xor, 0x2000, 0x4bc0); ... } and so on and so forth, with the other values // and the fairly straightforward reversal of the decryption, from neopcm2_tool void neopcm2_encrypt(byte *data_xor, int addr_xor, int shift) { int i; for (i = 0; i < v_size; i++) buf = sound ^ data_xor[i & 7]; for (i = 0; i < v_size; i++) sound[(i + v_size - shift) % v_size] = buf[swap_1_16(i) ^ addr_xor]; }

They beat me, damn it! Whatever, I just want to see it be public knowledge. I'll have a look at their values, they seem to be all the same. I just finished doing samsho5, and I'll post the info on the watermarks/patches below. It was good practice, for doing other more complicated encryption, and I managed to do the last one without any program as a guide, so I'm getting better ------------------ the samsho5 decrypted vs: 270-v1d.bin 6849136c 4194304 270-v2d.bin 222e1774 4194304 270-v3d.bin cd9e7adc 4194304 270-v4d.bin 8b305cac 4194304 stuck together 270-v1d.bin e5c71699 8388608 270-v2d.bin 70b7083d 8388608 encrypting them gives these: 270-v1.new c8b2a192 8388608 270-v2.new 3a339e67 8388608 the encrypted vs: 270-v1.bin 7541763a 8388608 270-v2.bin 4e6e7d98 8388608 decrypting those gives: 270-v1d.new 01c97b40 8388608 270-v2d.new ee3063ff 8388608 and you can see the differences when encrypted: --- 270-v1.bin 7541763a 800000 +++ 270-v1.new c8b2a192 800000 0 a0a6 2929 +f52be~100000 da09d7c3 8e8e8e8e +3cd3f f1f6 fbff +c32be db 8e +fffff f8 8e +1ad81 0000 fff7 +7fdc 0000 fff7 +dd29e 4b 8e +fffff 49 8e --- 270-v2.bin 4e6e7d98 800000 +++ 270-v2.new 3a339e67 800000 f52c0~100000 5b4ac3c8 088e8e8e +1ad3f fab9 febd +e52be~100000 518221c3 8e8e8e8e or when decrypted: --- 270-v1d.bin e5c71699 800000 +++ 270-v1d.tmp 01c97b40 800000 0 45 08 +ed40 00 89 +ffff 00 8f +e12be~100000 45454545 11c21c08 +4cd3f 30 3a +ffff 34 3d +a32bf 45 10 +fffff 45 33 +26d5f 34 cb +8021 82 7d +7fdd 3c cb +8021 8a 7d +c127d 45 80 --- 270-v2d.bin 70b7083d 800000 +++ 270-v2d.tmp ee3063ff 800000 0~100000 45c3454545 8290810803 +2ed3f 35 31 +ffff 76 72 +c12bf 45 9a +fffff 45 49 +fffff 45 ea

Sorry to be generating all these random programs, but I have one last one I'd like to try, which relaxes practically all of the assumptions. It is somewhat slower, but as a guide, it shouldn't take any longer than about twice as long on the ones which it works for (svcchaos, samsh5sp & kof2002). (http://up1.fastuploads.com/neopcm2_detect3.zip) Can you just post the output for mslug5 and samsho5, and if its still no good, I'll grab one or the other's encrypted roms to do next. Also, just wondered how you were attaching stuff before?

Well the xors were fine, but for it not to have gotten anywhere in the next part, means that it couldn't find any block of 512 bytes in the first 2mb of the decrypted one, that a partially decrypted other one had in common. Which is, um, surprising I guess. I'll have to take a look at the actual rom myself. I have the real svcchaos v's now (thanks to the patches), and I verified that the crcs are correct. I have shown here a diff of the effects of the patch, on the decrypted and encrypted roms: --- 269-v1.bin 34f9e19c 800000 +++ 269-v1.new c659b34c 800000 0 c3c3 ec29 --- 269-v1d.bin a81da99a 800000 +++ 269-v1d.tmp ff64cd56 800000 c73d8 00 2f +ffff 00 ea Obviously, both `c659b34c' and `a81da99a' can't both be correct (ie. it should be either patched or not), but thats not a big issue.

Its hard to say really. Can you post the preceding output. (Seeing as you can't redirect it, just use right click->mark. and select it all). If the rest of the output looks fine, then I'm not sure whats going wrong, and i'll probably have to bite the bullet and download it.

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.

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