Anti piracy block help

[Imagesowner2]

Hello everyone. I've got a game i would like to release but would like to install a code to stop people from burning it onto cart. But it would still have to work on emulators. Is there a sequence I can write into the code to help me do this ? I'm referring to a 8 bit NES game.

[BigEd]

Seems very unlikely to be possible. Why not open-source it? There's an opinion that an author's difficulty lies not with unauthorised copying, but with obscurity. Get your work out there as widely as you can.

Cheers
Ed

[GARTHWILSON]

I'm not familiar with how NES works, so maybe this is not the answer; but the only thing I can think of is that variables be mixed with the code, such that the code cannot be in ROM. Even a single instance of self-modifying code would prevent putting it in ROM. If they like your product enough to pay for a cartridge to burn it into though, they should like it enough to buy it from you, right? I'm all for the open-source thing too though, like Ed said. All the software on my PCs, including the OSs, is open-source. (No, I don't patronize Uncle Bill one bit.)

[BigEd]

Nice idea with the ROM-detection... but the emulator people work really hard at accurate emulation, and some of their test cases are taken from copy-protection schemes. It's unlikely they'd allow writes to ROM. What's really being asked is to detect whether or not you're running in emulation, which means arranging to do something so obscure that the emulator writers have not yet modelled it.

Matt Godbolt has been writing up some of his work on jsbeeb at
http://xania.org/201405/jsbeeb-emulatin ... javascript
and you'll see he's modelling the exact cycle that memory accesses occur in, including the double-writes of a RMW instruction. This is far more effort than needed for simple execution of obvious code. (He's working with RichTW on this.)

Cheers
Ed

[teamtempest]

As has been said, the only thing that readily comes to mind is to do something that works in RAM but not in ROM.

I'm not sure I'd go so far as to mix code and variables, but I might put variables in a block immediately after the code so that area would appear as ROM if burned to a cart.

An interrupt routine that does nothing but update a RAM location and check to see that it does in fact update might be able to detect if that location has suddenly turned into ROM. Or a similar routine could be part of the main game loop. It could be put to use as a pseudo-random number generator, if a practical use of it was needed.

The whole game might be encoded in its start state and decoded during initialization, a process that would fail if the result can't be written back to ROM. Of course a "freezer" program could save the decoded state, and a determined adversary could track down and eliminate the need for a decoding step.

Actually for a certain type of adversary the most fun your game can provide will be breaking its copy protection scheme.

[Dr Jefyll]

BigEd wrote:

What's really being asked is to detect whether or not you're running in emulation, which means arranging to do something so obscure that the emulator writers have not yet modelled it.

If I understand this properly, what we want is a method that will let the emulator work but cause actual hardware to fail. IOW, success may lie with finding some quirk emulator writers have not yet modelled, and causing the game to rely on that unmodelled behavior! But the success could be short-lived if the emulators are constantly being improved. (If in future they emulate the quirk then the game will think it's real hardware, and stop.)

There's one quirk not addressed in the blog Ed linked to, but I don't know if it's applicable. It's discussed here on 6502.org: A taken branch delays interrupt handling by one instruction

The blog is Beeb-related, and the OP is interested in NES. Are they the same CPU? (The topic I linked to seems to be for NMOS 6502.) Maybe this delayed interrupt thing ought to be added to emulator writers' to-do list!

-- Jeff

[nyef]

I actually looked at this from a different angle some fifteen years or so ago: As part of a community of hobbyist NES developers and "emulator" developers, we were at one point looking into what we could do that would work on real hardware, but be so stupidly expensive to simulate that nobody would bother to make it work in their "emulator".

I think that the absolute craziest setup involved the DMC audio channel DMA, stray bus capacitance, and trying to execute code from unmapped address space. The idea was to start up the DMC DMA on a block that was mostly a no-operation (whatever no-operation) but where the last byte or so on the sample was an RTS or RTI instruction, then jump to unmapped space. The CPU would start executing NOPs because of the stray bus capacitance (refreshed by the DMA channel) until the end of the sample, at which point it would return.

Problem is, I don't belive that this would work to reject real hardware as opposed to emulators, for the simple reason that it requires executing from unmapped address space, which is sufficiently off-the-wall that it is likely to break the emulators.

You're also going to run into things like emulators that run the CPU simulator a cycle at a time, dealing with each memory access as it happens, with the PPU in charge of the timing chain because it needs to render three pixels per CPU cycle, in order to get absolutely perfect video output (you can tell when an emulator does this in Crystalis, because scanline-granular emulators cause the text box to jump by a scanline every so often, while a cycle-by-cycle emulator only causes the first four or five eight-pixel blocks on the first scanline of the text box to flicker).

On the other hand, I've been out of the NES emulation loop for about the past thirteen years, so there might well be an angle that I don't know... But expect your game to break on some emulators because they start supporting the hardware just that little bit more accurately.

[White Flame]

If somebody gets their own personal one-off vanity cart made, do you have a problem with that?

If somebody makes a run of these or offers them for sale, I think you'd be able to see where they're coming from and offer them a friendly C&D. No need to try fringe technical weirdness to attempt to prevent that.

Besides, copy protection could very likely make it difficult for your normal users/customers to run it under their differing preferred setups.

[Bregalad]

I have an idea about how to perform what you want (not sure that it's exactly what you want though), but since the idea is to prevent from bootlegging your home-brew ROM on a real cart and sell it $100 on Ebay (which is a common practice nowadays), I won't tell publicly how it's performed otherwise it'll allow them to hack around it too easily. Check your private messages.

[White Flame]

Anything like that is just a challenge to crackers. Since it's available in soft form, it'll be disassembled & cracked by anybody with any passing interest.

[Movax12]

It would be a challenge to some that understand basic hardware and how to flash a ROM and build a cart. Some people that have the ability to do that don't know how to debug software. But anyone who has the ability and motivation will be able to figure out any software based anti-copy protection.

[joe7]

I don't think this is possible beyond what Garth suggested, using self-modifying code, and in large, convoluted amounts to make it a lot of trouble to hack. But even if someone carted up the game and sold it, in most countries you'd have legal recourse, and if not it's unlikely that someone would make a million dollars off it anyway regardless of how good the game is.

I think all you can do is indicate in your promotion of the game that its not licensed for burning to carts. At least then, when you release the game, people would know that if they see a cart for sale then its an illegal copy. Be sure to include all legal notices with the game and also in the game itself on the first screen that comes up.

[Bregalad]

I don't see how selfmod is a copy protection, to any extent. NES games does this frequently and it's not a problem for reproducing cartridges.