Skip to content

Expose enum-displayed operands and per-address string type#57

Open
ChrisKader wants to merge 7 commits into
Vector35:mainfrom
ChrisKader:feature/idb-import-data
Open

Expose enum-displayed operands and per-address string type#57
ChrisKader wants to merge 7 commits into
Vector35:mainfrom
ChrisKader:feature/idb-import-data

Conversation

@ChrisKader

Copy link
Copy Markdown

Summary

Adds the address-info APIs needed to recover how IDA displays operands and string literals, used by the Binary Ninja idb_import plugin.

Additions

  • Enum-displayed operands. AddressInfo::op_enum reads the per-operand enumeration reference (NALT_ENUM0/1 altval); op_enum_name resolves the referenced tid's netnode name; op_enum_type resolves the member tid back to the exact owning enumeration in a TILSection by tid range, so it returns the correct enum regardless of member-name collisions and whether the enum lives in a type library or the local types.
  • String literal type. AddressInfo::str_type decodes the per-address NALT_STRTYPE altval into width (byte/word/dword) and layout, so importers can type strings as the correct UTF-16/UTF-32 width.
  • Tooling. dump-address-info now reports the enum tid, resolved member, and owning enumeration for operands 0/1.

Note

Branch also contains the earlier "Parse bare BT_UNK / harden dirtree dump" change submitted as #56.

A type byte of 0x00 (BT_UNK with BTMT_SIZE0) is IDA's unknown type of
unspecified size, which appears in real databases as function argument and
return types. It was being rejected with "forbidden use of BT_UNK", which
aborted type parsing for any function that used it. Treat it like BT_UNKNOWN
(unknown, unspecified size) instead.

Also harden dump-dirtree-funcs so a single function whose label or type fails
to parse no longer panics the whole dump: per-function parse errors are
tolerated and, if printing a function still fails, the entry is emitted with
an inline error note rather than unwrapping.
Some databases carry extra bytes after the IDBParam structure. Erroring on
that aborted root-info parsing (and therefore the whole import) for those
files. Gate the "Data left after the IDBParam" check behind the `restrictive`
feature, matching how other strictness checks are handled, so normal parsing
tolerates the trailing data.
Add AddressInfo::str_type, which decodes the NALT_STRTYPE altval into the
character width (1/2/4 byte) and layout (zero-terminated or Pascal) IDA
recorded for a string literal. This is the SDK's get_str_type and lets
consumers distinguish C strings from UTF-16/UTF-32 and Pascal strings instead
of assuming single-byte characters.
Add AddressInfo::op_enum, reading the NALT_ENUM0/NALT_ENUM1 altval to return
the enumeration id an instruction operand is displayed against (the SDK's
op_enum / get_enum_id). This lets consumers render enum operands with the
referenced enumeration instead of a bare number.
An enum operand's altval holds a tid, and that tid is itself a netnode whose
N-tag name is the symbolic constant / type it identifies. Add
ID0Section::netnode_type_name to read that name (stripping IDA's `$$ ` prefix)
and AddressInfo::op_enum_name to resolve an operand's tid to it. This works
whether the enumeration lives in a type library or the local types, so callers
can identify exactly which enum an operand uses rather than only seeing a raw
tid.
Add AddressInfo::op_enum_type, which maps an enum operand's member tid back to
the enumeration it belongs to. An enum operand references a specific member
whose netnode is allocated right after the enumeration's own netnode (members
occupy enum_tid + 1 ..= enum_tid + member_count), so the member tid is matched
against each enumeration's tid range. This returns the exact enumeration
regardless of member-name collisions, for enumerations in a type library or
the local types, rather than relying on a name match.
Print op_enum tid, the resolved member name and the owning enumeration
(op_enum_type) for operands 0 and 1, so the address-info dump can be used to
inspect which operands IDA displays against an enumeration.
@emesare emesare self-assigned this Jun 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants