Copy protecting BASIC programs

Started by Vectrex32, August 25, 2016, 09:38:18 AM

Previous topic - Next topic

Vectrex32

Some people have suggested that the SmartCart provide copy protection, so that game writers can sell their games without fear of them being pirated.

Features that would be nice are:

  • Allows for a free trial period, so a user can try the game before buying
  • Does not require a terminal emulator, since some people might have trouble setting one up
  • As simple as possible for the user and the seller

- Bob

Vectrex32

I have two ideas for implementing this. One is less secure but is easier to use. The other is more secure but more difficult to use.

Proposal 1:

A password is hard-coded into every SmartCart. An author writes a game and encrypts it using the password (I would provide an app on Vectrex32.com to do the encryption). He then makes it available for anyone to download. Inside his game he calls a function, GetLicenseInfo. This function tells him if a valid license is found and how many times the game has been run.

GetLicenseInfo takes three arguments: a unique ID for the game (e.g. a 16 digit hexadecimal number - I'd provide an app on Vectrex32.com to generate it), a unique ID for the author, and the file name of the game. The SmartCart would track how many times the game has been run based on its ID number. It would look for a valid license in a <file name>.lic file on the SmartCart's drive.

If a valid license is found, the game runs without restrictions. If no license is found, the game can look at the number of times the program has been run and decide whether the free trial period has expired. During the trial period, it can also limit how long the game may be played (e.g. 15 minutes).

When the user is ready to buy, he prints out his SmartCart's serial number (every SmartCart has a unique, 64 bit serial number). He sends it to the author. The author combines the game ID and the S/N and encrypts it with his author ID (another app on Vectrex32.com could do this). That generates a license file which the author sends the the user. The user puts the file on his drive.

This scheme is vulnerable because there's a single password distributed with every SmartCart and that also exists on Vectrex32.com's server and on my development system. If I'm hacked or if someone disassembles the SmartCart code, this system could break.

Proposal 2:

Instead of having the same password on every SmartCart, the SmartCart's serial number is its password. So for every user who wants to try or buy the game, the user must send the author his serial number and the author must encrypt his game for that user.

To break this scheme, a user would need to disassemble the SmartCart code (or hack into my home computer), modify it, and re-program the PIC32 with the new code.

Notice that this requires more work from the author and more work from the user when he just wants to try out a game.

What do people think?

- Bob

MartyMcFly

#2
I will quote Benj Edwards in his 'Why History Needs Software Piracy' essay:

Quote"If you see strict DRM and copy protection that threatens the preservation of history, fight it: copy the work, keep it safe, and eventually share it so it never disappears. [...] no one living 500 years from now will judge your infringing deeds harshly when they can load up an ancient program and see it for themselves."

So if you want your work to disappear from history please use DRM. I won't come this way with you, furthermore on a system which has seen its initial games' catalog going public domain by the company selling the console. I want my kids/ future generations to play your game and enjoy your work. I don't want them to look at some blurry jpegs or old captured footage of it.

Developers should trust their customers. Piracy will always exist, DRM is not a solution; trust is.

Vectrex32

Marty, you bring up an important question: do developers even want this? I've heard from a few people that I should put copy protection into the SmartCart, but I'm not sure if I've heard from someone who actually wants to use it.

If no one really wants it, it's a lot less work for me not to implement it.

- Bob

MartyMcFly

#4
I'd say you should do nothing about it, and let it up to the developer. Hell, reverse engineering is fun so there can be challenges to be made (crackmes) between developers (of homebrew DRM) and crackers, like in the (old) computing scene!

The benefits of don't embedding native DRM into V32SC will be double:

  • Not more work for you; you can concentrate on more productive things
  • If the developers choose to bring DRM to their games, their will be different versions of it across their games/developers. So if when a protection is cracked they just have to make another version of it. If it was the SMartcard's DRM which would be cracked, all the software which depends on it will be cracked at once

Don't forget that your project is at first a debugging tool, so it *will* be turn against it to crack its own DRM if it happen to have one. You can chose to put in place schemes like execution rings (ring0, ring3...) to try to mitigate it but again this would means more work into a project that needs development and your attention on many other details which are more close to the original goal of it (making faster games on a legacy machine).

Vectrex32

Marty, the BASIC on the SmartCart is limited enough that no DRM would be possible without my assistance. Also, no DRM I create in the SmartCart would be breakable from the SmartCart debugger (because the DRM wouldn't be written in BASIC).

I don't want this to become a debate over the morality or ethics of DRM. I just want more Vectrex games to be written. If developers tell me "I will write great games for the SmartCart, but only if there's copy protection", then I'll create a mechanism for copy protection. If developers say "I will write great games regardless of whether there's copy protection" then I'll direct my efforts elsewhere.

- Bob

MartyMcFly

You're perfectly right, I get your point. But be sure that someone will find a way to access the DRM mechanism over BASIC. It's just a matter of time. See all the consoles that have been developped with milion$ in R&D (PSP, Playstations, Xbox...) and still be cracked at the end and you'll know V32SC's DRM will suffer the same fate. This is true the target is way smaller than the one for modern consoles so it have less chance of being cracked, but as soon as someone sees it as an intellectual/interesting enough challenge s-he'll go for it and defeat it.

TL;DR: never underestimate the power of PEEK/POKE ;)

Vectrex32

Quote from: MartyMcFly on August 25, 2016, 12:57:26 PM
TL;DR: never underestimate the power of PEEK/POKE ;)

The SmartCart's BASIC doesn't have PEEK/POKE.

- Bob

MartyMcFly

#8
Ok, so it is an high level only language for now? I remember starting developing things on Arduino and after few weeks begin to be interested into the assembly which was accessible with some commands (the same for C with the _asm_ directive). The programs written with some low level routines were so much faster.
My point is that providing high level language for this project is paramount and you made the right choice since it allows new developpers to get ahold of the system quickly and allow them to prototype faster since the learning curve is small. But don't forget that eventually they'd become seasoned developers and ambitious project would greatly benefit of faster routines. So making low level instructions accessible can be a big plus for V32SC.

As always it's only my two cents and you know better this hardware than me :)

Vectrex32

Quote from: MartyMcFly on August 25, 2016, 01:19:57 PM
Ok, so it is an high level only language for now?

Right. The goal is to make programming easier. If at some time in the future, people start hitting a performance wall with BASIC, I'll revisit that.  But you raise another good issue: if, at some point in the future, I give more access to the internals of the SmartCart, the security of the copy protection needs to be considered.

- Bob

gliptitude

#10
I started the thread on copy protection. I'm not a developer. Obviously the preference of copy protection is the prerogative of the author or owner of the software.

My actual concern was that the really amazing game programs might not be written because there is no physical media to exchange. Physical media is of course an antiquated concept. But so too are wired controllers, monochrome xy crt's and video games that don't connect to the internet. "CARTRIDGE RELEASE" is generally the threshold for full fledged, high quality, complete and finished homebrew games. .. Maybe that doesn't have to be the case, but I think a complete absence of distribution scructure will inhibit production. There may tend to be lots of experiments and test programs but few or no finished productions.

It's not really for me to be concerned about and I don't expect a decisive solution. But it is a relevant topic.

Vectronic

I also was an original commentator on this topic. I, as of yet, am not a programmer or developer, but am hoping that experimenting with the Vectrex32 will change that. I bought one to play around with programming on the Vectrex. I am a very ethical person, and believe in supporting the programmers/developers directly if at all possible, and not resorting to buying from re-sellers or auction sites where the programmers/developers don't make those mad profits from re-sale. I only suggested copy protection for the benefit of the people spending long hours making something new and great for my favorite console. They should be compensated and rewarded for their time and effort. If even one person uploads their ROM/BIN without the developer's permission, the damage is done. It pains me to see that. The Vectrex community is pretty strong, and the odds of seeing this publicly done are slim, and even after enough time passes, most developers do in fact release their ROM/BINs publicly either right away, or after a physical release. Physical releases won't be possible with programs written for the Vectrex32, so the developers may be at more risk for their works to be stolen - especially if an emulator is developed and released to play these games. Although one would still need a Vectrex32 to play said game on the actual hardware. I just want to see developers being justly compensated for their work.

ChadTower


The first question I would ask is how many Vectrex32s are anticipated to be produced through the life of the product?  How many will be in regular use?  The Vectrex scene is passionate but very small.  The number of people willing to purchase a Vectrex32 at its cost level will be a subset of that and I suspect the majority of us will be developers.  The developers will respect each others' work.  If someone does steal a game how many copies will have been not sold as a result?  I think it's more a question of "will this ever be an actual problem" than it is one of how possible it may be.

Vectrex32

I'll keep making SmartCarts as long as people keep buying them.

If developers tell me they want a way to protect their programs, I'll come up with a copy protection scheme.

- Bob