Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browser Games Aren't an Easy Target

jakob.space

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Browser Games Aren't an Easy Target

#11

Post by tetris11 »

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.

Re: Browser Games Aren't an Easy Target

#12

Post by TomGullen »

mysterydip wrote: post #5
thrower123 wrote: post #3

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

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

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.

Re: Browser Games Aren't an Easy Target

#13

Post by Eric_WVGG »

tetris11 wrote: post #11

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 d…

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

Re: Browser Games Aren't an Easy Target

#14

Post by terramex »

TomGullen wrote: post #12
mysterydip wrote: post #5

Earlier quoted context omitted.

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

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.

Can you create graphical assets within engine in Construct (vector or raster) or do you need to import them?

Re: Browser Games Aren't an Easy Target

#15

Post by mysterydip »

TomGullen wrote: post #12
mysterydip wrote: post #5

Earlier quoted context omitted.

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

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.

I wouldn't have thought to look there. I'm sure there's many ex-flash devs who would be happy to check it out if they knew.

Re: Browser Games Aren't an Easy Target

#16

Post by xg15 »

> 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.

Re: Browser Games Aren't an Easy Target

#17

Post by clktmr »

xg15 wrote: post #16

> 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. [...]…

Javascript can be obfuscated too. What is the difference?

Re: Browser Games Aren't an Easy Target

#18

Post by paulddraper »

clktmr wrote: post #17
xg15 wrote: post #16

> 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. [...]…

Javascript can be obfuscated too. What is the difference?

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

Re: Browser Games Aren't an Easy Target

#19

Post by trilliumbaker »

xg15 wrote: post #16

> 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. [...]…

JavaScript has it covered pretty well.

http://www.jsfuck.com/

Re: Browser Games Aren't an Easy Target

#20

Post by xg15 »

clktmr wrote: post #17
xg15 wrote: post #16

> 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. [...]…

Javascript can be obfuscated too. What is the difference?

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.

Post reply on HN