Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

Everything posted by aquasync

  1. 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.
  2. 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 ).
  3. 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.
  4. 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
  5. 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.
  6. 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?
  7. 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..
  8. 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).
  9. 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]; }
  10. 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
  11. 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?
  12. 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.
  13. 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.
  14. 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.
  15. 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
  16. 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?)
  17. 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? Actually I did know that, but it was only because I read the info on your site a few days ago
  18. 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.
  19. Yeah I'll post the source when I've cleaned it up a bit. The uploaded version for instance uses a huge table for one of the things that didn't really make sense, but I've since seen that that part can be done using simpler xors, and the source is down to only around 50 lines. There are some things left to do, like I think I am doing one of the steps in the wrong order, which is making things more complicated, anyway, when its done, I'll post the encryption source, and the decryption source is a fairly basic step from there. It uses an 8 byte data xor table, and I tried xorring that with 0x00 -> 0xff, in the hope that each rom has a specific xor, to try and do kof2002, but no luck. Anyone know of any info on the newer encryptions like neopcm2 (2002), neopvc etc?
  20. Handy, ok - http://up1.fastuploads.com/ss5sp_venc.zip. I'm also trying to see if the kof2002 sound roms and other neopcm2 (2002) games can be done simillarly. So where did those 2 programs come from anyway?
  21. If you allready have the encrypted V roms why are you trying to make encrypted V roms If work out a driver for Mame would'nt it better to be for the encrypted V roms that are allready in use.Mame allready loads them but does not use them at this point. <{POST_SNAPBACK}> I don't already have the encrypted roms, which is part of the reason I did it, saves me downloading them. And it is for the normal encrypted ones - it reverses vconv2, so it produces these 2 files: 272-v1.bin 76A94127 272-v2.bin 4BA507F1 As for uploading it, I thought I'd just be able to attach it to my message, I don't have any web space. Anyone want to host a 3kb zip .
  22. The only mame driver I have seen for this game, doesn't actually use the encrypted v roms, (that was an old one posted by james, presumably the encryption is unknown?), so I found it strange that there are these vconv programs that can decrypt them. With a view to encrypting my own set of v roms, and writing a full mame driver that uses the encrypted ones, I had a go at figuring out how vconv works today. So far, I made a program which will reverse vconv2 (ie. encrypt the 4 v roms, with the 3rd being 3f0f7554), which saves redownloading, and I'll post a new driver later on. I can upload it if there is any other poor dialup soul trying to change the decrypted set into the encrypted one
  23. Nice and easy: ./mame -listsourcefile | fgrep neogeo.c | cut '-d ' -f1 | sed s/.*/move \0.zip folder\r/ > neogeo.bat and the resulting neogeo.bat: ------------------------------------------- move nam1975.zip folder move bstars.zip folder move tpgolf.zip folder move mahretsu.zip folder move maglord.zip folder move maglordh.zip folder move ridhero.zip folder move ridheroh.zip folder move alpham2.zip folder move ncombat.zip folder move ncombata.zip folder move cyberlip.zip folder move superspy.zip folder move mutnat.zip folder move kotm.zip folder move kotmh.zip folder move sengoku.zip folder move sengokh.zip folder move burningf.zip folder move burningh.zip folder move lbowling.zip folder move gpilots.zip folder move joyjoy.zip folder move bjourney.zip folder move quizdais.zip folder move lresort.zip folder move eightman.zip folder move minasan.zip folder move legendos.zip folder move 2020bb.zip folder move 2020bba.zip folder move 2020bbh.zip folder move socbrawl.zip folder move roboarmy.zip folder move roboarma.zip folder move fatfury1.zip folder move fbfrenzy.zip folder move bakatono.zip folder move crsword.zip folder move trally.zip folder move kotm2.zip folder move sengoku2.zip folder move bstars2.zip folder move quizdai2.zip folder move 3countb.zip folder move aof.zip folder move samsho.zip folder move tophuntr.zip folder move tophunta.zip folder move fatfury2.zip folder move janshin.zip folder move androdun.zip folder move ncommand.zip folder move viewpoin.zip folder move ssideki.zip folder move wh1.zip folder move wh1h.zip folder move kof94.zip folder move aof2.zip folder move aof2a.zip folder move wh2.zip folder move fatfursp.zip folder move fatfursa.zip folder move savagere.zip folder move fightfev.zip folder move fightfva.zip folder move ssideki2.zip folder move spinmast.zip folder move samsho2.zip folder move wh2j.zip folder move wjammers.zip folder move karnovr.zip folder move gururin.zip folder move pspikes2.zip folder move fatfury3.zip folder move zupapa.zip folder move panicbom.zip folder move aodk.zip folder move sonicwi2.zip folder move zedblade.zip folder move galaxyfg.zip folder move strhoop.zip folder move quizkof.zip folder move ssideki3.zip folder move doubledr.zip folder move pbobblen.zip folder move pbobblna.zip folder move kof95.zip folder move kof95a.zip folder move tws96.zip folder move samsho3.zip folder move samsho3a.zip folder move stakwin.zip folder move pulstar.zip folder move whp.zip folder move kabukikl.zip folder move neobombe.zip folder move gowcaizr.zip folder move rbff1.zip folder move aof3.zip folder move sonicwi3.zip folder move turfmast.zip folder move mslug.zip folder move puzzledp.zip folder move mosyougi.zip folder move marukodq.zip folder move neomrdo.zip folder move sdodgeb.zip folder move goalx3.zip folder move zintrckb.zip folder move overtop.zip folder move neodrift.zip folder move kof96.zip folder move kof96h.zip folder move ssideki4.zip folder move kizuna.zip folder move ninjamas.zip folder move ragnagrd.zip folder move pgoal.zip folder move magdrop2.zip folder move samsho4.zip folder move rbffspec.zip folder move twinspri.zip folder move wakuwak7.zip folder move stakwin2.zip folder move ghostlop.zip folder move breakers.zip folder move miexchng.zip folder move kof97.zip folder move kof97a.zip folder move magdrop3.zip folder move lastblad.zip folder move lastblda.zip folder move puzzldpr.zip folder move irrmaze.zip folder move popbounc.zip folder move shocktro.zip folder move shocktra.zip folder move blazstar.zip folder move rbff2.zip folder move rbff2a.zip folder move mslug2.zip folder move kof98.zip folder move kof98k.zip folder move kof98n.zip folder move lastbld2.zip folder move neocup98.zip folder move breakrev.zip folder move shocktr2.zip folder move flipshot.zip folder move pbobbl2n.zip folder move ctomaday.zip folder move mslugx.zip folder move kof99.zip folder move kof99a.zip folder move kof99e.zip folder move kof99n.zip folder move kof99p.zip folder move ganryu.zip folder move garou.zip folder move garouo.zip folder move garoup.zip folder move s1945p.zip folder move preisle2.zip folder move mslug3.zip folder move mslug3n.zip folder move kof2000.zip folder move kof2000n.zip folder move bangbead.zip folder move nitd.zip folder move sengoku3.zip folder
  24. All post 2.8 winrar archives use a new method, so you can only use winrar to extract (or 7-zip or other up-to-date software)
  25. Its not surprising that your longer p rom has the same crc. if you check, the extra length will be all 0 - thats the idea of the rom_continue parts in the mame driver. Skid - yeah, i checked to see if the table is static, or rotates around a finite number, with a number of dumps - but it changes continually. One big difference between kof2003 and mslug5, is the write to the p rom (only ever the same spot). When you start the game, it has a lot of code that sort of initializes the table i found, with a fairly obvious looking pattern. From then on it just goes berserk.
  • Create New...