Browser Games Aren't an Easy Target

http://jakob.space/blog/browser-games-aren-t-an-easy-target.html

by jsnell • 7 years ago

106 50 7 years ago

Drakim2• 7 years ago

Very enjoyable read. It was especially interesting seeing the obfuscation techniques the devs had created to prevent cheating using WebAssembly.

thrower123• 7 years ago

Alas, we killed Flash. It's undeniable that that technology enabled a Cambrian explosion of creativity.

simion3143• 7 years ago

I put most of the blame on Adobe, they handled Flash and the related technologies as Flex/AIR badly. I think if they wuld have start from scrtch with an open source implementation of the player it would have had a better success, at tat time the only alternative was Java applets or Silverlight.

I liked the idea you had Flash off by default and you enable it only for the page or section of page you liked, I am running now Vivaldi with Javascript off by default because we have a even more garbage experience now with JS, like on BBC news with JS off the links are broken (wtf the web developers can't even create a working link without JS)

wmichelin• 7 years ago

What makes you think it isn't a requirement coming from their superiors?

There are many reasons your link may not work. Why do you assume incompetence?

mysterydip3• 7 years ago

I'm surprised someone hasn't made a flash-equivalent framework/environment for html5 or webassembly yet.

Drakim2• 7 years ago

With the programming language Haxe and the library OpenFL you can actually create "flash" games for HTML5 using the old school flash API and everything.

TomGullen3• 7 years ago

We have, with Construct 3 (https://www.construct.net)

Recent addition of our timeline editor means we think it ticks all the boxes as a replacement.

Pxtl• 7 years ago

Yeah, Flash created a golden age of indie animation and gaming. Although I think Macromedia has more to do with that than Adobe. Macromedia Flash was both affordable and easily pirateable, putting it in the hands of millions of budding artists.

Then Adobe bought it and duct-taped it to the Creative Suite and switched to a subscription-based business model.

tetris112• 7 years ago

I also take a weird pleasure in running `scanmem` on some of these io games (not the multiplayer ones) and just messing with the values so that I can win everything.

I know a lot of time and effort goes into game development, and that I should take the time to appreciate the rhythm of the story and the nuances of the gameplay... but I am an addict.

I don't casually play games. I'm all in, or not at all. I will play day and night until a game is finished and then I will move on with my life. As an adult with a full time career I can't do these marathon sessions anymore, and so cheating is a great means for me to accelerate through a game, tick the mental block of completion, and then be refreshed Monday morning with my mind focused on work.

Eric_WVGG• 7 years ago

It's cool, you're just playing a different game.

xg154• 7 years ago

So I went back to the debugger and placed some breakpoints around where the WebAssembly module is loaded, realizing that its only purpose is to deobfuscate the JavaScript that eventually makes it into that "SOURCE" pseudo-file I saw earlier. [...]
So… the WebAssembly is essentially generating JavaScript on-the-fly. Of course, all renditions of the code do the same thing, but the variable names are changing. [...]
So it seems the WebAssembly module is doing some sort of tampering checking, [...]

I remember various discussions when WASM was specced about the danger of WASM blobs being used for code obfuscation.

The fears were dismissed with the argument that WASM is easy to decompile and that there is a textual representation to preserve "view source" functionality.

And yet, as soon as WASM is practically usable, we get this - an application that uses WASM solely because it is hard to inspect in the browser.

clktmr• 7 years ago

Javascript can be obfuscated too. What is the difference?

paulddraper• 7 years ago

Yeah, it would seem that JS can be sufficiently obfuscated already.

xg154• 7 years ago

Well, someone went to the trouble of writing a Rust binary just to hide the game code, when they could have used standard JS obfuscation instead. This suggests to me that WASM has some properties that make reverse-engeneering harder than obfuscated JS could do alone.

This would give some validity to the fears of WASM becoming the "new Flash" that were voiced when it was still in development.

trilliumbaker• 7 years ago

JavaScript has it covered pretty well.

http://www.jsfuck.com/

kvakil• 7 years ago

jsfuck is hardly obfuscation: remove the first 828 bytes (for "eval(") and the last 3 bytes (for ")()"), and then execute the remaining string, and that gives you the original source code.

throwGuardian3• 7 years ago

Why should someone be forced to make their IP "open" just because someone else on the internet feels entitled to read and potentially copy/modify/... their code?

xg154• 7 years ago

Because the code is being executed on my machine, with my data, using my online identity.

Until now, the general understanding for the web platform was that code that runs on a user's machine is also inspectable by that user. A large number of browser functions are developed with that understanding in mind.

You can argue that this practice should be changed, but that would be a rather fundamental change to the way the web works and the advantages and disadvantages should be discussed.

As a practical point: I don't condone cheating in multiplayer games, but the exact same obfuscation techniques that a game might use for legitimate reasons are also available to malware. If you make a general rule that programs should be hands-off to everyone except the devs (and browsers should change their tools accordingly), the same benefits will be given to malware.

redka2• 7 years ago

It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of cheaters spoiling it for everyone is super slim. I wonder if it ever makes sense to think in those categories or am I just paranoid.

marcus_holmes• 7 years ago

that does kinda feel like premature optimisation. First make a game. Second make a game that people want to play. Third make a game that people want to hack. Then maybe look at stopping them from doing that.

Hard to resist that nagging thought, though.

judge2020• 7 years ago

Knowing and designing around the unavoidable wave of cheaters is extremely important when building online games.

If you build a multiplayer game then come back to "deal with cheaters" only a few months before launch (or heaven forbid, after launch) you're probably going to end up taking the easy route by using invasion ~~spyware~~ DRM solutions, which don't stop cheaters once it's broken. To contrast, designing the game around cheaters means you might actually implement sane networking design, such as nearly everything being server-authoritative, aka. "never trust the client". If your client is broken in to, the best your cheaters can do is script the game (scripting cheats are currently the only ones available for Dota2 and probably League of Legends) or see a small amount of information that's otherwise unknown (for dota 2 you can see which enemy illusions are fake, for example).

Of course this approach can be taken too far, eg. in Call of Duty: Modern Warfare (the new one) sometimes your camera positioning can lag due to packet loss; this probably stops some aimbots but things like camera orientation probably shouldn't be handled server-side.

bostonvaulter2• 7 years ago

On the other hand people don't like playing a multiplayer game when other people are badly hacking.

ghusbands• 7 years ago

And, as with premature optimisation, mantras don't communicate any of the subtleties around the fact that many concerns can influence your code at the same time.

saurik• 7 years ago

Why do you say "for the browser"? Unless you are working on a system with a ludicrous amount of effective DRM (which I hope we all hate for other reasons, and which means we are only really talking about consoles: the closest casual gaming platform you are going to get to "locked down system owned by the manufacturer" is an iPhone, and in practice they don't go quite far enough), players are always going to be able to modify your code: you can't prevent a user "cheating" (which I put in quotes, as I feel like you need to really question whether the environment you set up where that matters isn't somehow itself broken; maybe you are already doing that by "source-like networking", but I don't know the terminology context).

p1necone2• 7 years ago

The only way to stop players from cheating in a multiplayer game is to make the server the authoritative source for any information you want to stop players from messing with.

If it's a single player game, then who cares?

redka2• 7 years ago

The games are multiplayer and the server is authoritative. That doesn't mean the games can't be played with cheats, eg. wall-hack, auto-aim, etc.

ahmeni• 7 years ago

A very decent breakdown of some more modern obfuscation and deobfuscation techniques. It's nice to see some Rust getting used as well, I wonder if it's made things easier or more difficult for the krunker.io dev in the long-run.

webdva• 7 years ago

Have you heard of Hordes.io? It's an advanced multiplayer .io game.

Browser Games Aren't an Easy Target

Related Stories