Inject .dll into Qt and call functions

kshegunov

@Johannes-S
Well, no one objected, so I suppose discussing this isn't a problem. There are several approaches to this. One of the more popular ones is to attach to the running process, and load a dll into the address space. Then by some means (ordinarily starting a thread) to start your code. Another option is to have a custom loader, that does what the OS loader does, but at some point it'd load additional dlls. Another possibility is to attach to an interrupt (for example I/O operation) and inject code there. In any case Windows provides a documented API to do most of those things. Hooks installed at the system level are also a possibility, they work similarly to how Qt handles event filters, and are executed before a message is passed to the application to process. You could find some more detailed information here.

Once you have your code loaded into the process' address space. You can use QCoreApplication::instance() to retrieve the application object; QGuiApplication::topLevelWindows() to retrieve a list of the top level windows, or QApplication::topLevelWidgets() for top-level widgets if the application is using widgets (this can be discerned by the dlls it ships. If the Qt5Widgets.dll is present, most probably the application is using widgets). Once a pointer to widget or a window is known dynamic_casts/qobject_cast can be used to get the exact type of the widget/window, and Qt messages can be posted to them with QCoreApplication::postEvent() (this static function is thread-safe). By such means a resize event can be marshaled to an arbitrary widget/window thus providing the functionallity you're after.

Directly resizing the HWND handle by means of the WinAPI (supposedly) doesn't work, because in Qt most of the windows/widgets don't actually have a handle and are using the top-level widget's/window's to draw themselves. Additionally the main window's drawing surface is changed externally, but child objects (layouts/child widgets) are not notified, so you get clipping.

Kind regards.

Johannes S

@kshegunov Thanks alot for your reply.
I already got the .dll injected, what I'm struggling with is the second part. Your suggestions already helped alot. But one more question: how do I get the declaration of QApplication in my .dll code? Do I have to include the QT header files when compiling the .dll? Or do I have to load the classes dynamically? In that case: how would I do that?

About your last paragraph: Is there any chance to forward those events to the children, so I don't need all that dll-injection crap?

Really BIG thanks! That already helped alot!

kshegunov

@Johannes-S said:

how do I get the declaration of QApplication in my .dll code?

Yes, for the declarations you'd need the header files for Qt. Actually, Qt makes this easier by it's insistence of being binary compatible (which is a great thing on itself). This means that you shouldn't much care about the minor and patch versions of the Qt you obtain (to get the header files).

Additional note:
The headers won't be just enough, the linker will want to know about the symbols exported from the library. One way is find out the exact Qt version the said application is using, build Qt yourself (or download it) to finally obtain the .lib file and then use that to pass it to the linker. Or alternatively, you can obtain the library exports from the dll the application ships as described here or any equivalent method.

Is there any chance to forward those events to the children, so I don't need all that dll-injection crap?

You can post events to any QObject with QCoreApplication::postEvent, however you'd need to obtain a QObject * pointing to the object of interest. You are doing the dll injection, because your code has to run in the process' address space, not because you can't query the application/widgets/windows/objects for their children.

Kind regards.

Johannes S

Wow okay, that doesn't sound too complicated. Ill probably just need to create lib files from the .dlls of Qt5Widgtes.dll, Qt5Core.dll and maybe Qt5.Gui, right?
I'll give it a try this afternoon and probably come back after I've failed ;)

Big thanks!

Johannes S

Okay, I got to thank you guys a million times, this really worked and I got my .dll injected and am able to find the QWidgets and call QT functions on them.

Thank you!

However, the problem still persists: I tried resizing with setGeometry() and resize(), I tried to call update() and repaint() afterwards, but the clipping still does occur.
Any idea how I can fix that? Is there a chance I can identify the functions that are called when I resize the window manually (by mouse dragging?).
If I knew the function, I guess I could get it to work!

kshegunov

@Johannes-S
Hi,

However, the problem still persists: I tried resizing with setGeometry() and resize(), I tried to call update() and repaint() afterwards, but the clipping still does occur.

Does the window resize itself though, the clipping aside?

Any idea how I can fix that?

It really depends on how the application actually implemented the resizing/painting.

Is there a chance I can identify the functions that are called when I resize the window manually (by mouse dragging?).

Well, dragging the window will fire QResizeEvents, but how exactly those are handled can't be known at that level. The events can be intercepted before they reach the widget by installing an event filter, but I don't see how this'd help.

Johannes S

@kshegunov said:

Does the window resize itself though, the clipping aside?

So yeah, the window is smaller/bigger than before. Only the client area doesn't adjust properly.
I've tried sending QResizeEvents, but that didnt really help.

Isn't there a way to monitor the functions that are being called? If I could do that, I could resize the window by mouse and watch which functions are being used to resize..

kshegunov

@Johannes-S said:

Isn't there a way to monitor the functions that are being called?

In an optimized compiled code (like Qt that's used in this case), no, not really. The compiler have probably inlined whatever it could and stripped many of the call instructions (you'd expect such when a function is called). And even if it hadn't it would take ages to sift through the assembly, and all that for a dubious result. The stack frame won't have any references to function names, only to addresses, so it's simply not worth even trying.

One thing you could attempt is to inspect the properties of the main window or the central widget. It may be set to not resize through the size policy and/or minimum/maximum size, or in some other fashion. Currently, I don't have any better ideas.

Although I haven't done this, as a last resort you could in principle try to overwrite the virtual table, if in fact the resizeEvent function was overriden ...

JulienMaille

Isn't it the purpose of GammaRay?
https://github.com/KDAB/GammaRay

mrjj

Hi, just a thought
Maybe try to use findChildren and dump all ClassNames to see
how its structured.
That might give hints on what we need to target to resize.
also as @kshegunov, dump sizepol, min,max and geometry
for all Widgets owned by mainwin and childs.

kshegunov

@JulienMaille
Possibly, but I don't know if it'll work without the debug information. Worth a try though.

Johannes S

Thanks a million guys, didn't have time to look into it today, but I'll try everything out tomorrow and let you know how it worked!

Johannes S

Okay, I've tried to dump some info on the window. This is what I got:

Dumping window info:
Class name: TableMainWidget
Horizontal size policy: 5 Vertical size policy: 5
Minimum size: 480/340
Maximum size: 2560/1815
44 children found:

Class name: QRubberBand

Class name: QWidget
Form
Class name: TableLayoutWidget

Class name: QGraphicsView

Class name: QWidget

Class name: QScrollBar

Class name: QWidget

Class name: QScrollBar

Class name: QWidget

Class name: QWidget

Class name: QWidget
Form
Class name: CMinigamesTitleWidget

Class name: QWidget

Class name: QGraphicsView

Class name: QWidget

Class name: QScrollBar

Class name: QWidget

Class name: QScrollBar

Class name: QWidget

Class name: QWidget

Class name: QGraphicsView

Class name: QWidget

Class name: QScrollBar

Class name: QWidget

Class name: QScrollBar

Class name: QWidget

Class name: QScrollArea

Class name: QWidget
Form
Class name: CMinigamesPanelWidget

Class name: QWidget

Class name: QWebView
Betfair
Class name: QWebView

Class name: QWidget

Class name: QScrollBar

Class name: QWidget

Class name: QScrollBar

Class name: QWidget

Class name: QWidget

Class name: QWidget

Class name: QWidget

Class name: QWidget

Class name: QWidget

Class name: QWidget

Class name: QWidget

Not that helpful so far...I'm trying to get GammaRay to work.

EDIT: So, I've cloned the git repo and cmake. I've used the cmake gui to build GammaRay with the visual studio 12 compiler. Then I've opened the solution file and built it with Qt5.
For two files, I'm getting this error:

qtmain.lib(qtmain_win.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1800' in main.obj

The other 70 succeed. I then tried to start the gammaray.exe, but I'm getting:
error1
error2

What am I doing wrong here? Sorry that I seem to be so incompetent, I'm always struggling with this sh*t..

JulienMaille

@Johannes-S GammaRay needs to be compiled for exactly the Qt version you are using in the application you are debugging (and on most platforms even with the same compiler and compiler settings)

https://github.com/KDAB/GammaRay/wiki/Getting-GammaRay

kshegunov

@Johannes-S
Besides Gamma ray, i'd suggest focusing your investigations on CMinigamesPanelWidget subclass (possibly on Betfair as well).

Johannes S

@JulienMaille Yeah I figured that out, but I wasn't even able to start GammaRay without attaching it to anything...

Johannes S

Thank you very much, all of you who helped me here!
I finally got it to work today. It was the TableLayoutWidget, which I had tried to resize before, but I made a stupid mistake...I checked if the className was equal to "TableLayoutWidget" and resized only if it was. However, since I received the classname as a const char* the comparison to a string always failed and nothing happened...

So now all thats left to do is to find a way to easily communicate with the process to resize windows without reinjecting a .dll every time.

Thanks again!

EDIT: Do you know if there's a way to automatically subclass (SetWindowLong with a new WndProc) all windows of a process?

kshegunov

@Johannes-S
I'm glad it worked.

So now all thats left to do is to find a way to easily communicate with the process to resize windows without reinjecting a .dll every time.

This may not be possible, although don't hold me to that statement.

Do you know if there's a way to automatically subclass (SetWindowLong with a new WndProc) all windows of a process?

I have no clue what you're talking about, but it's probably just me. I haven't developed for Windows for quite a lot of years.

Kind regards.

patxi

Hi, sorry for the bump. I am upping this because I'd like to share some more thoughts about this topic with @Johannes-S. I hope I didn't break any rules.

mrjj

@patxi
Its quite ok
but the poster has not been online for 10 month so you might have better luck just posting a new question
regarding GammaRay and see what happens :)