1

I'm interested in writing a network component to my IDAPython plugin, and QtNetwork looks really attractive, however it isn't include-able from IDAPython shell.

Is there a simple way to add that functionality?

Thanks.

  • Isn't it better to use Python's own networking modules? – joxeankoret Aug 4 '16 at 16:07
  • I'd really like qtnetwork's abitiliy to work async as part of the entire qt signals&slots. I'm also somewhat trying to avoid having requests as a dependency – NirIzr Aug 4 '16 at 16:34
  • I'm afraid that for doing so you will need to build yourself QT for IDA... See this: hexblog.com/?p=250 – joxeankoret Aug 5 '16 at 11:42
1

The official response I got from hex-rays states they rather avoid shipping too many third party libraries bundled with IDA if said libraries will not be helpful for the majority of users.

They suggested compiling the necessary Qt libraries myself and bundling the resulting packages with the plugin, but unfortunately this will be a nightmare to maintain (carrying out those packages for every IDA version).

Although using QNetwork will have some advantages (like clean async operation), my original goal was ease of maintenance and this is better achieved by using a python library like requests. That's probably the direction I'll be taking.

the full response is this:

We don't, because the disadvantages would far surpass the benefit. That is, we would have to ship many more libraries (no reason to stop to QtNetwork), that probably < 1% our users need, and adding that much bloat for such little benefit, doesn't really make sense to us.

That being said we provide instructions + patch to re-build it yourself from the original Qt 5.4.1 sources: - http://www.hexblog.com/?p=969

With those you should obtain a new Qt build, that corresponds to the one we're shipping, ... plus those libraries we don't ship (and PDBs, of course.)

They also went on and explained why Python/PyQt/QtWidgets.pyd are indeed shipped rather surprisingly:

A valid question would be: why ship python/PyQt5/QtWidgets.pyd then? ..well, there really is no reason. This is a mistake.

And finished by tipping off about an upcoming new minor release:

PS: We are a few days away from a new release (IDA 6.95), that will ship with Qt 5.6.0, which is a long-term release (i.e., 3 years support + bugfixes.)

Noting the complexities of bundling additional IDA-QT libraries with plugins:

Unless you really have to build specifically for IDA 6.9 (and thus Qt 5.4.1), perhaps it's best to wait for the new release, in order to not have to do it twice? (I'll write a similar blog post with configure options + patch for IDA 6.95)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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