How do I access current_token in a plugin command?

[lks128]

Dear community,

I made a snippet to help me with static analysis of C++ structures and now want to convert it to a plugin.

Idea is simple: I highlight a call to constructor function, it identifies the structure size, creates type, renames constructor and changes type of the pointer in the constructor arguments. On the screenshot below you can see the highlighted constructor call after renaming.

This is the snippet itself:

# C++ define type

bv.begin_undo_actions()
try:
    size = results2[current_token.text]
    name = current_token.text.replace('sub_', 'type_')

    t = bv.parse_type_string(f'struct test{{__padding char _0[{size}];}}')[0]
    bv.define_user_type(name, t)

    fun = bv.get_functions_by_name(current_token.text)[0]
    fun.name = f'{name}_Init'
    fun.parameter_vars[0].type = bv.parse_type_string(f'{name}*')[0]
finally:
    bv.commit_undo_actions()

I was trying to replicate this functionality in an UI plugin, so that I could right click the constructor and select "Define type", however I am facing a problem that the current_token is not defined in the plugin action context.

I tried to work around it with using PluginCommand.register_for_range, however when executed from HLIL range does not contain actual call.

I also tried to use PluginCommand.register_for_function, however it gets the function currently visible on the screen, not the one which is highlighted. It would work if I would navigate a function before triggering the command, but I would like to avoid doing that.

Could you please give me an idea how could I achieve it with the UI plugin?

Best regards,
Andris

[lks128]

I tried this before, but was getting a strange error that something is not available / does not exist anymore, but now it works.

    log_info(f"address: {hex(start)} - {hex(start+end)}")
    context = UIContext.activeContext()
    print(f'context = {context}')

    action_handler = context.getCurrentActionHandler()
    print(f'action_handler = {action_handler}')

    view_frame = context.getCurrentViewFrame()
    print(f'view_frame = {view_frame}')
    
    view = context.getCurrentView()
    print(f'view = {view}')

    view_location = view_frame.getViewLocation()
    print(f'view_location = {view_location}')

    action_context = None
    if view is not None:
        action_context = view.actionContext()
    elif action_handler is not None:
        action_context = action_handler.actionContext()

    token_state = action_context.token
    print(f'token_state = {token_state}')

    token = token_state.token if token_state.valid else None
    print(f'token = {token}')

This produces the log:

[Default] context = <binaryninjaui.UIContext object at 0x0000024DAC8F2200>
[Default] action_handler = <binaryninjaui.UIActionHandler object at 0x0000024DAC94EF80>
[Default] view_frame = <binaryninjaui.ViewFrame(0x24da56f0400) at 0x0000024DAC932F00>
[Default] view = <binaryninjaui.View object at 0x0000024DAC933200>
[Default] view_location = <binaryninjaui.ViewLocation object at 0x0000024DAC933240>
[Default] token_state = <binaryninjaui.HighlightTokenState object at 0x0000024DAC9332C0>
[Default] token = type_458bc0_Init

I guess that's it 😆

[psifertex]

Yup, that's basically it. The short summary is that the register_for APIs don't give you UI features as they're designed to be triggerable even via headless if needed and so the callbacks are specific to things unrelated to the UI. The UIAction system was designed for this so that is indeed the correct way to write a plugin to do that.

Note that you can also register a UI action that receives a callback when triggered that can access the token without getting it from the current view.

And thanks for coming back to put your answer that can help others!

[lks128]

Oh, thanks, UIAction might be very useful later.

What I also just realized is that for action registered with PluginCommand.register_for_function there are two entries in the context menu:

• Plugins/Plugin name/Action name
• Selection target/Plugin name/Action name

Plugins/Plugin name/Action name will pass current function as a second parameter, whereas Selection target/Plugin name/Action name will pass function under the cursor. I am not sure how I did not notice it before...

So I think for my use case registering for function and using via selection target in the context menu will be the best as we are getting the needed function directly in the arguments.

It is a bit confusing though that the same action can be accessed from the different menus and will have different behavior. It makes sense though if we want to have an option whether to target current function or selected function.

[psifertex]

Ahh, yes, I kinda glossed over that you were always going to be working with functions and was thinking about all tokens in general -- yeah, the existing system works perfectly then as long as you remember to select the specific function and use selection target. Sorry I didn't think to suggest that!