Cracking unlicensed SNES games/HKOs

You really should have had a look at xmvssf. It has the same protection as pokemon stadium, but the correct return values can be guessed and from that the correct jumps for pokemon stadium can be deduced.

The other carts all have different protections.
I only own Tekken 2 and Soul Blade. All of them could be reverse-engineered without the cart except for Tekken 2. You gotta have the cart for that one. It's pure protection evilness.

The xmvssf/ps protection itself is very simple. I don't know the actual range where it can be accessed, cause the games only seem to use $88:8000 and $80:0000, but I guess that the protection on the real cart can be accessed either from bank $80 to $ff or from $80 to $bf.

Anyway, after guessing some correct values for xmvssf, I immediately noticed that the number of set bits for input and output are always the same. Obviously, there was some kind of hardware latch present that swapped the bits in a certain pattern.

To make a long story short, here's the bitswap pattern:
76543210 becomes 06712345

That'd mean that for example writing $f4 to $88:8000 returns $6b on $80:8000.
Pretty simple and also very cheap to implement in hardware.

Picachu might have the same protection, I'm not sure. It's been too long since I cracked that and it seems I didn't take any notes, unfortunately.

Soul Blade has another protection and was very obvious about what values it expected, so I didn't bother finding out how it worked, just gave it the values it was looking for and be done with it. Will have another look later.

Tekken 2 is a bit more complicated. It accesses the protection in a very strange way, always reading/writing the same data $f0 times.
I had a look at the cart and indeed, each access must be repeated a couple of times to be registered.(typically around 7-30 times)
At first, I was puzzled by this, because I was expecting a simple bitswap pattern.
My conclusion was that they used a microcontroller here.
It's pretty obvious that the mc sometimes misses the accesses from the s-cpu, so they have to be repeated often enough to make sure they always come through.
Also, the output pattern is too complicated to pull off with a couple of logic chips.

The protection itself is accessed in banks $80-$bf.
accessing (read/write, doesn't matter) adress lines A8,A9,A10 in these banks in a certain sequence makes the mc return a 4bit value.
$8080xx clears the sequence
$8081xx reads the result.

As an example, the access sequence $80:8000,$80:8300,$80:8400,$80:8700 first clears the previous result, then returns $c on data lines 0-3 when reading $80:8100.

I was thinking that it maybe was just xoring/adding/whatever the access results, but I couldn't spot any pattern that makes sense. Also, accessing the same region multiple times in a sequence doesn't change the result.

The way they implemented that into the s-cpu program was very evil. Apart from the usual jumps and data loads depending on the returned result from the protection(which can be guessed with ease because it just returns 4 bits), it was also using that returned data to calculate the next protection sequence adresses. I just popped the cart in and entered the sequences manually, then gave it the return values it was looking for.

Overall, I agree that patches are the way to go here. Emulating protections only one or two crappy games use isn't worth the effort.
Also, you'd probably have trouble detecting those roms in a generic way.

Phew, that was quite a rant...


[edit]
Pocket Monsters indeed uses the exact same protection as X-Men vs Street Fighter and Pokemon Stadium.

The Soul Blade protection is the weakest I've ever seen.
Adresses $xxx0-$xxx3 in banks $80-$bf always read $55, $0f, $aa, $f0
Banks $c0-$ff return open bus.