You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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).
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).
The text was updated successfully, but these errors were encountered: