Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #33503 > unrolled thread

Preventing piracy on the web

Back to article view | Back to comp.lang.javascript

Contents

  Preventing piracy on the web bit-naughty@hotmail.com - 2017-06-04 10:36 -0700
    Re: Preventing piracy on the web "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-06-04 15:40 -0700
      Re: Preventing piracy on the web Robert Heller <heller@deepsoft.com> - 2017-06-04 20:05 -0500
    Re: Preventing piracy on the web JJ <jj4public@vfemail.net> - 2017-06-05 09:04 +0700
      Re: Preventing piracy on the web bit-naughty@hotmail.com - 2017-06-09 08:48 -0700

#33503 — Preventing piracy on the web

...so I'm talking about web games here,....if the game is written in JS, there's no such thing as a "crack", right, like there is for retail DVDs etc. , ie. executables? Unless someone breaks into the *server* - which is a different story... But what I'd like to know is the situation where *one* guy pays for the game, downloads it, and then simply "views source" in his/her browser, and then just puts that JS on the web! - IS THERE ANY WAY IN WHICH THIS CAN BE PREVENTED?!! Like, I suppose you could intersperse the code with constant checks to the server, with some kind of unique "gameid" embedded in the game (posession of which is the proof that you've paid), - but even this seems rickety. In the olden days hackers use to go through *binary* to remove copy protection like this, how hard could it be with *source*??!! Know what I'm saying? So - what's the way out?

[toc] | [next] | [standalone]

#33505

bit-n...@hotmail.com wrote:
>  But what I'd like to know is the situation where *one* guy pays for the game, downloads it, and then simply "views source" in his/her browser, and then just puts that JS on the web! - IS THERE ANY WAY IN WHICH THIS CAN BE PREVENTED?!! Like, I suppose you could intersperse the code with constant checks to the server, with some kind of unique "gameid" embedded in the game (posession of which is the proof that you've paid), - but even this seems rickety. In the olden days hackers use to go through *binary* to remove copy protection like this, how hard could it be with *source*??!! Know what I'm saying? So - what's the way out?

Legal problems have legal solutions.

[toc] | [prev] | [next] | [standalone]

#33506

At Sun, 4 Jun 2017 15:40:36 -0700 (PDT) "Michael Haufe (TNO)" <tno@thenewobjective.com> wrote:

> 
> bit-n...@hotmail.com wrote:
> >  But what I'd like to know is the situation where *one* guy pays for the =
> game, downloads it, and then simply "views source" in his/her browser, and =
> then just puts that JS on the web! - IS THERE ANY WAY IN WHICH THIS CAN BE =
> PREVENTED?!! Like, I suppose you could intersperse the code with constant c=
> hecks to the server, with some kind of unique "gameid" embedded in the game=
>  (posession of which is the proof that you've paid), - but even this seems =
> rickety. In the olden days hackers use to go through *binary* to remove cop=
> y protection like this, how hard could it be with *source*??!! Know what I'=
> m saying? So - what's the way out?
> 
> Legal problems have legal solutions.

And the easiest solution is the oldest one in the book:

Charge for use of the *server*, but give the JavaScript away. If the game
cannot be played without a "live", paid for, token from the server (eg a
timestamped HTTP Cookie that can only be had with a Credit Card, Paypal,
etc. transaction), then the JavaScript code itself is worthless, unless
someone reverse engineers the server code and set up their own server. A VPS
is going to cost at least $20/month, plus the effort to reverse engineer the
server side of the game code and the effort to maintain and manage the server
-- this is likely going to cost more that the game tokens.

>                                                                      

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                            

[toc] | [prev] | [next] | [standalone]

#33507

On Sun, 4 Jun 2017 10:36:20 -0700 (PDT), bit-naughty@hotmail.com wrote:
> ....so I'm talking about web games here,....if the game is written in JS,
> there's no such thing as a "crack", right, like there is for retail DVDs
> etc. , ie. executables? Unless someone breaks into the *server* - which
> is a different story... But what I'd like to know is the situation where
> *one* guy pays for the game, downloads it, and then simply "views source"
> in his/her browser, and then just puts that JS on the web! - IS THERE ANY
> WAY IN WHICH THIS CAN BE PREVENTED?!! Like, I suppose you could
> intersperse the code with constant checks to the server, with some kind
> of unique "gameid" embedded in the game (posession of which is the proof
> that you've paid), - but even this seems rickety. In the olden days
> hackers use to go through *binary* to remove copy protection like this,
> how hard could it be with *source*??!! Know what I'm saying? So - what's
> the way out?

You can't prevent it, but you can make it difficult (or hell difficult) in
order to copy it.

I'd suggest using a custom byte-code (or similar) based interpreter - making
the main code as a mere interpreter engine (without any actual content). The
byte-codes are the actual instructions and data, and are stored in the
server - encrypted. Use authentication in order to retrieve the byte-code
from the server if necessary.

Do not use a ready-to-use byte-code interpreter library; made one which is
based on that; or made one which is based on others'
idea/concept/specifications, as it would give a hint on giving out
information on how to hack/crack/decode your application.

[toc] | [prev] | [next] | [standalone]

#33514

On Monday, June 5, 2017 at 7:34:39 AM UTC+5:30, JJ wrote:


> I'd suggest using a custom byte-code (or similar) based interpreter -

I have no idea what you just said - how does one "use a custom byte-code (or similar) based interpreter"? What the hell IS that??

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web