Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DetourCreateProcessWithDll*W do not use wide char for the dlls names #159

Closed
Lectem opened this issue Dec 19, 2020 · 6 comments
Closed

DetourCreateProcessWithDll*W do not use wide char for the dlls names #159

Lectem opened this issue Dec 19, 2020 · 6 comments
Labels

Comments

@Lectem
Copy link

Lectem commented Dec 19, 2020

All variants of DetourCreateProcessWithDllExW are taking LPCSTR instead of LPCWSTR for the dll names.
It seems to be due to the fact that deep down UPDATE_IMPORTS_XX does not have a widechar version.
Would changing this be conceivable ?
This is an issue if the dll is in a path requiring it.

@number201724
Copy link
Contributor

Because the import table does not have a wide character version.

@Lectem
Copy link
Author

Lectem commented Dec 25, 2020

Yes but then how does one load a DLL using full path or subdirectories containing wide characters then?

@number201724
Copy link
Contributor

number201724 commented Dec 25, 2020

You should use MBCS whenever possible
It seems that there is no good way, or you can convert Unicode to ANSI.

@Lectem
Copy link
Author

Lectem commented Dec 25, 2020

Ah, I've been using Unicode since it is recommended here https://docs.microsoft.com/en-us/cpp/text/support-for-multibyte-character-sets-mbcss?view=msvc-160
I'm already converting to ANSI so I suppose there is no other way since Detours uses import tables to inject DLLs as you said. I'll just output an error message if conversion fails.
Thanks for the answer!

I suppose the only way to fix this issue would be to use another method for the dll injection than patching the import table. (would detouring the child process entry point work)?

@number201724
Copy link
Contributor

number201724 commented Dec 25, 2020

Modifying the import table is currently the most reliable method. Of course, if you need it, you can try CreateRemoteThread+LoadLibraryW to inject. It is also possible to modify AddressOfEntryPoint code.

@Lectem
Copy link
Author

Lectem commented Dec 25, 2020

Thanks I'll look into it if I ever have issues with import tables!

@Lectem Lectem closed this as completed Dec 25, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Jan 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants