- Topic Author
- Posts: 292
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.
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.
- Posts: 74
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?
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:
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.
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.
- Topic Author
- Posts: 292
Most likely a D3D11CreateDevice/D3D12CreateDevice followed by IDXGIFactory2::CreateSwapChainForCoreWindow ( msdn.microsoft.com/library/windows/deskt...404559(v=vs.85).aspx ).
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.
mov ecx, [eax] call dword ptr [ecx+64]