aquasync
-
Posts
28 -
Joined
-
Last visited
Content Type
Profiles
Events
Forums
Blogs
Downloads
Posts posted by aquasync
-
-
ok here are the patches created from venc1..
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
-
Aqua, I would still be appreciative if you could post one of those encryption programs for matrim, mslug5, and samsho5 smile.gif
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..
-
hey aqua, can you try making a matrimelee V encrypter?
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?
Anyway aquasync there is still a set of V roms to work out and thats kof2003Well 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
-
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?)
-
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 samsho5spActually I did know that, but it was only because I read the info on your site a few days ago
-
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.
-
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?
-
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?
-
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.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
. -
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
-
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
-
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)
-
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.
SNK vs Capcom: What are the correct set?
in Arcade Emulators [/pc/arcade]
Posted
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.