Html5 game licensing?

#1

I’m completely new to html5 game development, so I was wondering if someone could explain to me how licensing of html5 games works.

The reason I’m asking, is that I uploaded my game to Newgrounds in the hope of earning some coffee-money from ads. But to my surprise, just a couple of days later, my game was running on all kinds of game aggregator sites (with ads). I don’t mind for this first game, that other people are making some money from it, but it raises the question of how one can support oneself with html5 games.

That’s when I came across the term ‘licensing’. How do those companies prevent the games they are selling / renting out from being published all over the web ? :thinking:

#2

I think that “site locking” is a primary method used to prevent distribution of a game, you check location.host in your code and prevent the game from running if it is not what you expect.

Now, the trick is doing so in a way that people won’t be able to easily bypass/strip from your code

1 Like
#3

On the flash target, it was possible to sitelock if needed and obfuscate to protect your intellectual property, I used to use SecureSWF http://www.kindi.com/ to do this. It would make it much harder for someone to decompile the .swf and make changes to, or copy the game

Unfortunately, due to the nature of the HTML target, it’s futile to protect your code. you could sitelock, obfuscate, and minimize your .js , but at the end of the day it’ll still be a text file that anyone can copy and edit.

2 Likes
#4

Isn’t code in haxe->js already “compiled” and unreadable? I think it’s really hard to edit anything outside of haxe source. Isn’t it?

#5

Mmm … yes.
That makes html5 games mostly ‘throwaway’ things. I wish there was something binary (non-text) that could take the place of flash …

#6

Not actually sure about this but maybe webAssembly?

#7

Haxe -> JavaScript output is very readable :slight_smile:

https://try.haxe.org/#e5d8D

Haxe

class Test {
    static function main() {
        trace("Haxe is great!");
    }
}

JavaScript

// Generated by Haxe 3.4.4
(function () { "use strict";
var Test = function() { };
Test.main = function() {
	console.log("Haxe is great!");
};
Test.main();
})();
#8

Some options I found:

https://javascript-obfuscator.org


https://javascriptobfuscator.com

If there’s something stable (and not licensed), we could wire it into our standard build.

There might be some stuff we could try from the NPM world

https://www.google.com/search?client=opera&q=npm+obfuscator&sourceid=opera&ie=UTF-8&oe=UTF-8

1 Like
#9

well, it’s time to make some obfuscation… :grinning:

#10

@singmajesty… That would be a great Idea if obfuscation is included in a build. Minifyng the js doesn’t guarantee that it is secured… Anyway hope this will be part in a future… thanks

#11

Resurrecting this topic, because just found out that someone copied my HTML5 games to their website.
I have site-lock (yeah, I know, it’s not so effective as in Flash), but code was modified and game locked to another website.
So, can anybody recommend a good effective obfuscator that works for OpenFL games?
Thank you!

#12

I’m seeing references to JScrambler but cannot find pricing, I’m sure there are other options as well? Would be interested what others have tried

#13

Hey singmajesty!
I have tried https://www.obfuscator.io/.
Some problems though:

  1. It can’t handle large files, in my case it didn’t return obfuscated code, so I’ve installed it on my server, then it worked.
  2. As any good obfuscator, it renames all the variables, so the code in index.html stops working and I have to fix it manually:

lime.embed (“Game”, “openfl-content”, WIDTH, HEIGHT, { parameters: {} });

Is it possible to move everything to .js?

#14

Is there a way to protect a single value from being renamed?

I think we could use a single JS only if we removed the flexibility of being able to embed at different insertion points

#15

Yep, there is such options, I will play more with obfuscator next week and post my results.

#16

i’ve used google closure and haxe optimizer flags, e.g.

  <haxelib name="closure" if="release" unless="windows" />
  <haxeflag name="-dce full" if="release" />
  <haxeflag name="-D closure_overwrite" if="release" />

it seems that it’s generating pretty good obfuscated code. the only thing you have to do is manually mask accessing LoaderInfo#url (use some sort of reflection on stage.loaderInfo to do it) and obviously, not name site-lock related code with explicit names :smiley:

I would also recommend not only presenting a “site lock” text/screen, but, silently proceed and randomly disable gameplay features in case of wrong domain (e.g. in a Mario-like game, disable jumping or moving, spawning enemies, corrupting the level, etc).

i’ve also mulled over the idea of generating the sitelocking code at runtime, using some technique like js safe of google ctf 2018 (https://github.com/google/google-ctf/tree/master/2018/beginners/web-js-safe-1) and also this code could also set some global variables that can be used to check their values randomly during gameplay, when the game starts/end, etc. However, I’m not sure how to implement this thingie in Haxe.

additionally, if you game is hosted on your own server, you can use some sort of a “heart-beat” server side script that is called by the client in random placed in the game code -> if the heart beat isn’t there, lock the game (although there might be potential issues with this approach for legitimate players).

i believe that unhackable is not the goal here, but simply to make it unworthwhile for any casual hacker. Take a look here, where a security researcher investigates JS malware, just to check the complexity in obfuscation you need to deter hackers: https://resources.infosecinstitute.com/reverse-engineering-javascript-obfuscated-dropper/

2 Likes
#17

Thank you @Karg!
Still hadn’t time to play with obfuscation, but will definitely try closure and these flags.

#18

Somehow Google’s closure removes parts of my code, while game still works, some features don’t.
For example, it completely removes ExternalInterface.call() function.
Kind of weird behavior. :confused: