Doyou guys know any solution for this?
I tried with 3 projects with Unity 2021.3.1f1 and all of the three spawn the same issue.
Currently we are upgrading our games to that version and API 31 for Android so downgrading or keeping our current versions of Unity is not a solution.
Thanks! Will try to delete the gameroom stuff and make it work so I can keep up to date.
For anyone reading this in the future take into account the dependencies and the manifests that points to gameroom.
The first thing I noticed was that Gameroom did not require any elevated permissions to install. It appeared to be a staged installer, where a minimal installer pulls additional files from the web instead of a monolithic installer. Indeed, I quickly found the installation directory at C:\Users\\AppData\Local\Facebook\Games, since most user-level applications are placed in the C:\Users\\AppData folder. The folder contained lots of .dll files as well as several executables. A few things stood out to me:
The third point suggested to me that Gameroom was written in the .NET framework. The .NET framework allows programmes to be compiled into Common Intermediate Language (CIL) code instead of machine code, which can run in a Common Language Runtime application virtual machine. There are several benefits to this, including greater interoperability and portability of .NET applications. However, it is also a lot easier to decompile these applications back into near-source code since they are compiled as CIL rather than pure machine code.
For .NET assemblies, DNSpy is the de-facto standard. Reverse engineers can easily debug and analyze .NET applications with DNSpy, including patching them live. I popped FacebookGameroom.exe into DNSpy and got to work.
Eventually, this led me to the System.Configuration.ApplicationSettingsBase.GetPreviousVersion(string) and System.Configuration.ApplicationSettingsBase.GetPropertyValue(string) functions. Gameroom used the deserialization function to retrieve its application settings at startup - but from where? Looking back at the installation folder, I found fbgames.settings, which turned out to be a serialized blob. As such, if I injected a malicious deserialization payload into this file, I could obtain code execution. Before that, however, I needed to find a deserialization gadget. With a bit more searching based on a list of known deserialization gadgets, I discovered that Gameroom used the WindowsIdentity class.
Have you ever clicked on a link from an email and magically started Zoom? What exactly happened behind the scenes? You just used a custom URI scheme, which allows you to open applications like any other link on the web. For example, Zoom registers the zoommtg: URI scheme and parses links like zoommtg:
zoom.us/join?confno=123456789&pwd=xxxx&zc=0&browser=chrome&uname=Betty .
Similarly, I noticed that Gameroom used a custom URI scheme to automatically open Gameroom after clicking a link from the web browser. After searching through the code, I realized that Gameroom checked for the fbgames: URI scheme in FacebookGames\Program.cs:
If the URI had the gameid host, it would parse it with SchemeHelper.SchemeType.Game. If it used the launch_local host, it would parse it with SchemeHelper.SchemeType.LaunchLocal. I started with the promising launch_local path, tracing it to FacebookGames.SchemeHelper.GenLocalLaunchFile(Uri):
I returned to the gameid path, which opened a Facebook URL based on the game ID in the URI. For example, if you wanted to launch Words With Friends in Gameroom, you would visit fbgame://gameid/168378113211268 in a browser and Gameroom would open in the native application window.
However, I realized that GetGameSchemeId, which extracted the ID from the URI that would be added to the
apps.facebook.com URL, did not actually validate that the slug was a valid ID. As such, an attacker could redirect the native application window to any other page on Facebook.
But how could I redirect to attacker-controlled code in Gameroom? There were a few options, including abusing an open redirect on
apps.facebook.com. Unfortunately, I did not have one on hand at that time. Another way was to redirect to a Facebook Page or ad that allowed embedded iframes with custom code.
Fortunately, there were additional code gadgets I could use. The version of Chrome used in Gameroom was really outdated: 63.0.3239.132 - the current version at the time was 86.0.4240.75. As such, it did not support the new version of Facebook Pages. The classic Facebook Pages version accepted a sk parameter such that =app_123456 led to the custom tab with the attacker-controlled code at !
But how could I inject the additional query parameter in my custom scheme? Remember that Gameroom discards anything after the first URL slug, including query parameters. Or does it? Looking back at FacebookGames/SchemeHelper.cs, I found GetCanvasParamsFromQuery:
This led me to my final payload scheme. fbgames://gameid/evilPage?canvas_params="sk":"app_123456" would be parsed by Gameroom into in the native application browser window, which would then execute my custom JavaScript code.
As mentioned earlier, the threat landscape for a native application is very different from a web application. By redirecting the embedded Chrome native window to attacker-controlled Javascript, an attacker could proceed to perform known exploits on the 3-year-old embedded Chromium browser. Although a full exploit had not been publicly released, I was able to leverage the CVE-2018-6056 proof-of-concept code to crash the Chrome engine via a type confusion vulnerability.
Alternatively, an attacker could create pop up boxes that were essentially legitimate native MessageBoxes to perform phishing attacks, or attempt to read the cached credentials file. Fortunately, unlike Electron applications that integrate Node.JS APIs, CefSharp limits API access. However, it still remains vulnerable to Chromium and third-party library vulnerabilities.
Facebook awarded it as High and subsequently patched the vulnerability, pushing me into the top-10 leaderboard for Bountycon. Although Gameroom will be shut down soon, it definitely left me with some fond memories (and practice) in basic offensive reverse engineering. For newcomers to application reverse engineering, Electron, CefSharp, and other browser-based frameworks are a good starting place to test for web-adjacent weaknesses like cross-site scripting and open redirects, while exploiting desktop-only code execution vectors.
The Facebook build target makes it easy to publish Unity games to Facebook and to use Facebook functionality in your games. Using the Facebook build target, you can build your content either as a WebGLA JavaScript API that renders 2D and 3D graphics in a web browser. The Unity WebGL build option allows Unity to publish content as JavaScript programs which use HTML5 technologies and the WebGL rendering API to run Unity content in a web browser. More info
See in Glossary player, which you can then publish to
facebook.com, or as a custom native Windows Standalone player, which you can then publish to the Facebook Gameroom client. Note: The Facebook Gameroom target is deprecated and will be removed in Unity version 2019.3.
To publish your game to Facebook, you first need to create a new App on the Facebook developer page. Once completed, this will give you an AppID, which you should paste into your Facebook Player settings. Now, you can get an Upload access token from Facebook, on your app configuration page, under the Web Hosting tab. Also paste this into your Facebook Player settings. This will allow you to upload your game to Facebook directly from the Unity Editor.
Here you can choose to build your content as WebGL or as a Windows Standalone for Gameroom. If you plan to upload your game, choose Package build for uploading, which generates a compressed package, which can be uploaded to facebook.
After making a build, the Upload last build to Facebook button becomes available. If you have correctly configured your AppID and Upload access token, you can click this button to upload your build to facebook. The Enter Comment for upload field lets you specify an optional comment to identify your build.
Once you have uploaded a build to Facebook, it will appear on your your app configuration page on Facebook, under the Web Hosting tab. Here you can choose to push your build to production or to stage partial rollouts to smaller percentages of your users.
If you want to use a different build of the Facebook SDK then the one included by Unity by default, you can do that, as long as it at least version 7.9.1 (so it supports the Facebook build target). Just download a build of the SDK from Facebook, and drop it into your Assets Folder. Unity will detect this, and disable the built-in SDK. This will allow you to use the Facebook SDK outside of the Facebook build target, which you want to use Facebook features on other platforms facebook supports.
3a8082e126