Say I'm developing a video game, but my publisher wants an exclusive on the ROM for the first few months of distribution. So I don't want one of the beta testers to leak a copy to the public. I already have people in my own family that I can't trust to keep a trade secret.
Here's what I plan: For each copy that I hand out to a beta tester, embed the recipient's name in multiple places in the ROM and encrypt important CHR data. If you turn on the game, you get a decoy: some random single-screen puzzle game. But if you hold a specific button and press Reset, you get a password entry screen. Enter the right password to start running the prototype; a wrong password will give either "Denied" or (if the user is lucky) corrupted CHR data.
Is there a better way?
Man, that's a horribly complicated idea. I don't think I have a better solution though...
Maybe give crippled versions to the testers, like with levels and music tracks missing. Make different crippled versions with different things missing, so that the individual parts can still all be tested. I think it's highly unlikely that all your testers will betray you, work together and try to join the pieces from all the crippled versions, but even if they try, this should be really hard to do if the data is shifted around.
If I were to do this I'd probably define some conditionals indicating what's to be assembled and what's not, so that I could quickly use different combinations for different crippled ROMs.
No matter the solution you use, you'll never be sure that the final product is bug-free unless people get to test the exact same binary you'll be selling.
tepples wrote:
I already have people in my own family that I can't trust to keep a trade secret.
If they're like you this is understandable.
Quote:
Maybe give crippled versions to the testers, like with levels and music tracks missing. Make different crippled versions with different things missing, so that the individual parts can still all be tested. I think it's highly unlikely that all your testers will betray you, work together and try to join the pieces from all the crippled versions, but even if they try, this should be really hard to do if the data is shifted around.
Sounds like horrible. Anyone here could crack your protection easily anyway.
Also if someone leaks the rom he'll most likely include the password with it anyway. The best way to get it from not being leaked is either not implement features (sivak didnt have testers have a password version of the rom) or just making absolutly sure the person testing is trustworthy. Also don't put their names in...just put in a random number at a random hex adress...that way they cant find it and erase it.
Bregalad wrote:
Sounds like horrible. Anyone here could crack your protection easily anyway.
You think it's that easy? With the data all shifted around it should be pretty hard to join them all and fix all the references to it, don't you think?
And you can also cripple by removing code, not only data. Say you make several ROMs, each with a single level for different people to debug, and you also make several ROMs each with a different boss (because the bosses weren't included in the levels)... I think it would be pretty hard to join it all, I wouldn't want that job.
But hey, piracy is piracy, someone always finds a way. If the big companies can't stop the pirates, neither can we. And I don't even know if all this trouble of protecting the ROM is worth it, since anyone that buys the cart can dump the ROM and distribute it the day it is released, so all the effort put into protecting the beta versions would have been for nothing.
And it sucks that you can't even trust people in your own family.
This kind of thing is called Data Fingerprinting. But it's really hard to pull off correctly.
And if a password is required to play the game, expect to see that password written on the cartridge in sharpie.
Knowing who leaked your game wouldn't help you much after it's already been done, unless you plan on taking legal action.
And people that want to play a game for free won't give a damn about who leaked it, as long as the game is playable.
tokumaru wrote:
Man, that's a horribly complicated idea. I don't think I have a better solution though...
Assume you're doing this on an emulator and not on a real NES with a PowerPAK?
If so, why not encrypt the ROM and send with it a modified emulator [binary only] that knows the decryption key? Or scramble the ROM and send with it a modified emulator that knows how to descramble it?
tokumaru wrote:
Knowing who leaked your game wouldn't help you much after it's already been done, unless you plan on taking legal action.
I believe Nintendo uses a similar technique to what I described for its official "Ensata" DS emulator, so that it can investigate a leak and apply appropriate contractual sanctions.
And I don't know of any emulator that comes with source code but isn't copylefted.
Each individual beta tester gets their own cart, which is associated with them digitally (duh). Just want to make that clear. The following would be done *per cart*. Focusing on the ROM itself as a whole, but I guess this would be best in PRG:
Fill in the leftover/unused areas with completely 100% random bytes, ranging from $00 to $FF. The leftover/unused areas should also be somewhat random in size or location (meaning you get to generate a unique ROM image with different offsets and everything per person, fun...).
Make note what the "base offsets" of those unused areas that contain random data are. Then, using the letters from their name, write down/take note of offsets (within the unused areas) which correlate with the letters from their name.
Here's a crummy example, keeping it simple with only 1 section of random data:
Code:
00006000: f5 41 93 ae 34 e7 54 98 08 2c 42 da d1 93 45 88
00006010: db c2 9a 68 8f f2 56 ca 25 a5 af a5 f6 06 f1 0e
00006020: be 2b 46 a5 6e b2 46 04 df d0 fd 0e 70 49 7b 3e
00006030: 89 f5 13 39 45 86 81 ae b1 b8 92 e9 50 67 89 8e
00006040: bd 81 f1 5d e8 ff e4 b0 9a 68 cd bc fa 66 03 56
00006050: b8 e0 3f 82 66 68 99 3b a5 d2 4e b7 64 a8 f7 2d
00006060: 5b f9 96 66 39 85 87 10 59 93 39 b4 fb 85 52 be
00006070: 95 b0 41 33 8f 6d 6b 2e c5 d0 6c 40 42 a2 01 d9
00006080: ac 6c 00 ca f3 8c 28 1a 9b ad 25 3d 83 53 d2 2f
00006090: 68 0c 28 8b e3 99 84 01 81 27 e1 f0 bd 0e 54 51
000060a0: d2 47 84 34 0c d6 f3 87 2a ba 20 b6 c8 aa 38 ff
000060b0: 14 3f c0 2a 32 84 6e 91 63 ed 8b 11 68 34 e1 36
000060c0: 07 5b cf 22 f8 36 bf d8 a2 6c 3f 41 36 1a e7 48
000060d0: 50 be 06 48 6a 43 d9 80 90 02 42 d8 f4 7f d0 41
000060e0: 31 e7 1e 54 96 3d bd 85 b0 6a a9 51 ca 26 08 db
000060f0: 2e 8e 68 49 53 91 70 01 9c 60 c2 50 b8 b6 2c cd
Let's pretend the individual's name is FAT HEAT. So you'd write down:
FAT HEAT = 0x6000, 23, 01, e4, aa, d4, 0e, cb, 06
The 0x6000 part indicates what base offset you'd need to look at the ROM image (again, assuming PRG) for, and the bytes after are the offsets from that base address.
If you get a hold of a ROM image someone's released on the net (and presumably hasn't modified the hell out of), or a cart someone's put up for sale somewhere, you can simply write a quick script (you know Python ;-) ) to go through your beta tester list, going to that base location + offset and print out the letters.
Well, that's my idea anyway. A good one? Hardly. Failure-prone? Very likely. But you get the idea.
Does the publisher want exclusive on cart production, or the ROM in general? If it's just cart production, aren't there some simple changes that could be made that cause the game to run in certain emulators but not a real NES? The hope is that the other cart makers assume it's a poorly-made game rather than hunting for the code you broke.
Cartridge pirates just don't care.
@ koitsu:
What you have shown is one way of identifying the person who leaked the game (there are many other possibilities), but that alone won't do it. When the ROM is out, the damage is done. What are you gonna do to the person who did it? Spam their inbox? There isn't much you can do unless you're willing to invest in hiring a lawyer, and that will hardly pay off in the end.
Better than just identifying the culprit after the shit has already hit the fan is to prevent it all from happening in the first place. So I guess the goal here is to find a way to make the distribution of the game impossible, or at least pretty damn hard.
Does the NES version of Contiki have a TCP/IP stack? If so, maybe you could include that on the ROM and have it sporatically make calls to a private server for verification and chunks of code in order to play the game. If said private server is offline, or denying access, then you have incomplete code and a non-working game.
UncleSporky: I'm not sure. This publisher has also put out cart versions of games whose demos are missing levels or (more relevant to my case) missing features. I seem to remember someone else on this publisher not releasing a ROM until the game has been out for months, and the cart got discontinued (on purpose) around the ROM release (also on purpose). So I'm trying to make leaked betas less attractive to casual players or at least try to shame the leaker out of the NESdev community.
Contiki 2.x doesn't support the classic game consoles anymore, only a few commercially significant microcontrollers. Contiki 1.x for NES never had a driver for any serial port hardware over which one could run SLIP or PPP. And even if there were, most of my testers wouldn't have the serial port mod or an emulator that supports it.
Just make a demonstration version of the rom that showcases a couple of the levels, and only those. There's your magazine exclusive.
In my opinion, it's really not worthwhile to put so much effort into completely encrypting your prototypes to make them unleakable, because that'll just make things hurt more when they do get leaked and cracked. See also: Megaman Vengeance.
That's one of the things that bugs me about programmers in general; the whole "MINE!" mindset they tend to have. It's really no benefit to anybody, and it only serves to damage one's own ego. This is just my opinion though.
I think the practical ideas are cutting data and code that isn't part of the test, and unique roms per tester like hidden data and/or unique offsets of code and data.
But whatever you do don't try too hard. I suppose if you were really serious about protecting a NES game you'd be best off with a highly customized mapper.
Drag wrote:
Just make a demonstration version of the rom that showcases a couple of the levels, and only those.
Right now, the major difference between the demo and the full version is that the full version will have cut scenes and an editor. It's not like a platformer where I can chop it into episodes and hand one out to each tester.
Quote:
That's one of the things that bugs me about programmers in general; the whole "MINE!" mindset they tend to have.
What about the "I'd like some reward for what I do to give me an incentive to keep doing it" mindset? Or, on platforms that aren't obsolete like the NES, the "I'd like to eat tonight" mindset?
Take a cue from the leading experts on preventing piracy, and mail NES consoles sealed in a steel box with only the buttons and outs exposed. Place in the beta cart a self-destruct mechanism that will destroy the rom chips should they somehow get in. Like a small glass tube of acid that will break when the shell is split open. Acid can corrode silicon wafers, right?
Easy solution: Take an NES CPU, solder some SRAM directly to it, and a battery with a long lifetime. Then seal the whole thing in some sealant that is sufficiently hard (so that any attempts to cut it would result in destroying the chips inside, or disconnecting the battery). Also, run the battery wires around like a cage, so any attempts to cut into the package would disconnect the battery.
Then plug this bad boy into a regular NES, and ship it.
(Inspiration:
http://www.google.com/#hl=en&q=sega+%22 ... a56c95bda8)
strat wrote:
Acid can corrode silicon wafers, right?
Thermite would be a sure-fire solution. Literally.
I think someone made something similar, except that there is a sensitive tape inside a cartridge that if the cart is opened, it would tear and the cart would no longer be genuine. I guess the same can be here, but instead of a tape it should be some cable that will make it impossible to play the game.
Can't remember the exact wording, but I do know some Chinese company did it (ShenZhen Nanjing?). Try to find it
here.
tepples wrote:
Quote:
That's one of the things that bugs me about programmers in general; the whole "MINE!" mindset they tend to have.
What about the "I'd like some reward for what I do to give me an incentive to keep doing it" mindset? Or, on platforms that aren't obsolete like the NES, the "I'd like to eat tonight" mindset?
What kind of reward were you looking for? I'm not saying "hand your rom out for free", I'm saying "focus more on your game, rather than how to protect the prototypes from being leaked".
Megaman Vengeance got leaked, and the project was ultimately cancelled because of it, meaning all of the effort was wasted on what ultimately were egos. Despite the prototype being readily available, it's only the first stage. Do you know how many people *still* say "man, I would've loved to see this get finished" despite this leaked prototype being available?
Even if free content was leaked, if there's the promise of more, the interest will remain. It's why people are interested in buying Battle Kid, despite the free demo being available.
tokumaru wrote:
Knowing who leaked your game wouldn't help you much after it's already been done, unless you plan on taking legal action.
There are multiple parties whom would have reason to take legal action - tepples and the publisher off hand, but there could be others depending on the contract.
There is no 100% way to prevent leaks - look at all the high-profile movies that get leaked due to people working at DVD pressing plants. I would suggest a multi-pronged approach:
1) Make testing builds identifiable. This way, you know where the leak came from
2) Make the publisher responsible for beta testing. That way, the onus is on them to investigate and prosecute any leaker for copyright infringement (and nowadays, infringement is much more serious for unreleased media than released)
3) Make it such that the due diligence you do to make the prototypes traceable insulates you from any negative results. If you do your damndest and the thing still gets leaked, you are not responsible and the publisher should not be able to pull out.
This may be easier said than done. I recommend you stress upon the publisher that despite the best efforts of multimillion dollar corporations, media still gets leaked, and due to economies of scale this is even harder for you to do as a lone developer.
This whole situation reminds me of CBS threatening to withhold ALL high-definition programming if the FCC did not implement a broadcast flag to allow them to prevent broadcasts from being recorded in the first place. The broadcast flag was shot down and yet CBS is still producing countless hours of HD material. Piracy is a known and unavoidable risk, and any publisher who wishes to make the developer responsible for mitigating the effects of piracy has not been properly advised by their legal department.
Hmm, I think if you distribute a ROM over the internet, it's going to be really really hard to prevent a leak. When you have access to a soft copy of the data, it can be easily duplicated and manipulated. So if you're looking for more security, go with a hardware test, I'd say.
Someone mentioned something where the cart stopped working as soon as you opened it. I think that kind of thing would work. But you'd want it so that the person can't remove the PRG or CHR chips without destroying them. For example, you could have the pins be extremely fragile towards the top, where you could easily break a pin off if you moved it. Or if you know what you're doing, do the whole glob-top thing. Though I don't know anything about that. Perhaps there's some sort of plastic you mold over the cart board so that you really just can't get the chips out?
But then you have to still make sure you can't get at the data with a CopyNES or something like that. If you can think of a way to fool the CopyNES, then you might be good to go. I'm probably overlooking a million other possible ways to dump data onto a computer though. I think I have a weird, but possible idea though. Modify a NES to send to beta testers that has your game locked in it. Your game's PRG will actually be on a battery packed RAM chip. If the tester tries to remove the cartridge, or unscrew the motherboard to make it into a CopyNES and dump your game (or basically tamper with the stuff in any way), the battery would be removed from the chip somehow. Then all the data would be lost. Hmm... Maybe a dumb idea.
Another option, and probably the safest, but most impractical one, is to physically meet with a beta tester, and have a single copy of the game that you take with you after they're done testing. That way, you know that there's only one copy, and that it's safe with you. If you're set on giving people a soft copy though, I would recommend just leaving stuff out of the test that you don't access. I don't really know what to say otherwise...
If we're talking about soft copies, I believe it's possible to make a program that would check that the IP address is legit (as in you have to be a specific person to see the game), write the NES file into some obscure directory, open it in an emulator, and as soon as the emulator is closed the temporary ROM is destroyed (much preferred if it would be deleted right after it was opened in the emulator).
Possible, highly; easy, not really.
LocalH wrote:
There is no 100% way to prevent leaks
I understand that, which was part of my original plan. It's more about shaming the leaker from the scene.
- It's less attractive to casual players who get the leaked ROM without README from a "complete GoodNES site" for two reasons: the decoy game makes them think it's a cuckoo egg, and even if they did figure out Select+Reset, they don't know the password.
- Encrypted CHR with unique passwords helps make the culprit identifiable. So do various other watermark methods, such as slight differences in on-screen text or data in unused parts of the ROM or exchanging ADC #x with SBC #255-x.
Quote:
2) Make the publisher responsible for beta testing.
I've been trying to get details about the beta process out of my publishers, but the publisher's last project of this scale was a platformer, and platformers are more suited to the strategy of giving each tester only half the levels than a game like Mario Paint or I Can Remember. And "release candidate" builds shipped to the beta testers need to be pretty much the same binary that goes on the final carts anyway. But once I do make a platformer, I can use leakers' names as the names of boss characters.
Quote:
3) Make it such that the due diligence you do to make the prototypes traceable insulates you from any negative results.
That's a good point.
Celius wrote:
physically meet with a beta tester
I would physically meet with beta testers, but I don't know enough gamers in Fort Wayne, Indiana, who would be interested. The only one I know has shown an interest in leaking things before. But I do have some power over him: he can't play Super NES games on a Super NES without something I own.
What do you own that does not let him play SNES games without it?
Why not simply ask the testers to come to your home without distributing the rom ?
Coincidentally, though without as much gravity seeing as my project will be free anyway, I'm asking my Beta testers for their IP address (actually I'm harvesting them from my request to comment on my blog site). I'm then going to put their IP address, broken up and transposed, in specific places in the ROM, the location of which will be impossible to find. I'm also going to watermark the manual (PDF).
It won't stop anyone distributing the ROM but it should hopefully encourage a basic level of integrity and enable me to name and shame anyone who does spread the ROM (if I find out!).
Trying to stop the spread of the ROM is only because there are features/bugs that I don't want spreading out to a wider audience. Hence the whole idea of a Beta test period - it will hopefully reduce the number of issues that people will have with the proper release and subsequently mean I won't have to spend quite so much time addressing problems from multiple sources.
It does bother me though that someone could actually make carts from the ROM and sell them. I'm not going to be charging for the ROM myself but there are plenty of unscrupulous people out there that might try.
What can you do....
neilbaldwin wrote:
It does bother me though that someone could actually make carts from the ROM and sell them. I'm not going to be charging for the ROM myself but there are plenty of unscrupulous people out there that might try.
What can you do....
True, and they commonly come on this board in hardware second and "kindly" ask for advice and does that many times a week. (okay they calmed down recently but...)
danntor wrote:
What do you own that does not let him play SNES games without it?
1. SNES with a working power supply, and 2. SNES PowerPak.
Bregalad wrote:
Why not simply ask the testers to come to your home without distributing the rom ?
Lack of funds for airfare.
tepples wrote:
Bregalad wrote:
Why not simply ask the testers to come to your home without distributing the rom ?
Lack of funds for airfare.
If you can find 2 or 3 people nearby that are willing to test the game for you, you could buy some snacks and beverage, invite them over and throw a small "beta test party". Just have the guys chill out and play the game. You can watch and take notes about things that might need changing/fixing and their opinions. Sounds safe and productive.
tokumaru wrote:
If you can find 2 or 3 people nearby that are willing to test the game for you
Which is exactly my problem. How do I find other NES fans in a given city?
Do they have to be NES fans? If you know someone your own age it's likely they played the NES (or other consoles) as kids too. I think that whatever friends or acquaintances you can get will do, they'll probably help you out even if it's not terribly fun for them. They're likely to do this as a favor, hence why you should offer something back (snack and stuff) to make the day less boring for them.
tepples wrote:
tokumaru wrote:
If you can find 2 or 3 people nearby that are willing to test the game for you
Which is exactly my problem. How do I find other NES fans in a given city?
Ummm...you ask on here? What city?
tokumaru wrote:
If you know someone your own age
That's my problem: I don't really know anyone else my own age except at work, and I don't know how my boss would like me soliciting testers at work.
NESICIDE wrote:
Ummm...you ask on here? What city?
Click www under this post, then click Contact at the left side of the page, then scroll down.
Spoiler: Fort Wayne, Indiana
If you ever need to test a really good game, I'm tempted to meet you halfway somewhere in IL. You can bring the ROM on your DS or PSP. I don't wanna drive all the way to where you live, though. I'm by old man river.
tepples wrote:
Spoiler: Fort Wayne, Indiana
Okay you said "a given city..." so I thought you meant in general. Apologies for my general solution.
NESICIDE wrote:
Okay you said "a given city..." so I thought you meant in general.
Both general and specific solutions would be fine by me.
But I've come up with a different idea: make a multicart with several minigames that can use the same assets, and each tester would get only one of the minigames. I'll open a new topic about it once more ideas come to me.
You could always hit up the previous beta testers from
Nintendoage. They are all really honest, and as far as I know none of them have leaked anything.
WhatULive4 wrote:
You could always hit up the previous beta testers from
Nintendoage. They are all really honest, and as far as I know none of them have leaked anything.
As opposed to releasing prototypes with their name edited into the ROM.
TSK wrote:
WhatULive4 wrote:
You could always hit up the previous beta testers from
Nintendoage. They are all really honest, and as far as I know none of them have leaked anything.
As opposed to releasing prototypes with their name edited into the ROM.
It's not really about figuring out who did it, but about finding people you can trust. Once it's leaked, it doesn't really matter who did it, now anyone/everyone has the game. The company commissioning the game doesn't want this to happen at all, but it needs to be tested. Hence, why I suggested a group of individuals who are honest and trustworthy and would beta-test the hell out of any homebrew you threw at them.
The aim of the previous message was intended to convey a lack of worth of trust on the part of NintendoAge. Apparently, I missed.
TSK wrote:
The aim of the previous message was intended to convey a lack of worth of trust on the part of NintendoAge. Apparently, I missed.
I thought you were referring to the above discussion regarding adding the beta testers name into a ROM to figure out who leaked it.
Releasing prototypes which they spent a lot of money for and editing their names in actually protects the community. If someone grabbed the rom, then tried to pass it off as an authentic proto, it could be authenticated as a copy, and the seller would be discredited.
Was there a particular incident that discredits them? (I'm not saying everyone on Nintendoage is honest, but that the Beta testers have been in the NES community for a long time and are well trusted and honest people)
WhatULive4 wrote:
Was there a particular incident that discredits them? (I'm not saying everyone on Nintendoage is honest, but that the Beta testers have been in the NES community for a long time and are well trusted and honest people)
Yeah, I was going to ask this. Why would you just show up and start badmouthing an entire forum without any reasoning or examples?
I lurk occasionally - I'm the author of
vNES. I'd call Tepples an acquaintance - he bought some stuff from me, we've had a few interesting conversations. Not the point.
The mentioning of NA struck me as rather odd in this sort of discussion, as a secondary feature of what they do is
leak prototypes, and unlike others (Hidden Palace, X-Cult, SEGASaturno etc.) they insert their name in the game, which itself is secondary to the point of this thread.
Exerion II, U-Force Power Games, Mike Tyson's Intergalactic Power Punch. That's precisely what I'm talking about.
Maybe I'm derailing this, and in the event that I am, I'd like to apologize to Tepples.
In an attempt to move away from this tangent; perhaps embedding it into vNES, encrypted, and requiring net-based access would be a reasonable solution to this problem.
TSK wrote:
The mentioning of NA struck me as rather odd in this sort of discussion, as a secondary feature of what they do is leak prototypes, and unlike others (Hidden Palace, X-Cult, SEGASaturno etc.) they insert their name in the game, which itself is secondary to the point of this thread.
Those aren't "leaked", those are released with full knowledge of the cart owner. The conditions of the release, set by the
prototype cart owner and not NintendoAGE, is that the ROM title screen must be modified. No modification, no ROM.
Following the direct instructions of the provider definitely increases trust instead of showing a lack of it.
Dwedit wrote:
LOL MEMORY DUMP
I don't work with encryption. Never really piqued my interest. Seems sort of obvious now, I suppose.
bunnyboy wrote:
Those aren't "leaked", those are released with full knowledge of the cart owner. The conditions of the release, set by the prototype cart owner and not NintendoAGE, is that the ROM title screen must be modified. No modification, no ROM.
Following the direct instructions of the provider definitely increases trust instead of showing a lack of it.
I'm looking at this from a completely different aspect. If DreamTR is the one responsible for the generously-named watermarks, then I suppose my issue is more with him than NintendoAGE, and I'm clearly in the wrong for finding fault with NA.
In an effort to convey my thought more clearly, I have the same problem with intros for the same reason. Perhaps it's unreasonable. It's plentiful in the scene, moreso with GBA than NES, but that's just my stance on it, not that anyone particularly cares.
neilbaldwin wrote:
It does bother me though that someone could actually make carts from the ROM and sell them. I'm not going to be charging for the ROM myself but there are plenty of unscrupulous people out there that might try.
Such people would be caught.
The transposing of the IP address is great. We do this with CC info of customers stored on my work CP (it's a rental store so we need to keep that stuff). Certain numbers are altered specific ways, in a way that is completely arbitrary and impossible to guess.
bunnyboy wrote:
Those aren't "leaked", those are released with full knowledge of the cart owner.
Secrecy can only last until you've started selling copies on RetroZone with the developer's OK, which is all I really want out of such a scheme. I just don't want a leaker to disqualify me from being able to publish my game.
TSK wrote:
In an effort to convey my thought more clearly, I have the same problem with intros for the same reason. Perhaps it's unreasonable. It's plentiful in the scene, moreso with GBA than NES, but that's just my stance on it, not that anyone particularly cares.
The decoy scheme I describe could be considered an intro, except that the intro is a different game. This way people think the prototype is of the intro.
bucky o'hare wrote:
Such people would be caught.
Caught, but what to do with him? Sue? As others have pointed out in this topic, that fails if the developer of the proto lacks the money to lawyer up.
Yes, secrecy in the industry has always been problematic, but locking the game with a password isn't the best way to handle this... Making sure that if anybody leaks the game, you can sue his or her pants off and that you can prove without a doubt that did so is the key issue here.
You shouldn’t make it difficult for testers to actually load the game every time. Trust me, it only serves to irk your alpha & beta stage testers and make them wants to do something else.
Is this a NES game? If so, imagine yourself as a tester who has to recall a cryptic passkey and punch it in with a NES controller every time you fire up the game. Games with passwords suck already, but having to use one each time you run the cart is just a horrifying thought.
It would probably be best to simply do a custom ROM for each tester and embed his or her name in the code, then sign everybody to an NDA. That way, you can perfectly track each copy and if anybody dumps the ROM, you know who it was and can bust him or her for breach of contract under the NDA.
If it is an NES game, I would be willing to both do testing and sign a full NDA. I've done that before for many software titles on various platforms (Commodore, Amiga, Mac, Atari, etc.) in the past when I used to write manuals and reviews.
If you need any legal help with writing an NDA, I can send you a template that I use for my own business.
-Xious
tepples wrote:
Say I'm developing a video game, but my publisher wants an exclusive on the ROM for the first few months of distribution. So I don't want one of the beta testers to leak a copy to the public. I already have people in my own family that I can't trust to keep a trade secret.
Here's what I plan: For each copy that I hand out to a beta tester, embed the recipient's name in multiple places in the ROM and encrypt important CHR data. If you turn on the game, you get a decoy: some random single-screen puzzle game. But if you hold a specific button and press Reset, you get a password entry screen. Enter the right password to start running the prototype; a wrong password will give either "Denied" or (if the user is lucky) corrupted CHR data.
Is there a better way?
I just noticed this thread. What about using a unique code "stored" in each NES? Each NES has unique values at power up, which are relatively stable (initial SRAM and palette values, for example). Could the program read this, display some sort of code (based on them) on screen for the tester to give back to the developer, and then the developer give the tester a password to use? The idea is that critical sections of game data would be encrypted. The tester wouldn't know his NES's power-up values. Assuming power-up values are relatively unique, he'd have to dump them from his particular NES for his password to be usable on a leaked copy. He could run it on an emulator first, so you could have that alter the displayed code subtly so that you are alerted.
See I wonder about the effectiveness of these name-embedding methods. If you are filling blank space in the ROM with random numbers, and then hiding a secret encrypted message (the person's name) in there, that can easily be worked around by profiling the ROM in the emulator. I.E., playing the game for a long period of time, and any memory location that doesn't ever get read from or changed would be set to zero, removing all the random data, along with the embedded message. You could always have the ROM read from random locations and then do nothing with that data, but that's not much of an improvement. Your best bet is probably stenography, hide the message in your sprites somehow.
If you're simply trying to keep non-technical folks from leaking this ROM, though, your idea will probably work fine.
phazmatis wrote:
playing the game for a long period of time, and any memory location that doesn't ever get read from or changed would be set to zero, removing all the random data, along with the embedded message.
What if the message is hidden within data that is used? It could be slight adjustments of the positions of background elements in a level, for example, or slight adjustments of graphics. There's no way to know what information is unique about your copy as compared to others. It only needs to be decodable by the developer.
Quote:
Your best bet is probably stenography, hide the message in your sprites somehow.
What does
shorthand writing have to do with it?
Zeroing out unused data obscures some watermarks but not these:
- Obfuscation of order of elements in RAM, such as putting the shadow-OAM at $0700 instead of $0200 or declaring zero page variables in a different order
- adc #x vs. sbc #255-(x)
- In CHR RAM games, changing the format of compressed CHR data
- Putting an image of the recipient's name in the CHR data
- Slight palette differences
- Music differences
- Rounding differences in full-justified text (like that seen in Super Mario World message boxes)
But all the steganography in the world won't help me sue a perpetrator in another state.
Good news: my cousin is no longer interested in leaking, given that he found an even older version of LJ65 on some ROM site. But really, the only leaks I'm worried about are those that interfere with a publisher's willingness to make repros. Remember how Half-Life 2 got delayed after much of the Source engine got
leaked?
blargg wrote:
What does
shorthand writing have to do with it?
lol... What was I thinking?
tepples wrote:
But all the steganography in the world won't help me sue a perpetrator in another state.
Tepples,
How exactly do you mean this? An NDA is good not only in every state, but in all countries that affirm US copyright laws 9such as Canada, Japan, the E.U., etc. and should protect you against anybody who tries to leak the game.
I like your ideas about slightly differing graphics, as this will be harder to track than a name in the code. That is probably the best way to go: any way to hide a tester's name so that they can't find it in the CHR data is ideal.
Would you like a copy of a solid NDA to use? If so, simply let me know and I'll pull one from my files and type up a template. I used to use Commodore's NDA as my own template for my businesses, as they had great lawyers (and unfortunately, rubbish marketing agents).
I'd be interested in testing your game, so if you are looking for further Beta-phase testers, please keep me in mind. I can also test your code on Famicom consoles and clones, which may be an added bonus.
What mapper are you using?
-Xious
Xious wrote:
How exactly do you mean this? An NDA is good not only in every state, but in all countries that affirm US copyright laws 9such as Canada, Japan, the E.U., etc. and should protect you against anybody who tries to leak the game.
Wouldn't an NDA be part of trade secret law, not copyright law?
Xious wrote:
tepples wrote:
But all the steganography in the world won't help me sue a perpetrator in another state.
How exactly do you mean this? An NDA is good not only in every state, but in all countries that affirm US copyright laws 9such as Canada, Japan, the E.U., etc. and should protect you against anybody who tries to leak the game.
I have found the person who violated my copyright and my NDA. He lives in another state or in another country, and he doesn't have a big bank account balance. Now how do I find the money to hire a lawyer to sue this person? And even once I have a favorable judgment, how do I collect the damages?
Quote:
What mapper are you using?
I'm not even sure to what extent I want to continue the project, whether people are willing to pay $35 for a battery-backed NES game that isn't an RPG.
For what it's worth, I just spent $40 for a non-battery-backed version of 'Frogger Ultimate Championship’, so I am certainly willing to pay $35 for a new NES title. Heck, they cost that much (if not more) fifteen to twenty years ago, so that's not a hefty price in today's money.
Do you know if the guy is in the USA? If so, there are a variety of ways to go after him and his bank account balance is irrelevant. You can get a judgment and garnishee his wages.
To do this, you file a lawsuit for breech of contract in your own state and send a legal summons to the infringing party. If they fail to appear, you get a default judgment against them and file for transferal of judgment in the state in which they reside, giving them legal notice of the filing at the same time. If they don’t contest the filing, you get a garnishee and any wages they make from that point on (along with their bank balances and possibly properties, depending on the value of the judgment) go to you.
International suits are far more complicated, although the proceedure works in much the same way, and I suggest limiting your testers to the US to simplify legal concerns.
-Xious
tepples wrote:
Xious wrote:
tepples wrote:
But all the steganography in the world won't help me sue a perpetrator in another state.
How exactly do you mean this? An NDA is good not only in every state, but in all countries that affirm US copyright laws 9such as Canada, Japan, the E.U., etc. and should protect you against anybody who tries to leak the game.
I have found the person who violated my copyright and my NDA. He lives in another state or in another country, and he doesn't have a big bank account balance. Now how do I find the money to hire a lawyer to sue this person? And even once I have a favorable judgment, how do I collect the damages?
Quote:
What mapper are you using?
I'm not even sure to what extent I want to continue the project, whether people are willing to pay $35 for a battery-backed NES game that isn't an RPG.
I've worked on fingerprinting systems for Sony and Microsoft, the reality of the situation is that you *can't* stop testers/reviewers from leaking betas. It's not even practical to scare or shame them into keeping the data secret.
Let me give you an example. This disc was sent out as a review build to a professional magazine (one of the big ones). I bought it off of ebay for $20. Here's a picture of the warning on the disc:
http://picasaweb.google.com/h4ckur/Phon ... 1141451842
The reviewer was under a heavy handed NDA, they risked not only their job but their career and the reputation of the magazine over $20 on ebay. There have been hundreds of these discs sold like that too. Best part is, Sony and Microsoft refuse to go after the reviewers.
Xious wrote:
For what it's worth, I just spent $40 for a non-battery-backed version of 'Frogger Ultimate Championship’, so I am certainly willing to pay $35 for a new NES title.
Thanks a bunch!!!
Assuming your game will work alright in a NOAC clone, you could get one of those cheap and encase the game PCB and NOAC board in some potting compound. The NOACs are generally very inexpensive and accurate enough for some things, and there is no worry about CopyNES with a NOAC. If your beta tester can't mail you back a whole unit (IE, he hacked the chips out) you'll know who your leaker is.
Agreed with arfink. Also, you may consider ways to subtly degrade the play experience rather than crashing outright if the game detects it's running in an emulator/unauthorized reproduction--here's an article about ways this was done for a Spyro game:
http://www.gamecareerguide.com/features ... odd_01.htm
Earthbound also makes attempts to discover if its crc has been changed and adds lots of extra enemies/makes the final bossfight unwinnable if it has. Keep in mind you don't have to have foolproof copy protection, it just needs to last a few months after your actual release really.
Also, consider your audience. If they're the type to buy a physical NES game, I'd say it's pretty likely they don't care whether a rom exists or not. Your publisher may disagree, however.
huge sesh wrote:
Earthbound also makes attempts to discover if its crc has been changed and adds lots of extra enemies/makes the final bossfight unwinnable if it has.
The FADE system in ARMA 2 does almost the same thing. The less confident the game is that your copy is authorized, the less accurate your weapons become.
Quote:
Your publisher may disagree, however.
This. I guess I'll have to get further in actually completing a publishable game before I discuss best practices for beta and release candidate testing with a publisher.
In general you might want also to consider things that can be included with the cart purchase as an added incentive to get the real thing. I have no idea what your game is, but I think simple things that personalize the object make it much more valuable to the customer. Part of what you're selling is participation in the scene so play to it and add in something cool like a booklet documenting your design process or a printout of parts of your source code. The other thing you're selling is the object itself, so you might consider doing a a limited run of your carts and numbering them, or add in an instruction manual + map, something to make it more of an object.
I was thinking about this topic and i wanted to make a few suggestions.
if you were worried of someone making a dump of the rom you could try to emu the game in a web browser using some java emulator. that way the person would not have access to the original copy and at worst would have a script that's useless for reproducing to live carts.
With this you could give each person a way to sign up for the beta and have them create their OWN username and password
If they use their own password they have more incentive to keep it more secret as it may be the same password they use for say email because we all know a lot of people like using the same passwords.
Another idea is to incorporate some kind of lock and key technology into the game. I have 2 approaches to this
If you could create a random number generator in the game that would act as a lock and a website that you type that number into in order to generate a key.
User types in the key and the game is unlocked.
Random number generating might be too complex and stressful for the cpu so a watered down version of this would be to make a set number of locks in the game. Say 100 or 200 random locks that you personally made. Find a random password generator on the web and then create all these numbers. then using the same generator create keys for each one. So when the game starts it prompts with a random lock you made and you type that lock on the website (which uses their user name and password) it gives you the key. the chances of the same lock being prompted twice would be slim as its randomly picked so if someone gave out the cart and a key the person would have to power cycle the cart probably 200 times in order to get the same lock to populate. this makes the attempt to play laughable.
Of course there are drawbacks to this if someone was skilled enough they could just delete the code and the game would be playable. but if you add a crc check to the rom...
Another drawback is save states just save the state with an old lock on the screen and use the old key they were holding on to. but then the person would have to have 3 different things to play the game. The rom the save state and the pass key.
one way or another if you created the code for this lock and key method you could sell the code for extras revenue for others to use this method of protecting games.
If this exact method is not reasonable I say be creative with the concept. You can make it as complex or lax as you want.
Sugam wrote:
if you were worried of someone making a dump of the rom you could try to emu the game in a web browser using some java emulator. that way the person would not have access to the original copy and at worst would have a script that's useless for reproducing to live carts.
Wouldn't you just be able to extract it from RAM?
Sugam wrote:
Of course there are drawbacks to this if someone was skilled enough they could just delete the code and the game would be playable. but if you add a crc check to the rom...
The CRC check could be skipped just as easily. All protection that's built into the program and has no external components can be easily broken.
Memblers wrote:
Sugam wrote:
if you were worried of someone making a dump of the rom you could try to emu the game in a web browser using some java emulator. that way the person would not have access to the original copy and at worst would have a script that's useless for reproducing to live carts.
Wouldn't you just be able to extract it from RAM?
You could program a largely inaccurate emulator that does some stuff the NES can't do, and tweak your game accordingly!
Actually I think we already talked about that and how it's still pretty pointlessly convoluted lengths to go to.
Memblers wrote:
Sugam wrote:
if you were worried of someone making a dump of the rom you could try to emu the game in a web browser using some java emulator. that way the person would not have access to the original copy and at worst would have a script that's useless for reproducing to live carts.
Wouldn't you just be able to extract it from RAM?
You could but if someone were to burry the rom code into the emulator code itself it might prove difficult to extract cleanly. I think there are a few java emulators that could be modified this way. only down side is that they dont get to play it on real hardware or perhaps even with a proper controller.
But one thing people need to remember is that in the end any lock or protection can be broken. The quality of the lock is just how much time you have. I would pick a locking method that would be suffucant enough that could last untill the rom is into production stages. Once the final carts are produced theres nothing stopping people form copying a real cart.
A lock is also only as effective as the lock picker. I would consider using any method that the user might be uneducated in. if the user is uneducated in modifying a nes rom code to make the game start then the easier lock is recomended.
If you're going to bury the ROM in a Java app, to avoid someone else digging it out you can always encrypt the data. Hell, I might even think that it's possible to do it in the ROM itself, but why would you want to...
WJYkK wrote:
If you're going to bury the ROM in a Java app, to avoid someone else digging it out you can always encrypt the data. Hell, I might even think that it's possible to do it in the ROM itself, but why would you want to...
In fact, if you scroll back to the first page, the latter was part of my original plan: encrypt the compressed CHR data in each tester's copy of the ROM with a different key so that I can name and shame the leaker.
UncleSporky mentioned making an inaccurate emulator and making the ROM rely on its specific inaccuracy. That'd be equivalent to making an emulator for a platform that isn't fully compatible with the NES and then making the ROM for that platform. That could work for some purposes but not for release-candidate testing.
Or the people who actually put games on carts (such as Memblers and bunnyboy) could post their ideas of best practices and end the whole discussion right there.
This is the solution I had come up with a while back. I didn't think it would be terribly useful, but it was fun to think about. It could work on Squeedo, or anywhere else there is a read-protected PIC (theoretically, the boot block on the PIC I'll use could be read/write protected to prevent "bricking").
What you would do, is make your game program more dependent on jump tables. Whenever you use the jump table, you write your entry # to the PIC, and the protected code in there does something mysterious with your data, and returns the real jump table entry for the NES to use. So who cares if anyone has the ROM of the game, good luck to whoever tries to recreate the program flow based on a jump table, heheh.
I may put something like that in the next Squeedo revision (with other weird stuff hidden in the boot block). All it would do though would be to stop a 'normal' game from working on an emulator or any non-Squeedo cart though. I don't know how useful that would be, but I guess it could stop betas from leaking outside of the Squeedo-using crowd. Of course in that case you could just as well use the features unique to the Squeedo board, and get nearly the same level of protection since I doubt it would ever be properly emulated.
edit - oh forgot to mention, it turns out this method of protection is similar to the protection used in some pirate port carts, like Earthworm Jim.
Couldn't the jump table be defeated by putting the cart into a CopyNES or similar and recording what it gives for the entries?
Yes, it could. So it depends on how the program use the jump table inter-dependently. To the point where the amount of work required to reconstruct it (step-by-step in the 6502 emulator, in CopyNES's case) exceeds the amount of work to rewrite the program.
CopyNES debugger could be defeated easily in Squeedo's case though with some extra measures, since the PIC has it's own oscillator you won't be able to single-step any kind of continuous operation it may be doing (which would still of course breakable with more hacking, but doesn't make things any easier).