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

can't found the window handle in handle view #2032

Open
oldn123 opened this Issue Sep 21, 2018 · 10 comments

Comments

Projects
None yet
5 participants
@oldn123

oldn123 commented Sep 21, 2018

hi, master
If the child window is the parent window of other processes, then after attach this process I can‘t found the window handle in handle view.

@pdcrrt

This comment has been minimized.

Show comment
Hide comment
@pdcrrt

pdcrrt Sep 21, 2018

Can you send some screens?

pdcrrt commented Sep 21, 2018

Can you send some screens?

@oldn123

This comment has been minimized.

Show comment
Hide comment
@oldn123

oldn123 Sep 21, 2018

image
the child window in process(id:33c4), hwnd=3086e

image
cant't find 3086e

oldn123 commented Sep 21, 2018

image
the child window in process(id:33c4), hwnd=3086e

image
cant't find 3086e

@mrexodia

This comment has been minimized.

Show comment
Hide comment
@mrexodia

mrexodia Sep 23, 2018

Member

The code for enumerating is here, do you see the bug?

bool HandlesEnumWindows(std::vector<WINDOW_INFO> & windowsList)

Member

mrexodia commented Sep 23, 2018

The code for enumerating is here, do you see the bug?

bool HandlesEnumWindows(std::vector<WINDOW_INFO> & windowsList)

@Mattiwatti

This comment has been minimized.

Show comment
Hide comment
@Mattiwatti

Mattiwatti Sep 29, 2018

Contributor

This is probably going to be borderline useless given my abysmal knowledge of Win32 GUI programming, but... of the two decent 'window spy' tools I know, one (your Spy++) uses DLL injection to set a hook, and the other (Process Hacker's Window Explorer) uses a fairly convoluted method involving a shared section but which does seem to avoid straight out DLL injection. (NB: I linked to an older commit on purpose as the current PH codebase is completely broken on my machine and this file seems to have been removed as well...). The PH DLL runs in two separate 'modes' (client or server) depending on the process context and these communicate with each other to post/retrieve info on the window proc addresses and such.

So compared to this, the x64dbg approach suddenly seems rather tame. Not that I'm complaining 😆 I'm not sure what the advantage of a hook DLL would be over simply enumerating windows out-of-process; maybe someone can tell me why these tools go to such lengths to enumerate other processs windows this way, no doubt there's a reason for it. But I think any solution requiring either DLL injection or section mapping would more likely fall into plugin territory than x64dbg core functionality.

OP, is it possible for you to post a small sample app (preferably not malware - if malware, please let me know in advance so I'll use my Windows 10 box) with some steps to reproduce? I'm not 100% clear on what order the process -> window creation is supposed to go, which process owns what window, and which process I should be debugging.

Contributor

Mattiwatti commented Sep 29, 2018

This is probably going to be borderline useless given my abysmal knowledge of Win32 GUI programming, but... of the two decent 'window spy' tools I know, one (your Spy++) uses DLL injection to set a hook, and the other (Process Hacker's Window Explorer) uses a fairly convoluted method involving a shared section but which does seem to avoid straight out DLL injection. (NB: I linked to an older commit on purpose as the current PH codebase is completely broken on my machine and this file seems to have been removed as well...). The PH DLL runs in two separate 'modes' (client or server) depending on the process context and these communicate with each other to post/retrieve info on the window proc addresses and such.

So compared to this, the x64dbg approach suddenly seems rather tame. Not that I'm complaining 😆 I'm not sure what the advantage of a hook DLL would be over simply enumerating windows out-of-process; maybe someone can tell me why these tools go to such lengths to enumerate other processs windows this way, no doubt there's a reason for it. But I think any solution requiring either DLL injection or section mapping would more likely fall into plugin territory than x64dbg core functionality.

OP, is it possible for you to post a small sample app (preferably not malware - if malware, please let me know in advance so I'll use my Windows 10 box) with some steps to reproduce? I'm not 100% clear on what order the process -> window creation is supposed to go, which process owns what window, and which process I should be debugging.

@oldn123

This comment has been minimized.

Show comment
Hide comment
@oldn123

oldn123 Sep 30, 2018

I've just experimented with another set of applications, and the problem is the same as the topic. I've created two GUI processes, set the main window of the first process to the child window of the second process, and then look at the second process with x32dbg and spy ++ respectively, and compare the windows they listed. You can see the difference.

oldn123 commented Sep 30, 2018

I've just experimented with another set of applications, and the problem is the same as the topic. I've created two GUI processes, set the main window of the first process to the child window of the second process, and then look at the second process with x32dbg and spy ++ respectively, and compare the windows they listed. You can see the difference.

@mrexodia

This comment has been minimized.

Show comment
Hide comment
@mrexodia

mrexodia Oct 1, 2018

Member

@oldn123 I believe there is a difference, but I was asking if you have any idea why this difference happens 🙂 Possibly x64dbg just simply doesn't enumerate child windows...

Member

mrexodia commented Oct 1, 2018

@oldn123 I believe there is a difference, but I was asking if you have any idea why this difference happens 🙂 Possibly x64dbg just simply doesn't enumerate child windows...

@Mattiwatti

This comment has been minimized.

Show comment
Hide comment
@Mattiwatti

Mattiwatti Oct 1, 2018

Contributor

@mrexodia And that in turn was why I was wondering why all these 'specialized'/'good' (admittedly, N = 2) window inspectors that give accurate results seem to need a hook DLL 😛 (not a rhetorical question, I have no idea.)

ping @reliasn

Contributor

Mattiwatti commented Oct 1, 2018

@mrexodia And that in turn was why I was wondering why all these 'specialized'/'good' (admittedly, N = 2) window inspectors that give accurate results seem to need a hook DLL 😛 (not a rhetorical question, I have no idea.)

ping @reliasn

@oldn123

This comment has been minimized.

Show comment
Hide comment
@oldn123

oldn123 Oct 1, 2018

@mrexodia yes, the EnumWindows just only enumerate all top-level windows , so it be missing .

oldn123 commented Oct 1, 2018

@mrexodia yes, the EnumWindows just only enumerate all top-level windows , so it be missing .

@torusrxxx

This comment has been minimized.

Show comment
Hide comment
@torusrxxx

torusrxxx Oct 2, 2018

Member

Child windows are followed and enumerated.

EnumChildWindows((HWND)i->handle, getWindowInfoCallback, (LPARAM)&childWindowsList);

Member

torusrxxx commented Oct 2, 2018

Child windows are followed and enumerated.

EnumChildWindows((HWND)i->handle, getWindowInfoCallback, (LPARAM)&childWindowsList);

@torusrxxx

This comment has been minimized.

Show comment
Hide comment
@torusrxxx

torusrxxx Oct 2, 2018

Member

A possible problem of the code is that when the debuggee creates a child window under a parent window which the debuggee doesn't own (ridiculous but not impossible). In this case that top level window will be dropped at first EnumWindows scan, and then this child window of debuggee is missed.

Member

torusrxxx commented Oct 2, 2018

A possible problem of the code is that when the debuggee creates a child window under a parent window which the debuggee doesn't own (ridiculous but not impossible). In this case that top level window will be dropped at first EnumWindows scan, and then this child window of debuggee is missed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment