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

Function Addr and Offset #3

Closed
sraboy opened this issue Aug 24, 2017 · 4 comments
Closed

Function Addr and Offset #3

sraboy opened this issue Aug 24, 2017 · 4 comments

Comments

@sraboy
Copy link

sraboy commented Aug 24, 2017

I don't use Binja so I'm not sure how it's handled there but the callback returns the plain addr. The addr only refers to the buffer so the matched function's actual address in the binary is at addr+funk.offset.

Was that intentional?

@thebabush
Copy link
Owner

addr is actually the offset inside the buffer given to the matching function, yes. In the case of the Binja plugin I wrote, buffers start at the beginning of functions so addr + funk.offset is correct. It made sense in my head :)

The naming of the variable isn't great... But other than that, is there something I'm missing? My idea was that a "dumb" matching function is actually better since it can be easily adapted to any situation. I'm open to suggestions ;)

@sraboy
Copy link
Author

sraboy commented Aug 26, 2017

Haha, I think it's just the naming throwing me off. I'm with you on the "dumb" function thing (though a **kwargs could be helpful).

I'm working on implementing ref funcs and, with angr, I also have to consider its symbol.relative_addr and kb.function.addr, plus the binary's remapped base address. Coupled with addr+funk.offset, there's just a lot of addr vars being thrown around.

@thebabush
Copy link
Owner

Feel free to rename / change things however you want ;) as long as it is still easy to use and works as intended.

@sraboy
Copy link
Author

sraboy commented Aug 31, 2017

No problem. I mostly wanted to be sure I was understanding it correctly. If I end up doing a more substantive PR for REF functions, I might throw that in as a commit but I try not to change "internal implementation" details.

@sraboy sraboy closed this as completed Aug 31, 2017
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

No branches or pull requests

2 participants