Nir

Let me know if you'd like me to have a look

This might fix it: https://www.hex-rays.com/products/ida/support/sdkdoc/kernwin_8hpp.html#a325854efebf01eab393c293a128f46b5

I think benefit/work ratio here is quite poor. We could parallelize by dividing the work into several threads: One reads the data and one serializes and sends it. Right now...

`idc.GetManyBytes` might be helpful there. Totally up for doing that if it's worth-while.

You might also want to checkout `idautils.FuncItems`

@shiftre Is this still a requirement for `first-release` milestone or are we satisfied with the delayed network requests happening in a different thread?

There are two types of graphs, one is a function's graph (the one i think you're talking about - graph of connections between function basic blocks), and another which is...

There are different types of hashes. Hash might work on assembly, binary or parts thereof. Generally +1 though

This is not set for the first-release milestone. The big benefit here won't be from successfully matching the data objects themselves (as those are indeed rarely interesting or difficult), but...

Won't 'export to IDC' work for both of these cases? Such matches should be off by default, otherwise they'll interfere with every other type of match