Open erasesys32 opened 6 years ago
Yep came here to post this. It succeeds at injecting and then the game crashes before it can do whatever remote thread IPC is.
I don't have Forza 4 myself to really test much of this. Have you tried using something like Process Explorer to suspend the process before injecting?
Yeah, I tried to suspend the process with Process Hacker as suggested in the other issue. No dice. Guess I'm waiting for the end of the month when the official soundtrack album comes out rather than dumping the radio station fmod bank. OH WELL. Thanks for your effort anyway!
FH4 Demo works for some reason
Sorry for the delay on this. Currently working full-time.
I have some ideas of things to try to poke in on the file-system but I also feel like it's probably crashing on something totally peripheral and trivial rather than Forza happening to have some advanced anti-dump stuff going on. Or they blocked shared pages somehow causing both processes to crash upon reading/writing to those pages. Does Forza require any specific Windows UWP/SDK versions?
How does the folder structure for the game look? Can someone run tree
on it and post the output here? How is the dumper or the game crashing? Does it have a "debug" option where you can seen a call-stack or memory location of some sort or some description of the error that it runs into like an access violation?
It's not related to permissions issues AFAIK. It seems to be blocking CreateThread.
No special windows or SDK versions from what i can see. And the folder layout is exactly the same as other titles. Albeit without the scrambled file names.
I am a firm believer that is is an anti-injection countermeasure, as the dumper worked just fine on press release 1. Even a dummy dll that just launches a command prompt window /Cybellum/DoubleAgent causes a crash.
Where would I be able to add the debug parameter?
Usually when a program crashes you'd be presented with some way to pick between closing the program or attempting to debug it. Which would allow you to pick a debug program like visual studio or ida or something to see the exact memory location, instructions, thread, and callstack where the crash occured.
If the crash happens at the Injector side then you can see where it crashes on the injector end but if DoubleAgent doesn't even seem to be able to get in then what it is probably doing is blocking the addition of loading additional DLLs at all somehow despite DoubleAgent being able to inject very early in the process creation. It also is capable of blocking it even with a suspended process somehow.
What do you mean exactly that it blocks CreateThread by the way? Is this in the injected DLL or in the injector itself and how did you derive that it's this? The injector runs CreateRemoteThread
which pretty much gets the target process to run CreateThread
. The injected DLL itself also creates a new thread for the actual dumping that occurs.
Right, after looking further my comment about createThread seems to be incorrect.
The app doesn't seem to be crashing either, since I would expect the app to throw the error you included above. Instead its terminating without throwing an error or prompting debug, as I've seen a lot of UWP apps do.
but if DoubleAgent doesn't even seem to be able to get in then what it is probably doing is blocking the addition of loading additional DLLs at all somehow despite DoubleAgent being able to inject very early in the process creation. It also is capable of blocking it even with a suspended process somehow.
bingo. DoubleAgents failure was a surprise to me.
Which makes me think it's definitely something inside the UWP wrapper itself, rather than the process it spawns, as suspending it has zero effect. I also found it impossible to attach x64dbg to put my, albeit uneducated, debugging skills to the test. lol.
Do you know if any other processes in memory are handed the keys to the EFS files? I've done some exploring of the network requests but found their MSA ticket format hard to decipher.
I don't know if DoubleAgent handles this. But any dll loaded into a UWP process has to have the S-1-15-2-1 (ALL APPLICATION PACKAGES
) access control too to be injected. Unless DoubleAgent already works with other UWP processes just fine and bypasses this requirement.
Debugging a UWP process externally via visual studio or IDAPro is generally pretty spotty since the virtualized UWP space doesn't play nice with being debugged from the native windows side on top of whatever anti-debug that Forza might have. Still surprising that even when suspended it crashes.
I've known some people that have tried to crack the EFS statically by snooping keys but haven't heard much from those efforts in a while to feel that it has been successful. Sometime this weekend I'll probably be able to get a hold of Forza running on my workstation to see exactly what's going on and do some refactors for UWPDumper in general such as by transporting all the file data through the IPC rather than using standard file IO into the tempstate folder and such.
Until then though any more detailed diagnostic info on this would help.
@Wunkolo Like I've already told you in my E-Mail I could provide access to FH4 if you like. But it seems like you've already found a different source. But the offer is still there
@Wunkolo Like I've already told you in my E-Mail I could provide access to FH4 if you like.
I'll check it out this weekend and join that discord and such. Thank you.
Can confirm that either the latest iteration of UWP or Forza itself is totally blocking any call to LoadLibrary
. Possibly UWP itself if it even blocks DoubleAgent but the fact that it works on the demo version of the game makes me think it's just Forza possibly tapping into some UWP feature that polices what DLLs are allowed to get loaded into the process.
I tried getting it to call LoadLibrary
from QueueUserAPC(which doesn't create a new thread) and it would still cause it to crash. Attaching a debugger also seems to throw an insane amount of access violations to just about any debugger I attach to it as well (visual studio, ida, windbg, etc) so I can't get any more details from the crash.
Maybe I'm approaching this naively as I haven't touched UWP stuff in a very long time but I could for sure use some aid on this. There is definitely some low-level library blocking going on.
Any idea on when this will be getting updated to work with fh4
I'm curious about that too.
Also interested if this is getting updated to work with FH4. Any news??
No updates as of now unfortunately
Hey there!!! I'm new on all this stuff (don't know nothing about coding and programming tbh) and very interested on decrypt the Forza Horizon 4 files, I know that at the time is not possible but If there is anything I could do to help I would be very pleased :)
As d1083168 said, the demo can be dumped… Cheers!!
Try doing it this way,
build release version of UWP Dumper, and download Process Hacker,
Start Forza Horizon 4, and get to the main menu, then open process hacker, find the game process and right click and suspend it.
use UWP Dumper has normal and it should dump the files, not sure 100% sure it works has I tried Sea of Thieves but that has a custom pak compression that uModel can't open, about to try with GOW4 though.
Edit* ok works with GOW4.
@Blenux doesn't work. suspended the process and it still crashed
Those of you still interested in ripping Forza should check this out
do you have a copy of those files as openload is gone
Try doing it this way,
build release version of UWP Dumper, and download Process Hacker,
Start Forza Horizon 4, and get to the main menu, then open process hacker, find the game process and right click and suspend it.
use UWP Dumper has normal and it should dump the files, not sure 100% sure it works has I tried Sea of Thieves but that has a custom pak compression that uModel can't open, about to try with GOW4 though.
Edit* ok works with GOW4.
this does work and the files returned don't have efs
Doesn't work, it still crashes :(
bump
As soon as the injector injects the DLL into FH4, the game just crashes and with it the dumper.