4

My goal is to see what's going on "under the hood" in the Windows command prompt when a user pastes text into it. So I loaded cmd.exe into IDA Pro that is set up in conjunction with the WinDbg debugger.

My initial guess was to put a breakpoint on OpenClipboard API which must be used to access clipboard, but it seems like cmd.exe doesn't even have a dependency on User32.dll (where OpenClipboard comes from):

enter image description here

So am I reading it correctly?

PS. I'm doing this on Windows 10.

EDIT: You know, there's something other than deferred loading. I let the cmd.exe initialize and begin running, after which I suspended it. The loaded modules list still didn't have user32.dll:

enter image description here

and my deferred breakpoint didn't trigger upon clipboard operation either:

enter image description here

Could there be some other process that does all the "command line" logic?

EDIT 2: Just tried to attach to a running conhost.exe:

enter image description here

while IDA Pro was running as administrator and got this error:

enter image description here

EDIT 3: Just tried to attach to conhost.exe via just WinDbg itself and got this error. I'm not sure how NTSTATUS 0xC00000BB applies here:

enter image description here

Improve this question
3
  • 1
    Using depends.exe on cmd.exe in syswow64 shows user32.dll as a delayed loaded module. I assume your screenshot only shows the currently loaded modules thus the discrepency.
    – Lieven Keersmaekers
    Commented Jun 23, 2016 at 6:13
  • @LievenKeersmaekers: Sorry for the delay. I updated my original question with additional info. And delayed loading doesn't seem to be the case here.
    – c00000fd
    Commented Jun 29, 2016 at 3:15
  • looks like you're using x86 windbg to attach to an x64 process :) This is not going to work.
    – Igor Skochinsky ♦
    Commented Jul 1, 2016 at 8:08

2 Answers 2

Reset to default
1

well if you cant attach with windbg then you have some other problem
uac / clamped down / policy / whatever // conhost.exe is attachable
(check if you are attaching to the correct conhost.exe there may be several some of them spawned by system user

screenshot showing windbg being attached to conhost and broke on OpenClipBoard with Hwnd (HANDLE of consoleWindowClass)

enter image description here

on the paste operation 

0:001> kb2
 # ChildEBP RetAddr  Args to Child              
00 020afc28 00adf554 020afd34 00000111 00000000 conhost!DoPaste+0x3d
01 020afcb8 773ec4e7 00080260 00000111 0000fff1 conhost!ConsoleWindowProc+0x847
0:001> ub eip l1
conhost!DoPaste+0x37:
00ae2d05 ff155411ad00    call    dword ptr [conhost!_imp__GetClipboardData (00ad1154)]
0:001> ? @$retreg
Evaluate expression: 10616892 = 00a2003c
0:001> du poi(@$retreg)
00172fa0  "2580 windbg.exe        Pid 3424 "
00172fe0  "- WinDbg:10.0.10586.567 X86"
0:001> g

as to comment yes maybe i dont know
a cursory glance over google says conhost is now a child of cmd in windows 10
the conhost enhancements technical preview article by some ms devs don't mention anything about conhost being protected super proteccted or ultra protected process
and i dont have a win10 handy so i can answer your comment only when i spleunk under winX till then happy hunting

well it appears i can attach in winX too
(winx is running in vmware player (test mode ) ) windbg screen shotted is runnning inside target os

enter image description here

Improve this answer
3
  • Thanks. Yeah, that's the right process. I checked. It was spawned right when cmd.exe was started. I updated my original post with the error message I got in WinDbg. BTW. I'm doing it on Win10. You're using Win7. Could that be the difference?
    – c00000fd
    Commented Jul 1, 2016 at 6:09
  • no dont see any logic difference between vii and x apart from some new dlls / functions //control flow from console to core APIS
    – blabb
    Commented Jul 1, 2016 at 10:33
  • OK. I got it solved... somewhat. I was using IDA Pro to start the process and then WinDbg thru it. It turns out that IDA Pro cannot attach to a 64-bit process so it was using a 32-bit version of WinDbg implicitly. Thus I was getting that strange error. I also discovered that I was using an old version of WinDbg. And lastly, even though I was originally starting a 32-bit version of cmd.exe it was implicitly connecting to a 64-bit version of conhost.exe. So eventually I had to ditch IDA and go with bare WinDbg which is somewhat hard to use... but it did the job. So thank you!
    – c00000fd
    Commented Jul 4, 2016 at 4:57
3

The actual console window is drawn and managed by conhost.exe, not cmd.exe. conhost.exe calling OpenClipboard

Improve this answer
3
  • Sorry, I'm somewhat new to this. Can you give more details on how you set that breakpoint?
    – c00000fd
    Commented Jun 29, 2016 at 15:29
  • attach to conhost.exe, pause, switch to asm (Alt-8), enter user32.dll!OpenClipboard in the address field, add breakpoint from asm listing. But VS is not very good debugger when you don't have source, I recommend you to use Windbg or IDA.
    – Igor Skochinsky ♦
    Commented Jun 29, 2016 at 19:01
  • Thanks. Tried to attach to conhost.exe and got access denied error. I updated my question w/details. Any idea why am I getting that error?
    – c00000fd
    Commented Jul 1, 2016 at 5:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.