Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No reliable way to retrieve the IL of a function without using try/catch #6170

Open
xusheng6 opened this issue Nov 21, 2024 · 1 comment
Open
Assignees
Labels
Component: API Issue needs changes to the API Effort: Low Issue should take < 1 week Impact: Low Issue is a papercut or has a good, supported workaround Type: Enhancement Issue is a small enhancement to existing functionality

Comments

@xusheng6
Copy link
Member

While working on the binja backend for capa, I noticed a few outstanding crashes: mandiant/capa#2406 (comment), and mandiant/capa#2249. After troubleshooting this, I realized that to reliably get the IL of a function, we have to use try/catch for now.

Here is what could happen when I try to retrieve the IL of a function:

  1. It is immediately available
  2. It is not yet available, but can be retrieved briefly
  3. It cannot be retrieved

Now think of the case of func.mlil, it will work for case 1 & 2, but it will throw an exception in case 3. If I use func.mlil_if_available, then it will work for case 1 & 3, but not for case 2 according to my test. I had to use this code pattern to handle all cases:

        try:
            mlil = f.mlil
        except ILException:
            return

        if mlil is None:
            return

        for mlil_bb in mlil.basic_blocks:
            pass

Which is quite ugly and inconvenient. It would be great if we can devise a way to retrieve the IL without needing to write code in the above pattern. Potentially we could just create a new API that wraps the above code logic

@xusheng6
Copy link
Member Author

Related to #6020

@xusheng6 xusheng6 added Type: Enhancement Issue is a small enhancement to existing functionality Component: API Issue needs changes to the API Impact: Low Issue is a papercut or has a good, supported workaround Effort: Low Issue should take < 1 week labels Nov 26, 2024
@xusheng6 xusheng6 self-assigned this Nov 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: API Issue needs changes to the API Effort: Low Issue should take < 1 week Impact: Low Issue is a papercut or has a good, supported workaround Type: Enhancement Issue is a small enhancement to existing functionality
Projects
None yet
Development

No branches or pull requests

1 participant