Import of known / standard structures

[0x61616161]

What is the feature you'd like to have?
It would be nice to have a way to import certain types / standard structs via an interface, if the struct name is known.
(and assign that to some variable)

Is your feature request related to a problem?
Sometimes structs are not there, like for example some windows structs that might be used for malware that resolves APIs from hashes.

Are any alternative solutions acceptable?
I can just maintain my own header to import with a lot of standard structs inside.

[alexmullins]

+1 for this feature request.

My specific use case for this is I have a Windows binary that imports functions via GetProcAddress from ws2_32.dll at runtime which I'd like to be able to apply structure and function signatures for.

[fuzyll]

I believe the current plan is to implement something we're currently calling a "TypeArchive" (see #3827) that we can either provide with the product, or users can create and maintain. We also have an open issue for importing types from an existing .bndb file (see #3271).

If these sufficiently capture what you're looking for, I'm going to go ahead and close this as a duplicate (and you should thumbs-up and/or subscribe to one or both of those issues). If they're not, could you help us understand what about your use-case isn't captured there?

EDIT: Also, I believe importing your own header should work right now? At least, I'm pretty sure we added import and export of header files in 3.2 or 3.3, but I may be mistaken.

[0x61616161]

Like alexmullins said function signatures would be great ans something like:
I know this function uses a IWbemLocator struct, it would get for me the struct (maybe also the vtable structure), and all the types /structs that are required for that struct to be a valid type.

So I am not sure if that explains it well and if that is covered by the other features, from my understanding those are meant for sharing indeed. However as I understand it, in that case I already need to have created it somewhere, while it "could just be supplied by a standard library".

Basically I was thinking of something like the IDA "import standard structure" functionality. If that is covered by the other features I maybe misunderstand them

I hope this makes sense.

Edit: so maybe this would also cover importing specific types/function definitions to apply and import all related structs, (headers might be kind of a work around, but ideally we could import it from the existing typelibraries instead of moving exports from one file to the other or moving the typearchive around)

[fuzyll]

We do actually have facilities for creating and using function signatures, although they're available as a plugin and largely something you'd have to build yourself. The plugin in question is called sigkit. We don't have a great way for users to share those, pool them together, and/or query for them (like Lumina), though.

For stuff like types, that's currently handled by our type library system. Basically, when we start analyzing your executable, we act like a loader and try to resolve types from anything your executable loads. These types come from the type libraries that we ship with the product.

You can create your own type libraries, and we do have some documentation for it, but it's not as easy as we'd like. It's also not easy to open and use a type library after analysis. This is what issue #3827 is aimed at solving.

The existing workaround is to import/export headers, but I think I see your point: You'd like for Binary Ninja provide a set of default types that you can import from a list, like IDA's "standard structure" menu. I think this would be implemented via the TypeArchives in issue #3827, but I do think this is a separate feature request now.

Thanks for the clarification. 🙂

[plafosse]

Ideally we'd be able to import on-demand from type libraries. The current problem is that TypeLibraries aren't really set up for on demand loading. So this is blocked on #3903

[fuzyll]

This is a bad answer and we still need improvement, but there is a way to get some of these types out of our type libraries right now. See the comment I left here: #3836 (comment).