Add handling for `disas:` URI scheme for shareable "deep linking" to locations within binaries

Start by tracing the existing binaryninja: URI handling and the code path used for opening or activating files and navigating to an expression. Review open file history and the binaryninjaui Python API, then compare the linked Ghidra and IDA URI formats. Done means matching disas: URIs can locate open or historical binaries by MD5, open or activate them, and navigate to the requested offset.

What is the feature you'd like to have?

Add support for handling the disas: URI scheme that is already supported by plugins for IDA Pro and Ghidra, for sharing cross-tool deep links to offsets within binaries, primarily to support collaboration between researchers as well as note-taking.

URIs are of the form disas://<md5-hash-of-original-binary>?offset=<offset-in-hex>

Are any alternative solutions acceptable?
We currently implement the binaryninja: URI scheme, with a slightly different format:

binaryninja:<URI>?expr=<expression>

where URI can be a file:, http:, or https: URI, a bare file path (including a bare filename to navigate in an open tab with a matching filename), or empty (to navigate in the currently active tab), and <expression> can be any expression parseable by the expression parser used by our Go to Address dialog (where unprefixed numbers are parsed as hex, not decimal).

The existing URI handling should be extended to take in disas: URIs in the common format and search for files with matching hashes among

1. Currently open files
2. Files in the open file history

If a match is found, it should be opened or its open tab should be activated, and navigation to the offset should be performed the same as binaryninja: URIs. Basically this would be a different entry point to a point in the same code path.

The primary issue is that we do not currently compute or store MD5 hashes for input binaries, so searching would require on-demand hashing of candidate files, or adding precomputed hashes to the database. (An alternative would be to compute MD5 hashes and store them in the open file history.)

Additional features could include other query parameters such as filename, path, view_type, il_index, etc.

Enterprise-specific URIs should also be supported.

Finally, a "copy URI for location/selection" action should be added to the UI and exposed in the binaryninjaui python API.

Additional Information:

Links to the existing implementations for Ghidra and IDA:

Ghidra: https://github.com/foundryzero/ghidra-deep-links?tab=readme-ov-file#-url-format

IDA: https://github.com/interruptlabs/heimdallr-client?tab=readme-ov-file#usage

Vector 35 employees can find additional notes by searching for "disas spec collab" on the internal wiki.