Description
Settings that control the engine partitioning.
These switches are used by the engine to control how it partitions addresses into instructions and static data, instructions into basic blocks, and basic blocks and static data into functions. Some of these settings are copied into a Partitioner object while others affect the Engine directly.
The runtime descriptions and command-line parser for these switches can be obtained from Engine::settings.
Definition at line 371 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
#include <Rose/BinaryAnalysis/Partitioner2/BasicTypes.h>
Public Attributes | |
| BasePartitionerSettings | base |
| Base partitioner settings. | |
| std::vector< rose_addr_t > | functionStartingVas |
| Starting addresses for disassembly. | |
| bool | followingGhostEdges = false |
| Whether to follow ghost edges. | |
| bool | discontiguousBlocks = true |
| Whether to allow discontiguous basic blocks. | |
| size_t | maxBasicBlockSize = 0 |
| Maximum size for basic blocks. | |
| std::vector< rose_addr_t > | ipRewrites |
| CFG edge rewrite pairs. | |
| bool | findingFunctionPadding = true |
| Whether to find function padding. | |
| bool | findingDeadCode = true |
| Whether to find dead code. | |
| rose_addr_t | peScramblerDispatcherVa = 0 |
| PE-Scrambler dispatcher address. | |
| size_t | findingIntraFunctionCode = 10 |
| Whether to find intra-function code. | |
| bool | findingIntraFunctionData = true |
| Whether to find intra-function data. | |
| bool | findingInterFunctionCalls = true |
| Whether to search for function calls between exiting functions. | |
| bool | findingFunctionCallFunctions = true |
| Whether to turn function call targets into functions. | |
| bool | findingEntryFunctions = true |
| Whether to make functions at program entry points. | |
| bool | findingErrorFunctions = true |
| Whether to make error handling functions. | |
| bool | findingImportFunctions = true |
| Whether to make functions at import addresses. | |
| bool | findingExportFunctions = true |
| Whether to make functions at export addresses. | |
| bool | findingSymbolFunctions = true |
| Whether to make functions according to symbol tables. | |
| AddressInterval | interruptVector |
| Property: Location of machine interrupt vector. | |
| bool | doingPostAnalysis = true |
| Whether to perform any post-partitioning analysis steps. | |
| bool | doingPostFunctionMayReturn = true |
| Whether to run the function may-return analysis. | |
| bool | doingPostFunctionStackDelta = true |
| Whether to run the function stack delta analysis. | |
| bool | doingPostCallingConvention = false |
| Whether to run calling-convention analysis. | |
| bool | doingPostFunctionNoop = false |
| Whether to run no-op function analysis. | |
| FunctionReturnAnalysis | functionReturnAnalysis = MAYRETURN_DEFAULT_YES |
| How to run the function may-return analysis. | |
| size_t | functionReturnAnalysisMaxSorts = 50 |
| Maximum number of function may-return sorting operations. | |
| bool | findingDataFunctionPointers = false |
| Whether to search static data for function pointers. | |
| bool | findingCodeFunctionPointers = false |
| Whether to search existing instructions for function pointers. | |
| bool | findingThunks = true |
| Whether to match thunk patterns. | |
| bool | splittingThunks = false |
| Whether to split thunk instructions into mini functions. | |
| SemanticMemoryParadigm | semanticMemoryParadigm = LIST_BASED_MEMORY |
| Type of container for semantic memory. | |
| AddressInterval | namingConstants = AddressInterval::hull(4096, AddressInterval::whole().greatest()) |
| Whether to give names to constants. | |
| AddressInterval | namingStrings = AddressInterval::hull(4096, AddressInterval::whole().greatest()) |
| Addresses where strings might start. | |
| bool | namingSyscalls = true |
| Whether to give names to system calls. | |
| boost::filesystem::path | syscallHeader |
| Header file in which system calls are defined. | |
| bool | demangleNames = true |
| Whether to demangle names. | |
Member Data Documentation
◆ base
| BasePartitionerSettings Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::base |
Base partitioner settings.
Definition at line 373 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ functionStartingVas
| std::vector<rose_addr_t> Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::functionStartingVas |
Starting addresses for disassembly.
This is a list of addresses where functions will be created to start recursive disassembly. These addresses are in addition to entry addresses, addresses from symbols, addresses from configuration files, etc.
Definition at line 379 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ followingGhostEdges
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::followingGhostEdges = false |
Whether to follow ghost edges.
A "ghost edge" is a control flow graph (CFG) edge that would be present if the CFG-building analysis looked only at individual instructions, but would be absent when the analysis considers coarser units of code. For instance, consider the following x86 instructions:
If the analysis looks only at instruction 3, then it appears to have two CFG successors: instructions 4 and 5. But if the analysis looks at the first three instructions collectively it will ascertain that instruction 3 has an opaque predicate, that the only valid CFG successor is instruction 4, and that the edge from 3 to 5 is a "ghost". In fact, if there are no other incoming edges to these instructions, then instructions 1 through 4 will form a basic block with the (unconditional) branch instruction in its interior. The ability to look at larger units of code than single instructions is controlled by the BasePartitionerSettings::usingSemantics property.
If this followingGhostEdges property is true then ghost edges will be added back into the CFG as real edges, which might force a basic block to end, as in this example, at the branch instruction and may attempt to disassemble additional code by folowing all edges.
Definition at line 405 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ discontiguousBlocks
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::discontiguousBlocks = true |
Whether to allow discontiguous basic blocks.
ROSE's definition of a basic block allows two consecutive instructions, A and B, to be arranged in memory such that B does not immediately follow A. Clearing this property prevents this and would force A and B to belong to separate basic blocks.
Definition at line 412 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ maxBasicBlockSize
| size_t Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::maxBasicBlockSize = 0 |
Maximum size for basic blocks.
This property is the maximum size for basic blocks measured in number of instructions. Any basic block that would contain more than this number of instructions is split into multiple basic blocks. Having smaller basic blocks makes some intra-block analysis faster, but they have less information. A value of zero indicates no limit.
Definition at line 419 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ ipRewrites
| std::vector<rose_addr_t> Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::ipRewrites |
CFG edge rewrite pairs.
This property is a list of old/new instruction pointer pairs that describe how to rewrite edges of the global control flow graph. Whenever an instruction has a successor whose address is an old address, it will be replaced with a successor edge that points to the new address. This list must have an even number of elements where element 2*i+0 is and old address and element 2*i+1 is the corresponding new address.
Definition at line 427 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingFunctionPadding
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingFunctionPadding = true |
Whether to find function padding.
If set, then the partitioner will look for certain padding bytes appearing before the lowest address of a function and add those bytes to the function as static data.
Definition at line 433 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingDeadCode
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingDeadCode = true |
Whether to find dead code.
If ghost edges are being discovered (see BasePartitionerSettings::usingSemantics and followingGhostEdges) and are not being inserted into the global CFG, then the target address of the ghost edges might not be used as code addresses during the code discovery phase. This property, when true, will cause the target address of ghost edges to be used to discover additional instructions even if they have no incoming CFG edges.
Definition at line 441 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ peScramblerDispatcherVa
| rose_addr_t Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::peScramblerDispatcherVa = 0 |
PE-Scrambler dispatcher address.
If non-zero then the partitioner defeats PE-scrambled binary obfuscation by replacing control flow edges that go through this function with the de-scrambled control flow edge.
Definition at line 447 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingIntraFunctionCode
| size_t Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingIntraFunctionCode = 10 |
Whether to find intra-function code.
If positive, the partitioner will look for parts of memory that were not disassembled and occur between other parts of the same function, and will attempt to disassemble that missing part and link it into the surrounding function. It will perform up to n passes across the entire address space.
Definition at line 454 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingIntraFunctionData
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingIntraFunctionData = true |
Whether to find intra-function data.
If set, the partitioner will look for parts of memory that were not disassembled and occur between other parts of the same function, and will treat the missing part as static data belonging to that function.
Definition at line 460 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingInterFunctionCalls
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingInterFunctionCalls = true |
Whether to search for function calls between exiting functions.
If set, then EngineBinary::makeFunctionFromInterFunctionCalls is invoked, which looks for call-like code between existing functions in order to create new functions at the call target addresses.
Definition at line 466 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingFunctionCallFunctions
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingFunctionCallFunctions = true |
Whether to turn function call targets into functions.
If set, then sequences of instructions that behave like a function call (including plain old function call instructions) will cause a function to be created at the call's target address under most circumstances.
Definition at line 472 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingEntryFunctions
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingEntryFunctions = true |
Whether to make functions at program entry points.
If set, then all program entry points are assumed to be the start of a function.
Definition at line 477 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingErrorFunctions
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingErrorFunctions = true |
Whether to make error handling functions.
If set and information is available about error handling and exceptions, then that information is used to create entry points for functions.
Definition at line 483 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingImportFunctions
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingImportFunctions = true |
Whether to make functions at import addresses.
If set and the file contains a table describing the addresses of imported functions, then each of those addresses is assumed to be the entry point of a function.
Definition at line 489 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingExportFunctions
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingExportFunctions = true |
Whether to make functions at export addresses.
If set and the file contains a table describing the addresses of exported functions, then each of those addresses is assumed to be the entry point of a function.
Definition at line 495 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingSymbolFunctions
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingSymbolFunctions = true |
Whether to make functions according to symbol tables.
If set and the file contains symbol tables, then symbols that define function addresses cause functions to be created at those addresses.
Definition at line 501 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ interruptVector
| AddressInterval Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::interruptVector |
Property: Location of machine interrupt vector.
If non-empty, the partitioner will treat the specified area as a machine interrupt vector. The effect of the vector varies by architecture.
Definition at line 507 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ doingPostAnalysis
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::doingPostAnalysis = true |
Whether to perform any post-partitioning analysis steps.
If set, then each of the enabled post-partitioning analysis steps are executed. Some of these can be quite expensive, but they can be enabled and disabled individually. Those that are enabled are only run if this property also is set.
Definition at line 513 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ doingPostFunctionMayReturn
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::doingPostFunctionMayReturn = true |
Whether to run the function may-return analysis.
Determines whether the may-return analysis is run when doingPostAnalysis is true.
Definition at line 518 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ doingPostFunctionStackDelta
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::doingPostFunctionStackDelta = true |
Whether to run the function stack delta analysis.
Determines whether the stack delta analysis is run when doingPostAnalysis is true.
Definition at line 523 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ doingPostCallingConvention
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::doingPostCallingConvention = false |
Whether to run calling-convention analysis.
Determines whether calling convention analysis is run on each function when doingPostAnalysis is true.
Definition at line 528 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ doingPostFunctionNoop
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::doingPostFunctionNoop = false |
Whether to run no-op function analysis.
Determines whether function no-op analysis is run on each function when doingPostAnalysis is true. This analysis determines whether a function is effectively a no-op and gives it a name indicative of a no-op if it is one.
Definition at line 534 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ functionReturnAnalysis
| FunctionReturnAnalysis Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::functionReturnAnalysis = MAYRETURN_DEFAULT_YES |
How to run the function may-return analysis.
The caller can decide if and how may-return analysis runs and whether an indeterminate result should be considered true or false.
Definition at line 540 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ functionReturnAnalysisMaxSorts
| size_t Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::functionReturnAnalysisMaxSorts = 50 |
Maximum number of function may-return sorting operations.
If function may-return analysis is being run, the functions are normally sorted according to their call depth (after arbitrarily breaking cycles) and the analysis is run from the leaf functions to the higher functions in order to minimize forward dependencies. However, the functions need to be resorted each time a new function is discovered and/or when the global CFG is sufficiently modified. Therefore, the total cost of the sorting can be substantial for large specimens. This property limits the total number of sorting operations and reverts to unsorted analysis once the limit is reached. This allows smaller specimens to be handled as accurately as possible, but still allows large specimens to be processed in a reasonable amount of time. The limit is based on the number of sorting operations rather than the specimen size.
Definition at line 552 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingDataFunctionPointers
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingDataFunctionPointers = false |
Whether to search static data for function pointers.
If this property is set, then the partitioner will scan static data to look for things that might be pointers to functions.
Definition at line 558 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingCodeFunctionPointers
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingCodeFunctionPointers = false |
Whether to search existing instructions for function pointers.
If this property is set, then the partitioner scans existing instructions to look for constants that seem to be pointers to functions that haven't been discovered yet.
Definition at line 564 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ findingThunks
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::findingThunks = true |
Whether to match thunk patterns.
If set, then the partitioner expands the list of function prologue patterns to include common thunk patterns when searching for funcitons in undiscovered areas of memory. This setting does not control whether thunk instructions are split into their own functions (see splittingThunks).
Definition at line 571 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ splittingThunks
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::splittingThunks = false |
Whether to split thunk instructions into mini functions.
If set, then functions whose entry instructions match a thunk pattern are split so that those thunk instructions are in their own function.
Definition at line 577 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ semanticMemoryParadigm
| SemanticMemoryParadigm Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::semanticMemoryParadigm = LIST_BASED_MEMORY |
Type of container for semantic memory.
Determines whether Partitioner objects created by this engine will be configured to use list-based or map-based semantic memory states. The list-based states are more precise, but they're also slower.
Definition at line 583 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ namingConstants
| AddressInterval Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::namingConstants = AddressInterval::hull(4096, AddressInterval::whole().greatest()) |
Whether to give names to constants.
Within instruciton operands, any constants that fall within this set of addresses and which have a label associated with them (such as names of symbols) are given a comment consisting of that label. Setting this to empty disables assigning such labels to integer values.
See also, Modules::nameConstants.
Definition at line 592 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ namingStrings
| AddressInterval Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::namingStrings = AddressInterval::hull(4096, AddressInterval::whole().greatest()) |
Addresses where strings might start.
Within instruction operands, any constants that fall within this set of addresses are checked to see if they point into an ASCII C-style NUL-terminated string. If so, and if the constant doesn't already have a comment, then a comment is attached describing the string. Setting this to empty disables assigning string literal comments to integer values.
Definition at line 599 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ namingSyscalls
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::namingSyscalls = true |
Whether to give names to system calls.
If this property is set, then the partitioner makes a pass after the control flow graph is finalized and tries to give names to system calls using the Rose::BinaryAnalysis::SystemCall analysis.
Definition at line 605 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ syscallHeader
| boost::filesystem::path Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::syscallHeader |
Header file in which system calls are defined.
If this property is not empty, then the specified Linux header file is parsed to obtain the mapping between system call numbers and their names. Otherwise, any analysis that needs system call names obtains them by looking in predetermined system header files.
Definition at line 613 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
◆ demangleNames
| bool Rose::BinaryAnalysis::Partitioner2::PartitionerSettings::demangleNames = true |
Whether to demangle names.
If this property is set, then names are passed through a demangle step, which generally converts them from a low-level format to a source language format.
Definition at line 619 of file Rose/BinaryAnalysis/Partitioner2/BasicTypes.h.
The documentation for this struct was generated from the following file:
