Byteswapping SNES on purpose

[jwiggams]

Hey all, new here but figured this was a good place to ask:

I'm working on a demo for SNES, and I've been looking into building a custom board for it that uses byteswapping as a cheap and easy (albeit not super effective, I know) method of anti piracy. It's more of a deterrent than actual protection...really.

I want to have the ROM data byteswapped like a Sega Genesis game, but then on the hardware level have that swap undone by switching the data lines around.

My question is, can this be done? And if so, how do i swap the data lines on the board so the SNES sees the proper format?

Thanks for any help

John

[tepples]

Is this with an 8-bit ROM or a 16-bit ROM? To byte-swap an 8-bit ROM, put an inverter between cart edge A0 and PRG ROM A0. This can be 1/6 of a 74HC04 (Hex Inverter), 1/4 of a quad NAND, NOR, or XOR with the other input tied to ground or power as appropriate, or whatever else might be left over from other logic on your cartridge board. To byte-swap a 16-bit ROM, swap the multiplexer inputs from D15-D8 with those from D7-D0 out of the ROM.

It won't even be a deterrent to dumping using a Retrode, Kazzo, Lythium, or other device with a cartridge slot. The only thing it'll deter is desoldering the PRG ROM and dumping it in an EPROM programmer, and that's more labor than just using a Retrode.


EDIT: Explained how an XOR relates to an inverter

[jwiggams]

Thanks for the reply!

I guess I didn't think of those dumpers... I may have to think of other options.

But as for the using a XOR between A0 on the cart bus and A0 on the ROM, how does that do the byteswapping? I thought that was all controlled by the data pins?

[tokumaru]

Switching the data lines will scramble the bits within each byte. XORing (inverting) A0 will cause odd bytes to be read when the CPU tries to read even bytes, and vice versa.

[lidnariq]

Tepples meant to say "an inverter".

The simplest way to defeat a simple cart dumper is to make something that will change the value read by the SNES depending on something that will be changed by the game as it runs. For example, something that reversed the bytes within each 16-byte block depending on a latched value.

However, as is always the case with DRM schemes (and this is one), it really just comes down to the question of: how much effort you want to put in order to make someone else put in some smaller amount of effort to undo it. (And it's always easier for the cracker than for the protector)

[jwiggams]

Tepples meant to say "an inverter".

So would something like one gate on a 7400 work? With inputs connecting to SNES A0 and the output going to ROM A0?

However, as is always the case with DRM schemes (and this is one), it really just comes down to the question of: how much effort you want to put in order to make someone else put in some smaller amount of effort to undo it. (And it's always easier for the cracker than for the protector)

That's the crappy part I guess. With so many repros being made out there I was hoping that I could at least delay stuff being ripped... But it may be more hassle than it's worth, I suppose.

[tepples]

If you really want to apply digital restrictions management, do like Seta did for that Morita Shogi game: put half of the game logic on a 32-bit MCU.

[Kismet]

Hey all, new here but figured this was a good place to ask:

I'm working on a demo for SNES, and I've been looking into building a custom board for it that uses byteswapping as a cheap and easy (albeit not super effective, I know) method of anti piracy. It's more of a deterrent than actual protection...really.

I want to have the ROM data byteswapped like a Sega Genesis game, but then on the hardware level have that swap undone by switching the data lines around.

My question is, can this be done? And if so, how do i swap the data lines on the board so the SNES sees the proper format?

Thanks for any help

John

Hate to pooh-pooh on this idea, but all forms of DRM are easily defeated once people know how the DRM works.

DVD's were defeated by knowing the CSS key, leaked through a software decoder, once it was out, it was out.
Bluerays, likewise were defeated by keys being leaked in software decoders.

The only way you prevent piracy is with ROM cartridges that have their own crypto-processor. This is how and why satellite and cell phone (GSM/LTE) cards can't be cloned. But they need to be paired to a matching crypto processor in the hardware, and the SNES just doesn't have that. However the SNES does support running expansion hardware chips. So effectively what you could do is pre-encrypt the data on a second ROM chip, and have the unencrypted rom chip verify that the chips signature are correct before booting the expansion chip to decrypting the ROM chip.

Boot rom -> expansion chip -> real rom.

Let's not even get into latency.

It's all more trouble than it's worth. Every scheme is eventually broken, and for the most part, the scheme is broken by trusting that the device you are running the software on has no debuggers on it. To give you an example, the way "private servers" for MMORPG's are created is not by decrypting the data the server sends, but by dumping the decrypted data from game client's RAM. They then walk backwards by using the same cryptoscheme on their private server. And that is considered some of the highest-end lowest-payoff hacking.

The weak point will always be the software itself. Even some early "30 day evaluation" software on PC's tried this scheme. In order for the software to actually work, it has to be decrypted, and the pirates just dump the software out of the RAM once it's running. Virtual Machines have only made this easier.

If you really want to prevent piracy in a cheeky way, the actual solution is to hide a key in the expansion chip, and when the key isn't found, you make the game unwinnable. You'd be surprised at how effective this can be at outing pirates, despite being obvious, http://www.greenheartgames.com/2013/04/ ... of-piracy/ .

That ups the piracy skill from "dump and run" to "dump, hack and run" but in todays kinds of emulators and things like the Retrofreak which let you enter game genie codes, you can can patch around even the cheeky things.

Back in the 80 and 90's software sometimes came with manuals or "license dongles" that would replicate this "hide a key" scheme. Sometimes all you need to do make it not obvious so the "zero day" dumps become useless and ruin the reputation of the pirate.

[lidnariq]

So would something like one gate on a 7400 work? With inputs connecting to SNES A0 and the output going to ROM A0?

Yeah, that would work.

That's the crappy part I guess. With so many repros being made out there I was hoping that I could at least delay stuff being ripped... But it may be more hassle than it's worth, I suppose.

Like I said, it really just depends on how much effort you're willing to go to. (And how much effort you're willing to learn/invest in designing obfuscating PCBs and/or modifying a debugging emulator).

Options could be as "simple" as using extra hardware to divide the ROM into multiple different images, or to shuffle different regions of memory depending on something other than just address.

But it's always just a matter of time. I found this writeup (from the PS1 era) to be a fun read about it.

[AWJ]

Any kind of simple address- or data-line swapping won't work as "protection", because any device that dumps the ROM via the cartridge slot will get the same unscrambled data that the SNES does.

[Fisher]

If you want to pin swap your ROM, Farid has done a nice tool for this task.
Take a look at this topic.
But as said before, any device that dumps the game through the connector will succeed in copying it.

[jwiggams]

Thank you everyone for the feedback.

I'll leave the idea alone for this right now. Doesn't seem worth the hassle at all, especially for the extra difficulty and cost involved.

Thanks again

[Fisher]

Maybe the discussion on this thread could give you some ideas.