ff14wed / deucalion Goto Github PK

Hi, I'm the maintainer of the detour fork!

I just renamed the repo/crate, so it's going to break your project, I'm really sorry about that.
But it's now on crates.io now here, so you can add it to your Cargo.toml!

retour = "0.1.0"

Figured I send out issues to the repos using it to avoid any confusion/frustration. Again, sorry about that, but this makes things a lot easier going forward.

Happy hacking! 😄

Deucalion uses its own signatures for finding the necessary function pointers automatically, This is very helpful, but if there is a problem finding the signatures, it would be helpful to know what they were / are for debugging purposes after game updates.

Can you add to the session log file (not debug output, that is unnecessary) the signature strings used when it scans for function pointers?

Issue

Although the Deucalion logs show successful shutdown, in some cases the module is still loaded in the target process preventing any future injection attempts and connections from being made.

Reproduction

1. Inject Deucalion into the target process, e.g.

   deucalion_client path/to/deucalion.dll
   

2. Using another client, force another injection of Deucalion into the target process, e.g.

   deucalion_client path/to/deucalion.dll -f
   

3. Disconnect both clients (Ctrl+C to exit)
4. Attempt to connect again with a new client. This client will fail to make a connection to the named pipe since it does not exist.

Symptoms

• Connecting to the named pipe yields the following error: The system cannot find the file specified. (os error 2)
• Disconnecting all clients and reconnecting a client will still fail to make a connection to Deucalion
• When listing the loaded modules on the target process, Deucalion will be loaded, but no threads are running and the named pipe does not exist.
• Checking the refcount on the Deucalion DLL yields a number greater than 0 even with no clients connected.
• Restarting the target process resolves the issue

Workarounds

• Restart the target process
• or use Deucalion client to eject the DLL (not guaranteed to work), e.g.

  deucalion_client path/to/deucalion.dll -e
  

Attempting to cargo build and it keeps failing, even after restarting.

Issue

This issue tracks the situation wherein the Deucalion named pipe handle still exists on the host process even after the DLL has been unloaded from memory. This issue should not occur during normal usage.

Reproduction

1. Inject Deucalion into the host process.
2. Connect a subscriber to Deucalion and start receiving data.
3. Use the signal_exit script to signal Deucalion to exit while data is being received.
4. The first subscriber will most likely hang waiting for more data. You can kill this subscriber since the server is gone.

Symptoms

• Connecting to the named pipe will result in an "i/o timeout" error
• Deucalion exits immediately after injection into the process, and logs state Server encountered error running: Access is denied. (os error 5)
• No data can be received by applications

Workaround

• Use Process Explorer to find the host process, scroll through the list of handles to find \\.\pipe\deucalion-* and forcibly kill the handle. New injection attempts should succeed.

Don't know if there's a solution for this.

If ACT is opened before the game, it seems to inject deucalion as soon as possible. Because deucalion adds hooks, a plugin attempting to scan for these signatures will fail. However, deucalion injecting after a plugin that uses these signatures seems to function fine. (unless ACT is falling back silently)

Is there any way the two can work together? My code could detect deucalion and fall back to using its IPC, but I have wanted to keep my code operating at the frame level, and deucalion emits packets.