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

Adding architecture support dynamically #37

Open
schomatis opened this issue Sep 12, 2016 · 1 comment
Open

Adding architecture support dynamically #37

schomatis opened this issue Sep 12, 2016 · 1 comment

Comments

@schomatis
Copy link

It would be very useful to employ BARF's REIL analysis tools for architectures not supported in BARF without modifying its core but rather through a defined API that allows to add support for an architecture (information, disassembler, REIL translator) in a dynamic fashion. In this way, BARF would be used as a library inside another project.

An example of this use case is the Hexag00n project (that works with the Hexagon architecture, currently not supported in BARF), where BARF's REIL analysis tools would be very useful. Hexag00n already has its own disassembler (for the Hexagon architecture) and REIL translator, porting these to the BARF core is not a trivial task, nor it is desirable: BARF and Hexag00n should be able to work together while avoiding as much coupling as possible.

In this scenario Hexag00n will use BARF as a library facilitating the Hexagon architecture support to BARF in a dynamic fashion, without modifying BARF's source code, e.g., forcing BARF to import Hexag00n disassembler (and thus generating a circular dependency). An API has to be defined in BARF to be able to import that architecture support, for this purpose the load_architecture method has been added to the BARF core. This method is employed in an Hexag00n's example script which will be used as a first step to precisely define what has to be provided to BARF to generate REIL code (from an Hexagon binary) through the BARF framework.

For now, what has been characterized as architecture support are 3 base classes:

  • ArchitectureInformation: contains the basic definitions of an architecture like its size, registers, etc.
  • Disassembler: encapsulates the architecture disassembler.
  • Translator: encapsulates the architecture to REIL translator.

For each architecture supported, new classes have to be derived from these ones, containing all the necessary information for BARF to generate an equivalent REIL code and proceed to its analysis. Up to now these derived classes are part of the BARF core (like x86 and ARM architectures). With this new functionality, the objective is, through a defined API, being able to provide architecture support on the fly while using BARF as a library (imported in the working project).

@schomatis
Copy link
Author

The list of BARF's supported architectures is static and can't be modified by the load_architecture method.

When BARF opens a binary ELF file, the _get_arch_elf function is called to figure out the machine type from the ELF header. As the Hexagon architecture is not registered it raises an exception (Machine not supported).

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

1 participant