Talking to PHP files within SWF

[JamesAllgood]

Im using the chrome add-on to see how ruffle would work with a site of mine called ride sims.

The .swf files look to a web file for a username and reports back with it to load the sim, however at the moment it sits on a blue loading screen.

This happens to all files on the website and I was wondering if it was something that just isn’t in your code yet and I need to wait a bit longer, or if its something that will never work.

The site is the following: https://ridesims.com

[Toad06]

For some reason, in Ruffle, the hash is always the same and the timestamp is NaN, when it calls LoadVars.sendAndLoad().

With Flash: File: api/?hash=3e2925fd5637cb3fb8a0bc34c7f4204b&time=1595588542.488 Response: data:text/html,no user found

With Ruffle: File: api/?hash=0123456789abcdeffedcba9876543210&time=NaN Response: Invalid request hash

So the issue may start here, but I'll let the devs confirm (as I'm just a tester 😆).

[kmeisthax]

Ruffle hash's output is highly suspicious already. "Same every time" sounds like this hash function's input relies on good randomness. We have an RNG which technically works but is entirely deterministic as it is never seeded with any useful entropy. Ergo, movies will be entirely deterministic unless user input causes the RNG to be clocked differently.

We also don't expose time & date APIs (@Dinnerbone is working on that). I'm not entirely sure why that's included in the request; maybe the 'hash' is some kind of encryption or authentication rather than a hash.

[Dinnerbone]

Looking into this now. The API stuff seems to be obfuscated which makes this a little harder to debug. A few observations:

• The time seems to a timestamp in number of seconds (new Date().getTime() / 1000).
• The hash is an MD5 hash of any arguments being sent to the API, plus the timestamp, plus a salt. This would cause it to be the same every time as in this instance, it's only taking timestamp (NaN), salt (static and embedded in the swf) and the same arguments action=get_user_details&sim=11.
• The server is most likely generating its own hash against the timestamp and arguments and salt, and then comparing it verses the clients as a primitive tamper detection.

Potential problems here:

• new Date().getTime() isn't implemented yet and will result in NaN right now. Follow #249 for updates, but basically I have it mostly working on desktop but not on web yet.
• There's a bunch of _global.__resolve = _global.__debugResolve scattered around the codebase. I don't know what its purpose is, perhaps more obfuscation, but we don't support __resolve yet. Not sure if it's actually being used, or if it's debug code?
• There's a lot of tellTarget("..") scattered around which seem to throw errors in Ruffle. Again, not sure if it's truly needed and causing problems.

Good news: the actual MD5 algorithm seems to work. In this specific case, the arguments will always be the same and so it's md5summing the following string: "sim11actionget_user_details3y2N0TI73oFIHm41fm58sSzdeVcfhj6vNaN". It's generating this as "9d9d153381c8827ba314083b82aacb5f", which is correct!

Most likely, once we have the timestamp this should work well. I don't know why it doesn't already work since technically NaN in the hash is the same as passed in the argument, but perhaps the server is expecting this to be an actual number and rejecting this for being invalid.

[Dinnerbone]

Managed to get the API request working in a local branch, it was just the timestamp. Now it returns my username and all seems to be well.

I can see that it stored it successfully, too. Variable dump:

_global.user = [object #0] {
    result: "success"
    username: "Dinnerbone"
    id: "34965"
    [... snip ...]
  }

Still stuck on a blue screen, though, so that wasn't the problem here. 🤔

[JamesAllgood]

The fact that it came back with a result, ID number and username is a great start good work guys!!

@Dinnerbone I guess that allow gotoAndStop/gotoAndPlay with frame numbers got you past the blue screen?

[Dinnerbone]

Yep, and I entertained a few dozen guests to a ride in Apocalypse!

It looks like your API sometimes returns a valid user even with timestamp NaN, so after that PR lands you can actually play your games sometimes despite Date not landing yet.

The games have various issues, of course, but those should be filed separately so we can identify and tackle each thing.

[JamesAllgood]

Thats amazing work thanks so much!!

Of course, I will test stuff as time goes on and raise them as bugs etc.

I guess ill wait for the next chrome add-on to be built in tonight's update and that might work for me tomorrow?

[Dinnerbone]

It'll only be in tonights build if it gets accepted by then, I don't know how busy Mike is!

I've attached an extension build that has both experimental Date support & that PR fix, which "should" let you test your games. Please don't raise any issues that are related to date/time, but visual artefacts and general gameplay should be valid. ruffle_extension.zip