Feature request: Publicize Rust API FFI conversion functions

[comex]

What is the feature you'd like to have?
In the Rust API, the functionality to convert between the Rust wrapper types and the underlying C FFI types is currently marked pub(crate). I am requesting that it be made public in some form. This functionality includes from_raw, into_raw, inc_ref, the handle property (could be changed to a function), etc.

Is your feature request related to a problem?
While writing a Rust plugin, I ran into three different use cases where I needed to convert between Rust API wrappers and raw pointers to the C FFI types:

1. Using binaryninjacore_sys to call functions that don't have a Rust wrapper yet (in my case, BNParseTypeString).
2. Communicating with Python code that is using BN's Python API (example - not the best code but it works).
3. Using a raw pointer as a hash map key (so that I can keep a per-object cache, but without keeping the object alive as would happen if I just used the wrapper type as the key).

Currently I am accomplishing all three by transmuting between the Rust wrapper types and raw pointers, but that is an abstraction violation. It would be better if I could use the proper APIs for this.

Are any alternative solutions acceptable?
In theory, you could obviate the need to drop down to the C API by providing the functionality natively. Respectively:

1. Wrap all the missing functions.
2. Add some kind of built-in Python object conversion functionality.
3. Add some kind of 'unique ID' method or weak reference type.

But even then I think there would be use cases here and there for dropping down to the C API, e.g. interop with C or C++ code.

[emesare]

Ive been meaning to do this for a while, I need this for WARP FFI. I also need to mark these functions appropriately, specifically the ones which will leak (into_raw).

[emesare]

Also for the BNParseTypeString, I know that specific API is not available, but IIRC it was superseded by the TypeParser which is available:

binaryninja-api/rust/tests/type_parser.rs

Lines 37 to 46 in bcdc0d9

	fn test_string_to_type(_session: &Session) {
	let platform = Platform::by_name("windows-x86_64").expect("windows-x86_64 exists");
	let plat_type_container = platform.type_container();
	let parser = CoreTypeParser::default();
	let parsed_type = parser
	.parse_type_string("int32_t", &platform, &plat_type_container)
	.expect("Parsed int32_t");
	let test_type = Type::int(4, true);
	assert_eq!(test_type, parsed_type.ty);
	}

You just need to get the type container from the binary view.

[emesare]

For the hash map I would highly recommend you to instead use an ID, the WARP integration does this like so:

binaryninja-api/plugins/warp/src/cache.rs

Lines 417 to 441 in bcdc0d9

	/// A unique function ID, used for caching.
	#[derive(Copy, Clone, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)]
	pub struct FunctionID(u64);
	impl From<&BNFunction> for FunctionID {
	fn from(value: &BNFunction) -> Self {
	let mut hasher = DefaultHasher::new();
	hasher.write_u64(value.start());
	hasher.write_u64(value.lowest_address());
	hasher.write_u64(value.highest_address());
	Self(hasher.finish())
	}
	}
	impl From<BNRef<BNFunction>> for FunctionID {
	fn from(value: BNRef<BNFunction>) -> Self {
	Self::from(value.as_ref())
	}
	}
	impl From<Guard<'_, BNFunction>> for FunctionID {
	fn from(value: Guard<'_, BNFunction>) -> Self {
	Self::from(value.as_ref())
	}
	}

[comex]

Ive been meaning to do this for a while, I need this for WARP FFI. I also need to mark these functions appropriately, specifically the ones which will leak (into_raw).

Cool.

Also for the BNParseTypeString, I know that specific API is not available, but IIRC it was superseded by the TypeParser which is available:

Aha. Thanks. I didn't notice those APIs because I was searching https://rust.binary.ninja/ which is on an older version of the crate that doesn't have them yet.

For the hash map I would highly recommend you to instead use an ID, the WARP integration does this like so:

In my case the thing I'm trying to cache is not a function but the BinaryView itself, so I don't know if there are any particular values that are guaranteed to be unique compared to all other BinaryViews in the same process. For that matter, I don't think your function hash is guaranteed to be unique either… it's possible to have multiple functions in the same binary with the same address bounds but different Platforms.

[emesare]

For the hash map I would highly recommend you to instead use an ID, the WARP integration does this like so:

In my case the thing I'm trying to cache is not a function but the BinaryView itself, so I don't know if there are any particular values that are guaranteed to be unique compared to all other BinaryViews in the same process.

You can use the session ID, its unique per view opening:

binaryninja-api/plugins/warp/src/cache.rs

Line 400 in bcdc0d9

hasher.write_usize(value.file().session_id());

For that matter, I don't think your function hash is guaranteed to be unique either… it's possible to have multiple functions in the same binary with the same address bounds but different Platforms.

The FunctionID is not unique for a view its unique for a platform, the caches all work under the platform. I was just giving it as an example.

[psifertex]

Also for the BNParseTypeString, I know that specific API is not available, but IIRC it was superseded by the TypeParser which is available:

Aha. Thanks. I didn't notice those APIs because I was searching https://rust.binary.ninja/ which is on an older version of the crate that doesn't have them yet.

FWIW, you can search the dev-version of the docs online: https://dev-rust.binary.ninja/binaryninja/