Inject .dll into Qt and call functions

[Paul Colby]

Disclaimer: I'm not a lawyer.

If the application is using a commercial Qt license, then you really ought not be messing with it, unless the copyright holder of that software has licensed you to do so (sounds unlikely in this case).

If the application is using Qt under the [L]GPL, then the [L]GPL protectes your right to replace the Qt libraries with your own modified versions, if you so wish. Of course, whether or not it's morally appropriate, is something for you to figure out.

So, which Qt license is the application using?

[Johannes S]

@Paul-Colby I tried to find something out about the license, but couldn't find any files in the directory, any info in the software itself and could also not find anything on the website..

@kshegunov I already have contacted the developers, I don't think I will have any luck there..all they told me was to "reinstall please..".

[kshegunov]

@Johannes-S
It's possible to do, however I really wish the @Moderators to take a look at this thread and give the green light. I hope you understand the reason for that ...

[Johannes S]

@kshegunov Sure, I hope they do give green light ;) So far thank you very much for the time you took!
Btw, this is what happens when I resize the tables with the WinAPI. The client area of the window simply doesn't adjust...

[Rondog]

This is not something that is automatically illegal (I assume). I have done this on two occasions in order to access information from software that was part of equipment I purchased in order to use it the way I need to. I've tried going through the manufacturer without success in both cases. The last one I wrote I told them what I was going to do to add the needed feature to their software and even sent them a working example. I couldn't wait for them to take action (which would be time measured in years if they decided to do this). They were not going to give me the source code and they didn't have anything suitable for my specific needs. If this is illegal then everyone who has ever written a debugger is breaking the law (another example of a practical use).

Now, when you do it this way there are many (many) problems. I limit what I do to hooking into specific message queues. Finding the window you want involves moving from the top level HWND (the only one you can directly find from an external process) and working your way down by searching for children with specific class and instance names. You are doing this from a separate thread you inject in the process space of the target application so this is another thing to be careful of. You need to make sure your hook doesn't create a problem with the target software.

If you can do this with something like SendMessage/PostMessage (i.e. WM_SIZE) then I am sure you can do it. If you need to call an API function from a thread specific instance in the running process I don't know about this. I only know a little about this subject (enough to do what I needed to do) so I assume anything is possible with enough time and effort.

[kshegunov]

@Rondog said:

I only know a little about this subject (enough to do what I needed to do) so I assume anything is possible with enough time and effort.

Once you get the binary you can always reverse engineer the assembly, in the end everything is executed at some point at that level. Of course, there are smarter (and easier) things to do (as you pointed out). Whether it's legal, I can't really say, such things are out of my expertise, I only wanted to make sure such kind of advice doesn't brake some forum rule.

[Johannes S]

Okay, so as I said, the WinAPI and SendMessage is not the way this will work.
I know how to do that and it used to work with the older version of their software, but now it doesn't work anymore.

What I really want to do, once I injected my .dll, is call QT functions directly on those windows.
I know how to find the HWND of the window I want to manipulate. What I don't know, is how to get that window as an instance of a QWidget and then how I would call for example QWidget::setGeometry() on that.

[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..