clink doesn't inject when launched though ConEmu about clink HOT 14 CLOSED

From [email protected] on July 06, 2012 05:41:41

I think this might be a problem with x86 installs of clink on x64. I presume you picked the autorun install option? Does clink load as expected if you run the x86 cmd.exe from c:\Windows\SysWOW64\cmd.exe?

Status: Accepted
Owner: [email protected]

from clink.

From [email protected] on July 07, 2012 02:32:30

Bug still happens when using the x86 version. I did pick the auto-run option, but running the clink binarys (clink_x86/64.exe?) manually seems to have no affect both in normal cmd and cmd launched though conemu

from clink.

From [email protected] on July 14, 2012 09:06:54

For clarification. ConEmu also uses "inject" technology (CreateProcess with CREATE_SUSPENDED flag, SetThreadContext, and ResumeThread). Don't know what technique click is used. May be they interfere.

from clink.

From [email protected] on July 14, 2012 10:41:33

Thanks for the info . Although I've not had opportunity to look into this yet, my expectation is ConEmu and clink are trying to apply hooks in the same place.

Clink hooks Read/WriteConsoleW() by injecting a DLL into cmd.exe and patching its import table. If the addresses it's replacing aren't in kernel32.dll it silently fails. I expect ConEmu has already changed the import table so clink decides it's best not to hook.

There are alternatives that I can do with clink so it can be used with a ConEmu owned cmd.exe process.

from clink.

From [email protected] on July 14, 2012 10:45:37

Yes, these functions are hooked. You may check, if the addresses are in ConEmuHk.dll (ConEmuHk64.dll) when started under ConEmu?

from clink.

From [email protected] on July 14, 2012 10:51:22

However, I have a plans about command line (cmd/powershell/etc.) May be, you are interested in integration/distribution with ConEmu?

from clink.

From [email protected] on July 14, 2012 11:06:06

Good to know that ConEmu hooks those two functions. What is the purpose of the hooks? Do they eventually call through to the original Read/WriteConsoleW() functions?

The easy fix is to remove the sanity check that the hook is in kernel32.dll and just hook regardless. This will of course bypass whatever ConEmu wants to do with those two APIs. Alternatively I could apply the hook in the kernel32.dll code segment. I'll know more once I look into it.

Integration/distribution sounds interesting. Drop me a mail outside of this issue and we can discuss it further if you'd like.

from clink.

From [email protected] on July 14, 2012 11:15:50

Yes, in the current version ConEmu bypass calls to kernel32.

ReadConsole(A|W) used for detection of "prompt is active now". ConEmu may position cursor in prompt with mouse click.

WriteConsole(A|W) used for ANSI x3.64 support. So, ESC codes are stripped from output and the rest passed to kernel32.

from clink.

From [email protected] on July 15, 2012 23:58:45

I think, you may close the issue without changes in code.
I'm going to create an option in ConEmu for loading clink_dll_x86.dll/clink_dll_x64.dll on demand and calling its exported call_readline.

Howerer there are few another issues

1. I think, clink must not try to change imports, when it is runned under ConEmu.
2. call_readline may be called not only for cmd.exe. For example, powershell calls ReadConsole too.
3. For information, not only ConEmu changes imports in executable. This may be AnsiCon http://adoxa.3eeweb.com/ansicon/ or Console2.

from clink.

From [email protected] on July 16, 2012 11:00:44

I'll touch upon two subjects in this comment. First I'll talk about how I plan to fix this issue, and secondly I'll comment on your plan to load clink's DLLs on demand.

Fixing the issue; There are many ways to hook API calls, the easiest of which is to patch the IAT. I will add a fallback hooking method (or two) to clink which it will use should it fail to hook the IAT. This way if ConEmu or the others you mention have already installed hooks they'll continue to work as intended and clink will also get the calls it needs.

Now to loading DLLs on demand; I advise against your approach of manually loading clink DLLs and calling the exported function for two reasons;

1. As the name may suggest, the call_readline() function only handles calling the Readline library. This is only part of the process and without the other half you will be missing core features (such as Doskey macro expansion).
2. The only reason call_readline() is exported is for my small test app that I use during development. It is not a public API and therefore should be considered volatile and likely to change. Particularly so given point 1.

from clink.

From [email protected] on July 16, 2012 11:31:07

Well, let see, how you'll change API call hooking. Few questions for now.

1. One thing, I'm afraid: if you install injects (after ConEmu) my hook will not be called at all, look

   Now (with call_readline):
   cmd.exe->ReadConsole->
   ConEmuHk.dll::HookedReadConsole->(pre ReadConsole operation)->
   clink_dll_x86.dll::call_readline
   ConEmuHk.dll::HookedReadConsole->(post ReadConsole operation)->
   cmd.exe...
   If you install hooks:
   cmd.exe->ReadConsole->
   clink_dll_x86.dll::hooked_read_console->(pre ReadConsole operation)->
   clink_dll_x86.dll::call_readline
   clink_dll_x86.dll::hooked_read_console->(post ReadConsole operation)->
   cmd.exe...
   And ConEmu is out of the road.

2. Another thing, I don't understand, what "another part of the process" you are mention. Future part? Now, looking into the code I can see only two hooks ReadConsoleW and WriteConsoleW.

3. At last, how do you plan to provide functionality to arbitrary process? For example, user run some shell (not a cmd.exe) in the ConEmu and want to use completion routines. What ConEmu shell do to provide this feature? I don't like assumption, that user must run some command every time after shell is loading.

from clink.

From [email protected] on July 16, 2012 12:26:12

I should have been clearer with my explanation; I shall have clink fallback to an alternative method of hooking into cmd.exe that does NOT modify the IAT of any module in the process. Any existing hooks will remain UNTOUCHED and continue to function as the author intended.

from clink.

From [email protected] on July 17, 2012 00:33:02

However, while new clink version is not available yet, anyone who wishes may play with ConEmu build 120716 (it works with clink through export so far).

from clink.

From [email protected] on July 23, 2012 15:36:45

Will be fixed in 0.2.

Status: Fixed

from clink.