Metro Injection

Will it be possible (in the near or far futue)? I know its kinda hard since Crosire doesn't have Win10, but maybe someone else could collab on this.

It does something differently that prevents anything to be ejected on the EXE, all the renderers of the games are DX11 and are usually x64.
Perhaps there's a memory workaround that can be done somewhere on the wrapper to make it possible to inject on Metro apps.

Metro uses WinRT, which is an architecture that differs greatly from traditional Win32 and loads its components differently. I'm not sure if it's possible to run "normal" native code under WinRT, neither do I know if it's possible to inject into a WinRT process externally (would probably have to register a WinRT build of ReShade to the system-wide component cache and force the app to use that registration somehow).

Either way. Can't do it.
I tried to install Win10 once again, but my desktop just doesn't want it. Won't boot anymore after UEFI initialization completed (just locks up). No matter which BIOS options are set. And believe me, I tried, but after 12 re-installs, every piece of hardware except for the motherboard and main components removed, various different installation options, all booting related options tested (even combinations that simply don't make sense), I gave up. And yes, I ran a diagnose boot and checked the log, but the boot always crashes at a different component. And since not even the core system succeeds, safe mode is no help either. Start repair doesn't find any issues too (just says Windows booted successfully, which it obviously does not).
Win7 booted again few minutes later without struggle. So yeah. Sorry.

I think it's possible to inject into Metro, Dxtory can display a fps overlay and can also capture screenshots and videos.
But of course I have no clue if the same goes for ReShade's functionality.

When the weather is shitty, maybe you want to give a Windows 10 Redstone build another try?

I'm unsure about metro apps, but UWP apps can be injected. All DLL's being injected into a UWP app have to give the "ALL APPLICATION PACKAGES" user read/execute permissions, after that, you can use any generic DLL injector to inject the DLL into any UWP app.



You can also add "ALL APPLICATION PACKAGES" to the DLL's ACL automatically before injection so users don't have to do it themselves; just add its SID (S-1-15-2-1) to the DLL's ACL with read/execute permission. I'm assuming Metro Apps in Windows 8/8.1 work the same way, since you can interact with them using the same API as UWP apps and also require DLL's use the "ALL APPLICATION PACKAGES" policy to be injected into.

I'm currently working on a mod loader for a specific UWP app and I haven't run into any issues with UWP modding as of yet. The sandbox can be a bit annoying though, since once you're inside a UWP app, you inherit that apps restricted access to the file system. The mod loader also includes a launcher which launches the app in a suspended state so we can inject code before the app does anything. It works by using the IPackageDebugSettings interface; we enable debugging on the app, pass the location of our modloader executable as command line arguments in the enable debugging method, launch the app, then disable debugging. Windows will pass to the mod loader the process ID and some other argument (I forget because we never needed it) automatically; however, when an app is being debugged, the mod loader executable has to resume the app after injecting, which can be done with NtResumeProcess (the resume function in IPackageDebugSettings doesn't appear to work when the app is being debugged).

You can inject a UWP app at any point while it's running, we only go through the trouble to inject before it begins to run so we can hook functions in the app that handle initialization.

All the code for the mod loader is on github, but it's only ever updated when we make significant progress. The main files of interest for general-purpose UWP modding are:

• DLL Injector
• App Launcher
• UWP Utilities and Interface Wrappers

If you guys have any questions on modding/injecting UWP apps from the Windows Store, feel free to ask.

Edit: As a side note, most apps in the Windows Store use DX11, though some can use or exclusively use DX12. Microsoft published apps on the Windows Store tend to exclusively use DX12 (e.x. Forza 6, Quantum Break, and Gears of War Ultimate), while games from other publishers and developers often use DX11. Wkipedia has a convenient list of games using DX12 .

Edit 2 (Addressing crosire): Apps targeting UWP can not only use the WinRT API (WinRT uses Win32 and DirectX under the hood), but they can also directly use the Win32 and .NET API's specific to the device the app is running on. The app I've been modding uses the Win32 API which has made modding it considerably easier; for example, I can hook Win32 API functions like CreateFile, which is called when the app uses the wfopen_s function in ucrtbase.dll to load files. This particular hook has come in handy since all app files stored in Program Files go through integrity checks before being loaded, where now I can force the app to load files from the its AppData directory to bypass integrity checks.

Thanks a lot for the information. I always had assumed WinRT was a must for apps. I'll do some more digging.

They use both WinRT, Win32, and .NET. WinRT support is guaranteed across all platforms (phones, xbox, pc, etc.), while Win32 and .NET support is guaranteed on platforms that support it; for PC games, it should be fine. WinRT on PC's also uses Win32 and DirectX under the hood, so you can still hook the same API functions as before.

As an added word of caution, don't try to find the app process by its window name, and don't try to access the app's window. The window the app resides in is owned by ApplicationFrameHost.exe, and not the app itself, so you'll end up injecting/messing with ApplicationFrameHost.exe instead of the actual app. ApplicationFrameHost requires all DLL's be signed as well, so it's difficult to mess with it in the first place; the apps themselves don't require DLL's be signed. This is what Fraps and many other tools do by mistake, which is partly why they don't work with UWP apps.

Tools like Fraps end up injecting their payload into ApplicationFrameHost.exe instead of the actual app process because they tend to look for all open windows on the desktop, and Fraps is only successful because the DLL it injects is signed. The other reasons include the fact that tools don't give "ALL APPLICATION PACKAGES" permissions to read/execute the payload and that they try to access files on the local system that are restricted by the apps sandbox. Adding UWP support can get messy and annoying, however most issues can be overcome by adhering to the limitations of the app sandbox; for example, storing files you want to read/write in an app's AppData directory instead of in restricted areas on the file system. The work around I use is to create a temp directory in the app's appdata directory containing any files I need to read/write to from inside the app; afterwards when the app is closed, I copy that temp directory back to its permanent location.

I'm still looking into how apps initialize the Direct3D context, and if they use the window provided by AppFrameHost. Most of my mods so far just use the app's game engine to do graphics instead of going straight to the Direct3D context, though I'd like a more general approach that works for all UWP apps.

Yes! That's the kind of light i was expecting.
You did a nice work by giving all those infos! Hope you succeed even more, pretty sure Forza can look even better with ReShade.

VoxelBlock wrote: I'm still looking into how apps initialize the Direct3D context, and if they use the window provided by AppFrameHost. Most of my mods so far just use the app's game engine to do graphics instead of going straight to the Direct3D context, though I'd like a more general approach that works for all UWP apps.

Most likely a D3D11CreateDevice/D3D12CreateDevice followed by IDXGIFactory2::CreateSwapChainForCoreWindow ( msdn.microsoft.com/library/windows/deskt...404559(v=vs.85).aspx ).

Most likely a D3D11CreateDevice/D3D12CreateDevice followed by IDXGIFactory2::CreateSwapChainForCoreWindow (msdn.microsoft.com/library/windows/deskt...404559(v=vs.85).aspx).

Found the call to D3D11CreateDevice, currently looking through what the app does before and after it creates the context.

I'd suggest looking out for the IDXGIFactory2 creation (most likely via CreateDXGIFactory2) and then look through all the calls that go through the created object. "CreateSwapChainForCoreWindow" is located at vtable index 16, so it would first load the associated vtable, offset into that one by 16 * sizeof(void *) = 64 (on 32 bit) and then call the result. Something along the lines of (assuming eax currently holds an IDXGIFactory2 object):IF "CreateSwapChainForCoreWindow" is used that is of course. But either way, everything has to go through DXGI at some point (or I'd be very surprised).